Received: by taz.hyperreal.com (8.8.4/V2.0) id LAA04226; Mon, 3 Mar 1997 11:09:47 -0800 (PST) Received: from nora.pcug.co.uk by taz.hyperreal.com (8.8.4/V2.0) with SMTP id LAA04141; Mon, 3 Mar 1997 11:09:37 -0800 (PST) Received: from imdb.demon.co.uk by nora.pcug.co.uk id aa27934; 3 Mar 97 19:09 GMT Date: Mon, 3 Mar 1997 19:06:08 +0000 (GMT) From: Rob Hartill To: Apache Group Subject: [BUG]: "kernel panics and dumps core" on SunOS 4.x (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com Most useful info at the end.. ---------- Forwarded message ---------- Date: Mon Mar 3 7:59:41 1997 From: chrisd@name.net To: apache-bugs%apache.org@organic.com Subject: [BUG]: "kernel panics and dumps core" on SunOS 4.x Submitter: chrisd@name.net Operating system: SunOS 4.x, version: Version of Apache Used: 1.2b7 Extra Modules used: rewrite, info, auth_dbm, digest, expires, headers, usertrack URL exhibiting problem: Symptoms: -- SunOs 4.1.3 kernel panics and dumps core, machine shuts down. No info is written to log files and no httpd core is created. Here's the syslog entry: BAD TRAP pid 11358, `httpd': Data fault kernel read fault at addr=0x20, pme=0x0 Sync Error Reg 80 pc=0xf801e7d8, sp=0xf8620da0, psr=0x114000c6, context=0x8 g1-g7: f801e7cc, 4b000, ffffff00, 48000000, f8621000, 0, 0 Begin traceback... sp = f8620da0 Called from f805d534, fp=f8620e00, args=1 ff66f50c 6 1 f8620eb0 0 Called from f8060294, fp=f8620e60, args=ff66f50c 6 1 ff66fb00 0 ff66fb00 Called from f810ac60, fp=f8620ec0, args=f8620fe0 348 f8143ab8 f836a1c8 ff66fb00 f8620fe0 Called from f8005a54, fp=f8620f58, args=f8621000 f8620fb4 f8620fe0 f8621000 f862 1000 f8620fb4 Called from 4e7c, fp=f7fffca8, args=11 6 1 f7fffd0c 4 1 End traceback... panic: Data fault One of our Unix gurus, Rens Troost, reports: Looking into the coredumps reveals that in fact the same code path is killing the server each time; the relevant part of the stack trace: f85eee60 f8060294 _setsockopt+ dc f85eefe0 348 f8143ab8 f83522a4 Looks like something in Apache is passing a bad value to setsockopt(), and the argument is not being properly validated. -- Backtrace: -- --