Are you using the fasthttp timeout handler? If its the case you could have a race condition once the timeout is triggered. Tiago
On Friday, May 3, 2019 at 5:23:58 AM UTC+1, Burak Serdar wrote: > > On Thu, May 2, 2019 at 6:34 PM Tyler Compton <xav...@gmail.com > <javascript:>> wrote: > > > > I took a quick look and yes, it uses unsafe to convert between byte > slices and strings. I don't know enough to say that it's the problem but > here's an example: > > > > > https://github.com/valyala/fasthttp/blob/645361952477dfc16938fb2993065130ed7c02b9/bytesconv.go#L380 > > > You could experiment by using that corrupt string with something > trivial, like calling strings.ToLower(r.Second_subid) before Sprintf > and see if that panics inside ToLower. And then you can add more > ToLower calls backtracking the stack to pinpoint where that string > gets corrupt. > > Or, you can just use the "slow" http, see if that works, and not look > back. > > > > > On Thu, May 2, 2019 at 5:16 PM Burak Serdar <bse...@ieee.org > <javascript:>> wrote: > >> > >> On Thu, May 2, 2019 at 6:02 PM XXX ZZZ <emarti...@gmail.com > <javascript:>> wrote: > >> > > >> > No use of C via CGO at all. > >> > > >> > Afaik, there isn't any unsafe use of the string, we are basically > reading it from a get parameter (fasthttp server) on an http request and > then adding it into this structure, most of the times is just a 5 char > string. Out of several millions requests, this panic happens. > >> > >> Does this "fasthttp" have any unsafe pointers? > >> > >> > >> > > >> > I failed to find any kind of race using go race detector, I'm > currently doing some more debugging, hopefuly I should have more info/tests > soon. > >> > > >> > El jueves, 2 de mayo de 2019, 20:44:33 (UTC-3), Burak Serdar > escribió: > >> >> > >> >> On Thu, May 2, 2019 at 3:56 PM Ian Lance Taylor <ia...@golang.org> > wrote: > >> >> > > >> >> > On Thu, May 2, 2019 at 2:50 PM Anthony Martin <al...@pbrane.org> > wrote: > >> >> > > > >> >> > > What version of Go are you using? > >> >> > > > >> >> > > XXX ZZZ <emarti...@gmail.com> once said: > >> >> > > > fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc000000076) > >> >> > > > /usr/local/go/src/fmt/print.go:448 +0x132 > >> >> > > > fmt.(*pp).printArg(0xc023c17740, 0x9978e0, 0xc016a68a30, 0x76) > >> >> > > > /usr/local/go/src/fmt/print.go:684 +0x880 > >> >> > > > fmt.(*pp).doPrintf(0xc023c17740, 0xa6e22f, 0x5, 0xc048c27818, > 0x1, 0x1) > >> >> > > > /usr/local/go/src/fmt/print.go:1112 +0x3ff > >> >> > > > fmt.Sprintf(0xa6e22f, 0x5, 0xc048c27818, 0x1, 0x1, 0x80, > 0xa36200) > >> >> > > > /usr/local/go/src/fmt/print.go:214 +0x66 > >> >> > > > >> >> > > This shows signs of memory corruption. The last argument passed > to > >> >> > > fmtString (0xc000000076) should be the same as the last argument > >> >> > > passed to printArg (0x76 or 'v') but it has some high bits set. > Also, > >> >> > > the pointer to the format string data changes from 0xa6e22f > (which is > >> >> > > probably in the .rodata section of the binary) to 0x0. > >> >> > > > >> >> > > Something is amiss. > >> >> > > >> >> > The change from 0x76 to 0xc000000076 does not necessarily indicate > a > >> >> > problem. The stack backtrace does not know the types. The value > here > >> >> > is a rune, which is 32 bits. The compiler will only set the low > order > >> >> > 32 bits on the stack, leaving the high order 32 bits unset. So > the > >> >> > 0xc000000000 could just be garbage left on the stack. > >> >> > > >> >> > I don't *think* the format string is changing. I think the 0 is > from > >> >> > the string being printed, not the format string. They both happen > to > >> >> > be length 5. > >> >> > >> >> There's something that doesn't make sense here. The 0 is from the > >> >> string being printed, it is not the format string. But how can that > >> >> be? > >> >> > >> >> Even if there is a race, the string cannot have a 0 for the slice, > can > >> >> it? So the other option is when Sprintf is called, the string being > >> >> printed is already corrupt. Can there be an overflow somewhere that > is > >> >> somehow undetected? Any unsafe use in the program? > >> >> > >> >> > >> >> > > >> >> > 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 golan...@googlegroups.com. > >> >> > For more options, visit https://groups.google.com/d/optout. > >> > > >> > -- > >> > 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 golan...@googlegroups.com <javascript:>. > >> > For more options, visit https://groups.google.com/d/optout. > >> > >> -- > >> 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 golan...@googlegroups.com <javascript:>. > >> For more options, visit https://groups.google.com/d/optout. > -- 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.
