[procps] Re: Final call for procps 3.3.4
- From: Jim Warner <james.warner@xxxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Sat, 27 Oct 2012 14:12:08 -0500
On Oct 26, 2012, at 3:24 PM, Sami Kerola <kerolasa@xxxxxx> wrote:
> Ooops. The libraryy change was bad, it mad top to die. I removed this:
>
> It seems the src and dst buffers either double freed or corrupted. My
> guess is that the later happens, but I am not sure where and why. Oh
> well, the whole library is such mess that it might not make sense to
> think too much what is wrong in that. Correct thing seems to be to
> nuke the library from orbit, and write replacement.
Hi Sami,
The reason your patch didn't work is because you were missing the following
after the free calls you inserted:
src_buffer = dst_buffer = NULL;
Unfortunately, if that had been present you would have added 2-4% more overhead
to the top program. It's bad enough that the PROCTAB is receated with each top
iteration, but why make things worse with the release and reacquisition of an
additional 300k bytes of storage.
Such storage is freed at task end and isn't treated by valgrind as a leak. But
if you wanted to exclude it from the valgrind heap summary "in use at exit"
category, an approach like this would do the trick:
#define MAX_BUFSZ 1024*64*2
static char src_buffer[MAX_BUFSZ],
dst_buffer[MAX_BUFSZ];
Lastly, I wish you wouldn't be so critical of the library. It was never
desgined to be other than internal to the procps programs. And while now
outdated, I think it has served those programs pretty well for over a decade.
Personally, I still appreciate Albert's initial library efforts.
Regards,
Jim
Other related posts: