Prevent double release of mach ports

[friss]

Summary

When a MIG routine returns KERN_FAILURE, the demux function will release any OOL resources like ports. In this case, task_port and thread_port will be released twice, potentially resulting in use after free of the ports.

I don't think we can test this in any useful way
rdar://problem/37331387

[jingham]

Yes, this is one of the required MIG functions, but it isn't the flavor we register to receive callbacks on (we pass EXCEPTION_DEFAULT to task_set_exception_ports), so this function should never get called. That makes it doubly hard to test!

[davide]

I'm not particularly worried about testing double-free behavior, FWIW.
Ideally we should, but, I really understand it's a PITA. I think we might get this for free when testing msan/asan (or just running under valgrind), assuming there was already coverage for this path.
(and if there wasn't, well, it's a separate issue).

[jingham]

Because of the mysteries of MIG, all the flavors of catch_exception_raise have to be defined, but you register for a particular flavor when you set the task exception ports. This isn't the flavor we register. So this function is necessary but never used.

[jasonmolenda]

valgrind/asan/msan aren't going to help - this is a pretty obscure stuff. We could verify by hand that we're not leaking a port if this code was actually executed via lsmp(1) on macos, but Jim knows more about our MIG use than I do & I'm sure he's right that this code is never called. LGTM.

lldb/trunk/source/Plugins/Process/Darwin/MachException.cpp

if (log) {
     log->Printf("::%s(exc_port = 0x%4.4x, thd_port = 0x%4.4x, "
                 "tsk_port = 0x%4.4x, exc_type = %d (%s), exc_data[%d] = "
                 "{ 0x%llx, 0x%llx })",
                 __FUNCTION__, exc_port, thread_port, task_port, exc_type,
                 MachException::Name(exc_type), exc_data_count,
                 (uint64_t)(exc_data_count > 0 ? exc_data[0] : 0xBADDBADD),
                 (uint64_t)(exc_data_count > 1 ? exc_data[1] : 0xBADDBADD));
   }
-  mach_port_deallocate(mach_task_self(), task_port);
-  mach_port_deallocate(mach_task_self(), thread_port);
 
   return KERN_FAILURE;
 }
 
 extern "C" kern_return_t
 catch_mach_exception_raise(mach_port_t exc_port, mach_port_t thread_port,
                            mach_port_t task_port, exception_type_t exc_type,
                            mach_exception_data_t exc_data,

lldb/trunk/tools/debugserver/source/MacOSX/MachException.cpp

if (DNBLogCheckLogBit(LOG_EXCEPTIONS)) {
     DNBLogThreaded("::%s ( exc_port = 0x%4.4x, thd_port = 0x%4.4x, tsk_port = "
                    "0x%4.4x, exc_type = %d ( %s ), exc_data[%d] = { 0x%llx, "
                    "0x%llx })",
                    __FUNCTION__, exc_port, thread_port, task_port, exc_type,
                    MachException::Name(exc_type), exc_data_count,
                    (uint64_t)(exc_data_count > 0 ? exc_data[0] : 0xBADDBADD),
                    (uint64_t)(exc_data_count > 1 ? exc_data[1] : 0xBADDBADD));
   }
-  mach_port_deallocate(mach_task_self(), task_port);
-  mach_port_deallocate(mach_task_self(), thread_port);
 
   return KERN_FAILURE;
 }
 
 extern "C" kern_return_t
 catch_mach_exception_raise(mach_port_t exc_port, mach_port_t thread_port,
                            mach_port_t task_port, exception_type_t exc_type,
                            mach_exception_data_t exc_data,