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

Crash on Pm_Write #31

Open
briansorahan opened this issue Jan 15, 2017 · 10 comments
Open

Crash on Pm_Write #31

briansorahan opened this issue Jan 15, 2017 · 10 comments

Comments

@briansorahan
Copy link
Contributor

i see this fairly regularly on linux (via the launchpad package) but haven't yet figured out how to reproduce

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x2 addr=0x7ff50c021000 pc=0x7ff51ce5ff46]

runtime stack:
runtime.throw(0x631c1f, 0x2a)
        /usr/lib/go/src/runtime/panic.go:566 +0x95
runtime.sigpanic()
        /usr/lib/go/src/runtime/sigpanic_unix.go:12 +0x2cc

goroutine 35 [syscall, locked to thread]:
runtime.cgocall(0x5bd000, 0xc420216c78, 0x0)
        /usr/lib/go/src/runtime/cgocall.go:131 +0x110 fp=0xc420216c30 sp=0xc420216bf0
github.com/scgolang/beats/vendor/github.com/rakyll/portmidi._Cfunc_Pm_Write(0x7ff50c000bf0, 0xc42016e4a0, 0x1, 0x0)
        ??:0 +0x4d fp=0xc420216c78 sp=0xc420216c30
github.com/scgolang/beats/vendor/github.com/rakyll/portmidi.(*Stream).Write(0xc4201fc4d0, 0xc420216cf8, 0x1, 0x1, 0x0, 0x0)
        /home/brian/go/src/github.com/scgolang/beats/vendor/github.com/rakyll/portmidi/stream.go:121 +0x11d fp=0xc420216cc8 sp=0xc420216c78
github.com/scgolang/beats/vendor/github.com/rakyll/portmidi.(*Stream).WriteShort(0xc4201fc4d0, 0x90, 0x54, 0xc, 0x0, 0x0)
        /home/brian/go/src/github.com/scgolang/beats/vendor/github.com/rakyll/portmidi/stream.go:132 +0x9b fp=0xc420216d28 sp=0xc420216cc8
@kisielk
Copy link
Collaborator

kisielk commented Jan 15, 2017

Can you try running the code with theGODEBUG=cgocheck=2 environment variable set?

@briansorahan
Copy link
Contributor Author

@kisielk Tried that and got the same error.

@kisielk
Copy link
Collaborator

kisielk commented Jan 15, 2017

Okay, but you didn't get any messages from the Go runtime? Also, which version of Go are you using?

@briansorahan
Copy link
Contributor Author

go version go1.7.4 linux/amd64

Didn't notice any extra messages from the Go runtime.

@briansorahan
Copy link
Contributor Author

Also here is pacman -Qi portmidi

Name            : portmidi
Version         : 217-5
Description     : Platform independent library for real-time MIDI input/output
Architecture    : x86_64
URL             : http://portmedia.sourceforge.net/
Licenses        : GPL
Groups          : None
Provides        : None
Depends On      : alsa-lib
Optional Deps   : java-runtime: for using pmdefaults
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 154.00 KiB
Packager        : Eric Belanger <eric@archlinux.org>
Build Date      : Sat 26 Oct 2013 12:14:09 PM CDT
Install Date    : Sat 14 Jan 2017 04:26:42 PM CST
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

@briansorahan
Copy link
Contributor Author

Reviewing the cgo docs it says that the GODEBUG checks are sidestepped by code that uses package unsafe, and the code that is crashing in this case does use unsafe. I wonder if it's possible to not use unsafe?

@briansorahan
Copy link
Contributor Author

Looks like we have to use unsafe.Pointer since PortMidiStream is void

@briansorahan
Copy link
Contributor Author

FWIW I started playing with an alternative midi implementation https://github.com/scgolang/midi seems pretty stable on linux so far, haven't used it on mac much yet

@kisielk
Copy link
Collaborator

kisielk commented Feb 16, 2017

@briansorahan cool, I will check it out. One thing I'm struggling with in PortMIDI is to have an efficient way to have channels for incoming MIDI events implemented in an efficient way, preferably without polling. Seems like using ALSA might solve that.

@briansorahan
Copy link
Contributor Author

@kisielk Writing that package has been interesting so far. The linux part took me maybe two hours and resulted in a beautiful tiny interface which basically just had Open, Read, Write, and Close. Read would block until I sent data from the device, which seemed just perfect to me since consumers of the package can easily type go to make it nonblocking.
Wrapping coremidi caused me to rewrite the linux code though because in order to get data from the device you register a callback.
So now I return a channel for reading in both the linux and darwin code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants