Stack space?

Hi! Any help anyone can offer would be HUGELY appreciated. I am trying to work on a website using Flash and whenever I go to try and publish the file it says
"Error Not Enough Stack Space"
I have no idea what this means, and am wondering if it has something to do with the memory on my mac or if it is a problem with flash.
Please help!

Found my answer on another forum... needed to delete some Adobe Illustrator files from the Flash file... it was an issue both of RAM and of Flash.

Similar Messages

SCRIPT28: Out of stack space

Using JDeveloper 11.1.2.3 and JHeadstart. With IE9 (9.0.8112.16421), the following error occurs:
SCRIPT28: Out of stack space
core-11.1.2.3.0-2247.js, line 192 character 200
SCRIPT28: Out of stack space
boot-11.1.2.3.0-2247.js, line 172 character 187
This is followed by IE9 hanging indefinitely. Here is an overview of the screen:
In Chrome and FF, when the user clicks the "Care Team" region (shown above as PPR using hidden button), it calls a hidden button to remove the tabs and replace the page content. The resulting page resembles:
As you can see, the menu tabs are gone and the page content is refreshed. The hidden button has an ID of menu1CareTeamButton and is inside a panelBox with a clientListener:
      <af:clientListener method="showCareTeamContext" type="click"/>
      <af:commandButton id="menu1CareTeamButton" text="CareTeam" action="patientShell:CareTeam"
                        visible="false">
        <af:setActionListener from="PatientCareTeam" to="#{jhsDynamicMenu.currentLevel1MenuItemName}"/>
      </af:commandButton>
The JavaScript function is straightforward enough:
function showCareTeamContext(actionEvent) {
    // Hack to find the hidden menu1CareTeamButton. This forces the button's action to fire
    // whenever the care team region is clicked.
    document.getElementById("pt:menu1CareTeamButton").click();
The menu1CareTeamButton has the following partialTriggers:
        <f:facet name="pageContent">
          <af:region id="mr" value="#{bindings.mainRegion.regionModel}"
                     partialTriggers="::Menu2 ::pendingChangesDialog ::menu1CareTeamButton ::CareTeamCloseButton"/>
        </f:facet>
      </af:pageTemplate>
            <af:navigationPane id="Menu2" hint="tabs"
                               partialTriggers="Item2 ::pendingChangesDialog ::mg:Menu1 ::menu1CareTeamButton ::CareTeamCloseButton"
                               rendered="#{attrs.showMenu2}">
Everything works flawlessly in Chrome and Firefox. IE9 fails.
Any ideas why?

Hi,
can you provide a test case that can be run stand alone (with no dependency to your project)? If so then this might be filed as a bug. If you have a customer support contract then you can file it yourself. If not you can send me a mail with the testcase in a zip (rename it unzip) and I file it for you. However, note that when i file the bug then it gets filed but you wont have a handle to check the bug status.
Note that the following line is not recommended to use with ADF Faces and there exist an ADF Faces JavaScript API that allows you to do the same but just not from making assumption about the rendered output (in a next release for example your code may break if the rendered output changes)
document.getElementById("pt:menu1CareTeamButton").click();
See this paper for how to do it properly: http://www.oracle.com/technetwork/developer-tools/jdev/1-2011-javascript-302460.pdf
You will also notice that instead of a hidden button, you could use af:serverListener to invoke server side Java to perform actions on your UI. This said, still chances are that IE is the cause of failure. Ensure you don't run this browser in IE compatibility mode but native.
Frank

The query processor ran out of stack space during query optimization. Please simplify the query

Can you suggest me that what should i do in this case.
Actually i am having one table that is a MasterTable.I am referring this table in more than 300 tables that means i am having foreign key of this primary key in 300+ tables.
due to this i am getting following error during deleting any row,
doesn't matter that data is existing in reference table or not.
Error that i am getting is
"The query processor ran out of stack space during query optimization. Please simplify the query"
Can you suggest me that what should i do to avoid this error,because i am unable to delete this entry.
Apart from it,i am getting performance problem too,so is it due to such huge FK on it.
Please suggest me on following points
1. Is it worst way to handle it,if yes then please suggest me solution for it.
2. If it is a correct way then what should i do if getting error during deleting any record.
3. Is it right to create Foreign key on each table where i am saving data of this master. if no then how to manage integrity.
4. What people do in huge database when they wants to create foreign key for any primary key.
5. Can you suggest me that how DBA's are handling this in big database,where they are having huge no. of tables.

The most common reason of getting such error is having more than 253 foreign key constraints on a table.
The max limit is documented here:
http://msdn.microsoft.com/en-us/library/ms143432(SQL.90).aspx
Although a table can contain an unlimited number of FOREIGN KEY constraints, the recommended maximum is 253. Depending on the hardware configuration hosting SQL Server, specifying additional foreign key constraints may be expensive for the query
optimizer to process. If you are on 32 bit, then you might want to move to 64 bit to get little bigger stack space but eventually having 300 FK is not something which would work in long run.
Balmukund Lakhani | Please mark solved if I've answered your question, vote for it as helpful to help other users find a solution quicker
This posting is provided "AS IS" with no warranties, and confers no rights.
My Blog |
Team Blog | @Twitter
Author: SQL Server 2012 AlwaysOn -
Paperback, Kindle

How to find Heap and stack space

How to find the heap sapce and stack space allocated at the moment.
My requirement, I need to test our application by changing both of these, and atfter finish testing and have to set them to old values.

You may consider reading up on how the Java stores data. There is no malloc() in java. I don't believe there is anyway within java that you can check the heap and stack size. And you can't allocate memory directly in java anyway so you wouldn't be able to change the value if you did get it. I would suggest using C or C++ to do this. Of course you can use JNI to call a C/C++ method from your java class but you will still have to first write the method in C/C++ which will make it platform specific anyway, so again I would suggest writeing this in another language which provides methods with direct access to the stack.

RangeError: Maximum call stack size exceeded

Dear all,
we are executing and EDGE project in a Samsung SmartTV. In more powerful models (more memory and cpu) the execution is correct. but in some old TV models we receive the following message:
File: file://c/........../EDGE_006/edge_includes/edge.2.0.1.min.js
Line No: 135
Error Detail: RangeError: Maximum call stack size exceeded.
It seems that this happens depending on the complexity of the EDGE project, as for some simple projects it works.
we would like to adjust our EDGE project for this less powerful models modifiying animations and simplifying complexity, but we dont know where to start (which animations to remove, etc.)
Or if there are some parameters in the edge API to adjust in order to increase performance in low memory browsers.
Thank you in advance,
Luis

sunil-online wrote:
> I am calling an external DLL and running it in the UI thread. How much
> stack space is available when they are on separate threads or on the
> UI thread?
>
> The problem is that I am getting seemingly random crashes while
> running this VI and after I quit labview after stopping and uninit-ing
> my DLL.
Unless you know this DLL is using exceedingly lots of stack (at least
several dozens of MB) for whatever obscure reasons it is very unlikely
that running out of stack space is causing your problem. More likely
either the DLL does something nasty to a data pointer passed in to it or
you made an error in setting up the call to the DLL.
For instace if the DLL expects strings or array pointers to be passed in
they need to
be allocated by the caller (here LabVIEW) and you need to
tell LabVIEW to do that in the diagram code.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Call Stack Size

Is there a way to increase the call stack size of LabVIEW or to know
when it has been exceeded?
Thanks.

sunil-online wrote:
> I am calling an external DLL and running it in the UI thread. How much
> stack space is available when they are on separate threads or on the
> UI thread?
>
> The problem is that I am getting seemingly random crashes while
> running this VI and after I quit labview after stopping and uninit-ing
> my DLL.
Unless you know this DLL is using exceedingly lots of stack (at least
several dozens of MB) for whatever obscure reasons it is very unlikely
that running out of stack space is causing your problem. More likely
either the DLL does something nasty to a data pointer passed in to it or
you made an error in setting up the call to the DLL.
For instace if the DLL expects strings or array pointers to be passed in
they need to
be allocated by the caller (here LabVIEW) and you need to
tell LabVIEW to do that in the diagram code.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Checking stack size

I have written a JNI app and it seems to work fine, but processing with very large files I run out of stack space.
I have solved this issue for the moment by changing the stack size with the -Xss param to java but this is not the ideal issue because with even bigger files I still will have issues.
So, I have 3 questions:
1. Is there any way (in the c++ dll) to query the total stack size ?
2. Is there any way to determine free (available) stack size ?
3. Is there any way to increase the stack size when the dll is already running (if it starts to get low)
I look forward to your thoughts
Ding

I have written a JNI app and it seems to workfine,
but processing with very large files I run out
of
stack space.
That suggests that you have a design problem.
As a guess you are using recursion. Start by
unrolling the recursion code to produce a
non-recursive solution.ood Guess but there is no recursion in my code :-)
While I am always trying to optimize my design, in
this case I am constrained by 3rd party c libraries
that are using very large multi dimensional arrays of
doubles that are neccessary for lots of complicated
math doing triangualtion of satellite data. So, I
have no control over how much memory they want to
consume.
ood Guess but there is no recursion in my code :-)
Then it is unclear as to what you think a good solution would entail.
Do you intend to just to keep retrying the processing step with ever increasing stack sizes? Will that not impact the processing time? Why not just start with a larger stack size? And if the stack size just continues to grow because the file sizes are continuing to grow then what?
While I am always trying to optimize my design, in
this case I am constrained by 3rd party c libraries
that are using very large multi dimensional arrays of
doubles that are neccessary for lots of complicated
math doing triangualtion of satellite data. So, I
have no control over how much memory they want to
consume.
One solution would be to create a C app, not a java one. Find the maximum amount of stack space that you can allocate via a C app and still operate (this depends on what happens with the file itself.) The output goes to a file.
Your java app just starts that in a separate process space.
>>
>
I was referring to the native C stack, used within
the c++ dll, for which the java VM starts via the
-Vss flag. I know the initial total as I am setting
it at runtime. I just wanted to print the value from
within the dll. #2 (below) is more important
though.
That would depend on your OS and compiler.
2. Is there any way to determine free(available)
stack size ? This is the part I was mostly hoping for an answer
to, as I need to communicate with the parent java app
if the stack space gets too low, instead of just
allowing the dll to crash when it runs out
That is a two part question. You want to know the size and you want to know if it gets 'too low'.
You suggested that this is all stack based processsing. So unless you have C methods that are called by the library and in addition it is recursive in nature then this is not possible. There is no point where you could detect it.
You can analyze the file yourself and compute a size before you start processing. But if that is what you are doing then you should do it first and let the java app know the result.
Other than that most OSes allow you to catch 'system exceptions' (which might or might not be actual C++ exceptions.) One of these would be generated when the stack overflows.
You then convert into something that java understands.
For example in Windows there is a function that allows you to set up system exceptions so that they cause a C++ exception to be thrown. You would then catch this exception and convert it into a java exception.
That lets you know that it didn't work but then what?
For example in windows you can create a custom stack for the dll but only when the dll loads (so far as I know.) So to restart this you would have to unload the dll and that means that you will have to have everything wrapped in a custom class loader (which is the only way to cause a dll to be unloaded.)
Not to mention that in my experience the windows function that I mentioned above doesn't necessarily always catch everything.
>>>
>>
No. The VM must be restarted.if that is true, It i a bummer :(You can however, on most OSes, increase the stack size for the shared library. This is done on start up of the shared library. To resize it however means that the shared library must be reloaded. And the only way you can do that in the Sun VM is with a class loader.

Stack Overflow Error for JNI program with Jdk1.3

I wrote a JNI wrapper for a third party sofware (written in C) to use some exported functions provided. My program runs fine when using Sun JDK1.2.2, but I got the following error when using Jdk1.3 to run the program (It's a runtime error, only the version of runtime virtual machine matters.)
# An EXCEPTION_STACK_OVERFLOW exception has been detected in native code outside
the VM.
# Program counter=0x9073337
A stack overflow was encountered at address 0x09073337.
I tried IBM jdk 1.2.2, it gave me a similar error complaining about the stack overflow error.
The vendor of the third party software denies any wrong doing in their code and I don't have their source code. A test client (simulate the Java client) I wrote in C works perfectly fine and as I mentioned earlier the same java progarm runs OK with jdk 1.2.2, without any change to my system stack size. Does any body know what this is about and the solution for this?
Thanks!
My email: [email protected]

I had the same exception occur in my JNI code and I have some advice on things to look for.
Symptoms: The C++ code runs fine when called in an native executable but when it is wrapped by a JNI call inside a DLL you get the following exception:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_STACK_OVERFLOW occurred at PC=0x100d72e5
Function name=_chkstk
The address will be different of course.
In my tests I isolated the problem to an allocation of a char array like so at the top of one of my wrapped C++ methods:
char buf[650000];
As you see this code is requesting 650000 bytes of stack memory. When run in a native executable there was no problem but when I ran it wrapped in the JNI call it blew up.
Conclusion: There is a much smaller stack space when using JNI OR the added overhead of my JNI wrapper exhausted the available stack space OR this is a stack space issue related to DLLs.
Hope this helps. Anyone with insight on this please put in your 2 cents.

TROUBLESHOOTING A STACK OVERFLOW ERROR

제품 : ORACLE SERVER
작성날짜 : 1997-02-04
==========================================
TROUBLESHOOTING A STACK OVERFLOW ERROR
==========================================
OVERVIEW
A stack is a temporary storage space for programs. All programs have a
stack. MS-DOS switches stacks for hardware interrupts to prevent stack
overflows. Some programs such as EMM386.EXE, SMARTDRV.EXE, mouse drivers
and TSR's will hook these hardware interrupts. When a hardware interrupt
hook requires more stack space than is available, a stack overflow error
occurs.
SYNTAX
The STACKS= command in your CONFIG.SYS specifies two parameters; the
number of stack frames and the size of those frames.
STACKS=x,y where x = number of stack frames
minimum value is 8
maximum value is 64
y = bytes of each stack frame
minimum value is 32
maximum value is 512
For most PC's the default is STACKS=9,128.
TROUBLESHOOTING
Perform the following troubleshooting steps prior to changing the STACKS=
command:
o If you are using a third party video driver reconfigure the pc to use the
generic Windows VGA drivers.
o Be sure you have 512K conventional RAM free before you load Windows.
You can check the free memory by using the MEM /C command. The value
for "Largest executable program size" should be 512k (524,288 bytes).
o Personal Oracle7 requires 8MB RAM. An additional 8MB RAM is required
when PL/SQL is also installed. The trial product requires PL/SQL and
therefore automatically installs it.
o Add the /X switch to the SMARTDRV.EXE driver in AUTOEXEC.BAT. This
switch disables the write-behind caching.
o Exclude the video graphics area from the memory manager.
i.e. DEVICE = C:\WINDOWS\EMM386.EXE X=A000-C7FF
The video driver's manufacturer can provide you with the appropriate
range to exclude..
o Boot clean.
CONFIG.SYS AUTOEXEC.BAT
========== ============
FILES=45 PROMPT$P$G
BUFFERS=20 PATH=C:\WINDOWS;C:\DOS;\C:\
DEVICE=C:\<dir>HIMEM.SYS SET TEMP=C:\<valid path>
STACKS=9,256
SHELL=C:\<valid path>\COMMAND.COM /E:1024 /P
!!!CAUTION: Your system may have third-party drivers that must be
loaded! Such drivers include hard disk drivers, disk
partitioning disk compression utilities.
Removing such drivers can render your hard drive
inaccessible and/or damage your data.
DO NOT REMOVE ANY DRIVER(S) THAT YOU CANNOT IDENTIFY ITS
PURPOSE!
o Add STACKS=9,256 to CONFIG.SYS. If you already have this statement
then increase the stack frames to 16.
The Microsoft Knowledge Base (http://www.microsoft.com/support/)provided
technical resources for this bulletin. .............................

The same issue seemed to be solved for me after I installed
the ColdFusion 8 beta plug-ins for Eclipse
http://www.adobe.com/cfusion/entitlement/index.cfm?e=labs_adobecf8_beta

CIN stack overflow error

Im using an recursiv c++ function in my VI.
After severall calls the VI crashes, printing an
stack overflow error.
I already increased in Visual Studio 6.0 the Link
setting: allocate stack. But nothing changed.
I need help fix this problem!!
My prg. looks like this:
recursiv (....) {
int array[..][..][..];
recursiv (..);
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

> Im using an recursiv c++ function in my VI.
> After severall calls the VI crashes, printing an
> stack overflow error.
> I already increased in Visual Studio 6.0 the Link
> setting: allocate stack. But nothing changed.
> I need help fix this problem!!
>
> My prg. looks like this:
>
> recursiv (....) {
> int array[..][..][..];
> ....
> recursiv (..);
> }
If you are truly allocating a three D array of ints
on the stack, then it makes sense that you will run
out of stack space sooner or later. I can't help
you with increasing the stack size, but if you move
your array into a memory block and store the pointer
on the stack, then you will use less stack space and
avoid the problem.
In otherwords:
recursive() {
int *array;
array= DSNewPtr()
array[][][]= ...
recursive();
DSDisposePtr();
Greg McKaskle

Pthreads not free'ing stack when terminated

Hello,
I have a simple program that initializes itself as a demon and then sits on a socket waiting for requests. For each request it gets on the socket the demon starts a pthread. The thread does a pthread_detach() and then does it's job (hello world) and then exits.
I notice that the memory footprint (via 'top') of my demon is growing and growing. I put a printf of a automatic variable in my thread function and it seems that the stack for the threads are not being released when the thread exits. And so my process grows and grows until it's a problem.
Can you please explain this behavior? I'd like to avoid having to allocate and manage the stack space for the threads myself.
Thank you,
[email protected]
617-621-5310

I want to correct my last post because the automatic variable address in my printf does stay the same. So the stack does seem to get released when the detached thread terminates. So why does the process size continue to grow in memory?

Stack overflow (0xC00000FD) at EIP=0x01B13469

Hello,
I am working on a large project and sometimes the LabView shuts down with the error message: Stack overflow (0xC00000FD) at EIP=0x01B13469 (that is tha last one I got). I am not able to identify the generator of this error. ( Maybe someone can do it from the error message above). It is possible to catch this error ????

charlie87 wrote:
Hello,
I am working on a large project and sometimes the LabView shuts down with the error message: Stack overflow (0xC00000FD) at EIP=0x01B13469 (that is tha last one I got). I am not able to identify the generator of this error. ( Maybe someone can do it from the error message above). It is possible to catch this error ????
This is a fatal error. As to catching it, Windows does it already for you, that is why you see the dialog. Trying to catch it yourself by some means wouldn't add anything as it is ABSOLUTELY unsafe to continue the process after this error. It could eat your breakfast, or the harddisk or something else!!
Something in your application is using huge stack space. This could be in LabVIEW itself, if you use some form of very strange VI settings, but since the LabVIEW VI execution itself is not stack based it is unlikely that the large project in itself would be the cause of it. Most likely you make use of some external code library somewhere, that has huge stack space requirements, either by allocating huge buffers on the stack (a very bad thing to do) or by calling functions recursively without a safe upper bound (just as a bad thing to do).
Also you should qunatify what a large project means. I have done projects in LabVIEW with about 1000 VIs and more already 15 years ago.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Tools for root cause analysis of stack corruption?

I'm experiencing extremely rare stack corruption that results in SEGV core dumps for a large and complex C++ program. Having run all the standard tools such as IBM Rational Purify, Sun mdb/libumem and dbx/rtc (although unfortunately using dbx check -access takes inordinately long and eventually crashes before the main() function is executed), I am no closer to discovering the root cause of the stack corruption. I'm confident based on the tools run and on the stack trace from the core dump that the problem is not heap corruption, but stack corruption.
The environment is Sun Studio 12 (but not update 1) on Solaris 10 on SPARC. The program is compiled with minor optimisation (-xO2 -xbuiltin=%all).
Is anyone aware of other tools or approaches that could help pinpoint the problem? Your help would be much appreciated!
Thanks in advance,
Simon

If you are in fact having stack corruption issues, I don't think any of the tools you mentioned other than Purify would help you identify it.
You may also be simply running out of stack space, and not having corruption issues. Is your app multi-threaded? If so, you could increase the stack size your threads use to something larger than the default.
Another thing you can look for are syslog entries stating "no swap space to grow stack" for your process, you've run out of virtual memory. To avoid this, you can "pre-allocate" your stack memory with code similar to this:
void growStack( size_t bytes )
    char *mem = ( char * ) alloca( bytes );
    memset( mem, 0, bytes );
    return;
}That code, when called, will force the creation of stack memory virtual pages backed by swap, before your server gets into a situation where free memory might be in short supply.
I also seem to recall that Solaris under certain circumstances will allocate stack memory with the MAP_NORESERVE option, which means swap space won't be reserved for your stack. If your process gets swapped out, its stack(s) will be lost and you'll probably get a SIGSEGV or SIGBUS. See this bug:
[http://bugs.opensolaris.org/view_bug.do?bug_id=1221729|http://bugs.opensolaris.org/view_bug.do?bug_id=1221729]
I remember working a similar issue for a customer running large apps on Sun E15Ks, maybe about 5 years ago. To work around this behavoir, I think you'll need to explicitly allocate stack memory for any threads you may be creating. I think that's what we had to do.

Debugging: Run-Time Check Failure #2 - Stack around the variable 'LoggerThread' was corrupted.

I am getting:
Run-Time Check Failure #2 - Stack around the variable 'LoggerThread' was corrupted.
I have searched as much as I can for a description of how to diagnose, but I have not found anything. I don't know how to determine the specific address that is being corrupted. If I knew that, then I could of course set a breakpoint on the condition of that changing.
I have found many answers about other instances of this error, but nothing that descibes how to diagnose this problem. All other problems were simple enough that the problem could be determined by looking at the code. I have looked at my code extensively and I don't see a problem. One of the previous answers I have found is Error: Stack corruption around the variable 'tm' but the current version of the program uses only default alignment.
This particular problem is a symptom of a problem that has had various other symptoms, most of which would be more difficult to diagnose. Therefore the problem is probably more subtle than most. I initially encountered the problem in a DLL project, but I wrote a console program to use and test the relevant code. It is the console version that I am debugging.

Sam Hobbs wrote:
Holger Grund wrote:
Hey, these data breakpoints are really not that hard to use ;-)
Actually they are useless for me when I use my own system, which is only 350 MHz. On that system, even very simple programs run noticeably slow and any meaningful debugging is impossible. The problem I am encountering I am developing and debugging using a fast system, so the performance is not likely to be a probem, but that has been a problem for me in the past.
You probably haven't set the breakpoints in the correct way (again you should calculate the address yourself and leave the context empty so that the hardware debug breakpoint registers can be used).
Sam Hobbs wrote:
One of us does not understand. First, I must correct what I said before; the stack is used in reverse of what I was thinking. I knew that but I forgot. In other words, for each item local appearing in a function, the addresses decrease. The processor's stack pointer register is decreased for each item put into it, which makes sense, because then the processor knows there is a problem when the register gets to zero or less.
Yes, I certainly understand that the error message is referring to memory before and after LoggerThread.
There is an important difference between stack memory before a function's allocations and after.
So for example if we have:
Code Snippet
void Level3(int a) {
char Local[4];
std::cout << "In Level3 Local is at " << &Local << '\n';
void Level2(int a) {
char Local[4];
std::cout << "In Level2 Local is at " << &Local << '\n';
Level3(3);
void Level1(int a) {
char Local[4];
std::cout << "In Level1 Local is at " << &Local << '\n';
Level2(2);
int main(int argc, char* argv[]) {
(void)argc, argv;
char Local[4]="321";
unsigned *pStack;
_asm {mov pStack, esp}
std::cout << "The stack is at " << pStack << '\n';
std::cout << "In main Local is at " << &Local << '\n';
Level1(1);
return 0;
Then the ouput I get is:
The stack is at 0012FF1C
In main Local is at 0012FF6C
In Level1 Local is at 0012FF0C
In Level2 Local is at 0012FEB0
In Level3 Local is at 0012FE54
Note that the addresses decrease. If I create a breakpoint using "{main,,} *(Local-256)" for 256 elements, then that breakpoint breaks constantly due to normal use of the stack. That makes debugging more difficult; are you aware of that problem?
Unsurprisingly the debugger will watch for modifications of 256 bytes if you tell it to do so. But I don't see why you would want to do it? It is obvious that this extends into callee stack space. There are only two bytes that you should be interested in: the one before the clobbered local and the one after. Of course, during its lifetime its allocated address will never change. And in debug stack frames its memory location is never shared with any other code. Any modification to it indicates a programming error.
Also, do note that scoped data breakpoints have had some performance problems. Again, if you care about performance calculate the address manually and set a data breakpoint without a C++ scope and make sure you don't exceed the number of available hardware watchpoint registers (IIRC there are 4 HW breakpoint registers which can watch 1,2 or 4 bytes at a given (aligned?) address). With HW watchpoints you shouldn't see any performance degradation.
-hg

WinCE6 stack leak issue

Hi,
I am trying to track down an memory leak that I have been working on for the past few weeks. The leak seems to be coming from the stack. We are creating a thread of 1MB stack, but the system is only allocating 64k. My gut feeling is anything
beyond this 64k is being leaked.
After the thread is created, I am getting the context ( reset) - and it is only 64k out beyond the mem base. It should be 1MB. Does anyone know why this is the case? If our stack usage goes beyond the 64k range, how can the memory be recovered
(freed)?
This is a kernel driver creating kernel threads. The driver is loaded by the system and threads are created and exited on "init" and "deinit" IOCTL (DeviceIOControl) calls, respectively.
Thanks!

Hi Paul,
Thank you so much for the reply. Yes, the real goal is to eliminate the leak. Leaks are on the order of 150k to 200k, but only occur when the threads are exited - we do a mem snaps shot from test to test and do a diff between the 2 physical mem
sizes. I have concluded the leak is coming from the stack by allocating a large char array (within a function so it's not static) in our library that is called into from the running thread - we see it grow the larger I make the array.
Here is my create thread.
nStackSize = 1024 * 1024;
m_hMyThread = CreateThread(NULL,nStackSize,(LPTHREAD_START_ROUTINE)MyThreadShell,(LPVOID)this,CREATE_SUSPENDED | STACK_SIZE_PARAM_IS_A_RESERVATION,NULL);
After this, we get the "reset context" and commit it all to RAM so we don't run into demand paging issues. What's strange is the context is at 64k (not 1MB as I would have expected). My suspicion is if we use more than that 64k, we
lose whatever goes beyond that. Our threading design typically runs in Application space for CE5/WinMobile - but relies on LoadDriver. Since this is now a kernel only call in CE6, we made a kernel driver.
We are tracking our own Heap and cleaning it up on exit, so I don't suspect this is leaking. Our library uses a lot of stack space and is why we allocate so much.
Some other points: This same design ("driver" model) works fine in CE5/Windows Mobile.
Thanks!
BTW: Here is some data... We are creating 2 threads, first size is 1MB and second is default (linker settings - which is 64k).
Windows Mobile:
AllocationBase=0x2a1a0000, m_pMyContext->Sp=0x2a29fee0
AllocationBase=0x2a2a0000, m_pMyContext->Sp=0x2a33fee0
Thread1 “my context” is 1MB out from AllocationBase.
Thread2 “my context” is 64KB out from AllocationBase.
WinCE6:
AllocationBase=0xd6d00000, m_pMyContext->Sp=0xd6d0fe90
AllocationBase=0xd60b0000, m_pMyContext->Sp=0xd60bfe90
Thread1 “my context” is 64KB out from AllocationBase. <- BAD
Thread2 “my context” is 64KB out from AllocationBase.

Stack space?

Similar Messages

Maybe you are looking for