Jump to page: 1 2
Thread overview
Better diagnostics for null classes dereferencing
Jul 11
Seb
Jul 10
kdevel
Jul 10
kdevel
Jul 10
kdevel
Jul 10
Seb
July 10
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?
July 10
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
July 10
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?
July 10
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.
July 10
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
July 10
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
July 10
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 .. $];
}
---

July 10
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
July 10
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?
July 10
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;

« First   ‹ Prev
1 2