Faulted PC

[v8dave]

Hi All,

I am getting a Faulted PC at 2023D2A and using the PC app, winaddr2line it shows the following:

FillerFunctionName()
C:\Cvsroot\nburn\EnetDebug\MCF5234/ethernet.cpp:1630

This line does not exist and I can't find this function either although it is shown in the MAP file in the ethernet.od library.

The programme is connecting over GPRS to a server and sendng data via the DAQConnect library. Another unit running in release mode is fine and has been working now for over 48 hours. This development unit with the same hardware crashes after anything from a few minutes to a few hours of connection.

Any one any ideas how I can go about tracking this down?

Cheers,
Dave...

[v8dave]

Following on from this, I am still getting this crash. Attached is a view of the debug window when it crashes.

It always crashes at this exact same point but when I check the variables they are all fine and it has just started the first itteration of the for loop. Last night it ran for about 2 hours before crashing, the night before it was about 6 hours.

When you stop debugging, the MTTY output shows a Faulted PC value that points to Ethernet.cpp as show in the previous post.

I have checked all code and can not find anything that could potentially be overwriting memory.

I have disable the call to DAQConnect sending to see if this is the cause of the crash.

[tod]

First let me put on my broken record (and this isn't directed directly at Dave)
sprintf and all its relations are type unsafe. Why not just use the much safer ostringstream? In your example if SensorData[x].Calculated is not a float it will cause a crash, if you overflow DispBuffer it will cause a crash. Using the c++ libs instead of the old c libs will ALWAYS avoid both of these potential crashes. Maybe someone from NetBurner will chime in here, but I can't see any reason not to use the more modern (yet tested over 20 years) versions from the C++ lib. See the wiki article on moving from C to C++ and for this topic scroll down to the sprintf is to misery as ostringstream is to happiness section


OK now that I have that out of my system. The interesting thing you said was that one system works and one doesn't and both have the same source code. I remember this issue coming up with someone else and they eventually yielded the vital piece of information that while the source code was the same it had been compiled on different development machines. Is this possibly the case with you as well?

The reason (in their case) that this was relevant was because the machine that was causing the crash had an older version of the NNDK installed. One of the versions in the recent past had a re-entrancy bug with floating point io operations. Unfortunately (despite my mini-rant above) it affects both the C and C++ versions of the library.

[v8dave]

Hi Tod,

I am, I am... Is just taking time to redo and learn not to use the old ways and your Wiki is most helpful. A lot of this code was ported from an older project running on the Rabbit so is generally all C code.

My comment on one system working was false. Afer a few hours of posting on here the system crashed with the same Faulted PC location.

The SensorData[x].Calculated is indeed a float so this is OK. The strange thing is that looking at the code when this crash happens, the loop has just started and the index is ZERO and the DispBuffer has not even been written to at this point. It still contains garbage from the stack.

I have disable today the calls to send the data over GPRS to the server via the DAQConnect calls. It has been running now for over 15 hours and no crashing. I suspect the DAQ connect libraries are the issue here and maybe that sprintf is not type safe or at least not thread safe although there is what appears to be a lock on balloc.

I'll start by re-writing a lot of the code to use the newer type safe libraries for my string handling and see if this improves things.

The issue I have is the DAQConnect library is supplied as compiled only and no source and it appears to be using sprintf. I am wondering if this is re-entrant? The lock on balloc would suggest so.

One quick question for you seeing as you are quite able with this new C++ way!!! )

How do you do formatting in strings in much the same way as sprintf() etc does. I couldn't see that in your code on the WiKi. I need to print in fixed formats to the LCD. The function call expects a fixed length string to print the LED digits.

Dave...
PS... Keep nagging us about it. It is the only way we will change our stubborn ways!!

[tod]

Dave,
Glad you're making the attempt. Even though I didn't mention it in my post, the trap information about where a fault occurs is only useful sometimes. Certain bugs (notably buffer overruns and re-entrancy issues) tend to cause a crash sometime after the offending code. Make sure you are not using the NNDK RC7a release. It had a known reentrancy problem with floating point IO.

The Wiki article talked a little about io format specifiers in previous paragraph on using cout instead of printf. I orignally gave just an example on how to do two fixed decimal places. I updated it with more examples. To save you the trip I'm attaching a screen shot of the new example code.

[v8dave]

Thanks Tod,

I am away on business on Monday for a few days and to pass the time in the evenings, I am going to re-write a lot of the code over to C++ ostreamlib as you suggested. I won't be able to test until I get back but at least I can write and compile it.

I am hoping that this will make the code more bullet proof. About time anyway that I started using C++ properly. )

Dave...