Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #12776 > unrolled thread

Error handling

Started byt1t0 <t1t0@noemail.not>
First post2011-11-05 13:31 +0000
Last post2011-11-06 03:56 +0000
Articles 12 — 6 participants

Back to article view | Back to comp.lang.c


Contents

  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

#12776 — Error handling

Fromt1t0 <t1t0@noemail.not>
Date2011-11-05 13:31 +0000
SubjectError 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]


#12777

FromEric Sosman <esosman@ieee-dot-org.invalid>
Date2011-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]


#12783

Fromt1t0 <t1t0@noemail.not>
Date2011-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]


#12784

FromEric Sosman <esosman@ieee-dot-org.invalid>
Date2011-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]


#12811

Fromt1t0 <t1t0@noemail.not>
Date2011-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]


#12793

FromKaz Kylheku <kaz@kylheku.com>
Date2011-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]


#12812

Fromt1t0 <t1t0@noemail.not>
Date2011-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]


#12813

FromNick Keighley <nick_keighley_nospam@hotmail.com>
Date2011-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]


#12814

FromKaz Kylheku <kaz@kylheku.com>
Date2011-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]


#12778

FromNobody <nobody@nowhere.com>
Date2011-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]


#12781

FromKaz Kylheku <kaz@kylheku.com>
Date2011-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]


#12797

FromMike Manilone <zhtx10@gmail.com>
Date2011-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