Re: loading windows & SIGBUS
Re: loading windows & SIGBUS
- Subject: Re: loading windows & SIGBUS
- From: <email@hidden>
- Date: Thu, 2 Jan 2003 15:56:41 -0800
Hello,
From a initial look at the code, it looks ok. so the answer lies elsewhere.
Now +alloc uses malloc()/dynamic memory allocation. It is possible (even
probable?) that your problem lies in another part of your code which is
smashing the dynamic memory allocation environment?
I looked in the Developer/Application directory, and I show there are 2 tools
which could help you right off the bat:
- MallocDebug
- ObjectAlloc
Which should help you figure out exactly what is happening in your malloc
environment.
There are other tools which can help you with malloc problems. Looking in the
documentation, Apple reccomends using 'malloc_history' (a command line tool)
which gives you a history of the mallocs a program has done.
There are other tools like electric fence, purify, etc which help you find
where memory 'stomps' (overwrites) are happening (a common cause of malloc
problems).
Good luck! Let us know what you find!
Regards,
-ryan
Carrie Brezine <email@hidden> said:
>
Hello, Happy New Year! mine is starting with a bang, or rather a
>
crash... one of those everything-was-fine now
>
what's-wrong-all-of-a-sudden days. Here's the situation:
>
>
I have a login window, the first window that appears in my application.
>
This window has an "open" button which is linked to an "open" method
>
which should load and display another window where a user can actually
>
do something. I've been using shared window controllers for loading
>
windows. All of a sudden I am getting a SIGBUS and crash when it tries
>
to open the next window. It fails on the -alloc method-- I know the
>
second window controller never gets to the init method because I have
>
logs in there that never get written out. Code is below-- similar code
>
is still working in other applications. What did I do? Why would an
>
alloc cause a SIGBUS?
>
>
totally mystified,
>
>
carrie
>
>
code from login window
>
//when user chooses "open" button,
>
//validate name and password
>
//if validation fails, send message
>
//if validation succeeds, set userid for db connectivity
>
//and show next window
>
- (IBAction)open:(id)sender
>
{
>
//validation actually will occur in the "setFBDC" method
>
//set name & passoword according to what user entered
>
[self setName:[txtName stringValue]];
>
[self setPassword:[txtPassword stringValue]];
>
//if connection is successful, show next window
>
//setFBDC is a method which creates a db connection and returns BOOL
>
if ([self setFBDCWith:name :password])
>
{
>
>>It breaks on this next line
>
[GroupWindowController sharedGroupWindowController];
>
[[GroupWindowController sharedGroupWindowController]
>
showWindow:sender];
>
>
//[[self window] orderOut:sender];
>
}else
>
//otherwise, do nothing--user alert happens in setFBDC method
>
{
>
NSLog(@"we didn't connect.");
>
}
>
}
>
>
code from GroupWindowController, subclass of WindowController
>
>
//create static shared instance of this class
>
+ (id) sharedGroupWindowController
>
{
>
static GroupWindowController *_sharedGroupWindowController = nil;
>
if (!_sharedGroupWindowController)
>
{
>
_sharedGroupWindowController =
>
[[GroupWindowController allocWithZone:[self zone]] init];
>
>>debugger shows an "EXC_BAD_ACCESS" error and application crashes.
>
Use of -alloc instead of -allocWithZone still produces a crash.
>
}
>
>
return _sharedGroupWindowController;
>
}
>
_______________________________________________
>
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.
_______________________________________________
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.