forums.silverfrost.com

mecej4 · Joined: 31 Oct 2006 Posts: 1886

If you read the Microsoft page that I referred to above, you can see something that may answer you: "The system commits additional pages from the reserved stack memory as they are needed, until either the stack reaches the reserved size minus one page (which is used as a guard page to prevent stack overflow)". I am not knowledgeable about corner cases where reserve size = commit size, etc., nor do I know if the description on that MS page applies to all versions of their VC compilers and tools.

When I write a program, I try to keep the stack small by using allocatable or statically allocated, saved arrays. However, when helping with some old F77 or F66 code, I find it necessary to specify a large enough stack to allow the program to be run with few changes.

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

Mecej4, you might be on to something. I have a small routine that reports the stack as an integer. It turns out that after 1 particular WRITE into a character array, the stack comes back corrupted.

I stripped the code out and got the problem to duplicate!

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

It may have something to do with the trim() on the last IO list item (state). If I remove that trim(), then the stack remains the same value.

I tried this using * instead of raw_data and gets the same stack difference. So, it's at least consistent.

mecej4 · Joined: 31 Oct 2006 Posts: 1886

Two comments: 1. You can report the %esp value more accurately by placing the following three lines once before the WRITE and once after.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

mecej4,

Thanks for the information on stack and how to change it; this is very helpful, but again the results of changing the stack size are not as I would expect.

Why is it that for:
"/stack:0x40000,0x20000" crashes with stack overflow.
"/stack:0x40000,0x40000" the program runs,

My understanding after reading the link you provided is that both provide for the same available stack size, although the first case initially has a smaller allocation (and for what reason?)
"/stack:0x40000" what would this be equivalent to?

This reproduces the confusion I have had with this in the past.
I shall look at using integer*4 function get_stack_pointer(), based on your example and see if that helps.

John

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

mecej4,

Yes, I was fully aware that the ESP reflects the stack pointer in the called routine. Rather than get the actual value at the point of call, I chose to use the fact that, relatively, the stack should be the same regardless of the actual value. In this way, I can more easily remove the trace simply by changing the one routine (my_routine) to always return the same value.

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

I expanded the code trials a bit more, putting in a few variations, explicit use of the non-blank length (len_trim), etc.

The results, while clear, are not consistent. Using len_trim() to set the character count is no better than using trim(), but using trim() then concatenating those results appears to work just fine.

Code:

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

Paul, I'm wondering if you might have tried the code and have seen the same results that I have.

Bill

PaulLaidler · Posted: Sat Dec 12, 2015 8:49 am Post subject:

Bill

I have not tried your code but will aim to do so on Monday.
Having said that, from a brief look at your post, I am not clear about what I will be looking for.

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

Paul, fair enough.

The basis for the request is that , while in a function/subroutine, the stack pointer should remain at the same value. However, using the sample program, you will find that, for whatever reason and only when running /CHECKMATE, the stack gets corrupted. Specifically, the stack will decrement under specific circumstances. My issue was that as my original code was running, it was performing tens/hundreds of thousands of the suspect IO statements until a stack overflow exception was generated. Running the same test code under /RELEASE will show that the stack pointer remains the same throughout the run. That was my experience; if I ran the /RELEASE version, all went well.

The problem I encountered was specifically found to be using TRIM() in an IO list. The first PRINT ("Using 2 trim() calls)" shows that the stack pointer returns after the PRINT decremented by 16. Later on, I found that other combinations of PRINT and use of TRIM() or just specifying the length of the character string in the IO list can cause the same problem, or make the problem disappear.

Specifically, "concat trims and print" uses three TRIM() calls, concatenating the data, but no stack problem was encountered. Also, "trim only quad" uses TRIM() to output the first data item then outputs a full data item, and the stack is unaltered. So, in my small number of tests, it would appear that if you use TRIM() or a specified character length at the end of the IO list, then the stack pointer is badly altered.

I hope this helps to clarify.

PaulLaidler · Posted: Mon Dec 14, 2015 11:34 am Post subject:

Bill

The problem is replicated on my machine and needs fixing so I will make a note of this.

In the meantime I suggest that you write your output to a string buffer and then use a single TRIM when PRINTing the buffer. That should allow you to continue to use /CHECKMATE.

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

Paul, the problem also occurs writing to a string buffer using the WRITE(char_data,format) form as well as to a file. This was how I identified the problem initially.

Or, I may have misunderstood your response.

PaulLaidler · Posted: Mon Dec 14, 2015 6:23 pm Post subject:

OK. Can you find a way to avoid multiple calls to TRIM in an output list?

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

Since this also happens even when the length of the string is specified (i.e. ABCD(1:10), or ABCD(1:I)), it becomes nightmare to recode all the formatted writes.

One interesting thing is that even though the stack is negatively affected, if I call a routine that manifests this effect, upon return, the stack is "normal" in the calling routine. So, something is happening (and I kind of see this in the /CHECKMATE listing files I've looked at) where the stack is "fixed" prior to return to the caller.

What I might be able to do is recode the huge, major loop in which this problem manifests itself most readily, breaking it into smaller routines that will contain the TRIM() functions and get called/fixed.

I've informed my external testers that this issue might manifest itself and have offered a "fix"; don't process so much data, or run the /RELEASE version also supplied to them.

I have a couple of other routines that process massive amounts of data as well. These will be much more difficult to recode, but so far, they have not yet crashed due to this stack fault issue.

Thanks for pursuing the fix, Paul. I'll get by until then!

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

Temporarily, I've placed code that saves the ESP register as the major loop starts and restores it before the loop end. It is certainly temporary.

This has totally eliminated the stack fault.