Stack Overflow in RtlVirtualUnwind

[simone]

Dear all, I have a strange problem that I can't solve. In a complex gui intensive application, if the user performs a repetitive action for a few seconds (it's a compulsive stress test!), an external stack overflow occurs. There are no obvious classic situations that determine stack overflow (too deep recursion, excessive input size, etc.)

Examining the call stack only the following item emerges:

#0 ntdll:RtlVirtualUnwind+1746 at :0

I realize that the elements I provide are minimal, but maybe someone of you who knows the Windows API better than me could have some intuition.

Thanks in advance.

[Martin_fr]

The Unwind is (probably) just called because of some error. E.g. maybe you have an other error somewhere, and it is either covered by an try-except/finally block of yours, or by a try-finally that was automatically generated.

Any Exception on Windows calls that function, which then calls the except or finally handler or some other error handler.

Mind that this may have been called by some error *before* the stack overflew. But the stack was near overflow. Then the overflow happens while the Unwind tried to deal with some other error.
And that includes any error in dll, including the kernel, if any function in such code would trigger an error.

How many entries does the "stack window" (menu: view > debug windows) show?

If it does on show any entries except for ntdll entries, then try in Tools > Option > Debugger to use the gdb debugger.
While FpDebug is better in many things, getting a longer stacktrace is something gdb is still sometimes better.

Application.ProcessMessages can also deep recurse. Just in case...

[simone]

Thanks Martin. Your information is valuable.

In the stack window there is only the item indicated above, as shown in the attached screenshot.

[Martin_fr]

Thanks Martin. Your information is valuable.

In the stack window there is only the item indicated above, as shown in the attached screenshot.

And that is the same with GDB?

[Thaddy]

an external stack overflow occurs.

External? What external libraries are you using?
RtlVirtualUnwind can not cause a stack problem on its own.

[Martin_fr]

Of course it could be a case of stack corruption. Then there is no easy way to get the stack at all.

The stack contains your local vars, and then also the return address, and internal info (I think, but need to check, the previous "basepointer" which might eventually become stackpointer.

If you have a local var "Foo: array [1..4] of integer" and you do "Foo[-1] := 1;" then you may destroy those internal values.

I am not 100% sure that such an "overwrite" could cause a stack overflow. But it probably can...

Make sure to have all range checks and stuff turned on.


What version of fpc... Arg, got it. Mind, while I am replying, I can  only see your message text, but not your signature. Please put info like this in the actual message.
Try it, hit reply, then look for my message below the reply edit field. You will see my msg, but no signature.

Fpc 3.2.2.
Are you compiling with/without optimizations?
If "with", does it happen without too?

[Martin_fr]

an external stack overflow occurs.

External? What external libraries are you using?
RtlVirtualUnwind can not cause a stack problem on its own.

That is just the wording in the popup of the debugger. IIRC it was taken from the ages of gdb.... Exception external something.

[simone]

@Martin: GDB shows a complete stack trace, unlike fpdebug, as you expected (see attached screenshot). I have to examine it carefully

@Thaddy: I don't use any external library. Only LCL.

[simone]

more information:

Lazarus 3.0 (rev lazarus_3_0) FPC 3.2.2 x86_64-win64-win32/win64
Optimization Level: -O1

[simone]

The stack trace obtained with gdb (I increased the maximum number of elements in the window) is very rich and allows me to understand, probably, the point in the code that generates problems.

I rarely use debuggers (when I started programming they didn't exist, so I often debug manually) and I didn't know that the choice between gdb or fpdebug impacted the stack trace generation.

[Martin_fr]

In 3.99 FpDebug has gained a bit, but with certain cases gdb still has the upper hand.
I know where I need to look to get FpDebug to full speed, but its a bigger piece of work.

The problem with gdb is that it has been primarily written for other compilers. Even though debug info is standardized, within the standard there exists many ways. And that is where FpDebug shines, at least when it works with an exe generated by FPC. (So the watches window will often get you better results under FpDebug).

[simone]

The stack trace is crucial to detect the cause of non-trivial stack overflow. In my case it was an hidden infinite mutual recursion present in my code. The use of gbd was decisive, thanks to its deeper stack trace.

Martin, I solved the problem with your suggestion. A thousand thanks!

[af0815]

In the picture of post #7 the stacktrace is limited to only "Max 10" entries. Why not more eg. "Max 50" ?!

[Martin_fr]

In the picture of post #7 the stacktrace is limited to only "Max 10" entries. Why not more eg. "Max 50" ?!

You mean "why has the OT not changed their default?" or "Why is the default itself 10"?

The default of the IDE really isn't that important. Because once you change it, it should be remembered.

I guess it was chosen when we were still using gdb. Back then it took longer to get the data (and it used to be blocking).
Though, do remember on Mac it is lldb, and an arm/arch Linux it is still gdb.

[af0815]

If i search more complex errors, i found 10 is sometimes not enough. In this situation, i can change to 50, knowing it consumes more time. 10 as default is not the problem and good for the speed, but not all know you can change this for searching in the depth. And after clearing the error, i go back to the 10