copied Proc objects cause crash when used as Objective-C blocks
I've been attempting to get an objective-c framework to work with macruby and I believe I've found a bug in the way ruby Proc objects are copied when used as objective-c blocks. The copied block doesn't seem to persist correctly beyond the scope in which it was copied. It isn't deallocated, but calling it results in a crash. Typical error messages are: wrong type NSCFSet (expected Proc) (TypeError) wrong type NSRectSet (expected Proc) (TypeError) I'm guessing that there's a pointer to the wrong memory location? Here's the Objective-C implementation: @implementation TestBlock - (id)initWithBlock:(void (^)())aBlock; { [super init]; block = [aBlock copy]; NSLog(@"Block: %@", block); block(); return self; } - (void)callBlock; { NSLog(@"block: %@", block); block(); } @end Within 'initWithBlock:', the copied block can be invoked without error. Attempting to do so from 'callBlock', results in a crash. The test framework can be used without error when using objective-c. Here's the ruby controller code: @b = TestBlock.alloc.initWithBlock Proc.new { puts "hello from ruby"} # this next line is called from a different scope and causes the crash @b.callBlock 2010-11-19 08:41:06.620 CallObjectiveCBlocks[7046:a0f] Block: <__NSAutoBlock__: 0x200be74a0> hello from ruby 2010-11-19 08:41:20.011 CallObjectiveCBlocks[7046:a0f] block: <__NSAutoBlock__: 0x200be74a0> 2010-11-19 08:41:20.012 CallObjectiveCBlocks[7046:a0f] /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/Controller.rb:21:in `call:': wrong type Array (expected Proc) (TypeError) from /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/rb_main.rb:23:in `<main>'
Hi Alan, I didn't look in further details yet, but clearly your initWithBlock method is wrong, it should be: - (id)initWithBlock:(void (^)())aBlock; { if ((self = [super init])) { block = [aBlock copy]; NSLog(@"Block: %@", block); block(); } return self; } You are not assigning `self` to be equal to what `[super init]` returns, and this is, even without macruby or blocks, prone to crashes :-) Can you try to fix this and then tell us if it's still crashing? -- Thibault Martin-Lagardette On Nov 19, 2010, at 10:14, Alan Skipp wrote:
I've been attempting to get an objective-c framework to work with macruby and I believe I've found a bug in the way ruby Proc objects are copied when used as objective-c blocks. The copied block doesn't seem to persist correctly beyond the scope in which it was copied. It isn't deallocated, but calling it results in a crash. Typical error messages are: wrong type NSCFSet (expected Proc) (TypeError) wrong type NSRectSet (expected Proc) (TypeError) I'm guessing that there's a pointer to the wrong memory location?
Here's the Objective-C implementation:
@implementation TestBlock
- (id)initWithBlock:(void (^)())aBlock; { [super init]; block = [aBlock copy]; NSLog(@"Block: %@", block); block(); return self; }
- (void)callBlock; { NSLog(@"block: %@", block); block(); }
@end
Within 'initWithBlock:', the copied block can be invoked without error. Attempting to do so from 'callBlock', results in a crash. The test framework can be used without error when using objective-c.
Here's the ruby controller code:
@b = TestBlock.alloc.initWithBlock Proc.new { puts "hello from ruby"}
# this next line is called from a different scope and causes the crash @b.callBlock
2010-11-19 08:41:06.620 CallObjectiveCBlocks[7046:a0f] Block: <__NSAutoBlock__: 0x200be74a0> hello from ruby
2010-11-19 08:41:20.011 CallObjectiveCBlocks[7046:a0f] block: <__NSAutoBlock__: 0x200be74a0> 2010-11-19 08:41:20.012 CallObjectiveCBlocks[7046:a0f] /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/Controller.rb:21:in `call:': wrong type Array (expected Proc) (TypeError) from /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/rb_main.rb:23:in `<main>' _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Whoops, sorry about that. I find that I can get away without assigning to self in 'init' when doing a quick hack, but certainly not the recommended approach, especially when attempting to track down another bug. I've amended the initializer now and I still encounter the same problem. Al On 19 Nov 2010, at 10:53, Thibault Martin-Lagardette wrote:
Hi Alan,
I didn't look in further details yet, but clearly your initWithBlock method is wrong, it should be:
- (id)initWithBlock:(void (^)())aBlock; { if ((self = [super init])) { block = [aBlock copy]; NSLog(@"Block: %@", block); block(); } return self; }
You are not assigning `self` to be equal to what `[super init]` returns, and this is, even without macruby or blocks, prone to crashes :-)
Can you try to fix this and then tell us if it's still crashing?
-- Thibault Martin-Lagardette
On Nov 19, 2010, at 10:14, Alan Skipp wrote:
I've been attempting to get an objective-c framework to work with macruby and I believe I've found a bug in the way ruby Proc objects are copied when used as objective-c blocks. The copied block doesn't seem to persist correctly beyond the scope in which it was copied. It isn't deallocated, but calling it results in a crash. Typical error messages are: wrong type NSCFSet (expected Proc) (TypeError) wrong type NSRectSet (expected Proc) (TypeError) I'm guessing that there's a pointer to the wrong memory location?
Here's the Objective-C implementation:
@implementation TestBlock
- (id)initWithBlock:(void (^)())aBlock; { [super init]; block = [aBlock copy]; NSLog(@"Block: %@", block); block(); return self; }
- (void)callBlock; { NSLog(@"block: %@", block); block(); }
@end
Within 'initWithBlock:', the copied block can be invoked without error. Attempting to do so from 'callBlock', results in a crash. The test framework can be used without error when using objective-c.
Here's the ruby controller code:
@b = TestBlock.alloc.initWithBlock Proc.new { puts "hello from ruby"}
# this next line is called from a different scope and causes the crash @b.callBlock
2010-11-19 08:41:06.620 CallObjectiveCBlocks[7046:a0f] Block: <__NSAutoBlock__: 0x200be74a0> hello from ruby
2010-11-19 08:41:20.011 CallObjectiveCBlocks[7046:a0f] block: <__NSAutoBlock__: 0x200be74a0> 2010-11-19 08:41:20.012 CallObjectiveCBlocks[7046:a0f] /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/Controller.rb:21:in `call:': wrong type Array (expected Proc) (TypeError) from /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/rb_main.rb:23:in `<main>' _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
I see. It would be ideal if you could provide a small test sample, so that we can reproduce the bug :-) -- Thibault Martin-Lagardette On Nov 19, 2010, at 12:25, Alan Skipp wrote:
Whoops, sorry about that. I find that I can get away without assigning to self in 'init' when doing a quick hack, but certainly not the recommended approach, especially when attempting to track down another bug. I've amended the initializer now and I still encounter the same problem.
Al
On 19 Nov 2010, at 10:53, Thibault Martin-Lagardette wrote:
Hi Alan,
I didn't look in further details yet, but clearly your initWithBlock method is wrong, it should be:
- (id)initWithBlock:(void (^)())aBlock; { if ((self = [super init])) { block = [aBlock copy]; NSLog(@"Block: %@", block); block(); } return self; }
You are not assigning `self` to be equal to what `[super init]` returns, and this is, even without macruby or blocks, prone to crashes :-)
Can you try to fix this and then tell us if it's still crashing?
-- Thibault Martin-Lagardette
On Nov 19, 2010, at 10:14, Alan Skipp wrote:
I've been attempting to get an objective-c framework to work with macruby and I believe I've found a bug in the way ruby Proc objects are copied when used as objective-c blocks. The copied block doesn't seem to persist correctly beyond the scope in which it was copied. It isn't deallocated, but calling it results in a crash. Typical error messages are: wrong type NSCFSet (expected Proc) (TypeError) wrong type NSRectSet (expected Proc) (TypeError) I'm guessing that there's a pointer to the wrong memory location?
Here's the Objective-C implementation:
@implementation TestBlock
- (id)initWithBlock:(void (^)())aBlock; { [super init]; block = [aBlock copy]; NSLog(@"Block: %@", block); block(); return self; }
- (void)callBlock; { NSLog(@"block: %@", block); block(); }
@end
Within 'initWithBlock:', the copied block can be invoked without error. Attempting to do so from 'callBlock', results in a crash. The test framework can be used without error when using objective-c.
Here's the ruby controller code:
@b = TestBlock.alloc.initWithBlock Proc.new { puts "hello from ruby"}
# this next line is called from a different scope and causes the crash @b.callBlock
2010-11-19 08:41:06.620 CallObjectiveCBlocks[7046:a0f] Block: <__NSAutoBlock__: 0x200be74a0> hello from ruby
2010-11-19 08:41:20.011 CallObjectiveCBlocks[7046:a0f] block: <__NSAutoBlock__: 0x200be74a0> 2010-11-19 08:41:20.012 CallObjectiveCBlocks[7046:a0f] /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/Controller.rb:21:in `call:': wrong type Array (expected Proc) (TypeError) from /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/rb_main.rb:23:in `<main>' _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Alan, Thanks for reporting that problem in the tracker. In the meantime, keeping a reference to the Proc object in the Ruby side might work around the problem (as I suspect that the proc here is being garbage-collected prematurely). @b = TestBlock.alloc.initWithBlock (@tmp ||= Proc.new { puts "hello from ruby"}) Laurent On Nov 19, 2010, at 3:25 AM, Alan Skipp wrote:
Whoops, sorry about that. I find that I can get away without assigning to self in 'init' when doing a quick hack, but certainly not the recommended approach, especially when attempting to track down another bug. I've amended the initializer now and I still encounter the same problem.
Al
On 19 Nov 2010, at 10:53, Thibault Martin-Lagardette wrote:
Hi Alan,
I didn't look in further details yet, but clearly your initWithBlock method is wrong, it should be:
- (id)initWithBlock:(void (^)())aBlock; { if ((self = [super init])) { block = [aBlock copy]; NSLog(@"Block: %@", block); block(); } return self; }
You are not assigning `self` to be equal to what `[super init]` returns, and this is, even without macruby or blocks, prone to crashes :-)
Can you try to fix this and then tell us if it's still crashing?
-- Thibault Martin-Lagardette
On Nov 19, 2010, at 10:14, Alan Skipp wrote:
I've been attempting to get an objective-c framework to work with macruby and I believe I've found a bug in the way ruby Proc objects are copied when used as objective-c blocks. The copied block doesn't seem to persist correctly beyond the scope in which it was copied. It isn't deallocated, but calling it results in a crash. Typical error messages are: wrong type NSCFSet (expected Proc) (TypeError) wrong type NSRectSet (expected Proc) (TypeError) I'm guessing that there's a pointer to the wrong memory location?
Here's the Objective-C implementation:
@implementation TestBlock
- (id)initWithBlock:(void (^)())aBlock; { [super init]; block = [aBlock copy]; NSLog(@"Block: %@", block); block(); return self; }
- (void)callBlock; { NSLog(@"block: %@", block); block(); }
@end
Within 'initWithBlock:', the copied block can be invoked without error. Attempting to do so from 'callBlock', results in a crash. The test framework can be used without error when using objective-c.
Here's the ruby controller code:
@b = TestBlock.alloc.initWithBlock Proc.new { puts "hello from ruby"}
# this next line is called from a different scope and causes the crash @b.callBlock
2010-11-19 08:41:06.620 CallObjectiveCBlocks[7046:a0f] Block: <__NSAutoBlock__: 0x200be74a0> hello from ruby
2010-11-19 08:41:20.011 CallObjectiveCBlocks[7046:a0f] block: <__NSAutoBlock__: 0x200be74a0> 2010-11-19 08:41:20.012 CallObjectiveCBlocks[7046:a0f] /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/Controller.rb:21:in `call:': wrong type Array (expected Proc) (TypeError) from /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/rb_main.rb:23:in `<main>' _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Laurent, The work around you suggested works. Also, after a clean build the automatic loading of framework and bridgeSupport file worked as well. Thanks very much, Alan On 22 Nov 2010, at 02:55, Laurent Sansonetti wrote:
Hi Alan,
Thanks for reporting that problem in the tracker. In the meantime, keeping a reference to the Proc object in the Ruby side might work around the problem (as I suspect that the proc here is being garbage-collected prematurely).
@b = TestBlock.alloc.initWithBlock (@tmp ||= Proc.new { puts "hello from ruby"})
Laurent
On Nov 19, 2010, at 3:25 AM, Alan Skipp wrote:
Whoops, sorry about that. I find that I can get away without assigning to self in 'init' when doing a quick hack, but certainly not the recommended approach, especially when attempting to track down another bug. I've amended the initializer now and I still encounter the same problem.
Al
On 19 Nov 2010, at 10:53, Thibault Martin-Lagardette wrote:
Hi Alan,
I didn't look in further details yet, but clearly your initWithBlock method is wrong, it should be:
- (id)initWithBlock:(void (^)())aBlock; { if ((self = [super init])) { block = [aBlock copy]; NSLog(@"Block: %@", block); block(); } return self; }
You are not assigning `self` to be equal to what `[super init]` returns, and this is, even without macruby or blocks, prone to crashes :-)
Can you try to fix this and then tell us if it's still crashing?
-- Thibault Martin-Lagardette
On Nov 19, 2010, at 10:14, Alan Skipp wrote:
I've been attempting to get an objective-c framework to work with macruby and I believe I've found a bug in the way ruby Proc objects are copied when used as objective-c blocks. The copied block doesn't seem to persist correctly beyond the scope in which it was copied. It isn't deallocated, but calling it results in a crash. Typical error messages are: wrong type NSCFSet (expected Proc) (TypeError) wrong type NSRectSet (expected Proc) (TypeError) I'm guessing that there's a pointer to the wrong memory location?
Here's the Objective-C implementation:
@implementation TestBlock
- (id)initWithBlock:(void (^)())aBlock; { [super init]; block = [aBlock copy]; NSLog(@"Block: %@", block); block(); return self; }
- (void)callBlock; { NSLog(@"block: %@", block); block(); }
@end
Within 'initWithBlock:', the copied block can be invoked without error. Attempting to do so from 'callBlock', results in a crash. The test framework can be used without error when using objective-c.
Here's the ruby controller code:
@b = TestBlock.alloc.initWithBlock Proc.new { puts "hello from ruby"}
# this next line is called from a different scope and causes the crash @b.callBlock
2010-11-19 08:41:06.620 CallObjectiveCBlocks[7046:a0f] Block: <__NSAutoBlock__: 0x200be74a0> hello from ruby
2010-11-19 08:41:20.011 CallObjectiveCBlocks[7046:a0f] block: <__NSAutoBlock__: 0x200be74a0> 2010-11-19 08:41:20.012 CallObjectiveCBlocks[7046:a0f] /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/Controller.rb:21:in `call:': wrong type Array (expected Proc) (TypeError) from /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/rb_main.rb:23:in `<main>' _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (3)
-
Alan Skipp
-
Laurent Sansonetti
-
Thibault Martin-Lagardette