Strange, Calysto should have caught the use of x(malloc|realloc). Either a bug in Calysto, or I misinterpreted the traces (I did a very sloppy job analyzing them). Thx for the feedback, I'll try to allocate more time for the analysis of the next run.
On 7/2/07, Alexandre Julliard julliard@winehq.org wrote:
"Domagoj Babic" babic.domagoj@gmail.com writes:
Possible NULL-ptr deref (vc796): @/work/benchmarks/SOURCES/wine-0.9.39/tools/makedep.c:196
- Ptr p xmalloc-ed (makedep.c:187) dereferenced. Note that although
xmalloc checks pointer (util.c:31), report(R_FATAL, "msg") does not exit, but only reports the msg and returns, so p (NULL) will be still dereferenced.
Not a bug, xmalloc does an exit(1).
*** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_winebuild_winebuild.bc
Possible NULL-ptr deref (vc5400): @/work/benchmarks/SOURCES/wine-0.9.39/tools/winebuild/import.c:108
- seems that table->names can be NULL (or unitialized) at this
line if the test @102 is false, and in the following call chain: main -> parse_options -> add_extra_ld_symbol -> add_name
Not a bug, xrealloc never returns NULL.
Possible NULL-ptr deref (vc5868): @/work/benchmarks/SOURCES/wine-0.9.39/tools/winebuild/import.c:362
- seems that ignore_symbols.names can be NULL if test @359 is true.
Not a bug, names can't be NULL if count isn't 0.
Possible NULL-ptr deref (vc1013): @/work/benchmarks/SOURCES/wine-0.9.39/tools/winegcc/utils.c:118
- starray_dup (utils.c:136) initializes dup with strarray_alloc().
strarray_alloc also sets dup->base to NULL. Then strarray_dup calls strarray_add (@142), passing it a pointer to dup. If the test in strarray_add (@113) fails, the function dereferences dup->base directly.
Not a bug, xrealloc never returns NULL.
-- Alexandre Julliard julliard@winehq.org