On Apr 28, 2010, at 1:25 PM, Andrei Alexandrescu wrote:

> On 04/28/2010 03:23 PM, Walter Bright wrote:
>> 
>> 
>> Robert Clipsham wrote:
>>> On 28/04/10 21:06, Andrei Alexandrescu wrote:
>>> 
>>>> should find a solution within the confines of the compiler.
>>> 
>>> Catching segfaults on linux is possible, it's hard to do and rather hacky though, this doesn't seem like something that should be included in the unittesting functionality. I guess a seperate process could be spawned for unit testing, and if a segfault occurs a message saying so could be given, but anything more seems excessive, and is the job of a debugger. Doesn't seem right to integrate a full debugger into every app compiled with unit tests.
>>> 
>> 
>> I agree, although I sympathize with not liking gdb, the solution is not to build a debugger into the compiler, it's build a better debugger.
> 
> All I want is the compiler to utter the last started unittest if it segfaults during unittesting. Although I do agree that may be difficult to implement, I don't think it's a tall or unusual order.

It's not hard to write a segfault handler that does this, but it involves doing technically illegal stuff in a signal handler (either IO or throwing an exception) so I don't want to make it a built-in feature.

On Apr 28, 2010, at 1:24 PM, Bernard Helyer wrote:

> On 29/04/10 08:06, Andrei Alexandrescu wrote:
>> On 04/28/2010 02:53 PM, Walter Bright wrote:
>>>> I'm not sure to what extent segfaulting is detectable, but we definitely must find good ways to address that too.
>>>> 
>>> 
>>> Debuggers are the standard tool for that.
>> 
>> I hear you but don't have one, and I swore to never use gdb. Ideally we should find a solution within the confines of the compiler.
>> 
>> Andrei
>> __________
> 
> But surely once a process has been sent SIGSEGV, we can't really recover from a generic handler? The process at that point is in an unknown state. The correct behaviour on SIGSEGV is to die.

It depends on the source of the SIGSEGV.  I've worked on apps where clean recovery from a segfault was an integral part of the design.

----- Original Message ----
> From: Sean Kelly <sean at invisibleduck.org>
> 
> On Apr 28, 2010, at 1:25 PM, Andrei Alexandrescu wrote:
> It's not hard to write a segfault handler that
> does this, but it involves doing technically illegal stuff in a signal handler
> (either IO or throwing an exception) so I don't want to make it a built-in
> feature.

syscalls are always legal because syscalls exit when signals occur (technically, they aren't even calls, they are software interrupts).  In other words, printf is illegal, write is not.

-Steve

On Apr 30, 2010, at 1:40 PM, Steve Schveighoffer wrote:
> 
> ----- Original Message ----
>> From: Sean Kelly <sean at invisibleduck.org>
>> 
>> On Apr 28, 2010, at 1:25 PM, Andrei Alexandrescu wrote:
>> It's not hard to write a segfault handler that
>> does this, but it involves doing technically illegal stuff in a signal handler
>> (either IO or throwing an exception) so I don't want to make it a built-in
>> feature.
> 
> syscalls are always legal because syscalls exit when signals occur (technically, they aren't even calls, they are software interrupts).  In other words, printf is illegal, write is not.

I think it's a bit more restrictive than that, but you're right.  If it helps, the list of signal-safe functions I use for reference is here:

http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html

Since we've been looking into this now and we have a solution in our collective mental caches, is there please a chance to effect this change for this beta? I'm telling you, it is an _important_ step forward in unittesting D programs.

Thanks!

Andrei

On 05/01/2010 01:19 AM, Sean Kelly wrote:
> On Apr 30, 2010, at 1:40 PM, Steve Schveighoffer wrote:
>>
>> ----- Original Message ----
>>> From: Sean Kelly<sean at invisibleduck.org>
>>>
>>> On Apr 28, 2010, at 1:25 PM, Andrei Alexandrescu wrote:
>>> It's not hard to write a segfault handler that
>>> does this, but it involves doing technically illegal stuff in a signal handler
>>> (either IO or throwing an exception) so I don't want to make it a built-in
>>> feature.
>>
>> syscalls are always legal because syscalls exit when signals occur (technically, they aren't even calls, they are software interrupts).  In other words, printf is illegal, write is not.
>
> I think it's a bit more restrictive than that, but you're right.  If it helps, the list of signal-safe functions I use for reference is here:
>
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Honestly, with proper support for debug info, this kind of change is pretty meaningless to me on the *nix side. For any program seg fault, either dump a core and examine, or rerun in a debugger.

Any environment or toolchain which doesn't allow that really shouldn't be used.

Sent from my iPhone

On May 1, 2010, at 8:55 AM, Andrei Alexandrescu <andrei at erdani.com> wrote:

> Since we've been looking into this now and we have a solution in our collective mental caches, is there please a chance to effect this change for this beta? I'm telling you, it is an _important_ step forward in unittesting D programs.
>
> Thanks!
>
> Andrei
>
> On 05/01/2010 01:19 AM, Sean Kelly wrote:
>> On Apr 30, 2010, at 1:40 PM, Steve Schveighoffer wrote:
>>>
>>> ----- Original Message ----
>>>> From: Sean Kelly<sean at invisibleduck.org>
>>>>
>>>> On Apr 28, 2010, at 1:25 PM, Andrei Alexandrescu wrote:
>>>> It's not hard to write a segfault handler that
>>>> does this, but it involves doing technically illegal stuff in a
>>>> signal handler
>>>> (either IO or throwing an exception) so I don't want to make it a
>>>> built-in
>>>> feature.
>>>
>>> syscalls are always legal because syscalls exit when signals occur (technically, they aren't even calls, they are software interrupts).  In other words, printf is illegal, write is not.
>>
>> I think it's a bit more restrictive than that, but you're right. If it helps, the list of signal-safe functions I use for reference is here:
>>
>> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Sure.

On May 1, 2010, at 5:55 AM, Andrei Alexandrescu wrote:

> Since we've been looking into this now and we have a solution in our collective mental caches, is there please a chance to effect this change for this beta? I'm telling you, it is an _important_ step forward in unittesting D programs.
> 
> Thanks!
> 
> Andrei
> 
> On 05/01/2010 01:19 AM, Sean Kelly wrote:
>> On Apr 30, 2010, at 1:40 PM, Steve Schveighoffer wrote:
>>> 
>>> ----- Original Message ----
>>>> From: Sean Kelly<sean at invisibleduck.org>
>>>> 
>>>> On Apr 28, 2010, at 1:25 PM, Andrei Alexandrescu wrote:
>>>> It's not hard to write a segfault handler that
>>>> does this, but it involves doing technically illegal stuff in a signal handler
>>>> (either IO or throwing an exception) so I don't want to make it a built-in
>>>> feature.
>>> 
>>> syscalls are always legal because syscalls exit when signals occur (technically, they aren't even calls, they are software interrupts).  In other words, printf is illegal, write is not.
>> 
>> I think it's a bit more restrictive than that, but you're right.  If it helps, the list of signal-safe functions I use for reference is here:
>> 
>> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Andrei Alexandrescu wrote:
> Since we've been looking into this now and we have a solution in our collective mental caches, is there please a chance to effect this change for this beta? I'm telling you, it is an _important_ step forward in unittesting D programs.
>

One thing I should mention is that dmd now calls a different function for unittest asserts than the asserts normally do, and it does not regard those calls as "terminating" calls. This means that the unittest behavior can now be controlled by adjusting the runtime library, without affecting the assert failure code.

On May 2, 2010, at 1:23 PM, Walter Bright wrote:
> 
> Andrei Alexandrescu wrote:
>> Since we've been looking into this now and we have a solution in our collective mental caches, is there please a chance to effect this change for this beta? I'm telling you, it is an _important_ step forward in unittesting D programs.
>> 
> 
> One thing I should mention is that dmd now calls a different function for unittest asserts than the asserts normally do, and it does not regard those calls as "terminating" calls. This means that the unittest behavior can now be controlled by adjusting the runtime library, without affecting the assert failure code.

I don't know if this is how you did it, but one option would be to have the unittest code set a custom assert handler, then reset it when done.  The problem with this has historically been that DMD didn't generate a valid callstack for returning normally from an assert failure (for runtime code efficiency, I believe).

Sean Kelly wrote:
>
> I don't know if this is how you did it, but one option would be to have the unittest code set a custom assert handler, then reset it when done.  The problem with this has historically been that DMD didn't generate a valid callstack for returning normally from an assert failure (for runtime code efficiency, I believe).
>
> 

The call stack is valid for the unittest calls. You're right that it is not for asserts.