Q: Would it mean a lot of work to add
null pointer/reference checks to DMD ?


Currently it has array bounds checks:

array.d:
> void main()
> {
>   byte[] a = new byte[32];
>   a[33] = 1;
> }

Which are "optional", for speed:

> $ dmd -debug array.d                                                                                   [182]
> $ ./array                                                                                              [183]
> Error: ArrayBoundsError array.d(4)
> $ dmd -release array.d                                                                                 [184]
> $ ./array                                                                                              [185]
> $

Same as in Java (the language):

Array.java:
> public class Array
> {
>   public static void main(String[] args)
>   {
>     byte[] a = new byte[32];
>     a[33] = 1;
>   }
> }

> $ jikes Array.java
> $ java Array                                                                                           [187]
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 33
>         at Array.main(Array.java:6)

(Java doesn't come with a "fast" option)


But null doesn't have the same feature :

null.d:
> void main()
> {
>   Object o = null;
>   o.toString();
> }

And DMD happily dereferences the null pointer:

> $ dmd -debug null.d $ ./null
> Bus error

A nice (debug) feature would be something like:

Null.java:
> public class Null
> {
>   public static void main(String[] args)
>   {
>     Object o = null;
>     o.toString();
>   }
> }

Which gives a runtime exception, with more info:

> $ jikes Null.java                                                                                      [196]
> $ java Null                                                                                            [197]
> Exception in thread "main" java.lang.NullPointerException
>         at Null.main(Null.java:6)

(which at least gives the line, and can be caught)


So, what would it take for -debug builds in D to
throw a similar "NullPointerError" exception ?

(again, they could be skipped in -release builds
for performance reasons - once the bugs are out)

--anders


PS. Pointers wouldn't have to be affected by the checks,
    but checking all Object references would be nice...

    Especially with the dreaded if (null==object) bugs ?
    http://www.digitalmars.com/d/archives/12141.html
    http://www.digitalmars.com/d/archives/12144.html

Why? When running from a debugger, it already breaks and shows you the line (if compiled with -g -debug).

Although the "bus error" is indeed way too vague. Maybe it's meant as a funny error message? In which case I don't get it :-/

L.

"Anders F Björklund" <afb@algonet.se> wrote in message news:cs3dpa$1t99$1@digitaldaemon.com...
> So, what would it take for -debug builds in D to
> throw a similar "NullPointerError" exception ?

It already does, thrown as an instance of "Exception" with a message of "Access Violation". It even happens in release builds (because it's done by the hardware!).

Walter wrote:

>>So, what would it take for -debug builds in D to
>>throw a similar "NullPointerError" exception ?
> 
> It already does, thrown as an instance of "Exception" with a message of
> "Access Violation". It even happens in release builds (because it's done by
> the hardware!).

Maybe I have the wrong hardware then (not X86),
or perhaps the wrong OS software (not Windows) -
because I only see a EXC_BAD_ACCESS or SIGSEGV ?

No Exceptions, and no trapping by the D runtime...

Mac OS X: (GDC)
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> 0x000025d4 in _Dmain () at null.d:6
> 6           o.toString();
> (gdb)

Linux X86: (DMD)
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1085177728 (LWP 2067)]
> _Dmain () at null.d:6
> 6           o.toString();
> (gdb)

But I guess I can live with just using the debugger.

--anders


PS. The test program was:

null.d:
> void main()
> {
>   try
>   {
>     Object o = null;
>     o.toString();
>   }
>   catch (Exception ex)
>   {
>     printf("Got an exception: %.*s\n", ex.toString());
>   }
> }

Ok, I see the problem. Under windows, access violations are trapped and converted into D exceptions. This isn't done under linux, though it should be. Though you're still receiving a reasonable message identifying the location of the error!

"Anders F Björklund" <afb@algonet.se> wrote in message news:csapi1$1q6m$1@digitaldaemon.com...
> Walter wrote:
>
> >>So, what would it take for -debug builds in D to
> >>throw a similar "NullPointerError" exception ?
> >
> > It already does, thrown as an instance of "Exception" with a message of "Access Violation". It even happens in release builds (because it's done
by
> > the hardware!).
>
> Maybe I have the wrong hardware then (not X86),
> or perhaps the wrong OS software (not Windows) -
> because I only see a EXC_BAD_ACCESS or SIGSEGV ?
>
> No Exceptions, and no trapping by the D runtime...
>
> Mac OS X: (GDC)
> > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > 0x000025d4 in _Dmain () at null.d:6
> > 6           o.toString();
> > (gdb)
>
> Linux X86: (DMD)
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread -1085177728 (LWP 2067)]
> > _Dmain () at null.d:6
> > 6           o.toString();
> > (gdb)
>
> But I guess I can live with just using the debugger.
>
> --anders
>
>
> PS. The test program was:
>
> null.d:
> > void main()
> > {
> >   try
> >   {
> >     Object o = null;
> >     o.toString();
> >   }
> >   catch (Exception ex)
> >   {
> >     printf("Got an exception: %.*s\n", ex.toString());
> >   }
> > }

Walter wrote:

> Ok, I see the problem. Under windows, access violations are trapped and converted into D exceptions. This isn't done under linux, though it should be. Though you're still receiving a reasonable message identifying the location of the error!

This is what happens for Unix in general: at the point of an access violation, a SIGSEGV is triggered. The program could capture this signal and transform it into an exception. Obviously, the GDC code in MacOS X does this, while the DMD on Linux does not.

The error message comes from the debugger that traps any kind of signals. On
MacOS X (GDC), it traps the uncaught exception, while under Linux (DMD), it
traps the SIGSEGV itself.

Obviously, the DMD has some problem there.


> "Anders F Björklund" <afb@algonet.se> wrote in message news:csapi1$1q6m$1@digitaldaemon.com...
>> Walter wrote:
>>
>> >>So, what would it take for -debug builds in D to
>> >>throw a similar "NullPointerError" exception ?
>> >
>> > It already does, thrown as an instance of "Exception" with a message of "Access Violation". It even happens in release builds (because it's done
> by
>> > the hardware!).
>>
>> Maybe I have the wrong hardware then (not X86),
>> or perhaps the wrong OS software (not Windows) -
>> because I only see a EXC_BAD_ACCESS or SIGSEGV ?
>>
>> No Exceptions, and no trapping by the D runtime...
>>
>> Mac OS X: (GDC)
>> > Program received signal EXC_BAD_ACCESS, Could not access memory.
>> > 0x000025d4 in _Dmain () at null.d:6
>> > 6           o.toString();
>> > (gdb)
>>
>> Linux X86: (DMD)
>> > Program received signal SIGSEGV, Segmentation fault.
>> > [Switching to Thread -1085177728 (LWP 2067)]
>> > _Dmain () at null.d:6
>> > 6           o.toString();
>> > (gdb)
>>
>> But I guess I can live with just using the debugger.
>>
>> --anders
>>
>>
>> PS. The test program was:
>>
>> null.d:
>> > void main()
>> > {
>> >   try
>> >   {
>> >     Object o = null;
>> >     o.toString();
>> >   }
>> >   catch (Exception ex)
>> >   {
>> >     printf("Got an exception: %.*s\n", ex.toString());
>> >   }
>> > }

Norbert Nemec wrote:

> This is what happens for Unix in general: at the point of an access
> violation, a SIGSEGV is triggered. The program could capture this signal
> and transform it into an exception. Obviously, the GDC code in MacOS X does
> this, while the DMD on Linux does not.
> 
> The error message comes from the debugger that traps any kind of signals. On
> MacOS X (GDC), it traps the uncaught exception, while under Linux (DMD), it
> traps the SIGSEGV itself.
> 
> Obviously, the DMD has some problem there.

I'm not sure if it is DMD, since GDC on Linux has the same behaviour ?

i.e. it also shows a SIGSEGV, when run through the "gdb" debugger...

--anders

Walter wrote:

>>Maybe I have the wrong hardware then (not X86),
>>or perhaps the wrong OS software (not Windows) -
>>because I only see a EXC_BAD_ACCESS or SIGSEGV ?
>>
>>No Exceptions, and no trapping by the D runtime...
>>
> Ok, I see the problem. Under windows, access violations are trapped and
> converted into D exceptions. This isn't done under linux, though it should
> be. Though you're still receiving a reasonable message identifying the
> location of the error!

That is: if I compile with DFLAGS="-g -debug",
and run it using the gdb debugger, it does...

If I do a -release build and run it, I just get:
"bus error"

But since the whole thing was about showing more
info when debugging, I'll consider this closed now.

--anders

PS.
It has nothing do with jokes or public transport.
See http://en.wikipedia.org/wiki/Bus_error

Anders F Björklund wrote:

> Norbert Nemec wrote:
> 
>> This is what happens for Unix in general: at the point of an access violation, a SIGSEGV is triggered. The program could capture this signal and transform it into an exception. Obviously, the GDC code in MacOS X does this, while the DMD on Linux does not.
>> 
>> The error message comes from the debugger that traps any kind of signals.
>> On MacOS X (GDC), it traps the uncaught exception, while under Linux
>> (DMD), it traps the SIGSEGV itself.
>> 
>> Obviously, the DMD has some problem there.
> 
> I'm not sure if it is DMD, since GDC on Linux has the same behaviour ?
> 
> i.e. it also shows a SIGSEGV, when run through the "gdb" debugger...
> 
> --anders

OK, that would mean that 'EXC_BAD_ACCESS' on MacOS X is equivalent to SIGSEGV on Linux. In that case, it would be a bug in both compilers under Unix in general.

Anders F Björklund wrote:

> Walter wrote:
> 
>  >>Maybe I have the wrong hardware then (not X86),
>  >>or perhaps the wrong OS software (not Windows) -
>  >>because I only see a EXC_BAD_ACCESS or SIGSEGV ?
>  >>
>  >>No Exceptions, and no trapping by the D runtime...
>  >>
>> Ok, I see the problem. Under windows, access violations are trapped and converted into D exceptions. This isn't done under linux, though it should be. Though you're still receiving a reasonable message identifying the location of the error!
> 
> That is: if I compile with DFLAGS="-g -debug",
> and run it using the gdb debugger, it does...
> 
> If I do a -release build and run it, I just get:
> "bus error"
> 
> But since the whole thing was about showing more
> info when debugging, I'll consider this closed now.

Not quite closed. If access violations are supposed to be converted into Exceptions, there still is a bug in the unix versions of the compiler. Not a serious one - since debugging is possble with the gdb - but still a bug.

In any case "bus error" sounds rather strange to me. I had a number of segfaults in various languages in the past, but I never saw these words in an error message...