Hi Gabriel. Happy that you’re getting some progress. Did Jens’s reply not explain why it would be interfered with when running in the debugger?
> On Jan 31, 2024, at 10:33 AM, Gabriel Zachmann via Cocoa-dev > <cocoa-dev@lists.apple.com> wrote: > > I have investigated a bit further. > > When I launch my app from lldb (on the command line), > it still stops in mach_msg2_trap when I send a SIGUSR1 to my app. > > But at least, I get a more meaningful stack trace: > > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGUSR1 > * frame #0: 0x0000000188d91874 libsystem_kernel.dylib`mach_msg2_trap + 8 > frame #1: 0x0000000188da3cf0 libsystem_kernel.dylib`mach_msg2_internal + 80 > frame #2: 0x0000000188d9a4b0 libsystem_kernel.dylib`mach_msg_overwrite + > 476 > frame #3: 0x0000000188d91bf8 libsystem_kernel.dylib`mach_msg + 24 > frame #4: 0x0000000188eafbf4 CoreFoundation`__CFRunLoopServiceMachPort + > 160 > frame #5: 0x0000000188eae4bc CoreFoundation`__CFRunLoopRun + 1208 > frame #6: 0x0000000188ead9ac CoreFoundation`CFRunLoopRunSpecific + 608 > frame #7: 0x000000019345c448 HIToolbox`RunCurrentEventLoopInMode + 292 > frame #8: 0x000000019345c284 HIToolbox`ReceiveNextEventCommon + 648 > frame #9: 0x000000019345bfdc > HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 > frame #10: 0x000000018c68a8a4 AppKit`_DPSNextEvent + 660 > frame #11: 0x000000018ce64980 AppKit`-[NSApplication(NSEventRouting) > _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716 > frame #12: 0x000000018c67dd50 AppKit`-[NSApplication run] + 476 > frame #13: 0x000000018c655014 AppKit`NSApplicationMain + 880 > frame #14: 0x0000000100021534 ArtSaverApp`main(argc=1, > argv=0x000000016fdfefd8) at main.m:10:12 > frame #15: 0x0000000188a510e0 dyld`start + 2360 > > > Does anybody have an idea why my signal handler would not get called when the > app is running in the debugger? > But it does get called (as it should) when not running in the debugger? > How could a debugger possibly prevent my app from installing a signal handler > ? > > I'd like to debug my app after it caught the SIGUSR1 ... > > > Best regards, Gabriel > > >> >> I am setting up a signal handler in my app like this: >> >> void *e = signal( SIGUSR1, signal_handler ); >> if ( e == SIG_ERR ) >> ... >> >> It works (i can 'kill -30 <pid>'), BUT ONLY, if I run my app outside of >> Xcode. >> >> When I launch it from Xcode, and I send a SIGUSR1 to my app, it always >> breaks at mach_msg2_trap. >> Obviously, this is a bit tedious for developing, since now I always have to >> go through Product / Archive / Distribute ... >> >> Any ideas, how I can prevent this from happening? >> >> And it's unclear to me what's going on. Can Xcode really prevent signal(3) >> from installing a signal handler? >> Or does a kill on the command line deliver the signal to several processes, >> one of them, maybe, an ancillary process from Xcode? >> > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
