Re: [boost] [test] Possible design flawinexecution_monitor::catch_signals

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-03-03 10:18:41

"Jim Douglas" <jim_at_[hidden]> wrote in message 
news:du8qc7$ikt$1_at_sea.gmane.org...
> Gennadiy Rozental wrote:
>>>In brief, the primary execution failure corrupts the program heap. When
>>>the C++ exception is thrown at execution_monitor:462, the exception
>>>handling mechanism calls __cxa_allocate_exception which then calls
>>>std::malloc. But, because of the corrupted heap, this call blocks
>>>against the malloc mutex.
>>
>> Is there any way to avoid memory allocation?
>
> Yes, don't throw an exception. It is the system that is allocating
> memory for the exception.
>
>> The exception itself doesn't allocate the memory (namely for the reasons 
>> above).
>
> Oh yes it does. Before you can throw an exception you have to create one
> and that will involve a call to new, which in most cases results in a
> call to malloc.

I don't see why. The exception is defined on stack. Why would the system 
need to call to new?
There are other alternatives: I could make exception object static, I could 
throw  special int value to indicate falire and have exception object 
available globally.

> [...]
>
>> You could disable catching system errors for this test or this 
>> configuration
>> (using either command line argument or environment variable).
>
> I am trying to make a general point here that the code is badly designed
> and is prone to failure on any OS, not just QNX. To use a simple analogy
> you are currently asking a mortally wounded soldier to get back in the
> front line and continue to fight.

I do not. Immediate reaction to SIGSEGV is an attempt to log an error and 
exit process.

> A memory segment violation _may_
> cripple a process. There is _no_guarantee_ that following a memory
> segment violation a process is in a fit state to continue execution.
> Don't you remember the good old days when a memory segment violation
> under Windows would wipe out the entire OS :-)
>
> See also Ian McCulloch's post that backs me up.
>
> BTW the specific case has been dealt with by withdrawing the test. I
> just want to make sure this does not happen again to anyone.

This is really very simple. For the usages in regression testing user is not 
interested in core files. Instead we prefer as much information in 
output/log that indicate the error. I do not have an ability to properly log 
an error from within signal handler. So I am trying to jump out of it to the 
place where I could. In worse case scenario we should end up with another 
core. Which is unusable, but we are not interested in core files in a fist 
place.

And as usual any alternative proposition would be very welcome.

Gennadiy