Subject: port-vax/19968: Increasing MAXDSIZ and MAXSSIZ results in kernel panics
To: None <gnats-bugs@gnats.netbsd.org>
From: None <vaxzilla@jarai.org>
List: netbsd-bugs
Date: 01/20/2003 15:00:24
>Number:         19968
>Category:       port-vax
>Synopsis:       Increasing MAXDSIZ and MAXSSIZ results in kernel panics
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-vax-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 20 15:01:01 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     Brian Chase
>Release:        NetBSD 1.6
>Organization:
	
>Environment:
	
	
System: NetBSD radiant.jarai.net 1.6 NetBSD 1.6 (RADIANT2) #0: Sun Jan 19 09:08:48 PST 2003 bdc@radiant.jarai.net:/n0/usr/src/sys/arch/vax/compile/RADIANT2 vax
Architecture: vax
Machine: vax
>Description:
In the interesting of getting some large pkgsrc compiles done, I bumped
up a few values in my /sys/arch/vax/include/vmparam.h file.  I took
MAXDSIZ from 64MB to 96MB and MAXSSIZ from 8MB to 12MB.  Having done
this, I config'ed and recompiled a new kernel.  Rebooting with the
kernel let me bump up the appropriate resource limits; something I was
hoping would let me squeeze the compile through.

I restarted the big compile, and when I checked on it an hour or so
later, I found that the kernel had panicked and dropped into the kernel
debugger at the console:

  panic: Segv in kernel mode: pc 800d7c48 addr 5103d030
  Stopped in pid 608 (cc1plus) at trap+0x1d3      cmpl     r1, $12
  db>

In another window, I've got the output from a top that was running.
It appears that things exploded just as the size of the process reached
65MB (probably 65536KB):

---
load averages:  2.88,  2.69,  2.11                                     10:20:18
44 processes:  1 runnable, 42 sleeping, 1 on processor
CPU states: 54.4% user,  0.0% nice, 31.4% system, 10.5% interrupt,  3.8% idle
Memory: 4416K Act, 2452K Inact, 1408K Wired, 608K Exec, 2724K File, 772K Free
Swap: 160M Total, 71M Used, 89M Free

  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
  608 root      59    0    65M 4644K RUN       21:23 53.12% 53.12% cc1plus
    4 root     -18    0     0K 1848K pgdaemon   4:26 27.93% 27.93% [pagedaemon]
  337 bdc       40    0   220K  424K CPU        2:32  5.81%  5.81% top
  226 bdc        2    0   380K  356K select     1:57  4.79%  4.79% sshd
    6 root      18    0     0K 1848K syncer     0:10  0.29%  0.29% [ioflush]
    7 root     -18    0     0K 1848K aiodoned   0:08  0.20%  0.20% [aiodoned]
  192 root       2    0   328K    0K select     1:08  0.00%  0.00% <sshd>
  450 root      10    0  1180K    0K wait       1:04  0.00%  0.00% <make>
  224 bdc        2    0   380K    0K select     0:16  0.00%  0.00% <sshd>
  369 root      10    0   544K    0K wait       0:14  0.00%  0.00% <make>
  432 root      10    0   544K    0K wait       0:13  0.00%  0.00% <make>
  301 root      10    0   516K    0K wait       0:12  0.00%  0.00% <make>
  220 root       2    0   348K    0K netio      0:11  0.00%  0.00% <sshd>
  221 root       2    0   348K    0K netio      0:11  0.00%  0.00% <sshd>
  233 root      18    0   772K    0K pause      0:10  0.00%  0.00% <tcsh>
  358 root      10    0   516K    0K wait       0:10  0.00%  0.00% <make>
  452 root      10    0   792K    0K wait       0:09  0.00%  0.00% <sh>
---

Without knowing for certain, my initial suspicion is that somewhere else
in the kernel, there's a dependency on the processes only having a
maximum data size of 64MB and that changing the value in the vmparam.h
file doesn't adjust this dependency.

I've left my console setting at the db> prompt in case there is other
useful information I can provide.

There's no urgency in getting the compile completed (it's the pkgsrc/x11/fox
package, the file being compiled is FXColorSelector.cpp).  Basically, I'm
trying to push the various limits of NetBSD/vax to see where things die.
With the default vmparam.h settings, the process is properly killed when
either (a) the system runs out of memory or (b) the process hits its
resource limits.  I only managed to get the kernel panic by upping the
values in vmparam.h.

Here are the trace results:

  panic: Segv in kernel mode: pc 800d7c48 addr 5103d030
  Stopped in pid 608 (cc1plus) at trap+0x1d3      cmpl     r1, $12
  db> trace
  panic: Segv in kernel mode: pc %x addr %x
  Stack traceback :
  0x8c06ad50: trap+0x1d3(0x8c06add8)
  0x8c06add8: trap type=0x8 code=0x5103d030 pc=0x800d7c48 psl=0xc00000
  0x8c06ada4: uvmfault_anonget+0x50(0x8c06af24,0x80ce5e40,0x50050)
  0x8c06ae28: uvm_fault+0x627(0x805678d4,0x3dc8000,0,0x1)
  0x8c06af40: trap+0x194(0x8c06afb4)
  db>

>How-To-Repeat:
To repeat the problem, I only need to attempt to recompile the pkgsrc/x11/fox
package with the kernel that has the altered vmparam.h settings.  The file 
FXColorSelector.cpp causes the cc1plus process to use in excess of 64MB of
memory, resulting in the panic.
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted: