Re: [go-nuts] CGO core dump analysis using GDB
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/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
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 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
Re: [go-nuts] Generic array and slice type options
On Sun, Jan 8, 2023 at 1:17 PM Daniel Theophanes wrote:
>
> When playing around with generics, I ran into what I perceive as an odd
> limitation.
>
> I forked an audio package "beep" to do some fun generics with it.
> https://github.com/kardianos/beep/blob/master/interface.go
>
> I was trying to use the following interfaces:
>
> type Point[S Size] interface {
> // NOTE: Uncommenting the next line will result in errors.
>// [1]S | [2]S
>[2]S
> }
>
> type Size interface {
>float64 | float32
> }
>
> I was thinking I could change the internal data structure from float64 or
> float32. This part works. I was thinking I could change the internal data
> structure from one channel to two with [1]S | [2]S. Now I realize this
> probably isn't a great idea to begin with, but hear me out...
>
> When I try to change to a union between len 1 array to len 2 array:
> 1. I cannot compile any access to point[1] even if behind a len(point) guard.
> 2. "for range point" appears to stop working at all, though I feel like it
> should still work, as it would work on either data type.
>
> I fully get why this is probably not a good serious approach, but more then
> anything, could someone help me with the why of the compiler errors? The
> specific error is "(P has no core type)".
Well, that error is why. In the current spec and implementation,
certain operations are only available if the type parameter has a
"core type". See https://go.dev/ref/spec#Core_types . I believe that
over time we can move toward a more flexible spec and implementation
that doesn't rely on that concept, but doing that will require
defining the notion of a dependent type--a type that depends on a type
parameter.
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/CAOyqgcVoz-8hSan4gJ-59zuXYwH465O21gPu0jBg680Ftufzzg%40mail.gmail.com.
[go-nuts] Generic array and slice type options
When playing around with generics, I ran into what I perceive as an odd
limitation.
I forked an audio package "beep" to do some fun generics with it.
https://github.com/kardianos/beep/blob/master/interface.go
I was trying to use the following interfaces:
type Point[S Size] interface {
// NOTE: Uncommenting the next line will result in errors.
// [1]S | [2]S
[2]S
}
type Size interface {
float64 | float32
}
I was thinking I could change the internal data structure from float64 or
float32. This part works. I was thinking I could change the internal data
structure from one channel to two with [1]S | [2]S. Now I realize this
probably isn't a great idea to begin with, but hear me out...
When I try to change to a union between len 1 array to len 2 array:
1. I cannot compile any access to point[1] even if behind a len(point)
guard.
2. "for range point" appears to stop working at all, though I feel like it
should still work, as it would work on either data type.
I fully get why this is probably not a good serious approach, but more then
anything, could someone help me with the why of the compiler errors? The
specific error is "(P has no core type)".
Thank you,
-Daniel
--
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/1c54e3be-8ba9-4991-9051-5946f2e3b495n%40googlegroups.com.
