|
From: Alex B. <ker...@be...> - 2006-08-08 14:59:04
|
Hi,
As I'm currently debugging various test cases for our program I ran one
through valgrind and managed to fire:
--1515:0:aspacem Valgrind: FATAL: aspacem assertion failed:
--1515:0:aspacem holeEnd <= aspacem_maxAddr
--1515:0:aspacem at m_aspacemgr/aspacemgr.c:1998
(vgPlain_am_get_advisory)
--1515:0:aspacem Exiting now.
I know the usual advice is fix other problems first. However the only
other issues are warnings about invalid fd's which is known about.
Curiously if I tweak our programs config I can cause valgrind to barf
differently. The two may well be related:
--1507-- memcheck GC: 1024 nodes, 1024 survivors (100.0%)
--1507-- memcheck GC: increase table size to 2048
VEX temporary storage exhausted.
Pool = TEMP, start 0x3880aef0 curr 0x38a4e728 end 0x38a54def (size
2399999)
vex: the `impossible' happened:
VEX temporary storage exhausted.
Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
vex storage: T total 712614672 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==1507== at 0x380188E3: report_and_quit (m_libcassert.c:136)
==1507== by 0x38018BD2: panic (m_libcassert.c:210)
==1507== by 0x38018BF5: vgPlain_core_panic_at (m_libcassert.c:215)
==1507== by 0x38018C13: vgPlain_core_panic (m_libcassert.c:220)
==1507== by 0x3802C807: failure_exit (m_translate.c:487)
==1507== by 0x38075D28: vpanic (vex_util.c:225)
==1507== by 0x380762BC: private_LibVEX_alloc_OOM (vex_util.c:182)
==1507== by 0x3809B5B7: addHInstr (libvex.h:209)
==1507== by 0x3809E712: doRegisterAllocation (reg_alloc2.c:1211)
==1507== by 0x38074E35: LibVEX_Translate (vex_main.c:578)
==1507== by 0x3802CE84: vgPlain_translate (m_translate.c:1097)
==1507== by 0x38039624: handle_tt_miss (scheduler.c:693)
==1507== by 0x38039B56: vgPlain_scheduler (scheduler.c:865)
==1507== by 0x3804D47E: thread_wrapper (syswrap-linux.c:87)
==1507== by 0x3804D575: run_a_thread_NORETURN (syswrap-linux.c:120)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==1507== at 0x629C346: ???
Thread 2: status = VgTs_WaitSys
==1507== at 0x3B73EBC6B2: poll (in /lib64/tls/libc-2.3.4.so)
==1507== by 0x7010B828: MyClass::threadMain() (MyClass.cc:316)
==1507== by 0x3B74B060A9: start_thread
(in /lib64/tls/libpthread-2.3.4.so)
==1507== by 0x3B73EC53D2: clone (in /lib64/tls/libc-2.3.4.so)
==1507== by 0x3C: ???
==1507== by 0x38019D96: vgPlain_printf (m_libcprint.c:115)
==1507== by 0x3000000007: ???
==1507== by 0x403A3DE6F: ???
==1507== by 0x403A3DDAF: ???
==1507== by 0x38019BCF: send_bytes_to_logging_sink (m_libcprint.c:55)
--
Alex, homepage: http://www.bennee.com/~alex/
The world's as ugly as sin, And almost as delightful -- Frederick
Locker-Lampson
|
|
From: Julian S. <js...@ac...> - 2006-08-08 15:42:32
|
> As I'm currently debugging various test cases for our program I ran one
> through valgrind and managed to fire:
>
> --1515:0:aspacem Valgrind: FATAL: aspacem assertion failed:
> --1515:0:aspacem holeEnd <= aspacem_maxAddr
> --1515:0:aspacem at m_aspacemgr/aspacemgr.c:1998
> (vgPlain_am_get_advisory)
> --1515:0:aspacem Exiting now.
Hmm, the chances of figuring out what went wrong without a test
case are essentially zero. Are you doing some weird messing around
with mmap(...,MAP_FIXED,...) ?
> I know the usual advice is fix other problems first. However the only
> other issues are warnings about invalid fd's which is known about.
>
> Curiously if I tweak our programs config I can cause valgrind to barf
> differently. The two may well be related:
>
> --1507-- memcheck GC: 1024 nodes, 1024 survivors (100.0%)
> --1507-- memcheck GC: increase table size to 2048
> VEX temporary storage exhausted.
> Pool = TEMP, start 0x3880aef0 curr 0x38a4e728 end 0x38a54def (size
> 2399999)
>
> vex: the `impossible' happened:
> VEX temporary storage exhausted.
> Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
> vex storage: T total 712614672 bytes allocated
This could happen if V has to deal with a block of very long,
lardy, x87 code. The register allocator has run out of memory.
But it could also mean there's a problem with IR optimisation
causing the backend to generate too many insns in the first
place.
What's the chances of seeing the basic block in question?
You can get this by first running with --trace-flags=10001000
and then, when you know the BB number just before it bombed,
adding --trace-notbelow=<number>. This assumes the execution
paths are identical for both runs.
J
|