Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #12776 > unrolled thread
| Started by | t1t0 <t1t0@noemail.not> |
|---|---|
| First post | 2011-11-05 13:31 +0000 |
| Last post | 2011-11-06 03:56 +0000 |
| Articles | 12 — 6 participants |
Back to article view | Back to comp.lang.c
Error handling t1t0 <t1t0@noemail.not> - 2011-11-05 13:31 +0000
Re: Error handling Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 09:55 -0400
Re: Error handling t1t0 <t1t0@noemail.not> - 2011-11-05 18:37 +0000
Re: Error handling Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 14:50 -0400
Re: Error handling t1t0 <t1t0@noemail.not> - 2011-11-06 10:36 +0000
Re: Error handling Kaz Kylheku <kaz@kylheku.com> - 2011-11-06 01:15 +0000
Re: Error handling t1t0 <t1t0@noemail.not> - 2011-11-06 10:44 +0000
Re: Error handling Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-06 06:02 -0800
Re: Error handling Kaz Kylheku <kaz@kylheku.com> - 2011-11-06 16:21 +0000
Re: Error handling Nobody <nobody@nowhere.com> - 2011-11-05 14:10 +0000
Re: Error handling Kaz Kylheku <kaz@kylheku.com> - 2011-11-05 15:31 +0000
Re: Error handling Mike Manilone <zhtx10@gmail.com> - 2011-11-06 03:56 +0000
| From | t1t0 <t1t0@noemail.not> |
|---|---|
| Date | 2011-11-05 13:31 +0000 |
| Subject | Error handling |
| Message-ID | <j93dqr$d4u$1@speranza.aioe.org> |
Hi all, there is a good way to obtain the 'call stack' when errors occur ? On Linux the S.O. create a core dump file with the debug information, but I would like to have a similar information inside the program, to log ever the error and send for an application/email/etc. Thanks in advance, t1t0
[toc] | [next] | [standalone]
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Date | 2011-11-05 09:55 -0400 |
| Message-ID | <j93fac$mgp$1@dont-email.me> |
| In reply to | #12776 |
On 11/5/2011 9:31 AM, t1t0 wrote:
> Hi all,
>
> there is a good way to obtain the 'call stack' when errors occur ?
>
> On Linux the S.O. create a core dump file with the debug information, but
> I would like to have a similar information inside the program, to log
> ever the error and send for an application/email/etc.
C itself provides no means to do this, short of keeping track
of all the calls and returns manually. However, many debuggers and
core-dump analyzers and so on can do this -- at least, they can
do it if the program is built in a prescribed way ("unstripped,"
for example).
Since you're interested in generating reports of programs that
are known to be in trouble, it may be best not to rely on the dying
program itself to do its own post-mortem. An attractive approach on
systems that allow more than one program to execute (again, this is
beyond the realm of the C language) is to write a simple "watchdog"
program that just observes the "worker" program. If the worker runs
to completion successfully, the watchdog just exits silently. But if
the worker completes unsuccessfully or abnormally, the watchdog can
scoop up core dumps or whatever other last-gasp breadcrumbs the worker
was able to strew. Since the watchdog is (presumably) not subject to
the same error that brought down the worker, it has a better chance of
getting the job done than the dying worker does.
However, all this is well outside what the C language provides.
The systems in which you run C programs quite probably offer some
tools to help with this sort of thing, but C itself does not.
--
Eric Sosman
esosman@ieee-dot-org.invalid
[toc] | [prev] | [next] | [standalone]
| From | t1t0 <t1t0@noemail.not> |
|---|---|
| Date | 2011-11-05 18:37 +0000 |
| Message-ID | <j93vpg$t9v$1@speranza.aioe.org> |
| In reply to | #12777 |
On Sat, 05 Nov 2011 09:55:03 -0400, Eric Sosman wrote: > An attractive approach on > systems that allow more than one program to execute (again, this is > beyond the realm of the C language) is to write a simple "watchdog" > program that just observes the "worker" program. Nice idea, that's remember some 'guardian' process like the Firebird one. But, there is a way to get the core dump on Windows OS ? I would like to find a solution for a generic program, like an pattern to have the error reported. I would resolve this problem before write the application, I want know all the app errors... On Sat, 05 Nov 2011 14:10:00 +0000, Nobody wrote: > Also, trying to report a "crash" from within the process which has > crashed is a fool's errand. If you want crash reporting, you need to > wrap the process so that the parent process handles the reporting when > the child crashes. In which case, you can just use the resulting core > dump. I understand, but what about a thread crash ? Could I write some informations on a log file from a catched signal of a secondary thread (like division for 0) and perform a read from the main thread to send informations by email (for example)? Is it very fool? On Sat, 05 Nov 2011 15:31:31 +0000, Kaz Kylheku wrote: > > On glibc-based Linux, you have a function called backtrace. Nice, but there is a way to do the same think on windows? With a library maybe? Do you know one that do this that is platform-independent ? Thanks to all, and sorry for my english t1t0
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Date | 2011-11-05 14:50 -0400 |
| Message-ID | <j940ij$93s$1@dont-email.me> |
| In reply to | #12783 |
On 11/5/2011 2:37 PM, t1t0 wrote:
> On Sat, 05 Nov 2011 09:55:03 -0400, Eric Sosman wrote:
>
>> An attractive approach on
>> systems that allow more than one program to execute (again, this is
>> beyond the realm of the C language) is to write a simple "watchdog"
>> program that just observes the "worker" program.
>
> Nice idea, that's remember some 'guardian' process like the Firebird one.
>
> But, there is a way to get the core dump on Windows OS ? I would like to
> find a solution for a generic program, like an pattern to have the error
> reported.
As I and others have said, there's no C language support for
such a thing. Nearly every platform you might run a C program on
has *some* kind of capability for post-mortem analysis, but both
the nature and the mechanisms are specific to the platform. You
should ask your question on forums devoted to those platforms that
interest you.
>> Also, trying to report a "crash" from within the process which has
>> crashed is a fool's errand. If you want crash reporting, you need to
>> wrap the process so that the parent process handles the reporting when
>> the child crashes. In which case, you can just use the resulting core
>> dump.
>
> I understand, but what about a thread crash ? Could I write some
> informations on a log file from a catched signal of a secondary thread
> (like division for 0) and perform a read from the main thread to send
> informations by email (for example)? Is it very fool?
First, none of this has anything to do with C. Second, "Yes:"
it is very foolish. It is even riskier in a multithreaded program
than in a single-threaded program, and it's already risky there.
--
Eric Sosman
esosman@ieee-dot-org.invalid
[toc] | [prev] | [next] | [standalone]
| From | t1t0 <t1t0@noemail.not> |
|---|---|
| Date | 2011-11-06 10:36 +0000 |
| Message-ID | <j95nv6$len$1@speranza.aioe.org> |
| In reply to | #12784 |
On Sat, 05 Nov 2011 14:50:14 -0400, Eric Sosman wrote: > You > should ask your question on forums devoted to those platforms that > interest you. Correct, but I looking for a 'logic' solution first, not platform- dependent, if it's possible. I'll ask about core dumps on Windows, the 'guardian' my be a good solution, thanks. > Second, "Yes:" > it is very foolish. It is even riskier in a multithreaded program than > in a single-threaded program, and it's already risky there. Thanks for the advise :)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-06 01:15 +0000 |
| Message-ID | <20111105181250.398@kylheku.com> |
| In reply to | #12783 |
On 2011-11-05, t1t0 <t1t0@noemail.not> wrote: > On Sat, 05 Nov 2011 15:31:31 +0000, Kaz Kylheku wrote: >> >> On glibc-based Linux, you have a function called backtrace. > > Nice, but there is a way to do the same think on windows? With a library > maybe? Do you know one that do this that is platform-independent ? It's been a few years for me, but there is "tool help" API in Windows for this kind of thing. You can catch an exception (in every thread) and then use the API to list the modules, snapshot the thread state and such. I wrote a crash dump reporter on Windows CE quite a few years ago. It was very helpful, because crashing programs would just "disappear without a trace" on that platform. With this module, programs left behind an "oops" text file with registers, stack memory, bytes around the instruction pointer and such. The API's are all there to cob this kind of thing together.
[toc] | [prev] | [next] | [standalone]
| From | t1t0 <t1t0@noemail.not> |
|---|---|
| Date | 2011-11-06 10:44 +0000 |
| Message-ID | <j95oeh$n0b$1@speranza.aioe.org> |
| In reply to | #12793 |
On Sun, 06 Nov 2011 01:15:05 +0000, Kaz Kylheku wrote: > You can catch an exception (in every thread) and then use the API to > list the modules, snapshot the thread state and such. But what about signal error (like zero division)? Did Windows produce a signal error or a exception for this kind of error? > I wrote a crash dump reporter on Windows CE quite a few years ago. It > was very helpful, because crashing programs would just "disappear > without a trace" on that platform Nice, this is exactly what I want to avoid at all costs: the death of the application without trace! So, on Windows there is an API to create a core dump, or is it a 'manual' implementation ? Thanks for the reply.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-11-06 06:02 -0800 |
| Message-ID | <364f7e4b-148f-4374-b110-5767904df2a6@r2g2000vbj.googlegroups.com> |
| In reply to | #12812 |
On Nov 6, 10:44 am, t1t0 <t...@noemail.not> wrote: > On Sun, 06 Nov 2011 01:15:05 +0000, Kaz Kylheku wrote: > > You can catch an exception (in every thread) and then use the API to > > list the modules, snapshot the thread state and such. > > But what about signal error (like zero division)? Did Windows produce a > signal error or a exception for this kind of error? yes divide by zero generates on exception on Windows. There are ways to turn this into text. > > I wrote a crash dump reporter on Windows CE quite a few years ago. It > > was very helpful, because crashing programs would just "disappear > > without a trace" on that platform > > Nice, this is exactly what I want to avoid at all costs: the death of the > application without trace! > So, on Windows there is an API to create a core dump, or is it a 'manual' > implementation ? search MSDN. I found MiniDumpWriteDump(),though my experience of Windows minidumps is that they're a bit too limited.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-06 16:21 +0000 |
| Message-ID | <20111106082013.905@kylheku.com> |
| In reply to | #12812 |
On 2011-11-06, t1t0 <t1t0@noemail.not> wrote: > On Sun, 06 Nov 2011 01:15:05 +0000, Kaz Kylheku wrote: > >> You can catch an exception (in every thread) and then use the API to >> list the modules, snapshot the thread state and such. > > But what about signal error (like zero division)? Did Windows produce a > signal error or a exception for this kind of error? I think at this point if you want to develop a solution, you have to do a lot of API doc reading on many details. Windows structured exception handling does represent CPU exceptions like division by zero and access violations. > So, on Windows there is an API to create a core dump, or is it a 'manual' > implementation ? On Windows there is the concept of a registered debugger. When a process goes belly up (unhandled exception), the registered debugger is invoked on it. This could be something interactive like Visual Studio, or a logging utility like Dr. Watson. Any core dumping would have to be done in user space by that debugger utility.
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-11-05 14:10 +0000 |
| Message-ID | <pan.2011.11.05.14.10.00.489000@nowhere.com> |
| In reply to | #12776 |
On Sat, 05 Nov 2011 13:31:07 +0000, t1t0 wrote: > there is a good way to obtain the 'call stack' when errors occur ? Run the program under a debugger. > On Linux the S.O. create a core dump file with the debug information, but > I would like to have a similar information inside the program, to log > ever the error and send for an application/email/etc. There isn't a practical solution which is remotely portable. You would do better asking in a forum which is dedicated to the platform which you are targetting. Also, trying to report a "crash" from within the process which has crashed is a fool's errand. If you want crash reporting, you need to wrap the process so that the parent process handles the reporting when the child crashes. In which case, you can just use the resulting core dump.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-05 15:31 +0000 |
| Message-ID | <20111105083216.546@kylheku.com> |
| In reply to | #12776 |
On 2011-11-05, t1t0 <t1t0@noemail.not> wrote: > Hi all, > > there is a good way to obtain the 'call stack' when errors occur ? > > On Linux the S.O. create a core dump file with the debug information, but > I would like to have a similar information inside the program, to log > ever the error and send for an application/email/etc. On glibc-based Linux, you have a function called backtrace.
[toc] | [prev] | [next] | [standalone]
| From | Mike Manilone <zhtx10@gmail.com> |
|---|---|
| Date | 2011-11-06 03:56 +0000 |
| Message-ID | <slrnjbc1eu.1g3.zhtx10@laptop.mike> |
| In reply to | #12776 |
On 2011-11-05, t1t0 <t1t0@noemail.not> wrote: > Hi all, > > there is a good way to obtain the 'call stack' when errors occur ? debug it! > > On Linux the S.O. create a core dump file with the debug information, but > I would like to have a similar information inside the program, to log > ever the error and send for an application/email/etc. GLib has a set of functions help you to do this. such as g_error, g_warning, g_info, g_message....... Then you can g_log_set_default_handler. If you won't use GLib, you can do it yourself. PS. if you have coredump file, it means you caught some signals. Another way is catching all the signals! Then you can setjmp/longjmp go back to where you have this problem. -- Best Regards, Mike Manilone.
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.c
csiph-web