Date: Fri, 14 Aug 1998 10:40:01 -0700 (PDT) From: Chris Timmons <skynyrd@opus.cts.cwu.edu> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/7468 Message-ID: <199808141740.KAA25030@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/7468; it has been noted by GNATS.
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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808141740.KAA25030>