Ehy Kurtis, Ehy TheDiveO thanks for the answer. Yes English is not my native language and I try to be precise as best as I can with my capabilities, thanks a lot for the patience and the effort on your side to understand what I'm sayings. Now that I read your answer is a little bit clearer how to read this stack regarding on what is happening. Thanks a lot! I wasn't sure about the CMAC_resume since the stack report CMAC_resume + 501884 which mean the offset from the CMAC_resume symbol is 501884, do you still think even with this offset is somehow trustable? Thanks a lot
Il giorno lunedì 11 settembre 2023 alle 11:08:30 UTC+2 TheDiveO ha scritto: > CMAC_resume might be something from here, IIRC Darwin's OpenBSD anchestry: > https://man.openbsd.org/CMAC_Init.3 > > On Monday, September 11, 2023 at 8:17:44 AM UTC+2 Kurtis Rader wrote: > >> On Sun, Sep 10, 2023 at 10:41 PM Danilo bestbug <bestbug.c...@gmail.com> >> wrote: >> >>> Hey Robert, >>> The problem is not reproducible in our test env but it occours on final >>> user. To make thing thougher is not even an application we develop directly >>> but is from one of our reseller, so we don't have direct access to the rest >>> of the codebase. Again I want to stress the main point of my request of >>> help: if this behavior is caused by some corner case to have a GO runtime >>> as third party dependencies instead of be a complete executable I would >>> like to understand if we can do something better to avoid to have this >>> stacktrace that are meaningless to us. Otherwise if this is a correct >>> behavior from GO runtime, I think we still have a problem because usually >>> the GO stacktrace are pretty clear about what is happening (and hence what >>> to do to fix it) but not in this case. >>> >> >> When you say "instead of be a complete executable" that suggests to me >> that a plugin is being used. I realize that English is not your native >> language but precision is important for this type of issue. Even if a >> plugin is not being used everything you have written suggests the problem >> is with your FFI code. In particular, issue >> https://github.com/golang/go/issues/61632 implies that a FFI function >> named `CMAC_resume` is calling Go code that detects its stack has been >> corrupted. That causes the Go runtime to raise SIGABRT to crash the >> program. So what does `CMAC_resume` do? Also, in this type of situation if >> you can't arrange for a core dump to be generated it is going to be very >> difficult to do a root cause analysis. Especially if you can't instrument >> the Cgo code that is causing the problem with debugging logging statements. >> >> -- >> 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/484155ae-394f-4faa-8cb3-225b50ded854n%40googlegroups.com.
