Certainly, I am finding evidence that memory corruption may exist in the Qt version I am using. There is no doubt that Qt statically initializes and de-initializes data simply by linking to it, too. Can someone here confirm that unless you call curl_global_init or curl_easy_init, no static data gets initialized in libcurl?   I highly doubt that libcurl itself is corrupting memory, but perhaps by linking to it + the TBB memory allocator, memory is re-arranged in a way that Qt's static data, upon deinitialization, is encountering the corruption. For example, I can confirm that by linking an empty C++ source (with nothing more than "int main() { return 0; }") against libcurl and the TBB allocator results in no memory issues according to valgrind. Similarly, linking the same empty C++ source against QtCore and TBB allocator (and no libcurl) results in memory corruption: $ valgrind ./cloud_qt_test  ==17224== Memcheck, a memory error detector ==17224== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==17224== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==17224== Command: ./cloud_qt_test ==17224==  ==17224== Invalid read of size 4 ==17224==    at 0x6DFB164: safer_scalable_free (in /acds_releases/quartuskit/13.0/28/linux32/linux/libtbbmalloc.so.2) ==17224==    by 0x6E001FA: __TBB_internal_free (in /acds_releases/quartuskit/13.0/28/linux32/linux/libtbbmalloc.so.2) ==17224==    by 0x4CDCD12: free (in /acds_releases/quartuskit/13.0/28/linux32/linux/libtbbmalloc_proxy.so.2) ==17224==    by 0xC1132D: free_mem (in /lib/libc-2.5.so) ==17224==    by 0xC10EA6: __libc_freeres (in /lib/libc-2.5.so) ==17224==    by 0x48B4451: _vgnU_freeres (vg_preloaded.c:62) ==17224==    by 0xB91073: _Exit (in /lib/libc-2.5.so) ==17224==    by 0xB14EB3: (below main) (in /lib/libc-2.5.so) ==17224==  Address 0x4cec058 is not stack'd, malloc'd or (recently) free'd ==17224==  ==17224== Invalid free() / delete / delete[] ==17224==    at 0x48BC9F8: free (vg_replace_malloc.c:366) ==17224==    by 0x6DFB17F: safer_scalable_free (in /acds_releases/quartuskit/13.0/28/linux32/linux/libtbbmalloc.so.2) ==17224==    by 0x6E001FA: __TBB_internal_free (in /acds_releases/quartuskit/13.0/28/linux32/linux/libtbbmalloc.so.2) ==17224==    by 0x4CDCD12: free (in /acds_releases/quartuskit/13.0/28/linux32/linux/libtbbmalloc_proxy.so.2) ==17224==    by 0xC1132D: free_mem (in /lib/libc-2.5.so) ==17224==    by 0xC10EA6: __libc_freeres (in /lib/libc-2.5.so) ==17224==    by 0x48B4451: _vgnU_freeres (vg_preloaded.c:62) ==17224==    by 0xB91073: _Exit (in /lib/libc-2.5.so) ==17224==    by 0xB14EB3: (below main) (in /lib/libc-2.5.so) ==17224==  Address 0x4cef840 is not stack'd, malloc'd or (recently) free'd ==17224==  ==17224==  ==17224== HEAP SUMMARY: ==17224==     in use at exit: 0 bytes in 0 blocks ==17224==   total heap usage: 1 allocs, 2 frees, 1,024 bytes allocated ==17224==  ==17224== All heap blocks were freed -- no leaks are possible ==17224==  ==17224== For counts of detected and suppressed errors, rerun with: -v ==17224== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 31 from 11)   Thanks everyone for listening in, I am loving libcurl and appreciate this mailing list and the experts here. ________________________________ From: Lijo Antony <lta@one.com> To: curl-library@cool.haxx.se Sent: Tuesday, September 18, 2012 10:22 PM Subject: Re: Question about compatibility with TBB allocator On 09/19/2012 08:37 AM, Rob Romano wrote: > > When it turns, it segfaults at exit (cleaning up some Qt static data): > > #0 0x00002aaaae19961e in > rml::internal::FreeBlockPool::returnBlock(rml::internal::Block*) () from > /data/rromano/13.0/acds/quartus/linux64/libtbbmalloc.so.2 > #1 0x00002aaaae19b2e5 in safer_scalable_free () from > /data/rromano/13.0/acds/quartus/linux64/libtbbmalloc.so.2 > #2 0x00002aaaadf94039 in free () from > /data/rromano/13.0/acds/quartus/linux64/libtbbmalloc_proxy.so.2 > #3 0x000000000040f350 in mem_delete_wrapper(void*, char const**) () > #4 0x000000000040f3c5 in operator delete(void*) () > #5 0x00002aaaac467662 in QReadWriteLock::~QReadWriteLock() () from > /data/rromano/13.0/acds/quartus/linux64/libQtCore.so.4 > #6 0x00002aaaac4e6058 in ?? () from > /data/rromano/13.0/acds/quartus/linux64/libQtCore.so.4 > #7 0x0000003b32a337fe in __cxa_finalize () from /lib64/libc.so.6 > #8 0x00002aaaac44fcb3 in ?? () from > /data/rromano/13.0/acds/quartus/linux64/libQtCore.so.4 > #9 0x00007fffffffd4d0 in ?? () > #10 0x00002aaaac5d2501 in _fini () from > /data/rromano/13.0/acds/quartus/linux64/libQtCore.so.4 > #11 0x00007fffffffd4d0 in ?? () > I think it's better to ask in Qt mailing list. They would be able to help you. -lijo ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette:  http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-09-19