[go-nuts] Re: Getting panic: proto: extension number 1042 is already registered on message google.protobuf.FileOptions

[Kevin Chowski]

Please provide some more information about what you are trying to do, and 
how to reproduce your problem from scratch. Otherwise it will be hard to 
provide you any help at all. For example, what code are you using? What 
commands are you running? What goal are you trying to accomplish in the 
first place?

On Sunday, December 24, 2023 at 11:07:07 PM UTC-5 Roopan M wrote:

> Hi Team,
>
> When I try to run the docker compose up, getting the below issue for one 
> of the container related to proto buf extension.
>
> Please help to resolve,
>
>
>
>
>
>
>
>
>
>
>
>
>
> *service-cms-1| panic: proto: extension number 1042 is already 
> registered on message google.protobuf.FileOptionsservice-cms-1| See 
> https://protobuf.dev/reference/go/faq#namespace-conflict 
> service-cms-1 
>|service-cms-1|service-cms-1| goroutine 1 
> [running]:service-cms-1| 
> google.golang.org/protobuf/reflect/protoregistry.glob..func1({0x23c0160 
> ?,
>  
> 0xc000467e20?}, {0x23c0160?, 0xc000467e20})service-cms-1| 
>  
> /builder/grpc/vendor/google.golang.org/protobuf/reflect/protoregistry/registry.go:56
>  
>  
> +0x1eeservice-cms-1| 
> google.golang.org/protobuf/reflect/protoregistry.(*Types).RegisterExtension(0xc00011a6f0
>  
> ,
>  
> {0x23f1cb0, 0x32e1920})service-cms-1| 
>  
> /builder/grpc/vendor/google.golang.org/protobuf/reflect/protoregistry/registry.go:554
>  
>  
> +0x2efservice-cms-1| 
> github.com/golang/protobuf/proto.RegisterExtension(.. 
> .)service-cms-1 
>| 
>  /builder/grpc/vendor/github.com/golang/protobuf/proto/registry.go:279 
> service-cms-1 
>| 
> github.com/grpc-ecosystem/grpc-gateway/protoc-gen-swagger/options.init.0() 
> service-cms-1
>  
>| 
>  
> /builder/grpc/vendor/github.com/grpc-ecosystem/grpc-gateway/protoc-gen-swagger/options/annotations.pb.go:70
>  
> 
>  
> +0x32*
>

-- 
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/b769d8bb-375e-46c7-8566-378d9cbdab16n%40googlegroups.com.

Re: [go-nuts] Re: A global panic handler for crash reporting

[Gergely Brautigam]

Yah, that's true, I completely forgot about that. :/

I guess you could do what some others have done which is implement a Call 
function or a framework that runs all function calls in a middleware-esk 
style. And middleware has a recovery. So every call will have a recovery.

On Tuesday 26 December 2023 at 10:15:12 UTC+1 Jan Mercl wrote:

> On Tue, Dec 26, 2023 at 9:12 AM Gergely Brautigam  
> wrote:
>
> > If you have a top level recover in you main, it doesn't matter where the 
> panic happens, you'll capture it. Even in third party library.
>
> Iff the panic occurs in the same goroutine where the defer is. Every
> go statement starts a new goroutine that is not affected by defer
> statement(s) in other goroutines.
>

-- 
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/754f1577-8578-454e-97ac-eb6a91b79986n%40googlegroups.com.

Re: [go-nuts] Re: A global panic handler for crash reporting

[Jan Mercl]

On Tue, Dec 26, 2023 at 9:12 AM Gergely Brautigam  wrote:

> If you have a top level recover in you main, it doesn't matter where the 
> panic happens, you'll capture it. Even in third party library.

Iff the panic occurs in the same goroutine where the defer is. Every
go statement starts a new goroutine that is not affected by defer
statement(s) in other goroutines.

-- 
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/CAA40n-V3eEVdouxr-uLiTvQSqNxmBSTCdpofUJ9rfFpDKB7Gpw%40mail.gmail.com.

[go-nuts] Re: A global panic handler for crash reporting

[Gergely Brautigam]

If you have a top level recover in you main, it doesn't matter where the 
panic happens, you'll capture it. Even in third party library.

package main

import (
"fmt"

"github.com/Skarlso/panic"
)

func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered in f", r)
}
}()
fmt.Println("testing")
panic.MakePanic("testing this now")
}

This will output:

go run main.go
testing
Recovered in f testing this now

Is that what you're looking for?
On Monday 25 December 2023 at 12:04:04 UTC+1 Nikolay Bryskin wrote:

> Hey, Alan. I'm relatively new to Go, and faced a similar issue - I writing 
> tests for a legacy codebase and want to fail the test if the tested code 
> panics somewhere inside.
> Almost ten years passed - did you find or create a solution?
>
> On Tuesday, June 17, 2014 at 6:01:49 AM UTC+3 Alan Shreve wrote:
>
>> I’d like to do crash-reporting for programs that run in environments I 
>> don’t control (e.g. your laptop). The behavior I want is similar to what 
>> many production-grade desktop applications do when they crash: capture 
>> process state information, optionally prompt the user for permission, and 
>> send the crash report to a secure server. 
>>
>> How one would implement such a function for Go programs is tricky without 
>> cooperation from the runtime. The options I’m considering: 
>>
>> 1. The strawman is to wrap every goroutine that I spawn with a function 
>> that defers and calls the panic handler. It would have no effect on third 
>> party libraries which spawn goroutines (or the standard library) which 
>> makes it pretty much a non-starter. It’s also extremely onerous and 
>> unidiomatic to write all of your code this way. 
>>
>> 2. Automate the above behavior by parsing all of the Go code (including 
>> 3rd party libs) to rewrite all statements which spawn goroutines to wrap 
>> each goroutine with a panic handler. It’s messy, adds another stage to my 
>> build process, but could work well for all of my code and 3rd party code 
>> and possibly for the 
>>
>> 3. Set GOTRACEBACK=crash and then use the operating-system native 
>> interfaces to recover the state of the program. This is a lot of work. This 
>> interface is defined differently on each OS. Recovering the state from 
>> these crash handlers would be challenging because it would happen outside 
>> the runtime and the existing tools for this like google’s breakpad are 
>> built for C applications. A minor point, but also GOTRACEBACK=crash isn’t 
>> implemented on some OS’s yet (notably Windows). 
>>
>> 4. Fork immediately after startup and use the parent process to monitor 
>> the child for exit code 2 and a panic traceback on stderr. This is the 
>> approach taken by panicwrap[0] which is known to work, but has two issues. 
>> Dealing with signals becomes especially tricky. Any number of supervisor 
>> programs and system administration tools rely on sending signals to 
>> manipulate processes in production. The crash-handling parent process would 
>> need to handle these signals appropriately. Should it forward them to the 
>> children? Or rely on the signaling process to signal the whole process 
>> tree? Signal handling behavior is not consistent across platforms, which 
>> makes this difficult to get right. For example, Windows apparently sends 
>> CTRL+BREAK to the whole tree, but not CTRL+C. As a final point, this 
>> approach also fails on systems that disallow spawning additional processes 
>> (NaCl, maybe AppEngine, I’m unsure). 
>>
>> 5. Fork immediately after startup and dup stderr through to the child 
>> process. This avoids all of the signal handling conundrums of approach #4 
>> but does mean that you can no longer check the exit status of the program 
>> and would have to fall back just to looking for the ‘panic:’ header only. 
>> Still doesn’t work if you can’t spawn processes. 
>>
>> 6. I’d like to modify the Go runtime to simply add an API which allows a 
>> developer to intercept runtime panics and choose how to handle them. 
>> Ideally, I would like to do this with an API like: 
>>
>> runtime.OnPanic(func(state *ProcessState) { 
>> // send to crash report server 
>> }) 
>>
>> I’d even settle for: 
>>
>> runtime.OnPanic(func () { 
>> // send to crash report server 
>> runtime.Stack() 
>> }) 
>>
>> What is the best option among these? Would this be an API the Go team 
>> would consider adding to the language? 
>>
>> [0] github.com/mitchellh/panicwrap
>
>

-- 
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/b38c45da-7411-433a-98f0-0b57f41990b3n%40googlegroups.com.