Exiting non-POSIX threads?

[Oleg Krupnov]

I'm writing an exception handler where I want to terminate a crashed
thread without terminating the entire process. Before GCD I used the
following code:


if ([NSThread currentThread] != [NSThread mainThread])
{
   [NSThread exit];
}

However for GCD thread (created with dispatch_async()) I get the
following signal:

pthread_exit() may only be called against threads created via pthread_create()


Is there a way to handle this case?

Is there a way to exit a GCD thread?

At least, is there a way of telling POSIX threads from GCD / other threads?
___

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: Exiting non-POSIX threads?

[Steve Sisak]

At 11:34 AM +0300 7/29/13, Oleg Krupnov wrote:

However for GCD thread (created with dispatch_async()) I get the
following signal:

pthread_exit() may only be called against threads created via pthread_create()

Is there a way to handle this case?


Just return from the block you passed to dispatch_async()


Is there a way to exit a GCD thread?


There's no such thing as a "GCD thread" only queues.

(OK, there's a pool of threads that GCD uses to service queues, but 
you don't own them)



At least, is there a way of telling POSIX threads from GCD / other threads?


WAYRTTD?

Exiting threads is bad form in general -- if you're really writing an 
exception handler, catch it at the outermost level and just return so 
the thread terminates normally.


Same for your outer block in GCD.

HTH,

-Steve
___

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: Exiting non-POSIX threads?

[Oleg Krupnov]

Thanks for your answer, Steve, but the problem remains.

In my case, the exception has already been thrown inside the block and
I cannot catch it or modify it in any way in my handler. I'm basically
writing an uncaught exception handler. My app should show a crash
report window and then terminate itself.

The problem is that if the exception happens in another thread, the
app gets instantly terminated by the system after my exception handler
(unlike exceptions in the main thread that are automatically
absorbed), unless I terminate the crashed thread manually. [NSThread
exit] worked with NSThreads, but with GCD threads (starting from
start_wqthread), it's causing the signal.


On Mon, Jul 29, 2013 at 12:27 PM, Steve Sisak  wrote:
> At 11:34 AM +0300 7/29/13, Oleg Krupnov wrote:
>>
>> However for GCD thread (created with dispatch_async()) I get the
>> following signal:
>>
>> pthread_exit() may only be called against threads created via
>> pthread_create()
>>
>> Is there a way to handle this case?
>
>
> Just return from the block you passed to dispatch_async()
>
>
>> Is there a way to exit a GCD thread?
>
>
> There's no such thing as a "GCD thread" only queues.
>
> (OK, there's a pool of threads that GCD uses to service queues, but you
> don't own them)
>
>
>> At least, is there a way of telling POSIX threads from GCD / other
>> threads?
>
>
> WAYRTTD?
>
> Exiting threads is bad form in general -- if you're really writing an
> exception handler, catch it at the outermost level and just return so the
> thread terminates normally.
>
> Same for your outer block in GCD.
>
> HTH,
>
> -Steve
___

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: Exiting non-POSIX threads?

[Ken Thomases]

On Jul 29, 2013, at 4:27 AM, Steve Sisak wrote:

> At 11:34 AM +0300 7/29/13, Oleg Krupnov wrote:
>> Is there a way to exit a GCD thread?
> 
> There's no such thing as a "GCD thread" only queues.
> 
> (OK, there's a pool of threads that GCD uses to service queues, but you don't 
> own them)

And you must not try to exit them.  This is clearly documented in the GCD docs.
https://developer.apple.com/library/ios/DOCUMENTATION/General/Conceptual/ConcurrencyProgrammingGuide/ThreadMigration/ThreadMigration.html#//apple_ref/doc/uid/TP40008091-CH105-SW18

Regards,
Ken


___

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: Exiting non-POSIX threads?

[Ken Thomases]

On Jul 29, 2013, at 4:54 AM, Oleg Krupnov wrote:

> Thanks for your answer, Steve, but the problem remains.
> 
> In my case, the exception has already been thrown inside the block and
> I cannot catch it or modify it in any way in my handler. I'm basically
> writing an uncaught exception handler. My app should show a crash
> report window and then terminate itself.
> 
> The problem is that if the exception happens in another thread, the
> app gets instantly terminated by the system after my exception handler
> (unlike exceptions in the main thread that are automatically
> absorbed), unless I terminate the crashed thread manually. [NSThread
> exit] worked with NSThreads, but with GCD threads (starting from
> start_wqthread), it's causing the signal.

Look into the ExceptionHandling framework and/or the 
NSSetUncaughtExceptionHandler() function.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html#//apple_ref/doc/uid/2473-BBCHGJIJ

However, you're not supposed to let exceptions escape from blocks which you 
submit to dispatch queues.  That's documented in the link I gave in my previous 
reply.

If you exit a thread that you don't own, you may screw up your app's ability to 
present a dialog.  Perhaps AppKit relies on that thread.  Perhaps the thread 
held a crucial resource and other threads will deadlock when they try to access 
it.

All in all, what you're doing seems like a bad idea.

Regards,
Ken


___

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: Exiting non-POSIX threads?

[Kevin Meaney]

Perhaps OP should be looking at using an xpc service.

Kevin

On 29 Jul 2013, at 15:54, Ken Thomases  wrote:

> On Jul 29, 2013, at 4:54 AM, Oleg Krupnov wrote:
> 
>> Thanks for your answer, Steve, but the problem remains.
>> 
>> In my case, the exception has already been thrown inside the block and
>> I cannot catch it or modify it in any way in my handler. I'm basically
>> writing an uncaught exception handler. My app should show a crash
>> report window and then terminate itself.
>> 
>> The problem is that if the exception happens in another thread, the
>> app gets instantly terminated by the system after my exception handler
>> (unlike exceptions in the main thread that are automatically
>> absorbed), unless I terminate the crashed thread manually. [NSThread
>> exit] worked with NSThreads, but with GCD threads (starting from
>> start_wqthread), it's causing the signal.
> 
> Look into the ExceptionHandling framework and/or the 
> NSSetUncaughtExceptionHandler() function.
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html#//apple_ref/doc/uid/2473-BBCHGJIJ
> 
> However, you're not supposed to let exceptions escape from blocks which you 
> submit to dispatch queues.  That's documented in the link I gave in my 
> previous reply.
> 
> If you exit a thread that you don't own, you may screw up your app's ability 
> to present a dialog.  Perhaps AppKit relies on that thread.  Perhaps the 
> thread held a crucial resource and other threads will deadlock when they try 
> to access it.
> 
> All in all, what you're doing seems like a bad idea.
> 
> Regards,
> Ken
> 
> 
> ___
> 
> 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/ktam%40yvs.eu.com
> 
> This email sent to k...@yvs.eu.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: Exiting non-POSIX threads?

[Oleg Krupnov]

Thanks Ken,

> However, you're not supposed to let exceptions escape from blocks which you 
> submit to dispatch queues.  That's documented in the link I gave in my 
> previous reply.

Yes, thanks for pointing it out, but let me note that this is not
consistent with other parts of the AppKit. When an exception happens
in the main thread, it is logged to the console and quietly absorbed
without any additional action on my part.

Now if the exception happens in a non-main thread, I am obliged to
catch it or otherwise the app will be instantly terminated. This is
inconsistent. I may not be using or even expecting any exceptions in
the thread, but merely use some NSAssert's and want to report logical
errors in my code. Putting explicit @try/@catch in every thread with
NSAssert's seems like an overkill or even something I should not rely
upon, because I want to write a catch-all for problems, including my
own bugs, such as forgetting to wrap the thread in @try/@catch.

> If you exit a thread that you don't own, you may screw up your app's ability 
> to present a dialog.  Perhaps AppKit relies on that thread.  Perhaps the 
> thread held a crucial resource and other threads will deadlock when they try 
> to access it.

I'd disagree. This thread has already crashed and its exception was
not caught, and so the thread is about to be terminated with or
without my intervention. Killing it myself would hardly produce any
side effects. I just want to prevent the entire app from termination
and so far it seems darn impossible.

> All in all, what you're doing seems like a bad idea.

Maybe but what is the right solution to this?
___

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: Exiting non-POSIX threads?

[j.carlson]

On July 30, 2013 at 12:04:44 AM, cocoa-dev-requ...@lists.apple.com 
(cocoa-dev-requ...@lists.apple.com) wrote:
Message: 5
Date: Mon, 29 Jul 2013 12:54:26 +0300
From: Oleg Krupnov 
To: Steve Sisak 
Cc: Cocoa-Dev List 
Subject: Re: Exiting non-POSIX threads?
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

Thanks for your answer, Steve, but the problem remains.

In my case, the exception has already been thrown inside the block and
I cannot catch it or modify it in any way in my handler. I'm basically
writing an uncaught exception handler. My app should show a crash
report window and then terminate itself.


Shortest path in this case may be to wrap dispatch_async() and pass a block 
which executes the block parameter (currently passed to dispatch_async()) but 
this added block introduces your exception handling. Be sure to copy the block 
parameter, as dispatch_async() would.

Remember that exceptions originating from Cocoa APIs are generally 
nonrecoverable (C++ implementations OTOH are generally designed to be safe to 
catch and resume -- recoverable without leaking resources or leaving them in 
potentially invalid states).

Assume killing threads is never an option ;) Just let them exit naturally so 
that all implementations within that context may conclude what they are in the 
process of executing. Sometimes that means you must choose (or design) more 
robust implementations.

So when you catch that halting exception, then you can add some work to the 
main run loop (e.g. to present the alert). You should then suspend the thread 
which handled the exception (until your process is exited from the other thread 
after the alert you mentioned was presented) to avoid returning control flow to 
the implementation/queue which executed your block. Make sure your presentation 
is quick and always exits, and avoid creating autoreleased objects in the 
suspended thread (the pools will not be drained).

Of course, if it's your API that throws nonrecoverable exceptions you should 
just use another mechanism for error handling to avoid all the above (and 
perhaps recover gracefully).___

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: Exiting non-POSIX threads?

[j.carlson]

Subject: Re: Exiting non-POSIX threads?
From: Oleg Krupnov 
Date: Tue, 30 Jul 2013 12:13:38 +0300
I'd disagree. This thread has already crashed and its exception was
not caught, and so the thread is about to be terminated with or
without my intervention. Killing it myself would hardly produce any
side effects.

Ken's right. The side effects may be significant, and you shouldn't assume that 
it will not impact system/foreign implementations executing in that context 
(i.e. thread). When an exception is thrown, the program unwinds. This gives 
other implementations the opportunity to perform their cleanup, even though 
*your* implementation may not do anything meaningful when unwinding. 
Killing/exiting the thread at an arbitrary point in execution is more likely to 
leave other implementations in unspecified states. A (non-shared) int on the 
stack is not a concern, but what if your thread's autorelease pools were never 
drained or locked shared resources never unlocked?

I just want to prevent the entire app from termination
and so far it seems darn impossible.
> All in all, what you're doing seems like a bad idea.
Maybe but what is the right solution to this?

The easy way is to just not introduce exceptions into your Cocoa programs, and 
to design with appropriate error handling and recovery in mind. That also means 
preventing your implementation from doing something which would cause an API 
you call to throw. If you use an implementation which throws (e.g. C++), forbid 
that exception from entering your Cocoa implementations. Some Cocoa APIs throw, 
but those errors are generally nonrecoverable and you should not try to handle 
them (you could prevent them, if it is your error). This default 'works' for 
most projects.
Defending your implementation from anything that could possibly throw while 
being prepared to appropriately handle what *could* be thrown without context 
is futile at this abstraction level. If you really insist you should intercept 
this information and think you can do meaningful things with it or allow 
meaningful tasks on other threads to complete, another angle would be to 
specify the thread's NSAssertionHandler instance in the -[NSThread 
threadDictionary] (key: NSAssertionHandlerKey). However, there's not much good 
you can do here beyond noting the error for future presentation or your log for 
review and immediately exiting -- I would not bother forcing an alert through 
to the user on the dying process' main run loop.___

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: Exiting non-POSIX threads?

[Scott Ribe]

On Jul 30, 2013, at 3:13 AM, Oleg Krupnov  wrote:

> I'd disagree. This thread has already crashed and its exception was
> not caught, and so the thread is about to be terminated with or
> without my intervention. Killing it myself would hardly produce any
> side effects. I just want to prevent the entire app from termination
> and so far it seems darn impossible.

The entire app is about to terminated precisely because the thread is in an 
unknown corrupt state, likely having corrupted the heap or stack, and possibly 
holding a crucial lock or other resource, so continuing is completely 
unreliable.

If your goal is to present a dialog to the user and ask that the user send 
diagnostic info to you, use an external process monitoring your logs and/or 
crash reports. (And don't try to log after an unhanded exception; log info 
before.)

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: Exiting non-POSIX threads?

[Kyle Sluder]

On Tue, Jul 30, 2013, at 02:13 AM, Oleg Krupnov wrote:
> > However, you're not supposed to let exceptions escape from blocks which you 
> > submit to dispatch queues.  That's documented in the link I gave in my 
> > previous reply.
> 
> Yes, thanks for pointing it out, but let me note that this is not
> consistent with other parts of the AppKit. When an exception happens
> in the main thread, it is logged to the console and quietly absorbed
> without any additional action on my part.

libdispatch is not part of AppKit.

--Kyle Sluder
___

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: Exiting non-POSIX threads?

[Ken Thomases]

On Jul 30, 2013, at 4:13 AM, Oleg Krupnov wrote:

>> However, you're not supposed to let exceptions escape from blocks which you 
>> submit to dispatch queues.  That's documented in the link I gave in my 
>> previous reply.
> 
> Yes, thanks for pointing it out, but let me note that this is not
> consistent with other parts of the AppKit. When an exception happens
> in the main thread, it is logged to the console and quietly absorbed
> without any additional action on my part.

The fact that AppKit continues after catching an exception at the top level is 
not great behavior to be emulating.  It often hides errors which would be 
revealed and fixed more promptly if they caused the app to crash.


> Now if the exception happens in a non-main thread, I am obliged to
> catch it or otherwise the app will be instantly terminated. This is
> inconsistent. I may not be using or even expecting any exceptions in
> the thread, but merely use some NSAssert's and want to report logical
> errors in my code. Putting explicit @try/@catch in every thread with
> NSAssert's seems like an overkill or even something I should not rely
> upon, because I want to write a catch-all for problems, including my
> own bugs, such as forgetting to wrap the thread in @try/@catch.

The point of asserts is to fail early and very noticeably.  Terminating the 
process is good.  The fact that Cocoa's asserts throw exceptions and, 
therefore, can be quietly absorbed by AppKit's main event loop is bad.  
Consider replacing your use of Cocoa asserts with custom asserts.  See this, 
for example:
http://www.mikeash.com/pyblog/friday-qa-2013-05-03-proper-use-of-asserts.html


>> If you exit a thread that you don't own, you may screw up your app's ability 
>> to present a dialog.  Perhaps AppKit relies on that thread.  Perhaps the 
>> thread held a crucial resource and other threads will deadlock when they try 
>> to access it.
> 
> I'd disagree. This thread has already crashed and its exception was
> not caught, and so the thread is about to be terminated with or
> without my intervention. Killing it myself would hardly produce any
> side effects. I just want to prevent the entire app from termination
> and so far it seems darn impossible.

The difference is precisely between terminating the process versus terminating 
a single thread but keeping the process alive and attempting to use frameworks 
whose internals may be corrupted.  Of course, the default behavior of 
terminating the process is safe.  It's the way you're trying to deviate from 
that that's not.


>> All in all, what you're doing seems like a bad idea.
> 
> Maybe but what is the right solution to this?

Let the app crash.  Let the CrashReporter tell the user that it crashed.  If 
you want to receive the crash report yourself, use an external watchdog process 
or collect the crash report file on next launch.

Regards,
Ken


___

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: Exiting non-POSIX threads?

[Sean McBride]

On Tue, 30 Jul 2013 10:20:21 -0500, Ken Thomases said:

>>> All in all, what you're doing seems like a bad idea.
>> 
>> Maybe but what is the right solution to this?
>
>Let the app crash.  Let the CrashReporter tell the user that it
>crashed.  If you want to receive the crash report yourself, use an
>external watchdog process or collect the crash report file on next launch.

Oleg's problem is basically the same as an issue I have.

Basically, when a Objective-C exception (from one's own code, third party 
libraries, or the OS) is thrown and not caught, the OS does what?  The answer 
depends on a few things: 

 1) which thread did it happen on?
 2) have you called NSSetUncaughtExceptionHandler(), see:

 3) the value of NSApplicationShowExceptions, see:


The next question is: what would be nice to do in response?  Ideally, a UI 
would be shown allowing the user to submit the crash report over the internet.  
Presenting this UI from the same process is probably a bad idea since the 
process is in a bad state.  So I guess the best thing to do is let the OS kill 
the process and create a crash log, which you can then read when you relaunch 
(modulo sandbox issues).

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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: Exiting non-POSIX threads?

[Graham Cox]

On 30/07/2013, at 5:20 PM, Ken Thomases  wrote:

> The fact that AppKit continues after catching an exception at the top level 
> is not great behavior to be emulating.  It often hides errors which would be 
> revealed and fixed more promptly if they caused the app to crash.


Hmmm, that's a *very* contentious statement. How often have you encountered an 
unexpected exception from some low-level code you don't own under circumstances 
you can't control? If your app crashed every time you'd soon have a reputation 
for unreliability that is in all probability undeserved. On balance it's better 
to carry on with some minor glitch than "quit unexpectedly". I guess if you are 
really concerned about this, install your own top-level handler.

JM2¢W

--Graham



___

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: Exiting non-POSIX threads?

[Quincey Morris]

On Jul 30, 2013, at 10:26 , Graham Cox  wrote:

> How often have you encountered an unexpected exception from some low-level 
> code you don't own under circumstances you can't control? If your app crashed 
> every time you'd soon have a reputation for unreliability that is in all 
> probability undeserved. On balance it's better to carry on with some minor 
> glitch than "quit unexpectedly".

Surely the problem with this perspective is that the uncaught exception results 
in an abrupt transfer of control from the point of the exception back to 
(approximately) [NSApplication sendEvent:]?

If you don't own the low-level code where the exception was thrown, you can 
have no confidence that non-stack data structures being maintained by that code 
-- along with all of the intermediate levels of calling code -- are in any 
usable state.

___

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: Exiting non-POSIX threads?

[Oleg Krupnov]

Hi Ken,

> Let the app crash.  Let the CrashReporter tell the user that it crashed.  If 
> you want to receive the crash report yourself, use an external watchdog 
> process or collect the crash report file on next launch.

I'd agree that this approach technically is more correct. One downside
of it though is that the user should launch the crashed app at least
one more time. Hopefully, it's not going to be a crash on first launch
followed by immediate trashing of the app :)

So it boils down to these questions:

1. What is the correct way of terminating the app if the exception
happens in the main thread? I need the system Crash Reporter to save
the context and stack trace of the original problem, not of some
exception handler.

2. Will it work in sandboxed mode? The folder with crash reports may
appear unaccessible.

P.S. It dawned at me that I could relaunch another instance of the app
(using a shell script) before my app terminates, in this way relying
on the user to do this is not needed.

Thanks.
___

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: Exiting non-POSIX threads?

[Graham Cox]

On 30/07/2013, at 7:43 PM, Quincey Morris  
wrote:

> On Jul 30, 2013, at 10:26 , Graham Cox  wrote:
> 
>> How often have you encountered an unexpected exception from some low-level 
>> code you don't own under circumstances you can't control? If your app 
>> crashed every time you'd soon have a reputation for unreliability that is in 
>> all probability undeserved. On balance it's better to carry on with some 
>> minor glitch than "quit unexpectedly".
> 
> Surely the problem with this perspective is that the uncaught exception 
> results in an abrupt transfer of control from the point of the exception back 
> to (approximately) [NSApplication sendEvent:]?
> 
> If you don't own the low-level code where the exception was thrown, you can 
> have no confidence that non-stack data structures being maintained by that 
> code -- along with all of the intermediate levels of calling code -- are in 
> any usable state.
> 


I totally agree - from the point of view of a developer.

However, from the point of view of a) the user and b) the director of a company 
making and selling apps, it's not what you want to happen. Any crash is 
unacceptable - it makes the app look flaky and the user will lose faith in it 
and probably lose their data too. The vast majority of exceptions in practice 
are benign - much better to effectively ignore them and continue as best you 
can (which is very often with 100% functionality) than crash. If there are 
cases that come up that can be handled better, then those handlers can be added 
in later.

As an example, I had one recently where under very specific circumstances, the 
user could end up pushing the code into inverting a transform that had no 
inverse, e.g. a divide by zero. The Core Graphics framework throws an exception 
if you do that, but the specific circumstances had not been caught in testing 
because it was such a weird corner case. If my app crashed at that point, it 
would look very serious indeed, whereas the actual outcome for the user was a 
very minor graphical glitch. I now add a handler for that case that puts things 
back in a good state, but simply ignoring the original exception wasn't a 
disaster either.

--Graham



___

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: Exiting non-POSIX threads?

[Kyle Sluder]

On Wed, Jul 31, 2013, at 12:07 AM, Graham Cox wrote:
> However, from the point of view of a) the user and b) the director of a
> company making and selling apps, it's not what you want to happen.

Within the past year or so, we moved all our apps to crashing on
uncaught exceptions. This change was supported by our CEO. And as far as
I'm aware, OmniFocus has _always_ crashed on uncaught exceptions.

Because crashing is better than corrupting the user's data.

--Kyle Sluder
___

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: Exiting non-POSIX threads?

[Scott Ribe]

On Jul 30, 2013, at 11:51 PM, Oleg Krupnov  wrote:

> One downside
> of it though is that the user should launch the crashed app at least
> one more time.

Which is why he specifically mentioned the option of an external watchdog 
process.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: Exiting non-POSIX threads?

[Oleg Krupnov]

> Which is why he specifically mentioned the option of an external watchdog 
> process.

This seems like an overkill. Every app needs some kind of crash
reporting, are you suggesting to accompany each app with a watchdog
process? Besides, the user might think your app is a spyware when he
sees the watchdog process in Activity Monitor.
___

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: Exiting non-POSIX threads?

[Scott Ribe]

On Jul 31, 2013, at 8:23 AM, Oleg Krupnov  wrote:

> Every app needs some kind of crash
> reporting, are you suggesting to accompany each app with a watchdog
> process?

Yes. (Unless you're distributing through the Mac App Store.)

> Besides, the user might think your app is a spyware when he
> sees the watchdog process in Activity Monitor.

Why? "MyApp_CrashReporter" shouldn't raise any red flags, especially if you 
give the user the *decision* as to whether to allow this or not--and if you 
don't, it really is spyware anyway--mild spyware, for an innocuous purpose, but 
regardless, sending yourself information about your user's activity without 
your user's permission is exactly that.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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: Exiting non-POSIX threads?

[Fritz Anderson]

On 31 Jul 2013, at 9:23 AM, Oleg Krupnov  wrote:

>> Which is why he specifically mentioned the option of an external watchdog 
>> process.
> 
> This seems like an overkill. Every app needs some kind of crash
> reporting, are you suggesting to accompany each app with a watchdog
> process? Besides, the user might think your app is a spyware when he
> sees the watchdog process in Activity Monitor.

Yes.

It has these advantages:

• It the practice of almost every high-end third-party developer I've 
encountered. Perhaps I am biased by my opinion that applications are high-end 
if they adopt this practice.

• It assures the user that the developer will receive the report. I have no 
such faith in Apple's crash reporter.

It has these defenses:

• By definition, the best way to do a job is not "overkill," a term that isn't 
to be confused with "more work for the developer."

• People don't run ps(1) or Activity Monitor. Those who do see dozens of 
processes they can't identify. Those who pass that threshold know enough to 
look for the parent process (your application). Those who can't do that, and 
kill it, deserve what they get; they haven't lost any of the functionality they 
expect.

• A small, sleeping process consumes practically no resources. There is no 
cause for horror.

— F


___

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: Exiting non-POSIX threads?

[Richard Somers]

On Jul 29, 2013, at 2:34 AM, Oleg Krupnov  wrote:

> Is there a way to exit a GCD thread?

You can exit a GCD thread with something like this.

- (void)invalidateQueue
{
_isQueueCanceled = YES;
dispatch_sync(_queue, ^{});
}

- (void)submitWorkToBeDone
{
dispatch_async(_queue, ^{
for ( ... ) {
if (_isQueueCanceled == YES) {
break;
} else {
// do work
}
}
});
}

When invalidateQueue returns the thread has been canceled.

Richard Somers

___

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: Exiting non-POSIX threads?

[Sean McBride]

On Thu, 1 Aug 2013 08:55:59 -0600, Richard Somers said:

>> Is there a way to exit a GCD thread?
>
>You can exit a GCD thread with something like this.

That's fine if you own/have acces to the GCD queue.  Oleg is talking about a 
general purpose framework crash/exception reporting framework, which needs to 
deal with exceptions from any thread from any code. 

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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: Exiting non-POSIX threads?

[Kyle Sluder]

On Thu, Aug 1, 2013, at 07:55 AM, Richard Somers wrote:

> - (void)submitWorkToBeDone
> {
> dispatch_async(_queue, ^{
> for ( ... ) {

NEVER do this.

You don't own the thread. GCD does.

--Kyle Sluder
___

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: Exiting non-POSIX threads?

[Greg Parker]

On Jul 30, 2013, at 10:51 PM, Oleg Krupnov  wrote:
> 1. What is the correct way of terminating the app if the exception
> happens in the main thread? I need the system Crash Reporter to save
> the context and stack trace of the original problem, not of some
> exception handler.

Re-throw the exception and let the uncaught exception handler halt the process. 
The uncaught exception handler should be able to add the backtrace of the 
uncaught exception's throw point to the system crash log. Recent OS versions do 
a better job of recording this, though I can't remember offhand what is in 
Mountain Lion and what is in Mavericks.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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: Exiting non-POSIX threads?

[Jens Alfke]

On Jul 30, 2013, at 2:32 AM, j.carlson  wrote:

> In my case, the exception has already been thrown inside the block and
> I cannot catch it or modify it in any way in my handler. I'm basically
> writing an uncaught exception handler. My app should show a crash
> report window and then terminate itself.

Setting the user default NSApplicationShowExceptions to YES enables the 
standard uncaught-exception alert in your process; so if there’s an uncaught 
exception on any thread, the alert automatically pops up (with some info about 
the exception) and gives the user the choice to continue or crash.

—Jens
___

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