There was a visitor on #valgrind-dev on August 10, 2012: [22:51:38] <truxton> So reverting to valgrind 3.7.0 worked. I was getting an assertion with 3.8.0 : [22:51:55] <truxton> valgrind: m_debuginfo/debuginfo.c:1286 (vgModuleLocal_find_rx_mapping): Assertion 'lo <= hi' failed. [22:53:25] <truxton> my application is an enormous pile of bloat, running on 32 bit debian distro from 2007 [22:54:56] <truxton> it was compiled with icc, so maybe the debug info is different than what valgrind expects [22:55:39] <truxton> But for finding memory leaks, valgrind 3.7.0 is working. Reproducible: Always Presumably broken by changes done under Bug 296318 - Debug info improvements (sorry!). There are 6 calls to ML_(find_rx_mapping), but only one which can possibly pass 'lo' and 'hi' parameters that have not been checked to satisfy the 'lo <= hi' condition yet - the one from storage.c, ML_(addLineInfo): if (ML_(find_rx_mapping)(di, this, next - 1) == NULL) { It seems there already is some code to correct weird/invalid values, but only 'size' is sanitized to 1 in those cases, the 'next' pointer stays the same. The attached patch fixes this to: if (ML_(find_rx_mapping)(di, this, this + size - 1) == NULL) {
Created attachment 73096 [details] Proposed patch (r12843)
Do we need a test case for this? I'm unclear why this assertion only failed after the 296318 patch had been committed for some weeks -- does it have ony a very obscure path? Am happy to commit this, but I would like to understand the background a bit more first.
I have the same problem (icc 12.x, 64bit linux) which makes valgrind 3.8.0 close to useless for that purpose.
(In reply to comment #3) > I have the same problem (icc 12.x, 64bit linux) which makes valgrind 3.8.0 > close to useless for that purpose. Does the patch in comment #1 fix it for you?
Also please try running Valgrind with extra verbose output (-v -v). Knowing if there is a line like "warning: line info addresses out of order ..." just before it breaks and perhaps what kind of file are debug infos currently being read for would help to see the cause and impact better.
(In reply to comment #4) > Does the patch in comment #1 fix it for you? Yes. No problem afterwards. (ok, small testbase ;-)
(In reply to comment #5) > Also please try running Valgrind with extra verbose output (-v -v). Knowing > if there is a line like "warning: line info addresses out of order ..." just > before it breaks and perhaps what kind of file are debug infos currently > being read for would help to see the cause and impact better. I get 314 lines like --28951-- warning: line info addresses out of order at entry 0: 0xd9 0x0 The last one as a different last address/number --28951-- warning: line info addresses out of order at entry 0: 0x4e30050 0x4e30000 My "project" features an ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped which causes the error according to the debug output and a ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped Both feature also many many lines like --28951-- summarise_context(loc_start = 0x2a8): cannot summarise(why=2): 0x2a9: [0]={ 16(r6) { u u u r3 u u r6 u u u u u u u u u c-8 u u u }
OK, thanks! So ICC apparently does something where 'this' = proper line address and 'next' = section/module start. Might be added into the comment.
The existing logic is also not 64-bit clean, since it computes the difference of the two addresses into a signed 32-bit int (Int): Int size = next - this; Committed patch + fix for the above + comments + more assertions, as r12891. Jiri, can you sanity-check what I committed? I would like to push it in 3.8.1 if it looks OK. alexander.mai, any possibility you can test the trunk on your failing case(s) ?
> alexander.mai, any possibility you can test the trunk on your failing > case(s) ? I have some difficulty to retrieve (lack of svn client on the machine, etc.). If you could provide the change as a patch here or via http download elsewhere I could try.
(In reply to comment #10) > I have some difficulty to retrieve (lack of svn client on the machine, > etc.). If you could provide the change as a patch here or via http download > elsewhere I could try. I got it meanwhile. Somebody (me?) removed the original artefacts on my disk, so test is on different binaries, but built with the very same configuration. It is running fine with the new storage.c
Julian: Yes, commit looks OK -- and works too, apparently.
This issue appears with my software on a WSL Linux and on a custom embedded Linux, with the Valgrind version 3.15.0 and 3.16.1. My software is a C container for Java (microej.com) but with a simple HelloWorld. The error message is: ==2562== Memcheck, a memory error detector ==2562== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2562== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun with -h for copyright info ==2562== Command: ./application.out ==2562== --2562-- Valgrind options: --2562-- -v --2562-- Contents of /proc/version: --2562-- Linux version 5.10.102.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Mar 2 00:30:59 UTC 2022 --2562-- --2562-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3-lzcnt --2562-- Page sizes: currently 4096, max supported 4096 --2562-- Valgrind library directory: /usr/lib/x86_64-linux-gnu/valgrind --2562-- Reading syms from /usr/lib/i386-linux-gnu/ld-2.31.so --2562-- Considering /usr/lib/debug/.build-id/3a/0d80f30fd290e8212f61bade2fb8a152b0eaaa.debug .. --2562-- .. build-id is valid --2562-- Reading syms from /mnt/c/Users/amorel/workspace/workspace_Linux_Valgrind/linux-bsp/projects/microej/scripts/application.out valgrind: m_debuginfo/debuginfo.c:1726 (vgModuleLocal_find_rx_mapping): Assertion 'lo <= hi' failed. Segmentation fault
Can you try with the latest Valgrind? I made some changes to the RX mapping code in 3.19.0
(In reply to Paul Floyd from comment #14) > Can you try with the latest Valgrind? I made some changes to the RX mapping > code in 3.19.0 Thanks for feedback. I tried with the latest and it's the same: ==28900== Memcheck, a memory error detector ==28900== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==28900== Using Valgrind-3.19.0-8d3c8034b8-20220411 and LibVEX; rerun with -h for copyright info ==28900== Command: ./application.out ==28900== --28900-- Valgrind options: --28900-- -v --28900-- -v --28900-- Contents of /proc/version: --28900-- Linux version 5.10.102.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Mar 2 00:30:59 UTC 2022 --28900-- --28900-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3-lzcnt --28900-- Page sizes: currently 4096, max supported 4096 --28900-- Valgrind library directory: /usr/local/libexec/valgrind --28900-- TT/TC: VG_(init_tt_tc) (startup of code management) --28900-- TT/TC: cache: ignoring --avg-transtab-entry-size=0, using tool provided default 640 --28900-- TT/TC: cache: 32 sectors of 27,597,024 bytes each = 883,104,768 total TC --28900-- TT/TC: table: 32 tables[42588] of C 3,747,744 + H 851,760 bytes each = 147,184,128 total TT --28900-- TT/TC: table: 42588 tt entries each = 1,362,816 total tt entries --28900-- TT/TC: table: 32 htt[65521] of 131,042 bytes each = 4,193,344 total HTT (htt[65521] 65% max occup) --28900-- Reading syms from /usr/lib/i386-linux-gnu/ld-2.31.so --28900-- svma 0x0000001100, avma 0x0004001100 --28900-- Considering /usr/lib/debug/.build-id/3a/0d80f30fd290e8212f61bade2fb8a152b0eaaa.debug .. --28900-- .. build-id is valid --28900-- summarise_context(loc_start = 0x69): cannot summarise(why=1): 0x72: [0]={ 44(r3) { u u u c-36 u u c-44 c-40 c-4 u u u u u u u u u u u } --28900-- summarise_context(loc_start = 0x72): cannot summarise(why=1): 0x75: [0]={ 44(r3) { u u u c-36 u u u c-40 c-4 u u u u u u u u u u u } --28900-- summarise_context(loc_start = 0x75): cannot summarise(why=1): 0x84: [0]={ 44(r3) { u u u c-36 u u u u c-4 u u u u u u u u u u u } ==28900== Adding active redirection: --28900-- new: 0x0401e250 (index ) R-> (0000.0) 0x580c9028 ??? ==28900== Adding active redirection: --28900-- new: 0x0401e510 (strlen ) R-> (0000.0) 0x580c904d ??? --28900-- Reading syms from /mnt/c/Users/amorel/workspace/workspace_Linux_Valgrind/linux-bsp/projects/microej/scripts/application.out --28900-- svma 0x000804a8d0, avma 0x000804a8d0 valgrind: m_debuginfo/debuginfo.c:1731 (vgModuleLocal_find_rx_mapping): Assertion 'lo <= hi' failed. Segmentation fault
OK. Can you post the Program Header part of the output of 'objdump -x your_app'? Also do you know if the test application uses any fancy link editor directives?
application.out: file format elf32-i386 application.out architecture: i386, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x0804a940 Program Header: PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2 filesz 0x00000140 memsz 0x00000140 flags r-- INTERP off 0x00000174 vaddr 0x08048174 paddr 0x08048174 align 2**0 filesz 0x00000013 memsz 0x00000013 flags r-- LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x00001858 memsz 0x00001858 flags r-- LOAD off 0x00002000 vaddr 0x0804a000 paddr 0x0804a000 align 2**12 filesz 0x0006d178 memsz 0x0006d178 flags r-x LOAD off 0x0006fee0 vaddr 0x080b8ee0 paddr 0x080b8ee0 align 2**12 filesz 0x000003ac memsz 0x00016a40 flags rw- DYNAMIC off 0x0006fef0 vaddr 0x080b8ef0 paddr 0x080b8ef0 align 2**2 filesz 0x000000d8 memsz 0x000000d8 flags rw- NOTE off 0x00000188 vaddr 0x08048188 paddr 0x08048188 align 2**2 filesz 0x00000044 memsz 0x00000044 flags r-- EH_FRAME off 0x0006b7ec vaddr 0x080b37ec paddr 0x080b37ec align 2**2 filesz 0x000005ac memsz 0x000005ac flags r-- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4 filesz 0x00000000 memsz 0x00000000 flags rwx RELRO off 0x0006fee0 vaddr 0x080b8ee0 paddr 0x080b8ee0 align 2**0 filesz 0x00000120 memsz 0x00000120 flags r-- Dynamic Section: NEEDED libm.so.6 NEEDED libpthread.so.0 NEEDED libc.so.6 INIT 0x0804a000 FINI 0x0807050c GNU_HASH 0x080481cc STRTAB 0x08048aec SYMTAB 0x080481ec STRSZ 0x00000699 SYMENT 0x00000010 DEBUG 0x00000000 PLTGOT 0x080b9000 PLTRELSZ 0x00000448 PLTREL 0x00000011 JMPREL 0x08049410 REL 0x080493e8 RELSZ 0x00000028 RELENT 0x00000008 VERNEED 0x080492a8 VERNEEDNUM 0x00000003 VERSYM 0x08049186 Here is our link directive: # Link everything $CC -Wl,-Map,build/microej_gcc.map \ -Wl,--gc-sections \ -Wl,--start-group \ platform/lib/microejapp.o \ build/lib/*.a \ platform/lib/*.a \ -Wl,--end-group \ -lm -lpthread -lrt -fno-stack-protector -no-pie -D_GNU_SOURCE -ldl \ -o build/microej
Can you link without --gc-sections and report back?
it's the same: ==29450== Memcheck, a memory error detector ==29450== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==29450== Using Valgrind-3.19.0-8d3c8034b8-20220411 and LibVEX; rerun with -h for copyright info ==29450== Command: ./application.out ==29450== --29450-- Valgrind options: --29450-- -v --29450-- -v --29450-- Contents of /proc/version: --29450-- Linux version 5.10.102.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Mar 2 00:30:59 UTC 2022 --29450-- --29450-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3-lzcnt --29450-- Page sizes: currently 4096, max supported 4096 --29450-- Valgrind library directory: /usr/local/libexec/valgrind --29450-- TT/TC: VG_(init_tt_tc) (startup of code management) --29450-- TT/TC: cache: ignoring --avg-transtab-entry-size=0, using tool provided default 640 --29450-- TT/TC: cache: 32 sectors of 27,597,024 bytes each = 883,104,768 total TC --29450-- TT/TC: table: 32 tables[42588] of C 3,747,744 + H 851,760 bytes each = 147,184,128 total TT --29450-- TT/TC: table: 42588 tt entries each = 1,362,816 total tt entries --29450-- TT/TC: table: 32 htt[65521] of 131,042 bytes each = 4,193,344 total HTT (htt[65521] 65% max occup) --29450-- Reading syms from /usr/lib/i386-linux-gnu/ld-2.31.so --29450-- svma 0x0000001100, avma 0x0004001100 --29450-- Considering /usr/lib/debug/.build-id/3a/0d80f30fd290e8212f61bade2fb8a152b0eaaa.debug .. --29450-- .. build-id is valid --29450-- summarise_context(loc_start = 0x69): cannot summarise(why=1): 0x72: [0]={ 44(r3) { u u u c-36 u u c-44 c-40 c-4 u u u u u u u u u u u } --29450-- summarise_context(loc_start = 0x72): cannot summarise(why=1): 0x75: [0]={ 44(r3) { u u u c-36 u u u c-40 c-4 u u u u u u u u u u u } --29450-- summarise_context(loc_start = 0x75): cannot summarise(why=1): 0x84: [0]={ 44(r3) { u u u c-36 u u u u c-4 u u u u u u u u u u u } ==29450== Adding active redirection: --29450-- new: 0x0401e250 (index ) R-> (0000.0) 0x580c9028 ??? ==29450== Adding active redirection: --29450-- new: 0x0401e510 (strlen ) R-> (0000.0) 0x580c904d ??? --29450-- Reading syms from /mnt/c/Users/amorel/workspace/workspace_Linux_Valgrind/HelloWorld/com.mycompany.Main/application.out --29450-- svma 0x00080494e0, avma 0x00080494e0 valgrind: m_debuginfo/debuginfo.c:1731 (vgModuleLocal_find_rx_mapping): Assertion 'lo <= hi' failed. Segmentation fault application.out: file format elf32-i386 application.out architecture: i386, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x08049540 Program Header: PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2 filesz 0x00000140 memsz 0x00000140 flags r-- INTERP off 0x00000174 vaddr 0x08048174 paddr 0x08048174 align 2**0 filesz 0x00000013 memsz 0x00000013 flags r-- LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x00000ec8 memsz 0x00000ec8 flags r-- LOAD off 0x00001000 vaddr 0x08049000 paddr 0x08049000 align 2**12 filesz 0x0002db18 memsz 0x0002db18 flags r-x LOAD off 0x0002ef08 vaddr 0x08077f08 paddr 0x08077f08 align 2**12 filesz 0x00000234 memsz 0x00013bf8 flags rw- DYNAMIC off 0x0002ef18 vaddr 0x08077f18 paddr 0x08077f18 align 2**2 filesz 0x000000d8 memsz 0x000000d8 flags rw- NOTE off 0x00000188 vaddr 0x08048188 paddr 0x08048188 align 2**2 filesz 0x00000044 memsz 0x00000044 flags r-- EH_FRAME off 0x0002de08 vaddr 0x08075e08 paddr 0x08075e08 align 2**2 filesz 0x000001ec memsz 0x000001ec flags r-- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4 filesz 0x00000000 memsz 0x00000000 flags rwx RELRO off 0x0002ef08 vaddr 0x08077f08 paddr 0x08077f08 align 2**0 filesz 0x000000f8 memsz 0x000000f8 flags r-- Dynamic Section: NEEDED libm.so.6 NEEDED libpthread.so.0 NEEDED libc.so.6 INIT 0x08049000 FINI 0x0806efdc GNU_HASH 0x080481cc STRTAB 0x080486dc SYMTAB 0x080481ec STRSZ 0x00000404 SYMENT 0x00000010 DEBUG 0x00000000 PLTGOT 0x08078000 PLTRELSZ 0x00000250 PLTREL 0x00000011 JMPREL 0x08048c78 REL 0x08048c60 RELSZ 0x00000018 RELENT 0x00000008 VERNEED 0x08048b80 VERNEEDNUM 0x00000003 VERSYM 0x08048ae0
In that case it's probably the map file. I had a quick look at an x86 binary and it had 4 LOAD sections whilst yours has only 3. Can you run Valgrind with -d -d -d. The output will be very long. Can you report back with the lines containing di_notify_mmap?
--121:1:mallocfr newSuperblock at 0x82857000 (pszB 1048560) owner VALGRIND/dinfo --121:1: main Load initial debug info --121-- di_notify_mmap-0: --121-- di_notify_mmap-1: 0x4000000-0x4000fff r-- --121-- di_notify_mmap-2: /usr/lib/i386-linux-gnu/ld-2.31.so --121-- di_notify_mmap-3: is_rx_map 0, is_rw_map 0, is_ro_map 1 --121-- di_notify_mmap-4: noting details in DebugInfo* at 0x828571E0 --121-- di_notify_mmap-6: no dinfo loaded /usr/lib/i386-linux-gnu/ld-2.31.so (no rx or no rw mapping) --121-- di_notify_mmap-0: --121-- di_notify_mmap-1: 0x4001000-0x401efff r-x --121-- di_notify_mmap-2: /usr/lib/i386-linux-gnu/ld-2.31.so --121-- di_notify_mmap-3: is_rx_map 1, is_rw_map 0, is_ro_map 0 --121-- di_notify_mmap-4: noting details in DebugInfo* at 0x828571E0 --121-- di_notify_mmap-6: no dinfo loaded /usr/lib/i386-linux-gnu/ld-2.31.so (no rx or no rw mapping) --121-- di_notify_mmap-0: --121-- di_notify_mmap-1: 0x401f000-0x4029fff r-- --121-- di_notify_mmap-2: /usr/lib/i386-linux-gnu/ld-2.31.so --121-- di_notify_mmap-3: is_rx_map 0, is_rw_map 0, is_ro_map 1 --121-- di_notify_mmap-4: noting details in DebugInfo* at 0x828571E0 --121-- di_notify_mmap-6: no dinfo loaded /usr/lib/i386-linux-gnu/ld-2.31.so (no rx or no rw mapping) --121-- di_notify_mmap-0: --121-- di_notify_mmap-1: 0x402b000-0x402cfff rw- --121-- di_notify_mmap-2: /usr/lib/i386-linux-gnu/ld-2.31.so --121-- di_notify_mmap-3: is_rx_map 0, is_rw_map 1, is_ro_map 0 --121-- di_notify_mmap-4: noting details in DebugInfo* at 0x828571E0 --121-- di_notify_mmap-5: achieved accept state for /usr/lib/i386-linux-gnu/ld-2.31.so --121-- Reading syms from /usr/lib/i386-linux-gnu/ld-2.31.so --121-- svma 0x0000001100, avma 0x0004001100 --121-- Considering /usr/lib/debug/.build-id/3a/0d80f30fd290e8212f61bade2fb8a152b0eaaa.debug .. --121-- .. build-id is valid --121-- summarise_context(loc_start = 0x69): cannot summarise(why=1): 0x72: [0]={ 44(r3) { u u u c-36 u u c-44 c-40 c-4 u u u u u u u u u u u } --121-- summarise_context(loc_start = 0x72): cannot summarise(why=1): 0x75: [0]={ 44(r3) { u u u c-36 u u u c-40 c-4 u u u u u u u u u u u } --121-- summarise_context(loc_start = 0x75): cannot summarise(why=1): 0x84: [0]={ 44(r3) { u u u c-36 u u u u c-4 u u u u u u u u u u u } --121:1:mallocfr newSuperblock at 0x82957000 (pszB 1048560) owner VALGRIND/dinfo --121:1:mallocfr newSuperblock at 0x82A57000 (pszB 1048560) owner VALGRIND/dinfo --121:1:hashtabl resizing table `di.storage.addStr.1' from 769 to 1543 (total elems 770) --121-- cfsi range rx-mappings coverage check: Covered 0x0-0xffffffff --121:1:mallocfr newSuperblock at 0x82B57000 (pszB 65520) owner VALGRIND/demangle --121:2:transtab discard_translations(0x401e250, 1) req by redir_new_DebugInfo(from_addr) --121:2:transtab FAST, ec = 15 --121:2:transtab discard_translations(0x580c9028, 1) req by redir_new_DebugInfo(to_addr) --121:2:transtab FAST, ec = 100 ==121== Adding active redirection: --121-- new: 0x0401e250 (index ) R-> (0000.0) 0x580c9028 ??? --121:2:transtab discard_translations(0x401e510, 1) req by redir_new_DebugInfo(from_addr) --121:2:transtab FAST, ec = 15 --121:2:transtab discard_translations(0x580c904d, 1) req by redir_new_DebugInfo(to_addr) --121:2:transtab FAST, ec = 100 ==121== Adding active redirection: --121-- new: 0x0401e510 (strlen ) R-> (0000.0) 0x580c904d ??? --121-- di_notify_mmap-0: --121-- di_notify_mmap-1: 0x8048000-0x8048fff r-- --121-- di_notify_mmap-2: /mnt/c/Users/amorel/workspace/workspace_Linux_Valgrind/HelloWorld/com.mycompany.Main/application.out --121-- di_notify_mmap-3: is_rx_map 0, is_rw_map 0, is_ro_map 1 --121-- di_notify_mmap-4: noting details in DebugInfo* at 0x82865030 --121-- di_notify_mmap-6: no dinfo loaded /mnt/c/Users/amorel/workspace/workspace_Linux_Valgrind/HelloWorld/com.mycompany.Main/application.out (no rx or no rw mapping) --121-- di_notify_mmap-0: --121-- di_notify_mmap-1: 0x8049000-0x8076fff r-x --121-- di_notify_mmap-2: /mnt/c/Users/amorel/workspace/workspace_Linux_Valgrind/HelloWorld/com.mycompany.Main/application.out --121-- di_notify_mmap-3: is_rx_map 1, is_rw_map 0, is_ro_map 0 --121-- di_notify_mmap-4: noting details in DebugInfo* at 0x82865030 --121-- di_notify_mmap-6: no dinfo loaded /mnt/c/Users/amorel/workspace/workspace_Linux_Valgrind/HelloWorld/com.mycompany.Main/application.out (no rx or no rw mapping) --121-- di_notify_mmap-0: --121-- di_notify_mmap-1: 0x8077000-0x8078fff rw- --121-- di_notify_mmap-2: /mnt/c/Users/amorel/workspace/workspace_Linux_Valgrind/HelloWorld/com.mycompany.Main/application.out --121-- di_notify_mmap-3: is_rx_map 0, is_rw_map 1, is_ro_map 0 --121-- di_notify_mmap-4: noting details in DebugInfo* at 0x82865030 --121-- di_notify_mmap-5: achieved accept state for /mnt/c/Users/amorel/workspace/workspace_Linux_Valgrind/HelloWorld/com.mycompany.Main/application.out --121-- Reading syms from /mnt/c/Users/amorel/workspace/workspace_Linux_Valgrind/HelloWorld/com.mycompany.Main/application.out --121-- svma 0x00080494e0, avma 0x00080494e0
The last trace is from "Bool ML_(read_elf_debug_info) ( struct _DebugInfo* di )" I see 6 call sites for the asserting function, ML_(find_rx_mapping)(). search_all_symtabs() and ML_(addDiCfSI)() use the same address for min and max so they can't be the problem. ML_(addVar)() is protected by a prior assert so it can't be that. ML_(addLineInfo) could be bad if size is 0 or wraps around, but there are asserts checking that size >=1 and <= MAX_LOC_SIZE which is only 2^12 - 1 get_elf_symbol_info could be bad if "*sym_size_out" is 0 or negative (or wraps?). It can't be negative as there is a test for this which clamps the size to 1. There's also a test for zero size which returns false. That just leaves wrapping. And I can't see how that could happen either. Could you please run with --trace-symtab=yes and post the output? Probably just the last few traces before the assert should be enough.
Thank you for the analysis. Log with --trace-symtab=yes: rec(d) [ 262]: val 0x000807025c, sz 16 _java_Ljava_lang_ref_ReferenceQueue_nameinfo raw symbol [ 263]: GLO FUN : svma 0x000805e200, sz 537 VMCOREMicroJvm__1211___dumpVM rec(t) [ 263]: val 0x000805e200, sz 537 VMCOREMicroJvm__1211___dumpVM raw symbol [ 264]: GLO FUN : svma 0x00080623f0, sz 50 com_is2t_microjvm_mowana_MowanaVMEngineIcetea___OPif_1icmple_1short rec(t) [ 264]: val 0x00080623f0, sz 50 com_is2t_microjvm_mowana_MowanaVMEngineIcetea___OPif_1icmple_1short raw symbol [ 265]: GLO NOT : svma 0x00080732d8, sz 0 LLNET_DNS_IP_ADDRESS raw symbol [ 266]: GLO OBJ : svma 0x000806ff64, sz 8 _java_Lcom_is2t_vm_support_util_EncUTF_18_htable rec(d) [ 266]: val 0x000806ff64, sz 8 _java_Lcom_is2t_vm_support_util_EncUTF_18_htable raw symbol [ 267]: GLO OBJ : svma 0x0008073f88, sz 20 MicroJvm_ILS_7__iceTea__initialStringArray rec(d) [ 267]: val 0x0008073f88, sz 20 MicroJvm_ILS_7__iceTea__initialStringArray raw symbol [ 268]: GLO FUN : svma 0x000805baf0, sz 25 VMCOREMicroJvm__1163____1_1966 rec(t) [ 268]: val 0x000805baf0, sz 25 VMCOREMicroJvm__1163____1_1966 raw symbol [ 269]: GLO FUN : svma 0x000806e050, sz 210 iceTea_lang_String___concat rec(t) [ 269]: val 0x000806e050, sz 210 iceTea_lang_String___concat raw symbol [ 270]: GLO FUN : svma 0x0008055110, sz 221 VMALLOCMicroJvm__124____1_135 rec(t) [ 270]: val 0x0008055110, sz 221 VMALLOCMicroJvm__124____1_135 raw symbol [ 271]: GLO FUN : svma 0x00080621b0, sz 42 com_is2t_microjvm_mowana_MowanaVMEngineIcetea___OPifeq_1const rec(t) [ 271]: val 0x00080621b0, sz 42 com_is2t_microjvm_mowana_MowanaVMEngineIcetea___OPifeq_1const raw symbol [ 272]: GLO FUN : svma 0x0008064900, sz 117 com_is2t_microjvm_mowana_MowanaVMEngineIcetea___OPgetfield_1ref rec(t) [ 272]: val 0x0008064900, sz 117 com_is2t_microjvm_mowana_MowanaVMEngineIcetea___OPgetfield_1ref raw symbol [ 273]: GLO OBJ : svma 0x0008078a9c, sz 0 __icetea___6bss_6soar_6BT4$$Limit ignore -- size=0: __icetea___6bss_6soar_6BT4$$Limit raw symbol [ 274]: GLO OBJ : svma 0x0000000001, sz 4 _java_Ljava_io_PrintStream_methodoffset_print_Ljava_lang_String_V ignore -- 0x1 .. 0x4 outside .text svma range 0x80494e0 .. 0x806efd8 raw symbol [ 275]: GLO FUN : svma 0x000804d930, sz 41 ist_microjvm_NativesPool___java_1lang_1Math_1rint rec(t) [ 275]: val 0x000804d930, sz 41 ist_microjvm_NativesPool___java_1lang_1Math_1rint raw symbol [ 276]: WEA FUN : svma 0x0008069810, sz 6 LLEXT_RES_seek rec(t) [ 276]: val 0x0008069810, sz 6 LLEXT_RES_seek raw symbol [ 277]: GLO OBJ : svma 0x0000000006, sz 4 _java_Ljava_io_OutputStream_methodoffset_flush_V ignore -- 0x6 .. 0x9 outside .text svma range 0x80494e0 .. 0x806efd8 raw symbol [ 278]: GLO FUN : svma 0x000806e5d0, sz 30 iceTea_lang_SystemOut___println__I rec(t) [ 278]: val 0x000806e5d0, sz 30 iceTea_lang_SystemOut___println__I raw symbol [ 279]: GLO FUN : svma 0x000805c6a0, sz 26 VMCOREMicroJvm__1170____4init_5 rec(t) [ 279]: val 0x000805c6a0, sz 26 VMCOREMicroJvm__1170____4init_5 raw symbol [ 280]: GLO FUN : svma 0x000806e9d0, sz 38 SNI_resumeJavaThreadWithArg rec(t) [ 280]: val 0x000806e9d0, sz 38 SNI_resumeJavaThreadWithArg raw symbol [ 281]: GLO FUN : svma 0x000804a240, sz 50 posix_timer_dispose rec(t) [ 281]: val 0x000804a240, sz 50 posix_timer_dispose raw symbol [ 282]: GLO OBJ : svma 0x0008072394, sz 19 _java_Ljava_lang_Object_method_hashCode_I rec(d) [ 282]: val 0x0008072394, sz 19 _java_Ljava_lang_Object_method_hashCode_I raw symbol [ 283]: GLO FUN : svma 0x000806d8f0, sz 86 iceTea_lang_String___substring__I rec(t) [ 283]: val 0x000806d8f0, sz 86 iceTea_lang_String___substring__I raw symbol [ 284]: GLO FUN : svma 0x000805dc70, sz 398 VMCOREMicroJvm__1210____1_1316 rec(t) [ 284]: val 0x000805dc70, sz 398 VMCOREMicroJvm__1210____1_1316 raw symbol [ 285]: GLO OBJ : svma 0x000806fdac, sz 4 _java_Lcom_is2t_tools_ToolsErrorMessage_htable rec(d) [ 285]: val 0x000806fdac, sz 4 _java_Lcom_is2t_tools_ToolsErrorMessage_htable raw symbol [ 286]: GLO OBJ : svma 0x000806ff74, sz 20 _java_soarfile_header_start rec(d) [ 286]: val 0x000806ff74, sz 20 _java_soarfile_header_start raw symbol [ 287]: GLO NOT : svma 0x0008073314, sz 0 MJVM_MONITOR_on_gc_start_ptr raw symbol [ 288]: GLO OBJ : svma 0x0008071ccc, sz 31 _java_Ljava_lang_AbstractStringBuilder_method_toString_Ljava_lang_String rec(d) [ 288]: val 0x0008071ccc, sz 31 _java_Ljava_lang_AbstractStringBuilder_method_toString_Ljava_lang_String raw symbol [ 289]: GLO FUN : svma 0x000805ba30, sz 5 VMCOREMicroJvm__1163____1_1978 rec(t) [ 289]: val 0x000805ba30, sz 5 VMCOREMicroJvm__1163____1_1978 raw symbol [ 290]: GLO OBJ : svma 0x000806ff08, sz 16 _java_Lej_sni_NativeIOException_htable rec(d) [ 290]: val 0x000806ff08, sz 16 _java_Lej_sni_NativeIOException_htable raw symbol [ 291]: GLO FUN : svma 0x0008059ea0, sz 18 VMCOREMicroJvm__1136____1_1447 rec(t) [ 291]: val 0x0008059ea0, sz 18 VMCOREMicroJvm__1136____1_1447 raw symbol [ 292]: GLO FUN : svma 0x00080527f0, sz 123 VMALLOCMicroJvm__1123____1_1698 rec(t) [ 292]: val 0x00080527f0, sz 123 VMALLOCMicroJvm__1123____1_1698 raw symbol [ 293]: GLO FUN : svma 0x0008054230, sz 32 VMALLOCMicroJvm__1173____4init_5__LVMALLOCMicroJvm__1172_2 rec(t) [ 293]: val 0x0008054230, sz 32 VMALLOCMicroJvm__1173____4init_5__LVMALLOCMicroJvm__1172_2 raw symbol [ 294]: GLO FUN : svma 0x0008053390, sz 63 VMALLOCMicroJvm__1172____1_11024 rec(t) [ 294]: val 0x0008053390, sz 63 VMALLOCMicroJvm__1172____1_11024 raw symbol [ 295]: GLO OBJ : svma 0x00ffffffff, sz 4 _java_Lej_error_ErrorMessages_method_category_Ljava_lang_String valgrind: m_debuginfo/debuginfo.c:1731 (vgModuleLocal_find_rx_mapping): Assertion 'lo <= hi' failed. Segmentation fault
> raw symbol [ 295]: GLO OBJ : svma 0x00ffffffff, sz 4 > _java_Lej_error_ErrorMessages_method_category_Ljava_lang_String > > valgrind: m_debuginfo/debuginfo.c:1731 (vgModuleLocal_find_rx_mapping): > Assertion 'lo <= hi' failed. > Segmentation fault That address 0x00ffffff looks very strange. Mark, do you have any idea what might cause that?
The readelf of our executable gives the following result: 155: 08053390 63 FUNC GLOBAL DEFAULT 13 VMALLOCMicroJvm__1172____1_11024 156: ffffffff 4 OBJECT GLOBAL HIDDEN ABS _java_Lej_error_ErrorMessages_method_category_Ljava_lang_String 157: 08072338 9 OBJECT GLOBAL HIDDEN 15 _java_Lcom_is2t_vm_support_util_EncUTF_18_method_getMaxBytesPerChar_I We investigate internally why the address is at 0xffffffff. By stripping all the symbol (strip -s application.out), we haven't got the segmentation fault. I'll keep you inform.
The workaround is to remove the symbols with 0xffffffff address of the binay with the command objcopy [-N symbolname|--strip-symbol=symbolname]. The Elf file shows different type of symbol with address at 0xffffffff: ffffffff 4 OBJECT GLOBAL HIDDEN ABS ffffffff 0 NOTYPE GLOBAL DEFAULT ABS Valgrind crashes only with the symbol with "OBJECT" type. It works with "NOTYPE" type. Do you know why?