Re: dbghelp: fix debuglink crash, accessing memory after munmap

[Eric Pouech]

Peter Oberndorfer a écrit :
> Winedbg would crash on my system when trying to set a breakpoint (loading the debug info from a .debug file)
> The problem is that hash_table_elt adds the symbols of the .debug file to the hashtable of the parent file.
> But at the time elf_new_public_symbols is run, the sections of the .debug file are already unmapped.
> In addition to that the symbols in .debug would be added 2 times (.so and .debug file)
>
> Changelog:
> dbghelp: fix debuglink crash, accessing memory after munmap

I don't think it's the right fix
IMO, we shouldn't call elf_new_public_symbols while processing the 
.gnu_link target, but in the parent call to elf_load_debug_from_map
can you provide more information on the crash itself (which reference is 
lost to an unmapped section)

A+

dbghelp: fix debuglink crash, accessing memory after munmap

[Peter Oberndorfer]

On Sunday 21 January 2007 16:25, Eric Pouech wrote:
> Peter Oberndorfer a écrit :
> > Winedbg would crash on my system when trying to set a breakpoint (loading the debug info from a .debug file)
> > The problem is that hash_table_elt adds the symbols of the .debug file to the hashtable of the parent file.
> > But at the time elf_new_public_symbols is run, the sections of the .debug file are already unmapped.
> > In addition to that the symbols in .debug would be added 2 times (.so and .debug file)
> >
> > Changelog:
> > dbghelp: fix debuglink crash, accessing memory after munmap
>
> I don't think it's the right fix
> IMO, we shouldn't call elf_new_public_symbols while processing the 
> .gnu_link target, but in the parent call to elf_load_debug_from_map
> can you provide more information on the crash itself (which reference is 
> lost to an unmapped section)
> The crash happens at elf_new_public_symbols while executing ELF32_ST_TYPE(ste->symp->st_info) == STT_FUNC
> ste->symp points to the unmapped section.
> But ste->symp->st_size and ste->symp->st_value will probably also produce problems...
> Also the comment in elf_hash_symtab says:

* as we added in the ht_symtab pointers to the symbols themselves,
     * we cannot unmap yet the sections, it will be done when we're over
     * with this ELF file

Wouldn't moving the elf_new_public_symbols also create the need to unmap sections from parent call?
Do you want to unmap both files in one go?
> A+

Greetings Peter

PS: If it matters i have gcc4.1.1 and .debug links for most of my system libraries