Mailing List Archive

nessus on AMD64
OK, I am making a little progress. I got hold of the dmalloc package for
debugging memory (allocation) problems. BTW, has anyone tried using dmalloc
with nessus?

1. When I run nessusd in the i386 system with the dmalloc "dmallocth"
library, i get lots of information (boy is it slow processing) about a large
number of relatively small memory areas which were allocated but never freed
(small is around 25 bytes). However, nessusd does work properly. Now when I
say large I mean around 29,000. I plan to look into this by maodifying
nessusd to more tightly couple with dmalloc so that I can see where stuff is
being allocated.

2. I finally managed to hack dmalloc/nessud so that I could use dmalloc. I
never get far enough to see if there are a large number of small unfreed
chunks of memory. Instead, dmalloc starts complaining that it is unable to
extend the heap. Now on the x86_64 pointers are 8 bytes rather than four and
thus the sizes of some allocated memeory may be much larger and fill the
heap. I am going to try and change some of the malloc parameters to get what
happens to change.

3. BTW, can someone explain why, when I run nessusd under a debugger such as
gdb, it does not run many of the tests unless I select "all but dangerous"
plugins?

Gene
--
Re: nessus on AMD64 [ In reply to ]
On Wed, Jan 21, 2004 at 11:46:22AM -0500, Gene C. wrote:
> OK, I am making a little progress. I got hold of the dmalloc package for
> debugging memory (allocation) problems. BTW, has anyone tried using dmalloc
> with nessus?

Use valgrind instead. Nessus does not play well at all with dmalloc.

You still did not tell me if standalone nasl was working. If it's not,
then there's no point in debugging nessusd at this time.


-- Renaud
Re: nessus on AMD64 [ In reply to ]
On Wednesday 21 January 2004 13:26, Renaud Deraison wrote:
> You still did not tell me if standalone nasl was working. If it's not,
> then there's no point in debugging nessusd at this time.

Standalone nasl works just fine everything runs with it OK.

I am beginning to suspect some kind of bug in (dare I say it...) glibc or gcc!
If that is the case, it is going to be hell to come up with a test case to
prove my point.

I have been playing around adding printf statements in libnessus service.c and
store.c where they do the mmap. I then print the mallinfo structure. The
numbers look fine on i386 but seem to be a bit large on the amd64.

I have also been using the system monitor to look at the memory usage numbers
for the various nessusd processes such as "serving" and "testing". On the
i386 these go from about 2.4MB to a bit less than 4MB. However, on the amd64
they go up to around 6MB and this is with lots of messages about being unable
to allocate memory.

So I tried using mallopt in nessusd.c to set the M_MMAP_THRESHOLD to a very
low number (64). Memory usage quickly grows to about 125MB but a lot (not
all) of the memory allocation error messages go away. If I set the threshold
to about 1024, then the mmap file mapping errors go away.

Running the low threshold on the i386 seems to have little effect in that
memory usage stays below 4MB.

While pointer size increases from 4 bytes to 8 bytes, that does not explain
this kind of behavior.

I will take a look at valgrind to see if it can help.
--
Gene
Re: nessus on AMD64 [ In reply to ]
On Wednesday 21 January 2004 13:26, Renaud Deraison wrote:
> Use valgrind instead.

valgrind is x86 specific ... don't have time to do a redevelopment on amd64.

Nessus does not play well at all with dmalloc.

It does not play badly either ... the biggest problem is the lack of info from
the sub-processes. In addition, you are correct in that it does not play
well at all with libnessus or libnasl.
--
Gene