Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Searching online briefly did spot an issue with old versions of glibc. My distro is a slackware 10.2 heavily customized, therefore upgrading glibc would be a real pain in the a... Basically it would mean replacing the whole OS, something which i'd rather not do. Here are further details from valgrind with the --show-reachable=yes arg: ==17647== 15 bytes in 1 blocks are still reachable in loss record 1 of 3 ==17647== at 0x401B81D: malloc (vg_replace_malloc.c:207) ==17647== by 0x424444F: strdup (in /lib/tls/libc-2.3.5.so) ==17647== by 0x4088ABE: CGlobalSettings::SetCvsCommand(char const*) (GlobalSettings.cpp:592) ==17647== by 0x808B999: main (main.cpp:728) ==17647== ==17647== ==17647== 71 bytes in 4 blocks are still reachable in loss record 2 of 3 ==17647== at 0x401B81D: malloc (vg_replace_malloc.c:207) ==17647== by 0x80C0C7C: xmalloc (subr.cpp:81) ==17647== by 0x80C0E4F: xstrdup(char const*) (subr.cpp:205) ==17647== by 0x808B9AD: main (main.cpp:734) ==17647== ==17647== ==17647== 960 bytes in 1 blocks are still reachable in loss record 3 of 3 ==17647== at 0x401BCBD: operator new(unsigned) (vg_replace_malloc.c:224) ==17647== by 0x4174569: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.7) ==17647== by 0x4174478: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==17647== by 0x4174149: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.7) ==17647== by 0x408B49B: __static_initialization_and_destruction_0(int, int) (stl_alloc.h:232) ==17647== by 0x408B5C1: _GLOBAL__I_sHandlers (stl_map.h:120) ==17647== by 0x408BA74: (within /usr/lib/libcvstools-2.5.03.2382.so) ==17647== by 0x407CEFC: (within /usr/lib/libcvstools-2.5.03.2382.so) ==17647== by 0x400B6FD: call_init (in /lib/ld-2.3.5.so) ==17647== by 0x400B555: _dl_init (in /lib/ld-2.3.5.so) ==17647== by 0x40007EE: (within /lib/ld-2.3.5.so) Regarding your suggestion, could you please guide me on how to find out "what _vgnU_freeres and __libc_freeres are actually trying to free"? Unfortunately, i'm not a developer. Being cvsnt a process spawned by a wrapper i'm not worried too much on the service availability, but nonetheless a crash during a bug tag could hinder operations a lot, so what do you suggest to do? Again, thanks a lot. Tony Hoyle wrote: > Albe wrote: >> ==17489== >> ==17489== 1 errors in context 1 of 1: >> ==17489== Invalid free() / delete / delete[] >> ==17489== at 0x401C689: free (vg_replace_malloc.c:323) >> ==17489== by 0x42D0F4B: free_mem (in /lib/tls/libc-2.3.5.so) >> ==17489== by 0x42D0A14: __libc_freeres (in /lib/tls/libc-2.3.5.so) >> ==17489== by 0x401735C: _vgnU_freeres (vg_preloaded.c:60) >> ==17489== by 0x4207A05: exit (in /lib/tls/libc-2.3.5.so) >> ==17489== by 0x806D3D0: error_exit() (error.cpp:55) >> ==17489== by 0x808CF7A: main (main.cpp:1043) >> > If that was the only error that valgrind found it might be worth asking > if there are any updates for your distro. It's failing after exit() > which means that the libc shutdown itself is failing.. it's not running > cvsnt code by that point. > > If we were corrupting something or overrunning a buffer I'd expect > valgrind to find it much earlier in the process, so I'm not sure what's > going on - if you can find out what _vgnU_freeres and __libc_freeres are > actually trying to free then it would help a lot. > > Tony