Re: Xcode interferes with signal handler
Sorry, Jens and Pascal! I have received your messages just now. You were right, as I have found out a while later kind of the hard way ... So, thanks again! Best regards, Gabriel smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: Xcode interferes with signal handler (was: Sending SIGUSR1 to a process)
I think , I found the solution, so just for the record (so that others will find it using Google): Launch the app in the debugger on the command line : lldb /private/tmp/Build/Products/Debug/MyApp.app In lldb's command line: process handle -p true -s false -n true // otherwise lldb will stop on SIGUSR1 Set your breakpoints as needed, then r --no-stdin Then you can 'kill -30 ' without getting those annoying breaks in mach_msg2_trap. Hope this helps. Gabriel. smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: Xcode interferes with signal handler
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 > 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: 0x000188d91874 libsystem_kernel.dylib`mach_msg2_trap + 8 >frame #1: 0x000188da3cf0 libsystem_kernel.dylib`mach_msg2_internal + 80 >frame #2: 0x000188d9a4b0 libsystem_kernel.dylib`mach_msg_overwrite + > 476 >frame #3: 0x000188d91bf8 libsystem_kernel.dylib`mach_msg + 24 >frame #4: 0x000188eafbf4 CoreFoundation`__CFRunLoopServiceMachPort + > 160 >frame #5: 0x000188eae4bc CoreFoundation`__CFRunLoopRun + 1208 >frame #6: 0x000188ead9ac CoreFoundation`CFRunLoopRunSpecific + 608 >frame #7: 0x00019345c448 HIToolbox`RunCurrentEventLoopInMode + 292 >frame #8: 0x00019345c284 HIToolbox`ReceiveNextEventCommon + 648 >frame #9: 0x00019345bfdc > HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 >frame #10: 0x00018c68a8a4 AppKit`_DPSNextEvent + 660 >frame #11: 0x00018ce64980 AppKit`-[NSApplication(NSEventRouting) > _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716 >frame #12: 0x00018c67dd50 AppKit`-[NSApplication run] + 476 >frame #13: 0x00018c655014 AppKit`NSApplicationMain + 880 >frame #14: 0x000100021534 ArtSaverApp`main(argc=1, > argv=0x00016fdfefd8) at main.m:10:12 >frame #15: 0x000188a510e0 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 '), 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
Re: Xcode interferes with signal handler
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: 0x000188d91874 libsystem_kernel.dylib`mach_msg2_trap + 8 frame #1: 0x000188da3cf0 libsystem_kernel.dylib`mach_msg2_internal + 80 frame #2: 0x000188d9a4b0 libsystem_kernel.dylib`mach_msg_overwrite + 476 frame #3: 0x000188d91bf8 libsystem_kernel.dylib`mach_msg + 24 frame #4: 0x000188eafbf4 CoreFoundation`__CFRunLoopServiceMachPort + 160 frame #5: 0x000188eae4bc CoreFoundation`__CFRunLoopRun + 1208 frame #6: 0x000188ead9ac CoreFoundation`CFRunLoopRunSpecific + 608 frame #7: 0x00019345c448 HIToolbox`RunCurrentEventLoopInMode + 292 frame #8: 0x00019345c284 HIToolbox`ReceiveNextEventCommon + 648 frame #9: 0x00019345bfdc HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 frame #10: 0x00018c68a8a4 AppKit`_DPSNextEvent + 660 frame #11: 0x00018ce64980 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716 frame #12: 0x00018c67dd50 AppKit`-[NSApplication run] + 476 frame #13: 0x00018c655014 AppKit`NSApplicationMain + 880 frame #14: 0x000100021534 ArtSaverApp`main(argc=1, argv=0x00016fdfefd8) at main.m:10:12 frame #15: 0x000188a510e0 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 '), 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? > smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: Xcode interferes with signal handler (was: Sending SIGUSR1 to a process)
That’s a great tip Jens. Gabriel, if you build your app with different dev/release schemes, you could detect your build scheme and then execute the desired process based on if you’re able to debug or not. Just expose the environment variable for $CONFIGURATION in an info.plist file, read it into a variable and then manage your response based on what the value is. If you want details on that, contact me off list and I’ll show you. Reference: https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html Hopefully, Jens’s tip will get you what you need! Best, Alex Zavatone > On Jan 31, 2024, at 12:20 AM, Jens Miltner via Cocoa-dev > wrote: > > Xcode intercepts signals in the process being debugged (for good reason). > You can ignore specific signals in Xcode (i.e. pass them through to the > process being debugged) by breaking into the debugger, then enter in the > Xcode console part (example for SIGUSR1): > > process handle SIGUSR1 -s false > process handle SIGUSR1 -p true > > HTH, > -jens > > >> Von: Gabriel Zachmann >> Betreff: Xcode interferes with signal handler (was: Sending SIGUSR1 to a >> process) >> Datum: 30. Januar 2024 um 20:31:45 MEZ >> An: "cocoa-dev@lists.apple.com" >> >> >> 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 '), 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? >> >> >> Best regards, Gabriel >> > ___ > > 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
