On 7/10/18 5:18 PM, kdevel wrote:
> On Tuesday, 10 July 2018 at 21:09:23 UTC, Steven Schveighoffer wrote:
> [...]
>> As far as the OS is concerned, a[2 .. $] is within the process memory limit.
>>
>> Of course, that's an out of bounds access, so the compiler or the bounds check *should* complain.
> 
> It complains at runtime
> 
>     > ./dumpme2
>     core.exception.RangeError@dumpme2.d(4): Range violation
>     ----------------
>     ??:? _d_arrayboundsp [0x42bb1e]
>     dumpme2.d:4 _Dmain [0x42ba42]
> 
> but how do I force the runtime to generate a coredump for real post-mortem analysis?

More difficult. You'd have to have a special runtime, and change the constructor for RangeError to access a null pointer.

-Steve

On Tuesday, 10 July 2018 at 21:18:01 UTC, kdevel wrote:
> but how do I force the runtime to generate a coredump for real post-mortem analysis?

Turn off rtTrapExceptions....

though the command line switch PR is STILL NOT MERGED

https://github.com/dlang/druntime/pull/2035


come on, people.

On Tuesday, 10 July 2018 at 22:31:54 UTC, Adam D. Ruppe wrote:
> Turn off rtTrapExceptions....
>
> though the command line switch PR is STILL NOT MERGED
>
> https://github.com/dlang/druntime/pull/2035

   extern (C) __gshared bool rt_trapExceptions;
   static this ()
   {
      rt_trapExceptions = false;
   }

plus

   -L-zmuldefs

is required for linking. It works. But why is that -zmuldefs linker option required? The "double extern" version

   extern extern (C) __gshared bool rt_trapExceptions;

compiles and links but does not behave seem to set the same variable.

On Tuesday, 10 July 2018 at 22:53:25 UTC, kdevel wrote:
>    extern (C) __gshared bool rt_trapExceptions;
>    static this ()
>    {
>       rt_trapExceptions = false;
>    }

This will catch exceptions raised in main and in static constructors that run after this one. However, if you put that code in the module that includes main(), it's probably going to be the last static constructor run. That means it doesn't impact other static constructors.

The only fix for that is putting this code in its own module that you add as the first import in every module. And if you depend on any library with a static constructor anywhere inside, you have to modify that library.

But exceptions can be thrown before any static constructor is run. The function that calls static constructors might detect a cycle straight off, for instance.

That's why the This Week In D post injected it into the C main function.

On Tuesday, 10 July 2018 at 20:57:02 UTC, Steven Schveighoffer wrote:
> On 7/10/18 4:02 PM, Per Nordlöw wrote:
>> On Tuesday, 10 July 2018 at 19:27:07 UTC, Steven Schveighoffer wrote:
>>> On 7/10/18 3:01 PM, Per Nordlöw wrote:
>>>> [...]
>>>
>>> Yes, call this function on startup:
>>>
>>> import etc.linux :  registerMemoryErrorHandler;
>>>
>>> void main()
>>> {
>>>     registerMemoryErrorHandler();
>>>     ...
>>> }
>>>
>>> No, it's not documented anywhere. Probably should be...
>>>
>> 
>> Okay thanks. When would you not want that behavior to be default?
>
> It was controversial at the time, and considered a hack. It's also only supported on Linux. So I don't know the reason why it's not always done for Linux, I really think it should be.
>
> -Steve

https://github.com/dlang/druntime/pull/2249

On Wednesday, 11 July 2018 at 04:17:49 UTC, Seb wrote:
> https://github.com/dlang/druntime/pull/2249

Thanks!