[go-nuts] Debugging memory leak when a GO process crashed

[mariappan balraj]

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] go build error in darwin: duplicate symbol

[Xie Zhenye]

Maybe cgo should build a single .o file for the same .c file.
On Tuesday, January 10, 2023 at 11:21:00 AM UTC+8 Xie Zhenye wrote:

> It's caused by github.com/lufia/iostat.
>
> Maybe two different dependencies used 'iostat'. 'iostat; used cgo, and 
> produced an object file from .c file for each dependency. Linker try to 
> link both .o file that cause the problem.
>
> On Tuesday, March 23, 2021 at 12:25:17 AM UTC+8 Ian Lance Taylor wrote:
>
>> On Mon, Mar 22, 2021 at 7:40 AM Alex  wrote:
>> >
>> > A package you import could be using cgo, you don't have to be using it 
>> directly.
>>
>> I'll add that I think that this must be what is happening, as you
>> could not get that error message in a program that doesn't use cgo
>> anywhere.
>>
>> 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/8e3a6ef9-6725-4748-98e7-c16fdf9a01e0n%40googlegroups.com.

Re: [go-nuts] go build error in darwin: duplicate symbol

[Xie Zhenye]

It's caused by github.com/lufia/iostat.

Maybe two different dependencies used 'iostat'. 'iostat; used cgo, and 
produced an object file from .c file for each dependency. Linker try to 
link both .o file that cause the problem.

On Tuesday, March 23, 2021 at 12:25:17 AM UTC+8 Ian Lance Taylor wrote:

> On Mon, Mar 22, 2021 at 7:40 AM Alex  wrote:
> >
> > A package you import could be using cgo, you don't have to be using it 
> directly.
>
> I'll add that I think that this must be what is happening, as you
> could not get that error message in a program that doesn't use cgo
> anywhere.
>
> 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/406ae785-36bd-4bd4-881d-9bea5d62830en%40googlegroups.com.

[go-nuts] Re: Help Bootstrapping to ESXi

[Mike Schinkel]

Is your ESXi server not running an Intel x86 processor?  That is what the 
article is about.

Also, what OS is your guest VM running?  

-Mike

On Monday, January 9, 2023 at 4:20:15 PM UTC-5 brett@gmail.com wrote:

> Good afternoon, hoping to get a little help.
>
> I am trying to build a bootstrap candidate that allows me to build and run 
> go programs on an ESXi server.
>
> I am following this 
> 
>  blog, and the issue is that my bootstrap candidate doesn't contain the 
> go binary in the bin directory that is required when running all.bash.
>
> Any help would be greatly appreciated.
>

-- 
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/9fc7173f-fc01-4fcf-8ce4-a329011cdf75n%40googlegroups.com.

[go-nuts] Help Bootstrapping to ESXi

[Brett Bergner]

Good afternoon, hoping to get a little help.

I am trying to build a bootstrap candidate that allows me to build and run 
go programs on an ESXi server.

I am following this 

 blog, and the issue is that my bootstrap candidate doesn't contain the go 
binary in the bin directory that is required when running all.bash.

Any help would be greatly appreciated.

-- 
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/d55f6df6-4295-48f7-aaf4-c7d8d96fa5c5n%40googlegroups.com.

[go-nuts] Re: [Proposal] Error slot

[Oliver Smith]

"or main could be lazy and let `error<-` panic when err != nil:"

* would require that `action`'s signature be `func action() (string, 
error<-)`

On Monday, January 9, 2023 at 12:10:25 PM UTC-8 Oliver Smith wrote:

> A complete example (followed by the code it replaced):
>
> ```
> package main
>
> import (
> "fmt"
> "os"
> )
>
> func getMotd() (string, error<-) {
> motd, error<- := os.ReadFile("/etc/motd")
> return "MOTD:\n---\n" + string(motd) + "\n---\n", nil
> }
>
> func getPwd() (string, error<-) {
> pwd, error<- := os.Getwd()
> return "PWD:\n" + pwd + "\n", nil
> }
>
> func action() error {
> motd, error<- := getMotd()
> pwd,  error<- := getPwd()
>
> fmt.Println(motd, pwd)
>
> return nil
> }
>
> func main() {
> if err := action(); err != nil {
>   fmt.Printf("ERROR: %s\n", err)
> }
> }
> ```
> The Go Playground (golang.com) 
>
> or main could be lazy and let `error<-` panic when err != nil:
> ```
> func main() {
> action()
> }
> ```
>
> The current go code would be:
>
> ```
> package main
>
> import (
> "fmt"
> "os"
> )
>
> func getMotd() (string, error) {
> motd, err := os.ReadFile("/etc/motd")
> if err != nil {
> return "", err
> }
> return "MOTD:\n---\n" + string(motd) + "\n---\n", nil
> }
>
> func getPwd() (string, error) {
> pwd, err := os.Getwd()
> if err != nil {
> return "", err
> }
> return "PWD:\n" + pwd + "\n", nil
> }
>
> func action() error {
> motd, err := getMotd()
> if err != nil {
> return err
> }
> pwd,  err := getPwd()
> if err != nil {
> return err
> }
>
> fmt.Println(motd, pwd)
>
> return nil
> }
>
> func main() {
> if err := action(); err != nil {
>   fmt.Printf("ERROR: %s\n", err)
> }
> }
> ```
> https://play.golang.com/p/2_pk-FNv-dk
> On Tuesday, December 27, 2022 at 3:52:41 PM UTC-8 Oliver Smith wrote:
>
>> Discussing implementations of the (returns..., error) idiom from golang 
>> in other languages, I noted a common thing: non-go developers often 
>> conceptualized this as a back channel and didn't intuit that it's just a 
>> return-value convention.
>>
>> This lead me to a new idea for addressing the excess verbosity of the 
>> majority of trivial error handling in golang,
>> that is primarily just an additional reflection tag for functions and a 
>> mechanism to leverage that from calling
>> sites.
>>
>> The error slot, written `error<-`.
>>
>> As a return type, it is just the type `error` but tags the function as 
>> having return field N be recognized as the error slot.
>> ```
>> func ReadFile1(filename string) ([]byte, bool, error)
>> // *can* optionally be written
>> func ReadFile2(filename string) ([]byte, bool, error<-)
>> ```
>>
>> - Actual type is just 'error',
>> - One per function,
>> - Position doesn't matter,
>> - Named/anoymous,
>> - reflection gains a method that gives -1 for no error slot otherwise >= 
>> 0 denoting which return field is official error slot,
>> - parsing: very context-specific cases, potentially even a dedicated 
>> token/symbol,
>>
>> Beyond syntax support, this requires no compatibility breaking changes, 
>> but one such break IS proposed:
>>
>> - Failing to forward/capture the error slot of a method in a function 
>> without an error slot be a compile error,
>>
>> ```
>> // slotted
>> func AnError() error<- { return io.EOF }
>>
>> // old code, unslotted
>> func OldError() error { return io.EOF }
>>
>> // old code, unslotted
>> func OldFunction() error  {
>>   OldError()  // valid as currently
>>
>>   AnError()   // compile error suggesting `_ = AnError()`
>>
>>   _ = AnError()  // valid but vet warned
>>
>>   return AnError()  // valid
>> }
>> ```
>>
>> Second, a change to provide an implicit nil-or-return shorthand: replace 
>> the field's capture on the left side with "error<-".
>>
>> ```
>> func Old() (int, error, bool, error)// Who knows
>> func New() (int, error<-, bool, error)  // They have their reasons
>>
>> func Caller() (err error<-) {   // Must be slotted to use new 
>> syntax.
>>   // Old code is still absolutely valid.
>>   if i, e1, b, e2 := Old(); e1 != nil {
>> return e1
>>   }
>>
>>   // Also still absolutely valid.
>>   if i, e1, b, e2 := New(); e1 != nil {
>> return e2
>>   }
>>
>>   // Because Old doesn't specify which is a slot, we can use either:
>>   _, error<-, _, _ = Old()
>>   // aka: if _, err, _, _ = Old(); err != nil { return }
>>
>>   _, _, _, error<- = Old()
>>   // aka: if _, _, _, err = Old(); err != nil { return }
>>
>>   // Slotted functions are constrained to the error slot return tho.
>>   _, error<-, _, _ = New()  // valid
>>   // _, _, _, error<- = New()  // invalid, slot mismatch
>> }
>> ```
>>
>> A final benefit of marking your function slotted is that if you fail to 
>> capture a call slot yourself, it introduces an implicit panic
>>
>> ```
>> func Panicy() error<- 

[go-nuts] Re: [Proposal] Error slot

[Oliver Smith]

A complete example (followed by the code it replaced):

```
package main

import (
"fmt"
"os"
)

func getMotd() (string, error<-) {
motd, error<- := os.ReadFile("/etc/motd")
return "MOTD:\n---\n" + string(motd) + "\n---\n", nil
}

func getPwd() (string, error<-) {
pwd, error<- := os.Getwd()
return "PWD:\n" + pwd + "\n", nil
}

func action() error {
motd, error<- := getMotd()
pwd,  error<- := getPwd()

fmt.Println(motd, pwd)

return nil
}

func main() {
if err := action(); err != nil {
  fmt.Printf("ERROR: %s\n", err)
}
}
```
The Go Playground (golang.com) 

or main could be lazy and let `error<-` panic when err != nil:
```
func main() {
action()
}
```

The current go code would be:

```
package main

import (
"fmt"
"os"
)

func getMotd() (string, error) {
motd, err := os.ReadFile("/etc/motd")
if err != nil {
return "", err
}
return "MOTD:\n---\n" + string(motd) + "\n---\n", nil
}

func getPwd() (string, error) {
pwd, err := os.Getwd()
if err != nil {
return "", err
}
return "PWD:\n" + pwd + "\n", nil
}

func action() error {
motd, err := getMotd()
if err != nil {
return err
}
pwd,  err := getPwd()
if err != nil {
return err
}

fmt.Println(motd, pwd)

return nil
}

func main() {
if err := action(); err != nil {
  fmt.Printf("ERROR: %s\n", err)
}
}
```
https://play.golang.com/p/2_pk-FNv-dk
On Tuesday, December 27, 2022 at 3:52:41 PM UTC-8 Oliver Smith wrote:

> Discussing implementations of the (returns..., error) idiom from golang in 
> other languages, I noted a common thing: non-go developers often 
> conceptualized this as a back channel and didn't intuit that it's just a 
> return-value convention.
>
> This lead me to a new idea for addressing the excess verbosity of the 
> majority of trivial error handling in golang,
> that is primarily just an additional reflection tag for functions and a 
> mechanism to leverage that from calling
> sites.
>
> The error slot, written `error<-`.
>
> As a return type, it is just the type `error` but tags the function as 
> having return field N be recognized as the error slot.
> ```
> func ReadFile1(filename string) ([]byte, bool, error)
> // *can* optionally be written
> func ReadFile2(filename string) ([]byte, bool, error<-)
> ```
>
> - Actual type is just 'error',
> - One per function,
> - Position doesn't matter,
> - Named/anoymous,
> - reflection gains a method that gives -1 for no error slot otherwise >= 0 
> denoting which return field is official error slot,
> - parsing: very context-specific cases, potentially even a dedicated 
> token/symbol,
>
> Beyond syntax support, this requires no compatibility breaking changes, 
> but one such break IS proposed:
>
> - Failing to forward/capture the error slot of a method in a function 
> without an error slot be a compile error,
>
> ```
> // slotted
> func AnError() error<- { return io.EOF }
>
> // old code, unslotted
> func OldError() error { return io.EOF }
>
> // old code, unslotted
> func OldFunction() error  {
>   OldError()  // valid as currently
>
>   AnError()   // compile error suggesting `_ = AnError()`
>
>   _ = AnError()  // valid but vet warned
>
>   return AnError()  // valid
> }
> ```
>
> Second, a change to provide an implicit nil-or-return shorthand: replace 
> the field's capture on the left side with "error<-".
>
> ```
> func Old() (int, error, bool, error)// Who knows
> func New() (int, error<-, bool, error)  // They have their reasons
>
> func Caller() (err error<-) {   // Must be slotted to use new 
> syntax.
>   // Old code is still absolutely valid.
>   if i, e1, b, e2 := Old(); e1 != nil {
> return e1
>   }
>
>   // Also still absolutely valid.
>   if i, e1, b, e2 := New(); e1 != nil {
> return e2
>   }
>
>   // Because Old doesn't specify which is a slot, we can use either:
>   _, error<-, _, _ = Old()
>   // aka: if _, err, _, _ = Old(); err != nil { return }
>
>   _, _, _, error<- = Old()
>   // aka: if _, _, _, err = Old(); err != nil { return }
>
>   // Slotted functions are constrained to the error slot return tho.
>   _, error<-, _, _ = New()  // valid
>   // _, _, _, error<- = New()  // invalid, slot mismatch
> }
> ```
>
> A final benefit of marking your function slotted is that if you fail to 
> capture a call slot yourself, it introduces an implicit panic
>
> ```
> func Panicy() error<- {
>   Old()   // no change
>   New()   // if new's error slot != nil, panics. vet warning.
> }
> ```
>
> Some of the people I discussed this with immediately went to method 
> chaining, but I think the above change actually already
> brings that approach to a more beautiful middle ground:
>
>
> A couple folks asked me about chaining: Special-case a method returning 
> one value and an error slot:
>
> ```
> func OpenFile(name string) (*File, error<-)
> func (f *File) 

[go-nuts] Re: Naive Bayesian Classifier for Golang

[Johan Liebert]

Naive Bayes classifiers are *a collection of classification algorithms 
based on Bayes' Theorem*. It is not a single algorithm but a family of 
algorithms where all of them share a common principle, i.e. every pair of 
features being classified is independent of each other.
Regards: Rarest philodendron 

On Thursday, November 24, 2011 at 9:22:35 AM UTC-8 Jake Brukhman wrote:

> Hey Dmitry, thanks for the resources, I'll look into implementing one
> of these methods.
>
>
> On Nov 24, 6:50 am, Dmitry Chestnykh  wrote:
> > On Wednesday, November 23, 2011 5:41:07 PM UTC+1, Jake wrote:
> >
> > > In terms of functionality, do you recommend going to float64, then?
> >
> > This would help a bit until you underflow float64 :-)
> >
> > Here are some resources:
> >
>
> > 1.https://en.wikipedia.org/wiki/Bayesian_spam_filtering#Other_expressio.
> ..
> > 2.http://nlp.stanford.edu/IR-book/html/htmledition/naive-bayes-text-cla.
> ..
> > 3.http://stackoverflow.com/questions/2691021/problem-with-precision-flo.
> ..
> >
> > -Dmitry
>

-- 
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/660d00b2-101c-4535-93e4-1e96627030e7n%40googlegroups.com.

[go-nuts] Alternative text/template function libraries to github.com/Masterminds/sprig?

[Tom Payne]

github.com/Masterminds/sprig is a popular library of template functions,
used by some popular projects, e.g. Kubernetes Helm.

Unfortunately, Masterminds/sprig also has a number of inherent flaws:
1. The order of arguments to many of its functions is incompatible with
text/template's pipeline syntax.
2. Many of its functions do not handle strings, []bytes, variable numbers
of arguments, and other argument variations in a sensible way.
3. It has, at the time of writing, 78 open issues
, most of them unaddressed,
and has seen only minor maintenance activity over the last few years.
4. Its function names do not follow Go's naming conventions.

#1 and #2 cannot be fixed in a backwards-compatible way. #3 means that
fixes aren't practically accepted anyway. #4 just means that templates
using Masterminds/sprig are ugly to Go developer eyes.

Instead, I want a library of template functions that works well with
text/template, has decent ergonomics, follows Go's naming conventions, and
is actively maintained. I don't care about backwards compatibility with
sprig as this is impossible to achieve anyway.

Before I start such a project, are there any existing good existing
alternatives to Masterminds/sprig?

Many thanks,
Tom

-- 
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/CAHY_QbTxDH_h4f1_o3DFg-9Jv-VfCwPGW4V%3DBFfCYNaf3A2jAA%40mail.gmail.com.

Re: [go-nuts] Generic array and slice type options

[Daniel Theophanes]

Thank you Ian.

On Sun, Jan 8, 2023 at 10:40 PM Ian Lance Taylor  wrote:

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

Re: [go-nuts] CGO core dump analysis using GDB

[Tamás Gulácsi]

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

Re: [go-nuts] CGO core dump analysis using GDB

[mariappan balraj]

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