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: