Re: [Magiclantern-devel] oustanding stability issues

[Nicholas H. <nic...@er...>]

Joshua,

1) The most likely cause of problems in the callback would generally be 
incorrect use of globals or cross section calls.  In a regular compile I 
don't think you'll see much of that, but something may have slipped through.  
If you compile with TML_DEBUG the call to TRACE could end up crashing it (If 
it uses any globals in turn or is compiled into another section).  However my 
saving/restoring of R10 should hopefully get around the global problems in 
the purearm version.

The other possible problem in the callback is in my implementation of mutexes.  
If you look in the sourcecode in main/mutex.* then you'll see that my wait 
loops contain a call to SysTaskDelay which fixed some crashing problems on my 
Tungsten E (when I did the original m68k version at least, I haven't touched 
that code in purearm).  Feel free to find a better way of mutual exclusion, 
or just fiddle with the code I've got there.

I know that turning on tracing generally slows down the system a little or a 
lot and can thus give rise to extra problems that you don't normally see.

There could be other problems in the callback, but given the number of asserts 
and checks and the small overall size there shouldn't be many other causes of 
crashes.  I suppose there could be other synchronisation issues though.


2) For testing the format handling code you should find it much easier in the 
purearm version.  Since I've centralised all the ARM/m68k glue functions I 
was able to provide a test harness to compile all the backend code natively 
on your local computer where your have full access to normal debugging tools.

Using the debugger as well as other tools such as valgrind I was able to track 
down some memory leaks and such.  If you think the buffer overrun is within 
the backend code, then this is a good way to test it.  If the problem is 
elsewhere then good luck :P

However I haven't had many problems with the avi parsing code itself for a 
while (at least not when it used to be built for m68k).  But if there's 
buffer problems elsewhere then anything could happen.

Obviously you'll want to narrow down which codecs/formats are causing the 
problems.  You should still be able to play a raw PCM/RGB avi file, an avi 
file with no sound, and (maybe) an avi with only sound.  These should help 
narrow down which case is causing the problem.  I know OGG files are still 
majorly broken - they only work if they're mono - stereo files produce random 
noise and crashes.


3) The code under glue is something I wrote entirely myself for this project.  
It does seem to be working reasonably well at the moment, but there could be 
subtle bugs remaining in it.  I did find out after the fact that I got some 
of the type definition summaries wrong, so there could be some more things 
wrong along those lines.  If you prefer you could look at what other 
open-source code is available to provide palm APIs from ARM, I must admit I 
didn't really look much before writing my own.


Nicholas


On Thursday 30 June 2005 11:41, Joshua P. Luben wrote:
> I've spent much of the last week trying to track down instability-causing
> bugs. I think I've found at least two areas that are causing problems.
> Because I'm new here, I seek any collective knowledge that you may have in
> further locating these problem areas and solving them.
>
> 1. Sound streaming callback from Palm OS seems to intermittently crash
> on Tungstens. I have an E2 and I would say it crashes within the callback
> about 50% of the time.
> 2. I think there is an AVI parsing bug, this might be coupled with what
> looks like a buffer overrun problem that is corrupting memory.
>
>
>
> Any ideas?