<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - Android: NULL pointer dereference with i965 mesa-dev, seems build_id_length related"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=104642#c4">Comment # 4</a>
              on <a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - Android: NULL pointer dereference with i965 mesa-dev, seems build_id_length related"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=104642">bug 104642</a>
              from <span class="vcard"><a class="email" href="mailto:lemody@gmail.com" title="Tapani Pälli <lemody@gmail.com>"> <span class="fn">Tapani Pälli</span></a>
</span></b>
        <pre>(In reply to Mauro Rossi from <a href="show_bug.cgi?id=104642#c3">comment #3</a>)
<span class="quote">> 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?</span >

As far as I know, no.

<span class="quote">> 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?</span >

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.

<span class="quote">> In any case, I think code should also be robust to unconformant libraries
> and should not crash.</span >

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.

<span class="quote">> 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"?</span >

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


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>