Marcus Meissner a écrit :
On Sun, Feb 18, 2007 at 01:40:12PM +0100, Eric Pouech wrote:
Marcus Meissner a écrit :
dlls/dbghelp/dwarf.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c index 4f74b6a..f51a948 100644 --- a/dlls/dbghelp/dwarf.c +++ b/dlls/dbghelp/dwarf.c @@ -1203,7 +1203,7 @@ static void dwarf2_parse_enumerator(dwar
TRACE("%s, for %s\n", dwarf2_debug_ctx(ctx), dwarf2_debug_di(di));
- if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) name.u.string
= NULL;
- if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) return; if (!dwarf2_find_attribute(ctx, di, DW_AT_const_value, &value)) value.u.svalue = 0; symt_add_enum_element(ctx->module, parent, name.u.string, value.u.svalue);
Hi Marcus,
can you send me the ELF file(s) which is/are causing this?
There is no ELF file.
Coverity spotted this as error, since name.u.string can be NULL in the flow and symt_add_enum_element() would crash in pool_strdup.
It is CID 461. 462 and 463 are related issues.
Ciao, Marcus
the point is that the code paths you're trying to fix would only be taken in case of corrupt ELF file (those attributes are mandatory in the dwarf specs) the proposed fix is not correct as we'll still have NULL references (to the objects for enumerators and variables you don't create) and this will crash later on so, I'd rather fix the symbol.c file by allowing to have NULL names for those objects, this will less likely lead to a crash A+