|
From: Florian K. <br...@ac...> - 2011-05-15 17:03:10
Attachments:
r11750-static-analysis
|
Greetings.
Attached are the results from a new run of IBM's BEAM checker.
As many complaints have been addressed already I'm including
some more.
(1) Complaints about constant conditions
In practice they are often harmless and identify code that
contains an unneeded computation. Something that could be
cleaned up perhaps. But sometimes (VEX r2141) it does find
a nugget. I'd like to find out whether people are interested
seeing these complaints.
(2) Complaints about missing breaks
We get quite a few of those but most of them are intended.
I'm including some here that I think deserve a look from
somebody who understands the code (syswrap-linux.c).
The breakdown is
coregrind 12
callgrind 2
cachegrind 2
memcheck 2
As always, let me know if a complaint is harmless and I will
suppress it in future reports.
Cheers, Florian
|
|
From: Philippe W. <phi...@sk...> - 2011-05-16 04:33:29
|
> memcheck 2 >-- ERROR23(heap_memory) /*memory leak*/ >>>ERROR23_print_results_f0341fd3ea33b83 > "memcheck/mc_leakcheck.c", line 925: memory leak > ONE POSSIBLE PATH LEADING TO THE ERROR: > "memcheck/mc_leakcheck.c", line 819: allocating using `vgPlain_malloc' (this memory will not be freed) > "memcheck/mc_leakcheck.c", line 819: assigning into `lr_array' ... > "memcheck/mc_leakcheck.c", line 925: deallocating `lr_array' because exiting its scope (losing last pointer to the memory) Note that I think that the memory leak of the lr_array is solved by the patch in comment 83 "implement delta leak reporting" of the gdbsrv bug 214909. I think the lr_table leak in this function is also leaked (and fixed by the patch) Maybe you could look to see if BEAM could detect the lr_table leak ? Philippe |
|
From: Florian K. <br...@ac...> - 2011-05-17 20:28:33
|
On 05/16/2011 12:33 AM, Philippe Waroquiers wrote: > > Note that I think that the memory leak of the lr_array is solved by > the patch in comment 83 "implement delta leak reporting" of the > gdbsrv bug 214909. > I think the lr_table leak in this function is also leaked (and fixed by > the patch) > > Maybe you could look to see if BEAM could detect the lr_table leak ? > Yeah, I think that should be doable. Florian |