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