[cvsnt] Segmentation fault on build

Albe alberto.difede at gmail.com
Wed Feb 6 14:15:50 GMT 2008

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*) 
==17647==    by 0x808B999: main (main.cpp:728)
==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== 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-
==17647==    by 0x407CEFC: (within /usr/lib/libcvstools-
==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

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook