January 16, 2005
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
January 16, 2005
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
> #0  0x000025d4 in _Dmain () at null.d:6
> #1  0x00002718 in _D6dmain29true_mainFiPPaZi ()
> #2  0x000021dc in _start (argc=1, argv=0xbffffb78, envp=0xbffffb80) at /SourceCache/Csu/Csu-47/crt.c:267
> #3  0x8fe1a558 in __dyld__dyld_start ()

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
> #0  0x000025d4 in ?? ()
> #1  0x000025c0 in ?? ()
> #2  0x000021dc in ?? ()
> #3  0x8fe1a558 in __dyld__dyld_start ()

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

--anders
January 17, 2005
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.


January 17, 2005
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
1 2
Next ›   Last »