Prev: Suggestions needed
Next: A tool that suggests optimized logic for a piece of code/module/function
From: John Gordon on 12 Jan 2010 13:48 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 12 Jan 2010 16:04 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 12 Jan 2010 17:02 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 12 Jan 2010 17:07 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 12 Jan 2010 17:11
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 |