the infamous stack overflow and openMP problem, suggestions plz

[j0e]

Hi All,

Once again I'm faced with the stack overflow problem when attempting to use openMP. I've search through many posts here, and have tried the following to remove the problem:

1) made all arrays allocatable
2) made sure no temp storage is created on the stack in subroutine calls
3) have made the stack reserve size about as big as allowed (/STACK:1000000000)
4) also tried heap arrays option (set to 0)

but still, when the code hits the first line of the // section when using openMP, a stackover flow occurs. No overflow occurs if not using omp libraries. I'm using the latest version of IVF under windows x64.

Any other suggestions?

EDIT: there are several real(8) moderate size arrays (20:100:100) made globally available via a module, but must be kept threadprivate. Does the treadprivate space impose any limitations?

also, setting KMP_STACKSIZE=1000000000 does not help either.

cheers,
-joe

[jimdempseyatthecove]

Joe,

A snip of code might help with the diagnosis.

If you can enter your parallel region (that exhibits the problem) and reach a break point prior to the problem, then in the VS debugger open the threads pane. One of the threads listed is highlighted/marked as the thread at the break point. If you right click on each of all the other threads you can select Freeze. Do so and freeze all the other threads. Then click back into the source code window and use the F10 or F11 to step over or into as the case may be up until you get the error. Should the error not occur on the first thread after it exits the problem subroutine, then freeze the current thread, and right click one of the other threads and pick Thaw. Then F5 to run. If the thread you thawed was one of the user code threads it will encounter the break point. If break not hit, then you thawed a support thread. Therefore, Thaw one of the other threads. Repeat the step through until you find the statement.

If the statement is an expression using arraysor a CALL using slices of an array then the stack overflow is the result of a temporary array creation (on stack). Rework the code to eliminate the temp.

Jim Dempsey

[Andrew_Smith]

Two hints:

1. Do you use any internal procedures? Passing an internal procedure is illegal but accepted by IVF and cought me out. Thesedont workproperly with OpenMP because the variablesin the containing routine are not correctly referenced in the internal procedure and are mixed up randomly between the threads. There are some workarounds to allow use of non-contained procedures.

2. Tryto make every routine PURE. This will pinpoint most access to external data that could cause a conflict.

[Steven_L_Intel1]

Quoting - Andrew Smith

Passing an internal procedure is illegal but accepted by IVF and cought me out.

This is non-standard in F2003 but is permitted in the draft of F2008. I would expect this to work ok even in an OpenMP context.

[j0e]

Hi all,

Jim: Sorry for not providing a code snippet, but I'm trying to get some parts of existing serial code to run parallel, and tied together with the problem I'm trying to solve. Consequently, things are a bit messy and difficult to provided an example for. In terms of your suggestion, the stack overflow occurs at first entry into the // region, so I can not step through as you recommend. However, I did not know about freezing threads, so I'm sure I can put that to use when the time comes (Thanks). I have put together some sample code on a related thread (Re "openMP, threadprivate and allocate") that you have already replied to, which I will address there.

Andrew: There is an internal procedure within a module used to allocate arrays and initialize global variables, but it is not passed as an argument, if that's what you mean. In any case, the procedure is not called within the // region. However, if you also kindly look at my other topic "openMP, threadprivate and allocate", you can let me know if you think problems might occur in the short sample code, as I was trying to use an internal procedure within a module to allocate global arrays within a // region.

Thank you all for your replies!
-joe

[Andrew_Smith]

Quoting - Steve Lionel (Intel)

This is non-standard in F2003 but is permitted in the draft of F2008. I would expect this to work ok even in an OpenMP context.

I would have too and I made many uses of it but it does not work! See support item 545221

[Andrew_Smith]

Quoting - Andrew Smith

I would have too and I made many uses of it but it does not work! See support item 545221

Try attached code

[j0e]

Andrew,

Now I see. While I had been calling internal routines from outside the host routine, I had not realized it was not legal (although I can now see it is clearly stated as illegal). I notice your test source has nested contains statements, which is also not supported. Could that push it over the edge?

Anyway, I have taken heed of your suggestion and have replace the internal procedures with external ones.

Thanks!

[Andrew_Smith]

Quoting - Joe

Andrew,

Now I see. While I had been calling internal routines from outside the host routine, I had not realized it was not legal (although I can now see it is clearly stated as illegal). I notice your test source has nested contains statements, which is also not supported. Could that push it over the edge?

Anyway, I have taken heed of your suggestion and have replace the internal procedures with external ones.

Thanks!

There are no nested CONTAINS in the code example. The outer CONTAINS statement is in a module and has a different meaning to the CONTAINS inside a routine. Therefore there is only one level of internal routine.