Thread overview | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
January 12, 2005 NullPointerError? | ||||
---|---|---|---|---|
| ||||
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 |
January 14, 2005 Re: NullPointerError? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | 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. |
January 15, 2005 Re: NullPointerError? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | "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!). |
January 15, 2005 Re: NullPointerError? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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()); > } > } |
January 15, 2005 Re: NullPointerError? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | 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()); > > } > > } |
January 16, 2005 Re: NullPointerError? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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()); >> > } >> > } |
January 16, 2005 Re: NullPointerError? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Norbert Nemec | 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
|
January 16, 2005 Re: NullPointerError? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 |
January 16, 2005 Re: NullPointerError? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | 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.
|
January 16, 2005 Re: NullPointerError? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | 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...
|
Copyright © 1999-2021 by the D Language Foundation