https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #26 from antoine.mo...@microej.com ---
The workaround is to remove the symbols with 0x address of the binay
with the command objcopy [-N symbolname|--strip-symbol=symbolname].
The Elf file shows different type of symbol with address
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #25 from antoine.mo...@microej.com ---
The readelf of our executable gives the following result:
155: 08053390 63 FUNC GLOBAL DEFAULT 13 VMALLOCMicroJvm__11721_11024
156: 4 OBJECT GLOBAL HIDDEN ABS
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #24 from Paul Floyd ---
> raw symbol [ 295]: GLO OBJ : svma 0x00, sz4
> _java_Lej_error_ErrorMessages_method_category_Ljava_lang_String
>
> valgrind: m_debuginfo/debuginfo.c:1731 (vgModuleLocal_find_rx_mapping):
> Assertion
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #23 from antoine.mo...@microej.com ---
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
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #22 from Paul Floyd ---
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
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #21 from antoine.mo...@microej.com ---
--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: 0x400-0x4000fff r--
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #20 from Paul Floyd ---
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
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #19 from antoine.mo...@microej.com ---
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;
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #18 from Paul Floyd ---
Can you link without --gc-sections and report back?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #17 from antoine.mo...@microej.com ---
application.out: file format elf32-i386
application.out
architecture: i386, flags 0x0112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0804a940
Program Header:
PHDR off0x0034 vaddr
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #16 from Paul Floyd ---
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?
--
You are receiving this mail because:
You are
https://bugs.kde.org/show_bug.cgi?id=304980
--- Comment #15 from antoine.mo...@microej.com ---
(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:
https://bugs.kde.org/show_bug.cgi?id=304980
Paul Floyd changed:
What|Removed |Added
CC||pjfl...@wanadoo.fr
--- Comment #14 from Paul
https://bugs.kde.org/show_bug.cgi?id=304980
antoine.mo...@microej.com changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
14 matches
Mail list logo
