NetBSD Problem Report #58691

From martin@aprisoft.de  Tue Sep 24 15:09:48 2024
Return-Path: <martin@aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id BB99B1A923B
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 24 Sep 2024 15:09:48 +0000 (UTC)
Message-Id: <20240924150939.7C9205CC795@emmas.aprisoft.de>
Date: Tue, 24 Sep 2024 17:09:39 +0200 (CEST)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: core from SIGTRAP while running under gdb
X-Send-Pr-Version: 3.95

>Number:         58691
>Category:       kern
>Synopsis:       core from SIGTRAP while running under gdb
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 24 15:10:00 +0000 2024
>Last-Modified:  Thu Sep 26 09:00:02 +0000 2024
>Originator:     Martin Husemann
>Release:        NetBSD 10.99.12
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD big-apple.aprisoft.de 10.99.12 NetBSD 10.99.12 (POWERMAC_G5.MP) #118: Mon Sep 23 20:59:21 CEST 2024 martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/macppc/compile/POWERMAC_G5.MP macppc
Architecture: powerpc
Machine: macppc
>Description:

When I try to run the palemoon browser under gdb on macppc, I get a strange
palemoon.core file:

[New process 2247]
Core was generated by `palemoon'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0  _rtld_debug_state () at /work/src/libexec/ld.elf_so/rtld.c:1593
warning: 1593   /work/src/libexec/ld.elf_so/rtld.c: No such file or directory
(gdb) bt
#0  _rtld_debug_state () at /work/src/libexec/ld.elf_so/rtld.c:1593
#1  0xfded9fa0 in dlopen (name=0xfba9b4dc "libgtk-3.so.0", mode=513) at /work/src/libexec/ld.elf_so/rtld.c:1061
#2  0xfa42d578 in glxtest () at /usr/pkgobj/www/palemoon/work/pale-moon/platform/toolkit/xre/glxtest.cpp:135
#3  0xfa42dad4 in fire_glxtest_process () at /usr/pkgobj/www/palemoon/work/pale-moon/platform/toolkit/xre/glxtest.cpp:331
#4  0xfa422f54 in XREMain::XRE_mainInit (this=this@entry=0xffffda20, aExitFlag=aExitFlag@entry=0xffffd9e7)
    at /usr/pkgobj/www/palemoon/work/pale-moon/platform/toolkit/xre/nsAppRunner.cpp:2747
#5  0xfa427b48 in XREMain::XRE_mainInit (aExitFlag=0xffffd9e7, this=0xffffda20)
    at /usr/pkgobj/www/palemoon/work/pale-moon/platform/toolkit/xre/nsAppRunner.cpp:2706
#6  XREMain::XRE_main (this=this@entry=0xffffda20, argc=argc@entry=1, argv=argv@entry=0xffffe544, 
    aAppData=aAppData@entry=0xffffdbb0) at /usr/pkgobj/www/palemoon/work/pale-moon/platform/toolkit/xre/nsAppRunner.cpp:3873
#7  0xfa427f8c in XRE_main (argc=1, argv=0xffffe544, aAppData=0xffffdbb0, aFlags=<optimized out>)
    at /usr/pkgobj/www/palemoon/work/pale-moon/platform/toolkit/xre/nsAppRunner.cpp:3975
#8  0x01803e94 in do_main (argc=<optimized out>, argc@entry=1, argv=argv@entry=0xffffe544, envp=envp@entry=0xffffe54c, 
    xreDirectory=0xf6ba4000) at /usr/pkgobj/www/palemoon/work/pale-moon/palemoon/app/nsBrowserApp.cpp:253
#9  0x0182b7dc in main (argc=1, argv=0xffffe544, envp=0xffffe54c)
    at /usr/pkgobj/www/palemoon/work/pale-moon/palemoon/app/nsBrowserApp.cpp:377

The source is:

135       void *gtk3 = dlopen("libgtk-3.so.0", RTLD_LOCAL | RTLD_LAZY);

It is not clear to me under what circumstances a SIGTRAP (as issued by
_rtld_debug_state(), trying to inform the debugger of the new shared lib
loaded) would cause a core dump while running under a debugger.

>How-To-Repeat:

just try to gdb something like firefox52 or palemoon?
What I actually did: cd to the pkgbuild work dir, there:
	cd build/dist/bin
	./run-mozilla.sh -g ./palemoon
and then at the gdb prompt:
	run

>Fix:
n/a

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/58691: core from SIGTRAP while running under gdb
Date: Thu, 26 Sep 2024 10:59:08 +0200

 Note that the core file is only generated if the parent process is traced.
 palemoon forks and has the child process run the glxtest() function.

 This sounds more like a gdb issue than a kernel problem, gdb is supposed
 to detach from that process early after fork with the default
 follow-fork-mode = parent.

 Here it doesn't seem to detach early enough but also not deal with the trap
 events.

 Martin

Home	PR Database Search