cmd/cgo: godefs intermittently panics in go/printer #6040
Labels
Comments
The crash trace shows the printer printing a StarExpr with no operand (x.X == nil). That cannot happen in the ASTs that cgo -godefs generates. It suggests a garbage collection problem. If you run it 10 or 100 times in a row, how often does it crash? If you export GOGC=off does the crash probability change? If you export GOGC=1 does the crash probability change? for i in $(seq 100); do go tool cgo -godefs x.go >/dev/null 2>/dev/null || echo BAD $i; done I cannot reproduce the crash with a similar input file on OS X. I don't have FreeBSD at hand. I'd like to track this down but I am not 100% sure it will happen for Go 1.2. Leaving as Go1.2Maybe for now. |
For the record I'm using go version go1.1.2 freebsd/amd64.
It happens ~85% of the time invariant of the GOGC setting:
$ export GOGC=1; for ((i=0; i<100; i++)); do go tool cgo -godefs
types_freebsd.go>/dev/null 2>/dev/null || echo BAD $i; done|wc -l
85
$ export GOGC=off; for ((i=0; i<100; i++)); do go tool cgo -godefs
types_freebsd.go>/dev/null 2>/dev/null || echo BAD $i; done|wc -l
87
$ export GOGC=100; for ((i=0; i<100; i++)); do go tool cgo -godefs
types_freebsd.go>/dev/null 2>/dev/null || echo BAD $i; done|wc -l
84
|
Hi couchmo.... I think this might be a duplicate of issue #8368, which was fixed by revision 0015a25415455c390ae135bef7de2d5e2b10ee88. I'd appreciate if you could repeat your testing against Go tip and let me know if you're still able to reproduce the intermittent panics. If so, it would be helpful if you could attach the output of running "gcc -E" against your Cgo preamble so we can try to reproduce the issue on non-FreeBSD. Also if you could try to minimize the test case. I'd suspect the root cause was the LIST_HEAD/LIST_ENTRY macros. |
Starting from revision 52e26bb34741, I was able to reproduce a very similar stack trace
by running "go tool cgo -godefs issue6040.go" on linux/amd64 using the below Go snippet.
I can also reproduce the issue immediately before revision 0015a254, but not at or
after.
So I believe this issue is now fixed.
package issue6040
/*
typedef struct one one;
typedef struct two two;
typedef struct three three;
struct one {
two *x;
three *y;
};
struct two {
one *x;
three *y;
};
struct three {
one *x;
two *y;
};
*/
import "C"
type One C.one
type Two C.two
type Three C.three
|
wathiede
added
fixed
Suggested
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: