Valgrind confused by a recursive internal subroutine.

[joseph-krahn]

I found that Valgrind can get confused by an internal, recursive subroutine compiled with Intel Fortran. Apparently, these routines can have a separate stack, which Valgrind gets confused with threading. The --max-stackframe option does not fix the problem. I think the problem might be that the recursive routines can access their own stack as well as the host-associated stack, but this is just a guess. I have not yet tried to isolate a test case, or tried varying compiler options.

Has anyone else come across this problem? Valgrind can be quite useful, so it may be worth contributing some Fortran-specific enhancements that make it better able to deal with Intel Fortran code.

[Steven_L_Intel1]

There's no separate stack involved with recursive contained procedures. There is a context block passed to the contained procedure when it is called from its host procedure.

[joseph-krahn]

It turns out that the code I am testing seems to have triggered a compiler error (I just submitted a bug report). I am getting unusual segfaults that don't make sense with idb. Maybe there is some stack corruption, which could account for Valgrind's confusion as well. I will try again later when this gets worked out.

[joseph-krahn]

My problem turns out to be a stack overflow. It seems that stack consumption for each level of recursion is significantly more than I would expect just by considering memory for local variables within the recursive subroutines. It works OK with an unlimited stack size, but I am surprised that a fairly simple recursion can be such a stack hog.

The recursive routines have one argument, an array. If I convert that array to an allocatable, I still have the stack overflow problem. If I allocate one large 2D allocatable in the main routine, the stack problem goes away, but I then have to pick a fixed recursion limit. Maybe this is because large allocations are from heap, and small ones are from the stack?

[Steven_L_Intel1]

ALLOCATEs are always from the heap. Always. It could be that an array temp is being created for an operation. Try the new -heap-arrays option and see if it helps.

[joseph-krahn]

OK, it seems that local arrays and temps are the ones using up the stack.

It would be nice if the debugger could detect stack overflows. That would have saved a lot of time. At least now I know to look for a stack overflow if a segfault is followed by strange behavior in IDB.

[jimdempseyatthecove]

Would I be correct in assuming that your recursive subroutine's one argument isn't an array but it is a subset of an array? e.g. the outer most level passes the whole array, the next level passes a portion of the array, the next level a portion of the portion, etc...

Depending on how the array is declared and portioned out your routine may be creating stack temporaries as you slice up the array going into the recursion. A different layout or technique can often be implemented that eliminates the stack temporaries. There was (or is) supposed to be a option to generate warnings when array stack temporaries are created on call statements. Steve might be able to comment on this.

There is a runtime check for arg temp creation

/check:arg_temp_created

But a compile time warning option would be better IMHO.

Jim Dempsey