Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/cgo: panic on type with bit fields #5242

Closed
gjemiller opened this issue Apr 8, 2013 · 10 comments
Closed

cmd/cgo: panic on type with bit fields #5242

gjemiller opened this issue Apr 8, 2013 · 10 comments

Comments

@gjemiller
Copy link

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.

Attempt to compile the following:
http://play.golang.org/p/VOH5glwcTB


What is the expected output?
Executable program

What do you see instead?
# command-line-arguments
panic: runtime error: integer divide by zero
[signal 0x8 code=0x1 addr=0x41d114 pc=0x41d114]

goroutine 1 [running]:
main.(*Package).structType(0xf84007e000, 0xf84008c180, 0xf8400d9190, 0xc, 0xf840062201,
...)
    /usr/local/go/src/cmd/cgo/out.go:201 +0xda9
main.(*Package).writeOutputFunc(0xf84007e000, 0xf8400d32c8, 0xf84008c180,
0xa732500000005, 0xf84008c180, ...)
    /usr/local/go/src/cmd/cgo/out.go:403 +0x218
main.(*Package).writeOutput(0xf84007e000, 0xf84006ac60, 0x7fff47f93a39,
0x6570797400000006, 0x2fffffffff, ...)
    /usr/local/go/src/cmd/cgo/out.go:381 +0x866
main.main()
    /usr/local/go/src/cmd/cgo/main.go:261 +0xe40

goroutine 2 [syscall]:
created by runtime.main
    /usr/local/go/src/pkg/runtime/proc.c:221


Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux

Which version are you using?  (run 'go version')
go version go1.0.3 (but confirmed crash on recent tip by minux)

Please provide any additional information below.
It seems that the alignment guessed by CGO for the struct with only bit fields in it is
0.  This is a problem if ever you are using a third party library that has types with
bit fields in it (even if you don't want to access those fields from your go code).
@minux
Copy link
Member

minux commented Apr 10, 2013

Comment 1:

fwiw, as Go doesn't have bitfields, you can't reference
C struct that contains bitfields in Go code, no matter
whether you actually access that field or not.

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

@davecheney
Copy link
Contributor

Comment 2:

@minux - what do you think the correct behavior is in this situation ? Should cgo reject
the program outright, or should we attempt to do our best in the hope if the struct is
not referenced directly in Go ?
https://golang.org/cl/10300043 is a possible solution for the former.

Labels changed: added go1.2maybe.

@minux
Copy link
Member

minux commented Jun 15, 2013

Comment 3:

i think we should reject a cgo program if it involves translating a C
structure with bitfields in it to a Go type.
but, what if the structure uses bitfields for alignment (e.g. only
use bitfields whose width is multiple of 8)?
i know some FreeBSD structures uses this trick which makes gccgo
fails to build (because gccgo also needs to translate C struct to
Go struct, and it refuses to do so if there is any bitfields in the
struct)

@robpike
Copy link
Contributor

robpike commented Aug 20, 2013

Comment 4:

Deferring to 1.3.

Labels changed: added go1.3maybe, removed go1.2maybe.

@robpike
Copy link
Contributor

robpike commented Aug 20, 2013

Comment 5:

Labels changed: removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 6:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 7:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@gopherbot
Copy link

Comment 9:

CL https://golang.org/cl/125120043 mentions this issue.

@ianlancetaylor
Copy link
Contributor

Comment 10:

This issue was closed by revision 31a996e.

Status changed to Fixed.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants