nil pointer panic with no stacktrace

[Tamás Gulácsi]

Line 93
Use a.u and a.a, not array

[Istvan Bak]

Changed it, tried it out, still panics. Updated the gist. I'm not really sure how the suggestion would have helped, though.

[Tad Glines]

It works fine on my system.

What OS/ARCH and go version are you using?

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Istvan Bak]

archlinux, 386, Go 1.1

But if I cross-compile to amd64 (on this same pc) and try it out on the ubuntu amd64 box right next to me, then it runs without problems, no runtime panic. I presume you also tried it with an am64 box?

Okay, so, on one arch the stack gets corrupted (according to gdb), and on an another, it runs okay. Can someone smarter than me make the conclusion about the root of this problem?

[Vova Niki]

got the crash too in windows 7 386.

the crash happens on the swap if you will change it to

func (s runeSlice) Swap(i, j int) {

s[i], s[j] = s[j], s[i]

}

it wont crash, for me atleast.

On Saturday, May 18, 2013 3:50:25 PM UTC+3, Istvan Bak wrote:

Hello there,

I have small go program with a bug in it, and I can't figure out what the problem is. It might be a runtime or compiler bug, though I highly doubt it. I'm posting it to the mailing list, just to be sure that the bug is in my code, if someone could help me diagnose it. I apologize if something similar has already been discussed/diagnosed on the list, but without being able to pinpoint anything of the nature of the bug, I can't really search for it.

The program counts all the unique runes in a file and prints out the occurence count, sorted according to the count. I would have trimmed the program down to the bare essentials to demonstrate the bug, but every time I remove something, the bug disappears also.

The program crashes at line 73, when a slice of runes is passed to sort.Sort(). The panic message says "invalid memory address or nil pointer dereference", but it doesn't print a stacktrace. I tried to prod the corpse with gdb, but neither did that give me any useful info. Then again, in gdb, when I print the value of the runeslice, it prints weird stuff for the address of the underlying array, or sometimes for the len field of the slice.

Okay, so summary questions:

-why does the code panic?

-why is there no stacktrace?

-why does gdb print out weird stuff when examining the runeslice at uniqc:71 ?

src and some debug output:

https://gist.github.com/paperwing/5604265

[Dan Kortschak]

Can you post a complete runable sample on play.golang.org? Replace the file with an io.Reader and provide the input in the code - use a strings.Reader wrapping a string of failing data for example.

On 19/05/2013, at 2:45 AM, "paperwing" <the.one...@gmail.com> wrote:

Hello there,

I have small go program with a bug in it, and I can't figure out what the problem is. It might be a runtime or compiler bug, though I highly doubt it. I'm posting it to the mailing list, just to be sure that the bug is in my code, if someone could help me diagnose it. I apologize if something similar has already been discussed/diagnosed on the list, but without being able to pinpoint anything of the nature of the bug, I can't really search for it.

The program counts all the unique runes in a file and prints out the occurence count, sorted according to the count. I would have trimmed the program down to the bare essentials to demonstrate the bug, but every time I remove something, the bug disappears also.

The program crashes at line 73, when a slice of runes is passed to sort.Sort(). The panic message says "invalid memory address or nil pointer dereference", but it doesn't print a stacktrace. I tried to prod the corpse with gdb, but neither did that give me any useful info. Then again, in gdb, when I print the value of the runeslice, it prints weird stuff for the address of the underlying array, or sometimes for the len field of the slice.

Okay, so summary questions:

-why does the code panic?

-why is there no stacktrace?

-why does gdb print out weird stuff when examining the runeslice at uniqc:71 ?

src and some debug output:

https://gist.github.com/paperwing/5604265

[Vova Niki]

http://play.golang.org/p/XPNFKHSWJZ

uncomment line 33 to stop the panic or use 

func (s runeSlice) Swap(i, j int) {

s[i], s[j] = s[j], s[i]

}

this is giving different panic though, 

panic: runtime error: call of nil func value

[signal 0xc0000005 code=0x0 addr=0x0 pc=0x0]

goroutine 1 [running]:

goroutine 2 [runnable]:

exit status 2

[Istvan Bak]

An in-memory Reader, that's a good idea. I don't know why I haven't thought of that.

Okay, here's the playground example:

http://play.golang.org/p/qKEBokzvAO

(I also updated the gist)

A couple of things to note:

1. Apparently the bug cannot be reproduced (with this program at least) on amd64 arch, and while I don't know for sure, I'd have to guess that the golang server runs on amd64.

2. The input isn't the culprit here, the bug is more related to some pointer being set to a weird value (just look at the debug outputs I posted; sometimes the slice len is 134546740, or the cap is 405037056, or the slice's underlying array ptr points to a function, apparently). It has little to do with what was read as input.

3. If I take out the runeslice and just decide not to sort it lexicographically, then there's no bug. But that's just covering up an open manhole with a big blanket - sure, I can sidestep it and pretend it's not there, but other people may still fall into it. Then again, my code isn't crucial at all, I don't give two bits whether it sorts or not, but the bug still exists; and I still need to be sure that the problem is indeed with my code, not the runtime or the compiler.

4. Vova Niki's code also panics ("call of nil func value") on my pc (386), and on the playground it doesn't. The golang/playground runs on an amd64, right?

[Dave Cheney]

Confirmed, this panics as you show on linux/386

% go run pan.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x1 pc=0x20]

goroutine 1 [running]:

goroutine 2 [runnable]:
exit status 2

but _not_ on linux/arm (also a 32bit platform).

Can you please raise a bug, make the prefix cmd/8g:

[Istvan Bak]

Done. I hope I didn't leave out anything important.
https://code.google.com/p/go/issues/detail?id=5515