[MacRuby] #1194: launch_msg(LAUNCH_KEY_CHECKIN) doesn't return nil when run outside of a daemon/agent
MacRuby
ruby-noreply at macosforge.org
Mon Mar 14 16:11:48 PDT 2011
#1194: launch_msg(LAUNCH_KEY_CHECKIN) doesn't return nil when run outside of a
daemon/agent
--------------------------------------+-------------------------------------
Reporter: warpflyght@… | Owner: lsansonetti@…
Type: defect | Status: new
Priority: major | Milestone:
Component: MacRuby | Keywords:
--------------------------------------+-------------------------------------
A normal user program calling launch_msg(LAUNCH_KEY_CHECKIN) will get
NULL, since the task is not a launchd job. Under RubyCocoa with Ruby
1.8.7, this is correctly converted to nil, but MacRuby returns a
launch_data_t instead. Subsequent use of this object (such as calling
launch_data_get_type) causes a segmentation fault.
Here's a test program that reproduces the issue:
{{{
#!ruby
if defined?(MACRUBY_VERSION)
framework "Foundation"
load_bridge_support_file
"/System/Library/BridgeSupport/libSystem.bridgesupport"
else
require 'osx/foundation'
include OSX
end
message = launch_data_new_string(LAUNCH_KEY_CHECKIN)
response = launch_msg(message)
if response.nil?
warn "Success! launch_msg(LAUNCH_KEY_CHECKIN) returned nil, as
expected."
exit 0
else
warn "Failure! launch_msg(LAUNCH_KEY_CHECKIN) did not return nil, though
it should have."
exit 1
end
}}}
Here's how the response object looks in gdb when I replace the nil check
with a launch_data_get_type call:
{{{
(gdb) frame 2
#2 0x0000000100139015 in rb_vm_dispatch (_vm=0x10111c5c0,
cache=0x1010d0780, top=8590063808, self=8590063808, klass=0x20001f780,
sel=0x101399360, block=0x0, opt=2 '\002', argc=1, argv=0x7fff5fbff608) at
dispatcher.cpp:981
(gdb) p *(struct RData *)argv[0]
$1 = {
basic = {
klass = 8592289600,
flags = 12
},
dmark = 0,
dfree = 0,
data = 0x0
}
}}}
Unfortunately, there's no apparent way to interrogate the opaque
launch_data_t object and determine that it is NULL, so a crash is hard to
avoid. I can implement this in native code if necessary, but I'm sure
there are other APIs that are also impacted.
--
Ticket URL: <http://www.macruby.org/trac/ticket/1194>
MacRuby <http://macruby.org/>
More information about the macruby-tickets
mailing list