Hi Grahame, It is important to note that not only your programs are running on the system for a long period of time. Fortunately, Debian usually only releases very stable software, unfortunately, it is not said that your software is the cause. If you are going to script regular checks of everything running I would probably opt to hack together a shell script that dumps all process information you can get to email every hour or so (with a cron job). If that does not get you the information you want it is probably best to write your own logger that holds a lot more finegrained info in memory and save that to a disk attached via USB for instance every 5 minutes. Then you need a log analyzer of course to make any sense of all the info, I use Excel when it suffices because it is easy to make graphs with. What I would avoid if I were you is to have your logging with maximum debug write to the on board NAND flash excessively. I am not sure how stable the MTD drivers in the kernel are and perhaps because your logging stops the moment the system is screwed that is actually part of the problem. If your applications are not using shared memory and are not communicating with drivers through /dev /proc or /sys and you are not out of memory, I think your problem is not a memory leak or stray pointer, as your application will not be able to access sufficient resources to crash the system. Good luck and my symphaties go out to you. Wouter Van: [ Namens wildpossum928
Verzonden: donderdag 9 december 2010 3:11
Aan:
Onderwerp: Res: [ts-7000] Re: My TS-7800 go's tropo approximately every 3 months +/- a month.
Hi Lissandro
I am currently doing as you suggested so to my developed programs.
I totally agree with your experience that such issues are causes of interminable problems. I have used Valgrind and memcheck to start off with but no issues found. I am thinking about running my apps under gdb just in case they are problematic.
Looking at the very small foot print for both memory, heap, stack and i/o usage I calculated it would take more than three years for a memory leak to effect the system is any perverse way.
I am also considering getting my apps /proc/ID information every couple of hours to see if I can follow and creeping condition.
Thanks for your assistance and feedback.
--- In ts-7000%40yahoogroups.com, Lissandro <> wrote:
>
> Hi.
>
> I would very, very carefully check all pairs of memory allocation/deallocation,
> if is the case, and if in cases where you use stack variables and/or much
> (recursive?) calls in your software, if is not the case to have static variables
> or dinamic (heap) allocation. This sounds also as a possible "wild pointer"
> case, or a very small memory leak.
>
> I would triple check all references, pointers, loop/index limits.
>
> You could have a variable, say, an unsigned long, that somewhere in future
> processing time will try to handle a negative value or so and the program to go
> berserk. It´s more common to happen than you think, even with experienced
> programmers. I´ve seen ALL of those to happen in the last 21 years "on the
> road".
>
> Usually a program that would take 10 lines of code to do something can end up
> with 80 lines total if you include care checking of everything that can go wrong
> and out of the regular processing path...
>
>
> Cheers
> Lissandro.
>
>
>
>
> ________________________________
> De: wildpossum928 <>
> Para:
> Enviadas: Terça-feira, 7 de Dezembro de 2010 22:25:36
> Assunto: [ts-7000] Re: My TS-7800 go's tropo approximately every 3 months +/- a
> month.
>
> Â
>
>
> I originally took the same investigative route. Only to find that there is
> (were) no crontab tasks scheduled or run over the intervening period (last 4
> months). I certainly wish is was, it would make the investigations so much
> simpler.
>
> As I alluded too on another post.
> "On the multiple crontab process entries is very very strange indeed as there
> are no crontab tasks placed at any time by any user (my programs) - I am the
> only user on the system per say. I suspect the multiple entries of crontab are
> some result, rather than the cause."
>
> I don't know if this is folly on my part or not.
>
> Currently I am thinking the only way I am going to solve this horride problem is
> to take snapshots of /proc and monitor all process requirements over the next
> three months or so.
>
> Anyone go any other ideas?
>
> Thanks for your reply Ian.
>
> --- In , Ian Thompson <ian.thompson@> wrote:
> >
> > It sounds to me like you have a process being started by CRON that is
> > not cleaning up after itself and slowly using up system resources.
> > Have you checked all of the CRON jobs?
> >
> > Ian T.
> >
> > This e-mail, including any attachments and response string, may contain
> >proprietary information which is confidential and may be legally privileged. It
> >is for the intended recipient only. If you are not the intended recipient or
> >transmission error has misdirected this e-mail, please notify the author by
> >return e-mail and delete this message and any attachment immediately. If you are
> >not the intended recipient you must not use, disclose, distribute, forward,
> >copy, print or rely on this e-mail in any way except as permitted by the author.
> >
> ![]()
__,_._,___ |
|