Re: Mystery threads eating CPU cycles (more info!)

FROM : Mike Laster
DATE : Thu Nov 21 22:50:19 2002

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_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.