Advertisements

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.

Advertisements

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.

On 2011-11-05, 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.

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.

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 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.

On 2011-11-05, t1t0 <> 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.

On 2011-11-05, t1t0 <> 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.

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.

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 ?

On Nov 6, 10:44 am, t1t0 <> 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.

On 2011-11-06, t1t0 <> 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.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!