www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - NullPointerError?

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 12 2005
next sibling parent "Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:
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.
Jan 14 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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!).
Jan 14 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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());
   }
 }
Jan 15 2005
parent reply "Walter" <newshound digitalmars.com> writes:
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());
   }
 }
Jan 15 2005
next sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
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());
   }
 }
Jan 16 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 16 2005
parent Norbert Nemec <Norbert Nemec-online.de> writes:
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.
Jan 16 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 16 2005
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
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...
Jan 16 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Norbert Nemec wrote:


 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.


Or at least undocumentated behaviour, Exceptions only on Windows.


 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...


That's just what the bash shell reports, when the program crashes...

--anders
Jan 16 2005
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Anders F Björklund wrote:


 Norbert Nemec wrote:
 

 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.


 
 Or at least undocumentated behaviour, Exceptions only on Windows.


Well - calling it "feature" would sound a bit bold. Calling it "known issue"
would be honest but lazy. Calling it "bug" would be just honest... :-)


 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...


 
 That's just what the bash shell reports, when the program crashes...


?? I've been using bash for years and always got "Segmentation fault" as
error message on crashes.
Jan 16 2005
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Norbert Nemec wrote:


That's just what the bash shell reports, when the program crashes...


 
 ?? I've been using bash for years and always got "Segmentation fault" as
 error message on crashes.


Oh, it does that on Linux (SIGSEGV):


 $ uname
 Linux
 $ ./null 
 Segmentation fault


On Mac OS X, you get a EXC_BAD_ACCESS:


 $ uname                                                                       
                          [1]
 Darwin
 $ ./null
 Bus error


Same thing, just with different names for it...
(apparently Windows calls it Access Violation?)

--anders
Jan 17 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 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!).


Why is this not a subclass ? (named, say, "NullPointerError" or so)
Seems a bit non-oop to have to look at the message of the Exception.

But it seems like the confusion has been cleared up now. It does throw
an exception on *null, just that it only works on Windows at the moment.


I guess that in -release builds, the Exception does not carry any info
about the source file and line number ? (since that info comes with -g)

Does all builds have symbol information on Windows, or how does the
exceptions work there ? (maybe it never has any such info available ?)


Here's what it looks like on the Mac:

With debug info: ["dmd -g -debug null.d", program size = 320 KB]


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



/SourceCache/Csu/Csu-47/crt.c:267



Without (strip): ["dmd -s -release null.d", program size = 100 KB]


 Program received signal EXC_BAD_ACCESS, Could not access memory.
 0x000025d4 in ?? ()
 (gdb) bt






You can of course still disassemble the stripped binary, if needed.

--anders
Jan 16 2005