Hi,
I could not post this bug report to the kde bugzilla due to the
following error message.
==========
Your comment has been automatically blocked as it is believed to contain
spam. Please contact Sysadmin if you believe this to be incorrect.
==========
Well, it does not, and the bugzilla web does not list sysadmin address.
So here it is.
I can send the full log on request.
Also, libxul.so when zipped is about 120MB.
I can send it via webtransfer or something to the interested party.
I forgot to mention, I recreated TB each day after a minor fix, and so
the change in the binary toolchain is likely the culprit.
Thank you for making the great package available to programming community.
Chiaki
=======================
valgrind 3.20GIT crashes while trying to run Thunderbird mail client.
------------------------
SUMMARY
I am trying to run thunderbird mail client (TB for short) under valgrind.
TB is created from the so-called comm-central source tree.
My local source was synced with the public source tree about a week
ago.
Well, I could run TB under valgrind on August 15.
Also, I believe I could run it about 10 days ago.
However, in the last few days, when I tried to run TB under valgrind,
valgrind crashed.
valgrind said:
00:08.54 GECKO(319869) --319873-- WARNING: Serious error when reading
debug info
00:08.54 GECKO(319869) --319873-- When reading debug info from
/NEW-SSD/moz-obj-dir/objdir-tb3/toolkit/library/build/libxul.so:
00:08.54 GECKO(319869) --319873-- Only DWARF version 2, 3, 4 and 5 line
info is currently supported.
00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x25
00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x25
00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x25
00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x1b
00:08.54 GECKO(319869) --319873-- VALGRIND INTERNAL ERROR: Valgrind
received a signal 8 (SIGFPE) - exiting
00:08.54 GECKO(319869) --319873-- si_code=1; Faulting address:
0x580C4519; sp: 0x100307c820
00:08.54 GECKO(319869) valgrind: the 'impossible' happened:
00:08.54 GECKO(319869) Killed by fatal signal
00:08.54 GECKO(319869) host stacktrace:
00:08.54 GECKO(319869) ==319873== at 0x580C4519:
read_dwarf2_lineblock (readdwarf.c:831)
00:08.54 GECKO(319869) ==319873== by 0x580C770F:
vgModuleLocal_read_debuginfo_dwarf3 (readdwarf.c:1380)
00:08.54 GECKO(319869) ==319873== by 0x58081053:
vgModuleLocal_read_elf_debug_info (readelf.c:3489)
00:08.54 GECKO(319869) ==319873== by 0x5806F0DB:
di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:969)
00:08.54 GECKO(319869) ==319873== by 0x5806F0DB:
vgPlain_di_notify_mmap (debuginfo.c:1326)
00:08.54 GECKO(319869) ==319873== by 0x5809EDBF:
vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2466)
00:08.54 GECKO(319869) ==319873== by 0x580AA5FF:
vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:413)
00:08.54 GECKO(319869) ==319873== by 0x5809B275:
vgPlain_client_syscall (syswrap-main.c:2234)
00:08.54 GECKO(319869) ==319873== by 0x58096D5A: handle_syscall
(scheduler.c:1211)
00:08.54 GECKO(319869) ==319873== by 0x58098D67: vgPlain_scheduler
(scheduler.c:1529)
00:08.54 GECKO(319869) ==319873== by 0x580E170C: thread_wrapper
(syswrap-linux.c:101)
00:08.54 GECKO(319869) ==319873== by 0x580E170C:
run_a_thread_NORETURN (syswrap-linux.c:154)
00:08.54 GECKO(319869) sched status:
00:08.54 GECKO(319869) running_tid=1
00:08.54 GECKO(319869) Thread 1: status = VgTs_Runnable syscall 9 (lwpid
319873)
00:08.54 GECKO(319869) ==319873== at 0x4020B82: __mmap64 (mmap64.c:59)
00:08.54 GECKO(319869) ==319873== by 0x4020B82: mmap (mmap64.c:47)
00:08.54 GECKO(319869) ==319873== by 0x400615B: _dl_map_segments
(dl-map-segments.h:94)
00:08.54 GECKO(319869) ==319873== by 0x400615B:
_dl_map_object_from_fd (dl-load.c:1250)
00:08.55 GECKO(319869) ==319873== by 0x40074E6: _dl_map_object
(dl-load.c:2301)
00:08.55 GECKO(319869) ==319873== by 0x400BB57: dl_open_worker_begin
(dl-open.c:533)
00:08.55 GECKO(319869) ==319873== by 0x4BFF09F: _dl_catch_exception
(dl-error-skeleton.c:208)
00:08.55 GECKO(319869) ==319873== by 0x400B325: dl_open_worker
(dl-open.c:777)
00:08.55 GECKO(319869) ==319873== by 0x4BFF09F: _dl_catch_exception
(dl-error-skeleton.c:208)
00:08.55 GECKO(319869) ==319873== by 0x400B70A: _dl_open (dl-open.c:878)
00:08.55 GECKO(319869) ==319873== by 0x4B32D77: dlopen_doit (dlopen.c:56)
00:08.55 GECKO(319869) ==319873== by 0x4BFF09F: _dl_catch_exception
(dl-error-skeleton.c:208)
00:08.55 GECKO(319869) ==319873== by 0x4BFF15E: _dl_catch_error
(dl-error-skeleton.c:227)
00:08.55 GECKO(319869) ==319873== by 0x4B32855: _dlerror_run
(dlerror.c:138)
00:08.55 GECKO(319869) ==319873== by 0x4B32E30: dlopen_implementation
(dlopen.c:71)
00:08.55 GECKO(319869) ==319873== by 0x4B32E30: dlopen@@GLIBC_2.34
(dlopen.c:81)
00:08.55 GECKO(319869) ==319873== by 0x118474: GetLibHandle(char
const*) (nsXPCOMGlue.cpp:89)
00:08.55 GECKO(319869) ==319873== by 0x1185F5: ReadDependentCB(char
const*, mozilla::LibLoadingStrategy) (nsXPCOMGlue.cpp:144)
00:08.55 GECKO(319869) ==319873== by 0x119252: XPCOMGlueLoad(char
const*, mozilla::LibLoadingStrategy) (nsXPCOMGlue.cpp:323)
00:08.55 GECKO(319869) ==319873== by 0x1193D4:
mozilla::GetBootstrap(char const*, mozilla::LibLoadingStrategy)
(nsXPCOMGlue.cpp:405)
00:08.55 GECKO(319869) ==319873== by 0x115D9B:
InitXPCOMGlue(mozilla::LibLoadingStrategy) (nsMailApp.cpp:244)
00:08.55 GECKO(319869) ==319873== by 0x11682F: main (nsMailApp.cpp:375)
00:08.55 GECKO(319869) client stack range: [0x1FFEFFA000 0x1FFF000FFF]
client SP: 0x1FFEFFB768
00:08.55 GECKO(319869) valgrind stack range: [0x1002F7E000 0x100307DFFF]
top usage: 18984 of 1048576
00:08.55 GECKO(319869) Note: see also the FAQ in the source distribution.
00:08.55 GECKO(319869) It contains workarounds to several common problems.
00:08.55 GECKO(319869) In particular, if Valgrind aborted or crashed after
00:08.55 GECKO(319869) identifying problems in your program, there's a
good chance
00:08.55 GECKO(319869) that fixing those problems will prevent Valgrind
aborting or
00:08.55 GECKO(319869) crashing, especially if it happened in
m_mallocfree.c.
00:08.55 GECKO(319869) If that doesn't help, please report this bug to:
www.valgrind.org
00:08.55 GECKO(319869) In the bug report, send all the above text, the
valgrind
00:08.55 GECKO(319869) version, and what OS and version you are using.
Thanks.
I suspect something has changed in the TB's binary toolchain in the last
10 days or so.
Valgrind version
Valgrind-3.20.0.GIT-90763ca763-20220522X and LibVEX
OS:
Linux version 5.18.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-11
(Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian)
2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)
It seems the binary toolchain for TB seemed to have generated debug
information that
valgrind could not grok (?)
I am uploading the relvant part of the log from the test run when the
fatal error occurred.
When valgrind failed, TB was created using ordinary -g flag of gcc-10.
On a hunch, I re-created TB using -gsplit-dwarf flag to gcc..
Then, with the newly created version of TB, valgrind did not crash
although it did print
"### unhandled dwarf2 ..." warnings.
So something in the debug information in the libxul.so is not quite
right when ordinary non-split dwarf information is in the object..
(I will attching the gzipped libxul if that big file is accepted.)
STEPS TO REPRODUCE
1. run valgrind to check the memory usage of thunderbird mail client
when it runs a test.
The command line is dumped in the attached log.
2. Wait for the completion of a test run.
3. valgrind crashes.
OBSERVED RESULT
00:08.54 GECKO(319869) --319873-- VALGRIND INTERNAL ERROR: Valgrind
received a signal 8 (SIGFPE) - exiting
00:08.54 GECKO(319869) --319873-- si_code=1; Faulting address:
0x580C4519; sp: 0x100307c820
00:08.54 GECKO(319869) valgrind: the 'impossible' happened:
00:08.54 GECKO(319869) Killed by fatal signal
00:08.54 GECKO(319869) host stacktrace:
EXPECTED RESULT
valgrind ought to finish the execution of TB running its test successfully.
SOFTWARE/OS VERSIONS
Debian GNU/Linux.
Linux version 5.18.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-11
(Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian)
2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)
Linux/KDE Plasma:
(available in About System) <--- not sure about this. My Debian XFCE4
desltop does not ahve "About System" anywhere.
I don't believe the GUI middleware has anything to do with the bug
reported here.
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:
ADDITIONAL INFORMATION
As I noted above, if I recompile TB using -gsplit-dwarf flag to gcc-10,
then valgrind prints warnings about
unknown dwarf2 symbol, but it runs TB running its test to its completion.
I pass "-gdwarf-4 " to gcc.
So if something is generating dwarf2 info, it is not gcc, I think.
Maybe rust compiler being used?
rustc --version
rustc 1.63.0 (4b91a6ea7 2022-08-08)
[end of memo]
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
