Rockbox

Tasklist

FS#6409 - Crash when stopping recording

Attached to Project: Rockbox
Opened by Peter D'Hoye (petur) - Sunday, 03 December 2006, 18:56 GMT
Task Type Bugs
Category Recording
Status Closed
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Had a crash at the end of a recording.
After recording almost 100 minutes I pressed stop and after a short pauze it gave me (if I remember correctly) I04 at 00000002. It turned out it had saved the file ok, including the header, so no problem there.
Could be I pressed stop more than once but I'm _unable_ to reproduce.
This task depends upon

Closed by  Peter D'Hoye (petur)
Monday, 26 February 2007, 23:52 GMT
Reason for closing:  Fixed
Additional comments about closing:  Seems to have been fixed by the recent changes
Comment by Peter D'Hoye (petur) - Friday, 08 December 2006, 18:06 GMT
Still not solved in CVS 2006-12-08 (around 1:00)

Last attempt during recording, after a mere 10 seconds pressing stop and again stop during flushing made my h340 require help from a paperclip :(

At this moment recording doesn't even want to start again :(
Comment by Peter D'Hoye (petur) - Friday, 08 December 2006, 18:13 GMT
just found a way to make it freeze:

from the rec screen:
- pres rec to start recording
- press stop
- press rec again while still flushing
*bingo*
Comment by Peter D'Hoye (petur) - Saturday, 09 December 2006, 16:54 GMT
dang - not reproducable anymore :( - now it just ends up not updating the screen the way it should but still respond to start/stop

also, a logf build works the way it should, so I *really* think we're looking at a timing/race condition here....
Comment by Michael Sevakis (MikeS) - Saturday, 09 December 2006, 23:35 GMT
I just plain can't get it to do it in either way (never could on x5 either when mashing buttons). As far as a race condition, that shouldn't be possible at all. The next command should wait for the stop to finish and the second (stop/pause/etc.) rejected because it's already stopped. I'll metion here again that the screen should freeze momentarily on the second press but should start updating again once the stop is finished. The pcmrec thread *always* receives the messages and incorrect commands are filtered by pcmrec after dequeue. The posting thread just waits for processing.

Some things are repeated here from the forum response just for the record. :)

Will keep thinking hard and may see ways to simplify things.

Loading...