|
From: Vianney L. <lec...@ne...> - 2004-05-26 13:07:46
|
Hello, I tried to use valgrind 2.1.1 (debian package and also compiled from sources) and I have different issue on different application. It's a unstable Debian distro, bi xeon processor 2.4GHz with 4GB physical RAM (and 2GB more of swap). Linux ater 2.6.5-grsec #18 SMP Wed May 5 22:33:22 CEST 2004 i686 unknown The command line is: valgrind --tool=memcheck -v --logfile=res src/myapp Applications work fine without valgrind and use multithread (pthread) and stlport, all C++. The log of the first application: ==4299== valgrind: vg_libpthread.c:2505 (se_remap): Assertion `res == 0' failed. ==4299== Please report this bug at: valgrind.kde.org ==4299== discard syms at 0x3C503000-0x3C50D000 in /lib/tls/libnss_files-2.3.2.so due to munmap() ==4299== ==4299== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 29 from 1) --4299-- --4299-- supp: 29 Ugly strchr error in /lib/ld-2.3.2.so ==4299== malloc/free: in use at exit: 12824394 bytes in 10142 blocks. ==4299== malloc/free: 67466 allocs, 57324 frees, 22496299 bytes allocated. ==4299== --4299-- TT/TC: 0 tc sectors discarded. --4299-- 17840 chainings, 0 unchainings. --4299-- translate: new 25639 (468481 -> 6410002; ratio 136:10) --4299-- discard 175 (2421 -> 34332; ratio 141:10). --4299-- dispatch: 213050000 jumps (bb entries), of which 51962354 (24%) were unchained. --4299-- 7697/663010 major/minor sched events. 54145 tt_fast misses. --4299-- reg-alloc: 5475 t-req-spill, 1171894+37782 orig+spill uis, 138518 total-reg-r. --4299-- sanity: 6120 cheap, 245 expensive checks. --4299-- ccalls: 140378 C calls, 53% saves+restores avoided (442610 bytes) --4299-- 193303 args, avg 0.87 setup instrs each (47536 bytes) --4299-- 0% clear the stack (420735 bytes) --4299-- 35946 retvals, 30% of reg-reg movs avoided (21080 bytes) And the second issue is on another application, it seems that valgrind can't allocate more memory (the application uses 260MB without valgrind): valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != ((void *)0)' failed. ==14751== at 0xB8029FB5: vgPlain_skin_assert_fail (vg_mylibc.c:1211) ==14751== by 0xB8029FB4: assert_fail (vg_mylibc.c:1207) ==14751== by 0xB8029FF2: vgPlain_core_assert_fail (vg_mylibc.c:1218) ==14751== by 0xB8026AA6: vgPlain_arena_malloc (vg_malloc2.c:535) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==14751== at 0x3C01F3E1: operator new(unsigned) (vg_replace_malloc.c:107) ==14751== by 0x851ADC0: (within /tmp/src/myapp) ==14751== by 0x851834B: (within /tmp/src/myapp) ==14751== by 0x851AEB6: (within /tmp/src/myapp) If you have some idea... Regards, Vianney Lecroart |
|
From: David E. <tw...@us...> - 2004-05-26 13:22:16
|
On Wed, 2004-05-26 at 15:07, Vianney Lecroart wrote:
> Hello,
>
> I tried to use valgrind 2.1.1 (debian package and also compiled from
> sources) and I have different issue on different application.
>
> It's a unstable Debian distro, bi xeon processor 2.4GHz with 4GB
> physical RAM (and 2GB more of swap).
> Linux ater 2.6.5-grsec #18 SMP Wed May 5 22:33:22 CEST 2004 i686 unknown
Try with grsec disabled.
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
ScummVM - http://scummvm.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: David E. <tw...@us...> - 2004-05-26 17:04:01
|
Vianney, Please keep the discussion on the mailing list. On Wed, 2004-05-26 at 18:46, Vianney Lecroart wrote: > By the way, > > > I still have this error: > > valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != > ((void *)0)' failed. > ==14941== at 0xB8029FB5: vgPlain_skin_assert_fail (vg_mylibc.c:1211) > ==14941== by 0xB8029FB4: assert_fail (vg_mylibc.c:1207) > ==14941== by 0xB8029FF2: vgPlain_core_assert_fail (vg_mylibc.c:1218) > ==14941== by 0xB8026AA6: vgPlain_arena_malloc (vg_malloc2.c:535) > > > I tried on a 2 different kernel: > > Linux xxx 2.4.24 #1 SMP Mon Jan 12 15:40:56 GMT 2004 i686 unknown > > Linux xxx 2.6.5 #1 SMP Mon May 17 17:44:55 CEST 2004 i686 unknown > (without grsec) > > (same hardware, same distrib) > > Regards, > Vianney This mail contains a previous report of the same error, but not much help I'm afraid: http://sourceforge.net/mailarchive/message.php?msg_id=7851179 -- Regards, -\- David Eriksson -/- SynCE - http://synce.sourceforge.net CalcEm - http://calcem.sourceforge.net ScummVM - http://scummvm.sourceforge.net Desquirr - http://desquirr.sourceforge.net SetiWrapper - http://setiwrapper.sourceforge.net |
|
From: Nicholas N. <nj...@ca...> - 2004-05-26 17:26:52
|
On Wed, 26 May 2004, Vianney Lecroart wrote: > valgrind: vg_libpthread.c:2505 (se_remap): Assertion `res == 0' failed. That might be fixed in CVS, but I'm not sure. Or you could trying disabling grsec as David suggests. > And the second issue is on another application, it seems that valgrind > can't allocate more memory (the application uses 260MB without valgrind): > > valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != > ((void *)0)' failed. For 2.1.1, Jeremy F completely overhauled the way Valgrind lays out memory. This had various good effects, such as better separation between Valgrind and the client program, and allowing static binaries. Various people have stumbled across this one, where Valgrind aborts when the program allocates a large (but not super-large) amount of memory. It could be a bug, or it could be that the new layout is a bit rigid, I don't know. N |
|
From: Vianney L. <lec...@ne...> - 2004-05-26 17:57:30
|
>>valgrind: vg_libpthread.c:2505 (se_remap): Assertion `res == 0' failed. > > > That might be fixed in CVS, but I'm not sure. Or you could trying > disabling grsec as David suggests. I tried with the 2.6 without grsec and on a 2.4.24 kernel and the issue still occurs. I'll try tomorrow with the CVS. >>valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != >>((void *)0)' failed. > > Various people have stumbled across this one, where Valgrind aborts when > the program allocates a large (but not super-large) amount of memory. It > could be a bug, or it could be that the new layout is a bit rigid, I don't > know. I added a debug info in valgrind and the function call is void* VG_(arena_malloc) ( ArenaId aid, Int req_pszB ) with aid = 4 and req_pszB = 20 Then the funtion tries to create a new super block: new_sb = newSuperblock(a, req_bszW); with req_bszW = 17 And then the newSuperblock returns NULL. So It doesn't look like a big allocation issue. I don't know if it could help. If you have any tips or info about these 2 issues... Regards, Vianney PS: I added 2 IOCTL case that happen on my application FIOCLEX and FIONCLEX that do absolutly nothing. Just need to add a "case" and a "break" on PRE(ioctl) and POST(ioctl) functions. |