www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Unit tests and segfaults

reply Russel Winder <russel winder.org.uk> writes:
What is the right idiom for testing that a function call does segfault
when you want it to?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 06 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 06-12-2012 10:02, Russel Winder wrote:

 What is the right idiom for testing that a function call does segfault
 when you want it to?


There is basically no portable, clean way to do that. Why are you 
relying on segmentation faults? It's generally speaking a very bad idea 
because behavior depends entirely on the platform and architecture...

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Dec 06 2012
parent reply "Russel Winder" <russel winder.org.uk> writes:
On Thursday, 6 December 2012 at 10:31:43 UTC, Alex Rønne Petersen 
wrote:

 On 06-12-2012 10:02, Russel Winder wrote:

 What is the right idiom for testing that a function call does 
 segfault
 when you want it to?


 There is basically no portable, clean way to do that. Why are 
 you relying on segmentation faults? It's generally speaking a 
 very bad idea because behavior depends entirely on the platform 
 and architecture...


I am not relying on segfaults, that would just be silly ;-) The 
issue is that unit tests should test error as well as success. I 
want to know if I get a segfault when I have an infinite 
recursion in an algorithm (due to incorrect parameters slipping 
through data validation).

I am also trying to investigate tail recursion optimization and 
getting a segfault is a way of detecting that it isn't happening.

(Sorry for the delay in replying I lost the email in my client.)
Dec 11 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, December 11, 2012 17:16:58 Russel Winder wrote:

 I am not relying on segfaults, that would just be silly ;-) The
 issue is that unit tests should test error as well as success. I
 want to know if I get a segfault when I have an infinite
 recursion in an algorithm (due to incorrect parameters slipping
 through data validation).
 
 I am also trying to investigate tail recursion optimization and
 getting a segfault is a way of detecting that it isn't happening.


I'd argue that if you want an error condition that you test for, you should 
actually do something in your code that generates an error condition (e.g. 
throw an exception) and that it really makes no sense to test for segfaults. 
That's not really an error condition. That just means that your code is 
broken. And such cases aren't generally worth testing for IMHO.

You test that a function works correctly with various inputs, but if it's 
given something that it's not supposed to accept, and you're not going to 
throw or assert that it's acceptable input, then it doesn't really matter what 
happens. Either you're doing defensive programming and checking inputs (in 
which case, your unit tests will catch error cases that don't fail properly 
when the exception isn't thrown), or you're doing design by contract, in which 
case, it doesn't matter what happens when the caller passes invalid input, 
because they've violated the contract. The unit tests on the caller should 
then catch that as opposed to the unit tests on the function being called. 
Testing that the function doesn't do weird things when the contract is broken 
is a waste of time. If you want to avoid weird stuff happening when contracts 
are broken, then use defensive programming and protect the function against 
such bad input.

- Jonathan M Davis
Dec 11 2012
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2012-12-11 at 18:58 +0100, Jonathan M Davis wrote:
[=E2=80=A6]

 I'd argue that if you want an error condition that you test for, you shou=


ld=20

 actually do something in your code that generates an error condition (e.g=


.=20

 throw an exception) and that it really makes no sense to test for segfaul=


ts.=20

 That's not really an error condition. That just means that your code is=


=20

 broken. And such cases aren't generally worth testing for IMHO.


I appreciate where you are coming from with respect to general testing
strategy, and am basically in agreement with what you say.  However in
this specific case a segfault is just another exception.  In terms of
recursion the exception is "recursion stack limit reached" it just
happens to be spelt "segfault"

[=E2=80=A6]

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 11 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-12-11 20:21, Russel Winder wrote:


 I appreciate where you are coming from with respect to general testing
 strategy, and am basically in agreement with what you say.  However in
 this specific case a segfault is just another exception.  In terms of
 recursion the exception is "recursion stack limit reached" it just
 happens to be spelt "segfault"


If you actually want to rely on segfaults there are code out there that 
can catch a segfault and convert it in to an exception. Actully, this 
got recently merged into druntime: 
https://github.com/D-Programming-Language/druntime/commit/ae3ef074f4cad03cc993737dcae17d2e1e16779f

-- 
/Jacob Carlborg
Dec 11 2012