| Summary: | Assertion 'lo <= hi' failed in vgModuleLocal_find_rx_mapping (debuginfo.c) | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Jiří Hruška <jirka> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | alexander.mai, antoine.morel, pjfloyd |
| Priority: | NOR | ||
| Version First Reported In: | 3.8.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Proposed patch (r12843) | ||
|
Description
Jiří Hruška
2012-08-11 13:30:02 UTC
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? |