View mode: basic / threaded / horizontal-split · Log in · Help
November 17, 2009
Re: Making alloca more safe
Max Samukha wrote:
> On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright
> <newshound1@digitalmars.com> wrote:
> 
>> If you've got a system that relies on the software continuing to 
>> function after an unexpected null seg fault, you have a VERY BADLY 
>> DESIGNED and COMPLETELY UNSAFE system. I really cannot emphasize this 
>> enough.
> 
> I have an example of such a software:
> http://www.steinberg.net/en/products/audiopostproduction_product/nuendo4.html
> 
> It loads third-party plugins into the host process's address space, an
> consequently it may fail at any moment. The software's design is not
> the best ever but it gives the user last chance to save his work in
> case of fatal error. This feature has saved my back a couple of times.

I suppose nobody much cares if it writes out a corrupted audio file. 
People care very much if their airplane suddenly dives into the ground.

Be that as it may, it is certainly possible to catch seg faults in an 
exception handler and write files out. That would be an unacceptable 
behavior, though, in a system that needs to be safe.

> 
>> P.S. I worked for Boeing for years on flight critical systems. Normally 
>> I eschew credentialism, but I feel very strongly about this issue and 
>> wish to point out that my knowledge on this is based on decades of real 
>> world experience by aviation companies who take this issue extremely 
>> seriously.
> 
> Then, instead of sticking with Windows and the likes, you may want to
> think about porting dmd to a more serious environment specifically
> designed for developing such systems. What about a real-time
> microkernel OS like this one:
> http://www.qnx.com/products/neutrino_rtos/ ?

dmd targets Windows because that's where probably half the programmers 
are. I'd certainly like to do embedded systems, too, but realistically 
that's going to be the purview of gdc or ldc.
November 17, 2009
Re: Making alloca more safe
On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
<newshound1@digitalmars.com> wrote:
> Max Samukha wrote:
>>
>> On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>
>>> If you've got a system that relies on the software continuing to function
>>> after an unexpected null seg fault, you have a VERY BADLY DESIGNED and
>>> COMPLETELY UNSAFE system. I really cannot emphasize this enough.
>>
>> I have an example of such a software:
>>
>> http://www.steinberg.net/en/products/audiopostproduction_product/nuendo4.html
>>
>> It loads third-party plugins into the host process's address space, an
>> consequently it may fail at any moment. The software's design is not
>> the best ever but it gives the user last chance to save his work in
>> case of fatal error. This feature has saved my back a couple of times.
>
> I suppose nobody much cares if it writes out a corrupted audio file. People
> care very much if their airplane suddenly dives into the ground.
>
> Be that as it may, it is certainly possible to catch seg faults in an
> exception handler and write files out. That would be an unacceptable
> behavior, though, in a system that needs to be safe.
>

You spent quite a bit of effort explaining that segfaults never cause
memory corruption, so it seems fairly reasonable to assume that some
parts of the application state could still be valid and useful not to
throw away.

>>
>>> P.S. I worked for Boeing for years on flight critical systems. Normally I
>>> eschew credentialism, but I feel very strongly about this issue and wish to
>>> point out that my knowledge on this is based on decades of real world
>>> experience by aviation companies who take this issue extremely seriously.
>>
>> Then, instead of sticking with Windows and the likes, you may want to
>> think about porting dmd to a more serious environment specifically
>> designed for developing such systems. What about a real-time
>> microkernel OS like this one:
>> http://www.qnx.com/products/neutrino_rtos/ ?
>
> dmd targets Windows because that's where probably half the programmers are.
> I'd certainly like to do embedded systems, too, but realistically that's
> going to be the purview of gdc or ldc.
>

I'm not sure if LDC will ever support D2 (at least wont be by my hand)
November 17, 2009
Re: Making alloca more safe
== Quote from Tomas Lindquist Olsen (tomas.l.olsen@gmail.com)'s article
> I'm not sure if LDC will ever support D2 (at least wont be by my hand)

What is it about D2 that makes this unlikely?  I thought after LDC D1 support was
stable and the D2 spec and front end were stable, the natural progression of
things would be for LDC to support D2.
November 17, 2009
Re: Making alloca more safe
On Tue, Nov 17, 2009 at 4:45 PM, dsimcha <dsimcha@yahoo.com> wrote:
> == Quote from Tomas Lindquist Olsen (tomas.l.olsen@gmail.com)'s article
>> I'm not sure if LDC will ever support D2 (at least wont be by my hand)
>
> What is it about D2 that makes this unlikely?  I thought after LDC D1 support was
> stable and the D2 spec and front end were stable, the natural progression of
> things would be for LDC to support D2.
>

LDC requires a lot of changes to the frontend.

* DMD is not written as a cross compiler
* The runtime interfaces are hardcoded into the frontend semantics
* The ast rewrites dmd does are destructive and buggy
* The dmd codegen is all over the frontend code, it wasn't meant to be
used with another backend

But most of all: someone has to do it.

Keeping the two in sync is a major PITA, the original merge of our
frontend changes, to the D2 frontend was done in a error prone way,
which introduced a lot of bugs, codegen that worked in D1 still
compiles, and generates code that compiles, but the code doesn't run.
This requires time consuming debugging/reviewing and of course fixing.

So most of all, like most of things D, it's about a lack of manpower.
I personally no longer have the time to maintain LDC besides critical
bugfixes now and then, and other devs are in similar situations.

Another factor may be more ideological (or something), not everyone is
happy about how D evolved, and who want to implement something they
don't really care about ?

-Tomas
November 17, 2009
Re: Making alloca more safe
Tomas Lindquist Olsen Wrote:

> On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
> <newshound1@digitalmars.com> wrote:
> >
> > I suppose nobody much cares if it writes out a corrupted audio file. People
> > care very much if their airplane suddenly dives into the ground.
> >
> > Be that as it may, it is certainly possible to catch seg faults in an
> > exception handler and write files out. That would be an unacceptable
> > behavior, though, in a system that needs to be safe.
> >
> 
> You spent quite a bit of effort explaining that segfaults never cause
> memory corruption, so it seems fairly reasonable to assume that some
> parts of the application state could still be valid and useful not to
> throw away.

At the moment the segfault occurs, sure.  But if the process eats the segfault and continues, what happens?  If an app is programmed in such a way that segfaults are a part of normal processing (I worked on a DB that performed dynamic loading this way) that's one thing.  But other apps are almost definitely going to try and write data near 0x00 after such an occurrence.
November 17, 2009
Re: Making alloca more safe
Sean Kelly wrote:
> Tomas Lindquist Olsen Wrote:
> 
>> On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>> I suppose nobody much cares if it writes out a corrupted audio file. People
>>> care very much if their airplane suddenly dives into the ground.
>>>
>>> Be that as it may, it is certainly possible to catch seg faults in an
>>> exception handler and write files out. That would be an unacceptable
>>> behavior, though, in a system that needs to be safe.
>>>
>> You spent quite a bit of effort explaining that segfaults never cause
>> memory corruption, so it seems fairly reasonable to assume that some
>> parts of the application state could still be valid and useful not to
>> throw away.
> 
> At the moment the segfault occurs, sure.  But if the process eats the segfault and continues, what happens?  If an app is programmed in such a way that segfaults are a part of normal processing (I worked on a DB that performed dynamic loading this way) that's one thing.  But other apps are almost definitely going to try and write data near 0x00 after such an occurrence.

I think throwing an Error object instead of failing immediately would be 
occasionally useful. (Same goes about other trapped errors such as 
integral division by zero.) There are applications out there that want 
to partially recover from a null pointer error. I wrote a few, so it's 
difficult to convince me they don't exist.

Andrei
November 17, 2009
D2 front-end for LLVM (Was: Re: Making alloca more safe)
Tomas Lindquist Olsen:

> LDC requires a lot of changes to the frontend.
> 
> * DMD is not written as a cross compiler
> * The runtime interfaces are hardcoded into the frontend semantics
> * The ast rewrites dmd does are destructive and buggy
> * The dmd codegen is all over the frontend code, it wasn't meant to be
> used with another backend

LLVM is one of the best thing happened to D1, so maybe Walter can improve the situation, to allow a simpler/better attach of the D2 front-end to LLVM. If you keep your muzzle shut things will never improve. Maybe someone can write a list of all the points where D2 causes such port problems, so Walter may improve/fix them some.

This is quite important, more than most syntax details discussed in the last weeks.

Bye,
bearophile
November 17, 2009
Re: D2 front-end for LLVM (Was: Re: Making alloca more safe)
On Tue, Nov 17, 2009 at 5:58 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Tomas Lindquist Olsen:
>
>> LDC requires a lot of changes to the frontend.
>>
>> * DMD is not written as a cross compiler
>> * The runtime interfaces are hardcoded into the frontend semantics
>> * The ast rewrites dmd does are destructive and buggy
>> * The dmd codegen is all over the frontend code, it wasn't meant to be
>> used with another backend
>
> LLVM is one of the best thing happened to D1, so maybe Walter can improve the situation, to allow a simpler/better attach of the D2 front-end to LLVM. If you keep your muzzle shut things will never improve. Maybe someone can write a list of all the points where D2 causes such port problems, so Walter may improve/fix them some.
>

Walter seems to be fairly rigid to work with. While the latest
improvements, like DMD in a SVN repo, is a great step, I just don't
have as much time for LDC as I used to, so the little difference it
makes doesn't really help me that much.

I agree it would be good with more developer documentation. But LDC is
really not implemented very cleanly and writing such would be a huge
amount of work. When I started on LDC I had no idea how DMD worked,
and I made a lot of mistakes along the way.

Now, since then, a lot of people have joined, and helped out. But it
still suffers from some of the issues introduced very early.

Another point is motivation. Personally, I've achieved what I
originally planned for LDC, and quite a lot more. New projects await
out there.

Don't get me wrong. I *use* D (1.0 + Tango). And I need a x86-64
compatible D compiler, so I'm not abandoning LDC. But other people
will have to step in for D2 support. Unless of course I somehow
magically convert to liking D2. But I doubt that's going to happen.

-Tomas

P.S. LDC is an open source project, and while I started it, many other
people now have write access to the repository. I'm not holding anyone
back from making the changes needed for D2 support. And in case
someone out there wants it, I'll be happy to give you access as well
(after seeing a first patch).
November 17, 2009
Re: Making alloca more safe
Tomas Lindquist Olsen wrote:
> You spent quite a bit of effort explaining that segfaults never cause
> memory corruption, so it seems fairly reasonable to assume that some
> parts of the application state could still be valid and useful not to
> throw away.

When a seg fault occurs, it is because your program is in a state that 
you, the programmer, never anticipated. Therefore, you cannot know what 
state your data is in. Therefore, your data is unreliable. While it may 
not be in a bad state from memory corruption, it could very well be in a 
bad state from your program's logic being wrong.

Do you want to bet your life on assuming your program and its data is 
still valid?
November 17, 2009
Re: Making alloca more safe
Tomas Lindquist Olsen wrote:
> LDC requires a lot of changes to the frontend.

If you send me the changes, I can incorporate at least some of them, 
making subsequent versions easier to port to LDC.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home