«

On 8/2/2012 3:20 PM, Scott Lurndal wrote:
> James Kanze <> writes:
>> On Thursday, August 2, 2012 5:57:15 PM UTC+1, Gerhard Fiedler wrote:
>>> James Kanze wrote:
>>
>>>> On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB wrote:
>>>>> 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. [...]
>>
>>>> You cannot throw in a signal handler. The results are undefined
>>>> behavior. And it doesn't reliably work on any platform I know.
>>
>>> What does then the following GCC option do? [1]
>>
>>> -fnon-call-exceptions
>>> Generate code that allows trapping instructions to throw exceptions.
>>> Note that this requires platform-specific runtime support that does
>>> not exist everywhere. Moreover, it only allows trapping instructions
>>> to throw exceptions, i.e. memory references or floating-point
>>> instructions. It does not allow exceptions to be thrown from
>>> arbitrary signal handlers such as SIGALRM.
>>
>>> I know that this is not portable, and that this is not defined in the
>>> C++ standard. (In this sense it is "undefined behavior", but this
>>> doesn't mean that a given compiler and platform can't define it.)
>>
>>> This seems to indicate that GCC allows to throw an exception in a signal
>>> handler for a SIGSEGV, at least on some platforms.
>>
>> It does. I'd be interested in seeing how they implement it.
>> And on what platforms it's supported.
>>
>> I suspect that the limitation to SIGSEGV is somehow linked to
>> the fact that you can't get a SIGSEGV at the critical moment,
>> after a successful call but before the necessary information has
>> been set up in the stack frame. Which isn't true for Intel
>> boxes, I don't think.
>>
>> And does it work for all sources of SIGSEGV? Most Unix systems
>> I know convert stack overflow into SIGSEGV (which may mean that
>> you can't catch the signal).
>
> If you setup an alternate stack for signals (sigaltstack(2)),
> you should be ok as far as catching the signal goes.
>
> You likely cannot throw an exeception then since the alternate
> stack starts with the signal handler activation record. Siglongjmp
> would work, but after the longjmp, you'd still have the problem
> where you don't know _what_ corruption resulted in the SIGSEGV.
>

in many/most cases, probably.

there are some cases though where one may know what caused it.

consider for example a person implementing a garbage collector which
scans the stack. upon trying to read from a guard-page, then a signal
may be generated, and can be fairly safely handled (the signal then
essentially serving as an indication that the end of the stack being
scanned has been reached). (whether or not this is a good way to
implement stack-scanning in a GC is a secondary issue).

likewise, in such a scenario, recovering from a signal may be relatively
safe (rather then in the general case, where a SIGSEGV or similar can be
taken as an indication that something went wrong).

>A perfect language would generate an exception with a stacktrace upon an
>Access Violation, which is much more preferable to a Core Dump. For

Why? You can load the Core Dump with Visual Studio under Windows and
then you have stack traces of all threads running when the access
violation occured.



>generate such a dump when the exception is not caught (AFAIK, Win32 does
>not offer a setting that generates dumps upon Access Violations).

The opposite is the case. Windows does generate dumps by default - always.
If no debugger is running the default debugger will be started.
- Either Dr. Watson or in newer versions of Windows Windows Error Reporting
is started.
- On Blue Screens (core dumps) a mini dump file will be written

These applications can send dump files to a central server (application must
be registered
by the developer for that), where they can be downloaded.
Optionally they can generated by calling a single Win API function or copied
from the Windows
temporary directory, which is generated by Dr. Watson / WER (Windows Error
Reporting).

>Thanks in advance,
>Stuart

Andre

On July 31, 2012 Stuart wrote:
>> Now I have the problem that I am bound to the Windows platform
>> (drivers), so when I do something wrong and get an Access Violation,
>> I'll get an BAD_ACCESS exception. This is actually a good thing because
>> my application does not shut down without a pip, but the stack is
>> unwound and the measurement machine returns to a defined state (stages
>> stopped, camera in idle mode). But unfortunately I have no more
>> information about where the Access Violation occurred since C++
>> exceptions are designed to be used in a different way. Well, this works
>> well for my StopException since I don't care which particalur action has
>> been performed when the user aborted the measurement, but in case
>> something went wrong, I'd like to see what happened.

On 8/1/12 James Kanze wrote:
> That's a problem regarding the platform, *not* C++. The last
> thing you want in such cases is for the stack to be unwound.
> You want a dump of the state exactly where the error occurred.
> A core dump, under Unix. (From what I understand, it's possible
> to configure Windows to behave correctly as well.)

Actually, I'm relying heavily on the stack unwind, since this
constitutes a kind of emergency stop procedure for me. The only
alternative would be to create a separate stack with emergency stop
actions that should be executed when an Access Violation occurs, but
that would be equally cumbersome.

>> A perfect language would generate an exception with a stacktrace upon an
>> Access Violation, which is much more preferable to a Core Dump. For
>> those who actually want to have the core dump, the language should
>> generate such a dump when the exception is not caught (AFAIK, Win32 does
>> not offer a setting that generates dumps upon Access Violations).
>
> How is unwinding the stack preferrable to a core dump. The
> stack trace tells where you were, but doesn't offer any
> possiblity to see the surrounding state at each level.
> Unwinding the stack looses important information.

I totally agree. But I thought that if backtraces in exceptions will
never make it into the standard, then core dumps will be out of the
question.

So let me rephrase it: Ideally, I would like the language to dump when
an Access Violation occurs (gives me all the information to debug the
programming error later on), and then to unwind the stack (brings the
measurement machine back into a defined state). Unfortunately, the C++
standard just says that upon Access Violations I will enter the land of UB.

I wonder how all those life-critical components for example in the
medical or aviation business are written. Probably with some compiler
that won't bust upon Access Violations. I mean, what good is a core dump
when your plane is already cruising at an altitude of 10.000 feet?

Regards,
Stuart

On 8/3/12 Andre Kaufmann wrote:
> The opposite is the case. Windows does generate dumps by default - always.
> If no debugger is running the default debugger will be started.
> - Either Dr. Watson or in newer versions of Windows Windows Error Reporting
> is started.
> - On Blue Screens (core dumps) a mini dump file will be written
>
> These applications can send dump files to a central server (application
> must be registered
> by the developer for that), where they can be downloaded.
> Optionally they can generated by calling a single Win API function or
> copied from the Windows
> temporary directory, which is generated by Dr. Watson / WER (Windows
> Error Reporting).

Gosh, I never even suspected such a thing. I think what fooled me into
this belief is that the window that informs you about an Access
Violation tells you that it wants to send some information to Microsoft
but never even mentions that it generated a core dump file. Our
workaround was to run the measurement application from the debugger, but
that is not an option when the application should run in the field.

Thanks,
Stuart

On Fri, 2012-08-03, Stuart wrote:
....
> Actually, I'm relying heavily on the stack unwind, since this
> constitutes a kind of emergency stop procedure for me. The only
> alternative would be to create a separate stack with emergency stop
> actions that should be executed when an Access Violation occurs, but
> that would be equally cumbersome.
....
> So let me rephrase it: Ideally, I would like the language to dump when
> an Access Violation occurs (gives me all the information to debug the
> programming error later on), and then to unwind the stack (brings the
> measurement machine back into a defined state).

There's possibly one non-C++ mechanism at play here.

If you're into controlling hardware (or other I/O not heavily
encapsulated by the OS) you often have OS mechanisms as a last resort.

E.g. if you control a flatbed scanner you want the light to go off and
the camera arm to move back to its parked position. A well-designed
device driver for that will see its file descriptor (in Unix) close as
the application crashes, and reset itself. Placing responsibility for
the reset on the application would be a very bad idea. Even if you
changed C++ so you could reliably do that before crashing, the device
could still not be safely used from C, Python, Perl, ...

> Unfortunately, the C++
> standard just says that upon Access Violations I will enter the land of UB.
>
> I wonder how all those life-critical components for example in the
> medical or aviation business are written. Probably with some compiler
> that won't bust upon Access Violations.

Such software must always rely on assumptions not found in the C++
standard, e.g. what the OS promises. I think the situation would be
the same if you chose any other mainstream language.

> I mean, what good is a core dump
> when your plane is already cruising at an altitude of 10.000 feet?

Ever watch Discovery Channel? Lots of people are very interested in
finding out why a plane crashed. I'm sure there are very detailed
requirements for this.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Thu, 02 Aug 2012 17:56:51 -0500, Paavo Helde wrote:

> So actually the destructor is one piece of code
> where one actually does not need to worry about thread-safety at all.

Other threads shouldn't be accessing the object being destroyed, but the
destructor may need to access referenced objects.

In theory, the issues can be dealt with by ensuring that all such accesses
are thread-safe (e.g. protected by a mutex). In practice, fine-grained
locking can have signicant performance costs, so it's not uncommon to seek
strategies to reduce this. Some of those strategies push the burden of
thread-safety onto callers, which may be problematic when calls are
implicit.

On 8/3/2012 2:49 AM, Jorgen Grahn wrote:
> On Fri, 2012-08-03, Stuart wrote:
> ...
>> Actually, I'm relying heavily on the stack unwind, since this
>> constitutes a kind of emergency stop procedure for me. The only
>> alternative would be to create a separate stack with emergency stop
>> actions that should be executed when an Access Violation occurs, but
>> that would be equally cumbersome.
> ...
>> So let me rephrase it: Ideally, I would like the language to dump when
>> an Access Violation occurs (gives me all the information to debug the
>> programming error later on), and then to unwind the stack (brings the
>> measurement machine back into a defined state).
>
> There's possibly one non-C++ mechanism at play here.
>
> If you're into controlling hardware (or other I/O not heavily
> encapsulated by the OS) you often have OS mechanisms as a last resort.
>
> E.g. if you control a flatbed scanner you want the light to go off and
> the camera arm to move back to its parked position. A well-designed
> device driver for that will see its file descriptor (in Unix) close as
> the application crashes, and reset itself. Placing responsibility for
> the reset on the application would be a very bad idea. Even if you
> changed C++ so you could reliably do that before crashing, the device
> could still not be safely used from C, Python, Perl, ...
>

yeah. it also makes sense to try to design software so that it can
recover from crashes.

usually, this often means explicit recover mechanisms, say the app can
fix its data once it restarts, and generally avoid leaving data in a
state where it will be "dead in the water" if a crash occurs.


drivers can often help here.

likewise, even a lot of hardware itself has its own safety mechanisms,
usually in the form of on-device firmware, and sometimes via
electromechanical mechanisms or similar, such as in the case of HDDs and
similar (for example, if an HDD looses power, it will automatically park
the heads, ...).

sadly, OS filesystem drivers and similar are often not as robustly
designed, as damage in the right spot may often render the drive unable
to recover (say, damage to the partition table / MBR, corruption of the
boot-sector or other core filesystem structures, ...).

things like journals/... can help, but usually performance and low
overhead are preferred over robustness, which is often left over to the
HDD (which itself is left implementing things like ECC and
sector-remapping, ..., at some cost to total drive capacity).


but, ultimately, I think this is also part of why file-based software
(and OS's which does full reboots, and recompiling software from
source-code, ...) are ultimately preferable to software based solely on
"process images" and "living systems", since in this latter case, if
something crashes or goes terribly wrong, there may be no recovery
(whereas with a file-based system, in the worst case, assuming the HDD
still works, a person can still recover all of their files from the
drive, reinstall the OS and software, and get back to whatever they were
doing).



>> Unfortunately, the C++
>> standard just says that upon Access Violations I will enter the land of UB.
>>
>> I wonder how all those life-critical components for example in the
>> medical or aviation business are written. Probably with some compiler
>> that won't bust upon Access Violations.
>
> Such software must always rely on assumptions not found in the C++
> standard, e.g. what the OS promises. I think the situation would be
> the same if you chose any other mainstream language.
>
>> I mean, what good is a core dump
>> when your plane is already cruising at an altitude of 10.000 feet?
>
> Ever watch Discovery Channel? Lots of people are very interested in
> finding out why a plane crashed. I'm sure there are very detailed
> requirements for this.
>

I once saw an episode of Nova talking about a plane that crashed.
basically, something went wrong (wind speed sensor froze, started
returning 0 wind-speed, causing control software to crash), the plane
sent a crash dump back to the manufacturer over radio, and then the
plane promptly crashed into the ocean.

the manufacturer later found the crash dump and this helped them
identify why the plane crashed.

>Gosh, I never even suspected such a thing.

I still wonder why such a feature isn't communicated widely by Microsoft.

>but never even mentions that it generated a core dump file.

Yes, not directly. But there is a link in the lower half of the dialog,
"additional info" or "view attached files" or something like that.

If you click on that it will open a list with some files. One of these
files is the dump file (*.dmp).


Additionally since IIRC Windows Vista you can write a dump file
of an application by right clicking on it's entry in the task manager.


I've added a kind of live debugging feature to our application.
You can load directly a snapshot dump file from inside Visual Studio
over a http channel of our running application and debug for example
deadlocks.

>Thanks,
>Stuart

Your welcome,
Andre

BGB wrote:

> On 8/2/2012 3:20 PM, Scott Lurndal wrote:
>> James Kanze <> writes:
>>> On Thursday, August 2, 2012 5:57:15 PM UTC+1, Gerhard Fiedler wrote:
>>>> James Kanze wrote:
>>>
>>>>> On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB wrote:
>>>>>> 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. [...]
>>>
>>>>> You cannot throw in a signal handler. The results are undefined
>>>>> behavior. And it doesn't reliably work on any platform I know.
>>>
>>>> What does then the following GCC option do? [1]
>>>
>>>> -fnon-call-exceptions
>>>> Generate code that allows trapping instructions to throw exceptions.
>>>> Note that this requires platform-specific runtime support that does
>>>> not exist everywhere. Moreover, it only allows trapping instructions
>>>> to throw exceptions, i.e. memory references or floating-point
>>>> instructions. It does not allow exceptions to be thrown from
>>>> arbitrary signal handlers such as SIGALRM.
>>>
>>>> I know that this is not portable, and that this is not defined in the
>>>> C++ standard. (In this sense it is "undefined behavior", but this
>>>> doesn't mean that a given compiler and platform can't define it.)
>>>
>>>> This seems to indicate that GCC allows to throw an exception in a signal
>>>> handler for a SIGSEGV, at least on some platforms.
>>>
>>> It does. I'd be interested in seeing how they implement it.
>>> And on what platforms it's supported.
>>>
>>> I suspect that the limitation to SIGSEGV is somehow linked to
>>> the fact that you can't get a SIGSEGV at the critical moment,
>>> after a successful call but before the necessary information has
>>> been set up in the stack frame. Which isn't true for Intel
>>> boxes, I don't think.
>>>
>>> And does it work for all sources of SIGSEGV? Most Unix systems
>>> I know convert stack overflow into SIGSEGV (which may mean that
>>> you can't catch the signal).
>>
>> If you setup an alternate stack for signals (sigaltstack(2)),
>> you should be ok as far as catching the signal goes.
>>
>> You likely cannot throw an exeception then since the alternate
>> stack starts with the signal handler activation record. Siglongjmp
>> would work, but after the longjmp, you'd still have the problem
>> where you don't know _what_ corruption resulted in the SIGSEGV.
>>
>
> in many/most cases, probably.
>
> there are some cases though where one may know what caused it.
>
> consider for example a person implementing a garbage collector which
> scans the stack. upon trying to read from a guard-page, then a signal
> may be generated, and can be fairly safely handled (the signal then
> essentially serving as an indication that the end of the stack being
> scanned has been reached). (whether or not this is a good way to
> implement stack-scanning in a GC is a secondary issue).
>
> likewise, in such a scenario, recovering from a signal may be
> relatively safe (rather then in the general case, where a SIGSEGV or
> similar can be taken as an indication that something went wrong).

FWIW, it was such "controlled" segfaults of which I was thinking, not
the rogue type where you really don't know what and why.

I don't think it would work for SIGSEGVs because of stack overflow.
Either your stack is bad, or you're using a separate stack for signal
handlers, in which case it seems that the mechanism won't work.

I haven't yet found an answer to the platform support. (GCC
documentation only says "Note that this requires platform-specific
runtime support that does not exist everywhere.") If anybody happens to
have a pointer for documentation about the platform support of this
feature, I'd be grateful.

Thanks,
Gerhard

On 8/4/2012 5:41 PM, Gerhard Fiedler wrote:
> BGB wrote:
>
>> On 8/2/2012 3:20 PM, Scott Lurndal wrote:
>>> James Kanze <> writes:
>>>> On Thursday, August 2, 2012 5:57:15 PM UTC+1, Gerhard Fiedler wrote:
>>>>> James Kanze wrote:
>>>>
>>>>>> On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB wrote:
>>>>>>> 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. [...]
>>>>
>>>>>> You cannot throw in a signal handler. The results are undefined
>>>>>> behavior. And it doesn't reliably work on any platform I know.
>>>>
>>>>> What does then the following GCC option do? [1]
>>>>
>>>>> -fnon-call-exceptions
>>>>> Generate code that allows trapping instructions to throw exceptions.
>>>>> Note that this requires platform-specific runtime support that does
>>>>> not exist everywhere. Moreover, it only allows trapping instructions
>>>>> to throw exceptions, i.e. memory references or floating-point
>>>>> instructions. It does not allow exceptions to be thrown from
>>>>> arbitrary signal handlers such as SIGALRM.
>>>>
>>>>> I know that this is not portable, and that this is not defined in the
>>>>> C++ standard. (In this sense it is "undefined behavior", but this
>>>>> doesn't mean that a given compiler and platform can't define it.)
>>>>
>>>>> This seems to indicate that GCC allows to throw an exception in a signal
>>>>> handler for a SIGSEGV, at least on some platforms.
>>>>
>>>> It does. I'd be interested in seeing how they implement it.
>>>> And on what platforms it's supported.
>>>>
>>>> I suspect that the limitation to SIGSEGV is somehow linked to
>>>> the fact that you can't get a SIGSEGV at the critical moment,
>>>> after a successful call but before the necessary information has
>>>> been set up in the stack frame. Which isn't true for Intel
>>>> boxes, I don't think.
>>>>
>>>> And does it work for all sources of SIGSEGV? Most Unix systems
>>>> I know convert stack overflow into SIGSEGV (which may mean that
>>>> you can't catch the signal).
>>>
>>> If you setup an alternate stack for signals (sigaltstack(2)),
>>> you should be ok as far as catching the signal goes.
>>>
>>> You likely cannot throw an exeception then since the alternate
>>> stack starts with the signal handler activation record. Siglongjmp
>>> would work, but after the longjmp, you'd still have the problem
>>> where you don't know _what_ corruption resulted in the SIGSEGV.
>>>
>>
>> in many/most cases, probably.
>>
>> there are some cases though where one may know what caused it.
>>
>> consider for example a person implementing a garbage collector which
>> scans the stack. upon trying to read from a guard-page, then a signal
>> may be generated, and can be fairly safely handled (the signal then
>> essentially serving as an indication that the end of the stack being
>> scanned has been reached). (whether or not this is a good way to
>> implement stack-scanning in a GC is a secondary issue).
>>
>> likewise, in such a scenario, recovering from a signal may be
>> relatively safe (rather then in the general case, where a SIGSEGV or
>> similar can be taken as an indication that something went wrong).
>
> FWIW, it was such "controlled" segfaults of which I was thinking, not
> the rogue type where you really don't know what and why.
>
> I don't think it would work for SIGSEGVs because of stack overflow.
> Either your stack is bad, or you're using a separate stack for signal
> handlers, in which case it seems that the mechanism won't work.
>
> I haven't yet found an answer to the platform support. (GCC
> documentation only says "Note that this requires platform-specific
> runtime support that does not exist everywhere.") If anybody happens to
> have a pointer for documentation about the platform support of this
> feature, I'd be grateful.
>

I think GCC has this support on Linux and x86.

what little I am aware of is that GCC (often?) implements exception
unwinding using a variant of the DWARF debug format, and by making calls
to API functions. the API magic then proceeds basically to start
unwinding call frames and restoring registers.

the uncertainty I have is regarding how Linux goes about transferring
control to the signal handler. there is a certain possibility that
control will pass through code which potentially lacks
exception-handling data, at which case the behavior of the unwinding
logic would be uncertain, though it is just as possible that the
unwinding API could just as easily detect/handle this case specially
(restoring the preserved state or similar, and resuming normal unwind
behavior within the code which generated the signal).

granted, yes, even if it does work, it is probably not exactly portable,
so other options may still be better.

I have not actually tried any of this personally though. most of my
experience has more been with longjmp and Win32 SEH and implementing a
"fake SEH" mechanism and similar (basically, unwinding via recursive
longjmp), which are admittedly a bit different from using C++ exceptions.


or such...


> Thanks,
> Gerhard
>