Re: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
Sorry, I meant to send this to the list. Leo -- Forwarded message -- From: Leo Singer doc.aron...@gmail.com Date: Thu, Feb 19, 2009 at 1:28 PM Subject: Re: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation To: Greg Parker gpar...@apple.com Thanks for all of the input on this. I decided to override NSOperation's - start selector and make the thread myself. I wish that there was a way to adjust the stack size per NSOperationQueue. Maybe I should report that as a feature request. I would rather not dynamically allocate that particular array because the Cocoa application I am developing is simply a wrapper for a cross platform C++ project. This particular project has to manage a number of different resources, including an SQLite database connection, an open file, and a serial port device. In order to keep error handling as simple as possible, I have made heavy use of the RIAA pattern. If a serial port error occurs, for example, an exception gets thrown. As a result, the objects representing both the database and the open file go out of scope, and their resources are released. A std::vector would be unsuitable also because in my actual application (not the cooked example I sent out) I need to be able to manipulate that memory directly. Some more background information might be helpful. The application is a GUI for a bootloader for Microchip brand DSPs. The big array in question is actually a 256 kb image of the device's program memory. Thanks again, Leo On Wed, Feb 18, 2009 at 3:17 PM, Greg Parker gpar...@apple.com wrote: On Feb 18, 2009, at 3:22 AM, Michael Vannorsdel wrote: Really it would be best to malloc the space, use it, and free it. Once you get to huge stack usage you gamble that you won't run out when there can be other higher up calls also consuming some (frameworks, libs, 3rd party code, ect). Also if you only use the large amount once in a while then you have a bunch of unutilized memory sitting around. Agreed: use malloc for large memory allocations. One other limit that you apparently haven't run into yet: some architectures limit the maximum size of a single stack frame, even if there is lots of space on the stack. ppc has a maximum 64K stack frame size; arm may have a similar limit. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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/doc.aronnax%40gmail.com This email sent to doc.aron...@gmail.com ___ 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: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
On 19 Feb 2009, at 18:29, Leo Singer wrote: Sorry, I meant to send this to the list. Leo -- Forwarded message -- From: Leo Singer doc.aron...@gmail.com Date: Thu, Feb 19, 2009 at 1:28 PM Subject: Re: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation To: Greg Parker gpar...@apple.com Thanks for all of the input on this. I decided to override NSOperation's - start selector and make the thread myself. I wish that there was a way to adjust the stack size per NSOperationQueue. Maybe I should report that as a feature request. Operation queues share and re-use threads amongst themselves, so this almost certainly couldn't work in practice. Requesting stack size per NSOperation seems reasonable though. I would rather not dynamically allocate that particular array because the Cocoa application I am developing is simply a wrapper for a cross platform C++ project. This particular project has to manage a number of different resources, including an SQLite database connection, an open file, and a serial port device. In order to keep error handling as simple as possible, I have made heavy use of the RIAA pattern. If a serial port error occurs, for example, an exception gets thrown. As a result, the objects representing both the database and the open file go out of scope, and their resources are released. A std::vector would be unsuitable also because in my actual application (not the cooked example I sent out) I need to be able to manipulate that memory directly. Some more background information might be helpful. The application is a GUI for a bootloader for Microchip brand DSPs. The big array in question is actually a 256 kb image of the device's program memory. Thanks again, Leo On Wed, Feb 18, 2009 at 3:17 PM, Greg Parker gpar...@apple.com wrote: On Feb 18, 2009, at 3:22 AM, Michael Vannorsdel wrote: Really it would be best to malloc the space, use it, and free it. Once you get to huge stack usage you gamble that you won't run out when there can be other higher up calls also consuming some (frameworks, libs, 3rd party code, ect). Also if you only use the large amount once in a while then you have a bunch of unutilized memory sitting around. Agreed: use malloc for large memory allocations. One other limit that you apparently haven't run into yet: some architectures limit the maximum size of a single stack frame, even if there is lots of space on the stack. ppc has a maximum 64K stack frame size; arm may have a similar limit. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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/doc.aronnax%40gmail.com This email sent to doc.aron...@gmail.com ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
On Feb 19, 2009, at 10:29 AM, Leo Singer wrote: I would rather not dynamically allocate that particular array because the Cocoa application I am developing is simply a wrapper for a cross platform C++ project. This particular project has to manage a number of different resources, including an SQLite database connection, an open file, and a serial port device. In order to keep error handling as simple as possible, I have made heavy use of the RIAA pattern. If a serial port error occurs, for example, an exception gets thrown. As a result, the objects representing both the database and the open file go out of scope, and their resources are released. It's not hard to write a wrapper object for the malloc() block that calls free() when destructed. That would work just like your database wrapper object and your file wrapper object. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
On Feb 19, 2009, at 12:29 PM, Leo Singer wrote: A std::vector would be unsuitable also because in my actual application (not the cooked example I sent out) I need to be able to manipulate that memory directly. std::vector guarantees that you're allowed to do that. Cheers, Ken ___ 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: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
On Thu, Feb 19, 2009 at 10:29 AM, Leo Singer doc.aron...@gmail.com wrote: A std::vector would be unsuitable also because in my actual application (not the cooked example I sent out) I need to be able to manipulate that memory directly. Not true; std::vector's memory is guaranteed to be contiguous; you can treat it exactly as you did your raw array before. std::vector is *exactly* what you want in this case; it meets every requirement that you've stated. -- Clark S. Cox III clarkc...@gmail.com ___ 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: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
On Thu, Feb 19, 2009 at 1:29 PM, Leo Singer doc.aron...@gmail.com wrote: I would rather not dynamically allocate that particular array because the Cocoa application I am developing is simply a wrapper for a cross platform C++ project. This particular project has to manage a number of different resources, including an SQLite database connection, an open file, and a serial port device. In order to keep error handling as simple as possible, I have made heavy use of the RIAA pattern. If a serial port error occurs, for example, an exception gets thrown. As a result, the objects representing both the database and the open file go out of scope, and their resources are released. A std::vector would be unsuitable also because in my actual application (not the cooked example I sent out) I need to be able to manipulate that memory directly. Some more background information might be helpful. The application is a GUI for a bootloader for Microchip brand DSPs. The big array in question is actually a 256 kb image of the device's program memory. What you'd rather do is irrelevant: your code has a bug. Allocating that much memory on the stack simply isn't supported. For example, as mentioned in another post, some architectures have absolute limits on stack frame size that you've exceeded here. That you've succeeded now is mainly due to luck. Your code is still broken, it's just that you've managed to coax it into working. There are many ways to automatically manage resources like this, including using std::vector, writing a small class to wrap your memory block in the RAII pattern, or simply putting your call to free() in a finally block. Pick one, and use it, because what you're doing right now is wrong. Mike ___ 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
Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
Hi,
I have a C++ method that I am invoking from within the - (void) main
selector of an NSOperation. My Cocoa application is crashing because
this particular C++ method puts a huge amount of data on the stack. I
am getting an EXEC_BAD_ACCESS error. However, the same C++ routine
works fine if I call it from within a command line C++ program.
I have contrived some sample code to illustrate the problem.
TestOperation is an (Objective C) subclass of NSOperation; I am
running the NSOperation in a separate thread by putting it into an
NSOperationQueue. TestOperationImpl is a C++ class. The NSOperation
is responsible for doing one thing only: calling the go() method on an
instance of TestOperationImpl.
Note the very large array of ints that is declared inside
TestOperationImpl::go(). If it is changed to an array of shorts or an
array of chars, then this example code works fine, no EXEC_BAD_ACCESS.
Is there any way for me to give my application more memory, or at
least give more memory to the thread that is running this C++ method?
Thanks,
Leo
TestOperation.h /
#import Cocoa/Cocoa.h
class TestOperationImpl {
private:
bool cancelled;
public:
TestOperationImpl();
void go();
void cancel();
};
@interface TestOperation : NSOperation {
TestOperationImpl* testOpImpl;
}
- initWithController: (TestOperationController*) controller;
@end
End of TestOperation.h /
TestOperation.mm /
#import TestOperation.h
TestOperationImpl::TestOperationImpl(TestOperationController* controller)
: cancelled(false)
{
}
void TestOperationImpl::go()
{
int bigArray[256000];
for (int j = 0 ; j 256000 !cancelled ; j ++)
{
bigArray[j] = 2*j;
}
}
void TestOperationImpl::cancel()
{
cancelled = true;
}
@implementation TestOperation
- initWithController: (TestOperationController*) ctrl
{
if (self = [self init])
testOpImpl = new TestOperationImpl(ctrl);
controller = ctrl;
return self;
}
- (void) dealloc
{
delete testOpImpl;
[super dealloc];
}
- (void) cancel
{
testOpImpl-cancel();
[super cancel];
}
- (void) main
{
testOpImpl-go();
}
@end
End of TestOperation.mm /
___
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: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
Actually, if the big array and the loop are moved from the C++ method
into the Objective C selector - (void) main then the same
EXEC_BAD_ACCESS occurs. So the problem is not related to C++. The
following source code still exhibits the same problem:
TestOperation.h /
#import Cocoa/Cocoa.h
@interface TestOperation : NSOperation {
}
@end
End of TestOperation.h /
TestOperation.mm /
#import TestOperation.h
@implementation TestOperation
- (void) main
{
int bigArray[256000];
for (int j = 0 ; j 256000 ![self isCancelled] ; j ++)
{
bigArray[j] = 2*j;
}
}
@end
End of TestOperation.mm /
On Wed, Feb 18, 2009 at 3:16 AM, Leo Singer doc.aron...@gmail.com wrote:
Hi,
I have a C++ method that I am invoking from within the - (void) main
selector of an NSOperation. My Cocoa application is crashing because
this particular C++ method puts a huge amount of data on the stack. I
am getting an EXEC_BAD_ACCESS error. However, the same C++ routine
works fine if I call it from within a command line C++ program.
I have contrived some sample code to illustrate the problem.
TestOperation is an (Objective C) subclass of NSOperation; I am
running the NSOperation in a separate thread by putting it into an
NSOperationQueue. TestOperationImpl is a C++ class. The NSOperation
is responsible for doing one thing only: calling the go() method on an
instance of TestOperationImpl.
Note the very large array of ints that is declared inside
TestOperationImpl::go(). If it is changed to an array of shorts or an
array of chars, then this example code works fine, no EXEC_BAD_ACCESS.
Is there any way for me to give my application more memory, or at
least give more memory to the thread that is running this C++ method?
Thanks,
Leo
TestOperation.h /
#import Cocoa/Cocoa.h
class TestOperationImpl {
private:
bool cancelled;
public:
TestOperationImpl();
void go();
void cancel();
};
@interface TestOperation : NSOperation {
TestOperationImpl* testOpImpl;
}
- initWithController: (TestOperationController*) controller;
@end
End of TestOperation.h /
TestOperation.mm /
#import TestOperation.h
TestOperationImpl::TestOperationImpl(TestOperationController* controller)
: cancelled(false)
{
}
void TestOperationImpl::go()
{
int bigArray[256000];
for (int j = 0 ; j 256000 !cancelled ; j ++)
{
bigArray[j] = 2*j;
}
}
void TestOperationImpl::cancel()
{
cancelled = true;
}
@implementation TestOperation
- initWithController: (TestOperationController*) ctrl
{
if (self = [self init])
testOpImpl = new TestOperationImpl(ctrl);
controller = ctrl;
return self;
}
- (void) dealloc
{
delete testOpImpl;
[super dealloc];
}
- (void) cancel
{
testOpImpl-cancel();
[super cancel];
}
- (void) main
{
testOpImpl-go();
}
@end
End of TestOperation.mm /
___
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: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
OK, so there is a way to change the size of the stack for an NSThread.
But how do I do this for an NSOperationQueue?
NSThread has the following selector:
- (void) setStackSize:(NSInteger)s;
I need to find the equivalent selector for NSOperationQueue. Any
ideas out there?
Leo
#import Cocoa/Cocoa.h
@interface MemoryTortureController : NSObject {
}
- (IBAction)memoryTortureBackground: (id) sender;
- (IBAction)memoryTorture: (id) sender;
@end
@implementation MemoryTortureController
- (IBAction)memoryTortureBackground: (id) sender
{
NSThread* thread;
thread = [[NSThread alloc] initWithTarget: self
selector: @selector(memoryTorture:)
object: sender];
// The magic line
[thread setStackSize:256000*8];
[thread start];
}
- (IBAction)memoryTorture: (id) sender
{
int bigmem[256000];
for (int i = 0 ; i 256000 ; i ++)
bigmem[i] = 2*i;
}
@end
On Wed, Feb 18, 2009 at 3:31 AM, Leo Singer doc.aron...@gmail.com wrote:
Actually, if the big array and the loop are moved from the C++ method
into the Objective C selector - (void) main then the same
EXEC_BAD_ACCESS occurs. So the problem is not related to C++. The
following source code still exhibits the same problem:
TestOperation.h /
#import Cocoa/Cocoa.h
@interface TestOperation : NSOperation {
}
@end
End of TestOperation.h /
TestOperation.mm /
#import TestOperation.h
@implementation TestOperation
- (void) main
{
int bigArray[256000];
for (int j = 0 ; j 256000 ![self isCancelled] ; j ++)
{
bigArray[j] = 2*j;
}
}
@end
End of TestOperation.mm /
On Wed, Feb 18, 2009 at 3:16 AM, Leo Singer doc.aron...@gmail.com wrote:
Hi,
I have a C++ method that I am invoking from within the - (void) main
selector of an NSOperation. My Cocoa application is crashing because
this particular C++ method puts a huge amount of data on the stack. I
am getting an EXEC_BAD_ACCESS error. However, the same C++ routine
works fine if I call it from within a command line C++ program.
I have contrived some sample code to illustrate the problem.
TestOperation is an (Objective C) subclass of NSOperation; I am
running the NSOperation in a separate thread by putting it into an
NSOperationQueue. TestOperationImpl is a C++ class. The NSOperation
is responsible for doing one thing only: calling the go() method on an
instance of TestOperationImpl.
Note the very large array of ints that is declared inside
TestOperationImpl::go(). If it is changed to an array of shorts or an
array of chars, then this example code works fine, no EXEC_BAD_ACCESS.
Is there any way for me to give my application more memory, or at
least give more memory to the thread that is running this C++ method?
Thanks,
Leo
TestOperation.h /
#import Cocoa/Cocoa.h
class TestOperationImpl {
private:
bool cancelled;
public:
TestOperationImpl();
void go();
void cancel();
};
@interface TestOperation : NSOperation {
TestOperationImpl* testOpImpl;
}
- initWithController: (TestOperationController*) controller;
@end
End of TestOperation.h /
TestOperation.mm /
#import TestOperation.h
TestOperationImpl::TestOperationImpl(TestOperationController* controller)
: cancelled(false)
{
}
void TestOperationImpl::go()
{
int bigArray[256000];
for (int j = 0 ; j 256000 !cancelled ; j ++)
{
bigArray[j] = 2*j;
}
}
void TestOperationImpl::cancel()
{
cancelled = true;
}
@implementation TestOperation
- initWithController: (TestOperationController*) ctrl
{
if (self = [self init])
testOpImpl = new TestOperationImpl(ctrl);
controller = ctrl;
return self;
}
- (void) dealloc
{
delete testOpImpl;
[super dealloc];
}
- (void) cancel
{
testOpImpl-cancel();
[super cancel];
}
- (void) main
{
testOpImpl-go();
}
@end
End of TestOperation.mm /
___
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: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
Would this work?
- (void)main
{
[[NSThread currentThread] setStackSize:stackSize];
// Do usual work
}
Actually, with a bit more reading, apparently not. You'd need to set
the stack size before starting the thread, not after. In which case
your only option is to subclass NSOperation to create a custom
concurrent operation which creates its own special thread.
However, I can't help thinking that there's probably a better way to
achieve the desired result of the code without playing around like this.
On 18 Feb 2009, at 08:52, Leo Singer wrote:
OK, so there is a way to change the size of the stack for an NSThread.
But how do I do this for an NSOperationQueue?
NSThread has the following selector:
- (void) setStackSize:(NSInteger)s;
I need to find the equivalent selector for NSOperationQueue. Any
ideas out there?
Leo
#import Cocoa/Cocoa.h
@interface MemoryTortureController : NSObject {
}
- (IBAction)memoryTortureBackground: (id) sender;
- (IBAction)memoryTorture: (id) sender;
@end
@implementation MemoryTortureController
- (IBAction)memoryTortureBackground: (id) sender
{
NSThread* thread;
thread = [[NSThread alloc] initWithTarget: self
selector:
@selector(memoryTorture:)
object: sender];
// The magic line
[thread setStackSize:256000*8];
[thread start];
}
- (IBAction)memoryTorture: (id) sender
{
int bigmem[256000];
for (int i = 0 ; i 256000 ; i ++)
bigmem[i] = 2*i;
}
@end
On Wed, Feb 18, 2009 at 3:31 AM, Leo Singer doc.aron...@gmail.com
wrote:
Actually, if the big array and the loop are moved from the C++ method
into the Objective C selector - (void) main then the same
EXEC_BAD_ACCESS occurs. So the problem is not related to C++. The
following source code still exhibits the same problem:
TestOperation.h /
#import Cocoa/Cocoa.h
@interface TestOperation : NSOperation {
}
@end
End of TestOperation.h /
TestOperation.mm /
#import TestOperation.h
@implementation TestOperation
- (void) main
{
int bigArray[256000];
for (int j = 0 ; j 256000 ![self isCancelled] ; j ++)
{
bigArray[j] = 2*j;
}
}
@end
End of TestOperation.mm /
On Wed, Feb 18, 2009 at 3:16 AM, Leo Singer doc.aron...@gmail.com
wrote:
Hi,
I have a C++ method that I am invoking from within the - (void) main
selector of an NSOperation. My Cocoa application is crashing
because
this particular C++ method puts a huge amount of data on the
stack. I
am getting an EXEC_BAD_ACCESS error. However, the same C++ routine
works fine if I call it from within a command line C++ program.
I have contrived some sample code to illustrate the problem.
TestOperation is an (Objective C) subclass of NSOperation; I am
running the NSOperation in a separate thread by putting it into an
NSOperationQueue. TestOperationImpl is a C++ class. The
NSOperation
is responsible for doing one thing only: calling the go() method
on an
instance of TestOperationImpl.
Note the very large array of ints that is declared inside
TestOperationImpl::go(). If it is changed to an array of shorts
or an
array of chars, then this example code works fine, no
EXEC_BAD_ACCESS.
Is there any way for me to give my application more memory, or at
least give more memory to the thread that is running this C++
method?
Thanks,
Leo
TestOperation.h /
#import Cocoa/Cocoa.h
class TestOperationImpl {
private:
bool cancelled;
public:
TestOperationImpl();
void go();
void cancel();
};
@interface TestOperation : NSOperation {
TestOperationImpl* testOpImpl;
}
- initWithController: (TestOperationController*) controller;
@end
End of TestOperation.h /
TestOperation.mm /
#import TestOperation.h
TestOperationImpl::TestOperationImpl(TestOperationController*
controller)
: cancelled(false)
{
}
void TestOperationImpl::go()
{
int bigArray[256000];
for (int j = 0 ; j 256000 !cancelled ; j ++)
{
bigArray[j] = 2*j;
}
}
void TestOperationImpl::cancel()
{
cancelled = true;
}
@implementation TestOperation
- initWithController: (TestOperationController*) ctrl
{
if (self = [self init])
testOpImpl = new TestOperationImpl(ctrl);
controller = ctrl;
return self;
}
- (void) dealloc
{
delete testOpImpl;
[super dealloc];
}
- (void) cancel
{
testOpImpl-cancel();
[super cancel];
}
- (void) main
{
testOpImpl-go();
}
@end
End of TestOperation.mm /
___
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
Re: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
Really it would be best to malloc the space, use it, and free it.
Once you get to huge stack usage you gamble that you won't run out
when there can be other higher up calls also consuming some
(frameworks, libs, 3rd party code, ect). Also if you only use the
large amount once in a while then you have a bunch of unutilized
memory sitting around.
In your test NSOperation's setup calls probably use just enough stack
space to make your block run short. It also doesn't help secondary
threads usually have smaller stack sizes.
void TestOperationImpl::go()
{
int * bigArray = malloc(sizeof(int) * 256000);
for (int j = 0 ; j 256000 !cancelled ; j ++)
{
bigArray[j] = 2*j;
}
free(bigArray);
}
On Feb 18, 2009, at 1:16 AM, Leo Singer wrote:
I have a C++ method that I am invoking from within the - (void) main
selector of an NSOperation. My Cocoa application is crashing because
this particular C++ method puts a huge amount of data on the stack. I
am getting an EXEC_BAD_ACCESS error. However, the same C++ routine
works fine if I call it from within a command line C++ program.
I have contrived some sample code to illustrate the problem.
TestOperation is an (Objective C) subclass of NSOperation; I am
running the NSOperation in a separate thread by putting it into an
NSOperationQueue. TestOperationImpl is a C++ class. The NSOperation
is responsible for doing one thing only: calling the go() method on an
instance of TestOperationImpl.
Note the very large array of ints that is declared inside
TestOperationImpl::go(). If it is changed to an array of shorts or an
array of chars, then this example code works fine, no EXEC_BAD_ACCESS.
Is there any way for me to give my application more memory, or at
least give more memory to the thread that is running this C++ method?
___
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: Running out of memory on stack in C++ routine invoked within Cocoa NSOperation
I would strongly reccommend using std::vector instead of a raw array.
That way you're immune from stack size issues.
Sent from my iPhone
On Feb 18, 2009, at 0:31, Leo Singer doc.aron...@gmail.com wrote:
Actually, if the big array and the loop are moved from the C++ method
into the Objective C selector - (void) main then the same
EXEC_BAD_ACCESS occurs. So the problem is not related to C++. The
following source code still exhibits the same problem:
TestOperation.h /
#import Cocoa/Cocoa.h
@interface TestOperation : NSOperation {
}
@end
End of TestOperation.h /
TestOperation.mm /
#import TestOperation.h
@implementation TestOperation
- (void) main
{
int bigArray[256000];
for (int j = 0 ; j 256000 ![self isCancelled] ; j ++)
{
bigArray[j] = 2*j;
}
}
@end
End of TestOperation.mm /
On Wed, Feb 18, 2009 at 3:16 AM, Leo Singer doc.aron...@gmail.com
wrote:
Hi,
I have a C++ method that I am invoking from within the - (void) main
selector of an NSOperation. My Cocoa application is crashing because
this particular C++ method puts a huge amount of data on the
stack. I
am getting an EXEC_BAD_ACCESS error. However, the same C++ routine
works fine if I call it from within a command line C++ program.
I have contrived some sample code to illustrate the problem.
TestOperation is an (Objective C) subclass of NSOperation; I am
running the NSOperation in a separate thread by putting it into an
NSOperationQueue. TestOperationImpl is a C++ class. The NSOperation
is responsible for doing one thing only: calling the go() method on
an
instance of TestOperationImpl.
Note the very large array of ints that is declared inside
TestOperationImpl::go(). If it is changed to an array of shorts or
an
array of chars, then this example code works fine, no
EXEC_BAD_ACCESS.
Is there any way for me to give my application more memory, or at
least give more memory to the thread that is running this C++ method?
Thanks,
Leo
TestOperation.h /
#import Cocoa/Cocoa.h
class TestOperationImpl {
private:
bool cancelled;
public:
TestOperationImpl();
void go();
void cancel();
};
@interface TestOperation : NSOperation {
TestOperationImpl* testOpImpl;
}
- initWithController: (TestOperationController*) controller;
@end
End of TestOperation.h /
TestOperation.mm /
#import TestOperation.h
TestOperationImpl::TestOperationImpl(TestOperationController*
controller)
: cancelled(false)
{
}
void TestOperationImpl::go()
{
int bigArray[256000];
for (int j = 0 ; j 256000 !cancelled ; j ++)
{
bigArray[j] = 2*j;
}
}
void TestOperationImpl::cancel()
{
cancelled = true;
}
@implementation TestOperation
- initWithController: (TestOperationController*) ctrl
{
if (self = [self init])
testOpImpl = new TestOperationImpl(ctrl);
controller = ctrl;
return self;
}
- (void) dealloc
{
delete testOpImpl;
[super dealloc];
}
- (void) cancel
{
testOpImpl-cancel();
[super cancel];
}
- (void) main
{
testOpImpl-go();
}
@end
End of TestOperation.mm /
___
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/clarkcox3%40gmail.com
This email sent to clarkc...@gmail.com
___
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
