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>