On Fri, Jan 25, 2019 at 5:27 AM Tom de Vries <tdevr...@suse.de> wrote: > > On 25-01-19 14:17, Tom de Vries wrote: > > On 25-01-19 01:51, Ian Lance Taylor wrote: > >> On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell <nat...@acm.org> wrote: > >>> > >>> I just tripped over a segfault in libbacktrace. We apply strrchr to a > >>> possibly NULL filename, with predictable results when it is. > >>> > >>> elf.c:3044 passes NULL as the filename parm: > >>> ret = elf_add (state, NULL, d, base_address, error_callback, > >>> data, > >>> fileline_fn, found_sym, found_dwarf, NULL, 0, 1, > >>> NULL, > >>> 0); > >>> > >>> This gets to elf_open_debugfile_by_debuglink which passes it on through: > >>> ddescriptor = elf_find_debugfile_by_debuglink (state, filename, > >>> debuglink_name, > >>> error_callback, data); > >>> > >>> this patch avoids the strrchr when filename is null. I reordered the > >>> way prefix & prefix len got set, finding it prefereable to: > >>> slash = filename ? NULL : strrchr (filename, '/'); > >>> but if you prefer to avoid the assignment in the conditional I'm fine > >>> with that too. > >> > >> Yeah, please don't do an assignment in a conditional. > >> > >> Why don't we just pass "" instead of NULL in the call to elf_add? If > >> that works, that is OK. > >> > > > > With this refactoring preamble ... > > ... I can more easily add a test-case btest_dwz_gnudebuglink, which > triggers a segfault due to strrchr being called with a NULL string. > > This patch fixes it by passing "" instead of NULL, in the call to > elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at > line 3044 (for .gnu_debuglink) mentioned above. > > Nathan, does this fix the problem for you? If not, can you provide a > reproducer, or give a hint on how one could be constructed?
This is OK. s/Call/call/ in the ChangeLog entry. Thanks. Ian
