Newbie SIGBUS Error

Newbie SIGBUS Error

Post by Colin Kirkh » Fri, 18 Jul 2003 17:16:33



Hi all,

I'm afraid this question is probably old hat to all of you, but I
can't seem to find out why the following code is wrong.  I have
tracked down the exact line causing the problem, but do not understand
exactly why the error is caused.  Could it be because I have not
directly created the object (using the alloc and init messages), but
received it from a method on another object?  If so, how do I release
the memory used for the reference correctly?

Any clarifications would be gratefully received.  Also, on Mac OS X
does anyone know how on earth I can find the documentation for
NSRange.  It doesn't appear on the listing in the Cocoa documentation
(although NSString does).  Again, any pointers would be truly
appreciated.

Many thanks,

Colin

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
  NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];



  int count = [array count];

  int i;
  for (i = 0; i < count; i++) {
    printf("%i: %s\n", i, [[array objectAtIndex:i] UTF8String]);
  }

  [string release];
  // This release causes a "arrays has exited due to signal 10
(SIGBUS)."
  // [array release];
  [pool release];
  return 0;

Quote:}

 
 
 

Newbie SIGBUS Error

Post by Stefan Arent » Fri, 18 Jul 2003 17:22:11



> Hi all,

> I'm afraid this question is probably old hat to all of you, but I
> can't seem to find out why the following code is wrong.  I have
> tracked down the exact line causing the problem, but do not understand
> exactly why the error is caused.  Could it be because I have not
> directly created the object (using the alloc and init messages), but
> received it from a method on another object?  If so, how do I release
> the memory used for the reference correctly?

The rules for the retain/release system are very simple; only release what you
retained. So there is no need to release either the string or the array.

Here is all you need to know:

 <http://www.stepwise.com/Articles/Technical/2001-03-11.01.html>

Quote:> Any clarifications would be gratefully received.  Also, on Mac OS X
> does anyone know how on earth I can find the documentation for
> NSRange.  It doesn't appear on the listing in the Cocoa documentation
> (although NSString does).  Again, any pointers would be truly
> appreciated.

NSRange is not a class but a simple struct. It is documented here:

 <http://developer.apple.com/documentation/Cocoa/Reference/Foundation/O...>

 S.

 
 
 

Newbie SIGBUS Error

Post by Colin Kirkh » Sat, 19 Jul 2003 00:05:28


Thanks very much for the info Stefan, the url's were very useful
indeed.

One point though, according to the Stepwise article the 'string'
variable should be released as it is in the same block as the alloc.
I know the closing of the application will take care of it, but for
completeness its probably worth mentioning right?

Colin

 
 
 

Newbie SIGBUS Error

Post by Erik M. Buc » Sat, 19 Jul 2003 04:06:21



Quote:> Thanks very much for the info Stefan, the url's were very useful
> indeed.

> One point though, according to the Stepwise article the 'string'
> variable should be released as it is in the same block as the alloc.
> I know the closing of the application will take care of it, but for
> completeness its probably worth mentioning right?

> Colin

It is harmless to release the string, but it is not necessary.  The string
is not allocated.  You didn't send a message that includes the word "alloc".
The string was generated by the compiler and is constant.  It can't be
deallocated because it is part of the program's binary image. However, as
motioned, it is harmless to release it because such strings ignore release
messages.

You don't need to know about constant strings of course.  All you need to
know is that if use send a message with the words alloc, copy, or retain in
it to an object, you must release or autorelease the object.  If you didn't
send a message with the words alloc, copy, or retain in it  you must NOT
release or autorelease it.  To be consistent and follow the rules, you
probably should NOT send release to the constant string.

 
 
 

Newbie SIGBUS Error

Post by David Ste » Sat, 19 Jul 2003 05:50:16



>  [string release];
>  // This release causes a "arrays has exited due to signal 10
> (SIGBUS)."
>  // [array release];

Try to see whether adding a couple of -retain messages fixes the problem.

This is a known problem with the design of the autorelease pool memory
management.

 
 
 

Newbie SIGBUS Error

Post by David Ste » Sat, 19 Jul 2003 06:51:08



Quote:

> To be consistent and follow the rules, you
> probably should NOT send release to the constant string.

If this is the problem, then it is really bad for design of container classes.

Suppose you have a class that accepts as input an object.  It should always
deal with the object in the same way; why should it make a difference between
constant strings and 'other' strings ?

The right thing to do is then to implement -release as a "no operation" for
the constant string, so that all objects are dealt with in a uniform way,
and that nothing happens for constant strings that should not be released.

(if this is the problem at all, because I think it is
more like a 'regular' autorelease SIGBUS).

 
 
 

Newbie SIGBUS Error

Post by Christian Brunsch » Sat, 19 Jul 2003 07:23:26





>>  [string release];
>>  // This release causes a "arrays has exited due to signal 10
>> (SIGBUS)."
>>  // [array release];

>Try to see whether adding a couple of -retain messages fixes the problem.

>This is a known problem with the design of the autorelease pool memory
>management.

What is a well-known problem is David Stes' aversion to anything involving
Apple or NeXT, and indeed Cocoa's retain-counting memory management in
particular. His suggestion to essentially randomly retain objects shows
precisely how little he knows and understands about the issue, however;
and indeed, his post is most likely simply an attempt to spread FUD
('Fear, Uncertainty and Doubt'), by making wildly inaccurate statements.

Much better advice to Mr. Kirkham is indeed to read the article on Cocoa's
memory management at

  <http://www.stepwise.com/Articles/Technical/2001-03-11.01.html>

which explains the very simple rules both concisely and well. If you'd
prefer a longer and even more detailed explanation, take a look at

  <http://www.stepwise.com/Articles/Technical/HoldMe.html>

Best wishes,

// Christian Brunschen

 
 
 

Newbie SIGBUS Error

Post by publiclo » Sat, 19 Jul 2003 23:39:10




> > To be consistent and follow the rules, you
> > probably should NOT send release to the constant string.

> If this is the problem, then it is really bad for design of container classes.

> Suppose you have a class that accepts as input an object.  It should always
> deal with the object in the same way; why should it make a difference between
> constant strings and 'other' strings ?

> The right thing to do is then to implement -release as a "no operation" for
> the constant string, so that all objects are dealt with in a uniform way,
> and that nothing happens for constant strings that should not be released.

> (if this is the problem at all, because I think it is
> more like a 'regular' autorelease SIGBUS).

Mr. Stes, please read what I wrote.  The constant string does in fact
ignore the release (implement -release as a "no operation") and
everything works fine for collections and in any other situation with
anonymous objects.  Ironically, you and I are in complete agreement
about "the right thing to do", and guess what, that id how the Cocoa
frameworks work.  Congratulations, you agree with Cocoa's
implementation.  I just wish you would read what I wrote before trying
to disagree with it.
 
 
 

Newbie SIGBUS Error

Post by Colin Kirkh » Sun, 20 Jul 2003 01:14:16


Thanks Christian,

I have now scoured Stepwise for all the documents on memory management
and believe I have it clear in my mind.  For some reason I was
convinced I had alloc'd the string rather than it being a constant -
too many small examples in too short a time I guess.

Thanks a lot for all your help people, erm well almost all anyway.
Luckily FUD won't work on me - I "fear" I "certain"ly don't know
enough about objective-c yet, and don't "doubt" I have a lot to learn,
but am enjoying working with it and it makes a change from Java.

Cheers again for the help.

Colin

 
 
 

Newbie SIGBUS Error

Post by Christian Brunsch » Sun, 20 Jul 2003 01:34:19




>Thanks Christian,

>I have now scoured Stepwise for all the documents on memory management
>and believe I have it clear in my mind.  

Excellent :) Of course, if you have any further questions, please don't
hesitate to ask.

One suggestion, though: If you're going to be developing mainly for Mac OS
X, then you might want to get in touch with some of the Mac development
newsgroups, or some of the mailing lists at lists.apple.com or
www.omnigroup.com .

Quote:>For some reason I was
>convinced I had alloc'd the string rather than it being a constant -
>too many small examples in too short a time I guess.

Yeah, information overload can do that :)

Quote:>Thanks a lot for all your help people, erm well almost all anyway.
>Luckily FUD won't work on me - I "fear" I "certain"ly don't know
>enough about objective-c yet, and don't "doubt" I have a lot to learn,

Oh, we all have lots to learn, I know I do - indeed, learning is one of
the most fun things I know!

Quote:>but am enjoying working with it and it makes a change from Java.

A pleasant change, I hope :)

Quote:>Cheers again for the help.

Best wishes,

Quote:>Colin

// Christian Brunschen
 
 
 

Newbie SIGBUS Error

Post by John C. Randolp » Sun, 20 Jul 2003 05:57:32



> Hi all,

> I'm afraid this question is probably old hat to all of you, but I
> can't seem to find out why the following code is wrong.  


[snip]

Quote:>   [string release];

It's an error to try to release a constant string object.

-jcr

 
 
 

Newbie SIGBUS Error

Post by David Ste » Sun, 20 Jul 2003 18:55:05



Quote:

> It's an error to try to release a constant string object.

Unless you retain it first ...

If a program mysteriously "core dumps" or you experience SIGBUS etc. for
some strange reason, it's always a good idea to add -retain messages in
your code.

If that fixes the problem, then open a support call with Apple and tell'em
adding -retain fixed the problem.

 
 
 

Newbie SIGBUS Error

Post by John C. Randolp » Mon, 21 Jul 2003 02:53:24




> > It's an error to try to release a constant string object.

> Unless you retain it first ...

> If a program mysteriously "core dumps" or you experience SIGBUS etc. for
> some strange reason, it's always a good idea to add -retain messages in
> your code.

No.  The right thing to do is run the program under GDB, and see what
was going on when the SIGBUS ocurred.

-jcr

 
 
 

Newbie SIGBUS Error

Post by Christian Brunsch » Sun, 20 Jul 2003 23:13:32





>> It's an error to try to release a constant string object.

>Unless you retain it first ...

>If a program mysteriously "core dumps" or you experience SIGBUS etc. for
>some strange reason, it's always a good idea to add -retain messages in
>your code.

>If that fixes the problem, then open a support call with Apple and tell'em
>adding -retain fixed the problem.

The above is like saying that if a C program core dumps or similar, it is
always a good idea to remove some free() statements from your code, and
that if that fixes the problem you should call Microsoft and tell them
there''s a bug in free().

David Stes' suggestion is also exactly as _wrong_, and goes to show just
how little David Stes understands about Cocoa's memory management.

In general, the solution is of course to inspect the code, perhaps run it
through a de*, and find out exactly what is going on, and find the
code that is causing the problem. A thorough understanding of the Cocoa
memory management mechanism is very helpful of course, and fortunately not
very difficult to gain; documentation has been referred to in other posts
in this thread.

Best wishes,

// Christian Brunschen

 
 
 

Newbie SIGBUS Error

Post by David Ste » Mon, 21 Jul 2003 18:17:23



> David Stes' suggestion is also exactly as _wrong_, and goes to show just
> how little David Stes understands about Cocoa's memory management.

Well there is some confusing input on how it actually works:

        a) retain/release have been implemented as "NOPs" for constant strings
        b) retain/release work, but dealloc causes the thing to crash

So it must be one of those two options.

John Randolph (who is a faithful Apple maniac, working at Apple in fact) said
it is option (b), so I'm assuming it is the option b.  In that case, the
dealloc crash can be avoided by adding -retain messages.

 
 
 

1. SIGBUS and threads

Hello,

    Currently, I am working on a multi-threaded application using
Solaris threads under Solaris x86 2.6.  The machine is a single
processor machine and all of the threads are bound.

    During development, my process was getting a bus error causing the
whole thing to core dump.  I quickly coded up a signal handler to log
which thread is currently running and to exit the thread using
thr_exit().

    My question is that I know that the signal handler is executed in
whatever thread is currently running, according the Threads Primer.  Is
there the potential that the LWP could be swapped out before the signal
handler runs causing me to report the wrong thread to my log?  Or will
the signal handler always be handled in the offending thread?

dennis

2. Whether to use a Screen or a View..

3. is SIGBUS directed to the thread that caused it?

4. CheckBoxList and client-side script

5. membar and MMU - which address caused the SIGBUS?

6. No PDF File Open in InDesign?

7. hpux11+pthreads+malloc -> SIGSEGV|SIGBUS

8. How to print the unicode with C ++?

9. pthreads, memory allocation, and SIGBUS on Solaris 2.x

10. Return Error Code from ControlService fuction (newbie)

11. Newbie: Access Error - AfxMessageBox in COM server

12. Newbie alert: compile errors involving dwStockPropMask

13. Newbie question - Getting Linker errors when trying to use lineInitialize and lineShutdown