Re: Mystery threads eating CPU cycles (more info!)
Re: Mystery threads eating CPU cycles (more info!)
- Subject: Re: Mystery threads eating CPU cycles (more info!)
- From: Mike Laster <email@hidden>
- Date: Thu, 21 Nov 2002 16:50:19 -0500
On Monday, November 11, 2002, at 02:34 PM, Douglas Davidson wrote:
How do you know you didn't create these threads? From the stack
traces? That's not evidence; the traces are corrupt. Is it because
you never spawn threads? There are cases in which frameworks spawn
threads for their own purposes; try looking at a sample from a
correctly running instance to see what those might be.
I tracked it down to an EXC_BAD_ACCESS happening sometimes. This leads
to another problem though. Aren't these supposed to be turned into
exceptions with the exception handling framework? I finally was able
to get the problem down into a very simple test case, and as far as I
can tell,
it appears to be a bug introduced in 10.2. The following code exhibits
the bug I see in my server. It will hang, sucking up loads of CPU and
have a backtrace that 'sample' cannot parse properly. Running the
sample program under 10.1 works correctly:
2002-11-21 16:45:06.001 crashtest[25274] >>> dereference bad pointer
2002-11-21 16:45:06.127 crashtest[25274] NSExceptionHandler has
recorded the following exception:
NSUncaughtSystemExceptionException -- Uncaught system exception: signal
11
Stack trace: 0x00002bec 0x00002994 0x000027c4
2002-11-21 16:45:06.128 crashtest[25274]
exceptionhandler:<NSExceptionHandler: 0x109820>
shouldHandleException:Uncaught system exception: signal 11 mask:0x8
2002-11-21 16:45:06.128 crashtest[25274] CAUGHT EXCEPTION!
2002-11-21 16:45:06.128 crashtest[25274] localException: Uncaught
system exception: signal 11
2002-11-21 16:45:06.129 crashtest[25274] <<< dereference bad pointer
crashtest has exited with status 0.
Here is the test program:
#import <Foundation/Foundation.h>
#import <ExceptionHandling/NSExceptionHandler.h>
@interface ExceptionHandlerDelegate: NSObject
@end
@implementation ExceptionHandlerDelegate
- (BOOL)exceptionHandler:(NSExceptionHandler *)sender
shouldHandleException:(NSException *)exception mask:(unsigned int)aMask
{
NSLog(@"exceptionhandler:%@ shouldHandleException:%@ mask:%#x",
sender, exception, aMask);
return YES;
}
@end
int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
char *badPtr = (char *)0xdeadbeef;
NSExceptionHandler *handler = [NSExceptionHandler
defaultExceptionHandler];
ExceptionHandlerDelegate *delegate = nil;
delegate = [[ExceptionHandlerDelegate alloc] init];
[handler setExceptionHandlingMask:NSLogAndHandleEveryExceptionMask];
[handler setDelegate:delegate];
NSLog(@">>> dereference bad pointer");
NS_DURING
NSLog(@"%c", *badPtr);
NS_HANDLER
NSLog(@"CAUGHT EXCEPTION!");
NSLog(@"localException: %@", localException);
NS_ENDHANDLER
NSLog(@"<<< dereference bad pointer");
[pool release];
return 0;
}
Is there any way I can work around this bug? My whole goal is to get a
backtrace whenver a sig11 occurs to make tracking down the bug easier.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.