From nobody@hyperreal.com Sun Jan 19 14:19:32 1997 Received: by taz.hyperreal.com (8.8.3/V2.0) id OAA17502; Sun, 19 Jan 1997 14:19:32 -0800 (PST) Message-Id: <199701192219.OAA17502@taz.hyperreal.com> Date: Sun, 19 Jan 1997 14:19:32 -0800 (PST) From: "Andrew J. Korty" Reply-To: ajk@purdue.edu To: apbugs@hyperreal.com Subject: httpd seems to crash machine X-Send-Pr-Version: 3.2 >Number: 117 >Category: general >Synopsis: httpd seems to crash machine >Confidential: no >Severity: critical >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Sun Jan 19 14:20:00 1997 >Last-Modified: Sun Apr 6 14:44:51 PDT 1997 >Originator: ajk@purdue.edu >Organization: >Release: 1.2b4 >Environment: Sun 630/MP with four HyerSPARC CPUs SunOS 4.1.3_U1 gcc 2.7.2 >Description: We had this problem with NCSA httpd 1.5. The machine would crash randomly with the following kernel messages: Jan 16 23:16:14 london vmunix: BAD TRAP: cpu=0 type=9 rp=f1bc6d54 addr=20 mmu_fs r=326 rw=1 Jan 16 23:16:14 london vmunix: MMU sfsr=326: Invalid Address on supv data fetch at level 3 Jan 16 23:16:14 london vmunix: regs at f1bc6d54: >How-To-Repeat: Jan 16 23:16:14 london vmunix: psr=1f4000c6 pc=f001f92c npc=f001f930 Jan 16 23:16:14 london vmunix: y: 40000000 g1: f001f920 g2: ef7f3870 g3: ffffff 00 Jan 16 23:16:14 london vmunix: g4: ef6bad0a g5: f1bc7000 g6: 0 g7: 0 >Fix: Jan 16 23:16:14 london vmunix: o0: ffbfffff o1: 88001 o2: f1bc6fe0 o3: 0 Jan 16 23:16:14 london vmunix: o4: f1bc6fe0 o5: f1bc7000 sp: f1bc6da0 ra: fd00a 800 Jan 16 23:16:14 london vmunix: pid 14630, `httpd': Data access exceptio >Audit-Trail: State-Changed-From-To: open-analyzed State-Changed-By: fielding State-Changed-When: Thu Jan 23 17:28:56 PST 1997 State-Changed-Why: Unfortunately, there is nothing in the report that can be used in tracing the problem to a specific httpd action. Please let us know if you can repeat it (non-randomly) or if there is a core file produced that you could run a backtrace upon. One possibility is that it is a bad memory SIMM. I encountered similar errors on a SPARC 5 system last year and fixed it by swapping the SIMMs with other systems until the one with the bad memory crashed. Such errors are only revealed by Solaris when a program attempts to use a bad segment in high memory. State-Changed-From-To: analyzed-closed State-Changed-By: marc State-Changed-When: Sun Apr 6 14:44:50 PDT 1997 State-Changed-Why: No futher followup from user; probably not an Apache problem. >Unformatted: