View topic - Crash application after some hours

Search

Crash application after some hours

AVR Freaks Forum Index » AVR32 (32-bit) Technical Forums » AVR32 Linux Forum

Author

Message

jaws75

Posted: Apr 13, 2011 - 06:20 AM

Joined: Nov 04, 2003
Posts: 77

Hi all,
I am facing a problem with my application. It is a data-logger application that shows the graphics of the measures with FLTK on X. It must be up for hours and days.

After 2/3 hours, sometimes more than 20 hours it crashes. The backtrace of core dump is like this:

Quote:

#0 0x2af7ce54 in malloc () from /nfs/lib/libc.so.0
#1 0x2aefbf40 in ?? () from /nfs/usr/lib/libstdc++.so.6
Backtrace stopped: frame did not save the PC

the log on the shell reports:

X_SetClipRectangles: BadMatch (invalid parameter attributes) 0x0

I think that the error on X are correlated with the crash even if I have seen other time this message in the log.

I traced also the sysinfo data to see how may free ram is available and before the crash we had 32MB of free RAM.

Do you have any suggestions to the possible cause of the crash and how can face this problem?

Any help is really appreciated.
Thanks
J

eaanon01

Posted: Apr 14, 2011 - 01:09 PM

Joined: Aug 22, 2002
Posts: 1586
Location: Arendal Norway

Without knowing anything about the program of the drivers you are using, I would call this a mem handling issue. It migth relate to somthing beeing deleted from memory and then accessed. Just guessing actually here. Or are you running a networking filsystem where the filesystem becomes unaccessable for a period? Again guessing.

_________________
Life's to short for waiting on slow CPU's

jaws75

Posted: Apr 14, 2011 - 01:28 PM

Joined: Nov 04, 2003
Posts: 77

First of all, I'm using buildroot 2.2 with related toolchain gcc 4.2.2, linux 2.6.25.10, boost and boost-log library to manage the logs, fltk and X for the graphics part.

The log data are stored for the moment on NAND flash UBI formatted, next will be stored on SD card FAT formatted, but due to a problem with that driver that blocks the machine after some hours, I decided to build the new kernel 2.6.35 and try the mmc part with the new kernel.

What is hard to understand is why I have this fault!

Any suggestion how to catch the problem is welcome.

eaanon01

Posted: Apr 14, 2011 - 01:33 PM

Joined: Aug 22, 2002
Posts: 1586
Location: Arendal Norway

Can you start the app with strace to see where in your code it craches?

_________________
Life's to short for waiting on slow CPU's

jaws75

Posted: Apr 22, 2011 - 07:41 AM

Joined: Nov 04, 2003
Posts: 77

Hi all,
this is the last part of the strace output that I collected in the last days.
Any idea or suggestions on the cause of the fail?

Thanks
J

Quote:

select(6, [5], [], [], {0, 988087}) = 0 (Timeout)
gettimeofday({42110, 292392}, NULL) = 0
time(NULL) = 42110
open("/etc/TZ", O_RDONLY) = 7
read(7, "CET1CDT\n", 6 Cool

= 8
read(7, "", 60) = 0
close(7) = 0
read(5, 0x81384, 4096) = -1 EAGAIN (Resource temporarily unavailable)
select(6, [5], [], [], {0, 989051}) = 0 (Timeout)
gettimeofday({42111, 293817}, NULL) = 0
time(NULL) = 42111
open("/etc/TZ", O_RDONLY) = 7
read(7, "CET1CDT\n", 6 Cool

= 8
read(7, "", 60) = 0
close(7) = 0
read(5, 0x81384, 4096) = -1 EAGAIN (Resource temporarily unavailable)
select(6, [5], [], [], {0, 987626}) = 0 (Timeout)
gettimeofday({42112, 293464}, NULL) = 0
time(NULL) = 42112
open("/etc/TZ", O_RDONLY) = 7
read(7, "CET1CDT\n", 6 Cool

= 8
read(7, "", 60) = 0
close(7) = 0
read(5, 0x81384, 4096) = -1 EAGAIN (Resource temporarily unavailable)
select(6, [5], [], [], {0, 987979}) = 0 (Timeout)
gettimeofday({42113, 292844}, NULL) = 0
time(NULL) = 42113
open("/etc/TZ", O_RDONLY) = 7
read(7, "CET1CDT\n", 6 Cool

= 8
read(7, "", 60) = 0
close(7) = 0
select(6, [5], [5], NULL, NULL) = 1 (out [5])
writev(5, [{"8\3\0\4\0`\0\7\0\10\0\0\0\0\0\0;\3\0\25\0`\0\7\0\0\0\0"..., 3824}], 1) = 3824
read(5, 0x81384, 4096) = -1 EAGAIN (Resource temporarily unavailable)
select(6, [5], [], [], {0, 988599} <unfinished ...>
+++ killed by SIGSEGV +++
/data #

leon_heller

Posted: Apr 22, 2011 - 11:02 AM

Joined: Jul 27, 2001
Posts: 7429
Location: St. Leonards-on-Sea (UK)

It might be getting a glitch from the mains.

_________________
Leon Heller
G1HSM

jaws75

Posted: Apr 22, 2011 - 11:04 PM

Joined: Nov 04, 2003
Posts: 77

what exactly do you mean?

the backtrace of the core file is:
Core was generated by `/usr/bin/cPlot -v -s -l'.
Program terminated with signal 11, Segmentation fault.
#0 0x2af7d0fe in malloc () from /nfs/rootfs/lib/libc.so.0

eaanon01

Posted: Apr 26, 2011 - 10:13 AM

Joined: Aug 22, 2002
Posts: 1586
Location: Arendal Norway

Have you tried lokking at the memory consumption of your application? Is it constandly increasing?

_________________
Life's to short for waiting on slow CPU's

jaws75

Posted: May 15, 2011 - 03:45 PM

Joined: Nov 04, 2003
Posts: 77

yes, the memory is constantly increases, due to the fact that the application collects some data, writes them into a file and then plots the data in a graph.
The consumption is due to the graphical part.
How can I verify if it is a problem related to the memory?
I tried with getrusage and sysinfo or mallinfo to have some data but I don't see when the crash occurred a memory completely used.
In any case I need a mechanism to discovery when the memory is almost finished in order to do the proper action:
1) release all the data in the graph and restart the draw from the begin
2) Restart the application
3) etc.
Do you have any suggestion to manage this mechanism?
In some application like this, where the system is always working with a constant memory consumption we need to have a recovery mechanism when the memory is finished.

Thanks in advance
J

hce

Posted: May 15, 2011 - 06:21 PM

Joined: Jan 07, 2003
Posts: 4580
Location: Oslo, Norway

You can not allocate memory forever, the system will run out of RAM in the end. Reuse the memory buffers you allocate to draw your plot, or free the plot and make a new one when applicable.

jaws75

Posted: May 15, 2011 - 11:45 PM

Joined: Nov 04, 2003
Posts: 77

Thanks for the reply.
What I am thinking is to free all the memory allocated for the plot at a certain time.
My question now is, how can I calculate the right time to free all the memory allocated and restart the plot, in order to not anticipate too much but at the same time don't reach the point where the application going to crash?

Looking at mallinfo() parameters I am seeing that the free memory fordblks decreasing until about 2k and the increase probably because it acquires a memory page from the global memory amount.

The global memory free is read from sysinfo() -> freeram.

What is the right choice, trigger the free of data plot when the freeram returned by sysinfo reach a certain amount? How can be calculated the right value?

Thanks,
J

Jump to:

All times are GMT + 1 Hour

AVR Freaks Forum Index » AVR32 (32-bit) Technical Forums » AVR32 Linux Forum

AVRFreaks.net

Search