Re: Building a tool which links with librados

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The import-rados feature (#8276) uses librados so in my wip-8231 branch I now link with librados.   It is hard to reproduce, but I’ll play with that commit and branch.

David Zafman
Senior Developer
http://www.inktank.com
http://www.redhat.com

On Aug 21, 2014, at 4:56 PM, Sage Weil <sweil@xxxxxxxxxx> wrote:

> On Thu, 21 Aug 2014, Gregory Farnum wrote:
>> On Thu, Aug 21, 2014 at 4:37 PM, David Zafman <david.zafman@xxxxxxxxxxx> wrote:
>>> 
>>> Has anyone seen anything like this from an application linked with librados using valgrind?  Or a Segmentation fault on exit from such an application?
>>> 
>>> Invalid free() / delete / delete[] / realloc()
>>>    at 0x4C2A4BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>>    by 0x8195C12: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
>>>    by 0x13890F3: coll_t::~coll_t() (osd_types.h:468)
>>>    by 0x8944DEC: __cxa_finalize (cxa_finalize.c:56)
>>>    by 0x6E1CEC5: ??? (in /src/ceph/src/.libs/librados.so.2.0.0)
>>>    by 0x725F400: ??? (in /src/ceph/src/.libs/librados.so.2.0.0)
>>>    by 0x89449D0: __run_exit_handlers (exit.c:78)
>>>    by 0x8944A54: exit (exit.c:100)
>>>    by 0x137FF37: usage(boost::program_options::options_description&) (ceph_objectstore_tool.cc:1794)
>>>    by 0x1380572: main (ceph_objectstore_tool.cc:1849)
>> 
>> This looks fairly strange to me ? why does ceph_objectstore_tool do
>> anything with librados? I thought it was just hitting the OSD
>> filesystem structure directly.
>> Also note that the crash appears to be underneath the coll_t
>> destructor, probably in destroying its string. That combined with the
>> weird librados presence makes me think memory corruption is running
>> over the stack somewhere.
> 
> Ah, this was fixed in 5d79605319fcde330bccce5e1b07276a98be02de in the 
> wip-libcommon branch.  The problem is partly when we link libcommon 
> staticaly (ceph-objectstore-tool) and dynamically (librados) at teh same 
> time.  The easy fix here is not linking librados at all.
> 
> Not sure why we see this sometimes and not always.. maybe link order?  In 
> any case, wip-libcommon moves libcommon.la into a .so shared between 
> librados and the binary using it to avoid the problem.  Makes things 
> slightly more restrictive with mixed versions, but i suspect it is worth 
> avoiding this sort of pain.
> 
> Can you cherry-pick that commit and see if it resolves this for you?  
> And/or merge in that entire branch?
> 
> sage

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux