www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tim Sweeney on Next Programming Language

reply Mike Parker <aldacron71 yahoo.com> writes:
Tim Sweeney of Epic Games recently gave a talk at POPL'06 titled "The 
Next Mainstream Programming Language: A Game Developer's Perspective". 
Using Epic's Unreal Engine 3 as an example, he goes through several 
limiting and costly issues with C++ and other current mainstream 
languages, then moves on to what he wants to do before closing with 
features he thinks the next mainstream language should have. If you 
aren't so interested in what he says about language features, it's 
interesting enough reading the insights he gives to the Unreal Engine.

http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
Feb 05 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Mike Parker" <aldacron71 yahoo.com> wrote in message 
news:ds6bbn$1tp3$1 digitaldaemon.com...

 Tim Sweeney of Epic Games recently gave a talk at POPL'06 titled "The Next 
 Mainstream Programming Language: A Game Developer's Perspective". Using 
 Epic's Unreal Engine 3 as an example, he goes through several limiting and 
 costly issues with C++ and other current mainstream languages, then moves 
 on to what he wants to do before closing with features he thinks the next 
 mainstream language should have. If you aren't so interested in what he 
 says about language features, it's interesting enough reading the insights 
 he gives to the Unreal Engine.

 http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf


Interesting how he comments time and time again how much he'd like null 
pointer dereferencing to be checked.. funny, last time I brought that up, 
Walter shot it down, since after all, access violations are more than 
enough!  Right guys?  Right?
Feb 05 2006
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:ds6oia$26g5$1 digitaldaemon.com...

 Interesting how he comments time and time again how much he'd like null 
 pointer dereferencing to be checked.. funny, last time I brought that up, 
 Walter shot it down, since after all, access violations are more than 
 enough!  Right guys?  Right?


I looked for his email address, but couldn't find it. I'd ask him how 
checking for null pointers in software before dereferencing would result in 
fewer bugs than having the hardware check it automatically. Because it 
won't:

    assert(p != null);
    p[3] = 2;

is not one whit more robust than:

    p[3] = 2;

The bug is not dereferencing a null pointer, it is why that pointer is null 
in the first place. Often, pointers are null because:

1) uninitialized data (he mentions that this is a big source of problems)

2) often, functions return NULL when they fail rather than throw an 
exception (like malloc() does)
Feb 05 2006
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 6 Feb 2006 01:00:03 -0500, Jarrett Billingsley wrote:


 "Mike Parker" <aldacron71 yahoo.com> wrote in message 
 news:ds6bbn$1tp3$1 digitaldaemon.com...

 Tim Sweeney of Epic Games recently gave a talk at POPL'06 titled "The Next 
 Mainstream Programming Language: A Game Developer's Perspective". Using 
 Epic's Unreal Engine 3 as an example, he goes through several limiting and 
 costly issues with C++ and other current mainstream languages, then moves 
 on to what he wants to do before closing with features he thinks the next 
 mainstream language should have. If you aren't so interested in what he 
 says about language features, it's interesting enough reading the insights 
 he gives to the Unreal Engine.

 http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf


 
 Interesting how he comments time and time again how much he'd like null 
 pointer dereferencing to be checked.. funny, last time I brought that up, 
 Walter shot it down, since after all, access violations are more than 
 enough!  Right guys?  Right?


I understood that this argument went something like ...

One can have null pointers checked by the compiler, by software at run
time, or by hardware at run time. The first is not always going to work (to
find all cases), the second is (can be) a performance hit and is
susceptible to compiler bugs, and the third is the fastest and always works
(on modern CPU's anyway).

So with the current D, one does get null pointer dereference checking; its
just that it looks like an access violation instead. So maybe we can plead,
cajole, whatever to make Walter give us a more meaningful message when an
access violation is the result of a NULL pointer (file name and line number
would be a bloody big help too).

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
6/02/2006 5:55:26 PM
Feb 05 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg 40tude.net...

 So with the current D, one does get null pointer dereference checking; its
 just that it looks like an access violation instead. So maybe we can 
 plead,
 cajole, whatever to make Walter give us a more meaningful message when an
 access violation is the result of a NULL pointer (file name and line 
 number
 would be a bloody big help too).


Compile with -g, and run it under the debugger. When the access violation 
happens, the debugger gives you the location of the fault, as well as a call 
stack trace.

It works even better than just a null check, it checks for any pointer value 
that falls outside of address space allocated to the process.
Feb 05 2006
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 5 Feb 2006 23:56:37 -0800, Walter Bright wrote:


 
 Compile with -g, and run it under the debugger. When the access violation 
 happens, the debugger gives you the location of the fault, as well as a call 
 stack trace.


I just *knew* you were going to say that <G>

For those that need to know about this in Windows environments...

You can get the Microsoft debugger from 
http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.6.03.5.exe

And once you install it, compile your D program with the -g switch.

To get it running under the debugger ...

  windbg mytest.exe

then press F5 till it stops running ... then look at the register values
and the assembly instruction to see what might be wrong. Easy eh? So you
thought you only had to learn D --- silly you. A good knowledge of
assembler is useful when using the debugger properly.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
6/02/2006 8:12:33 PM
Feb 06 2006
next sibling parent "Todor Totev" <umbra.tenebris list.ru> writes:
On Mon, 06 Feb 2006 11:16:36 +0200, Derek Parnell <derek psych.ward> wro=
te:


 On Sun, 5 Feb 2006 23:56:37 -0800, Walter Bright wrote:


 Compile with -g, and run it under the debugger. When the access  =





 violation
 happens, the debugger gives you the location of the fault, as well as=




 a  =


 call
 stack trace.


 I just *knew* you were going to say that <G>

 For those that need to know about this in Windows environments...

 You can get the Microsoft debugger from
 http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.6.03.5.=


exe

 And once you install it, compile your D program with the -g switch.

 To get it running under the debugger ...

   windbg mytest.exe

 then press F5 till it stops running ... then look at the register valu=


es

 and the assembly instruction to see what might be wrong. Easy eh? So y=


ou

 thought you only had to learn D --- silly you. A good knowledge of
 assembler is useful when using the debugger properly.



The standart answer Walter gives to that is "Microsoft's newer windbg's
seem to have dropped support for codeview debug info. But the one that  =

comes
on the Digital Mars CD *does* work."
Anyway you can try this one:
http://www.cs.nmt.edu/~cs221/jbpub/Detmer/Software/
Just download the exe & the dll files.
Of course, that version does NOT work with obj files compiled with curre=
nt  =

dmc
so if you are trying to bridge C or even worse C++ code with D you are o=
ut  =

of
luck but see above.
Another advice I receive is to use GDB but I really prefer to postpone m=
y  =

serious
usage of D that to come near that beast.
Cheers,
Todor
Feb 06 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1h25tvba9ut64.jgems5c0705k$.dlg 40tude.net...

 then press F5 till it stops running ... then look at the register values
 and the assembly instruction to see what might be wrong. Easy eh? So you
 thought you only had to learn D --- silly you. A good knowledge of
 assembler is useful when using the debugger properly.


When I run it under windbg, it pops up a window with the offending source 
line of code in context highlighted.

gdb will display the source line, too.

You can, of course, switch to an assembler view, but that isn't necessary.
Feb 06 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Tue, 07 Feb 2006 05:03:28 +1100, Walter Bright  
<newshound digitalmars.com> wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:1h25tvba9ut64.jgems5c0705k$.dlg 40tude.net...

 then press F5 till it stops running ... then look at the register values
 and the assembly instruction to see what might be wrong. Easy eh? So you
 thought you only had to learn D --- silly you. A good knowledge of
 assembler is useful when using the debugger properly.


 When I run it under windbg, it pops up a window with the offending source
 line of code in context highlighted.

 gdb will display the source line, too.

 You can, of course, switch to an assembler view, but that isn't  
 necessary.


Yes, I can see now that we should use a debugger because there cannot be  
any other alternative. No one would be capable of writing a compiler to  
issue an helpful message in this situation.

-- 
Derek Parnell
Melbourne, Australia
Feb 06 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds70qm$2d28$1 digitaldaemon.com...

 Compile with -g, and run it under the debugger. When the access violation 
 happens, the debugger gives you the location of the fault, as well as a 
 call stack trace.


Yeah, that'd be fantastic if the break didn't always happen in the middle of 
NTDLL.  And if the stack trace actually worked properly, which it doesn't, 
making it nearly impossible to find where the AV occurred.  (VS6)


 The bug is not dereferencing a null pointer, it is why that pointer is 
 null
 in the first place. Often, pointers are null because:

 1) uninitialized data (he mentions that this is a big source of problems)

 2) often, functions return NULL when they fail rather than throw an
 exception (like malloc() does)


In D, neither of these really apply.  All variables are initialized 
(including references to NULL, hint hint), and when functions fail, they 
throw an exception.  So it's very easy to get a null pointer - just forget 
to initialize a reference, and then try to access one of its members.  Or 
perhaps delete a reference (which, again, sets it to null) and try to access 
it.

Fun fact: I've yet to have an access violation in D that _wasn't_ because of 
a null reference.  And I've had quite a few.
Feb 06 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:ds7k3v$2ul7$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ds70qm$2d28$1 digitaldaemon.com...

 Compile with -g, and run it under the debugger. When the access violation 
 happens, the debugger gives you the location of the fault, as well as a 
 call stack trace.


 Yeah, that'd be fantastic if the break didn't always happen in the middle 
 of NTDLL.  And if the stack trace actually worked properly, which it 
 doesn't, making it nearly impossible to find where the AV occurred.  (VS6)


For the stack trace to work properly, it must be compiled with -g. 
Otherwise, stack frames are omitted from the code generation.
Feb 06 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds83p5$bmf$2 digitaldaemon.com...

 For the stack trace to work properly, it must be compiled with -g. 
 Otherwise, stack frames are omitted from the code generation.


No kidding.  Compiling without -g doesn't allow you to debug the program, 
period (unless you call stepping through unnamed assembly routines 
"debugging").  In VS6 (which uses WinDbg), the call stack view always gets 
messed up when debugging D programs - functions do not seem to stay on the 
stack.  They just get overwritten.

You also have a knack for responding to everything _but_ the most important 
part of a message.
Feb 06 2006
prev sibling next sibling parent reply "Charles" <noone nowhere.com> writes:
 Compile with -g, and run it under the debugger. When the access violation
 happens, the debugger gives you the location of the fault, as well as a


call

 stack trace.



Ummmm... What debugger, the 15 yeard old windbg that comes on the CD that
you have to purchase ?  Debugging D has become extremely painful , all these
great new age techniques to speed productivity, then it takes 5 - 6 hours to
setup an assembly level debugger , then a few years to learn assembly , and
your ready to use D!

The other access voilations throw line number and file, why this
inconsitency ?


"Walter Bright" <newshound digitalmars.com> wrote in message
news:ds70qm$2d28$1 digitaldaemon.com...

 "Derek Parnell" <derek psych.ward> wrote in message
 news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg 40tude.net...

 So with the current D, one does get null pointer dereference checking;




its

 just that it looks like an access violation instead. So maybe we can
 plead,
 cajole, whatever to make Walter give us a more meaningful message when




an

 access violation is the result of a NULL pointer (file name and line
 number
 would be a bloody big help too).


 Compile with -g, and run it under the debugger. When the access violation
 happens, the debugger gives you the location of the fault, as well as a


call

 stack trace.

 It works even better than just a null check, it checks for any pointer


value

 that falls outside of address space allocated to the process.
Feb 06 2006
parent reply "Charles" <noone nowhere.com> writes:
Actually the debugger that comes with the IDE is pretty nice once you get
used to it , but for me it would still be 100 times better if we got line
number and file names with all exceptions, I dont see how this could hurt
anything -- only help.

Charlie


"Charles" <noone nowhere.com> wrote in message
news:ds7o54$121$1 digitaldaemon.com...

 Compile with -g, and run it under the debugger. When the access




violation

 happens, the debugger gives you the location of the fault, as well as a


 call

 stack trace.



 Ummmm... What debugger, the 15 yeard old windbg that comes on the CD that
 you have to purchase ?  Debugging D has become extremely painful , all


these

 great new age techniques to speed productivity, then it takes 5 - 6 hours


to

 setup an assembly level debugger , then a few years to learn assembly ,


and

 your ready to use D!

 The other access voilations throw line number and file, why this
 inconsitency ?


 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:ds70qm$2d28$1 digitaldaemon.com...

 "Derek Parnell" <derek psych.ward> wrote in message
 news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg 40tude.net...

 So with the current D, one does get null pointer dereference checking;




 its

 just that it looks like an access violation instead. So maybe we can
 plead,
 cajole, whatever to make Walter give us a more meaningful message when




 an

 access violation is the result of a NULL pointer (file name and line
 number
 would be a bloody big help too).


 Compile with -g, and run it under the debugger. When the access




violation

 happens, the debugger gives you the location of the fault, as well as a


 call

 stack trace.

 It works even better than just a null check, it checks for any pointer


 value

 that falls outside of address space allocated to the process.
Feb 06 2006
parent reply Sebastián E. Peyrott <as7cf yahoo.com> writes:
I think Sweeney does make some valid points in his presentation, especially
regarding the future of computingthat seems to involve concurrency as it's main
paradigm. I'm a noob when it comes to those matters, so what should we expect
from D running on 20-core massively multithreaded systems?
He mentions manual synchronization (which I believe is what D provides, correct
me if wrong) as a problem in gameplay simulation (slide 49), what would the
solution be fot D?
Also, some of those Haskell concepts he mentions are interesting, I shall study
how they work.

[OT]Oh, I can envision a bright future where D is nearing v2.0 and Unreal Engine
4 is written completely in D...oh, yes, such a nice future.

--Sebastián
Feb 06 2006
parent Sean Kelly <sean f4.ca> writes:
Sebastián E. Peyrott wrote:

 I think Sweeney does make some valid points in his presentation, especially
 regarding the future of computingthat seems to involve concurrency as it's main
 paradigm. I'm a noob when it comes to those matters, so what should we expect
 from D running on 20-core massively multithreaded systems?
 He mentions manual synchronization (which I believe is what D provides, correct
 me if wrong) as a problem in gameplay simulation (slide 49), what would the
 solution be fot D?


The same at the moment.  The "atomic" parallelized functions he 
describes could be accomplished pretty easily--I have a class to handle 
this manually in C++ (which I suppose should be ported to D).  However, 
such parallelization requires the use of a semaphore, event, or 
condition variable to signal the work thread, so it really isn't 
worthwhile for very small tasks.  Memory synchronization when the task 
is complete is another issue, though the x86 memory model generally 
handles this automatically (not so for PPC or for other architectures).

I think he's right that transactional memory is likely the way things 
are going, but that has overhead issues as well.  The original proposal 
required all memory involved in the transaction to be held in the CPU 
cache, which requires the transaction to be very small, and imposes 
architecture-dependent constraints on software design.  A later proposal 
by the same people introduced the idea of virtual transactional memory 
which removes the CPU cache constraint in much the way that virtual 
memory support does for physical memory limitations.  This is likely 
ideal, but as both of these proposals require hardware changes, it may 
be a while before anything happens here--from what I've heard, the 
hardware folks are waiting for the theory to mature a bit before 
investing in it.

There have also been a bunch of all-software transactional designs that 
work by keeping multiple copies of objects around and messing with 
pointers to "commit" changes when the transaction is complete.  The only 
drawback to this method is that the multiple copies it requires incurs 
memory overhead, and cloning objects can be expensive.  However, this is 


somehow extended in some ways?).


Sean
Feb 06 2006
prev sibling next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 5 Feb 2006 23:56:37 -0800, Walter Bright  
<newshound digitalmars.com> wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg 40tude.net...

 So with the current D, one does get null pointer dereference checking;  
 its
 just that it looks like an access violation instead. So maybe we can
 plead,
 cajole, whatever to make Walter give us a more meaningful message when  
 an
 access violation is the result of a NULL pointer (file name and line
 number
 would be a bloody big help too).


 Compile with -g, and run it under the debugger. When the access violation
 happens, the debugger gives you the location of the fault, as well as a  
 call
 stack trace.

 It works even better than just a null check, it checks for any pointer  
 value
 that falls outside of address space allocated to the process.


Customers/Clients can/will not run our programs in a debugger.

Intermittent/situational faults often cannot be reliably reproduced in a  
debugger at a later stage.

We need a way to reliably produce:
  - [at least] a file and line number for the fault.
  - [at best] a complete stack trace.
  - [dream] a snapshot of the running state which we can re-execute at a  
later stage in a debugger.

To guarantee a piece of software is without fault is very hard  
(impossible?). To guarantee you will fix any such fault in a short space  
of time is much easier, the above will make that even easier still.

A large percentage of the code in the software I currently work on is  
there to guarantee that we can find and fix faults. We have memory  
tracking, handle tracking, deadlock detection, stack trace generation, a  
monitor process to restart the main process, etc.

When I was working on CGI applications I had my code store all it's input  
in a file. This file could be used at a later stage to reproduce that  
request. It made debugging reported faults trivial.

Regan
Feb 06 2006
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Walter,

My primary work is web-related software.  For example, I might write 
software that is loaded into Apache as a shared library.  My library 
might be threaded, and handle multiple requests at once.  This is just 
an example.

If my library segfaults, or gets an access violation, or whatever... 
Apache dies.  Say goodbye to my program, and possibly my job if it 
results in a lot of downtime.  Boy, that's a dangerous thing, those 
"useful access violations"...

Luckily, I haven't had that many run-ins with this problem.  Still, if 
it were to happen, I would most certainly want an exception thrown - I 
had thought - which could then be caught, and handled gracefully (read: 
show the user a 500 Internal Server Error message, not die and give them 
nothing.)  After all, a null pointer doesn't necessarily mean the server 
blew up.  Maybe it could even send me an email to set me straight.

However, I do believe you have significantly more experience than I do 
as it comes to compilers and programming.  What should I do, excepting 
"never dereference null pointers" (which I already mean to do, I want a 
backup plan.)

I do realize that Apache could be changed to more gracefully handle 
this; for example, Firefox detects access violations caused by plugins 
such as Flash and Java, and gives you an error message suggesting you 
restart as soon as possible.  However, this is out of scope; I cannot 
change Apache.

I also realize that if a pointer is actually invalid (which is one thing 
forced initialization is there to avoid) this won't save me, but alas 
you cannot have it all.

Thanks,
-[Unknown]



 "Derek Parnell" <derek psych.ward> wrote in message 
 news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg 40tude.net...

 So with the current D, one does get null pointer dereference checking; its
 just that it looks like an access violation instead. So maybe we can 
 plead,
 cajole, whatever to make Walter give us a more meaningful message when an
 access violation is the result of a NULL pointer (file name and line 
 number
 would be a bloody big help too).


 
 Compile with -g, and run it under the debugger. When the access violation 
 happens, the debugger gives you the location of the fault, as well as a call 
 stack trace.
 
 It works even better than just a null check, it checks for any pointer value 
 that falls outside of address space allocated to the process.
Feb 06 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:ds9e1j$1dpu$1 digitaldaemon.com...

 However, I do believe you have significantly more experience than I do as 
 it comes to compilers and programming.  What should I do, excepting "never 
 dereference null pointers" (which I already mean to do, I want a backup 
 plan.)


Under Linux, you can set up a signal handler to intercept the seg faults, 
and use it to shut down your plug in gracefully.
Feb 07 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Walter,

I am aware of that ability, but the missing link for me is that I don't 
know how to unwind the stack from the signal handler.

In other words, consider a case where I am eight function calls deep 
into the program, and a problem occurs.  I want to send a 500 error 
message to the client.  To do this, I need to get back to the main 
function, so I can return to Apache and Apache can be happy.  I don't 
know how to do this other than by an exception.

I suppose... I could throw an exception in the signal handler.  This 
thought does not seem like one that might be completely assured to work, 
however.  Would it?

Thanks again,
-[Unknown]



 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
 news:ds9e1j$1dpu$1 digitaldaemon.com...

 However, I do believe you have significantly more experience than I do as 
 it comes to compilers and programming.  What should I do, excepting "never 
 dereference null pointers" (which I already mean to do, I want a backup 
 plan.)


 
 Under Linux, you can set up a signal handler to intercept the seg faults, 
 and use it to shut down your plug in gracefully.
Feb 07 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Unknown W. Brackets wrote:

 Walter,
 
 I am aware of that ability, but the missing link for me is that I don't 
 know how to unwind the stack from the signal handler.
 
 In other words, consider a case where I am eight function calls deep 
 into the program, and a problem occurs.  I want to send a 500 error 
 message to the client.  To do this, I need to get back to the main 
 function, so I can return to Apache and Apache can be happy.  I don't 
 know how to do this other than by an exception.
 
 I suppose... I could throw an exception in the signal handler.  This 
 thought does not seem like one that might be completely assured to work, 
 however.  Would it?


I don't think this is legal.  Signal handlers have fairly tight 
restrictions on what's allowed.  The pragmatic approach might simply be 
to use a proxy program that in turn calls the main program.  If that 
program aborts or fails to return the correct data then the proxy 
program can report a "500" error to the client and restart the target 
app if appropriate.  Since the code in such proxy apps is exceedingly 
simple, the chance of it crashing is pretty much nil.  I consider this 
almost a required technique for 100% uptime services.


Sean
Feb 07 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:dsadrj$2ac0$1 digitaldaemon.com...

 I am aware of that ability, but the missing link for me is that I don't 
 know how to unwind the stack from the signal handler.

 In other words, consider a case where I am eight function calls deep into 
 the program, and a problem occurs.  I want to send a 500 error message to 
 the client.  To do this, I need to get back to the main function, so I can 
 return to Apache and Apache can be happy.  I don't know how to do this 
 other than by an exception.

 I suppose... I could throw an exception in the signal handler.  This 
 thought does not seem like one that might be completely assured to work, 
 however.  Would it?


I am less familiar with how signals work on Linux than I ought to be. It 
should work - as long as the signal is on the same thread.
Feb 07 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Unknown W. Brackets wrote:

 
 If my library segfaults, or gets an access violation, or whatever... 
 Apache dies.  Say goodbye to my program, and possibly my job if it 
 results in a lot of downtime.  Boy, that's a dangerous thing, those 
 "useful access violations"...
 
 Luckily, I haven't had that many run-ins with this problem.  Still, if 
 it were to happen, I would most certainly want an exception thrown - I 
 had thought - which could then be caught, and handled gracefully (read: 
 show the user a 500 Internal Server Error message, not die and give them 
 nothing.)  After all, a null pointer doesn't necessarily mean the server 
 blew up.  Maybe it could even send me an email to set me straight.
 


But in D, the Access Violations are Exceptions, and you can catch them. 
This post had made me think otherwise, when I first read it, but today I 
checked it.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Feb 09 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:


 But in D, the Access Violations are Exceptions, and you can catch them. 


On Windows, that is...

--anders
Feb 09 2006
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
(on which you'd generally not run a webserver.)

-[Unknown]



 Bruno Medeiros wrote:
 

 But in D, the Access Violations are Exceptions, and you can catch them. 


 
 On Windows, that is...
 
 --anders
Feb 13 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Derek Parnell wrote:

 
 So with the current D, one does get null pointer dereference checking; its
 just that it looks like an access violation instead. So maybe we can plead,
 cajole, whatever to make Walter give us a more meaningful message when an
 access violation is the result of a NULL pointer (file name and line number
 would be a bloody big help too).
 


If this should be made, and I too agree it should, it should work in the 
form of throwing an exception, as was also was noted.

Implementing this (throwing an exception) should be simple enough, just 
modify some code in the access violation handler.
But showing the line number on a violation I'm not sure it's that easy. 
The exception handler would have to have some very complicated 
debugger-like code, no? These are all suppositions as I'm not very 
knowledgeable in this, so explain to me, if I'm wrong.

I wonder how that other fellow (shinichiro) implemented the stack trace. 
Does it show only the called functions, or line nunmbers too, ŕ la Java?

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Feb 08 2006
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Bruno Medeiros wrote:

 Derek Parnell wrote:
 

 So with the current D, one does get null pointer dereference checking; 
 its
 just that it looks like an access violation instead. So maybe we can 
 plead,
 cajole, whatever to make Walter give us a more meaningful message when an
 access violation is the result of a NULL pointer (file name and line 
 number
 would be a bloody big help too).


 If this should be made, and I too agree it should, it should work in the 
 form of throwing an exception, as was also was noted.
 
 Implementing this (throwing an exception) should be simple enough, just 
 modify some code in the access violation handler.
 But showing the line number on a violation I'm not sure it's that easy. 
 The exception handler would have to have some very complicated 
 debugger-like code, no? These are all suppositions as I'm not very 
 knowledgeable in this, so explain to me, if I'm wrong.
 
 I wonder how that other fellow (shinichiro) implemented the stack trace. 
 Does it show only the called functions, or line nunmbers too, ŕ la Java?
 


Has anyone bothered to look at the code in deh.c in phobos?  It's all 
right there.  Bruno is correct - the Access Violation is a D exception 
that was translated from a Windows SEH.  In order for the Windows SEH to 
know about D source code lines we'd have to modify it, and I don't see 
that happening any time soon.

There is a solution that I can see:

Assumptions:
* We have the memory address in D code at which the access violation 
occurred.
* We know which executable the access violation occurred in. (look it up 
by the memory address ranges for all DLLs/EXEs loaded by the application)
* We can read the CV debugging information from the executable directly. 
(DDL can certainly provide support here - does it support reading CV 
information?)  (Would this read be from within memory or from the 
executable file itself?  I'm not sure if CV information is copied into 
memory...)

Following that, it is a simple matter of looking up the code address 
(possibly after some translation) and retrieving the filename and line 
number.  Then, the Exception class should be modified to account for 
this extra information (if it does not already), or perhaps simply 
encode it within the Exception's message string.

However, this is largely dependent on implementation details.  We know 
that Digital Mars makes use of CodeView (CV) debugging information and 
this is also a Windows-specific modification.  Similar work can be done 
for Linux.

Of course this is all a hefty price tag for such a useful feature.  Is 
it worth it?

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O 
M--  V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e 
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne
Feb 08 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"James Dunne" <james.jdunne gmail.com> wrote in message 
news:dsd2bk$1nlm$1 digitaldaemon.com...

 Of course this is all a hefty price tag for such a useful feature.  Is it 
 worth it?


Or, like I suggested before, insert an implicit

assert(objReference !is null)

Before dereferencing any object references.  The compiler already does 
something like this for array bounds checking.  And like array bounds 
checking, this could be turned on or off.
Feb 08 2006
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Jarrett Billingsley wrote:

 "James Dunne" <james.jdunne gmail.com> wrote in message 
 news:dsd2bk$1nlm$1 digitaldaemon.com...
 

Of course this is all a hefty price tag for such a useful feature.  Is it 
worth it?


 
 
 Or, like I suggested before, insert an implicit
 
 assert(objReference !is null)
 
 Before dereferencing any object references.  The compiler already does 
 something like this for array bounds checking.  And like array bounds 
 checking, this could be turned on or off. 


Why not just use the Phobos hack ?


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Feb 08 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Tom S" <h3r3tic remove.mat.uni.torun.pl> wrote in message 
news:dsdo9a$293t$1 digitaldaemon.com...

 Why not just use the Phobos hack ?


You're right.  I forgot that it checks for all kinds of access violations.

What a wonderful hack :)
Feb 08 2006
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Bruno Medeiros wrote:

 I wonder how that other fellow (shinichiro) implemented the stack trace. 
 Does it show only the called functions, or line nunmbers too, ŕ la Java?


It displays both, e.g.

Unhandled win32 exception!
backtrace:
  00402055 _Dmain (+9) console_main.d:19
  0040235f main (+77)
  00412b35 mainCRTStartup (+a9)
  7c816d4f ???

And it acually is a stack trace for a simple program which uses null 
pointers...



-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O 
!M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Feb 08 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dscnvs$1eb4$1 digitaldaemon.com...

 I wonder how that other fellow (shinichiro) implemented the stack trace.


I took a brief look at it. What he did was intercept the exception generated 
by the operating system, then used the Microsoft debug interface to read the 
debug data in the executable to associate a file/line number with it.

It is the same thing that a debugger does, and so it relies on the 
executable being compiled with -g (full debug info).

To implement this requires a pretty advanced technical knowledge of how 
Windows SEH works, and shinichiro deserves a lot of respect for figuring 
this out, since it's mostly undocumented.

The code is highly Windows dependent, and none of it is useful under Linux. 
But the equivalent could presumably be done on Linux given someone who knows 
how debuggers work under Linux.
Feb 08 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Bruno Medeiros wrote:

 Derek Parnell wrote:

 So with the current D, one does get null pointer dereference checking;
 its
 just that it looks like an access violation instead. So maybe we can
 plead,
 cajole, whatever to make Walter give us a more meaningful message 




when an

 access violation is the result of a NULL pointer (file name and line
 number
 would be a bloody big help too).


 If this should be made, and I too agree it should, it should work in the
 form of throwing an exception, as was also was noted.


This is in error. Under Unknown W. Brackets assumption I thought that 
access violations didn't throw Exceptions but they do. Someone should 
have corrected us.

Walter Bright wrote:

 "Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
 news:dscnvs$1eb4$1 digitaldaemon.com...

 I wonder how that other fellow (shinichiro) implemented the stack trace.


 
 I took a brief look at it. What he did was intercept the exception generated 
 by the operating system, then used the Microsoft debug interface to read the 
 debug data in the executable to associate a file/line number with it.
 
 It is the same thing that a debugger does, and so it relies on the 
 executable being compiled with -g (full debug info).
 
 To implement this requires a pretty advanced technical knowledge of how 
 Windows SEH works, and shinichiro deserves a lot of respect for figuring 
 this out, since it's mostly undocumented.
 
 The code is highly Windows dependent, and none of it is useful under Linux. 
 But the equivalent could presumably be done on Linux given someone who knows 
 how debuggers work under Linux. 
 
 


Based on this new perspective, I now agree that a stack trace is not a 
prioritary feature. It would require non-trivial code, and different 
implementations for each platform, and it's quite some work.

But still, we could have line numbers for explicitly thrown exceptions, 
as that is quite easy to implement. Since throw is a static construct, 
it is known at compile the line and file were it occurs (similarly to 
assert), and so it could add such info to the thrown Exception.


 To implement this requires a pretty advanced technical knowledge of how
 Windows SEH works, and shinichiro deserves a lot of respect for figuring
 this out, since it's mostly undocumented.


Still, you, as a compiler writer, already know how it(SEH) works, right?

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Feb 09 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:


  > If this should be made, and I too agree it should, it should work in the
  > form of throwing an exception, as was also was noted.
 
 This is in error. Under Unknown W. Brackets assumption I thought that 
 access violations didn't throw Exceptions but they do. Someone should 
 have corrected us.


They only throw exceptions with DMD/Win, and in fact it seems
that you *lose* some valuable information because of that... ?
(which might have been rectified somewhat by the new patch, but)

Some info on how it looks on other platforms can be found in:
http://www.digitalmars.com/d/archives/digitalmars/D/14342.html
In fact, it also looks similar on Windows when using GDC/MinGW:

Program received signal SIGSEGV, Segmentation fault.
0x00401290 in _Dmain () at null.d:4
4         o.toString();
(gdb) bt


     main_func=0x401280 <_Dmain>) at 
../../../libphobos/internal/dgccmain2.d:81

     at ../../../libphobos/internal/cmain.d:5
(gdb)

This was when running "null.exe" with gdb.exe, on Windows XP.

Walter has said that the signals "should" (i.e. eventually)
be converted into D exceptions on the other platforms too,
but I'm not all that sure if that's such a great idea... ?

If there's such an exception, it should at least have all info.

--anders
Feb 09 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Anders F Björklund wrote:

 Bruno Medeiros wrote:
 

  > If this should be made, and I too agree it should, it should work 
 in the
  > form of throwing an exception, as was also was noted.

 This is in error. Under Unknown W. Brackets assumption I thought that 
 access violations didn't throw Exceptions but they do. Someone should 
 have corrected us.


 
 They only throw exceptions with DMD/Win, and in fact it seems
 that you *lose* some valuable information because of that... ?
 (which might have been rectified somewhat by the new patch, but)
 


Yikes. Didn't know about that one, that clears up things.


 Some info on how it looks on other platforms can be found in:
 http://www.digitalmars.com/d/archives/digitalmars/D/14342.html
 In fact, it also looks similar on Windows when using GDC/MinGW:
 


Thanks for the info on that thread.


 Walter has said that the signals "should" (i.e. eventually)
 be converted into D exceptions on the other platforms too,
 but I'm not all that sure if that's such a great idea... ?
 


Why not? Afraid that one won't get all the information when debugging 
with gdb as one gets now?


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Feb 09 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:


 Walter has said that the signals "should" (i.e. eventually)
 be converted into D exceptions on the other platforms too,
 but I'm not all that sure if that's such a great idea... ?


 Why not? Afraid that one won't get all the information when debugging 
 with gdb as one gets now?


Yes. (Just get a generic runtime error, with some basic message)

I'm not chronically against the idea, if it works OK as in Java ?
Just that if it can't be all the way, might as well be as in C...

--anders

PS.
This is somewhat similar to how string literals are writable in
DMD/Win, but how they cause access violations in other setups...

"Implementation Defined"
Feb 09 2006
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Anders F Björklund wrote:

 Bruno Medeiros wrote:
 

 Walter has said that the signals "should" (i.e. eventually)
 be converted into D exceptions on the other platforms too,
 but I'm not all that sure if that's such a great idea... ?


 Why not? Afraid that one won't get all the information when debugging 
 with gdb as one gets now?


 
 Yes. (Just get a generic runtime error, with some basic message)
 
 I'm not chronically against the idea, if it works OK as in Java ?
 Just that if it can't be all the way, might as well be as in C...
 
 --anders
 
 PS.
 This is somewhat similar to how string literals are writable in
 DMD/Win, but how they cause access violations in other setups...
 
 "Implementation Defined"


Yes, loosing such functionality wouldn't be nice. However, there should 
some workaround/fix. For example, one can put a breakpoint in the D 
runtime code that would handle the access violations (where the 
exception is created and thrown), so that all the debug info would still 
be available? And could gdb be hacked/fixed/wraped so that this 
breakpoint setting is done automatically?


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Feb 11 2006
prev sibling parent nick <nick.atamas gmail.com> writes:
Jarrett Billingsley wrote:

 Interesting how he comments time and time again how much he'd like null 
 pointer dereferencing to be checked.. funny, last time I brought that up, 
 Walter shot it down, since after all, access violations are more than 
 enough!  Right guys?  Right? 
 


Cyclone is a language (based on C) that introduced array bounds checks 
and fat pointers:
http://www.research.att.com/projects/cyclone/online-manual/main-screen002.html#toc3

When I took a OSs course with Michael Hicks' (one of the people behind 
Cyclone) he urged students to use Cyclone in order to make their life 
easier. Somehow it never caught on. I had no problems finishing any of 
the projects in plain C, but I always wondered if Cyclone would have 
made things easier.

The bug that caused me the most grief was not a pointer issue. I was 
calling a WriteBlock() function to READ a page from the drive(that 
didn't work, DUH). The bug was caused by a copy pasting error. The 
experience has taught me that NULL pointers are quite manageable.

Also, I don't know that Sweeny's desire for dereference checking is 
justified. I would like to see some hard numbers to be convinced. 
Finally, I believe this is best left to tools like LINT.
Feb 05 2006
prev sibling parent Lucas Goss <lgoss007 gmail.com> writes:
This discussion came up in gamedev.net too. D was mentioned but sort of 
blown off. Here's a few of the comments ...

"D isn't much different from C++ therefore suffer the same 
problems/issues, there fundamentally imperative languages"

"Also, the "key" feature here, IMO, is STM. It really is the first 
concurrency abstraction to come around (ever) which is really useful. 
And it only came around in Nov 2004 (and AFIK it's only available in 
Haskell at the moment).

"I don't think it can be solved with a design pattern in an existing 
language."

And yes there are concurrent OO design patterns but that means very 
little here, it doesn't help/change the fact that most numerical 
computations are purely functional and in some places you may need to do 
state-full computation locally. It' s not going to change the fact that 
the way we keep going with inappropriate tools there will be to much 
shared mutable state flying around for reliable, maintainable, correct & 
clean concurrent code written by a medium to large team of developers 
who want to be productive."

http://www.gamedev.net/community/forums/topic.asp?topic_id=373751
(page 2, towards the bottom)
Feb 10 2006