On Thu, May 2, 2019 at 6:34 PM Tyler Compton <xavi...@gmail.com> 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 <bser...@ieee.org> wrote: >> >> On Thu, May 2, 2019 at 6:02 PM XXX ZZZ <emartinez1...@gmail.com> 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 golang-nuts+unsubscr...@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 golang-nuts+unsubscr...@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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
