site_archiver@lists.apple.com Delivered-To: cocoa-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=2019; t=1706718795; i=@uni-bremen.de; bh=aam0eH3DATJ8HBnj9VJbr6rG0qCJKBPTmlXNL8yzLDM=; h=From:Date:References:To:In-Reply-To; b=ZZC+rLvfwFsTws/c9uNoINXs0Pkjo3pVL5SBUUkr9SDkO0H7PWwjukfXlr05wyGg2 vA1JDuTwAI1zuCo3bAuRh9MPY8gEH9MIopOGMCYGrkk1GCoOgWNwYr3fj5DqMTkZYL Rea07Md6jlQWGnGMK/YDRKwgdpvukS+HZNL4pYevBJdqLjw4D7svzpzwPmqWOlZlwd TzVo2mGrHMC4RPG50JUvunGIPzPdH1/FAPTpsRb9RKp44hwR4RG7Okjfve9Q5lFqA2 yFohKp3ablSiH3wdew74rOOWDer2SoPW1tRE/JblaWmVtr+ZDOMWD2Cg6ne3D3U+Mq OIUxmVnACftZg== 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/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com smime.p7s