Re: [go-nuts] Re: Random panic in production with Sprintf
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 > 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 > wrote: > >> > >> On Thu, May 2, 2019 at 6:02 PM XXX ZZZ > 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 > wrote: > >> >> > > >> >> > On Thu, May 2, 2019 at 2:50 PM Anthony Martin > wrote: > >> >> > > > >> >> > > What version of Go are you using? > >> >> > > > >> >> > > XXX ZZZ once said: > >> >> > > > fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076) > >> >> > > > /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 (0xc00076) 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 0xc00076 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 > >> >> > 0xc0 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 . > >> > 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
Re: [go-nuts] Re: Random panic in production with Sprintf
On Thu, May 2, 2019 at 6:34 PM Tyler Compton 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 wrote: >> >> On Thu, May 2, 2019 at 6:02 PM XXX ZZZ 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 wrote: >> >> > >> >> > On Thu, May 2, 2019 at 2:50 PM Anthony Martin wrote: >> >> > > >> >> > > What version of Go are you using? >> >> > > >> >> > > XXX ZZZ once said: >> >> > > > fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076) >> >> > > > /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 (0xc00076) 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 0xc00076 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 >> >> > 0xc0 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.
Re: [go-nuts] Re: Random panic in production with Sprintf
Whenever I see fast* I think someone took shortcuts to make something “faster” without fully implementing the spec (or external constraints, like safe data access) > On May 2, 2019, at 7:16 PM, Burak Serdar wrote: > >> On Thu, May 2, 2019 at 6:02 PM XXX ZZZ 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 wrote: > On Thu, May 2, 2019 at 2:50 PM Anthony Martin wrote: > > What version of Go are you using? > > XXX ZZZ once said: >> fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076) >>/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 (0xc00076) 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 0xc00076 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 0xc0 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.
Re: [go-nuts] Re: Random panic in production with Sprintf
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 On Thu, May 2, 2019 at 5:16 PM Burak Serdar wrote: > On Thu, May 2, 2019 at 6:02 PM XXX ZZZ 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 > wrote: > >> > > >> > On Thu, May 2, 2019 at 2:50 PM Anthony Martin > wrote: > >> > > > >> > > What version of Go are you using? > >> > > > >> > > XXX ZZZ once said: > >> > > > fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076) > >> > > > /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 (0xc00076) 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 0xc00076 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 > >> > 0xc0 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.
Re: [go-nuts] Re: Random panic in production with Sprintf
On Thu, May 2, 2019 at 6:02 PM XXX ZZZ 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 wrote: >> > >> > On Thu, May 2, 2019 at 2:50 PM Anthony Martin wrote: >> > > >> > > What version of Go are you using? >> > > >> > > XXX ZZZ once said: >> > > > fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076) >> > > > /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 (0xc00076) 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 0xc00076 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 >> > 0xc0 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.
Re: [go-nuts] Re: Random panic in production with Sprintf
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. 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 > wrote: > > > > On Thu, May 2, 2019 at 2:50 PM Anthony Martin > wrote: > > > > > > What version of Go are you using? > > > > > > XXX ZZZ > once said: > > > > fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076) > > > > /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 (0xc00076) 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 0xc00076 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 > > 0xc0 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.
Re: [go-nuts] Re: Random panic in production with Sprintf
On Thu, May 2, 2019 at 3:56 PM Ian Lance Taylor wrote: > > On Thu, May 2, 2019 at 2:50 PM Anthony Martin wrote: > > > > What version of Go are you using? > > > > XXX ZZZ once said: > > > fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076) > > > /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 (0xc00076) 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 0xc00076 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 > 0xc0 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 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.
Re: [go-nuts] Re: Random panic in production with Sprintf
Is any of this string data touched/from C via CGO? On Thu, May 2, 2019 at 3:09 PM Anthony Martin wrote: > Ian Lance Taylor once said: > > 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. > > Misled by the pair of fives. Mea culpa. > > Anthony > > -- > 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. > -- *Michael T. jonesmichael.jo...@gmail.com * -- 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.
Re: [go-nuts] Re: Random panic in production with Sprintf
Ian Lance Taylor once said: > 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. Misled by the pair of fives. Mea culpa. Anthony -- 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.
Re: [go-nuts] Re: Random panic in production with Sprintf
On Thu, May 2, 2019 at 2:50 PM Anthony Martin wrote: > > What version of Go are you using? > > XXX ZZZ once said: > > fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076) > > /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 (0xc00076) 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 0xc00076 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 0xc0 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. 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. For more options, visit https://groups.google.com/d/optout.
