Hi Ian, I used the latest Go version(not gotip) and get the right signal, but now I had another question the stack backtrace correct or not. And I think it's related to Go and had posted a new issue here: https://github.com/golang/go/issues/63277. Thanks.
zzkcode 在2023年9月27日星期三 UTC+8 13:24:56<zzk819...@gmail.com> 写道： > Hi Ian, > > Sorry for missing the mail list, just reply it via my phone and didn't > notice that. > > For the question, it seem not our case from what you saying, so I assume > it's ok and will try this if gotip fix the issue. > > To be clear, what we are using is: > 1. Goroutine 1 call into C on Thread A, switch stack, running, save stack > and then return to Go. > > 2. Do network io(during this process it may have runtime scheduling > involved, so next time goroutine 1 may running on Thread B.) > > 3. Network IO done, goroutine 1 into C on thread B. And thread B will > switch back to the stack which saved in step1. > > So this is the case that thread may change, but all in Go side(control by > go runtime), I think it should be OK then? Thanks. > > zzkcode > > ---Original--- > *From:* "Ian Lance Taylor"<ia...@golang.org> > *Date:* Wed, Sep 27, 2023 11:40 AM > *To:* "zzk819...@gmail.com"<zzk819...@gmail.com>; > *Subject:* Re: [go-nuts] Golang+CGO using ucontext crash(on purpose) with > SIGSEGV or SIGTRAP while using different stacks > > On Tue, Sep 26, 2023 at 7:30 PM zzk819...@gmail.com > wrote: > > > > > Hi Ian, thanks for your attention, it really looks like this is what I'm > > looking for since in our case we are also switching stacks in c code. Will > > give a try later tonight or tomorrow. > > > > > One more question here(maybe I'll post it on the github issue too), from > > what you comment here: > https://github.com/golang/go/issues/62130#issuecomment-1712330693 > , it seems like if there are different threads in different time call into c > and switching stack, the fix is still not working? In our real application, > it may change thread every time call into C wihtin one request tranaction. > LockOSThread is just not working in our case since it would significantly > increase the OS threads numbers. Thanks. > > Please reply to the mailing list, not just to me. Thanks. > > I think the case that may fail is: > > - Go code calls C code on thread T1 > - Thread T1 saves stack A and starts running a different C coroutine B > > - A different C thread T2 picks up coroutine A and starts using its stack > - Thread T2 returns to Go > > > If that happens, I think the Go code may get confused. I'm not sure, though. > > Ian > > > > ---Original--- > > From: "Ian Lance Taylor" > > Date: Tue, Sep 26, 2023 11:28 AM > > To: "zk Z"; > > Cc: "golang-nuts"; > > > Subject: Re: [go-nuts] Golang+CGO using ucontext crash(on purpose) with > > SIGSEGV or SIGTRAP while using different stacks > > > > > On Sat, Sep 23, 2023 at 10:32 PM zk Z wrote: > > > > > > > I'm currently writing a Golang + CGO program, and will use posix ucontext > > > in CGO. Since all my core logic will be in the bind function of ucontext, > > > we should catch up all the bad code. And I test it by accessing to the > > > null pointer, which give me totally different behaviors that all > > > depending on the stack location which ucontext used. Here are more > > > details with simplified example. > > > > > > > If I allocate the ucontext stack on the thread's stack, it will trigger > > > SIGSEGV. But if I allocate it on the heap, it will first trigger SIGSEGV, > > > and then SIGTRAP while calling `morestack_noctxt` before calling into > > > `runtime.sigpanic`. How can I fix this or how can I just get SIGSEGV? Why > > > it need morestack? > > > > > > > Here is my guess, but seems not correct: when I used the malloc stack, it > > > was treat as it has stack overflow, and should more stack, but end up > > > find it's g0, then fatal. But it seems the goroutine's stack is much more > > > lower address than thread's stack? > > > > This looks related to https://go.dev/issue/62130, which is partially > > fixed on tip. Perhaps you could try tip to see what happens? > > > > 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/ebfb32a6-3056-4947-8b8a-127b8bdc91dbn%40googlegroups.com.
