[go-nuts] Re: strange stack trace when panic
When I run with -gcflags="-l", it works~ winlin$ go run -gcflags="-l" t.go panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x104bf82] goroutine 1 [running]: main.causedPanic() /Users/winlin/git/t.go:13 +0x2 main.run() /Users/winlin/git/t.go:7 +0x20 main.main() /Users/winlin/git/t.go:4 +0x20 exit status 2 The code is here: https://play.golang.org/p/MHKPG5uFFn It seems it's caused by inling. Thanks a lot! On Wednesday, June 7, 2017 at 4:25:35 PM UTC+8, Dave Cheney wrote: > > Try building your program with -gcflags="-l" to disable inlining. If that > restores the stacktrace, then it's inlining. The good news is this should > be fixed with Go 1.9 > > On Wednesday, 7 June 2017 16:37:26 UTC+10, winlin wrote: >> >> Hi, I'm confused by the stack trace when panic, and I have searched both >> in history topics and google. >> If I use panic, the stack is fine, code is >> https://play.golang.org/p/Yb7fYW9ro3 , output is: >> >> panic: Panic from user >> >> goroutine 1 [running]: >> >> main.causedPanic() >> >> /tmp/sandbox078566511/main.go:11 +0x60 >> >> main.run() >> >> /tmp/sandbox078566511/main.go:7 +0x20 >> >> main.main() >> >> /tmp/sandbox078566511/main.go:4 +0x20 >> >> >> But if there is a runtime panic, the stack is completely unreadable, code >> is https://play.golang.org/p/MHKPG5uFFn , output is: >> >> panic: runtime error: invalid memory address or nil pointer dereference >> >> goroutine 1 [running]: >> >> main.main() >> >> /tmp/sandbox277759147/main.go:4 +0x4 >> >> >> If I add a defer to the last function, the stack comes back, code is >> https://play.golang.org/p/V7qDdyt_4Z , output is: >> >> panic: runtime error: invalid memory address or nil pointer dereference >> >> goroutine 1 [running]: >> >> main.causedPanic() >> >> /tmp/sandbox416089181/main.go:13 +0x48 >> >> main.run() >> >> /tmp/sandbox416089181/main.go:7 +0x20 >> >> main.main() >> >> /tmp/sandbox416089181/main.go:4 +0x20 >> >> >> Why it's diferent when there is a empty defer? It confused me. >> >> -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] strange stack trace when panic
Hi, I'm confused by the stack trace when panic, and I have searched both in history topics and google. If I use panic, the stack is fine, code is https://play.golang.org/p/Yb7fYW9ro3 , output is: panic: Panic from user goroutine 1 [running]: main.causedPanic() /tmp/sandbox078566511/main.go:11 +0x60 main.run() /tmp/sandbox078566511/main.go:7 +0x20 main.main() /tmp/sandbox078566511/main.go:4 +0x20 But if there is a runtime panic, the stack is completely unreadable, code is https://play.golang.org/p/MHKPG5uFFn , output is: panic: runtime error: invalid memory address or nil pointer dereference goroutine 1 [running]: main.main() /tmp/sandbox277759147/main.go:4 +0x4 If I add a defer to the last function, the stack comes back, code is https://play.golang.org/p/V7qDdyt_4Z , output is: panic: runtime error: invalid memory address or nil pointer dereference goroutine 1 [running]: main.causedPanic() /tmp/sandbox416089181/main.go:13 +0x48 main.run() /tmp/sandbox416089181/main.go:7 +0x20 main.main() /tmp/sandbox416089181/main.go:4 +0x20 Why it's diferent when there is a empty defer? It confused me. -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: letsencrypt, localhost and autocert
There is a library base on lego and letsencrypt
project:
https://github.com/ossrs/go-oryx-lib/blob/master/https/example_test.go#L33
And there is a server as an example for that
library: https://github.com/ossrs/go-oryx/blob/develop/httpx-static/main.go#L174
On Wednesday, June 7, 2017 at 1:07:16 AM UTC+8, Sankar wrote:
>
> Hi
>
> I saw the tweet https://twitter.com/mholt6/status/848704744474292224 and
> decided to try out the code
>
> log.Fatal(http.Serve(autocert.NewListener("mydomain.com
>
[go-nuts] Re: A question about reading of TCP sockets.
1516, haha, are you writing a RTMP handshake?
The io.Reader is not promise always get the size data, you can use io.CopyN
or ReadBuffer.
For io.Writer of netFD, it always write all the data.
On Saturday, May 20, 2017 at 11:01:44 PM UTC+8, fusi.enr...@gmail.com wrote:
>
> Hello All
>
> first I apologize for my English, I'm not a native speaker.
> I have a question about how golang reads the sockets in tcp.
>
> Imagine I send , using a conn.Write(buffer), a buffer which has the
> (unpredictable) size from 80 Bytes to 1516.
>
> Now, if I do something like this (after creating "ln"):
>
> for {
>> message := make([]byte, 1516)
>> var err error
>> // accept connection on port
>> conn, _ := ln.Accept()
>> mytimeout := 1000
>> mytimeout, _ = strconv.Atoi(cf.GConfig["TimeOut"])
>> Gtimeout := time.Duration(mytimeout) * time.Millisecond
>> conn.SetReadDeadline(time.Now().Add(Gtimeout))
>>
>> _, err = conn.Read(message)
>> if err != nil {
>> conn.Close()
>> continue
>> }
>
> *messageinterpreter(message) // just do something with message*
>
> }
>
>
> what I am afraid is that , when the client is sending i.e 100 chars using
> conn.Write(100chars) , the conn.Read will not understand the size, and not
> stop until it has read 1516 bytes
>
> What is the expected behavior in such a case? I cannot serialize this
> content (which is binary) because I fear the impact of overhead.
>
>
> thanks in advance for any comment.
>
> EFM
>
>
>
>
>
>
--
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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Stop HTTP Server with Context cancel
Will this be OK?
func ListenAndServe(ctx context.Context, srv *http.Server) error {
ctx,cancel := context.WitchCancel(ctx)
wg := sync.WaitGroup{}
defer wg.Wait()
wg.Add(1)
go func(ctx context.Context) {
defer cancel()
err := srv.ListenAndServe()
fmt.Println("Server err is", err)
}(ctx)
select {
case <-ctx.Done():
srv.Close()
}
return ctx.Err()
}
When the http server error and quit, it will call the cancel to unblock the
select.
When the ctx is cancelled, it will call svr.Close() to unblock the server.
Does it works?
On Wednesday, April 5, 2017 at 2:02:16 AM UTC+8, Pierre Durand wrote:
>
> Hello
>
> I wrote a small helper to stop an HTTP Server when a Context is canceled.
> https://play.golang.org/p/Gl8APynVdh
>
> What do you think ?
> Is it OK to use context cancellation for stopping long running functions ?
>
--
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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Go 1.8.1 is released
Great work! On Saturday, April 8, 2017 at 2:02:49 AM UTC+8, Chris Broadfoot wrote: > > Hi gophers, > > We have just released Go version 1.8.1, a minor point release. > > This release includes fixes to the compiler, runtime, documentation, go > command, and the > crypto/tls, encoding/xml, image/png, net, net/http, reflect, > text/template, and time packages. > https://golang.org/doc/devel/release.html#go1.8.minor > > You can download binary and source distributions from the Go web site: > https://golang.org/dl/ > > To compile from source using a Git clone, update to the release with "git > checkout go1.8.1" and build as usual. > > Thanks to everyone who contributed to the release. > > Chris > -- 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. For more options, visit https://groups.google.com/d/optout.
