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



--- Comment #73 from Martin Nowak <code@dawg.eu> 2014-01-11 10:53:13 PST ---
(In reply to comment #72)
> (In reply to comment #71)
> 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.

It's a bigger topic amd opinions vary. AFAIK Errors skip cleanup code, but it's possible to catch Errors to perform minimal cleanup.

-- 
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 #74 from Jonathan M Davis <jmdavisProg@gmx.com> 2014-01-11 15:16:45 PST ---
> It's a bigger topic amd opinions vary. AFAIK Errors skip cleanup code, but it's possible to catch Errors to perform minimal cleanup.

According to Walter, there is no guarantee that any cleanup code is run when an Error is thrown (though I'm not sure what the spec says on the matter). However, some of the folks that believe that cleanup should be done on Errors made it so that most cleanup code _is_ run when an Error is thrown. So, unless something is changed, I believe that normally finally blocks, scope(exit), scope(failure), and destructors will all be run when an Error is thrown. Where they will get skipped is when an Error is thrown from a nothrow function, and the cleanup code is outside the nothrow function, because the caller of the nothrow function will assume that the nothrow function doesn't throw anything and optimize based on that.

So, at this point, whether cleanup code is run on an Error depends on the code, and at minimum, it will never be the case that cleanup code is always run on an Error, because it won't be done for nothrow functions, or we lose the ability to optimize it based on the fact that it won't throw an exception (which is one its benefits). However, whether it will ever be changed such that cleanup code is never run for Errors is an open question and a topic of hot debate.

-- 
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 #75 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-02-15 22:17:15 EET ---
(In reply to comment #63)
> So we have stack traces on all platforms by now, can I close the bug?

What about line numbers? I think we only have them on Win64.

> Regarding DWARF processing, it shouldn't be too hard.

DWARF uses a weird state machine for efficient representation of file/line information. Doable but not trivial.

> But we could also dynamically load libdw.so from elfutils if it's installed similarly to how we load dbghelp.dll on Windows.

It's GPL just like binutils. IANAL, but I'm not sure about dynamically loading GPL libs. I know the GPL forbids redistribution of any programs that include the library... Doesn't that mean that it would make it impossible for e.g. Linux distributions to distribute non-GPL D software together with the library?

> https://github.com/bombela/backward-cpp

This seems to only support binutils and elfutils, both of which are GPL.

-- 
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


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #76 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2014-02-15 12:23:39 PST ---
(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
> 
> Code used to test:
> import core.stdc.stdio;
> 
> void test()
> {
>   int* i;
>   *i = 5;
> }
> 
> void main(string[] args)
> {
> test();
> printf("done\n");
> }

I can't reproduce this on Win7 x64 with 2.064. Here's the results for me:

$ dmd
> DMD32 D Compiler v2.064

$ dmd -run test.d
object.Error: Access Violation
----------------
0x00402012 in __xc_a
0x004022FF in __xi_a
0x00402217 in __xc_z
0x00402047 in __xc_a
0x75CC3677 in BaseThreadInitThunk
0x77859D72 in __RtlUserThreadStart
0x77859D45 in _RtlUserThreadStart
----------------

$ dmd -g -run test.d
object.Error: Access Violation
----------------
0x00402019 in void test.test() at C:\dev\code\d_code\test.d(6)
0x0040202C in _Dmain at C:\dev\code\d_code\test.d(12)
0x0040233C in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll().void __lambda1()
0x0040230F in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x00402227 in _d_run_main
0x00402054 in main
0x004140A9 in mainCRTStartup
0x75CC3677 in BaseThreadInitThunk
0x77859D72 in __RtlUserThreadStart
0x77859D45 in _RtlUserThreadStart
----------------

-- 
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 #77 from Benjamin Thaut <code@benjamin-thaut.de> 2014-02-15 12:31:09 PST ---
@Andrej Mitrovic
You forgott the -m64 switch in your test. You are testing 32-bit binaries. The
problem is not the 64 bit operating system it is the 64-bit executable, as 64
bit executables do not implement SEH.

-- 
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 #78 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-02-15 22:31:49 EET ---
(In reply to comment #76)
> I can't reproduce this on Win7 x64 with 2.064. Here's the results for me:

The problem applies to 64-bit programs. I can reproduce it with -m64.

(In reply to comment #75)
> It's GPL just like binutils. IANAL, but I'm not sure about dynamically loading GPL libs. I know the GPL forbids redistribution of any programs that include the library... Doesn't that mean that it would make it impossible for e.g. Linux distributions to distribute non-GPL D software together with the library?

Just found this: http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

Quoting:
> Q: If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?
> 
> A: Yes, because the software as it is actually run includes the library.

So I guess that gives us a definitive answer. We CANNOT use binutils or elfutils, so libdw and libbfd are out of the question. From the discussed options, that leaves FreeBSD's Elftoolchain, integrating with addr2line, or our own DWARF/ELF parser.

-- 
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 #79 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2014-02-15 12:50:07 PST ---
(In reply to comment #77)
> @Andrej Mitrovic
> You forgott the -m64 switch in your test. You are testing 32-bit binaries.

My bad. It's a huge thread and I didn't notice this. I can now confirm your test results with -m64.

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