[Pixman] SIGBUS in pixman_composite_src_0565_0565_asm_neon

[Siarhei Siamashka]

On Tue, Jan 31, 2012 at 3:44 PM,  <hubert-b at gmx.de> wrote:
>> The argument values may be reported incorrectly at this place in the
>> backtrace (src_bpp=17 is definitely wrong), so it's hard to make any
>> conclusions.
>
> I also spotted this and after reading the relevant code parts from
> the stack trace bottom to top and I must say that I don't have a
> glue why the src_bpp could suddenly changed from 16 to 17.

It's just that the value 17 happens to be in a couple of registers at
the time of the fault. And gdb mistakenly associates these registers
with the argument values for the function calls upper in the
backtrace, probably because it has no clue about what the assembly
code is doing. Nothing to be worried about, just gdb is not perfect
and is trying to make guesses which are wrong in this case.

>> But it's a good idea to check if the buffers are 4 bytes
>> aligned and strides are 4 bytes aligned too. Strides are a bit
>> confusing, because in some places of code they are measured in bytes,
>> in some places of code in pixels and in some places in uint32_t sized
>> units. Violating alignment requirements may result in a SIGBUS.
>
> Could you aid me with that? Honestly, I'm a little bit lost here because GDB is actually reporting an "error" on line 692 of pixman-arm-neon-asm.h but this is the closing "*/" of a comment (in the "generate_composite_function" macro).
>
>> It usually also helps to get the output of "info registers" and
>> "disassemble" gdb commands.
>
> I did another shot, output is attached as plain-text file as it is a lot of content... I hope mailman keeps the file and doesn't copy it line-by-line into this mail.

Thanks for the log. The "Unhandled fault: imprecise external abort
(0x1c06) at 0x404bce10" message can be decoded using the information
from:
    http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Bgbiaghh.html
For imprecise aborts, only bits [3:0] of DFSR (0x1c06) are valid and
they can be decoded as "b000110 access flag fault, page". The
0x404bce10 address related to r4 register and used for reading data is
most likely misleading. The actual problem seems to be caused by
writing data to the memory address stored in r2 register (0x1d02010),
which is suspiciously very close to the start of the page. You can
inspect the data in memory at various addresses in gdb using "x"
command, for example "x/16x 0x1d02000". I guess the framebuffer is
just not mapped right, or the code just tries to write data at the end
of the framebuffer and fails when accessing the next unmapped page.

-- 
Best regards,
Siarhei Siamashka