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

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

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

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

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 something that's available now--there is a C# version available that works automatically (from what I understand, the C# compiler can be somehow extended in some ways?).


Sean

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

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

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

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

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