Hello,
I have some code that loads a bundle like :
[NSBundle bundleForPath: path]
Then I get its main class. Then I cycle through some parameters that
initialize that loaded main class and stores each new instance in a
NSMutableArray.
Problem is that when I do the assignment to th
On 08/04/2009, at 10:23 AM, Daniel Luis dos Santos wrote:
The only thing I can think of, to see something like this is that I
am probably overwriting the NSFileManager's class internal tables
and therefore the message. When I comment out the assignment it all
goes well.
The class that I
Sorry. Sent the original to another list
Begin forwarded message:
From: Daniel Luis dos Santos
Date: April 8, 2009 1:02:18 PM GMT+01:00
To: Graham Cox
Cc: list Xcode-users
Subject: Re: Storing bundle loaded main class instances in NSArray
Ok, here goes,
This is were I load the bundle
On 08/04/2009, at 10:33 PM, Daniel Luis dos Santos wrote:
if ((nil != saID) && ([[saID class] isSubclassOfClass: [NSData
class]])) {
//[_instances addObject: aDriverInstance];
When I uncomment the addObject line above, later in the code
NSFileManager throws a doesNotRespon
The _instances mutable array is instantiated in the default init
method that is called on all other init methods. It is never released.
I am using an Auto release pool. The log writes ;
2009-04-08 13:56:53.189 TestRunner[2568:813] *** -[NSFileManager
fileExistsAtPath:]: unrecognized selecto
If your _instances variable is initialized using either
[NSMutableArray array] or [NSMutableArray arrayWithCapacity:...], it
will be autoreleased and become invalid. You can fix that by doing
something like [NSMutableArray array] retain] or using
[NSMutableArray alloc] initWithCapacity:...]
Since I am using an auto release pool that is created before anything
else, those initializers create auto released objects that will only
be released at the end of the code execution. They will be valid until
the program terminates
On Apr 8, 2009, at 3:01 PM, Steve Christensen wrote:
If
On Apr 8, 2009, at 9:34 AM, Daniel Luis dos Santos wrote:
Since I am using an auto release pool that is created before
anything else, those initializers create auto released objects that
will only be released at the end of the code execution. They will be
valid until the program terminates
If its outer and the code is done right, it should be disposed of when
the code within it is no longer needed
On Apr 8, 2009, at 3:46 PM, glenn andreas wrote:
On Apr 8, 2009, at 9:34 AM, Daniel Luis dos Santos wrote:
Since I am using an auto release pool that is created before
anything e
On Apr 8, 2009, at 7:55 AM, Daniel Luis dos Santos wrote:
If its outer and the code is done right, it should be disposed of
when the code within it is no longer needed
That still isn't correct according to the Cocoa memory management
guidelines. Thus, the general conclusion will be that so
I just discovered that if I don't load the code through a bundle and
link it directly to the executable the error goes away. From the
bundle loading code I posted at the beginning of this thread, am I
doing anything wrong ?
On Apr 8, 2009, at 4:34 PM, Bill Bumgarner wrote:
On Apr 8, 200
On Apr 8, 2009, at 8:48 AM, Daniel Luis dos Santos wrote:
I just discovered that if I don't load the code through a bundle and
link it directly to the executable the error goes away. From the
bundle loading code I posted at the beginning of this thread, am I
doing anything wrong ?
Doesn't
I expect a file manager and it tells me that it does not respond to
fileExistsAtPath
On Apr 8, 2009, at 5:05 PM, Bill Bumgarner wrote:
On Apr 8, 2009, at 8:48 AM, Daniel Luis dos Santos wrote:
I just discovered that if I don't load the code through a bundle
and link it directly to the exec
On Wed, Apr 8, 2009 at 12:13 PM, Daniel Luis dos Santos
wrote:
> I expect a file manager and it tells me that it does not respond to
> fileExistsAtPath
Until you fix your memory management bug, the behavior of your program
is undefined.
--Kyle Sluder
_
On Apr 8, 2009, at 9:13 AM, Daniel Luis dos Santos wrote:
I expect a file manager and it tells me that it does not respond to
fileExistsAtPath
I'm terribly confused, then. Set a breakpoint on objc_exception_throw
and post the backtrace at the point that the exception is thrown.
b.bum
___
On 09/04/2009, at 2:13 AM, Daniel Luis dos Santos wrote:
I expect a file manager and it tells me that it does not respond to
fileExistsAtPath
No you don't.
According to your original post, you are complaining that calling -
addObject on _instances throws this error. So does _instances poi
Summarizing the behaviour I see here
If I add an object (which is the principal class of a bundle) to an
NSMutableArray, later in the program I get the exception that the
NSFileManager default manager object does not respond to a known
message selector.
I further narrowed it down to a frea
Sorry I did not follow this thread as I thought it was a clear malloc/
free error.
size_t fread(void * restrict ptr, size_t size, size_t nmemb,
FILE * restrict stream);
Where is your ptr coming from?
If you comment out fread but rthe just crash somewhere else I’d bet
your ptr or strea
18 matches
Mail list logo