Debugging embedded board-linux

[garimella]

Hi
I have a power PC board from freescale which runs a linux application for about 20 minutes and then crashes with seg fault. The most predominant message appearing on prompt is "vmap allocation for size 8192 failed: use vmalloc=<size> to increase size" . I have searched all over that recommend increase in size of vmap, but conceptually I do not understand why system crashes exactly after 20 min. If there were problem in vmap allocation, the application should not have run in the first place?

 

[betwixt]

It could be a lot of things but most likely this is a memory leak. At each pass of some routine, more memory is requested but not released afterwards. The cumulative effect over time is insufficient memory to continue. It could be difficult to debug but I would start by stepping each routine and noting how much memory is being used. If a routine exits with less memory than when it was started, it is holding some back.

Brian.

 

[garimella]

Hi
Could you tell me as what would be the best starting point to debug?

 

[andre_luis]

You did not tell anything about your system, as for example the programming language, but in general a well wrote code has a debug mode selection, which is a variable or preprocessor that once enabled, makes the code logging either at console or to a text file (or even via UART), a lot of information about where it is at each pass, as well as showing value of critical variables. This way you can check what the last event recordered and than try to increase the level of detailing of the debug in the last passed routine; that is, it is an experiment of trial and error, converging to the exact point where some allocated memory has certainly not been released.

 

[garimella]

Hi andre,
Programming language is "C". But may be I found the clue. This system crashes after a predetermined time if a device driver is linked with the application. Without device driver invocation, the program runs fine. This brings the suspicion about the driver code. Just to clarify, I am running an application in an infinite loop. Before the while(1) function, I open the driver, but I am not closing it ( within the while loop). It is perpetually open. Whether this might be causing the problem?

 

[andre_luis]

Before the while(1) function, I open the driver, but I am not closing it ( within the while loop). It is perpetually open. Whether this might be causing the problem?

If you are trying to instantiate a device that is already open this would indeed generate an error, but usually in code this is avoided by checks like this:

FILE * pDev = open ("Device_Tpen");
if (pDev == NULL)
{

 

[garimella]

Hi Andre,
Well i discovered that file instantiation is not a problem. my next guess is the usage of ioremap in my driver. What are best ways to use ioremap function. I declared as a= ioremap((volatile unsigned long)<phyaddress>,4) then i passed values *a= data1;*a=data2; and so -on. In particular this code did not work in the beginning. the compiler seems to optimizing two write functions into one. So ihad to declare a1 and a2 mapping to the same phy address and then *a1=data1; *a2=data2 really worked. When i run this code , the system hangs with seg fault after 20 min.

 

[cfant]

I guess that you user trying to use return value from ioremap directly. This is wrong. Please read this link: https://lwn.net/Articles/653585/.

 

[KlausST]

Hi,

Before the while(1) function, I open the driver, but I am not closing it ( within the while loop). It is perpetually open.

If you want it to be open all the time: Then OPEN it before the while(1) loop.

Otherwise
* OPEN and CLOSE it within the while loop.
* Or you OPEN it only when it is not opened already.

Klaus

 

[garimella]

Hi cfant

Do you recommend using memremap instead of ioremap?