[MacRuby] #1194: launch_msg(LAUNCH_KEY_CHECKIN) doesn't return nil when run outside of a daemon/agent

14 Mar 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/>