[MacRuby] #876: EXC_BAD_ACCESS using IOBluetooth
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: MacRuby 0.7 Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- This is using MacRuby built from the SVN Head on 2010-08-21 (revision 4438). Program received signal: “EXC_BAD_ACCESS”. #0 0x00007fff80bbc5f0 in object_getClass () #1 0x00000001000ed2d3 in rb_objc_nsnumber2numeric () #2 0x00000001036ccce0 in ?? () #3 0x00007fff86c1ddd6 in -[IOBluetoothL2CAPChannel processIncomingData:] () #4 0x00007fff86c1c767 in -[IOBluetoothL2CAPChannel handleMachMessage:] () #5 0x00007fff820bf07f in __NSFireMachPort () #6 0x00007fff831b7bce in __CFMachPortPerform () #7 0x00007fff83190171 in __CFRunLoopRun () #8 0x00007fff8318e84f in CFRunLoopRunSpecific () #9 0x00007fff8766491a in RunCurrentEventLoopInMode () #10 0x00007fff8766471f in ReceiveNextEventCommon () #11 0x00007fff876645d8 in BlockUntilNextEventMatchingListInMode () #12 0x00007fff838ed29e in _DPSNextEvent () #13 0x00007fff838ecbed in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #14 0x00007fff838b28d3 in -[NSApplication run] () #15 0x00007fff838ab5f8 in NSApplicationMain () #16 0x00000001036c5dcd in ?? () #17 0x0000000100140c94 in rb_vm_dispatch () #18 0x00000001036c4260 in ?? () #19 0x00000001036c3a1b in ?? () #20 0x000000010014ec08 in rb_vm_run () #21 0x0000000100040650 in ruby_run_node () #22 0x000000010014f06d in macruby_main () #23 0x0000000100000efe in main (argc=1, argv=0x7fff5fbff640) -- Ticket URL: <http://www.macruby.org/trac/ticket/876> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: MacRuby 0.7 Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by matt.wizeman@…): Sorry for the poor formatting of the original... lets try again {{{ Program received signal: “EXC_BAD_ACCESS”. #0 0x00007fff80bbc5f0 in object_getClass () #1 0x00000001000ed2d3 in rb_objc_nsnumber2numeric () #2 0x00000001036ccce0 in ?? () #3 0x00007fff86c1ddd6 in -[IOBluetoothL2CAPChannel processIncomingData:] () #4 0x00007fff86c1c767 in -[IOBluetoothL2CAPChannel handleMachMessage:] () #5 0x00007fff820bf07f in __NSFireMachPort () #6 0x00007fff831b7bce in __CFMachPortPerform () #7 0x00007fff83190171 in __CFRunLoopRun () #8 0x00007fff8318e84f in CFRunLoopRunSpecific () #9 0x00007fff8766491a in RunCurrentEventLoopInMode () #10 0x00007fff8766471f in ReceiveNextEventCommon () #11 0x00007fff876645d8 in BlockUntilNextEventMatchingListInMode () #12 0x00007fff838ed29e in _DPSNextEvent () #13 0x00007fff838ecbed in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #14 0x00007fff838b28d3 in -[NSApplication run] () #15 0x00007fff838ab5f8 in NSApplicationMain () #16 0x00000001036c5dcd in ?? () #17 0x0000000100140c94 in rb_vm_dispatch () #18 0x00000001036c4260 in ?? () #19 0x00000001036c3a1b in ?? () #20 0x000000010014ec08 in rb_vm_run () #21 0x0000000100040650 in ruby_run_node () #22 0x000000010014f06d in macruby_main () #23 0x0000000100000efe in main (argc=1, argv=0x7fff5fbff640) }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:1> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: MacRuby 0.7 Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by lsansonetti@…): I suspect one of the Ruby callbacks is not registered in the runtime with the proper signature. But just from the backtrace it's hard to know which one. Do you happen to have a sample project (or even better, a standalone script) which reproduces the crash? If yes please attach it to this ticket :) -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:2> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: MacRuby 0.7 Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by matt.wizeman@…): So, the crash happens when I implement the following IOBluetooth delegate method and the framework tries to call it: {{{ - (void)l2capChannelData:(IOBluetoothL2CAPChannel*)l2capChannel data:(void *)dataPointer length:(size_t)dataLength; }}} I've attempted to create a sample for you that demonstrates the problem and have attached it to this issue. Inside you will find three xcode projects: DefectSample:: This is a simple cocoa framework project that will play the part of the Obj-c code trying to call the delegate. CocoaApp:: This is a simple cocoa application that registers itself as the delegate of the DefectSample framework and provides buttons to force the framework to call the delegate methods. MacRubyApp:: This is a macruby port of the CocoaApp. In order to run this, first build the DefectSample project then build and run the other two projects. When running CocoaApp, all of the buttons work fine and the delegate methods are called with no issues. When running MacRubyApp, four of the six buttons will cause the app to crash in exactly the same place that IOBluetooth is as shown in the stack trace from my previous comment. The two buttons that work in MacRubyApp are the delegate method that accepts an NSNumber and the delegate method that takes no arguments. I hope this gives you a good idea about what my problem might be. If not, I can try to work up a sample using the actual IOBluetooth framework but I fear that will be much harder for you to test with. Let me know. Thanks for your help. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:3> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Changes (by lsansonetti@…): * milestone: MacRuby 0.7 => Comment: I'm confused, the attached projects do not deal with IOBluetooth. You have a pure Objective-C framework (DefectSample) which exposes an informal protocol, you use it from MacRuby (MacRubyApp) and the methods are not registered with the proper signatures, which is normal since the pure Objective-C framework is not covered by a BridgeSupport file. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:4> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by lsansonetti@…): Could you tell us the IOBluetooth callbacks your MacRuby code is using? In the backtrace posted above, -[IOBluetoothL2CAPChannel processIncomingData:] calls a MacRuby method. It would be nice to know which one. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:5> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by lsansonetti@…): To locate the method, an easy way is to start your program in the Xcode debugger, then make the app crash. In the debugger prompt, ask for the backtrace (typing "bt"), then call the rb_symbolicate() functions on the ?? address. Given your backtrace: {{{ #0 0x00007fff80bbc5f0 in object_getClass () #1 0x00000001000ed2d3 in rb_objc_nsnumber2numeric () #2 0x00000001036ccce0 in ?? () #3 0x00007fff86c1ddd6 in -[IOBluetoothL2CAPChannel processIncomingData:] () #4 0x00007fff86c1c767 in -[IOBluetoothL2CAPChannel handleMachMessage:] () }}} You can type: {{{ (gdb) p rb_symbolicate(0x00000001036ccce0) }}] This should show you the Ruby file, line and name of the method. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:6> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by matt.wizeman@…): Sorry for the confusion on the attachment. I didn't want you to have to use an actual bluetooth device to try out the code, so I was attempting to demonstrate the problem without using IOBluetooth. The IOBluetooth callback that causes the crash is: {{{ - (void)l2capChannelData:(IOBluetoothL2CAPChannel*)l2capChannel data:(void *)dataPointer length:(size_t)dataLength; }}} which I've implemented in my ruby code as: {{{ def l2capChannelData l2capChannel, data:data, length:dataLength }}} At least I think this is the case because if I comment out that method the application no longer crashes. I tried to get the method name in the debugger as requested but didn't have any luck. I got: {{{ (gdb) bt #0 0x00007fff80bbc5f0 in object_getClass () #1 0x00000001000ed2d3 in rb_objc_nsnumber2numeric () #2 0x0000000103f09630 in ?? () #3 0x00007fff86c1ddd6 in -[IOBluetoothL2CAPChannel processIncomingData:] () #4 0x00007fff86c1c767 in -[IOBluetoothL2CAPChannel handleMachMessage:] () #5 0x00007fff820bf07f in __NSFireMachPort () #6 0x00007fff831b7bce in __CFMachPortPerform () #7 0x00007fff83190171 in __CFRunLoopRun () #8 0x00007fff8318e84f in CFRunLoopRunSpecific () #9 0x00007fff8766491a in RunCurrentEventLoopInMode () #10 0x00007fff8766471f in ReceiveNextEventCommon () #11 0x00007fff876645d8 in BlockUntilNextEventMatchingListInMode () #12 0x00007fff838ed29e in _DPSNextEvent () #13 0x00007fff838ecbed in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #14 0x00007fff838b28d3 in -[NSApplication run] () #15 0x00007fff838ab5f8 in NSApplicationMain () #16 0x0000000103f02dcd in ?? () #17 0x0000000100140c94 in rb_vm_dispatch () #18 0x0000000103f01260 in ?? () #19 0x0000000103f00a1b in ?? () #20 0x000000010014ec08 in rb_vm_run () #21 0x0000000100040650 in ruby_run_node () #22 0x000000010014f06d in macruby_main () #23 0x0000000100000efe in main (argc=1, argv=0x7fff5fbff640) (gdb) p rb_symbolicate(0x0000000103f09630) warning: Cancelling call - objc code on the current thread's stack makes this unsafe. warning: Canceling call as the ObjC runtime would deadlock. Unable to call function "rb_symbolicate" at 0x100147be0: no return type information available. To call this function anyway, you can cast the return type explicitly (e.g. 'print (float) fabs (3.0)') }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:7> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by lsansonetti@…): Oh, you might want to cast the call as void in the debugger. {{{ (gdb) p (void)rb_symbolicate(0x0000000103f09630) }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:8> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by lsansonetti@…): It looks like l2capChannelData:data:length: is properly annotated in the BridgeSupport file, so this is strange. Could you tell us more about the context where the method is defined in MacRuby? How is this method created? (on what kind of class). Thanks. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:9> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by matt.wizeman@…): Sorry for the delayed response. Here is the output of my gdb session: {{{ (gdb) bt #0 0x00007fff883d35f0 in object_getClass () #1 0x00000001000ed2d3 in rb_objc_nsnumber2numeric () #2 0x000000010354cf40 in ?? () #3 0x00007fff811b0dd6 in -[IOBluetoothL2CAPChannel processIncomingData:] () #4 0x00007fff811af767 in -[IOBluetoothL2CAPChannel handleMachMessage:] () #5 0x00007fff804c007f in __NSFireMachPort () #6 0x00007fff82426bce in __CFMachPortPerform () #7 0x00007fff823ff171 in __CFRunLoopRun () #8 0x00007fff823fd84f in CFRunLoopRunSpecific () #9 0x00007fff8375491a in RunCurrentEventLoopInMode () #10 0x00007fff8375471f in ReceiveNextEventCommon () #11 0x00007fff837545d8 in BlockUntilNextEventMatchingListInMode () #12 0x00007fff8156429e in _DPSNextEvent () #13 0x00007fff81563bed in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #14 0x00007fff815298d3 in -[NSApplication run] () #15 0x00007fff815225f8 in NSApplicationMain () #16 0x0000000103545b4d in ?? () #17 0x0000000100140c94 in rb_vm_dispatch () #18 0x0000000103543fe0 in ?? () #19 0x00000001035437f3 in ?? () #20 0x000000010014ec08 in rb_vm_run () #21 0x0000000100040650 in ruby_run_node () #22 0x000000010014f06d in macruby_main () #23 0x0000000100000efe in main (argc=1, argv=0x7fff5fbff640) (gdb) p (void)rb_symbolicate(0x000000010354cf40) addr 0x10354cf40 start 0x10354cf00 selector l2capChannelData:data:length: location :0 $1 = void }}} If you like I can actually simplify my project and post that for you. Do you have a Wiimote handy? That's the device I'm connecting to and you'll need it to run the code and cause the error. Let me know. The class in question is simply defined as: {{{ class WiiRemote def connectTo device return false if device.nil? @wiiDevice = device @cchan = openL2CAPChannelWithPSM(KBluetoothL2CAPPSMHIDControl, delegate:self) return kIOReturnNotOpen unless @cchan sleep 0.02 @ichan = openL2CAPChannelWithPSM(KBluetoothL2CAPPSMHIDInterrupt, delegate:self) return kIOReturnNotOpen unless @ichan sleep 0.02 # Poll the device to get its current status result = getCurrentStatus sleep (0.01) if (result == KIOReturnSuccess) && available @disconnectNotification = @wiiDevice.registerForDisconnectNotification(self, selector:'disconnected:fromDevice:'.to_sym) @opened = true else @opened = false closeConnection end result end ... SOME OTHER METHODS ... def openL2CAPChannelWithPSM(psm, delegate:delegate) channel = Pointer.new_with_type("@") if (@wiiDevice.openL2CAPChannelSync(channel, withPSM:psm, delegate:delegate) != KIOReturnSuccess) closeConnection return nil end channel[0] end def l2capChannelReconfigured l2capChannel puts "l2capChannelReconfigured" end def l2capChannelWriteComplete l2capChannel, refcon:refcon, status:error puts "l2capChannelWriteComplete" end def l2capChannelQueueSpaceAvailable l2capChannel puts "l2capChannelQueueSpaceAvailable" end def l2capChannelOpenComplete l2capChannel, status:error puts "l2capChannelOpenComplete" end def l2capChannelClosed l2capChannel puts "l2capChannelClosed" end def l2capChannelData l2capChannel, data:data, length:dataLength puts "l2capChannelData" end end -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:10> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by matt.wizeman@…): One more bit of information. When running the above code and connecting I see the following output in the console: {{{ l2capChannelReconfigured l2capChannelQueueSpaceAvailable l2capChannelReconfigured l2capChannelQueueSpaceAvailable l2capChannelOpenComplete Program received signal: “EXC_BAD_ACCESS” }}} So, it looks like other delegate methods are OK. Its when the device starts to try to send data and IOBluetooth wants to call l2capChannelData:data:length: that things go bad. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:11> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by lsansonetti@…): Thanks for the information. I do have a Wiimote at home so yes, if you could attach a project that reproduces the issue, it would be super awesome. It looks like this should just work, this is very strange. 2 things I would try. First, run the application with GC disabled, by setting the GC_DISABLE environment variable to any value, and see if the problem still happens. Second, run the application in 32-bit mode, using {{{arch -i386 /path/to/MyApp.app/...}}}. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:12> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Comment(by matt.wizeman@…): I just attached the wiimote sample project. To try it, first make sure that Bluetooth is enabled on your mac. Next, run the attached project and press the "Do Wiimote Pairing" button. Next, press the 1 and 2 buttons on the Wiimote simultaneously to make it discoverable. You will know the wiimote is discoverable as all of the LED's on the bottom will be flashing. After running the test you will probably need to unpair the wiimote manually. Open the Bluetooth preferences pane in System Preferences, select the paired wiimote and choose disconnect from the menu at the bottom. Let me know if this doesn't work for you. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:13> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: MacRuby 1.0 Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Changes (by lsansonetti@…): * milestone: => MacRuby 1.0 Comment: Let's look at this one for 1.0. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:14> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: mattaimonetti@… Type: defect | Status: new Priority: critical | Milestone: MacRuby 1.0 Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- Changes (by mattaimonetti@…): * owner: lsansonetti@… => mattaimonetti@… -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:15> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: mattaimonetti@… Type: defect | Status: closed Priority: critical | Milestone: MacRuby 0.9 Component: MacRuby | Resolution: invalid Keywords: | -------------------------------------------+-------------------------------- Changes (by mattaimonetti@…): * status: new => closed * resolution: => invalid * milestone: MacRuby 1.0 => MacRuby 0.9 Comment: confirmed, here is the backtrace: {{{ #0 0x00007fff8390b700 in _class_getSuperclass () #1 0x00000001000f3b26 in rb_objc_convert_immediate () #2 0x0000000100f219f7 in ?? () #3 0x00007fff885d7d7a in -[IOBluetoothL2CAPChannel processIncomingData:] () #4 0x00007fff885d670b in -[IOBluetoothL2CAPChannel handleMachMessage:] () #5 0x00007fff822a8f47 in __NSFireMachPort () #6 0x00007fff8567268e in __CFMachPortPerform () #7 0x00007fff8564a6e1 in __CFRunLoopRun () #8 0x00007fff85648dbf in CFRunLoopRunSpecific () #9 0x00007fff81f8a93a in RunCurrentEventLoopInMode () #10 0x00007fff81f8a73f in ReceiveNextEventCommon () #11 0x00007fff81f8a5f8 in BlockUntilNextEventMatchingListInMode () #12 0x00007fff827e7e64 in _DPSNextEvent () #13 0x00007fff827e77a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #14 0x00007fff827ad48b in -[NSApplication run] () #15 0x00007fff827a61a8 in NSApplicationMain () #16 0x0000000100f1dbcd in ?? () #17 0x000000010014a7e8 in rb_vm_dispatch () #18 0x0000000100f1c12c in ?? () #19 0x0000000100f1b913 in ?? () #20 0x0000000100163523 in rb_vm_run () #21 0x0000000100040f80 in ruby_run_node () #22 0x000000010015a872 in macruby_main () #23 0x0000000100000efe in main (argc=1, argv=0x7fff5fbff7d0) at /Users/mattetti/tmp/wiimote-test/main.m:13 }}} After further investigation, this is a bug in the sample code: {{{ def openL2CAPChannelWithPSM(psm, delegate:delegate) channel = Pointer.new_with_type("@") if (@wiiDevice.openL2CAPChannelSync(channel, withPSM:psm, delegate:delegate) != KIOReturnSuccess) closeConnection return nil end channel[0] end }}} The channel local variable gets GC'd, to avoid that, use an instance variable to keep the pointer from being GC'd. {{{ def openL2CAPChannelWithPSM(psm, delegate:delegate) @channel = Pointer.new_with_type("@") if (@wiiDevice.openL2CAPChannelSync(channel, withPSM:psm, delegate:delegate) != KIOReturnSuccess) closeConnection return nil end channel[0] end }}} I tested that here and everything is working fine. I think the confusion might be related to the fact that you might not have expected the pointer to be garbage collected. Feel free to reopen this ticket if my solution doesn't work for you. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:16> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: mattaimonetti@… Type: defect | Status: closed Priority: critical | Milestone: MacRuby 0.9 Component: MacRuby | Resolution: invalid Keywords: | -------------------------------------------+-------------------------------- Comment(by mattaimonetti@…): oops I realized there was a typo the pasted code: {{{ def openL2CAPChannelWithPSM(psm, delegate:delegate) @channel = Pointer.new_with_type("@") if (@wiiDevice.openL2CAPChannelSync(@channel, withPSM:psm, delegate:delegate) != KIOReturnSuccess) closeConnection return nil end channel[0] end }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:17> MacRuby <http://macruby.org/>
#876: EXC_BAD_ACCESS using IOBluetooth -------------------------------------------+-------------------------------- Reporter: matt.wizeman@… | Owner: mattaimonetti@… Type: defect | Status: reopened Priority: critical | Milestone: MacRuby 1.0 Component: MacRuby | Resolution: Keywords: | -------------------------------------------+-------------------------------- Changes (by mattaimonetti@…): * status: closed => reopened * resolution: invalid => * milestone: MacRuby 0.9 => MacRuby 1.0 Comment: forget about all that, I was tired and didn't really test things properly, if you use an ivar and return the dereferenced value of the pointer, the same problem will occur. Sorry for the spamming. -- Ticket URL: <http://www.macruby.org/trac/ticket/876#comment:18> MacRuby <http://macruby.org/>
participants (1)
-
MacRuby