From gad@freefour.acs.rpi.edu  Sat Aug  1 22:12:18 1998
Received: from freefour.acs.rpi.edu (freefour.acs.rpi.edu [128.113.24.91])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA02220
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 1 Aug 1998 22:12:18 -0700 (PDT)
          (envelope-from gad@freefour.acs.rpi.edu)
Received: (from gad@localhost)
	by freefour.acs.rpi.edu (8.8.8/8.8.8) id BAA00386;
	Sun, 2 Aug 1998 01:12:28 -0400 (EDT)
	(envelope-from gad)
Message-Id: <199808020512.BAA00386@freefour.acs.rpi.edu>
Date: Sun, 2 Aug 1998 01:12:28 -0400 (EDT)
From: Garance A Drosehn <gad@freefour.acs.rpi.edu>
Reply-To: gad@eclipse.its.rpi.edu
To: FreeBSD-gnats-submit@freebsd.org
Cc: gad@eclipse.its.rpi.edu
Subject: Error building modula-3 on dual-processor kernel
X-Send-Pr-Version: 3.2

>Number:         7468
>Category:       kern
>Synopsis:       [smp] Error building modula-3 on dual-processor kernel
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Aug  1 22:20:01 PDT 1998
>Closed-Date:    Thu Oct 1 13:47:09 PDT 1998
>Last-Modified:  Thu Oct  1 13:48:25 PDT 1998
>Originator:     Garance A Drosehn
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
RPI ; Troy NY
>Environment:

	Running on a Toshiba 6200M computer, with two 200Mhz
	Pentium Pro processors and 192 meg of RAM on an
	Intel PR440FX motherboard.

>Description:

	I updated my system to current as of July 31st.  After updating,
	I tried rebuilding modula-3, and after many successful steps in
	that process, I got the following failure:
---------------------- building m3 ----------------------

mkdir FreeBSD2
--- building in FreeBSD2 ---
m3 -w1 -why -O -times -o m3 -F/var/tmp/qkPl7596 
new source -> compiling ../src/M3Backend.i3
new source -> compiling ../src/Arg.i3
new source -> compiling ../src/Msg.i3
new source -> compiling ../src/M3Path.i3
new source -> compiling ../src/Unit.i3
new source -> compiling ../src/Utils.i3
new source -> compiling ../src/WebFile.i3
new source -> compiling ../src/M3BackPosix.m3
new source -> compiling ../src/Arg.m3
new source -> compiling ../src/Msg.m3
new source -> compiling ../src/M3Path.m3


***
*** runtime error:
***    improper typecode: 174758
***
---------------------------------------------------------
	It then just hung there.  From another session I was running
	'top', and it showed:
  PID USERNAME PRI NICE  SIZE    RES STATE  C   TIME   WCPU    CPU COMMAND
 7598 root      91   0  3744K  2140K CPU0   1   1:29 99.32% 98.42% m3

	This was while running with an SMP kernel definition (note that
	I had already rebooted the system after the 'make installworld'
	and building this kernel).  I have a similar kernel definition
	which does not turn on the SMP support, so I installed that
	kernel, rebooted, and did a 'make clean' and 'make' for modula-3.
	This time it worked fine.

	I would also note that I ran into the same problem when I first
	built this system from 3.0-980627-SNAP.  In that case I had built
	the system from scratch (reformatting disks, etc), via an FTP
	install.  That time I also had a similar error when building
	modula-3 on a SMP kernel, but that time I didn't think to save
	the error message before rebooting into a single-CPU kernel.

	Other than the problems building modula-3, I have seen no odd
	failures during the month I ran with the 3.0-980627-SNAP-based
	SMP kernel, or the ten or fifteen minutes I've been running
	with the latest code from CURRENT...

>How-To-Repeat:

	Try to build modula-3 on a system with an SMP kernel, I guess.

>Fix:
	
	I have no idea about possible fixes (other than the workaround
	of rebooting with a single-cpu kernel).

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports->jdp 
Responsible-Changed-By: steve 
Responsible-Changed-When: Sat Aug 8 17:00:53 PDT 1998 
Responsible-Changed-Why:  
Pass over to port's maintainer. 
Responsible-Changed-From-To: jdp->freebsd-bugs 
Responsible-Changed-By: jdp 
Responsible-Changed-When: Sat Aug 8 20:35:50 PDT 1998 
Responsible-Changed-Why:  
There is no way this is a bug in the port or in Modula-3.  It is a 
kernel bug.  It really belongs in the kern category, but I don't know 
how to refile it. 

From: Chris Timmons <skynyrd@opus.cts.cwu.edu>
To: freebsd-gnats-submit@freebsd.org
Cc: John Polstra <jdp@polstra.com>
Subject: Re: kern/7468
Date: Fri, 14 Aug 1998 10:32:25 -0700 (PDT)

 With the guidance of John Polstra <jdp@polstra.com>, I have performed
 some coarse debugging.  John suspects that the problem is triggered by
 the m3 runtime system's memory allocator.
 
 According to John: "The allocator uses mprotect(2) to make allocated
 pages inaccessible.  When the program later attempts to access the
 data, a SIGBUS results.  The allocator catches the signal, records the
 fact that the page was accessed, and calls mprotect again to allow
 access.  The signal handler returns in such a way as to re-execute the
 faulting instruction, which succeeds the this time."
 
 John suggested building the m3 compiler (itself an m3 program) with
 the elaborate run-time allocator disabled; indeed, with the elaborate
 allocator disabled, the compiler is able to complete the build which
 otherwise had failed.
 
 
 1) TESTING ENVIRONMENT:
 
 	-current as of August 4, 1998
 	-SMP kernel
 	-UP machine (failure syndrome is identical on UP machine
 	 running SMP kernel and my UP -current machine is much
 	 faster than the dual-processor one.)
 
 	- cd /usr/ports/lang/modula-3-lib
 
 diff -r1.10 Makefile
 92c92
 <           make -f ../src/makefile TARGET=FreeBSD2 COPT=-O CDEBUG= ; \
 ---
 >           make -f ../src/makefile TARGET=FreeBSD2 COPT=-O CDEBUG=-g ; \
 110c110
 <           make m3cgc1 CC="${CC}" CFLAGS="${CFLAGS}"; \
 ---
 >           make m3cgc1 CC="${CC}" CFLAGS="-g -O"; \
 
 
 	- do "make configure"
 
 	- Edit "work/m3/m3build/templates/FreeBSD2".  Search for the
 	  string "M3OPTIONS" (should be on or about line 201)
 
 		M3OPTIONS = [ "-w1", "-why", "-O" ]
 		% ------ FOR DEBUGGING INFO, add "-g"
 
 	  Add ", -g" to generate debugging symbols.
 		M3OPTIONS = [ "-w1", "-why", "-O", "-g" ]
 	
 
 	- *** TO MASK THE PROBLEM - add "@M3novm"
 
 		M3OPTIONS = [ "-w1", "-why", "-O", "-g", "@M3novm" ]
 
 	- do "make"
 
 	- expect pid <pid#> (m3), uid 0: exited on signal 6 (core dumped)
 	  which occurs during the build of work/m3/parseparams.
 
 	- if you restart from this point, there is another reliable crash
 	  soon to follow.
 
 2) M3 CRASH BACKTRACE
 
 GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation,
 Inc...
 Core was generated by `m3'.
 Program terminated with signal 6, Abort trap.
 #0  0xdb315 in _kill ()
 (gdb) bt
 #0  0xdb315 in _kill ()
 #1  0xdafd8 in abort ()
 #2  0xc56df in RTHeapDep__Core (M3_DLS2Hj_sig=6, M3_DLS2Hj_code=0,
 M3_AROiO0_scp=0xefbfd054) at RTHeapDep.m3:155
 #3  <signal handler called>
 #4  0xdb315 in _kill ()
 #5  0xc4b65 in RTOS__Crash () at RTOS.m3:20
 #6  0xc1681 in RTProcess__Crash (M3_Bd56fi_msg=0x0) at RTProcess.m3:65
 #7  0xc0a4f in RTMisc__EndError () at RTMisc.m3:121
 #8  0xc0806 in RTMisc__FatalErrorS (M3_AJWxb1_file=0x11d970,
 M3_AcxOUs_line=35, M3_Bd56fi_msgA=0x11c1ec, M3_Bd56fi_msgB=0x0, 
     M3_Bd56fi_msgC=0x0) at RTMisc.m3:66
 #9  0xb53a6 in RTHooks__ReportFault (M3_AJWxb1_module=0x11d6cc,
 M3_AcxOUs_info=560) at RTHooks.m3:107
 #10 0xb7b46 in _m3_fault (M3_AcxOUs_arg=560) at RTHeapMap.m3:225
 #11 0xb72b6 in RTHeapMap__WalkRef (M3_DjW59Y_h=0x1b5000,
 M3_Deq2V9_v=0x1ae004) at RTHeapMap.m3:35
 #12 0xba9c4 in RTCollector__CleanBetween (M3_DjW59Y_h=0x1b5000,
 M3_DjW59Y_he=0x1b6000) at RTCollector.m3:1005
 #13 0xba6df in RTCollector__CopySome () at RTCollector.m3:970
 #14 0xb9f55 in RTCollector__CollectSomeInStateOne () at RTCollector.m3:848
 #15 0xb9655 in RTCollector__CollectSome () at RTCollector.m3:694
 #16 0xbbe15 in RTHeapRep__Crash () at RTCollector.m3:1614
 #17 0xc089c in RTMisc__FatalErrorPC (M3_AcxOUs_pc=723612,
 M3_Bd56fi_msgA=0x122b88, M3_Bd56fi_msgB=0x0, M3_Bd56fi_msgC=0x0)
     at RTMisc.m3:84
 #18 0xc5bc9 in RTSignal__SegV (M3_DLS2Hj_sig=11, M3_DLS2Hj_code=12,
 M3_AROiO0_scp=0xefbfd274) at RTSignal.m3:96
 #19 0xc5641 in RTHeapDep__Fault (M3_DLS2Hj_sig=11, M3_DLS2Hj_code=12,
 M3_AROiO0_scp=0xefbfd274) at RTHeapDep.m3:129
 #20 <signal handler called>
 #21 0xb0a9c in IntRefTbl__KeyEqual (M3_CJQvia_tbl=0x19a0a4,
 M3_EN2A1V_k1=0x28d564, M3_EN2A1V_k2=0x44524143) at Table.mg:186
 #22 0xb06e4 in IntRefTbl__Get (M3_CJQvia_tbl=0x19a0a4,
 M3_EN2A1V_key=0x28d564, M3_EKuYlT_val=0xefbfd318) at Table.mg:103
 #23 0x7df4 in Main__CheckImp (M3_A7mgsK_u=0x251810, M3_EIVwTa_z=0x251824,
 M3_BpHyht_map=0x19a0a4) at Main.m3:1497
 #24 0x7d47 in Main__CheckImports (M3_A7mgsK_u=0x251810) at Main.m3:1487
 #25 0x7cb4 in Main__Merge (M3_ANTBnu_f=0x1720cc) at Main.m3:1465
 #26 0x7733 in Main__CompileM3 (M3_ANTBnu_f=0x1720cc) at Main.m3:1281
 #27 0x7206 in Main__CompileOne (M3_ANTBnu_f=0x1720cc) at Main.m3:1129
 #28 0x710c in Main__CompileEverything () at Main.m3:1099
 #29 0x43d4 in Main__DoIt () at Main.m3:155
 #30 0xb9b0 in _INITM_Main () at Main.m3:2923
 #31 0xc03d1 in RTLinker__RunMainBodies () at RTLinker.m3:58
 #32 0xc04c7 in _INITM_RTLinker () at RTLinker.m3:88
 #33 0x15b9 in main (argc=31, argv=0xefbfd418, envp=0xefbfd498) at
 _m3main.c:1440
 
 
 3) KTRACE snippets.  'ktrace -idg <top-level-make-pid>' was used.
    Probably the build script could be hacked to call ktrace on just
    the m3 invocation, continually over-writing the ktrace.out file
    until the crash occurs; I managed ktrace by hand, starting close
    to the inevitable crash.
 
 
 ; THIS IS TYPICAL OF HOW THE M3 ALLOCATOR EXERCISES MPROTECT()
 ; SIMILAR SEQUENCES OCCUR VERY ROUTINELY.
 
  14541 m3       CALL  mprotect(0x142000,0x1000,0x3)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x143000,0x2000,0x3)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x14b000,0x2000,0x3)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x14d000,0x6000,0x1)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x142000,0x1000,0x1)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x14b000,0x2000,0x1)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x158000,0x1000,0x1)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x159000,0x8000,0x1)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x165000,0x1000,0x1)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  getrusage(0,0xefbfd1ec)
  14541 m3       RET   getrusage 0
  14541 m3       PSIG  SIGBUS caught handler=0xc55c0 mask=0x0 code=0xc
  14541 m3       CALL  mprotect(0x158000,0x1000,0x3)
  14541 m3       RET   mprotect 0
 
 ; THIS IS THE SEQUENCE WHEN M3 DIES; NOTE THE SEGV WHICH LEADS TO 
 ; AN ASSERTION FIRING AND ULTIMATELY - CALL  kill(0x38cd,0x6).
 
  14541 m3       PSIG  SIGBUS caught handler=0xc55c0 mask=0x0 code=0xc
  14541 m3       CALL  mprotect(0x246000,0x1000,0x3)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  sigreturn(0xefbfd260)
  14541 m3       RET   sigreturn JUSTRETURN
  14541 m3       CALL  unlink(0x177e1c)
  14541 m3       NAMI  "ParseParams.ms"
  14541 m3       RET   unlink 0
  14541 m3       CALL  gettimeofday(0xefbfd304,0xefbfd30c)
  14541 m3       RET   gettimeofday 0
  14541 m3       PSIG  SIGBUS caught handler=0xc55c0 mask=0x0 code=0xc
  14541 m3       CALL  getrusage(0,0xefbfd1bc)
  14541 m3       RET   getrusage 0
  14541 m3       CALL  mprotect(0x269000,0x1000,0x3)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x1c1000,0x1000,0x3)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x1c1000,0x1000,0x1)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  mprotect(0x269000,0x1000,0)
  14541 m3       RET   mprotect 0
  14541 m3       CALL  getrusage(0,0xefbfd1a8)
  14541 m3       RET   getrusage 0
  14541 m3       CALL  sigreturn(0xefbfd274)
  14541 m3       RET   sigreturn JUSTRETURN
  14541 m3       PSIG  SIGSEGV caught handler=0xc55c0 mask=0x0 code=0xc
 
 
State-Changed-From-To: open->closed 
State-Changed-By: jdp 
State-Changed-When: Thu Oct 1 13:47:09 PDT 1998 
State-Changed-Why:  
Fixed by Tor Egge in revision 1.136 of "src/sys/vm/vm_map.c". 
>Unformatted:
