Doing a null deref such as

    int* y = null;
    *y = 42;                    // boom

currently outputs

/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x406474]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0)[0x7f08cf25e3d0]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x40233a]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x4023b9]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x4064c1]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x405704]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x40be2b]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x40c2d2]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x40bdbc]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x4056e0]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x4063b3]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x402a97]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x402a39]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x4029aa]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x402540]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f08ce77c830]
/home/per/.emacs.d/auto-builds/dmd/Debug-Unittest-Require-Full-Coverage/home/per/foo[0x402219]

Is there a way to get a stacktrace instead?

I'm using dmd git master.

On Wednesday, 21 September 2016 at 23:36:08 UTC, Nordlöw wrote:

> Is there a way to get a stacktrace instead?

{ import etc.linux.memoryerror; registerMemoryErrorHandler(); }

warning: this is hightly system-specific, and may work or not work depending of the moon phase, and may broke on any system upgrade.

On Wednesday, 21 September 2016 at 23:36:08 UTC, Nordlöw wrote:
> Doing a null deref such as
>
>     int* y = null;
>     *y = 42;                    // boom
>
> [...]

Can you include compiler command line?  I use -g -gs -debug to get stack traces on windows.

On Thursday, 22 September 2016 at 00:46:19 UTC, ketmar wrote:
> { import etc.linux.memoryerror; registerMemoryErrorHandler(); }

Thx! That at least triggered an exception. However the line number for the innermost function is wrong. For instance

1   void boom()
2   {
3       int* y = null;
4       *y = 42;                    // boom
5   }

gives stacktrace

etc.linux.memoryerror.NullPointerError@src/etc/linux/memoryerror.d(325)
----------------
??:? [0x404e6d]
??:? [0x404dba]
t_segFaulException.d:3 [0x402301]
t_segFaulException.d:22 [0x402370]
??:? [0x402a2e]
??:? [0x402978]
??:? [0x4029ea]
??:? [0x402978]
??:? [0x4028e9]
??:? [0x40247f]
??:? __libc_start_main [0x2867d82f]

A known bug?

On Thursday, 22 September 2016 at 19:51:31 UTC, Nordlöw wrote:
> A known bug?

prolly. segfault handler is highly non-standard hack, it may miss exact position or something. as is "it is not guaranteed to work, and if it will work, it is not guaranteed to work correctly".

p.s. that is the reason it is not turned on by default, btw.

On Thursday, 22 September 2016 at 19:51:31 UTC, Nordlöw wrote:
> A known bug?

Yeah, it shows the line before instead of the line of. But it still shows basically where you are.