cppunit-devel

[Cppunit-devel] Signal handling in Linux

[Robert W. <ro...@po...>]

Hi,

I expect some of my tests to access a null pointer and thus to raise a
signal (SIGSGV). I would like to thow an Exception on arrival of any
signal to avoid it terminating the program and instead be recorded
as a failed or succeded test run.
The C++=A0standard does not allow any C++ features being used in
signal handler functions, especially no exceptions.
I really do not like using a global variable (or singleton) which I=20
check at the end of the test.
Can anybody please point me to a more elegant solution?
Is there perhaps some kind of compiler setting to map signals to
exceptions by default (I use g++)?

Thanks in advance

Robert

Re: [Cppunit-devel] Signal handling in Linux

[Baptiste L. <gai...@fr...>]

VC++ provides _set_se_translator() do translate such fault into C++
exception (a life saver when testing multithreaded application). I don't
know if g++ provides a similar functionnality...

Baptiste.

----- Original Message -----
From: "Robert Wenner" <ro...@po...>
To: <cpp...@li...>
Sent: Thursday, March 21, 2002 4:56 PM
Subject: [Cppunit-devel] Signal handling in Linux


Hi,

I expect some of my tests to access a null pointer and thus to raise a
signal (SIGSGV). I would like to thow an Exception on arrival of any
signal to avoid it terminating the program and instead be recorded
as a failed or succeded test run.
The C++ standard does not allow any C++ features being used in
signal handler functions, especially no exceptions.
I really do not like using a global variable (or singleton) which I
check at the end of the test.
Can anybody please point me to a more elegant solution?
Is there perhaps some kind of compiler setting to map signals to
exceptions by default (I use g++)?

Thanks in advance

Robert

_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] Signal handling in Linux

[Baptiste L. <gai...@fr...>]

Is it possible to wrap the signal logic into a class (even if it use global
variable) ? I'm planning to add a feature to add 'custom' exception support
(export not based on std::exception) to CppUnit.

To do that, I just call a must on a class with the Test to run and the
TestResult which 'protect ' the test run. In your case, that would means
trapping the signal, and throwing adding a failure to TestResult.

I'm really interessed into this, because VC++ does this automatically for us
in debug mode. This is not the case on Unix, and as such does not provide a
consistent behavior across plateform. As a consequence, on Unix, you would
need a TestListener that print the test name before running the test, just
to now which test failed...

Baptiste.

----- Original Message -----
From: "Robert Wenner" <ro...@po...>
To: <cpp...@li...>
Sent: Thursday, March 21, 2002 5:56 PM
Subject: [Cppunit-devel] Signal handling in Linux


Hi,

I expect some of my tests to access a null pointer and thus to raise a
signal (SIGSGV). I would like to thow an Exception on arrival of any
signal to avoid it terminating the program and instead be recorded
as a failed or succeded test run.
The C++ standard does not allow any C++ features being used in
signal handler functions, especially no exceptions.
I really do not like using a global variable (or singleton) which I
check at the end of the test.
Can anybody please point me to a more elegant solution?
Is there perhaps some kind of compiler setting to map signals to
exceptions by default (I use g++)?

Thanks in advance

Robert

_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] Signal handling in Linux

[Baptiste L. <gai...@fr...>]

So If I understood thing well, the only hope that remains would compiler
specific. VC++ has such a thing, have you found anything like that on gcc ?
(I guess not, but...)

In the meantime, I think I'll add a VerboseTestProgressListener:
startTest(): print test name
failure(): print ':' and 'E' or 'F'
endTest(): new line

Baptiste.

----- Original Message -----
From: "Robert Wenner" <ro...@po...>
To: "Baptiste Lepilleur" <gai...@fr...>;
<cpp...@li...>
Sent: Monday, April 15, 2002 8:33 AM
Subject: Re: [Cppunit-devel] Signal handling in Linux


> On Saturday 13 April 2002 11:28, Baptiste Lepilleur wrote:
> > Is it possible to wrap the signal logic into a class (even if it use
> > global variable) ? I'm planning to add a feature to add 'custom'
> > exception support (export not based on std::exception) to CppUnit.
>
> As far as I found something on the web on the topic of signal handling
> and C++: don't do it.
> Std C++ sticks to the old C behaviour of signal handling.
> That means use of C++ features will result in undefined behaviour;
> especially use of RTTI, member variables and exceptions.
> IMHO the best way to solve the signal problems is to set a global
> variable in the signal handler and return. The calling program (in
> case of CppUnit) the framework has to check that variable.
> Having the signal wrapper class use a list of received signals would
> also be possible to throw multiple exceptions (if desired).
> Ignoring some signals (such as SIG_SEGV) is considered dangerous
> as the program may be left in an undefined state (e.g. what is the
> result from a divide by zero?). This may be no problem with some
> short test cases, though.
>
> > To do that, I just call a must on a class with the Test to run and
> > the TestResult which 'protect ' the test run. In your case, that
> > would means trapping the signal, and throwing adding a failure to
> > TestResult.
> I tried a little with setting the signal handler in setUp and checking
> the global variable in tearDown, but signals behaved really strange
> on my machine (examples for a SEGV by wrong pointer access).
> - Ignoring (SIG_IGN setting ) the signal (or using no handler) crashes
> the program (the default behaviour for unhandled signals)
> - Catching the signal causes the handler to execute and after that
> crash the program
> - Catching the signal and re-installing the signal handler (it is
> uninstalled by default according to the man page) or not using the
> ONESHOT option in sa_flags results in endless signals received ->
> program hangs.
>
> > I'm really interessed into this, because VC++ does this automatically
> > for us in debug mode. This is not the case on Unix, and as such does
> > not provide a consistent behavior across plateform. As a consequence,
> > on Unix, you would need a TestListener that print the test name
> > before running the test, just to now which test failed...
> IMHO the C++ std is somewhat lazy / minimalistic here. :-(
> By time C++ should drop these old C garbage.
> Anyway  I would be really interestedin a soultion, too.
>
> Robert
>

Re: [Cppunit-devel] Signal handling in Linux

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Robert Wenner" <ro...@po...>
To: "Baptiste Lepilleur" <gai...@fr...>;
<cpp...@li...>
Sent: Tuesday, April 16, 2002 7:58 AM
Subject: Re: [Cppunit-devel] Signal handling in Linux


> Hi!
>
> On Monday 15 April 2002 23:44, Baptiste Lepilleur wrote:
> > So If I understood thing well, the only hope that remains would
> > compiler specific. VC++ has such a thing, have you found anything
> > like that on gcc ? (I guess not, but...)
>
> I think it would be compiler dependent, yes.
> I do not know the exact behaviour in VC++, but I did not even found
> something like a workaround on g++, as my C style stuff didn't work
> as expected I quickly dropped that topic and tried to have test cases
> that don't result in null pointer access -- not the bes solution, I
> know...

VC++ as a function called _set_se_translator() which allow you to set a
'translator' that is called to handle structured exception (the equivalent
of signal if I understood correctly) and convert them into C++ exception. In
any case, the stack frame is always unwinded correctly. Structured exception
are the equivalent for VC++ to a throw int(exception_type) (in debug mode),
which explains why catch(...) works for us even though we did not set any
exception translator.

>
> > In the meantime, I think I'll add a VerboseTestProgressListener:
> > startTest(): print test name
> > failure(): print ':' and 'E' or 'F'
> > endTest(): new line
> Better to be names BriefTestProgressListener?

Done. If you have others suggestions like that one, they are welcome. One of
the step that will be taken before going beta is renaming 'not so intention
revealing classes' (TestResult is a primary candidate but does not have its
final form yet).

Thanks,
Baptiste.