[Bug 104642] Android: NULL pointer dereference with i965 mesa-dev, seems build_id_length related

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=104642

--- Comment #4 from Tapani Pälli <lemody at gmail.com> ---
(In reply to Mauro Rossi from comment #3)
> Hi Tapani,
> 
> Thanks a lot for sharing the workaround
> 
> It seams a regression introduced by 5c98d3825ccbed9054a1bb2de607116b2b31d48b
> "util: Query build-id by symbol address, not library name".
> Is Chad Versace already having a look?

As far as I know, no.

> In the former coding of build_id_find_nhdr_callback() there was a comment:
> 
> -   /* The first object visited by callback is the main program.
> -    * Android's libc returns a NULL pointer for the first executable.
> -    */
> -   if (info->dlpi_name == NULL)
> -      return 0;
> 
> and NULL was checked; does last return 0 mean that nothing was done for
> Android, if Android libc returns systematically NULL?

This callback gets called for binary itself + libraries. This NULL check is not
needed anymore since address check is better guard (if it worked ..). It works
fine on desktop, both 32bit and 64bit. On Android it also works fine on 64bit.

> In any case, I think code should also be robust to unconformant libraries
> and should not crash.

Agreed, but if it's a linker bug I think then we want to get it fixed in bionic
as well. Let's try to avoid duct-taping if possible.

> Just a question for my knowledge, where does the add '0x8000' to dlpi_addr
> during comparison on 32bit comes from, is it due to some "Android thing"?

That seems to be the amount of offset there is so that comparison will work. I
haven't figured out why this is.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20180116/ed0f7f7f/attachment.html>