• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category User Interface → Themes
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by kcrimson - 2008-12-13
Last edited by Unhelpful - 2008-12-14

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

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

Closed by  Unhelpful
2008-12-14 20:33
Reason for closing:  Fixed
Additional comments about closing:  

Works on my e200.

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.

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)

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.

idak commented on 2008-12-14 13:28

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”(130×130) on cabbiev2 wps (120×120)
(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 (+0×174)
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 ; 0×0 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 ; 0×0

Free-State is the following.;

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.


Available keyboard shortcuts


Task Details

Task Editing