bug report: bugzilla refused to accept this saying it contains spam. But it doesn't.

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 ([email protected]) (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 ([email protected]) (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
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users