https://d.puremagic.com/issues/show_bug.cgi?id=1001


Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu


--- Comment #63 from Martin Nowak <code@dawg.eu> 2014-01-05 07:28:16 PST ---
So we have stack traces on all platforms by now, can I close the bug?

Regarding DWARF processing, it shouldn't be too hard.
But we could also dynamically load libdw.so from elfutils if it's installed
similarly to how we load dbghelp.dll on Windows.

http://forum.dlang.org/post/eahjyebbtjynlivijqtn@forum.dlang.org https://github.com/bombela/backward-cpp

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #64 from Benjamin Thaut <code@benjamin-thaut.de> 2014-01-06 10:46:55 PST ---
on Windows 64 bit a executable still crashes silently when a access violation occures. At least with 2.064.2

Code used to test:
import core.stdc.stdio;

void test()
{
  int* i;
  *i = 5;
}

void main(string[] args)
{
test();
printf("done\n");
}

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #65 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-01-06 22:21:36 EET ---
(In reply to comment #64)
> on Windows 64 bit a executable still crashes silently when a access violation occures. At least with 2.064.2

Fixed in git HEAD, see Issue 11865.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #66 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-01-06 22:22:50 EET ---
(In reply to comment #65)
> (In reply to comment #64)
> > on Windows 64 bit a executable still crashes silently when a access violation occures. At least with 2.064.2
> 
> Fixed in git HEAD, see Issue 11865.

My bad, never mind. I get a WER dialog, though, so it's not silent?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #67 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-01-06 23:55:44 EET ---
(In reply to comment #66)
> My bad, never mind. I get a WER dialog, though, so it's not silent?

Putting a null pointer dereference into try/catch does not catch it, so I guess the root cause is that D exceptions are not integrated with Windows exceptions (through SEH or whatever mechanism is used on Win64).

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #68 from Benjamin Thaut <code@benjamin-thaut.de> 2014-01-06 13:59:30 PST ---
Its not neccessary to implement windows SEH on 64-bit to support stack traces on access violations (or other hardware exceptions). For now we could simply use SetUnhandledExceptionFilter to handle such errors and then terminate the program.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #69 from Martin Nowak <code@dawg.eu> 2014-01-07 02:20:21 PST ---
(In reply to comment #67)
> Putting a null pointer dereference into try/catch does not catch it, so I guess the root cause is that D exceptions are not integrated with Windows exceptions (through SEH or whatever mechanism is used on Win64).

Which is rather good, turning asynchronous SEH into normal Exceptions ws a bad idea.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #70 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-01-07 12:24:10 EET ---
(In reply to comment #69)
> Which is rather good, turning asynchronous SEH into normal Exceptions ws a bad idea.

Could you elaborate why? I thought SEH was designed so that it would integrate neatly with C++ exceptions.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #71 from Martin Nowak <code@dawg.eu> 2014-01-07 02:55:12 PST ---
http://en.wikipedia.org/wiki/Exception_handling#Exception_synchronicity It's simply that the compiler cannot handle cleanup when every instruction could throw. In case an asynchronous exception happens in the middle of some statement your program is immediately in an invalid state. Continuing could deadlock or corrupt data, much worse than a crash.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #72 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-01-11 14:06:23 EET ---
(In reply to comment #71)
> It's simply that the compiler cannot handle cleanup when every instruction could throw. In case an asynchronous exception happens in the middle of some statement your program is immediately in an invalid state. Continuing could deadlock or corrupt data, much worse than a crash.

OK... so the problem is basically that we call destructors / finally blocks / scope(exit) blocks when Errors are thrown, and those may behave in a bad way since the program was in an indeterminate state? I imagine that it's the same for signals on POSIX? In that case, I suppose we could handle both in the same way: immediately print a stack trace and exit, but still provide a mechanism for the user to customize handling of such conditions.

I recall a discussion regarding whether thrown Errors should call finalizers on the stack, but I suppose it's not really clear-cut.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------