FS#12743 - 'Data Abort' on USB connection

Attached to Project: Rockbox
Opened by Giles (gilesn) - Wednesday, 29 August 2012, 12:41 GMT
Last edited by Thomas Martitz (kugel.) - Tuesday, 11 September 2012, 04:43 GMT
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System iPod 5G
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Build 16335da-120826 and earlier

On USB connection to mac or linux I get 'data abort' with the message below (sp number varies). This happens from off or on, playing or idle. Forcing a reboot then clearing settings seems to fix it. After this the USB connection works as normal, after estore my settings it starts happening again. Some settings I've changed are load to RAM Yes, AutoUpdate:Yes, Gather runtime data:Yes. Any other settings that might cause this?

Data abort at 00009E34 (0)
bt pc: 00009E34, sp: 000D6980
A: 0004F3F0
bt end
This task depends upon

Closed by  Thomas Martitz (kugel.)
Tuesday, 11 September 2012, 04:43 GMT
Reason for closing:  Fixed
Additional comments about closing:  b985d5c
Comment by Michael Carr (Strife89) - Thursday, 30 August 2012, 21:15 GMT
This issue has occurred with my Sansa c250 as well, though with a slightly different error message. Suspecting Clip+ issues, too, though unconfirmed.

Build: 16335da-180826

Error message:
Data abort at 000092C4
bt pc: 000092C4, sp: 0
A: 0004CA8C
bt end

Attached file is a report I wrote up Aug. 29, in a vain attempt to reproduce. It has a paste of my settings.
Comment by Dominik Riebeling (bluebrother) - Thursday, 30 August 2012, 21:17 GMT
I've experienced a similar issue on mini2g as well. Haven't written down the exact panic screen message.
Comment by Dominik Riebeling (bluebrother) - Monday, 03 September 2012, 21:25 GMT
Tried a few devices with current build (1e8eb47)

sa9200: crash. Unfortunately the output is only partially readable
Data abort at 000090c?
bt pc: 000090c4, sp: ?
a: 00045a94
show files: all

h10_5gb: no crash, but shows an "error accessing playlist file" (playback was stopped before plugging USB)
usb keypad mode: mouse

gigabeats: no crash, but shows an "error accessing playlist file" (playback was stopped before plugging USB)
volume: -12
show files: all

e200: no crash
volume: -32
default codepage: cp1252

data abort at 00097ec
bt pc: 000097ec, sp: 40(cut off here, might be longer)
a: 0004431c

volume: -19
contrast: 39
backlight timeout: 5
battery capacity: 600
backlight fade out: 5000
scroll speed: 7
bidir limit: 0
scroll step: 2
volume fade: off
follow playlist: on
playlist viewer indices: off
talk dir clip: on
talk file clip: on
beep: weak
crossfade: man track skip
eq band 0 gain: 10
eq band 2 gain: 20
eq band 3 gain: 45
eq band 4 gain: 15
warn when erasing dynamic playlist: off
pause on headphone unplug: pause and resume
lang: /.rockbox/langs/english.lng
start in screen: files
keyclick repeats: on
qs top: follow playlist
qs bottom: follow playlist
usb hid: off

After resetting the settings the mini2g doesn't crash anymore. Interestingly still no crash if I load the old settings and then connect USB. Reboot and I get the crash again.
Comment by Stephane Moutard-Martin (Steak) - Tuesday, 04 September 2012, 08:01 GMT
sansa clip+ with RELEASE 3.11.2
message pointed out by other users "error accessing playlist file" (& playback was stopped before plugging USB), may be irrelevant : I get it with RELEASE 3.11.2 and it does not seem (so far) to affect/corrupt the playlists.
I shall try current build & add a comment if anything happens
Comment by Stephane Moutard-Martin (Steak) - Tuesday, 04 September 2012, 08:34 GMT
sansa clip+ 072bade-120904

I get a slightly different message "error accessing playlist file, control files"
No settings were applied (see config01.cfg backup)
I noticed an odd parameter in build initial settings = "playlist catalog directory: //Playlists". Changing it to "/Playlist" did not fix anything though.
Playlists were actually unaffected
Comment by Dominik Riebeling (bluebrother) - Tuesday, 04 September 2012, 18:01 GMT
Bisecting on sa9200 blamed the following commit: 8bbd4d91a0d7a2933b3bec4cb74da50016e8dd1e

Reverting the commit fixes the issue but I haven't checked if this causes other problems (especially with voice since the commit message indicates the change to be voice related)
Comment by Dominik Riebeling (bluebrother) - Tuesday, 04 September 2012, 18:16 GMT
reverted 8bbd4d91a0d7a2933b3bec4cb74da50016e8dd1e on top of current HEAD (1e8eb4752b679469b7f830c4ed97a1da1e607bad) and tried again:

mini2g: playback of vorbis, mp4 and mp3 works, voice and talk clips too. After unplugging USB voice speaks "loading" and I can see a splash for a fraction of the second (too fast to read it, not sure if that's been there before).

h10_5gb: no crash but still the "error accessing playback control file" message so that seems to be unrelated.
Comment by Thomas Martitz (kugel.) - Wednesday, 05 September 2012, 05:35 GMT
Interesting. If the memcpy() call that was added is the offender it could point to a buffer overlap or somesuch.
Comment by Marcin Bukat (MarcinBukat) - Wednesday, 05 September 2012, 10:19 GMT
You mean memset(), right? I don't see how this call could break - it looks reasonably ok to zero buffer obtained from
voice_buf_hid = core_alloc_ex("voice buf", sizeof (*voice_buf), &ops);
voice_buf = core_get_data(voice_buf_hid);
memset(voice_buf, 0, sizeof (*voice_buf));
Comment by Dominik Riebeling (bluebrother) - Monday, 10 September 2012, 20:42 GMT
The following change has been suggested by kugel on IRC and fixes the issue for me on sa9200 and mini2g.

diff --git a/apps/voice_thread.c b/apps/voice_thread.c
index 87e4eee..e8c7fcc 100644
--- a/apps/voice_thread.c
+++ b/apps/voice_thread.c
@@ -335,6 +335,7 @@ static void voice_data_init(struct voice_thread_data *td)

mixer_channel_set_amplitude(PCM_MIXER_CHAN_VOICE, MIX_AMP_UNITY);
voice_buf->td = td;
+ td->dst = NULL;

/* Voice thread message processing */