Getting the name of the method that is causing infinite loops in imx6 WEC7

Technical Support
, ,
1

Hi,

We had some issues in our app where after running for a few days one of the threads start to saturate and takes 99% of the CPU resource. I tried Kernel Tracker and Profiler tools but was unable to pinpoint the method/function causing it. The lowest I could get is the address of the method. But this is a C# managed code, the PDB files do not contain any address to method info.

I found a tool made my somebody for PC based desktop application in .Net as follows which I need to work on .NetCF framework. But, it seems .NetCF does not have a StackTrace class.

My requirements are as follows:

  1. We need a debugging system that will be lightweight and will pinpoint me to the method/function that is talking up the 99% CPU resource.

  2. The modified code of the above small debugger code that will work for WEC7 in .NetCF

  3. Any professional service from Toradex to track down the bug or from any other third party who can professionally help debug such problems in Windows CE C# based application. The system needs a large number of attachable hardware setup to test in our lab which will be difficult, but not impossible to ship. But, we would prefer to debug it here in our lab.

2

Dear @marifhossain

The first thing I recommend is to re-test using our latest beta image V1.5b4, mainly because this is a simple test. I know that we recently fixed a bug around L2 cache, which could generate random problems.

  1. What happens if you attach a regular .NET application debugger? Just wait until the process takes 99% of the CPU load, then press break the application manually through the debugger. with a 99% chance, the debugger will stop in the failing thread. You can continue and break again multiple times to be sure you are in the correct thread.
    This won’t work of course, if a part of the .NET framework itself uses the CPU (e.g. the garbage collector)

  2. I’m afraid I’m not aware of such a tool

  3. At Toradex we try to focus on generic improvement of our products and selective support where our knowledge is required.
    In your case I would recommend you team up with a company from our partner network if you cannot get further on.
    I can ask our team in the US whether they know somebody in your area which is capable to support you locally in your offices.

A completely different approach would be to switch to WEC2013 and .NET CF V3.9. This version supports multiple cores even within the .NET framework. This might not really solve your problem, but could hide it if the second CPU core could continue executing non-blocked threads.

Regards, Andy

3

Dear Andy,

We cannot run the app in .Net application debug mode as most of the times the application becomes “low in memory” and OS shoots a pop-up window and hangs there until we click ok several times and that happens again and again. And, this is not a natural process as it seems to slow down our application and affects the real-time performance.

This bug is not predictable and happens intermittently. We can only intervene when the CPU usage becomes 99%. Generally, I suspect that it happens when we connect a high number of sensors (256 max) to the communication bus (Dialog bus).

We would like to team up with your partners to solve this issue. Please ask your US team if they have anyone to help us with this issue.

Regards,
Arif

4

Dear @marifhossain
I forwarded your request to our US team. They will get in contact with you.

Regards, Andy