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.
Ciao everybody, i found several cvsnt segmentation faults in my syslog which i didn't notice, mainly because daily usage didn't highlight any error. I recompiled from sources, but it didn't fix things. Here's the message from the syslog: cvsnt[25107]: segfault at 00000000 eip 08052ca2 esp bff567c0 error 4 (besides different memory addressing it is the same kind of error) and here is the error found by valgrind: ==17489== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 39 from 1) ==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) ==17489== Address 0x41dc2a8 is not stack'd, malloc'd or (recently) free'd --17489-- --17489-- supp: 39 Ubuntu-stripped-ld.so ==17489== ==17489== IN SUMMARY: 1 errors from 1 contexts (suppressed: 39 from 1) ==17489== ==17489== malloc/free: in use at exit: 1,046 bytes in 6 blocks. ==17489== malloc/free: 13 allocs, 8 frees, 2,883 bytes allocated. ==17489== ==17489== searching for pointers to 6 not-freed blocks. ==17489== checked 497,856 bytes. ==17489== ==17489== LEAK SUMMARY: ==17489== definitely lost: 0 bytes in 0 blocks. ==17489== possibly lost: 0 bytes in 0 blocks. ==17489== still reachable: 1,046 bytes in 6 blocks. ==17489== suppressed: 0 bytes in 0 blocks. ==17489== Reachable blocks (those to which a pointer was found) are not shown. ==17489== To see them, rerun with: --leak-check=full --show-reachable=yes --17489-- memcheck: sanity checks: 6 cheap, 2 expensive --17489-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --17489-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10 --17489-- memcheck: auxmaps_L2: 0 searches, 0 nodes --17489-- memcheck: SMs: n_issued = 18 (288k, 0M) --17489-- memcheck: SMs: n_deissued = 0 (0k, 0M) --17489-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) --17489-- memcheck: SMs: max_undefined = 0 (0k, 0M) --17489-- memcheck: SMs: max_defined = 53 (848k, 0M) --17489-- memcheck: SMs: max_non_DSM = 18 (288k, 0M) --17489-- memcheck: max sec V bit nodes: 1 (0k, 0M) --17489-- memcheck: set_sec_vbits8 calls: 1 (new: 1, updates: 0) --17489-- memcheck: max shadow mem size: 592k, 0M --17489-- translate: fast SP updates identified: 5,693 ( 89.8%) --17489-- translate: generic_known SP updates identified: 255 ( 4.0%) --17489-- translate: generic_unknown SP updates identified: 390 ( 6.1%) --17489-- tt/tc: 7,541 tt lookups requiring 7,737 probes --17489-- tt/tc: 7,541 fast-cache updates, 3 flushes --17489-- transtab: new 3,652 (76,438 -> 1,159,315; ratio 151:10) [0 scs] --17489-- transtab: dumped 0 (0 -> ??) --17489-- transtab: discarded 6 (150 -> ??) --17489-- scheduler: 614,660 jumps (bb entries). --17489-- scheduler: 6/4,080 major/minor sched events. --17489-- sanity: 7 cheap, 2 expensive checks. --17489-- exectx: 769 lists, 25 contexts (avg 0 per list) --17489-- exectx: 60 searches, 35 full compares (583 per 1000) --17489-- exectx: 6 cmp2, 82 cmp4, 0 cmpAll --17489-- errormgr: 10 supplist searches, 252 comparisons during search --17489-- errormgr: 40 errlist searches, 88 comparisons during search most probably things got wrong with the kernel update to version 2.6.23.1, but maybe you can help me to spot the issue. I've enabled the core dump now, so in case you wanted i can provide you with it. Thanks in advance for any help! Alberto