On 8/1/2012 9:04 AM, Scott Lurndal wrote:
> Mark <> writes:
>> On Tue, 31 Jul 2012 17:49:51 -0500, BGB <> wrote:
>>
>>> On 7/31/2012 3:25 PM, Scott Lurndal wrote:
>>>> BGB <> writes:
>>>>> On 7/31/2012 9:20 AM, Scott Lurndal wrote:
>>>>>> James Kanze <> writes:
>>>>>>> On Monday, July 30, 2012 7:59:44 PM UTC+1, Stuart wrote:
>>>>>>>> On 7/30/12 Jorgen Grahn wrote:
>>>>>>>
>>>>>>>>> Wait a minute -- you say the MS compiler works as you want;
>>>>>>>>> I say gcc does on Linux ... where *do* you see the problem?
>>>>>>>
>>>>>>>> I thought gcc did not turn Access Violations into exceptions.
>>>>>>>> AFAIK, this is a unique feature of the MS compilers. However,
>>>>>>>> I would very much like to be proven wrong.
>>>>>>>
>>>>>>> This error is unique to MS compilers I think (and I think it's
>>>>>>> optional there). With g++ under Linux (and all other Unix
>>>>>>> compilers, I think), and access violation results in a core
>>>>>>> dump, which is far preferrable for most applications.\\
>>>>>>
>>>>>> technically, an access violation results in a signal, which if
>>>>>> not caught by the application will terminate the application with
>>>>>> a core file (if the core file resource limit allows, and if the
>>>>>> stupid Fedora ABRT package isn't running).
>>>>>>
>>>>>
>>>>> yeah, and nifty stuff can be done in signal handlers, potentially
>>>>> including, among other things, triggering an exception to the thrown and
>>>>> the stack to be unwound. whether or not this is a good idea is a
>>>>> separate issue, normal C++ exceptions may not necessarily work (a custom
>>>>> mechanism may be needed), and have not yet determined how portable or
>>>>> versatile this is.
>>>>
>>>> I tend to use siglongjmp() to unwind when I catch asynchronous signals
>>>> such as SIGTERM/SIGINT/SIGQUIT. When catching synchronous, such as SIGSEGV, there are
>>>> no assurances that the rest of the program is still sane, and attempting
>>>> to generate a C++ exception may result in undefined behaviour.
>>>>
>>>
>>> yeah. another issue though is that given how signals and C++ exceptions
>>> work on Linux, I would suspect (untested) that trying to throw a C++
>>> exception in a signal handler could very well cause it to blow up.
>>>
>>> but, yeah, siglongjmp() is probably a much better idea.
>>
>> I often assume that if we receive a SIGTERM/SIGINT/SIGQUIT signal then
>> this is a request to terminate so the application would normally clean
>> up and quit.
>>
>> With SIGSEGV I print out a stack trace and then allow the application
>> to create a core dump.
>
> If, for example, the SIGSEGV was because the FILE structure for stdout
> had been stepped on (or the stdout OutputStream), then attempting to print
> the stack trace will also fault - likewise, if you're using the glibc
> backtrace helpers, they could also encounter undefined behavior after
> a SIGSEGV/SIGBUS. You could use write(2, buf, strlen(buf)) to avoid
> a subsequent signal in the stdio code, but the backtrace helpers may
> still encounter issues if the stack got stepped on.
>
even this may not necessarily be unworkable, depending on how the logic
is set up. carefully written logic can still operate in the case of
bad/uncertain pointers. IOW: don't access memory through a pointer
unless it is (presumably) already known to be valid, ...
whether or not this is practical is a different matter (usually, it is
limited to special logic where the possibility of corrupted memory is
not unexpected, such as in the internals of a memory manager, ...).
more often though, the reason a person might be catching a SIGSEGV or
similar might actually be because a failure is expected in a certain
context, say:
potentiallyUnsafeOperation()
{
setup special signal handler;
do unsafe operation;
restore signal handler.
}
usually, in such a case, a person will know why the SIGSEGV or similar
has taken place, and so the intention is to trap and handle it.
in other cases, it might be because, actually, something "clever" is
being done with a memory region, so the signal handler may be used as a
way to handle it (I am aware of people doing this sort of thing partly
for reasons of implementing shared-memory and persistent memory systems,
among other things).
a big reason for not doing this though in the general case (such as
trying to use signal catching in an attempt to make a "crash-proof"
app), it that it may impede the ability to effectively debug the app
(and, may also just create an app that basically just goes into an
endless crash/recovery loop and is unable to resume normal operation
anyways).
Similar Threads
