From owner-freebsd-questions Sun Jan 6 23:15:41 2002 Delivered-To: freebsd-questions@freebsd.org Received: from hotmail.com (f55.law11.hotmail.com [64.4.17.55]) by hub.freebsd.org (Postfix) with ESMTP id 1237837B427 for ; Sun, 6 Jan 2002 23:15:26 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 6 Jan 2002 23:15:25 -0800 Received: from 24.38.53.86 by lw11fd.law11.hotmail.msn.com with HTTP; Mon, 07 Jan 2002 07:15:25 GMT X-Originating-IP: [24.38.53.86] From: "Charles Burns" To: questions@freebsd.org Subject: The only way I have ever found to crash FreeBSD Date: Mon, 07 Jan 2002 00:15:25 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jan 2002 07:15:25.0801 (UTC) FILETIME=[140FDD90:01C1974B] Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The only way that I have found to crash FreeBSD is to run a Linux program with statically linked binaries. Am am curious as to why this happens, if it still does as I have not tried since 4.4-Release, and I am wondering if there is a way to prevent this from occuring if the Linux executable's library linkage is not known. I'm not complaining, as this hasn't been a problem for me, I am just honestly curious as to what goes on that causes the system to reboot or whatever it decides to do that day. If that glitch were to be dealth with, perhaps by detecting whether libs are statically compiled and refusing to run the program, FreeBSD would be 100% unbcrashable as far as I can tell (short of doing things that are not the fault of FreeBSD, like removing the CPU while the system is running or compiling the kernel with the '-malign-double' option) _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message