Re: [go-nuts] Need help: Calling panic() is corrupting system stack
Hi Ian,
You are correct. The following test case is failing. I commented out the
code to make sure whether my analysis is correct or not. Definitely, you
people are experts. What could be the best fix for this issue? If you can
help then that is really helpful.
=== RUN TestCallbackPanicLoop
signal: segmentation fault
FAILmisc/cgo/test 0.671s
Best Regards
Mariappan
On Thu, Apr 6, 2023 at 2:22 AM Ian Lance Taylor wrote:
> On Tue, Apr 4, 2023 at 9:20 PM mariappan balraj
> wrote:
> >
> > In my test case, I have tried, Go-->C-->Go->panic() only.
>
> You can run a bunch of cgo tests by running "go test" in the directory
> $GOROOT/misc/cgo/test.
>
> Ian
>
>
> > On Wed, Apr 5, 2023 at 3:35 AM Ian Lance Taylor wrote:
> >>
> >> On Mon, Apr 3, 2023 at 9:26 PM mariappan balraj
> >> wrote:
> >> >
> >> > Hi Kurtis Rader,
> >> >
> >> > Thanks for your response. I am working on it. I will quickly share
> it. Before that one more update. I have commented the below two lines. Now
> from the core, I am able to see the correct stack trace.
> >> >
> >> > 326 func unwindm(restore *bool) {
> >> > 327 if *restore {
> >> > 328 // Restore sp saved by cgocallback during
> >> > 329 // unwind of g's stack (see comment at top of
> file).
> >> > 330 mp := acquirem()
> >> > 331 //sched :=
> >> > 332 //sched.sp = *(*uintptr)(unsafe.Pointer(sched.sp
> + alignUp(sys.MinFrameSize, sys.StackAlign)))
> >> > 333
> >> > 334 // Do the accounting that cgocall will not have a
> chance to do
> >> > 335 // during an unwind.
> >> > 336 //
> >> > 337 // In the case where a Go call originates from C,
> ncgo is 0
> >> > 338 // and there is no matching cgocall to end.
> >> > 339 if mp.ncgo > 0 {
> >> > 340 mp.incgo = false
> >> > 341 mp.ncgo--
> >> > 342 osPreemptExtExit(mp)
> >> > 343 }
> >> > 344
> >> > 345 releasem(mp)
> >> > 346 }
> >> > 347 }
> >>
> >>
> >>
> >> Just a note that in general we can't make that change, as it will
> >> break the case where a Go function calls a C function calls a Go
> >> function and that Go function calls panic.
> >>
> >> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAKKWi6SkVFB1V9af_BDeX8hEMg_hxnYxdkYvmW9HCufpms7Y5A%40mail.gmail.com.
Re: [go-nuts] Need help: Calling panic() is corrupting system stack
Hi Ian,
In my test case, I have tried, Go-->C-->Go->panic() only.
On Wed, Apr 5, 2023 at 3:35 AM Ian Lance Taylor wrote:
> On Mon, Apr 3, 2023 at 9:26 PM mariappan balraj
> wrote:
> >
> > Hi Kurtis Rader,
> >
> > Thanks for your response. I am working on it. I will quickly share it.
> Before that one more update. I have commented the below two lines. Now from
> the core, I am able to see the correct stack trace.
> >
> > 326 func unwindm(restore *bool) {
> > 327 if *restore {
> > 328 // Restore sp saved by cgocallback during
> > 329 // unwind of g's stack (see comment at top of file).
> > 330 mp := acquirem()
> > 331 //sched :=
> > 332 //sched.sp = *(*uintptr)(unsafe.Pointer(sched.sp +
> alignUp(sys.MinFrameSize, sys.StackAlign)))
> > 333
> > 334 // Do the accounting that cgocall will not have a
> chance to do
> > 335 // during an unwind.
> > 336 //
> > 337 // In the case where a Go call originates from C,
> ncgo is 0
> > 338 // and there is no matching cgocall to end.
> > 339 if mp.ncgo > 0 {
> > 340 mp.incgo = false
> > 341 mp.ncgo--
> > 342 osPreemptExtExit(mp)
> > 343 }
> > 344
> > 345 releasem(mp)
> > 346 }
> > 347 }
>
>
>
> Just a note that in general we can't make that change, as it will
> break the case where a Go function calls a C function calls a Go
> function and that Go function calls panic.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAKKWi6Q6A1nF8u2whHEL%3DMJprzakdB15DB%3DfApbswe7ZNEX%3DhA%40mail.gmail.com.
Re: [go-nuts] Need help: Calling panic() is corrupting system stack
Sorry. Forgot to share go environment. root@soomohan:/home/soomohan/mbalraj/test_hb2# go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/root/.cache/go-build" GOENV="/root/.config/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/root/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/root/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct; GOROOT="/home/soomohan/mbalraj/GO/go1.20.2/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/soomohan/mbalraj/GO/go1.20.2/go/pkg/tool/linux_amd64" GOVCS="" GOVERSION="go1.20.2" GCCGO="/usr/bin/gccgo" GOAMD64="v1" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/dev/null" GOWORK="" CGO_CFLAGS="-O2 -g" CGO_CPPFLAGS="" CGO_CXXFLAGS="-O2 -g" CGO_FFLAGS="-O2 -g" CGO_LDFLAGS="-O2 -g" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3821222181=/tmp/go-build -gno-record-gcc" On Wed, Apr 5, 2023 at 8:49 AM Kurtis Rader wrote: > On Tue, Apr 4, 2023 at 3:30 PM robert engels > wrote: > >> Unfortunately, I am on OSX - and Go doesn’t appear to generate a core >> dump on panic despite the GOTRACEBACK setting. >> >> That being said, the stack-traces look ok to me. See attached. >> > > Since I also use macOS (aka "OS X") I investigated why core dumps are not > generated. The answer can be found in > https://github.com/golang/go/issues/59446 that I just opened. The short > answer is that on macOS on amd64 core dumps from Go programs are explicitly > disallowed. On macOS on arm64 they should occur but generating them > requires a code-signed Go binary. Something I don't have enough interest to > verify. Also, presumably the same issue that affects Go core dumps on macOS > amd64 also applies to macOS arm64. So even if you go to the trouble of > code-signing a Go binary generating a core dump would not be practical on > Apple Silicon. > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKKWi6STgM3Dus5%3DCVqV%2B57ryePJ2iaX4kAYt7qq3zABJjygqg%40mail.gmail.com.
Re: [go-nuts] Need help: Calling panic() is corrupting system stack
Hi Robert,
I have published the test case on github. Please find the links. Please let
me know if you need any information. I am ready to provide and support.
https://github.com/MariappanBalraj/test_cgo_panic
https://github.com/MariappanBalraj/test_cgo_panic.git
https://github.com/MariappanBalraj/test_cgo_panic/archive/refs/heads/main.zip
Best Regards
Mariappan
On Mon, Apr 3, 2023 at 9:50 AM Robert Engels wrote:
> I would start by publishing a small reproducible test case on github that
> fully compiles that demonstrates the issue.
>
> On Apr 2, 2023, at 10:59 PM, mariappan balraj
> wrote:
>
>
> Hello Go Experts,
>
> It is good if someone can help on this?
>
> Best Regards
> Mariappan
> On Sat, Apr 1, 2023 at 7:45 AM mariappan balraj <
> mariappan.bal...@gmail.com> wrote:
>
>> Hello Go experts,
>>
>> Could someone please help to resolve this issue?
>>
>> Best Regards
>> Mariappan
>>
>> On Thu, Mar 30, 2023 at 2:52 PM mariappan balraj <
>> mariappan.bal...@gmail.com> wrote:
>>
>>> Hello Go Experts,
>>>
>>> When panic() is called from Go function, in the below call sequence,
>>> runtime.unwindm() [which is defer function of runtime.cgocallbackg1] is
>>> called. This function is unwinding the system stack. Later, as part of the
>>> function addOneOpenDeferFrame(), systemstack() is called to run a function
>>> in the system stack. This will use the stack which is allocated for C
>>> function calls. This makes stack unwinding impossible in case of panic() is
>>> called. Can someone please help me to fix this issue?
>>>
>>> (dlv) bt
>>> 0 0x004054e6 in runtime.unwindm
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:326
>>> 1 0x00405446 in runtime.cgocallbackg1.func3
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:304
>>> 2 0x004340c8 in runtime.deferCallSave
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:796
>>> 3 0x00433fa5 in runtime.runOpenDeferFrame
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:769
>>> 4 0x00434332 in runtime.gopanic
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:884
>>> 5 0x004642a7 in main.Test4
>>> at ./export.go:7
>>> at ./export.go:7
>>> 6 0x0046431c in _cgoexp_78b81bbf688e_Test4
>>> at _cgo_gotypes.go:61
>>> 7 0x0040535b in runtime.cgocallbackg1
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:315
>>> 8 0x00405079 in runtime.cgocallbackg
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:234
>>> 9 0x00461b0f in runtime.cgocallbackg
>>> at :1
>>> 10 0x0045f3f4 in runtime.cgocallback
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:998
>>> 11 0x004641bd in crosscall2
>>> at
>>> /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgo/asm_amd64.s:30
>>> 12 0x00464386 in C.Test4
>>> at /tmp/go-build/_cgo_export.c:33
>>> 13 0x00464432 in C.test1
>>> at ./hello.go:9
>>> 14 0x0046444d in C.test2
>>> at ./hello.go:14
>>> 15 0x00464468 in C.test3
>>> 15 0x00464468 in C.test3
>>> at ./hello.go:19
>>> 16 0x004644a7 in C._cgo_78b81bbf688e_Cfunc_test3
>>> at /tmp/go-build/cgo-gcc-prolog:49
>>> 17 0x0045f2e4 in runtime.asmcgocall
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:848
>>> 18 0x0046448a in C._cgo_78b81bbf688e_Cfunc_test3
>>> at /tmp/go-build/cgo-gcc-prolog:44
>>> 19 0x00404f0a in runtime.cgocall
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:167
>>> 20 0x00464245 in main._Cfunc_test3
>>> at _cgo_gotypes.go:39
>>> 21 0x004642d7 in main.main
>>> at ./hello.go:33
>>> 22 0x00437073 in runtime.main
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/proc.go:250
>>> 23 0x0045f5e1 in runtime.goexit
>>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:1598
>>>
>>> 254 func cgocallbackg1(fn, frame unsafe.Pointer, ctxt uintptr) {
>>> 304 defer unwindm()
>>>
>>> 326 func unwindm(restore *bool) {
>>> 327 if *
Re: [go-nuts] Need help: Calling panic() is corrupting system stack
Hi Kurtis Rader,
Thanks for your response. I am working on it. I will quickly share it.
Before that one more update. I have commented the below two lines. Now from
the core, I am able to see the correct stack trace.
326 func unwindm(restore *bool) {
327 if *restore {
328 // Restore sp saved by cgocallback during
329 // unwind of g's stack (see comment at top of file).
330 mp := acquirem()
*331 //sched := //sched.sp
= *(*uintptr)(unsafe.Pointer(sched.sp + alignUp(sys.MinFrameSize,
sys.StackAlign)))*
333
334 // Do the accounting that cgocall will not have a
chance to do
335 // during an unwind.
336 //
337 // In the case where a Go call originates from C, ncgo
is 0
338 // and there is no matching cgocall to end.
339 if mp.ncgo > 0 {
340 mp.incgo = false
341 mp.ncgo--
342 osPreemptExtExit(mp)
343 }
344
345 releasem(mp)
346 }
347 }
(dlv)bt
0 0x00460ea1 in runtime.raise
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/sys_linux_amd64.s:154
1 0x00449845 in runtime.dieFromSignal
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/signal_unix.go:879
2 0x00449e25 in runtime.sigfwdgo
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/signal_unix.go:1092
3 0x004487a7 in runtime.sigtrampgo
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/signal_unix.go:432
4 0x00461186 in runtime.sigtramp
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/sys_linux_amd64.s:354
5 0x7f2d5ba16520 in ???
at ?:-1
6 0x00449a58 in runtime.crash
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/signal_unix.go:971
7 0x00434d85 in runtime.fatalpanic
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/panic.go:1168
8 0x004344cc in runtime.gopanic
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/panic.go:987
9 0x004642a7 in main.Test4
at ./export.go:8
10 0x0046431c in _cgoexp_209e16473f08_Test4
at _cgo_gotypes.go:61
11 0x0040535b in runtime.cgocallbackg1
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/cgocall.go:315
12 0x00405079 in runtime.cgocallbackg
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/cgocall.go:234
13 0x00461b0f in runtime.cgocallbackg
at :1
14 0x0045f3d4 in runtime.cgocallback
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/asm_amd64.s:998
15 0x004641bd in crosscall2
15 0x004641bd in crosscall2
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/cgo/asm_amd64.s:30
16 0x00464386 in C.Test4
at /tmp/go-build/_cgo_export.c:33
17 0x00464432 in C.test1
at ./hello.go:10
18 0x0046444d in C.test2
at ./hello.go:15
19 0x00464468 in C.test3
at ./hello.go:20
20 0x004644a7 in C._cgo_209e16473f08_Cfunc_test3
at /tmp/go-build/cgo-gcc-prolog:49
21 0x0045f2c4 in runtime.asmcgocall
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/asm_amd64.s:848
22 0x0046448a in C._cgo_209e16473f08_Cfunc_test3
at /tmp/go-build/cgo-gcc-prolog:44
23 0x00404f0a in runtime.cgocall
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/cgocall.go:167
24 0x00464245 in main._Cfunc_test3
at _cgo_gotypes.go:39
25 0x004642d7 in main.main
at ./hello.go:34
26 0x00437053 in runtime.main
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/proc.go:250
27 0x0045f5c1 in runtime.goexit
at /home/soomohan/mbalraj/GO/go1202/go/src/runtime/asm_amd64.s:1598
Best Regards
Mariappan
On Tue, Apr 4, 2023 at 9:02 AM Kurtis Rader wrote:
> You have not done what Robert suggested. That is, "I would start by
> publishing a small reproducible test case on github that fully compiles
> that demonstrates the issue." It may not be practical to do so. However,
> providing the source code for a small reproducible test case will make it
> infinitely easier for others to a) reproduce the problem, and b)
> investigate the problem and provide additional insights and possible fixes.
> Note that option (a) will, itself, provide insights into the nature of the
> problem if it only manifests on some, rather than all, platforms. You have
> provided a lot of useful data but this type of problem really requires
> others to be able to reproduce it. I say this as someone who was a level
> three support engineer for two decades that specialized in solving exactly
> this type of problem for the customers of the companies I worked for.
>
> On Mon, Apr 3, 2023 at 8:16 PM mariappan balraj <
> mariappan.bal...@gmail.com> wrote:
>
>> Hi Robert,
>>
>> Eager
Re: [go-nuts] Need help: Calling panic() is corrupting system stack
me.raise() /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/sys_linux_amd64.s:144 (dlv) c (dlv) c (dlv) > runtime.raise() /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/sys_linux_amd64.s:153 (PC: 0x460ebf) Warning: debugging optimized function 148: SYSCALL 149: MOVLAX, SI // arg 2 tid 150: MOVLR12, DI // arg 1 pid 151: MOVLsig+0(FP), DX // arg 3 152: MOVL$SYS_tgkill, AX => 153: SYSCALL 154: RET (dlv) bt 0 0x00460ebf in runtime.raise at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/sys_linux_amd64.s:153 1 0x00449865 in runtime.dieFromSignal at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/signal_unix.go:879 2 0x00449a78 in runtime.crash at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/signal_unix.go:971 3 0x00434da5 in runtime.fatalpanic at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:1168 4 0x004344ec in runtime.gopanic at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:987 5 0x004642a7 in main.Test4 at ./export.go:8 6 0x0046431c in _cgoexp_209e16473f08_Test4 at _cgo_gotypes.go:61 7 0x0040535b in runtime.cgocallbackg1 at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:315 8 0x00405079 in runtime.cgocallbackg at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:234 9 0x00461b0f in runtime.cgocallbackg at :1 10 0x0045f3f4 in runtime.cgocallback at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:998 11 0x004641bd in crosscall2 at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgo/asm_amd64.s:30 12 0x00464386 in C.Test4 at /tmp/go-build/_cgo_export.c:33 13 0x00464432 in C.test1 at ./hello.go:10 14 0x0046444d in C.test2 at ./hello.go:15 15 0x00464468 in C.test3 15 0x00464468 in C.test3 at ./hello.go:20 16 0x004644a7 in C._cgo_209e16473f08_Cfunc_test3 at /tmp/go-build/cgo-gcc-prolog:49 17 0x0045f2e4 in runtime.asmcgocall at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:848 18 0x0046448a in C._cgo_209e16473f08_Cfunc_test3 at /tmp/go-build/cgo-gcc-prolog:44 19 0x00404f0a in runtime.cgocall at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:167 20 0x00464245 in main._Cfunc_test3 at _cgo_gotypes.go:39 21 0x004642d7 in main.main at ./hello.go:34 22 0x00437073 in runtime.main at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/proc.go:250 23 0x0045f5e1 in runtime.goexit at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:1598 Stack trace looks fine till this point. Best Regards Mariappan On Mon, Apr 3, 2023 at 9:50 AM Robert Engels wrote: > I would start by publishing a small reproducible test case on github that > fully compiles that demonstrates the issue. > > On Apr 2, 2023, at 10:59 PM, mariappan balraj > wrote: > > > Hello Go Experts, > > It is good if someone can help on this? > > Best Regards > Mariappan > On Sat, Apr 1, 2023 at 7:45 AM mariappan balraj < > mariappan.bal...@gmail.com> wrote: > >> Hello Go experts, >> >> Could someone please help to resolve this issue? >> >> Best Regards >> Mariappan >> >> On Thu, Mar 30, 2023 at 2:52 PM mariappan balraj < >> mariappan.bal...@gmail.com> wrote: >> >>> Hello Go Experts, >>> >>> When panic() is called from Go function, in the below call sequence, >>> runtime.unwindm() [which is defer function of runtime.cgocallbackg1] is >>> called. This function is unwinding the system stack. Later, as part of the >>> function addOneOpenDeferFrame(), systemstack() is called to run a function >>> in the system stack. This will use the stack which is allocated for C >>> function calls. This makes stack unwinding impossible in case of panic() is >>> called. Can someone please help me to fix this issue? >>> >>> (dlv) bt >>> 0 0x004054e6 in runtime.unwindm >>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:326 >>> 1 0x00405446 in runtime.cgocallbackg1.func3 >>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:304 >>> 2 0x004340c8 in runtime.deferCallSave >>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:796 >>> 3 0x00433fa5 in runtime.runOpenDeferFrame >>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:769 >>> 4 0x00434332 in runtime.gopanic >>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/ru
[go-nuts] When assert is called from C code, dlv is not able to decode the core dump.
Hello Go Experts, Raised the following issue on DLV to track this issue. https://github.com/go-delve/delve/issues/3322 Best Regards Mariappan -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKKWi6SczODjrQPdXiiuwJBMM9Q_M75J9d%2BxtsDCAHe8O7925g%40mail.gmail.com.
[go-nuts] Need help: Calling panic() is corrupting system stack
Hello Go Experts,
It is good if someone can help on this?
Best Regards
Mariappan
On Sat, Apr 1, 2023 at 7:45 AM mariappan balraj
wrote:
> Hello Go experts,
>
> Could someone please help to resolve this issue?
>
> Best Regards
> Mariappan
>
> On Thu, Mar 30, 2023 at 2:52 PM mariappan balraj <
> mariappan.bal...@gmail.com> wrote:
>
>> Hello Go Experts,
>>
>> When panic() is called from Go function, in the below call sequence,
>> runtime.unwindm() [which is defer function of runtime.cgocallbackg1] is
>> called. This function is unwinding the system stack. Later, as part of the
>> function addOneOpenDeferFrame(), systemstack() is called to run a function
>> in the system stack. This will use the stack which is allocated for C
>> function calls. This makes stack unwinding impossible in case of panic() is
>> called. Can someone please help me to fix this issue?
>>
>> (dlv) bt
>> 0 0x004054e6 in runtime.unwindm
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:326
>> 1 0x00405446 in runtime.cgocallbackg1.func3
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:304
>> 2 0x004340c8 in runtime.deferCallSave
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:796
>> 3 0x00433fa5 in runtime.runOpenDeferFrame
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:769
>> 4 0x00434332 in runtime.gopanic
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:884
>> 5 0x004642a7 in main.Test4
>> at ./export.go:7
>> at ./export.go:7
>> 6 0x0046431c in _cgoexp_78b81bbf688e_Test4
>> at _cgo_gotypes.go:61
>> 7 0x0040535b in runtime.cgocallbackg1
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:315
>> 8 0x00405079 in runtime.cgocallbackg
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:234
>> 9 0x00461b0f in runtime.cgocallbackg
>> at :1
>> 10 0x0045f3f4 in runtime.cgocallback
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:998
>> 11 0x004641bd in crosscall2
>> at
>> /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgo/asm_amd64.s:30
>> 12 0x00464386 in C.Test4
>> at /tmp/go-build/_cgo_export.c:33
>> 13 0x00464432 in C.test1
>> at ./hello.go:9
>> 14 0x0046444d in C.test2
>> at ./hello.go:14
>> 15 0x00464468 in C.test3
>> 15 0x00464468 in C.test3
>> at ./hello.go:19
>> 16 0x004644a7 in C._cgo_78b81bbf688e_Cfunc_test3
>> at /tmp/go-build/cgo-gcc-prolog:49
>> 17 0x0045f2e4 in runtime.asmcgocall
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:848
>> 18 0x0046448a in C._cgo_78b81bbf688e_Cfunc_test3
>> at /tmp/go-build/cgo-gcc-prolog:44
>> 19 0x00404f0a in runtime.cgocall
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:167
>> 20 0x00464245 in main._Cfunc_test3
>> at _cgo_gotypes.go:39
>> 21 0x004642d7 in main.main
>> at ./hello.go:33
>> 22 0x00437073 in runtime.main
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/proc.go:250
>> 23 0x0045f5e1 in runtime.goexit
>> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:1598
>>
>> 254 func cgocallbackg1(fn, frame unsafe.Pointer, ctxt uintptr) {
>> 304 defer unwindm()
>>
>> 326 func unwindm(restore *bool) {
>> 327 if *restore {
>> 328 // Restore sp saved by cgocallback during
>> 329 // unwind of g's stack (see comment at top of file).
>> 330 mp := acquirem()
>> 331 sched :=
>> 332 sched.sp = *(*uintptr)(unsafe.Pointer(sched.sp +
>> alignUp(sys.MinFrameSize, sys.StackAlign)))
>>
>> (dlv)
>> > runtime.addOneOpenDeferFrame()
>> /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:642 (PC:
>> 0x433a45)
>> Warning: debugging optimized function
>>637: func addOneOpenDeferFrame(gp *g, pc uintptr, sp unsafe.Pointer) {
>>638: var prevDefer *_defer
>>639: if sp == nil {
>>640: prevDefer = gp._defer
>>641: pc = prevDefer.framepc
>> => 642: sp = unsafe.Pointer(prevDefer.sp)
>>643: }
>>644: systemstack(func() {
>
[go-nuts] Re: Calling panic() is corrupting system stack
Hello Go experts,
Could someone please help to resolve this issue?
Best Regards
Mariappan
On Thu, Mar 30, 2023 at 2:52 PM mariappan balraj
wrote:
> Hello Go Experts,
>
> When panic() is called from Go function, in the below call sequence,
> runtime.unwindm() [which is defer function of runtime.cgocallbackg1] is
> called. This function is unwinding the system stack. Later, as part of the
> function addOneOpenDeferFrame(), systemstack() is called to run a function
> in the system stack. This will use the stack which is allocated for C
> function calls. This makes stack unwinding impossible in case of panic() is
> called. Can someone please help me to fix this issue?
>
> (dlv) bt
> 0 0x004054e6 in runtime.unwindm
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:326
> 1 0x00405446 in runtime.cgocallbackg1.func3
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:304
> 2 0x004340c8 in runtime.deferCallSave
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:796
> 3 0x00433fa5 in runtime.runOpenDeferFrame
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:769
> 4 0x00434332 in runtime.gopanic
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:884
> 5 0x004642a7 in main.Test4
> at ./export.go:7
> at ./export.go:7
> 6 0x0046431c in _cgoexp_78b81bbf688e_Test4
> at _cgo_gotypes.go:61
> 7 0x0040535b in runtime.cgocallbackg1
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:315
> 8 0x00405079 in runtime.cgocallbackg
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:234
> 9 0x00461b0f in runtime.cgocallbackg
> at :1
> 10 0x0045f3f4 in runtime.cgocallback
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:998
> 11 0x004641bd in crosscall2
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgo/asm_amd64.s:30
> 12 0x00464386 in C.Test4
> at /tmp/go-build/_cgo_export.c:33
> 13 0x00464432 in C.test1
> at ./hello.go:9
> 14 0x0046444d in C.test2
> at ./hello.go:14
> 15 0x00464468 in C.test3
> 15 0x00464468 in C.test3
> at ./hello.go:19
> 16 0x004644a7 in C._cgo_78b81bbf688e_Cfunc_test3
> at /tmp/go-build/cgo-gcc-prolog:49
> 17 0x0045f2e4 in runtime.asmcgocall
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:848
> 18 0x0046448a in C._cgo_78b81bbf688e_Cfunc_test3
> at /tmp/go-build/cgo-gcc-prolog:44
> 19 0x00404f0a in runtime.cgocall
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:167
> 20 0x00464245 in main._Cfunc_test3
> at _cgo_gotypes.go:39
> 21 0x004642d7 in main.main
> at ./hello.go:33
> 22 0x00437073 in runtime.main
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/proc.go:250
> 23 0x0045f5e1 in runtime.goexit
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:1598
>
> 254 func cgocallbackg1(fn, frame unsafe.Pointer, ctxt uintptr) {
> 304 defer unwindm()
>
> 326 func unwindm(restore *bool) {
> 327 if *restore {
> 328 // Restore sp saved by cgocallback during
> 329 // unwind of g's stack (see comment at top of file).
> 330 mp := acquirem()
> 331 sched :=
> 332 sched.sp = *(*uintptr)(unsafe.Pointer(sched.sp +
> alignUp(sys.MinFrameSize, sys.StackAlign)))
>
> (dlv)
> > runtime.addOneOpenDeferFrame()
> /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:642 (PC:
> 0x433a45)
> Warning: debugging optimized function
>637: func addOneOpenDeferFrame(gp *g, pc uintptr, sp unsafe.Pointer) {
>638: var prevDefer *_defer
>639: if sp == nil {
>640: prevDefer = gp._defer
>641: pc = prevDefer.framepc
> => 642: sp = unsafe.Pointer(prevDefer.sp)
>643: }
>644: systemstack(func() {
>645: gentraceback(pc, uintptr(sp), 0, gp, 0, nil,
> 0x7fff,
>646: func(frame *stkframe, unused
> unsafe.Pointer) bool {
>647: if prevDefer != nil &&
> prevDefer.sp == frame.sp {
> (dlv) bt
> 0 0x00433a45 in runtime.addOneOpenDeferFrame
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:642
> 1 0x00434357 in runtime.gopanic
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:886
[go-nuts] Re: Calling panic() is corrupting system stack
Hello Go Experts,
When panic() is called from Go function, in the below call sequence,
runtime.unwindm() [which is defer function of runtime.cgocallbackg1] is
called. This function is unwinding the system stack. Later, as part of the
function addOneOpenDeferFrame(), systemstack() is called to run a function
in the system stack. This will use the stack which is allocated for C
function calls. This makes stack unwinding impossible in case of panic() is
called. Can someone please help me to fix this issue?
(dlv) bt
0 0x004054e6 in runtime.unwindm
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:326
1 0x00405446 in runtime.cgocallbackg1.func3
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:304
2 0x004340c8 in runtime.deferCallSave
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:796
3 0x00433fa5 in runtime.runOpenDeferFrame
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:769
4 0x00434332 in runtime.gopanic
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:884
5 0x004642a7 in main.Test4
at ./export.go:7
at ./export.go:7
6 0x0046431c in _cgoexp_78b81bbf688e_Test4
at _cgo_gotypes.go:61
7 0x0040535b in runtime.cgocallbackg1
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:315
8 0x00405079 in runtime.cgocallbackg
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:234
9 0x00461b0f in runtime.cgocallbackg
at :1
10 0x0045f3f4 in runtime.cgocallback
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:998
11 0x004641bd in crosscall2
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgo/asm_amd64.s:30
12 0x00464386 in C.Test4
at /tmp/go-build/_cgo_export.c:33
13 0x00464432 in C.test1
at ./hello.go:9
14 0x0046444d in C.test2
at ./hello.go:14
15 0x00464468 in C.test3
15 0x00464468 in C.test3
at ./hello.go:19
16 0x004644a7 in C._cgo_78b81bbf688e_Cfunc_test3
at /tmp/go-build/cgo-gcc-prolog:49
17 0x0045f2e4 in runtime.asmcgocall
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:848
18 0x0046448a in C._cgo_78b81bbf688e_Cfunc_test3
at /tmp/go-build/cgo-gcc-prolog:44
19 0x00404f0a in runtime.cgocall
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:167
20 0x00464245 in main._Cfunc_test3
at _cgo_gotypes.go:39
21 0x004642d7 in main.main
at ./hello.go:33
22 0x00437073 in runtime.main
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/proc.go:250
23 0x0045f5e1 in runtime.goexit
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:1598
254 func cgocallbackg1(fn, frame unsafe.Pointer, ctxt uintptr) {
304 defer unwindm()
326 func unwindm(restore *bool) {
327 if *restore {
328 // Restore sp saved by cgocallback during
329 // unwind of g's stack (see comment at top of file).
330 mp := acquirem()
331 sched :=
332 sched.sp = *(*uintptr)(unsafe.Pointer(sched.sp +
alignUp(sys.MinFrameSize, sys.StackAlign)))
(dlv)
> runtime.addOneOpenDeferFrame()
/home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:642 (PC:
0x433a45)
Warning: debugging optimized function
637: func addOneOpenDeferFrame(gp *g, pc uintptr, sp unsafe.Pointer) {
638: var prevDefer *_defer
639: if sp == nil {
640: prevDefer = gp._defer
641: pc = prevDefer.framepc
=> 642: sp = unsafe.Pointer(prevDefer.sp)
643: }
644: systemstack(func() {
645: gentraceback(pc, uintptr(sp), 0, gp, 0, nil,
0x7fff,
646: func(frame *stkframe, unused
unsafe.Pointer) bool {
647: if prevDefer != nil && prevDefer.sp
== frame.sp {
(dlv) bt
0 0x00433a45 in runtime.addOneOpenDeferFrame
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:642
1 0x00434357 in runtime.gopanic
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:886
2 0x004642a7 in main.Test4
at ./export.go:7
On Tue, Mar 28, 2023 at 4:14 PM mariappan balraj
wrote:
> Hello Go Experts,
>
> I am observing system stack corruption when panic() is called from go
> function. When panic is called from Test4(), as part of
> runtime.systemstack_switch(), the RSP and RBP is set in such a way that it
> will corrupt the stack.
>
> Rbp = 0x7ffdb188bd20===> This should be less than 0x7ffdb188bc50. But
> it is set to the value which is already used for CGO calls. So it is making
> the system stack to corrupt. When the core file is generated, it makes it
> unable to debug fro
[go-nuts] Calling panic() is corrupting system stack
Hello Go Experts,
I am observing system stack corruption when panic() is called from go
function. When panic is called from Test4(), as part of
runtime.systemstack_switch(), the RSP and RBP is set in such a way that it
will corrupt the stack.
Rbp = 0x7ffdb188bd20===> This should be less than 0x7ffdb188bc50. But
it is set to the value which is already used for CGO calls. So it is making
the system stack to corrupt. When the core file is generated, it makes it
unable to debug from the core file using dlv. Can someone please help on
this issue?
RBP 0x7ffdb188bc50 RA 0x45f3f4 runtime.cgocallback
/home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s 1003
RBP 0x7ffdb188bca0 RA 0x4641bd crosscall2
/home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgo/asm_amd64.s 32
RBP 0x7ffdb188bcd0 RA 0x464386 C.Test4 /tmp/go-build/_cgo_export.c 35
RBP 0x7ffdb188bce0 RA 0x464432 C.test1 /home/soomohan/mbalraj/test/hello.go
10
RBP 0x7ffdb188bd00 RA 0x46444d C.test2 /home/soomohan/mbalraj/test/hello.go
15
RBP 0x7ffdb188bd20 RA 0x464468 C.test3 /home/soomohan/mbalraj/test/hello.go
20
RBP 0x7ffdb188bd50 RA 0x4644a7 C._cgo_78b81bbf688e_Cfunc_test3
/tmp/go-build/cgo-gcc-prolog 51
go version
go version go1.20.2 linux/amd64
//hello.go
package main
/*
#include
extern void Test4(void);
void test1(void) {
Test4();
}
void test2(void) {
int val = 2;
test1();
}
void test3(void) {
int val = 3;
test2();
}
void test4(void) {
printf("Test4()");
}
*/
import "C"
func Test5() {
C.test4()
}
func main() {
C.test3()
}
//export.go
package main
import "C"
//export Test4
func Test4() {
panic("Panic inside Test4")
//Test5()
}
I have written the following script test.start to debug this issue further
in DLV.
def command_goroutine_start_line(args):
regs = registers().Regs
rip = 0
for reg in regs:
if reg.Name == "Rbp":
rbp = int(reg.Value, 16)
elif reg.Name == "Rip":
rip = int(reg.Value, 16)
da = disassemble(StartPC=rip, EndPC=rip+1).Disassemble
print("RBP 0x%x RIP 0x%x %s %s %s" % (rbp, rip,
da[0].Loc.Function.Name_, da[0].Loc.File, da[0].Loc.Line))
while True:
mem = examine_memory(rbp, 8).Mem
val = 0
for i in range(len(mem)):
val <<= 8
val += mem[len(mem) - i - 1]
prbp = val
mem = examine_memory(rbp + 8, 8).Mem
val = 0
for i in range(len(mem)):
val <<= 8
val += mem[len(mem) - i - 1]
ra = val
da = disassemble(StartPC=ra, EndPC=ra+1).Disassemble
print("RBP 0x%x RA 0x%x %s %s %s" % (prbp, ra,
da[0].Loc.Function.Name_, da[0].Loc.File, da[0].Loc.Line))
if prbp == 0:
break
rbp = prbp
def main():
dlv_command("config alias goroutine_start_line gsl")
(dlv)bt
RBP 0x0 RA 0x45f5e1 runtime.goexit
/home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s 1599
0 0x00433b04 in runtime.addOneOpenDeferFrame.func1
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:646
1 0x0045f0c0 in runtime.systemstack_switch
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:463
2 0x00433a89 in runtime.addOneOpenDeferFrame
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:644
3 0x00434357 in runtime.gopanic
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:886
4 0x004642a7 in main.Test4
at ./export.go:7
5 0x0046431c in _cgoexp_78b81bbf688e_Test4
at _cgo_gotypes.go:61
6 0x0040535b in runtime.cgocallbackg1
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:315
7 0x00405079 in runtime.cgocallbackg
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:234
8 0x00461b0f in runtime.cgocallbackg
at :1
9 0x0045f3f4 in runtime.cgocallback
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:998
10 0x0001 in ???
at ?:-1
11 0x00464386 in C.Test4
at /tmp/go-build/_cgo_export.c:33
12 0x00464432 in C.test1
at ./hello.go:9
13 0x0046444d in C.test2
at ./hello.go:14
14 0x00464468 in C.test3
at ./hello.go:19
15 0x004644a7 in C._cgo_78b81bbf688e_Cfunc_test3
15 0x004644a7 in C._cgo_78b81bbf688e_Cfunc_test3
at /tmp/go-build/cgo-gcc-prolog:49
16 0x0045f2e4 in runtime.asmcgocall
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:848
17 0x0046448a in C._cgo_78b81bbf688e_Cfunc_test3
at /tmp/go-build/cgo-gcc-prolog:44
18 0x00404f0a in runtime.cgocall
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:167
19 0x00464245 in main._Cfunc_test3
at _cgo_gotypes.go:39
20 0x004642d7 in main.main
at ./hello.go:33
21 0x00437073 in runtime.main
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/proc.go:250
22
Re: [go-nuts] CGO core dump analysis using GDB
Hi Tamas, Using RPC will not scale and it needs lot of effort. So our only choice is CGO. Best Regards Mariappan On Monday, January 9, 2023 at 5:04:19 PM UTC+5:30 Tamás Gulácsi wrote: > I'd create a separate C program, that can be communicated with RPC style - > (https://github.com/protobuf-c/protobuf-c-rpc may solve it easily), > and have the Go program start it like > https://github.com/hashicorp/go-plugin . > > That way the stack traces and core dumps are separate, each program is > easier to debug, > the C error does not take down the Go program, which can restart the > plugin ... > > mariappa...@gmail.com a következőt írta (2023. január 9., hétfő, 10:20:28 > UTC+1): > >> Hi Ian, >> >> Thanks. I will try this. When a process is crashed because of a >> SEGMENTATION fault, it can be debugged by identifying the stack trace from >> the core dump. Is there any other technique to debug this issue? Can you >> please help if any other technique is there? >> >> Best Regards >> Mariappan >> >> On Mon, Jan 9, 2023 at 12:07 PM Ian Lance Taylor >> wrote: >> >>> On Sun, Jan 8, 2023, 9:33 PM mariappan balraj >>> wrote: >>> >>>> Hi Ian, >>>> >>>> Thanks for all your replies. It really shows that you have tried to >>>> give your best all the time. I need some direction to get a permanent >>>> solution for this. Is it possible to get help from the core google GO >>>> team? >>>> How to escalate this issue and get the fix? Please give me directions. So >>>> that I can try best from my side. >>>> >>> >>> I'm on the core Google Go team myself. >>> >>> The next step is to file a bug report at https://go.dev/issue, with >>> exact details for how to reproduce the problem. But I don't want to >>> mislead you: it's unlikely that anybody on the core Go team is going to fix >>> this. That said, Go is an open source project, and filing a bug report is >>> the right step to encourage someone to fix the problem. >>> >>> It's also worth taking a step back and describing the real problem. >>> Using gdb to get a stack trace from a core dump is a technique, it's not a >>> solution. Perhaps there are other techniques. >>> >>> Ian >>> >>> >>> >>>> On Sat, Jan 7, 2023 at 10:29 PM Ian Lance Taylor >>>> wrote: >>>> >>>>> On Fri, Jan 6, 2023 at 9:01 PM mariappan balraj >>>>> wrote: >>>>> > >>>>> > Thanks for your continuous support. GOLANG supports CGO to invoke C >>>>> functions. When it is supported, the important thing is, it should >>>>> provide >>>>> better debugging support when there is any issue. In customer sites, it >>>>> is >>>>> not possible to run applications with GDB. Customers only provide core >>>>> dump >>>>> and logs. With the provided information, we should be able to debug the >>>>> issue. It may not be possible to reproduce all the issues in the >>>>> development environment to debug the issue. >>>>> > >>>>> > When we run the application with GDB, we are getting stack trace. >>>>> Then the same thing should be possible with core dump also. >>>>> > >>>>> > I have tried with CGO symbolizer from >>>>> https://github.com/ianlancetaylor/cgosymbolizer. I am getting the >>>>> following output. This is useful. But I want to dump the C variables >>>>> (local >>>>> and global) to debug the issue. This is very critical when we want to >>>>> debug >>>>> some issues. >>>>> > >>>>> > What should I do now? How to proceed further? If possible, please >>>>> provide your help with this. >>>>> >>>>> I'm sorry, I don't have any useful suggestions. It's possible in >>>>> principle to unwind the stack yourself by looking carefully at the >>>>> instructions that will be executed and the PC and SP registers, and >>>>> then to look at the instructions to figure out where variables are >>>>> stored, but it's hard and it's easy to make a mistake. >>>>> >>>>> Ian >>>>> >>>>> >>>>> > fatal error: unexpected signal during runtime execution >>>>> > [signal SIGSEG
Re: [go-nuts] Re: Debugging memory leak when a GO process crashed
Hi Brian, A Go program can crash because of Out of Memory. Yes it can be because of goroutine leak. Or it can have some reference to global variables, but it should be freed? How to debug this? When the leak is happening while using CGO, is there any tool to debug this? Best Regards Mariappan On Thu, Jan 12, 2023 at 2:19 PM Brian Candler wrote: > I think you're not being clear on your problem you're trying to solve. > > There are no "memory leaks" in Go in the traditional sense (omitting to > free an allocation) because of the garbage collector. Therefore, if memory > is not being freed in a pure Go program, it's because you are keeping a > reference to it somewhere - e.g. in a global variable, directly or > indirectly. Or it could be referenced from a local variable in a goroutine > which isn't terminating - in that case I'd say that's a goroutine leak, not > a memory leak. Is that the sort of thing you're trying to debug? > > Or, is the situation that you're using CGO and forgetting to free some > allocations in your C code? > > Or, I've seen some people complain that Go doesn't not release unused > memory back to the operating system as quickly as they'd like or expect, > showing as high RSS. If that's your issue then it can be discussed. > > On Thursday, 12 January 2023 at 03:58:52 UTC mariappa...@gmail.com wrote: > >> Hello Go experts, >> >> Can someone please help with this? >> >> Best Regards >> Mariappan >> >> On Tue, Jan 10, 2023 at 1:24 PM mariappan balraj >> wrote: >> >>> Hello Go experts, >>> >>> I could able to find the solution to debug memory leaks of GO process, >>> when it is running by using PPROF. Is it possible to collect the heap >>> profile for debugging, when GO process crashed using core dump? or what is >>> the recommended way to root cause the memory leak? Based on the need, >>> enabling PPROF and debugging may not be possible in the production >>> environment. Please help. >>> >>> Best Regards >>> Mariappan >>> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/19a761a1-7707-4300-9128-93f22b9ee342n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/19a761a1-7707-4300-9128-93f22b9ee342n%40googlegroups.com?utm_medium=email_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKKWi6SKZr9x7-YoJNLLp57815bzg40wjCsYSYxtd7SQ2VMEUA%40mail.gmail.com.
[go-nuts] Re: Debugging memory leak when a GO process crashed
Hello Go experts, Can someone please help with this? Best Regards Mariappan On Tue, Jan 10, 2023 at 1:24 PM mariappan balraj wrote: > Hello Go experts, > > I could able to find the solution to debug memory leaks of GO process, > when it is running by using PPROF. Is it possible to collect the heap > profile for debugging, when GO process crashed using core dump? or what is > the recommended way to root cause the memory leak? Based on the need, > enabling PPROF and debugging may not be possible in the production > environment. Please help. > > Best Regards > Mariappan > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKKWi6THY4LAe1Euc%2BwyOT%2By_Cb90hOAWQzqhcSK%2BE%2BGEWsjYg%40mail.gmail.com.
[go-nuts] Debugging memory leak when a GO process crashed
Hello Go experts, I could able to find the solution to debug memory leaks of GO process, when it is running by using PPROF. Is it possible to collect the heap profile for debugging, when GO process crashed using core dump? or what is the recommended way to root cause the memory leak? Based on the need, enabling PPROF and debugging may not be possible in the production environment. Please help. Best Regards Mariappan -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKKWi6RpzsG8NHn4VpQYgOESCfz4g6CyzYmAs-HeWtq0y5bUCg%40mail.gmail.com.
Re: [go-nuts] CGO core dump analysis using GDB
Hi Ian,
Thanks. I will try this. When a process is crashed because of a
SEGMENTATION fault, it can be debugged by identifying the stack trace from
the core dump. Is there any other technique to debug this issue? Can you
please help if any other technique is there?
Best Regards
Mariappan
On Mon, Jan 9, 2023 at 12:07 PM Ian Lance Taylor wrote:
> On Sun, Jan 8, 2023, 9:33 PM mariappan balraj
> wrote:
>
>> Hi Ian,
>>
>> Thanks for all your replies. It really shows that you have tried to give
>> your best all the time. I need some direction to get a permanent solution
>> for this. Is it possible to get help from the core google GO team? How to
>> escalate this issue and get the fix? Please give me directions. So that I
>> can try best from my side.
>>
>
> I'm on the core Google Go team myself.
>
> The next step is to file a bug report at https://go.dev/issue, with exact
> details for how to reproduce the problem. But I don't want to mislead you:
> it's unlikely that anybody on the core Go team is going to fix this. That
> said, Go is an open source project, and filing a bug report is the right
> step to encourage someone to fix the problem.
>
> It's also worth taking a step back and describing the real problem. Using
> gdb to get a stack trace from a core dump is a technique, it's not a
> solution. Perhaps there are other techniques.
>
> Ian
>
>
>
>> On Sat, Jan 7, 2023 at 10:29 PM Ian Lance Taylor wrote:
>>
>>> On Fri, Jan 6, 2023 at 9:01 PM mariappan balraj
>>> wrote:
>>> >
>>> > Thanks for your continuous support. GOLANG supports CGO to invoke C
>>> functions. When it is supported, the important thing is, it should provide
>>> better debugging support when there is any issue. In customer sites, it is
>>> not possible to run applications with GDB. Customers only provide core dump
>>> and logs. With the provided information, we should be able to debug the
>>> issue. It may not be possible to reproduce all the issues in the
>>> development environment to debug the issue.
>>> >
>>> > When we run the application with GDB, we are getting stack trace. Then
>>> the same thing should be possible with core dump also.
>>> >
>>> > I have tried with CGO symbolizer from
>>> https://github.com/ianlancetaylor/cgosymbolizer. I am getting the
>>> following output. This is useful. But I want to dump the C variables (local
>>> and global) to debug the issue. This is very critical when we want to debug
>>> some issues.
>>> >
>>> > What should I do now? How to proceed further? If possible, please
>>> provide your help with this.
>>>
>>> I'm sorry, I don't have any useful suggestions. It's possible in
>>> principle to unwind the stack yourself by looking carefully at the
>>> instructions that will be executed and the PC and SP registers, and
>>> then to look at the instructions to figure out where variables are
>>> stored, but it's hard and it's easy to make a mistake.
>>>
>>> Ian
>>>
>>>
>>> > fatal error: unexpected signal during runtime execution
>>> > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x463926]
>>> >
>>> > runtime stack:
>>> > runtime.throw({0x49046b?, 0x0?})
>>> > /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7ffca8644230
>>> sp=0x7ffca8644200 pc=0x43243d
>>> > runtime.sigpanic()
>>> > /usr/local/go/src/runtime/signal_unix.go:819 +0x369 fp=0x7ffca8644280
>>> sp=0x7ffca8644230 pc=0x446569
>>> >
>>> > goroutine 1 [syscall]:
>>> > test1
>>> > /home/ubuntu/mbalraj/GO/TEST/test.go:9 pc=0x463926
>>> > test2
>>> > /home/ubuntu/mbalraj/GO/TEST/test.go:14 pc=0x46393b
>>> > test3
>>> > /home/ubuntu/mbalraj/GO/TEST/test.go:18 pc=0x46394b
>>> > _cgo_64d258852278_Cfunc_test3
>>> > /tmp/go-build/cgo-gcc-prolog:49 pc=0x46396b
>>> > runtime.asmcgocall
>>> > /usr/local/go/src/runtime/asm_amd64.s:844 pc=0x45c443
>>> > runtime.cgocall(0x46394f, 0xc58f70)
>>> > /usr/local/go/src/runtime/cgocall.go:158 +0x5c fp=0xc58f48
>>> sp=0xc58f10 pc=0x40579c
>>> > main._Cfunc_test3()
>>> > _cgo_gotypes.go:41 +0x45 fp=0xc58f70 sp=0xc58f48 pc=0x463885
>>> > main.main()
>>> > /home/ubuntu/mbalraj/GO/TEST/test.go:26 +0x17 fp=0xc58f80
>>> sp=0xc58f70 pc=0x4638b7
>>> > runtime.main()
>>> > /usr/l
Re: [go-nuts] CGO core dump analysis using GDB
Hi Ian,
Thanks for all your replies. It really shows that you have tried to give
your best all the time. I need some direction to get a permanent solution
for this. Is it possible to get help from the core google GO team? How to
escalate this issue and get the fix? Please give me directions. So that I
can try best from my side.
Best Regards
Mariappan
On Sat, Jan 7, 2023 at 10:29 PM Ian Lance Taylor wrote:
> On Fri, Jan 6, 2023 at 9:01 PM mariappan balraj
> wrote:
> >
> > Thanks for your continuous support. GOLANG supports CGO to invoke C
> functions. When it is supported, the important thing is, it should provide
> better debugging support when there is any issue. In customer sites, it is
> not possible to run applications with GDB. Customers only provide core dump
> and logs. With the provided information, we should be able to debug the
> issue. It may not be possible to reproduce all the issues in the
> development environment to debug the issue.
> >
> > When we run the application with GDB, we are getting stack trace. Then
> the same thing should be possible with core dump also.
> >
> > I have tried with CGO symbolizer from
> https://github.com/ianlancetaylor/cgosymbolizer. I am getting the
> following output. This is useful. But I want to dump the C variables (local
> and global) to debug the issue. This is very critical when we want to debug
> some issues.
> >
> > What should I do now? How to proceed further? If possible, please
> provide your help with this.
>
> I'm sorry, I don't have any useful suggestions. It's possible in
> principle to unwind the stack yourself by looking carefully at the
> instructions that will be executed and the PC and SP registers, and
> then to look at the instructions to figure out where variables are
> stored, but it's hard and it's easy to make a mistake.
>
> Ian
>
>
> > fatal error: unexpected signal during runtime execution
> > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x463926]
> >
> > runtime stack:
> > runtime.throw({0x49046b?, 0x0?})
> > /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7ffca8644230
> sp=0x7ffca8644200 pc=0x43243d
> > runtime.sigpanic()
> > /usr/local/go/src/runtime/signal_unix.go:819 +0x369 fp=0x7ffca8644280
> sp=0x7ffca8644230 pc=0x446569
> >
> > goroutine 1 [syscall]:
> > test1
> > /home/ubuntu/mbalraj/GO/TEST/test.go:9 pc=0x463926
> > test2
> > /home/ubuntu/mbalraj/GO/TEST/test.go:14 pc=0x46393b
> > test3
> > /home/ubuntu/mbalraj/GO/TEST/test.go:18 pc=0x46394b
> > _cgo_64d258852278_Cfunc_test3
> > /tmp/go-build/cgo-gcc-prolog:49 pc=0x46396b
> > runtime.asmcgocall
> > /usr/local/go/src/runtime/asm_amd64.s:844 pc=0x45c443
> > runtime.cgocall(0x46394f, 0xc58f70)
> > /usr/local/go/src/runtime/cgocall.go:158 +0x5c fp=0xc58f48
> sp=0xc58f10 pc=0x40579c
> > main._Cfunc_test3()
> > _cgo_gotypes.go:41 +0x45 fp=0xc58f70 sp=0xc58f48 pc=0x463885
> > main.main()
> > /home/ubuntu/mbalraj/GO/TEST/test.go:26 +0x17 fp=0xc58f80
> sp=0xc58f70 pc=0x4638b7
> > runtime.main()
> > /usr/local/go/src/runtime/proc.go:250 +0x212 fp=0xc58fe0
> sp=0xc58f80 pc=0x434c92
> > runtime.goexit()
> > /usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc58fe8
> sp=0xc58fe0 pc=0x45c761
> >
> > Best Regards
> > Mariappan
> >
> > On Sat, Jan 7, 2023 at 9:45 AM Ian Lance Taylor wrote:
> >>
> >> On Fri, Jan 6, 2023, 5:57 PM mariappan balraj <
> mariappan.bal...@gmail.com> wrote:
> >>>
> >>> Hi Ian,
> >>> Thanks for your active help. When I run the program by using gdb, I am
> getting the complete stack. No issue. The issue is there when we debug core
> dump. Could you kindly please check whether you are seeing the same
> behavior with core dump?
> >>
> >>
> >>
> >> Oh, right, sorry, I forgot about the core dump part. I don't know if
> there is a way to make that better, given the three different stacks
> involved. I'm surprised that it works as well as it does. A pure C
> program that doesn't use sigaltstack only has a single stack, so it's a
> much simpler case.
> >>
> >> Ian
> >>
> >>
> >>
> >>> On Sat, 7 Jan, 2023, 7:03 am Ian Lance Taylor,
> wrote:
> >>>>
> >>>> On Fri, Jan 6, 2023 at 5:28 PM mariappan balraj
> >>>> wrote:
> >>>> >
> >>>> > I am not expecting GO stack. I am interested only in getting C
> stack. If I want go stack, I can use delve debugger to get it. From GO,
> using CGO, test3() is c
Re: [go-nuts] CGO core dump analysis using GDB
Hi Ian,
Thanks for your continuous support. GOLANG supports CGO to invoke C
functions. When it is supported, the important thing is, it should provide
better debugging support when there is any issue. In customer sites, it is
not possible to run applications with GDB. Customers only provide core dump
and logs. With the provided information, we should be able to debug the
issue. It may not be possible to reproduce all the issues in the
development environment to debug the issue.
When we run the application with GDB, we are getting stack trace. Then the
same thing should be possible with core dump also.
I have tried with CGO symbolizer from
https://github.com/ianlancetaylor/cgosymbolizer. I am getting the following
output. This is useful. But I want to dump the C variables (local and
global) to debug the issue. This is very critical when we want to debug
some issues.
What should I do now? How to proceed further? If possible, please provide
your help with this.
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x463926]
runtime stack:
runtime.throw({0x49046b?, 0x0?})
/usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7ffca8644230
sp=0x7ffca8644200 pc=0x43243d
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:819 +0x369 fp=0x7ffca8644280
sp=0x7ffca8644230 pc=0x446569
goroutine 1 [syscall]:
test1
/home/ubuntu/mbalraj/GO/TEST/test.go:9 pc=0x463926
test2
/home/ubuntu/mbalraj/GO/TEST/test.go:14 pc=0x46393b
test3
/home/ubuntu/mbalraj/GO/TEST/test.go:18 pc=0x46394b
_cgo_64d258852278_Cfunc_test3
/tmp/go-build/cgo-gcc-prolog:49 pc=0x46396b
runtime.asmcgocall
/usr/local/go/src/runtime/asm_amd64.s:844 pc=0x45c443
runtime.cgocall(0x46394f, 0xc58f70)
/usr/local/go/src/runtime/cgocall.go:158 +0x5c fp=0xc58f48
sp=0xc58f10 pc=0x40579c
main._Cfunc_test3()
_cgo_gotypes.go:41 +0x45 fp=0xc58f70 sp=0xc58f48 pc=0x463885
main.main()
/home/ubuntu/mbalraj/GO/TEST/test.go:26 +0x17 fp=0xc58f80
sp=0xc58f70 pc=0x4638b7
runtime.main()
/usr/local/go/src/runtime/proc.go:250 +0x212 fp=0xc58fe0
sp=0xc58f80 pc=0x434c92
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc58fe8
sp=0xc58fe0 pc=0x45c761
Best Regards
Mariappan
On Sat, Jan 7, 2023 at 9:45 AM Ian Lance Taylor wrote:
> On Fri, Jan 6, 2023, 5:57 PM mariappan balraj
> wrote:
>
>> Hi Ian,
>> Thanks for your active help. When I run the program by using gdb, I am
>> getting the complete stack. No issue. The issue is there when we debug core
>> dump. Could you kindly please check whether you are seeing the same
>> behavior with core dump?
>>
>
>
> Oh, right, sorry, I forgot about the core dump part. I don't know if
> there is a way to make that better, given the three different stacks
> involved. I'm surprised that it works as well as it does. A pure C
> program that doesn't use sigaltstack only has a single stack, so it's a
> much simpler case.
>
> Ian
>
>
>
> On Sat, 7 Jan, 2023, 7:03 am Ian Lance Taylor, wrote:
>>
>>> On Fri, Jan 6, 2023 at 5:28 PM mariappan balraj
>>> wrote:
>>> >
>>> > I am not expecting GO stack. I am interested only in getting C stack.
>>> If I want go stack, I can use delve debugger to get it. From GO, using CGO,
>>> test3() is called which is calling test2() which is calling test1(). I am
>>> expecting only C stack which contains test3(), test2(), test1(). In this
>>> particular case assigning value by using pointer variable which contains
>>> NULL(segmentation fault). I am seeing only test1(). After that it is not
>>> stack and saying stack corruption. I strongly believe that you can help on
>>> this. Please help.
>>>
>>> I put your program in foo.go. Then I did:
>>>
>>> > CGO_CFLAGS=-g go build foo.go
>>> > gdb ./foo
>>> GNU gdb (Debian 12.1-3) 12.1
>>> Copyright (C) 2022 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <
>>> http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> Type "show copying" and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <https://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>> <http://www.gnu.org/software/gdb/documentation/>.
>>>
>>> For help, type "help".
>>> Type "apropos word"
Re: [go-nuts] CGO core dump analysis using GDB
Hi Ian, Thanks for your active help. When I run the program by using gdb, I am getting the complete stack. No issue. The issue is there when we debug core dump. Could you kindly please check whether you are seeing the same behavior with core dump? Best Regards Mariappan On Sat, 7 Jan, 2023, 7:03 am Ian Lance Taylor, wrote: > On Fri, Jan 6, 2023 at 5:28 PM mariappan balraj > wrote: > > > > I am not expecting GO stack. I am interested only in getting C stack. If > I want go stack, I can use delve debugger to get it. From GO, using CGO, > test3() is called which is calling test2() which is calling test1(). I am > expecting only C stack which contains test3(), test2(), test1(). In this > particular case assigning value by using pointer variable which contains > NULL(segmentation fault). I am seeing only test1(). After that it is not > stack and saying stack corruption. I strongly believe that you can help on > this. Please help. > > I put your program in foo.go. Then I did: > > > CGO_CFLAGS=-g go build foo.go > > gdb ./foo > GNU gdb (Debian 12.1-3) 12.1 > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ./foo... > warning: File "/home/iant/go/src/runtime/runtime-gdb.py" auto-loading > has been declined by your `auto-load safe-path' set to > "$debugdir:$datadir/auto-load". > To enable execution of this file add > add-auto-load-safe-path /home/iant/go/src/runtime/runtime-gdb.py > line to your configuration file "/home/iant/.config/gdb/gdbinit". > To completely disable this security protection add > set auto-load safe-path / > line to your configuration file "/home/iant/.config/gdb/gdbinit". > For more information about this security protection see the > --Type for more, q to quit, c to continue without paging-- > "Auto-loading safe path" section in the GDB manual. E.g., run from the > shell: > info "(gdb)Auto-loading safe path" > (gdb) r > Starting program: /tmp/x/foo > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [New Thread 0x7fffd09ea640 (LWP 650585)] > [New Thread 0x7fffcbfff640 (LWP 650586)] > [New Thread 0x7fffcb7fe640 (LWP 650587)] > [New Thread 0x7fffcaffd640 (LWP 650588)] > [New Thread 0x7fffca7fc640 (LWP 650589)] > > Thread 1 "foo" received signal SIGSEGV, Segmentation fault. > 0x0045b01a in test1 () at /home/iant/foo.go:6 > 6*p = 30; > (gdb) where > #0 0x0045b01a in test1 () at /home/iant/foo.go:6 > #1 0x0045b02c in test2 () at /home/iant/foo.go:10 > #2 0x0045b038 in test3 () at /home/iant/foo.go:14 > #3 0x0045b054 in _cgo_3060c004c901_Cfunc_test3 (v=0xc64f70) > at /tmp/go-build/cgo-gcc-prolog:49 > #4 0x00456c64 in runtime.asmcgocall () > at /home/iant/go/src/runtime/asm_amd64.s:848 > #5 0x004e3460 in ?? () > #6 0x0001 in ?? () > #7 0x00c80500 in ?? () > #8 0x7fffe458 in ?? () > #9 0x00439225 in runtime.malg.func1 () > at /home/iant/go/src/runtime/proc.go:4227 > #10 0x00456aa9 in runtime.systemstack () > at /home/iant/go/src/runtime/asm_amd64.s:496 > #11 0x004596a5 in runtime.newproc (fn=0x1) at :1 > #12 0x004cc720 in runtime[scavenger] () > #13 0x0001 in ?? () > #14 0x004569a5 in runtime.mstart () > at /home/iant/go/src/runtime/asm_amd64.s:394 > #15 0x0045692f in runtime.rt0_go () > at /home/iant/go/src/runtime/asm_amd64.s:358 > #16 0x0001 in ?? () > --Type for more, q to quit, c to continue without paging--q > Quit > > > > So when I try it, I do see the full C stack at the point where the > signal occurs. > > In your backtrace earlier you are trying to see the stack after the > signal is already being handled by the Go signal handler. I don't > know why that would work. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKKWi6TaVDmb%3Dz%2BjM0%3DRqyz0OAiJV1j6q97_N3pwbo89BOpdjA%40mail.gmail.com.
Re: [go-nuts] CGO core dump analysis using GDB
Hi Ian, I am not expecting GO stack. I am interested only in getting C stack. If I want go stack, I can use delve debugger to get it. From GO, using CGO, test3() is called which is calling test2() which is calling test1(). I am expecting only C stack which contains test3(), test2(), test1(). In this particular case assigning value by using pointer variable which contains NULL(segmentation fault). I am seeing only test1(). After that it is not stack and saying stack corruption. I strongly believe that you can help on this. Please help. Best regards Mariappan On Sat, 7 Jan, 2023, 12:12 am Ian Lance Taylor, wrote: > On Thu, Jan 5, 2023 at 10:39 PM mariappan balraj > wrote: > > > > When I call the same function from pure C code, I am able to get the > complete stack and it is not reporting that the stack is corrupted. I am > expecting the same C stack when I use CGO also. Please kindly help with > this. > > C code and Go code run on different stacks. As I tried to explain > earlier, gdb does not have enough information to unwind from a C stack > to a Go stack. > > What you are looking for simply doesn't work. Sorry. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKKWi6STx%2BXNYfG3srky_8YpnqOTaC62n6UzNr3C2s%3Dhds460Q%40mail.gmail.com.
Re: [go-nuts] CGO core dump analysis using GDB
Hi Ian,
When I call the same function from pure C code, I am able to get the
complete stack and it is not reporting that the stack is corrupted. I am
expecting the same C stack when I use CGO also. Please kindly help with
this.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x559e2af8813d in test1 () at test.c:6
6 *p = 30;
(gdb) bt
#0 0x559e2af8813d in test1 () at test.c:6
#1 0x559e2af88153 in test2 () at test.c:11
#2 0x559e2af88163 in test3 () at test.c:15
#3 0x559e2af88173 in main () at test.c:19
#include
#include
void test1(void) {
int *p = (int*)NULL;
*p = 30;
//assert(1 == 2);
}
void test2(void) {
test1();
}
void test3(void) {
test2();
}
int main(void) {
test3();
}
Best Regards
Mariappan
On Fri, Jan 6, 2023 at 11:42 AM mariappan balraj
wrote:
> Hi Ian,
>
> Thanks for your quick reply. I have now tried setting the CGO_CFLAGS to
> -g. Now I am seeing the following BT. It is reporting "corrupt stack".
>
> (gdb) bt
> #0 runtime.raise () at /usr/local/go/src/runtime/sys_linux_amd64.s:159
> #1 0x00443345 in runtime.dieFromSignal (sig=6) at
> /usr/local/go/src/runtime/signal_unix.go:870
> #2 0x004438de in runtime.sigfwdgo (sig=6, info=,
> ctx=, ~r0=)
> at /usr/local/go/src/runtime/signal_unix.go:1086
> #3 0x00442027 in runtime.sigtrampgo (sig=0, info=0x0,
> ctx=0x4583c1 ) at
> /usr/local/go/src/runtime/signal_unix.go:432
> #4 0x004586a6 in runtime.sigtramp () at
> /usr/local/go/src/runtime/sys_linux_amd64.s:359
> #5
> #6 runtime.raise () at /usr/local/go/src/runtime/sys_linux_amd64.s:159
> #7 0x00443345 in runtime.dieFromSignal (sig=6) at
> /usr/local/go/src/runtime/signal_unix.go:870
> #8 0x00443558 in runtime.crash () at
> /usr/local/go/src/runtime/signal_unix.go:962
> #9 0x0042f891 in runtime.fatalthrow.func1 () at
> /usr/local/go/src/runtime/panic.go:1129
> #10 0x0042f80c in runtime.fatalthrow (t=) at
> /usr/local/go/src/runtime/panic.go:1122
> #11 0x0042f4bd in runtime.throw (s=...) at
> /usr/local/go/src/runtime/panic.go:1047
> #12 0x00443289 in runtime.sigpanic () at
> /usr/local/go/src/runtime/signal_unix.go:819
> #13 0x0045abe6 in test1 () at
> /home/ubuntu/mbalraj/GO/TEST/test.go:9
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> root@nvme-tcp:/home/ubuntu/mbalraj/GO/TEST# go env
> GO111MODULE=""
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/root/.cache/go-build"
> GOENV="/root/.config/go/env"
> GOEXE=""
> GOEXPERIMENT=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOINSECURE=""
> GOMODCACHE="/root/go/pkg/mod"
> GONOPROXY=""
> GONOSUMDB=""
> GOOS="linux"
> GOPATH="/root/go"
> GOPRIVATE=""
> GOPROXY="https://proxy.golang.org,direct;
> GOROOT="/usr/local/go"
> GOSUMDB="sum.golang.org"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
> GOVCS=""
> GOVERSION="go1.19.4"
> GCCGO="gccgo"
> GOAMD64="v1"
> AR="ar"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD="/home/ubuntu/mbalraj/GO/TEST/go.mod"
> GOWORK=""
> CGO_CFLAGS="-g"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build1125623398=/tmp/go-build
> -gno-record-gcc-switches"
>
> Best Regards
> Mariappan
>
> On Fri, Jan 6, 2023 at 11:29 AM Ian Lance Taylor wrote:
>
>> On Thu, Jan 5, 2023 at 9:02 PM mariappan balraj
>> wrote:
>> >
>> > Thanks for your reply. This point is clear. I am interested only in
>> getting the complete C call stack only. I could able to get the GO stack by
>> using the delve debugger.
>> >
>> > When I use the GDB, I am getting the following stack. In the stack I am
>> seeing the last C function called which test1(). But I am not seeing
>> test2() and test3() in the stack. In GO code, test3() is called. These
>> details are very important when we want to debug the issues from production.
>> >
>> > I am eagerly waiting for the solution. It really helps others also.
>> Kindly please help on this.
>>
>> Please include plain text as plain text, not in colors with a
>> background. Plain text
Re: [go-nuts] CGO core dump analysis using GDB
Hi Ian, Thanks for your quick reply. I have now tried setting the CGO_CFLAGS to -g. Now I am seeing the following BT. It is reporting "corrupt stack". (gdb) bt #0 runtime.raise () at /usr/local/go/src/runtime/sys_linux_amd64.s:159 #1 0x00443345 in runtime.dieFromSignal (sig=6) at /usr/local/go/src/runtime/signal_unix.go:870 #2 0x004438de in runtime.sigfwdgo (sig=6, info=, ctx=, ~r0=) at /usr/local/go/src/runtime/signal_unix.go:1086 #3 0x00442027 in runtime.sigtrampgo (sig=0, info=0x0, ctx=0x4583c1 ) at /usr/local/go/src/runtime/signal_unix.go:432 #4 0x004586a6 in runtime.sigtramp () at /usr/local/go/src/runtime/sys_linux_amd64.s:359 #5 #6 runtime.raise () at /usr/local/go/src/runtime/sys_linux_amd64.s:159 #7 0x00443345 in runtime.dieFromSignal (sig=6) at /usr/local/go/src/runtime/signal_unix.go:870 #8 0x00443558 in runtime.crash () at /usr/local/go/src/runtime/signal_unix.go:962 #9 0x0042f891 in runtime.fatalthrow.func1 () at /usr/local/go/src/runtime/panic.go:1129 #10 0x0042f80c in runtime.fatalthrow (t=) at /usr/local/go/src/runtime/panic.go:1122 #11 0x0042f4bd in runtime.throw (s=...) at /usr/local/go/src/runtime/panic.go:1047 #12 0x00443289 in runtime.sigpanic () at /usr/local/go/src/runtime/signal_unix.go:819 #13 0x0045abe6 in test1 () at /home/ubuntu/mbalraj/GO/TEST/test.go:9 Backtrace stopped: previous frame inner to this frame (corrupt stack?) root@nvme-tcp:/home/ubuntu/mbalraj/GO/TEST# go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/root/.cache/go-build" GOENV="/root/.config/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/root/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/root/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct; GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GOVCS="" GOVERSION="go1.19.4" GCCGO="gccgo" GOAMD64="v1" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/ubuntu/mbalraj/GO/TEST/go.mod" GOWORK="" CGO_CFLAGS="-g" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1125623398=/tmp/go-build -gno-record-gcc-switches" Best Regards Mariappan On Fri, Jan 6, 2023 at 11:29 AM Ian Lance Taylor wrote: > On Thu, Jan 5, 2023 at 9:02 PM mariappan balraj > wrote: > > > > Thanks for your reply. This point is clear. I am interested only in > getting the complete C call stack only. I could able to get the GO stack by > using the delve debugger. > > > > When I use the GDB, I am getting the following stack. In the stack I am > seeing the last C function called which test1(). But I am not seeing > test2() and test3() in the stack. In GO code, test3() is called. These > details are very important when we want to debug the issues from production. > > > > I am eagerly waiting for the solution. It really helps others also. > Kindly please help on this. > > Please include plain text as plain text, not in colors with a > background. Plain text is much easier to read in e-mail. Thanks. > > I expect that you are only seeing test1 because the C code is compiled > with optimization and all the functions are inlined. Try building > with `CGO_CFLAGS=-g` set in the environment. > > Ian > > > > > > (gdb) thread apply all bt > > > > Thread 3 (Thread 0x7f2d70694740 (LWP 182930)): > > > > #0 runtime.usleep () at /usr/local/go/src/runtime/sys_linux_amd64.s:140 > > > > #1 0x00448fd8 in runtime.sighandler (sig=6, info= out>, ctxt=, gp=0xc061a0) at > /usr/local/go/src/runtime/signal_unix.go:789 > > > > #2 0x004484a5 in runtime.sigtrampgo (sig=6, info=0xc0fbf0, > ctx=0xc0fac0) at /usr/local/go/src/runtime/signal_unix.go:479 > > > > #3 0x0045fba6 in runtime.sigtramp () at > /usr/local/go/src/runtime/sys_linux_amd64.s:359 > > > > #4 > > > > #5 0x7f2d7072da7c in pthread_kill () from > /lib/x86_64-linux-gnu/libc.so.6 > > > > #6 0x7f2d706d9476 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > > > > #7 0x7f2d706bf7f3 in abort () from /lib/x86_64-linux-gnu/libc.so.6 > > > > #8 0x7f2d706bf71b in ?? () from /lib/x86_
Re: [go-nuts] CGO core dump analysis using GDB
Hi Ian, Thanks for your reply. This point is clear. I am interested only in getting the complete C call stack only. I could able to get the GO stack by using the delve debugger. When I use the GDB, I am getting the following stack. In the stack I am seeing the last C function called which test1(). But I am not seeing test2() and test3() in the stack. In GO code, test3() is called. These details are very important when we want to debug the issues from production. I am eagerly waiting for the solution. It really helps others also. Kindly please help on this. (gdb) thread apply all bt Thread 3 (Thread 0x7f2d70694740 (LWP 182930)): #0 runtime.usleep () at /usr/local/go/src/runtime/sys_linux_amd64.s:140 #1 0x00448fd8 in runtime.sighandler (sig=6, info=, ctxt=, gp=0xc061a0) at /usr/local/go/src/runtime/signal_unix.go:789 #2 0x004484a5 in runtime.sigtrampgo (sig=6, info=0xc0fbf0, ctx=0xc0fac0) at /usr/local/go/src/runtime/signal_unix.go:479 #3 0x0045fba6 in runtime.sigtramp () at /usr/local/go/src/runtime/sys_linux_amd64.s:359 #4 #5 0x7f2d7072da7c in pthread_kill () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x7f2d706d9476 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x7f2d706bf7f3 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #8 0x7f2d706bf71b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #9 0x7f2d706d0e96 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 *#10 0x00462be7 in test1 () at /home/ubuntu/mbalraj/GO/TEST/test.go:10* #11 0x0045dce4 in runtime.asmcgocall () at /usr/local/go/src/runtime/asm_amd64.s:844 #12 0x004dd620 in ?? () #13 0x0001 in ?? () #14 0x00c80a00 in ?? () #15 0x0a007ffebe0a3b28 in ?? () #16 0x0001 in ?? () #17 0x00f8 in ?? () #18 0x00c061a0 in ?? () #19 0x00c58ae0 in ?? () #20 0x0045db29 in runtime.systemstack () at /usr/local/go/src/runtime/asm_amd64.s:492 #21 0x004604e5 in runtime.newproc (fn=0x1) at :1 #22 0x004c57c0 in runtime[scavenger] () #23 0x0001 in ?? () #24 0x0045da25 in runtime.mstart () at /usr/local/go/src/runtime/asm_amd64.s:390 #25 0x0045d9af in runtime.rt0_go () at /usr/local/go/src/runtime/asm_amd64.s:354 #26 0x0001 in ?? () #27 0x7ffebe0a3ca8 in ?? () #28 0x in ?? () By using dlv, I am seeing the following GO stack. (dlv) goroutine 1 bt 0 0x0045f85d in runtime.usleep at /usr/local/go/src/runtime/sys_linux_amd64.s:140 1 0x0045dac0 in runtime.systemstack_switch at /usr/local/go/src/runtime/asm_amd64.s:459 2 0x00404c4a in runtime.cgocall at /usr/local/go/src/runtime/cgocall.go:168 *3 0x00462b45 in main._Cfunc_test3* * at _cgo_gotypes.go:41* 4 0x00462b97 in main.main at ./test.go:24 5 0x00437458 in runtime.main at /usr/local/go/src/runtime/proc.go:250 6 0x0045dfe1 in runtime.goexit at /usr/local/go/src/runtime/asm_amd64.s:1594 My GDB version is gdb --version *GNU gdb (GDB) 12.1* go version go1.19.4 linux/amd64 Best Regards Mariappan On Fri, Jan 6, 2023 at 1:12 AM Ian Lance Taylor wrote: > On Thu, Dec 22, 2022 at 1:57 PM mariappan balraj > wrote: > > > > I have following programming where making CGO from GO code. test3() is > called from Go code. Which calls test2() and which calls test1(). In > test1(), there is a NULL pointer assignment. I could able to generate the > core dump when running the program. But when I use gdb, I am not getting > the stack trace. Can someone please help? > > The call from Go to C switches stacks. The Go runtime doesn't provide > enough information for gdb to be able to unwind past that stack > switch. gdb can show the stack trace of the C function calls, but not > the stack trace of the Go functions. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKKWi6TZENNMRTA0dsu4js42SeLMYvr80HXZvGWYDpcLQ6LjzQ%40mail.gmail.com.
[go-nuts] Re: CGO core dump analysis using GDB
Hello Go Experts,
Can someone please help on this? When we invoke CGO and there is a crash in
C code, is it possible to get the complete C stack details to debug the
problem? I am not seeing much information regarding this.
Best Regards
Mariappan
On Friday, December 23, 2022 at 3:27:51 AM UTC+5:30 mariappan balraj wrote:
> Hi,
>
> I have following programming where making CGO from GO code. test3() is
> called from Go code. Which calls test2() and which calls test1(). In
> test1(), there is a NULL pointer assignment. I could able to generate the
> core dump when running the program. But when I use gdb, I am not getting
> the stack trace. Can someone please help?
>
> package main
>
> /*
>
> void test1(void) {
>
>int *p = (int*)NULL;
>
>*p = 30;
>
> }
>
>
> void test2(void) {
>
> test1();
>
> }
>
>
> void test3(void) {
>
> test2();
>
> }
>
> */
>
> import "C"
>
>
> func main() {
>
> C.test3();
>
> }
>
> Best Regards
>
> Mariappan
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/f4c9c45e-3847-47f4-a664-23e684fcf1e9n%40googlegroups.com.
[go-nuts] CGO core dump analysis using GDB
Hi,
I have following programming where making CGO from GO code. test3() is
called from Go code. Which calls test2() and which calls test1(). In
test1(), there is a NULL pointer assignment. I could able to generate the
core dump when running the program. But when I use gdb, I am not getting
the stack trace. Can someone please help?
package main
/*
void test1(void) {
int *p = (int*)NULL;
*p = 30;
}
void test2(void) {
test1();
}
void test3(void) {
test2();
}
*/
import "C"
func main() {
C.test3();
}
Best Regards
Mariappan
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/ebf09be4-0b96-430e-8577-ee85f2c6cf88n%40googlegroups.com.
