February 05, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6088



--- Comment #11 from Rainer Schuetze <r.sagitario@gmx.de> 2012-02-05 11:50:46 PST ---
>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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 05, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6088



--- Comment #12 from Rainer Schuetze <r.sagitario@gmx.de> 2012-02-05 11:54:48 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 05, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6088



--- Comment #13 from Yao Gomez <yao.gomez@gmail.com> 2012-02-05 13:41:20 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 06, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6088


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|regression                  |minor


--- Comment #14 from Walter Bright <bugzilla@digitalmars.com> 2012-02-05 16:01:11 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 06, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6088



--- Comment #15 from Yao Gomez <yao.gomez@gmail.com> 2012-02-05 16:10:26 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 06, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6088



--- Comment #16 from bearophile_hugs@eml.cc 2012-02-05 17:43:00 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 06, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6088



--- Comment #17 from bearophile_hugs@eml.cc 2012-02-05 17:55:47 PST ---
(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)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 06, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6088


dawg@dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg@dawgfoto.de


--- Comment #18 from dawg@dawgfoto.de 2012-02-06 02:07:21 PST ---
The problem is likely that the added stack trace generation causes another stack overflow.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 25, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6088



--- Comment #19 from bearophile_hugs@eml.cc 2012-02-24 18:19:13 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 25, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6088


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com


--- Comment #20 from yebblies <yebblies@gmail.com> 2012-02-25 14:16:49 EST ---
Note that fixing issue 3713 will prevent a stack overflow from being generated in these cases.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
1 2
Next ›   Last »