On 28/04/10 21: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

Why put that constraint on yourself? Debugging takes a fraction of the time with a good debugger eg. gdb at your hands.

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

>
> Andrei

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.

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.

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.

Andrei

On 28/04/10 21:23, Walter Bright wrote:
> 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.

This is something we're making huge leaps and bounds with in the last week, at least with respect to D. The D patches for gdb have been approved and are awaiting a commit, so they will be in the next release of gdb (there is also the possibility that the main author of the patches will get commit access, which would be great for D :)). This combined with my recent patches that make debugging with dmd bearable rather than hitting errors with most applications (read anything that uses std.stdio), will make the debugging situation with D a lot better!

Of course there's still a long way to go, but it's a great first step :)

On Apr 28, 2010, at 3:53 PM, Walter Bright <walter at digitalmars.com> wrote:

> ----------------------------
> int x;
> void main() { }
> unittest {
>   assert(x == 3, "x should be 3");
>   assert(x == 4);
>   assert(x == 5);
> }
> --------------------------------
> Running it:
>
> test3.d(10): x should be 3
> test3(11): unittest failure
> test3(12): unittest failure

Ick. A single assert failure in a unit test should stop that test (and run test teardown...). Continuing past an assert failure is useless.

PS: Your file names are inconsistent in the sample output

Robert Clipsham wrote:
>
> This is something we're making huge leaps and bounds with in the last week, at least with respect to D. The D patches for gdb have been approved and are awaiting a commit, so they will be in the next release of gdb (there is also the possibility that the main author of the patches will get commit access, which would be great for D :)). This combined with my recent patches that make debugging with dmd bearable rather than hitting errors with most applications (read anything that uses std.stdio), will make the debugging situation with D a lot better!
>
> Of course there's still a long way to go, but it's a great first step :)
>

Yes, and you've been a great help in pushing these things along!

On 28/04/10 21:36, Walter Bright wrote:
> Yes, and you've been a great help in pushing these things along!

Just doing my bit :) Since I started playing with D2 I've been using dmd, and the state of debugging wasn't any way near what I was used to... So I fixed it. I figured I may as well push for a couple of other debugging things to get sorted while my head was in debugging mode :) Of course having played with dmd I now find myself wanting to fix more issues ;)

On 04/28/2010 03:33 PM, Jason House wrote:
> On Apr 28, 2010, at 3:53 PM, Walter Bright <walter at digitalmars.com> wrote:
>
>> ----------------------------
>> int x;
>> void main() { }
>> unittest {
>> assert(x == 3, "x should be 3");
>> assert(x == 4);
>> assert(x == 5);
>> }
>> --------------------------------
>> Running it:
>>
>> test3.d(10): x should be 3
>> test3(11): unittest failure
>> test3(12): unittest failure
>
> Ick. A single assert failure in a unit test should stop that test (and run test teardown...). Continuing past an assert failure is useless.

That's a bug. An assertion failure stops the current unittest and proceeds to the next one. Walter, I meant to mention this to you when you first described how you plan to change unittests, but I forgot.

Andrei

On 04/28/2010 03:35 PM, Walter Bright wrote:
>
>
> Andrei Alexandrescu wrote:
>> On 04/28/2010 03:23 PM, Walter Bright wrote:
>>
>> 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.
>>
>
> The tester does print out failing unit tests as they happen, it does not save up the strings until the end.

Makes sense but it's not a reply to my point.

> When you run a program under a debugger, it gives you the file/line of a seg fault. Pretty much everything else a debugger does is fluff.

Many would disagree but that's besides the point.

All I'm saying is: instead of discussing the mechanics of why things can't be made to work as they should and also discussing ways to make things work with extra effort, let's focus on one thing and one thing only: getting things to work the way they should work. And the way things should work is clear: upon failure the unittest tells the point of failure.


Andrei