Re: Storing bundle loaded main class instances in NSArray

[Alexander Spohr]

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 stream is garbage.

Please post the allocation/deallocation code around the fread.

atze



Am 09.04.2009 um 15:57 schrieb Daniel Luis dos Santos:


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 fread call (standard libc) that I do  
just before the exception is thrown. If I comment the fread the  
error appears at another point in the code when I am initializing a  
NSDictionary with dictionaryWithDictionary. That other error shows  
itself in the gdb log as a pointer  modified after being freed.


Since this error is a bit difficult to track and explain through  
emails, I appreciate all your help, and think I will try to debug  
some more (change the code to some other way of doing it).


Thanks anyway


On Apr 9, 2009, at 1:38 AM, Graham Cox wrote:



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 point  
to NSFileManager or an array, as the code implies?


You're confused, so the rest of us have no chance.

Regarding your comments about autorelease pools, sounds like you're  
relying on some assumed behaviour that is not stated anywhere in  
any documentation. Don't do that, you're just creating problems  
that don't need to be there. What about the autorelease pools  
created around the main event loop for example?


--Graham




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/atze%40freeport.de

This email sent to a...@freeport.de


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Daniel Luis dos Santos]

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 fread call (standard libc) that I do  
just before the exception is thrown. If I comment the fread the error  
appears at another point in the code when I am initializing a  
NSDictionary with dictionaryWithDictionary. That other error shows  
itself in the gdb log as a pointer  modified after being freed.


Since this error is a bit difficult to track and explain through  
emails, I appreciate all your help, and think I will try to debug some  
more (change the code to some other way of doing it).


Thanks anyway


On Apr 9, 2009, at 1:38 AM, Graham Cox wrote:



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 point  
to NSFileManager or an array, as the code implies?


You're confused, so the rest of us have no chance.

Regarding your comments about autorelease pools, sounds like you're  
relying on some assumed behaviour that is not stated anywhere in any  
documentation. Don't do that, you're just creating problems that  
don't need to be there. What about the autorelease pools created  
around the main event loop for example?


--Graham




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Graham Cox]

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 point to  
NSFileManager or an array, as the code implies?


You're confused, so the rest of us have no chance.

Regarding your comments about autorelease pools, sounds like you're  
relying on some assumed behaviour that is not stated anywhere in any  
documentation. Don't do that, you're just creating problems that don't  
need to be there. What about the autorelease pools created around the  
main event loop for example?


--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Bill Bumgarner]

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

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Kyle Sluder]

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
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Daniel Luis dos Santos]

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 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 look like it, but I'd focus -- instead -- on the original  
bug.   Run with Zombies enabled.  Figure out why you end up with a  
File Manager reference where you expect an array reference.


b.bum



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Bill Bumgarner]

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 look like it, but I'd focus -- instead -- on the original  
bug.   Run with Zombies enabled.  Figure out why you end up with a  
File Manager reference where you expect an array reference.


b.bum

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Daniel Luis dos Santos]

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, 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 something is  
over-released and something else subsequently receives messages  
destined for the over-released object.


A terribly common error, actually -- quite typical.

And this statement:

When I uncomment the addObject line above, later in the code  
NSFileManager throws a doesNotRespondToSelector exception, which is  
very odd.


Backs up that assessment.

So... fix your memory management to be in line with the guidelines  
*then* try and debug the problem.   Of course, fixing the memory  
management might just make the problem go away entirely.


Since this appears to be relatively new code, one possible fix would  
be to simply turn on GC.  If it is a command line tool -- or a  
daemon -- read the docs on how to start the collector thread.


b.bum



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Bill Bumgarner]

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 something is  
over-released and something else subsequently receives messages  
destined for the over-released object.


A terribly common error, actually -- quite typical.

And this statement:

When I uncomment the addObject line above, later in the code  
NSFileManager throws a doesNotRespondToSelector exception, which is  
very odd.


Backs up that assessment.

So... fix your memory management to be in line with the guidelines  
*then* try and debug the problem.   Of course, fixing the memory  
management might just make the problem go away entirely.


Since this appears to be relatively new code, one possible fix would  
be to simply turn on GC.  If it is a command line tool -- or a daemon  
-- read the docs on how to start the collector thread.


b.bum

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Daniel Luis dos Santos]

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 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




That's not what the memory management rules tell you to do.

How do you know that there isn't an auto-release pool outside of  
that which gets cleaned up (and nested auto release pools are  
automatically cleaned up when the outer one is)?



Glenn Andreas  gandr...@gandreas.com
 wicked fun!
Mad, Bad, and Dangerous to Know



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[glenn andreas]

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




That's not what the memory management rules tell you to do.

How do you know that there isn't an auto-release pool outside of that  
which gets cleaned up (and nested auto release pools are automatically  
cleaned up when the outer one is)?



Glenn Andreas  gandr...@gandreas.com
  wicked fun!
Mad, Bad, and Dangerous to Know

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Daniel Luis dos Santos]

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 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:...].


When an object is released, the underlying memory is reclaimed but  
any variables that were referencing the object are unmodified so  
they now point to garbage.


And as for zombies, Google is your friend. The first hit for  
NSZombieEnabled gives a good description.



On Apr 8, 2009, at 6:15 AM, Daniel Luis dos Santos wrote:

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 selector sent to instance 0x1126f0


When releasing a pointer does its value change ? or it just  
releases the memory ?

What is that zombie thing you're talking about ?


On Apr 8, 2009, at 1:53 PM, Graham Cox wrote:



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 doesNotRespondToSelector exception, which  
is very odd.





Still not enough to go on.

Where is _instances initialised? Is it released anywhere? What  
does the exception log? Is it possible _instances could be being  
released leaving a stale pointer that points to NSFileManager?  
Have you run it with NSZombieEnabled turned on? Any difference?


Please post the *relevant* code.

--Graham




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Steve Christensen]

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:...].


When an object is released, the underlying memory is reclaimed but  
any variables that were referencing the object are unmodified so they  
now point to garbage.


And as for zombies, Google is your friend. The first hit for  
NSZombieEnabled gives a good description.



On Apr 8, 2009, at 6:15 AM, Daniel Luis dos Santos wrote:

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 selector sent to instance 0x1126f0


When releasing a pointer does its value change ? or it just  
releases the memory ?

What is that zombie thing you're talking about ?


On Apr 8, 2009, at 1:53 PM, Graham Cox wrote:



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 doesNotRespondToSelector exception, which  
is very odd.





Still not enough to go on.

Where is _instances initialised? Is it released anywhere? What  
does the exception log? Is it possible _instances could be being  
released leaving a stale pointer that points to NSFileManager?  
Have you run it with NSZombieEnabled turned on? Any difference?


Please post the *relevant* code.

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Daniel Luis dos Santos]

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 selector sent to instance 0x1126f0


When releasing a pointer does its value change ? or it just releases  
the memory ?

What is that zombie thing you're talking about ?


On Apr 8, 2009, at 1:53 PM, Graham Cox wrote:



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 doesNotRespondToSelector exception, which  
is very odd.





Still not enough to go on.

Where is _instances initialised? Is it released anywhere? What does  
the exception log? Is it possible _instances could be being released  
leaving a stale pointer that points to NSFileManager? Have you run  
it with NSZombieEnabled turned on? Any difference?


Please post the *relevant* code.

--Graham




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Graham Cox]

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 doesNotRespondToSelector exception, which is  
very odd.





Still not enough to go on.

Where is _instances initialised? Is it released anywhere? What does  
the exception log? Is it possible _instances could be being released  
leaving a stale pointer that points to NSFileManager? Have you run it  
with NSZombieEnabled turned on? Any difference?


Please post the *relevant* code.

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Fwd: Storing bundle loaded main class instances in NSArray

[Daniel Luis dos Santos]

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 :

	NSString *bundlePath = (NSString*)[_configuration objectForKey:  
DRIVERBUNDLE_PATH];

NSBundle *bundle = [NSBundle bundleWithPath: bundlePath];

if (nil == bundle) {
		[errorLog addObject: [NSNumber numberWithInt:  
DRIVER_ERRORCODE_BUNDLEMISSINGATPATH]];

*logList = [NSArray arrayWithArray: errorLog];
return nil;
}

Class driverClass = [bundle principalClass];
if ((nil == driverClass) ||
		![driverClass conformsToProtocol:  
@protocol(StorageDriverInterface)]) {
		[errorLog addObject: [NSNumber numberWithInt:  
DRIVER_ERRORCODE_BUNDLEMAINCLASSNOTCOMPLIANT]];

*logList = [NSArray arrayWithArray: errorLog];
return nil;
}
_bundle = bundle;

fine until there, then later in the same method inside a loop where  
I initialize several instances of the principal class:


	id  aDriverInstance = [[driverClass alloc]  
init: driverConfig callingbackto: callback logTo:  
&interfaceInitLogList];


That instantiates the object whose class was loaded.  Then in the  
same loop afterwards I want to add the previous id to an NSArray


	id saID = [_parametersOfLatestInitializedSA objectForKey:  
CONFIG_SAID];
	if ((nil != saID) && ([[saID class] isSubclassOfClass: [NSData  
class]])) {

//[_instances addObject: aDriverInstance];
[_instanceIDs addObject: saID];
[mutableInstanceDict setObject: saID forKey: CONFIG_SAID];
} else {
if (!errorOcurred) {
[errorLog addObject: [NSNumber numberWithInt: index]];
errorOcurred = YES;
}
		[errorLog addObject: [NSNumber numberWithInt:  
DRIVER_ERRORCODE_INSTANCEDIDNOTREPORTID]];

}

When I uncomment the addObject line above, later in the code  
NSFileManager throws a doesNotRespondToSelector exception, which is  
very odd.





On Apr 8, 2009, at 1:31 AM, Graham Cox wrote:



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 instantiate from the bundle is handled through a  
protocol. The implementation is derived from an NSObject. I have  
considered using an NSPointerArray instead.



Show your code.

This word description is not very enlightening to anyone except  
you, who are familiar with the code.


Sounds like it could be an over-release problem, but without seeing  
the code, who knows?


--Graham






___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storing bundle loaded main class instances in NSArray

[Graham Cox]

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 instantiate from the bundle is handled through a  
protocol. The implementation is derived from an NSObject. I have  
considered using an NSPointerArray instead.



Show your code.

This word description is not very enlightening to anyone except you,  
who are familiar with the code.


Sounds like it could be an over-release problem, but without seeing  
the code, who knows?


--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Storing bundle loaded main class instances in NSArray

[Daniel Luis dos Santos]

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 the array that causes the  
code later to behave unstable and failing with a message like :


2009-04-08 01:03:48.357 TestRunner[9643:813] *** -[NSFileManager  
fileExistsAtPath:]: unrecognized selector sent to instance 0x1126f0


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 instantiate from the bundle is handled through a  
protocol. The implementation is derived from an NSObject. I have  
considered using an NSPointerArray instead.


Help!


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com