Bug 6088 – Stack trace or some info with stack overflow

This crashes at runtime because of a stack overflow (DMD 2.053). No stack trace, stack frame, error message or line number are shown: int foo(int n) { return n ? foo(n - 1) : 1; } void main() { foo(100_000); } If you aren't running a debugger then receiving a nude crash is not so nice, because in a larger program there are many functions that may be the cause of a stack overflow. So is it possible to produce a stack trace in this case too? If this is not possible, then an error message with the name of the last function called (and line number) or anything is useful. If necessary DMD may add some stack protection code in non-release mode only.

Regarding a stack overflow in a program Andrei has answered: > I think a better tail call optimization would be in order. A better compiler with better optimizations is welcome, but there are situations where even if you are able to optimize the code a lot, a stack overflow happens anyway. In such cases receiving some kind of error message (in debug builds only, if necessary) is quite useful.

This is partially a regression because if I compile that little foo+main program with DMD v2.050 it prints: object.Error: Stack Overflow That doesn't give a lot of information, but it explains the cause of the crash.

Using 2.055 it only returns exit code -1073741819 on XP32 at runtime. It used to display a stack overflow error in past releases, so this has to be a regression.

With 2.058 it prints: object.Error: Stack Overflow ---------------- 40B9FC 40B873 ... ----------------

(In reply to comment #4) > With 2.058 it prints: > > object.Error: Stack Overflow > ---------------- > 40B9FC > 40B873 > ... > ---------------- I can't reproduce it, so if someone confirms it this regression needs to be reopened. I am using Win Vista 32 bit, I compile with dmd 2.058head using the GitHub of Feb 5, and the demo code (foo + main) crashes with no messages.

What OS and wordsize have you used Walter? I have asked on IRC, and the situation seems very confused. Two other persons have received a nude 'Segmentation fault' and "segment fault 11". So I think this preliminary and incomplete evidence is enough to justify reopening this bug report, asking for further testing.

XP32, 2.057 and 2.058 don't print a stack trace.

It depends on the version of dbghelp.dll. From an earlier discussion on the d-runtime mailing list: On XP I have version 5.1.2600.5512, it fails. on Win7, it is 6.1.7600.16385 and works. Also there is version 6.11.1.404 in Microsofts "Debugging Tools for Windows (x86)" which also works on XP.

(In reply to comment #8) > It depends on the version of dbghelp.dll. > > From an earlier discussion on the d-runtime mailing list: On XP I have version > 5.1.2600.5512, it fails. on Win7, it is 6.1.7600.16385 and works. Also there is > version 6.11.1.404 in Microsofts "Debugging Tools for Windows (x86)" which also > works on XP. What works exactly? Win7 x64: http://i.imgur.com/r2Tl4.png Where's the stack overflow error?

Windows 7 user here. It works and prints a nice stack trace when I compile and run my console program with rdmd, but with a Windows one (using WinMain) it doesn't. The stack trace just print the first thrown exception, and between the dashed lines y only get some memory addresses.

>What works exactly? Win7 x64: http://i.imgur.com/r2Tl4.png >Where's the stack overflow error? You are right, my previous tests have been with access violations and explicite throw. A stack overflow is a lot nastier and another stack overflow is raised while trying to create the stack trace. BTW: even when a stack trace is printed, it doesn't show a lot of useful information in the original example: char*p; int foo(int n) { if(n==99990) *p = 1; return n ? foo(n - 1) : 1; } void main() { foo(100_000); } c:\>dmd -g test.d c:\>test object.Error: Access Violation ---------------- ... ---------------- It seems better with non-recursive functions, but actually, I don't care. I usually use a dirty hack to get rid of stack trace generation in exceptions.

(In reply to comment #10) > Windows 7 user here. It works and prints a nice stack trace when I compile and > run my console program with rdmd, but with a Windows one (using WinMain) it > doesn't. I guess you will need to run it from the console to see the output. > The stack trace just print the first thrown exception, and between the dashed > lines y only get some memory addresses. You need to compile your application with debug information. There is a higher chance to get symbolic results after converting the debug info with cv2pdb.

(In reply to comment #12) > (In reply to comment #10) > > Windows 7 user here. It works and prints a nice stack trace when I compile and > > run my console program with rdmd, but with a Windows one (using WinMain) it > > doesn't. > > I guess you will need to run it from the console to see the output. I actually print the catched exception using MessageBox, So I get a similar result as the Console, but with the memory addresses. > > The stack trace just print the first thrown exception, and between the dashed > > lines y only get some memory addresses. > > You need to compile your application with debug information. There is a higher > chance to get symbolic results after converting the debug info with cv2pdb. Yes, I'm doing that. I compile with -g.

This relies on Windows itself creating a stack overflow structured exception event, which is then captured by druntime and turned into a D exception. The trouble is, I've never been able to get Windows to reliably create these upon stack overflow. Sometimes, it generates other faults instead. In other words, it's always behaved erratically, and is not a regression. Nor do I think it is a serious problem, because it isn't caught by C or C++ runtimes, nor for D on non-Windows platforms. It's just a nicety that druntime tries at all to catch this.

(In reply to comment #14) > This relies on Windows itself creating a stack overflow structured exception > event, which is then captured by druntime and turned into a D exception. > > The trouble is, I've never been able to get Windows to reliably create these > upon stack overflow. Sometimes, it generates other faults instead. > > In other words, it's always behaved erratically, and is not a regression. Nor > do I think it is a serious problem, because it isn't caught by C or C++ > runtimes, nor for D on non-Windows platforms. It's just a nicety that druntime > tries at all to catch this. It also heavily depends on the dbghelp.dll version that the programmer has in its system. I've had different results in different machines with the same code, and it turns out that it was because different versions of the aforementioned file.

(In reply to comment #14) > In other words, it's always behaved erratically, and is not a regression. I have just done a little binary search, and I've found that up to DMD 2.052, DMD always shows "stack overflow", reliably, every time. And starting from DMD 2.053 it never shows "stack overflow". This test is done on the same machine, so I think it's a problem inside the DMD zip and not outside it, like in the operating system or its libs. So I think this is a regression, to be searched inside the changed of 2.053. > Nor do I think it is a serious problem, because it isn't caught by C or C++ > runtimes, nor for D on non-Windows platforms. It's just a nicety that druntime > tries at all to catch this. It's not a serious problem, but the missing stack overflow error has confused me in the beginning. I have seen two other persons confused by the crash. One of them was in D.learn: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=32133 A "stack overflow" message is a simple thing, but most programmers know what a stack overflow is, and this avoids confusion. Knowing what's the cause of the crash is useful if you don't run a debugger. If you know it's a stack overflow, you start searching for bad behaving recursive functions in your program. So while this is not a serious problem, DMD used to give this valuable information to me until some time ago, and I'd like to have it back.

(In reply to comment #16) > DMD used to give this valuable > information to me until some time ago, and I'd like to have it back. Please :-) (and sorry for my tone)

The problem is likely that the added stack trace generation causes another stack overflow.

(In reply to comment #18) > The problem is likely that the added stack trace generation causes another > stack overflow. Then a possible idea to solve this problem: in nonrelease mode at the beginning of the program (before main?) reserve some free stack space, to be used later by the routine that shows the stack overflow.

Note that fixing issue 3713 will prevent a stack overflow from being generated in these cases.