Date: Sun, 3 May 1998 13:51:01 +1000 From: Sue Blake <sue@welearn.com.au> To: freebsd-questions@FreeBSD.ORG Subject: Re: junk pointer, too low to make sense Message-ID: <19980503135101.41667@welearn.com.au> In-Reply-To: <85d8dw4s3l.fsf@localhost.zilker.net>; from Dave Marquardt on Sat, May 02, 1998 at 10:20:30AM -0500 References: <19980502212231.18540@welearn.com.au> <85d8dw4s3l.fsf@localhost.zilker.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 02, 1998 at 10:20:30AM -0500, Dave Marquardt wrote:
> Sue Blake <sue@welearn.com.au> writes:
> > inetd in realloc(): warning: junk pointer, too low to make sense.
> I'm pretty sure this has been discussed often in the mailing lists.
> You might search the archives.
Just in case anyone is, for some odd reason, interested in getting to the
bottom of this, here is a summary of the last year's head-scratching on
this list.
All questions reported the above error message when trying to access a
machine via ftp and/or telnet and/or rlogin. In the case of ftp the
session failed as a result. Versions of FreeBSD mentioned included
2.2.1, 2.2.2, 2.2.5, and 2.2.5-STABLE
Some said the problem came and went, others said a reboot fixed it.
Several claimed that there must be a fix in the mail archives because
they'd heard it discussed so often. Not so.
Here's what I found:
* Doug White, July 1997
This is a message from the system malloc library saying that it may be
getting invalid pointers. This is usually caused by programming errors,
but it's interesting to see inetd spitting these out. You might check
your inetd.conf and make sure it's properly formatted.
* Doug White, September 1997
Its a small complaint from the memory allocation library. I don't see an
explicit fix for it, I might send in a pr just to confirm it's been fixed.
* Doug White, October 1997
The memory allocation library detected what it thinks is an invalid call
to free() memory. This can be safely ignored. There is something in
inetd which trips it but I'm not sure what it is.
* Doug White, October 1997
The memory allocation library detected what it thinks is an invalid call
to free() memory. This can be safely ignored. There is something in
inetd which trips it but I'm not sure what it is.
* Doug White, October 1997
It's harmless. If it bugs you, have inetd's log output placed in a
different file. See syslog.conf.
* Ian Pallfreeman, October 1997
If that's "inetd in free()", this happens when you're out of swap space. I
get it often when some jerk fires of heaps of nntp daemons on the news box.
* Doug White, October 1997
It shouldn't stop su to root since it's long after inetd gets through. It
shouldn't do anything to ftp either, unless it never gets started. What
error messages are you seeing?
* Guy Helmer, January 1998
This problem has been mentioned many times before but I don't see whether
anyone has resolved it. Any solutions?
* Doug White, January 1998
> This problem has been mentioned many times before but I don't see whether
> anyone has resolved it. Any solutions?
None yet that I know of. The biggest problem is that it's hard to
reproduce -- my machine doesn't give those errors. If you can get a
consistent case and can attach gdb to it and give details, then we might
be able to do something with it.
Note that it could be a library call, if realloc() isn't called in the
program itself.
* Ruslan Shevchenko, January 1998
I was have the same message, fix unknown and I have no any idea :(In
current-stable (during one month) all ok.
* William M. Cole, February 1998
I get this at every login after having run out of swap space until a
reboot. It doesn't seem to affect anything else, but don't take my word
for it. A workaround, I guess, would be to increase your swap space. I
would, but I'm only running on a 100MB drive.
* Doug White, February 1998
This happens to a fraction of the users and unfortunately I don't know a
solution offhand.
The last suggestion was to check `netstat -m' and see how many mbuf
clusters are in use and the max value. If the max is within 3/4 of the
total maxiumum (default 255?) then you need to increase the number by
compiling your kernel with `options NMBCLUSTERS=XXXX'.
Something is running out of memory or is leaking memory.
* Doug White, February 1998
Check the mail archives for my previous advice on this. Rebooting will
usually clear it up, but you may need to increase your mbufs.
* Greg Lehey, March 1998
Yes, I've seen this too. I seem to recall some solution, but I'd have
to dig. You can recover from this by stopping and restarting inetd.
* Andrew MacIntyre, March 1998
Someone (Cy Schubert??) in the last week or so posted a set of accumulated
patches for 2.2.5-RELEASE, including a fairly critical VM fix from John
Dyson. The VM fix may be a solution to your freeze problem....
If you can, I'd suggest looking through the list archive for that set of
patches, which will probably tide you over until you're ready to upgrade
to 2.2.6.
Now, my machine is still doing this.
I am yet to try Greg's suggestion of restarting inetd.
My question is, does anyone know or care why this is happening, and if it
is transient can I assist in working it out while it's happening here?
PS
No, please don't ask me to read the mail archives a fourth time :-)
--
Regards,
-*Sue*-
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980503135101.41667>