Menu
▾
▴
Re: [Valgrind-users] bug report: bugzilla refused to accept this saying it contains spam. But it doesn't.
|
From: ISHIKAWA,chiaki <ish...@yk...> - 2022-09-22 08:30:35
|
Hi,
I thought SIGFPE is a bit odd.
But now I know why.
I think valgrind experienced a division by zero.
readdwarf.c:
if (op_code >= info.li_opcode_base) {
op_code -= info.li_opcode_base;
Word adv = (op_code / info.li_line_range) <--- line 831
* info.li_min_insn_length;
Int advAddr = adv;
state_machine_regs.address += adv;
On 2022/09/22 13:39, ISHIKAWA,chiaki wrote:
> 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 (deb...@li...) (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 (deb...@li...) (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]
>
|
