Date: Wed, 1 Jan 1997 12:20:02 -0800 (PST) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-bugs Subject: Re: bin/2347: sysinstall: ppp: recursive call in malloc() Message-ID: <199701012020.MAA22030@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/2347; it has been noted by GNATS. From: J Wunsch <j@uriah.heep.sax.de> To: andrew@ugh.net.au Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/2347: sysinstall: ppp: recursive call in malloc() Date: Wed, 1 Jan 1997 19:25:38 +0100 (MET) As andrew@ugh.net.au wrote: > When installing via PPP I got the message on vty2 (the PPP screen anyway): > ppp in malloc(): warning: recursive call. So this is now the reason for the problem you're describing in PR # bin/2345, both are duplicates, but this one here is more detailed. For no known to me reason, sysinstall uses an /etc/malloc.conf containing the letter "A", meaning it should abort (signal 6) any program that causes a malloc warning. You could probably work around this by typing "rm /etc/malloc.conf" early in the emergency holographic shell. Hmm, no, you gotta type it _before_ you're starting PPP, so i think the only way to achieve this is to first use the `fixit' floppy. Download the fixit image, copy it to a floppy, then select `fixit' as the first step of your installation session, before installing anything. Remove said symlink from the fixit shell. Ick. ISTR that the fixit process was broken in BETA, i'm not sure. I could provide you with an alternate (more recent) boot floppy, where you can even start the Emergency Holographic Shell before (but i think you need the fixit session anyway, since there's no rm command available that early). > I typed show mem to see what was wrong and things froze - modem stopped > receiving, ppp didnt respond - I went to vty4 (the emergency holographic (signal 6) > shell one) to do a ps and see what was going on - i typed ps and nothing > happened. I switched to vty0 and nothing had changed - i could > no longer go back to vty4 (it just beeped when i tried). I pressec ^C and There are two basically known bugs here. One is broken by design :), in that the console driver prevents you from switching to a screen when no process has this VTY open. This bugfeature has been copied from SCO, but it's IMHO a very silly one. The second is that syscons seems to have serious trouble with VT switching these days. This is also basically known (but i don't think anybody is working on a fix for this right now). It renders the Emergency Holographic Shell fairly unusable. :-( The only workaround i've found for this is starting yet another shell on top of the EHS early during installation. Apparently, this keeps yet another process running on that VTY, and this seems to tell syscons that switching to that screen is possible. > Try getting PPP to transfer a lot of data for an hour or two - It seems > to happen when the modem has been flat chat at 28.8 for an hour or so. Hmm, this would be interesting to find. Maybe it's something related to your setup, i'm not sure. I'm using PPP a lot, and i also have malloc.conf set to `Abort'. Yet, i have not seen this phenomenon. If you can trigger it later, once your system has already been installed, it would be great if you could help us out with a stacktrace from the coredump. I'm afraid this PR will remain open until this. In order to do this, you also have to type ln -s AJ /etc/malloc.conf Errm, nope. :-((( For security reasons, setuid binaries don't generate coredumps now, not even if your real UID matches the UID of the process. So the only chance to get a core is to remove the suid and sgid bits from /usr/sbin/ppp, and run it as root. It would be really great if you could trigger the bug again. (If you did, send it as mail to freebsd-gnats-submit@freebsd.org, with a subject line of just ``bin/2347''. This way, your mail will be appended to the audit-trail of this PR.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701012020.MAA22030>