Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#9631 : Since Resize added to current build, certain themes crash



FS#9631 - Since Resize added to current build, certain themes crash

Attached to Project: Rockbox
Opened by Mitch (kcrimson) - Saturday, 13 December 2008, 20:48 GMT
Last edited by Andrew Mahone (Unhelpful) - Sunday, 14 December 2008, 20:33 GMT
Task Type Bugs
Category Themes
Status Closed
Assigned To No-one
Operating System Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


It seems that the current builds now include album art resizing, and most themes seem to behave just fine using it. Free-State however crashes on me when loading certain album art. I'm getting a freeze (background is intact with no text) when switching to certain albums (certain bmps), and when switching themes to Free-State while playing those albums, I get the following error: Data abort at 000320B8 (0)
Free-State is not the ONLY theme I've noticed this behavior in, but its the one I'd miss most if this isn't fixed. I'll add to this thread more information as I explore further and identify which themes exhibit similar behavior since the resize feature was added.
My non-programmer-based-suspicion is that since its only occurring while loading certain albums, that those bmp's are too large to properly resize, or the resizing doesn't fit into the alloted area given it in the .wps
This task depends upon

Closed by  Andrew Mahone (Unhelpful)
Sunday, 14 December 2008, 20:33 GMT
Reason for closing:  Fixed
Additional comments about closing:  Works on my e200.
Comment by Andrew Mahone (Unhelpful) - Sunday, 14 December 2008, 01:22 GMT
If you know which album art in particular was giving you trouble, or at least what was in the playlist when the crash occurred, and if you could attach it here or upload it somewhere, that would be a big help. Most problems I've seen so far have turned out to be related to the relative sizes of the WPS AA tag and the source bitmap - a few cases where things can go wrong have shown up since scaling was committed.
Comment by Mitch (kcrimson) - Sunday, 14 December 2008, 04:32 GMT
I'm attaching the .bmp from an album that I know exhibited the problems I mentioned. I'll have to wait until I have some time to document my usage to provide more information.
   cover.bmp (33.1 KiB)
Comment by Richard (tenson) - Sunday, 14 December 2008, 04:46 GMT
Surfi from Anythingbutipod just helped me with this exact problem. It seems that the problem lies in resizing the album art to an odd number. I fixed the problem with my theme by simply changing the resize size from 85 to 90.
Comment by Akio Idehara (idak) - Sunday, 14 December 2008, 13:28 GMT
I saw the same problem on my e200 real target.
"Data abort at 000322E8 (0)"

Steps to reproduce
(1) play with the attached "cover.bmp"(130x130) on cabbiev2 wps (120x120)
(2) select Free-State wps (%Cl|7|138|c75|c75|)
(3) can't change wps and abort...

and this problem does not occur on e200 sim.
#I also saw the same problem on my ipod video real target.
#but the problem does not occur on ipod video sim.
#Something arm related issue?

So, I dumped my e200 binary with nm and objdump.
Please see the following info.

$ arm-elf-nm rockbox.elf | sort
000320b0 T unload_wps_backdrop
000320c4 T show_main_backdrop
000320f8 T show_wps_backdrop
00032134 t scale_h_area_setup
00032174 t scale_h_area <<< maybe this func (+0x174)
00032434 t scale_v_area
00032720 t scale_h_linear_setup

$ arm-elf-objdump -SDlr app/recorder/resize.o
00000040 <scale_h_area>:

/* horizontal area average scaler */
static bool scale_h_area(struct bitmap *bm, struct dim *src,
struct uint32_rgb *out_line,
struct scaler_context *ctx, bool accum)
40: e92d4ff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
44: e24dd028 sub sp, sp, #40 ; 0x28
48: e1a09000 mov r9, r0
4c: e58d1008 str r1, [sp, #8]
50: e58d2004 str r2, [sp, #4]
54: e1a06003 mov r6, r3
58: e5dd104c ldrb r1, [sp, #76]
5c: e58d1000 str r1, [sp]


rgbvalacc.g += rgbvaltmp.g * mul;
18c: e1a0e00b mov lr, fp
190: e02e8e90 mla lr, r0, lr, r8
rgbvalacc.b += rgbvaltmp.b * mul;
194: e1a0800c mov r8, ip
198: e0284890 mla r8, r0, r8, r4
/* round, divide, and either store or accumulate to output row */
out_line[ox].r = (accum ? out_line[ox].r : 0) +
19c: e59da00c ldr sl, [sp, #12]
1a0: e08a308a add r3, sl, sl, lsl #1
1a4: e59db004 ldr fp, [sp, #4]
1a8: e08b1103 add r1, fp, r3, lsl #2
1ac: e59dc000 ldr ip, [sp]
1b0: e35c0000 cmp ip, #0 ; 0x0
1b4: 1591c000 ldrne ip, [r1] <<<<< here?
1b8: e5963004 ldr r3, [r6, #4]
1bc: e0823003 add r3, r2, r3
1c0: e5962000 ldr r2, [r6]
1c4: e08ba293 umull sl, fp, r3, r2
1c8: e08c300b add r3, ip, fp
1cc: e5813000 str r3, [r1]
((rgbvalacc.r + ctx->round) *
(uint64_t)ctx->divmul >> 32);
out_line[ox].g = (accum ? out_line[ox].g : 0) +
1d0: e59db000 ldr fp, [sp]
1d4: e35b0000 cmp fp, #0 ; 0x0
Free-State is the following.;

Comment by Andrew Mahone (Unhelpful) - Sunday, 14 December 2008, 18:15 GMT
Akio: thanks for finding it. The load is guaranteed to be unaligned if both dimensions of the output size are odd, I've added an align_buffer to fix it. Should work as of r19439.