From: John Gordon on
In <f9eb3dce-70e7-44af-a61c-6123d34a89f9(a)g25g2000yqd.googlegroups.com> cerr <ron.eggler(a)gmail.com> writes:

> > How long does the application run before it gets killed?

> There's no fix time base. siometimes after a few seconds, other times
> after a few minutes or even like a half an hour...it's always
> different...

Perhaps the application binary file is stored on a faulty region of
the disk? (This is a complete guess. What is supposed to happen when
a program tries to page into memory, but fails?)

--
John Gordon A is for Amy, who fell down the stairs
gordon(a)panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

From: cerr on
On Jan 12, 10:48 am, John Gordon <gor...(a)panix.com> wrote:
> In <f9eb3dce-70e7-44af-a61c-6123d34a8...(a)g25g2000yqd.googlegroups.com> cerr <ron.egg...(a)gmail.com> writes:
>
> > > How long does the application run before it gets killed?
> > There's no fix time base. siometimes after a few seconds, other times
> > after a few minutes or even like a half an hour...it's always
> > different...
>
> Perhaps the application binary file is stored on a faulty region of
> the disk?  (This is a complete guess.  What is supposed to happen when
> a program tries to page into memory, but fails?)

Well, I took a different hardware platform (PC 104) and tried it
there. It's crashing as well but however, GDB does not report SIGKILL
anymore but the application instead just dies... :o
>
> --
> John Gordon                   A is for Amy, who fell down the stairs
> gor...(a)panix.com              B is for Basil, assaulted by bears
>                                 -- Edward Gorey, "The Gashlycrumb Tinies"

From: John Gordon on
In <e304a543-a511-4c8a-9179-be00acaaf5ad(a)k17g2000yqh.googlegroups.com> cerr <ron.eggler(a)gmail.com> writes:

> I just saw that I got a SIGABRT - but that twice only... :o may this
> be a clue?
> How would my process be getting a SIGABRT? Any clues? :o

SIGABRT is raised by calling the abort() system call, or when an assert()
evaluates to false.

Does your program contain any abort() or assert() calls?

--
John Gordon A is for Amy, who fell down the stairs
gordon(a)panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

From: cerr on
On Jan 12, 2:02 pm, John Gordon <gor...(a)panix.com> wrote:
> In <e304a543-a511-4c8a-9179-be00acaaf...(a)k17g2000yqh.googlegroups.com> cerr <ron.egg...(a)gmail.com> writes:
>
> > I just saw that I got a SIGABRT - but that twice only... :o may this
> > be a clue?
> > How would my process be getting a SIGABRT? Any clues? :o
>
> SIGABRT is raised by calling the abort() system call, or when an assert()
> evaluates to false.
>
> Does your program contain any abort() or assert() calls?
Yes, there's abort() calls in a file called memwatch.c - I guess I
should have a look at this one...

Thanks!
Ron
From: cerr on
On Jan 12, 2:07 pm, cerr <ron.egg...(a)gmail.com> wrote:
> On Jan 12, 2:02 pm, John Gordon <gor...(a)panix.com> wrote:> In <e304a543-a511-4c8a-9179-be00acaaf...(a)k17g2000yqh.googlegroups.com> cerr <ron.egg...(a)gmail.com> writes:
>
> > > I just saw that I got a SIGABRT - but that twice only... :o may this
> > > be a clue?
> > > How would my process be getting a SIGABRT? Any clues? :o
>
> > SIGABRT is raised by calling the abort() system call, or when an assert()
> > evaluates to false.
>
> > Does your program contain any abort() or assert() calls?
>
> Yes, there's abort() calls in a file called memwatch.c - I guess I
> should have a look at this one...

Oh look there, it's a huge file and in the header it says:

** MEMWATCH.C
** Nonintrusive ANSI C memory leak / overwrite detection
** Copyright (C) 1992-2001 Johan Lindh
** All rights reserved.
** Version 2.67

o after all I probably sent myself these signals...Does anyone know
anything about this memwatch.c file - gotta make myself smart 1st :)?
--
Ron