www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Better diagnostics for null classes dereferencing

reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
Is it possible to change run-time behaviour of null-class 
dereferencing, on Linux, so that it gives some other diagnostics 
than:

Program exited with code -11

Does DMD and LDC provide different alternatives here?
Jul 10 2018
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/10/18 3:01 PM, Per Nordlöw wrote:

 Is it possible to change run-time behaviour of null-class dereferencing, 
 on Linux, so that it gives some other diagnostics than:
 
 Program exited with code -11
 
 Does DMD and LDC provide different alternatives here?


Yes, call this function on startup:

import etc.linux :  registerMemoryErrorHandler;

void main()
{
     registerMemoryErrorHandler();
     ...
}

No, it's not documented anywhere. Probably should be...

-Steve
Jul 10 2018
next sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 10 July 2018 at 19:27:07 UTC, Steven Schveighoffer 
wrote:

 On 7/10/18 3:01 PM, Per Nordlöw wrote:

 Is it possible to change run-time behaviour of null-class 
 dereferencing, on Linux, so that it gives some other 
 diagnostics than:
 
 Program exited with code -11
 
 Does DMD and LDC provide different alternatives here?


 Yes, call this function on startup:

 import etc.linux :  registerMemoryErrorHandler;

 void main()
 {
     registerMemoryErrorHandler();
     ...
 }

 No, it's not documented anywhere. Probably should be...

 -Steve


Okay thanks. When would you not want that behavior to be default?
Jul 10 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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:

 Is it possible to change run-time behaviour of null-class 
 dereferencing, on Linux, so that it gives some other diagnostics than:

 Program exited with code -11

 Does DMD and LDC provide different alternatives here?


 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
Jul 10 2018
parent reply Seb <seb wilzba.ch> writes:
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
Jul 10 2018
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 11 July 2018 at 04:17:49 UTC, Seb wrote:

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


Thanks!
Jul 11 2018
prev sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 10 July 2018 at 19:27:07 UTC, Steven Schveighoffer 
wrote:

 import etc.linux :  registerMemoryErrorHandler;


Needs to be:

import etc.linux.memoryerror : registerMemoryErrorHandler;
Jul 10 2018
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 10 July 2018 at 19:01:22 UTC, Per Nordlöw wrote:

 Is it possible to change run-time behaviour of null-class 
 dereferencing, on Linux, so that it gives some other 
 diagnostics than:


Run the program in a debugger, or run `ulimit -c unlimited` to 
enable core dumps so you can run a debugger on the dead program 
after the fact.
Jul 10 2018
parent reply kdevel <kdevel vogtner.de> writes:
On Tuesday, 10 July 2018 at 20:10:54 UTC, Adam D. Ruppe wrote:

 On Tuesday, 10 July 2018 at 19:01:22 UTC, Per Nordlöw wrote:


[...]

 Run the program in a debugger, or run `ulimit -c unlimited` to 
 enable core dumps [...]


Works for null ptr deref but how do I enforce core dumps in this 
code:

dumpme2.d
---
void main ()
{
    int [1] a;
    auto s = a[2 .. $];
}
---
Jul 10 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/10/18 5:01 PM, kdevel wrote:

 On Tuesday, 10 July 2018 at 20:10:54 UTC, Adam D. Ruppe wrote:

 On Tuesday, 10 July 2018 at 19:01:22 UTC, Per Nordlöw wrote:


 [...]

 Run the program in a debugger, or run `ulimit -c unlimited` to enable 
 core dumps [...]


 
 Works for null ptr deref but how do I enforce core dumps in this code:
 
 dumpme2.d
 ---
 void main ()
 {
     int [1] a;
     auto s = a[2 .. $];
 }
 ---
 


Core dumps are triggered from the process accessing memory it doesn't 
own. 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.

-Steve
Jul 10 2018
parent reply kdevel <kdevel vogtner.de> writes:
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?
Jul 10 2018
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jul 10 2018
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jul 10 2018
parent reply kdevel <kdevel vogtner.de> writes:
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.
Jul 10 2018
parent Neia Neutuladh <neia ikeran.org> writes:
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.
Jul 10 2018
prev sibling parent Seb <seb wilzba.ch> writes:
On Tuesday, 10 July 2018 at 19:01:22 UTC, Per Nordlöw wrote:

 Is it possible to change run-time behaviour of null-class 
 dereferencing, on Linux, so that it gives some other 
 diagnostics than:

 Program exited with code -11

 Does DMD and LDC provide different alternatives here?


On a Systemd system coredumps are typically configured to be 
automatically generated and saved.
For example you can start up gdb at the most recent crash:

coredumpctl gdb -1
Jul 10 2018