<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <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#c3">Comment # 3</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 <a class="email" href="mailto:issor.oruam@gmail.com" title="Mauro Rossi <issor.oruam@gmail.com>"> Mauro Rossi</a> <pre>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? 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? In any case, I think code should also be robust to unconformant libraries and should not crash. 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"? Mauro</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>