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
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
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 (
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: 0
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
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 f
Le 30/01/2024 à 20:31, Gabriel Zachmann via Cocoa-dev a écrit :
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 f
