From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 539CD3858C62; Wed, 15 Feb 2023 11:24:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 539CD3858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676460267; bh=76A1ghKgMacXsgQYYSDcHxN+DJ/mGM1rv7zrfA7map4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HSX6Ez9yWLKctyMKq/QYFEOAEyokMeIyADoiM+CgYyhessNrnsdMV0aPM3/Dio2vr NRIamWbVyVoigNqXesu7MAyH9D+76fB0ahiJFnEG7V1gPUWuJw8RsCsrZ1cMzeuYiH qog1fALl/xb2JPRNOm6dL7PMx3EBecnZMALTNK1g= From: "mariappan.balraj at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug go/30038] When using CGO and C code is calling GO function, not getting call stack of C from core dump. Only getting call stack of GO. Date: Wed, 15 Feb 2023 11:24:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: go X-Bugzilla-Version: 12.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: mariappan.balraj at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30038 --- Comment #11 from mariappan balraj -= -- Hi, I am seeing some difference between what BT you are getting in and what I am getting. In your case, libgo.so got used. But in my case it is not. I am trying to understand what makes this difference. Could you please share the following information? This will help me to progress further. 1) GO version 2) Build steps? 3) output of go env command 4) Output of "go version -m " #8 0x00007fcf85b2ae84 in runtime[dieFromSignal] () from /lib64/libgo.so.21 #9 0x00007fcf85b2aeee in runtime[crash] () from /lib64/libgo.so.21 #10 0x00007fcf85b5e405 in runtime[gopanic] () from /lib64/libgo.so.21 #8 0x00000000004411e5 in runtime.dieFromSignal (sig=3D6) at /usr/lib/go-1.18/src/runtime/signal_unix.go:852 #9 0x000000000042dca9 in runtime.crash () at /usr/lib/go-1.18/src/runtime/signal_unix.go:944 #10 runtime.fatalpanic (msgs=3D) at /usr/lib/go-1.18/src/runtime/panic.go:1092 #11 0x000000000042d477 in runtime.gopanic (e=3D...) at /usr/lib/go-1.18/src/runtime/panic.go:941 Best Regards Mariappan On Wed, Feb 15, 2023 at 11:24 AM mariappan balraj < mariappan.balraj@gmail.com> wrote: > Hi, > > I am seeing the same behaviour even in red hat linux. It is good if you > can share your go environment and the steps you are following to build it. > So that I can try. If that solves the issue then it is really nice. Kindly > please help. > > Best Regards > Mariappan > > On Tue, Feb 14, 2023 at 11:09 PM tromey at sourceware dot org < > sourceware-bugzilla@sourceware.org> wrote: > >> https://sourceware.org/bugzilla/show_bug.cgi?id=3D30038 >> >> --- Comment #9 from Tom Tromey --- >> Sorry, I can't check on Ubuntu for you. >> I think you will have to look more deeply into it yourself somehow. >> Normally a core file shouldn't affect the backtrace. >> So I suspect something is weird in your environment, like >> maybe you compiled something with optimization or LTO or the like. >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. >> You reported the bug. > > --=20 You are receiving this mail because: You are on the CC list for the bug.=