Re: [png-mng-implement] gcc-4.5.3/arm vs png

[John B. <joh...@gm...>]

​It's an iCCP chunk.  The call to png_icc_set_sRGB is misleading:

 #4 0x20304a7c in __gesf2 () from /usr/lib/libc.so.12
 #5 0x228a13fc in png_chunk_warning () from /usr/pkg/lib/libpng16.so.16
 #6 0x228a027c in png_icc_set_sRGB () from /usr/pkg/lib/libpng16.so.16
 #7 0x228b1950 in png_handle_iCCP () from /usr/pkg/lib/libpng16.so.16
 #8 0x228a3b34 in png_push_read_chunk () from /usr/pkg/lib/libpng16.so.16
It's actually png_compare_ICC_profile_with_sRGB (I believe) and the
compiler has folded that function into the one reported on the backtrace.
png_compare_ICC_profile_with_sRGB calls png_chunk_report in two places and
png_benign_error in one place and both calls can be trivially optimized by
the compiler so that the calls they make to png_chunk_warning are done via
a branch, not a call (tail call elimination.)

I guess it's possible that the push reader might be leaving
png_ptr->chunk_name unset, or set to garbage, which would trigger the
maximum prefix length (18 characters) and so might expose a buffer
overflow, but the three calls to png_chunk_warning all have warning
messages that are much shorter than 196 characters so that seems unlikely.

It seems more likely that something in the tail call elimination in 4.5.3
is making the png_chunk_warning call end up with bogus parameters.  The
obvious this is to check with a breakpoint at the function entry (there is
probably only one call to png_chunk_warning, so this should be relatively
easy) and examine A0 and A1, A1 should be the pointer to the error message,
A0 should be a pointer to a png_struct, while that is a lot more difficult
to recognize it should be the same pointer that ruby originally created
with png_create_read_struct.

I'm assuming the call to _gesf2 is bogus; probably the nearest extern
function.  _gesf2 is a software implementation of floating point compare,
so I guess knowing the -mfpu option might be useful and it would probably
be good to known what was really on the call stack (I think it's the libc
signal handler.)

John Bowler <jb...@ac...>