Re: [go-nuts] Need help: Calling panic() is corrupting system stack

[mariappan balraj]

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

[Ian Lance Taylor]

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/CAOyqgcVEOhyBGBuq4R8GM%3D4cEknHTczwpYjj%2Bhm316WA6vyv-w%40mail.gmail.com.

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

[mariappan balraj]

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

[mariappan balraj]

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

[Kurtis Rader]

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/CABx2%3DD-_3MU6Z4gVUzG-XHmTbv8%3DOL5rAPTkSHrMyEV6cHPeYA%40mail.gmail.com.

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

[robert engels]

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.



-- 
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/9E0182AE-9759-4371-8DE8-2B837438F9B9%40ix.netcom.com.


test.out.txt
Description: application/applefile
On Apr 3, 2023, at 11:59 PM, mariappan balraj  wrote: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_panichttps://github.com/MariappanBalraj/test_cgo_panic.githttps://github.com/MariappanBalraj/test_cgo_panic/archive/refs/heads/main.zipBest RegardsMariappanOn 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 RegardsMariappanOn Sat, Apr 1, 2023 at 7:45 AM mariappan balraj  wrote:Hello Go experts,Could someone please help to resolve this issue?Best RegardsMariappanOn 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 :110  0x0045f3f4 in runtime.cgocallback    at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:99811  0x004641bd in crosscall2    at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgo/asm_amd64.s:3012  0x00464386 in C.Test4    at /tmp/go-build/_cgo_export.c:3313  0x00464432 in C.test1    at ./hello.go:914  0x0046444d in C.test2    at ./hello.go:1415  0x00464468 in C.test315  0x00464468 in C.test3    at ./hello.go:1916  0x004644a7 in C._cgo_78b81bbf688e_Cfunc_test3    at /tmp/go-build/cgo-gcc-prolog:4917  0x0045f2e4 in runtime.asmcgocall    at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:84818  0x0046448a in C._cgo_78b81bbf688e_Cfunc_test3    at /tmp/go-build/cgo-gcc-prolog:4419  0x00404f0a in runtime.cgocall    at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:16720  0x00464245 in main._Cfunc_test3    at _cgo_gotypes.go:3921  0x004642d7 in main.main    at ./hello.go:3322  0x00437073 in runtime.main    at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/proc.go:25023  0x0045f5e1 in runtime.goexit    at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:1598254 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 during329                 // 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: 

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

[Ian Lance Taylor]

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/CAOyqgcXKqtvRB1CHysZbjeC88pi_tt7LiS4RozWLsV5LHxAszw%40mail.gmail.com.

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

[mariappan balraj]

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 *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
>>>

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

[mariappan balraj]

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,
>>
>> Eagerly waiting for your help. Some further update.
>>
>> I have set a break point at line 

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

[Kurtis Rader]

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 
wrote:

> Hi Robert,
>
> Eagerly waiting for your help. Some further update.
>
> I have set a break point at line number 332 by using dlv, noted the value
> of shced.sp. Once line number 332 is executed, reset the value of  sched.sp
> by using set command in dlv. In this case, I am getting the proper 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)))
>
> Actual core file produces following stack trace:
>
>  0  0x00460ec1 in runtime.raise
> at
> /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/sys_linux_amd64.s:154
>  1  0x00449865 in runtime.dieFromSignal
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/signal_unix.go:879
>  2  0x00449e45 in runtime.sigfwdgo
> at
> /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/signal_unix.go:1092
>  3  0x004487c7 in runtime.sigtrampgo
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/signal_unix.go:432
>  4  0x00461186 in runtime.sigtramp
> at
> /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/sys_linux_amd64.s:352
>  5  0x7f9ab9b5f520 in ???
> at ?:-1
>  6  0x00449a78 in runtime.crash
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/signal_unix.go:971
>  7  0x00434da5 in runtime.fatalpanic
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:1168
>  8  0x004344ec in runtime.gopanic
> at /home/soomohan/mbalraj/GO/go1.20.2/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/go1.20.2/go/src/runtime/cgocall.go:315
> 12  0x00405079 in runtime.cgocallbackg
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:234
> 13  0x00461b0f in runtime.cgocallbackg
> at :1
> 14  0x0045f3f4 in runtime.cgocallback
> at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:998
> 15  0x0001 in ???
> 15  0x0001 in ???
> at ?:-1
> 16  0x00c3e000 in ???
> at ?:-1
> error: error while reading spliced memory at 0x8: EOF
>
> <<< By using DLV and setting break point
>
>  /root/go/bin/dlv exec ./test
> Type 'help' for list of commands.
> (dlv) break unwindm
> Breakpoint 1 set at 0x4054e6 for runtime.unwindm()
> /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:326
> (dlv) c
> > runtime.unwindm()
> /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:326 (hits
> goroutine(1):1 total:1) (PC: 0x4054e6)
> Warning: debugging optimized function
>321: // Do not unwind m->g0->sched.sp.
>322: // Our caller, cgocallback, will do that.
>323: restore = false
>324: }
>325:
> => 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 := 
>
> (dlv)
> > runtime.unwindm()
> /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:332 (PC:
> 0x40550d)
> Warning: debugging optimized function
>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 

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

[mariappan balraj]

Hi Robert,

Eagerly waiting for your help. Some further update.

I have set a break point at line number 332 by using dlv, noted the value
of shced.sp. Once line number 332 is executed, reset the value of  sched.sp
by using set command in dlv. In this case, I am getting the proper 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)))

Actual core file produces following stack trace:

 0  0x00460ec1 in runtime.raise
at
/home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/sys_linux_amd64.s:154
 1  0x00449865 in runtime.dieFromSignal
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/signal_unix.go:879
 2  0x00449e45 in runtime.sigfwdgo
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/signal_unix.go:1092
 3  0x004487c7 in runtime.sigtrampgo
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/signal_unix.go:432
 4  0x00461186 in runtime.sigtramp
at
/home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/sys_linux_amd64.s:352
 5  0x7f9ab9b5f520 in ???
at ?:-1
 6  0x00449a78 in runtime.crash
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/signal_unix.go:971
 7  0x00434da5 in runtime.fatalpanic
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/panic.go:1168
 8  0x004344ec in runtime.gopanic
at /home/soomohan/mbalraj/GO/go1.20.2/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/go1.20.2/go/src/runtime/cgocall.go:315
12  0x00405079 in runtime.cgocallbackg
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:234
13  0x00461b0f in runtime.cgocallbackg
at :1
14  0x0045f3f4 in runtime.cgocallback
at /home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/asm_amd64.s:998
15  0x0001 in ???
15  0x0001 in ???
at ?:-1
16  0x00c3e000 in ???
at ?:-1
error: error while reading spliced memory at 0x8: EOF

<<< By using DLV and setting break point

 /root/go/bin/dlv exec ./test
Type 'help' for list of commands.
(dlv) break unwindm
Breakpoint 1 set at 0x4054e6 for runtime.unwindm()
/home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:326
(dlv) c
> runtime.unwindm()
/home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:326 (hits
goroutine(1):1 total:1) (PC: 0x4054e6)
Warning: debugging optimized function
   321: // Do not unwind m->g0->sched.sp.
   322: // Our caller, cgocallback, will do that.
   323: restore = false
   324: }
   325:
=> 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 := 

(dlv)
> runtime.unwindm()
/home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:332 (PC:
0x40550d)
Warning: debugging optimized function
   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

(dlv) p %x mp.g0.sched.sp
7fffab8268a8

(dlv) n
> runtime.unwindm()
/home/soomohan/mbalraj/GO/go1.20.2/go/src/runtime/cgocall.go:339 (PC:
0x405529)
Warning: debugging optimized function
   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:
(dlv) p %x mp.g0.sched.sp
7fffab826a18

(dlv) set mp.g0.sched.sp=0x7fffab8268a8
(dlv)  p %x mp.g0.sched.sp
7fffab8268a8

(dlv) break  runtime.raise
Breakpoint 2 set at 0x460ea0 for runtime.raise()

Re: [go-nuts] Need help: Calling panic() is corrupting system stack

[Robert Engels]

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  
>> 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 
>>>  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 {
>>>