From dabenavidesd at yahoo.es Tue Sep 18 23:29:18 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 18 Sep 2007 23:29:18 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler Message-ID: <291833.75281.qm@web27114.mail.ukl.yahoo.com> Hi all: Im getting this runtiem error because the symbol missing version stamps -> compiling RTAllocStats.m3 "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime symbol !! (R THooks.AllocateTracedRef) AllocateTracedRef is not defined in the m3core version of this Dll (I guess the change is more new than the bootstrap compiler). How can avoid this issue? Thanks in advance C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd INSTALLROOT=C:\cm3 LIB=%INSTALLROOT%\LIB;%LIB% CM3ROOT=C:\\cm3-cvs\\cm3 call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override -DROOT=C:\\cm3-c vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner m3tools m3cgcat m3c ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph parseparams realgeo metry set slisp sortedtableextras table-list tempfiles tcp tapi === package C:\cm3-cvs\cm3\m3-win\import-libs === +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ --- building in NT386 --- unable to read ..\src\m3overrides, options "-override" and "-x" ignored. === package C:\cm3-cvs\cm3\m3-libs\m3core === +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ --- building in NT386 --- missing version stamps -> compiling RTAllocStats.m3 "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime symbol !! (R THooks.AllocateTracedRef) *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 ......... ......... ... more frames ... *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 failed with 0 *** error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override -DROOT=C :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner m3tools m3c gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp tapi failed C:\cm3-cvs\cm3\scripts\win> --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 19 00:25:14 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Sep 2007 18:25:14 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <291833.75281.qm@web27114.mail.ukl.yahoo.com> References: <291833.75281.qm@web27114.mail.ukl.yahoo.com> Message-ID: You need to recompile m3core before compiling with the new compiler. On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > Im getting this runtiem error because the symbol > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > AllocateTracedRef is not defined in the m3core version of this Dll > (I guess the change is more new than the bootstrap compiler). How > can avoid this issue? > > Thanks in advance > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > INSTALLROOT=C:\cm3 > LIB=%INSTALLROOT%\LIB;%LIB% > CM3ROOT=C:\\cm3-cvs\\cm3 > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > DROOT=C:\\cm3-c > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > m3tools m3cgcat m3c > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > parseparams realgeo > metry set slisp sortedtableextras table-list tempfiles tcp tapi > === package C:\cm3-cvs\cm3\m3-win\import-libs === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > unable to read ..\src\m3overrides, options "-override" and "-x" > ignored. > === package C:\cm3-cvs\cm3\m3-libs\m3core === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > failed with 0 *** > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > override -DROOT=C > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > m3scanner m3tools m3c > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > digraph parseparams > realgeometry set slisp sortedtableextras table-list tempfiles tcp > tapi failed > > C:\cm3-cvs\cm3\scripts\win> > > > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . From dabenavidesd at yahoo.es Wed Sep 19 00:30:16 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 19 Sep 2007 00:30:16 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: Message-ID: <248580.34013.qm@web27103.mail.ukl.yahoo.com> Hi: Thanks for your answer, I have done that and also I get the same runtime error in the same source file: C:\cm3-cvs\cm3\m3-libs\m3core>CM3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Csetjmp.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapDep.i3 new source -> compiling RTHeapRep.i3 new source -> compiling ThreadF.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime symbol !! (R THooks.AllocateTracedRef) *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 ......... ......... ... more frames ... C:\cm3-cvs\cm3\m3-libs\m3core> >You need to recompile m3core before compiling with the new compiler. >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > Im getting this runtiem error because the symbol > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > AllocateTracedRef is not defined in the m3core version of this Dll > (I guess the change is more new than the bootstrap compiler). How > can avoid this issue? > > Thanks in advance > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > INSTALLROOT=C:\cm3 > LIB=%INSTALLROOT%\LIB;%LIB% > CM3ROOT=C:\\cm3-cvs\\cm3 > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > DROOT=C:\\cm3-c > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > m3tools m3cgcat m3c > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > parseparams realgeo > metry set slisp sortedtableextras table-list tempfiles tcp tapi > === package C:\cm3-cvs\cm3\m3-win\import-libs === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > unable to read ..\src\m3overrides, options "-override" and "-x" > ignored. > === package C:\cm3-cvs\cm3\m3-libs\m3core === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > failed with 0 *** > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > override -DROOT=C > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > m3scanner m3tools m3c > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > digraph parseparams > realgeometry set slisp sortedtableextras table-list tempfiles tcp > tapi failed > > C:\cm3-cvs\cm3\scripts\win> > > > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 19 00:35:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Sep 2007 18:35:08 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <248580.34013.qm@web27103.mail.ukl.yahoo.com> References: <248580.34013.qm@web27103.mail.ukl.yahoo.com> Message-ID: You need to compile the new m3core with the old compiler so that the symbol is available to you when you compile using the new compiler. This is a classical bootstrapping problem. On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your answer, I have done that and also I get the same > runtime error > in the same source file: > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > new source -> compiling Compiler.m3 > new source -> compiling RTAllocator.i3 > new source -> compiling RTType.i3 > new source -> compiling Csetjmp.i3 > new source -> compiling BasicCtypes.i3 > new source -> compiling Ctypes.i3 > new source -> compiling RTMachine.i3 > new source -> compiling RTHeapDep.i3 > new source -> compiling RTHeapRep.i3 > new source -> compiling ThreadF.i3 > new source -> compiling RTOS.i3 > new source -> compiling RTMisc.i3 > new source -> compiling RTHeap.i3 > new source -> compiling Cstdlib.i3 > new source -> compiling Cstddef.i3 > new source -> compiling RTAllocCnts.i3 > new source -> compiling RTAllocator.m3 > new source -> compiling RTAllocStats.i3 > new source -> compiling Convert.i3 > new source -> compiling TextClass.i3 > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > > C:\cm3-cvs\cm3\m3-libs\m3core> > >You need to recompile m3core before compiling with the new compiler. > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > > > Hi all: > > Im getting this runtiem error because the symbol > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > AllocateTracedRef is not defined in the m3core version of this Dll > > (I guess the change is more new than the bootstrap compiler). How > > can avoid this issue? > > > > Thanks in advance > > > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > > INSTALLROOT=C:\cm3 > > LIB=%INSTALLROOT%\LIB;%LIB% > > CM3ROOT=C:\\cm3-cvs\\cm3 > > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > > DROOT=C:\\cm3-c > > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > > m3tools m3cgcat m3c > > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > > parseparams realgeo > > metry set slisp sortedtableextras table-list tempfiles tcp tapi > > === package C:\cm3-cvs\cm3\m3-win\import-libs === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > unable to read ..\src\m3overrides, options "-override" and "-x" > > ignored. > > === package C:\cm3-cvs\cm3\m3-libs\m3core === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > > > *** > > *** runtime error: > > *** Attempt to reference an illegal memory location. > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > *** > > > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > \RTSignal.m3 > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > ..\src\stmts\AssignStmt.m3 > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > ......... ......... ... more frames ... > > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > > failed with 0 *** > > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > > override -DROOT=C > > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > > m3scanner m3tools m3c > > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > > digraph parseparams > > realgeometry set slisp sortedtableextras table-list tempfiles tcp > > tapi failed > > > > C:\cm3-cvs\cm3\scripts\win> > > > > > > S? un Mejor Amante del Cine > > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > > > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . From dabenavidesd at yahoo.es Wed Sep 19 00:49:57 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 19 Sep 2007 00:49:57 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: Message-ID: <940950.96289.qm@web27108.mail.ukl.yahoo.com> Hi: I have compiled with the Jay produced 5.5 bootstrap compiler, and also with 5.1.3a, 5.2.6 and get the same error. Thanks >You need to compile the new m3core with the old compiler so that the >symbol is available to you when you compile using the new compiler. >This is a classical bootstrapping problem. >On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your answer, I have done that and also I get the same > runtime error > in the same source file: > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > new source -> compiling Compiler.m3 > new source -> compiling RTAllocator.i3 > new source -> compiling RTType.i3 > new source -> compiling Csetjmp.i3 > new source -> compiling BasicCtypes.i3 > new source -> compiling Ctypes.i3 > new source -> compiling RTMachine.i3 > new source -> compiling RTHeapDep.i3 > new source -> compiling RTHeapRep.i3 > new source -> compiling ThreadF.i3 > new source -> compiling RTOS.i3 > new source -> compiling RTMisc.i3 > new source -> compiling RTHeap.i3 > new source -> compiling Cstdlib.i3 > new source -> compiling Cstddef.i3 > new source -> compiling RTAllocCnts.i3 > new source -> compiling RTAllocator.m3 > new source -> compiling RTAllocStats.i3 > new source -> compiling Convert.i3 > new source -> compiling TextClass.i3 > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > > C:\cm3-cvs\cm3\m3-libs\m3core> > >You need to recompile m3core before compiling with the new compiler. > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > > > Hi all: > > Im getting this runtiem error because the symbol > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > AllocateTracedRef is not defined in the m3core version of this Dll > > (I guess the change is more new than the bootstrap compiler). How > > can avoid this issue? > > > > Thanks in advance > > > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > > INSTALLROOT=C:\cm3 > > LIB=%INSTALLROOT%\LIB;%LIB% > > CM3ROOT=C:\\cm3-cvs\\cm3 > > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > > DROOT=C:\\cm3-c > > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > > m3tools m3cgcat m3c > > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > > parseparams realgeo > > metry set slisp sortedtableextras table-list tempfiles tcp tapi > > === package C:\cm3-cvs\cm3\m3-win\import-libs === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > unable to read ..\src\m3overrides, options "-override" and "-x" > > ignored. > > === package C:\cm3-cvs\cm3\m3-libs\m3core === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > > > *** > > *** runtime error: > > *** Attempt to reference an illegal memory location. > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > *** > > > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > \RTSignal.m3 > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > ..\src\stmts\AssignStmt.m3 > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > ......... ......... ... more frames ... > > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > > failed with 0 *** > > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > > override -DROOT=C > > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > > m3scanner m3tools m3c > > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > > digraph parseparams > > realgeometry set slisp sortedtableextras table-list tempfiles tcp > > tapi failed > > > > C:\cm3-cvs\cm3\scripts\win> --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 19 02:41:09 2007 From: jay.krell at cornell.edu (Jay) Date: Wed, 19 Sep 2007 00:41:09 +0000 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <940950.96289.qm@web27108.mail.ukl.yahoo.com> References: <940950.96289.qm@web27108.mail.ukl.yahoo.com> Message-ID: Daniel, can you try just going back to 5.2.6 and running scripts\win\update? You should be able to build the current source the last "official" Win32 binaries, as long as you build in the correct order and all, which the update.cmd does. You know, there's a certain mentality around bootstrapping and keeping the connection back to the previous version, that I upheld. As long as you are careful, you can go from old binaries to new binaries, you don't have to get the new binaries magically somewhere, though you do need the old binaries magically from somewhere. :) Perhaps there's a regression. I can check "later". - Jay Date: Wed, 19 Sep 2007 00:49:57 +0200From: dabenavidesd at yahoo.esTo: hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compilerHi:I have compiled with the Jay produced 5.5 bootstrap compiler, and also with 5.1.3a, 5.2.6 and get the same error.Thanks>You need to compile the new m3core with the old compiler so that the >symbol is available to you when you compile using the new compiler. >This is a classical bootstrapping problem.>On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote:> Hi:> Thanks for your answer, I have done that and also I get the same > runtime error> in the same source file:>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3> --- building in NT386 --->> ignoring ..\src\m3overrides>> new source -> compiling RTHooks.i3> new source -> compiling RT0.i3> new source -> compiling RuntimeError.i3> new source -> compiling Word.i3> new source -> compiling RTException.i3> new source -> compiling RTHooks.m3> new source -> compiling RT0.m3> new source -> compiling Compiler.i3> new source -> compiling RuntimeError.m3> new source -> compiling Compiler.m3> new source -> compiling RTAllocator.i3> new source -> compiling RTType.i3> new source -> compiling Csetjmp.i3> new source -> compiling BasicCtypes.i3> new source -> compiling Ctypes.i3> new source -> compiling RTMachine.i3> new source -> compiling RTHeapDep.i3> new source -> compiling RTHeapRep.i3> new source -> compiling ThreadF.i3> new source -> compiling RTOS.i3> new source -> compiling RTMisc.i3> new source -> compiling RTHeap.i3> new source -> compiling Cstdlib.i3> new source -> compiling Cstddef.i3> new source -> compiling RTAllocCnts.i3> new source -> compiling RTAllocator.m3> new source -> compiling RTAllocStats.i3> new source -> compiling Convert.i3> new source -> compiling TextClass.i3> new source -> compiling Text.i3> new source -> compiling RTProcedureSRC.i3> new source -> compiling Fingerprint.i3> new source -> compiling RTProcedure.i3> new source -> compiling RTStack.i3> new source -> compiling RTAllocStats.m3> "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R> THooks.AllocateTracedRef)>>> ***> *** runtime error:> *** Attempt to reference an illegal memory location.> *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3> ***>> Stack trace:> FP PC Procedure> --------- --------- -------------------------------> 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3> 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3> 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3> 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3> 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3> 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3> 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3> 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3> 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3> 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3> ......... ......... ... more frames ...>> C:\cm3-cvs\cm3\m3-libs\m3core>> >You need to recompile m3core before compiling with the new compiler.>> >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote:>> > Hi all:> > Im getting this runtiem error because the symbol> >> > missing version stamps -> compiling RTAllocStats.m3> > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime> > symbol !! (R> > THooks.AllocateTracedRef)> >> > AllocateTracedRef is not defined in the m3core version of this Dll> > (I guess the change is more new than the bootstrap compiler). How> > can avoid this issue?> >> > Thanks in advance> >> > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd> > INSTALLROOT=C:\cm3> > LIB=%INSTALLROOT%\LIB;%LIB%> > CM3ROOT=C:\\cm3-cvs\\cm3> > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override -> > DROOT=C:\\cm3-c> > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner> > m3tools m3cgcat m3c> > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph> > parseparams realgeo> > metry set slisp sortedtableextras table-list tempfiles tcp tapi> > === package C:\cm3-cvs\cm3\m3-win\import-libs ===> > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++> > --- building in NT386 ---> >> > unable to read ..\src\m3overrides, options "-override" and "-x"> > ignored.> > === package C:\cm3-cvs\cm3\m3-libs\m3core ===> > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++> > --- building in NT386 ---> >> > missing version stamps -> compiling RTAllocStats.m3> > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime> > symbol !! (R> > THooks.AllocateTracedRef)> >> >> > ***> > *** runtime error:> > *** Attempt to reference an illegal memory location.> > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3> > ***> >> > Stack trace:> > FP PC Procedure> > --------- --------- -------------------------------> > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386> > \RTSignal.m3> > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3> > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3> > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3> > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3> > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3> > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3> > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3> > 0x12f63c 0x544d7f PrepForEmit + 0x81 in> ..\src\stmts\AssignStmt.m3> > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3> > ......... ......... ... more frames ...> > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3> > failed with 0 ***> > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -> > override -DROOT=C> > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake> > m3scanner m3tools m3c> > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector> > digraph parseparams> > realgeometry set slisp sortedtableextras table-list tempfiles tcp> > tapi failed> >> > C:\cm3-cvs\cm3\scripts\win> S? un Mejor Amante del Cine?Quieres saber c?mo? ?Deja que otras personas te ayuden! . _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 19 16:55:24 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 19 Sep 2007 10:55:24 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: References: <940950.96289.qm@web27108.mail.ukl.yahoo.com> Message-ID: <889F2EFF-2F38-4FB8-BBF2-08104548E060@cs.purdue.edu> It strikes me that you may need to sequence as follows to avoid running into having a compiler that does not handle LONGINT. Using the "devel_LONGINT_start" tagged versions of m3core and libm3 from CVS, using your original compiler, build and ship in the following order: m3core (devel_LONGINT_start) libm3 (devel_LONGINT_start) m3middle m3linker m3front m3quake cm3 Now you have a new compiler linked against the old m3core. Using the new compiler (in cm3/NT386), and the CVS head versions of m3core and libm3, build and ship in the following order: m3core (CVS head) libm3 (CVS head) m3middle m3linker m3front m3quake cm3 Now you have a new compiler linked against the new m3core. Copy this new compiler to your CM3 installation bin directory. Use this new compiler to rebuild the world. On Sep 18, 2007, at 8:41 PM, Jay wrote: > Daniel, can you try just going back to 5.2.6 and running scripts\win > \update? > You should be able to build the current source the last "official" > Win32 binaries, as long as you build in the correct order and all, > which the update.cmd does. You know, there's a certain mentality > around bootstrapping and keeping the connection back to the > previous version, that I upheld. As long as you are careful, you > can go from old binaries to new binaries, you don't have to get the > new binaries magically somewhere, though you do need the old > binaries magically from somewhere. :) > > Perhaps there's a regression. I can check "later". > > - Jay > Date: Wed, 19 Sep 2007 00:49:57 +0200 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compiler > > Hi: > > I have compiled with the Jay produced 5.5 bootstrap compiler, and > also with 5.1.3a, > 5.2.6 and get the same error. > > Thanks > > >You need to compile the new m3core with the old compiler so that the > >symbol is available to you when you compile using the new compiler. > >This is a classical bootstrapping problem. > > >On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote: > > > Hi: > > Thanks for your answer, I have done that and also I get the same > > runtime error > > in the same source file: > > > > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > new source -> compiling RT0.i3 > > new source -> compiling RuntimeError.i3 > > new source -> compiling Word.i3 > > new source -> compiling RTException.i3 > > new source -> compiling RTHooks.m3 > > new source -> compiling RT0.m3 > > new source -> compiling Compiler.i3 > > new source -> compiling RuntimeError.m3 > > new source -> compiling Compiler.m3 > > new source -> compiling RTAllocator.i3 > > new source -> compiling RTType.i3 > > new source -> compiling Csetjmp.i3 > > new source -> compiling BasicCtypes.i3 > > new source -> compiling Ctypes.i3 > > new source -> compiling RTMachine.i3 > > new source -> compiling RTHeapDep.i3 > > new source -> compiling RTHeapRep.i3 > > new source -> compiling ThreadF.i3 > > new source -> compiling RTOS.i3 > > new source -> compiling RTMisc.i3 > > new source -> compiling RTHeap.i3 > > new source -> compiling Cstdlib.i3 > > new source -> compiling Cstddef.i3 > > new source -> compiling RTAllocCnts.i3 > > new source -> compiling RTAllocator.m3 > > new source -> compiling RTAllocStats.i3 > > new source -> compiling Convert.i3 > > new source -> compiling TextClass.i3 > > new source -> compiling Text.i3 > > new source -> compiling RTProcedureSRC.i3 > > new source -> compiling Fingerprint.i3 > > new source -> compiling RTProcedure.i3 > > new source -> compiling RTStack.i3 > > new source -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > > > *** > > *** runtime error: > > *** Attempt to reference an illegal memory location. > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > *** > > > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > \RTSignal.m3 > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > ......... ......... ... more frames ... > > > > C:\cm3-cvs\cm3\m3-libs\m3core> > > >You need to recompile m3core before compiling with the new > compiler. > > > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > > > > > Hi all: > > > Im getting this runtiem error because the symbol > > > > > > missing version stamps -> compiling RTAllocStats.m3 > > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined > runtime > > > symbol !! (R > > > THooks.AllocateTracedRef) > > > > > > AllocateTracedRef is not defined in the m3core version of this Dll > > > (I guess the change is more new than the bootstrap compiler). How > > > can avoid this issue? > > > > > > Thanks in advance > > > > > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > > > INSTALLROOT=C:\cm3 > > > LIB=%INSTALLROOT%\LIB;%LIB% > > > CM3ROOT=C:\\cm3-cvs\\cm3 > > > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > > > DROOT=C:\\cm3-c > > > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > > > m3tools m3cgcat m3c > > > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > > > parseparams realgeo > > > metry set slisp sortedtableextras table-list tempfiles tcp tapi > > > === package C:\cm3-cvs\cm3\m3-win\import-libs === > > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > > --- building in NT386 --- > > > > > > unable to read ..\src\m3overrides, options "-override" and "-x" > > > ignored. > > > === package C:\cm3-cvs\cm3\m3-libs\m3core === > > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > > --- building in NT386 --- > > > > > > missing version stamps -> compiling RTAllocStats.m3 > > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined > runtime > > > symbol !! (R > > > THooks.AllocateTracedRef) > > > > > > > > > *** > > > *** runtime error: > > > *** Attempt to reference an illegal memory location. > > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > > *** > > > > > > Stack trace: > > > FP PC Procedure > > > --------- --------- ------------------------------- > > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > > \RTSignal.m3 > > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > > ..\src\stmts\AssignStmt.m3 > > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > > ......... ......... ... more frames ... > > > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > > > failed with 0 *** > > > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > > > override -DROOT=C > > > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > > > m3scanner m3tools m3c > > > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > > > digraph parseparams > > > realgeometry set slisp sortedtableextras table-list tempfiles tcp > > > tapi failed > > > > > > C:\cm3-cvs\cm3\scripts\win> > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . > > Make your little one a shining star! Shine on! From dabenavidesd at yahoo.es Thu Sep 20 17:15:01 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 20 Sep 2007 17:15:01 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <889F2EFF-2F38-4FB8-BBF2-08104548E060@cs.purdue.edu> Message-ID: <894591.8437.qm@web27109.mail.ukl.yahoo.com> Hi: Thanks for your suggestions. I have tried the scripts/win/upgrade.cmd, and It does compile and then you can execute do-cm3-std.cmd. However I noticed the that script exports a m3core pkg to the repository with a m3core-d5.5 like suffix. Not sure what is this for. I will test if it can recognize the LONGINT datatype. Also I have a question about Tony's suggestion. The packages m3objfile and m3back are not ncessary on the stages you mention for NT386 target? Thanks --- Tony Hosking escribi?: > It strikes me that you may need to sequence as > follows to avoid > running into having a compiler that does not handle > LONGINT. > > Using the "devel_LONGINT_start" tagged versions of > m3core and libm3 > from CVS, > using your original compiler, build and ship in the > following order: > > m3core (devel_LONGINT_start) > libm3 (devel_LONGINT_start) > m3middle > m3linker > m3front > m3quake > cm3 > > Now you have a new compiler linked against the old > m3core. > > Using the new compiler (in cm3/NT386), and the CVS > head versions of > m3core and libm3, > build and ship in the following order: > > m3core (CVS head) > libm3 (CVS head) > m3middle > m3linker > m3front > m3quake > cm3 > > Now you have a new compiler linked against the new > m3core. > > Copy this new compiler to your CM3 installation bin > directory. > > Use this new compiler to rebuild the world. > > > On Sep 18, 2007, at 8:41 PM, Jay wrote: > > > Daniel, can you try just going back to 5.2.6 and > running scripts\win > > \update? > > You should be able to build the current source the > last "official" > > Win32 binaries, as long as you build in the > correct order and all, > > which the update.cmd does. You know, there's a > certain mentality > > around bootstrapping and keeping the connection > back to the > > previous version, that I upheld. As long as you > are careful, you > > can go from old binaries to new binaries, you > don't have to get the > > new binaries magically somewhere, though you do > need the old > > binaries magically from somewhere. :) > > > > Perhaps there's a regression. I can check "later". > > > > - Jay > > Date: Wed, 19 Sep 2007 00:49:57 +0200 > > From: dabenavidesd at yahoo.es > > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Subject: Re: [M3devel] NT386 with cm3-5.5 > bootstrap compiler > > > > Hi: > > > > I have compiled with the Jay produced 5.5 > bootstrap compiler, and > > also with 5.1.3a, > > 5.2.6 and get the same error. > > > > Thanks > > > > >You need to compile the new m3core with the old > compiler so that the > > >symbol is available to you when you compile using > the new compiler. > > >This is a classical bootstrapping problem. > > > > >On Sep 18, 2007, at 6:30 PM, Daniel Alejandro > Benavides D. wrote: > > > > > Hi: > > > Thanks for your answer, I have done that and > also I get the same > > > runtime error > > > in the same source file: > > > > > > > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > > > --- building in NT386 --- > > > > > > ignoring ..\src\m3overrides > > > > > > new source -> compiling RTHooks.i3 > > > new source -> compiling RT0.i3 > > > new source -> compiling RuntimeError.i3 > > > new source -> compiling Word.i3 > > > new source -> compiling RTException.i3 > > > new source -> compiling RTHooks.m3 > > > new source -> compiling RT0.m3 > > > new source -> compiling Compiler.i3 > > > new source -> compiling RuntimeError.m3 > > > new source -> compiling Compiler.m3 > > > new source -> compiling RTAllocator.i3 > > > new source -> compiling RTType.i3 > > > new source -> compiling Csetjmp.i3 > > > new source -> compiling BasicCtypes.i3 > > > new source -> compiling Ctypes.i3 > > > new source -> compiling RTMachine.i3 > > > new source -> compiling RTHeapDep.i3 > > > new source -> compiling RTHeapRep.i3 > > > new source -> compiling ThreadF.i3 > > > new source -> compiling RTOS.i3 > > > new source -> compiling RTMisc.i3 > > > new source -> compiling RTHeap.i3 > > > new source -> compiling Cstdlib.i3 > > > new source -> compiling Cstddef.i3 > > > new source -> compiling RTAllocCnts.i3 > > > new source -> compiling RTAllocator.m3 > > > new source -> compiling RTAllocStats.i3 > > > new source -> compiling Convert.i3 > > > new source -> compiling TextClass.i3 > > > new source -> compiling Text.i3 > > > new source -> compiling RTProcedureSRC.i3 > > > new source -> compiling Fingerprint.i3 > > > new source -> compiling RTProcedure.i3 > > > new source -> compiling RTStack.i3 > > > new source -> compiling RTAllocStats.m3 > > > "..\src\runtime\common\RTAllocStats.m3", line > 46: undefined runtime > > > symbol !! (R > > > THooks.AllocateTracedRef) > > > > > > > > > *** > > > *** runtime error: > > > *** Attempt to reference an illegal memory > location. > > > *** pc = 0x4c4a0d = StartCall + 0xf in > ..\src\values\Procedure.m3 > > > *** > > > > > > Stack trace: > > > FP PC Procedure > > > --------- --------- > ------------------------------- > > > 0x12f494 0x60b3ce SystemError + 0x66 in > ..\src\runtime\NT386 > > > \RTSignal.m3 > > > 0x12f4c4 0x4c4a0d StartCall + 0xf in > ..\src\values\Procedure.m3 > > > 0x12f524 0x51beb8 GenRecord + 0x73 in > ..\src\builtinOps\New.m3 > > > 0x12f58c 0x51b8a3 GenRef + 0x111 in > ..\src\builtinOps\New.m3 > > > 0x12f5c8 0x51b70f Gen + 0x12d in > ..\src\builtinOps\New.m3 > > > 0x12f5e0 0x51b4a3 Prep + 0x15 in > ..\src\builtinOps\New.m3 > > > 0x12f600 0x550f08 Prep + 0x75 in > ..\src\exprs\CallExpr.m3 > > > 0x12f61c 0x54312d Prep + 0x54 in > ..\src\exprs\Expr.m3 > > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > ..\src\stmts\AssignStmt.m3 > > > 0x12f66c 0x54453b Compile + 0xd6 in > ..\src\stmts\AssignStmt.m3 > > > ......... ......... ... more frames ... > > > > > > C:\cm3-cvs\cm3\m3-libs\m3core> > > > >You need to recompile m3core before compiling > with the new > > compiler. > > > > > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro > Benavides D. wrote: > > > > > > > Hi all: > > > > Im getting this runtiem error because the > symbol > > > > > > > > missing version stamps -> compiling > RTAllocStats.m3 > > > > "..\src\runtime\common\RTAllocStats.m3", line > 46: undefined > > runtime > > > > symbol !! (R > > > > THooks.AllocateTracedRef) > > > > > > > > AllocateTracedRef is not defined in the m3core > version === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Thu Sep 20 18:15:26 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Sep 2007 12:15:26 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <894591.8437.qm@web27109.mail.ukl.yahoo.com> References: <894591.8437.qm@web27109.mail.ukl.yahoo.com> Message-ID: On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your suggestions. I have tried the > scripts/win/upgrade.cmd, and It does compile and then > you can execute do-cm3-std.cmd. > > However I noticed the that script exports a m3core pkg > to the repository with a m3core-d5.5 like suffix. Not > sure what is this for. > > I will test if it can recognize the LONGINT datatype. > > Also I have a question about Tony's suggestion. The > packages m3objfile and m3back are not ncessary on the > stages you mention for NT386 target? Oh, yes, of course they are. Sorry, I forgot about that for NT386. > > Thanks > > --- Tony Hosking escribi?: > >> It strikes me that you may need to sequence as >> follows to avoid >> running into having a compiler that does not handle >> LONGINT. >> >> Using the "devel_LONGINT_start" tagged versions of >> m3core and libm3 >> from CVS, >> using your original compiler, build and ship in the >> following order: >> >> m3core (devel_LONGINT_start) >> libm3 (devel_LONGINT_start) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the old >> m3core. >> >> Using the new compiler (in cm3/NT386), and the CVS >> head versions of >> m3core and libm3, >> build and ship in the following order: >> >> m3core (CVS head) >> libm3 (CVS head) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the new >> m3core. >> >> Copy this new compiler to your CM3 installation bin >> directory. >> >> Use this new compiler to rebuild the world. >> >> >> On Sep 18, 2007, at 8:41 PM, Jay wrote: >> >>> Daniel, can you try just going back to 5.2.6 and >> running scripts\win >>> \update? >>> You should be able to build the current source the >> last "official" >>> Win32 binaries, as long as you build in the >> correct order and all, >>> which the update.cmd does. You know, there's a >> certain mentality >>> around bootstrapping and keeping the connection >> back to the >>> previous version, that I upheld. As long as you >> are careful, you >>> can go from old binaries to new binaries, you >> don't have to get the >>> new binaries magically somewhere, though you do >> need the old >>> binaries magically from somewhere. :) >>> >>> Perhaps there's a regression. I can check "later". >>> >>> - Jay >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 >>> From: dabenavidesd at yahoo.es >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> >>> Hi: >>> >>> I have compiled with the Jay produced 5.5 >> bootstrap compiler, and >>> also with 5.1.3a, >>> 5.2.6 and get the same error. >>> >>> Thanks >>> >>>> You need to compile the new m3core with the old >> compiler so that the >>>> symbol is available to you when you compile using >> the new compiler. >>>> This is a classical bootstrapping problem. >>> >>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro >> Benavides D. wrote: >>> >>>> Hi: >>>> Thanks for your answer, I have done that and >> also I get the same >>>> runtime error >>>> in the same source file: >>>> >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3 >>>> --- building in NT386 --- >>>> >>>> ignoring ..\src\m3overrides >>>> >>>> new source -> compiling RTHooks.i3 >>>> new source -> compiling RT0.i3 >>>> new source -> compiling RuntimeError.i3 >>>> new source -> compiling Word.i3 >>>> new source -> compiling RTException.i3 >>>> new source -> compiling RTHooks.m3 >>>> new source -> compiling RT0.m3 >>>> new source -> compiling Compiler.i3 >>>> new source -> compiling RuntimeError.m3 >>>> new source -> compiling Compiler.m3 >>>> new source -> compiling RTAllocator.i3 >>>> new source -> compiling RTType.i3 >>>> new source -> compiling Csetjmp.i3 >>>> new source -> compiling BasicCtypes.i3 >>>> new source -> compiling Ctypes.i3 >>>> new source -> compiling RTMachine.i3 >>>> new source -> compiling RTHeapDep.i3 >>>> new source -> compiling RTHeapRep.i3 >>>> new source -> compiling ThreadF.i3 >>>> new source -> compiling RTOS.i3 >>>> new source -> compiling RTMisc.i3 >>>> new source -> compiling RTHeap.i3 >>>> new source -> compiling Cstdlib.i3 >>>> new source -> compiling Cstddef.i3 >>>> new source -> compiling RTAllocCnts.i3 >>>> new source -> compiling RTAllocator.m3 >>>> new source -> compiling RTAllocStats.i3 >>>> new source -> compiling Convert.i3 >>>> new source -> compiling TextClass.i3 >>>> new source -> compiling Text.i3 >>>> new source -> compiling RTProcedureSRC.i3 >>>> new source -> compiling Fingerprint.i3 >>>> new source -> compiling RTProcedure.i3 >>>> new source -> compiling RTStack.i3 >>>> new source -> compiling RTAllocStats.m3 >>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined runtime >>>> symbol !! (R >>>> THooks.AllocateTracedRef) >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Attempt to reference an illegal memory >> location. >>>> *** pc = 0x4c4a0d = StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- >> ------------------------------- >>>> 0x12f494 0x60b3ce SystemError + 0x66 in >> ..\src\runtime\NT386 >>>> \RTSignal.m3 >>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> 0x12f524 0x51beb8 GenRecord + 0x73 in >> ..\src\builtinOps\New.m3 >>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in >> ..\src\builtinOps\New.m3 >>>> 0x12f5c8 0x51b70f Gen + 0x12d in >> ..\src\builtinOps\New.m3 >>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in >> ..\src\builtinOps\New.m3 >>>> 0x12f600 0x550f08 Prep + 0x75 in >> ..\src\exprs\CallExpr.m3 >>>> 0x12f61c 0x54312d Prep + 0x54 in >> ..\src\exprs\Expr.m3 >>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in >> ..\src\stmts\AssignStmt.m3 >>>> 0x12f66c 0x54453b Compile + 0xd6 in >> ..\src\stmts\AssignStmt.m3 >>>> ......... ......... ... more frames ... >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core> >>>>> You need to recompile m3core before compiling >> with the new >>> compiler. >>>> >>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro >> Benavides D. wrote: >>>> >>>>> Hi all: >>>>> Im getting this runtiem error because the >> symbol >>>>> >>>>> missing version stamps -> compiling >> RTAllocStats.m3 >>>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined >>> runtime >>>>> symbol !! (R >>>>> THooks.AllocateTracedRef) >>>>> >>>>> AllocateTracedRef is not defined in the m3core >> version > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Thu Sep 20 22:53:35 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 20 Sep 2007 22:53:35 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: Message-ID: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Hi: The script upgarde.cmd produced compiler does recognize the LONGINT as a reserved word. I can get this error when compiling the m2libs of m2tom3 compiler: new source -> compiling SYSTEM.i3 "..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT) 1 error encountered Thanks again >On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your suggestions. I have tried the > scripts/win/upgrade.cmd, and It does compile and then > you can execute do-cm3-std.cmd. > > However I noticed the that script exports a m3core pkg > to the repository with a m3core-d5.5 like suffix. Not > sure what is this for. > > I will test if it can recognize the LONGINT datatype. > > Also I have a question about Tony's suggestion. The > packages m3objfile and m3back are not ncessary on the > stages you mention for NT386 target? >Oh, yes, of course they are. Sorry, I forgot about that for NT386. > > Thanks > > --- Tony Hosking escribi?: > >> It strikes me that you may need to sequence as >> follows to avoid >> running into having a compiler that does not handle >> LONGINT. >> >> Using the "devel_LONGINT_start" tagged versions of >> m3core and libm3 >> from CVS, >> using your original compiler, build and ship in the >> following order: >> >> m3core (devel_LONGINT_start) >> libm3 (devel_LONGINT_start) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the old >> m3core. >> >> Using the new compiler (in cm3/NT386), and the CVS >> head versions of >> m3core and libm3, >> build and ship in the following order: >> >> m3core (CVS head) >> libm3 (CVS head) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the new >> m3core. >> >> Copy this new compiler to your CM3 installation bin >> directory. >> >> Use this new compiler to rebuild the world. >> >> >> On Sep 18, 2007, at 8:41 PM, Jay wrote: >> >>> Daniel, can you try just going back to 5.2.6 and >> running scripts\win >>> \update? >>> You should be able to build the current source the >> last "official" >>> Win32 binaries, as long as you build in the >> correct order and all, >>> which the update.cmd does. You know, there's a >> certain mentality >>> around bootstrapping and keeping the connection >> back to the >>> previous version, that I upheld. As long as you >> are careful, you >>> can go from old binaries to new binaries, you >> don't have to get the >>> new binaries magically somewhere, though you do >> need the old >>> binaries magically from somewhere. :) >>> >>> Perhaps there's a regression. I can check "later". >>> >>> - Jay >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 >>> From: dabenavidesd at yahoo.es >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> >>> Hi: >>> >>> I have compiled with the Jay produced 5.5 >> bootstrap compiler, and >>> also with 5.1.3a, >>> 5.2.6 and get the same error. >>> >>> Thanks >>> >>>> You need to compile the new m3core with the old >> compiler so that the >>>> symbol is available to you when you compile using >> the new compiler. >>>> This is a classical bootstrapping problem. >>> >>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro >> Benavides D. wrote: >>> >>>> Hi: >>>> Thanks for your answer, I have done that and >> also I get the same >>>> runtime error >>>> in the same source file: >>>> >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3 >>>> --- building in NT386 --- >>>> >>>> ignoring ..\src\m3overrides >>>> >>>> new source -> compiling RTHooks.i3 >>>> new source -> compiling RT0.i3 >>>> new source -> compiling RuntimeError.i3 >>>> new source -> compiling Word.i3 >>>> new source -> compiling RTException.i3 >>>> new source -> compiling RTHooks.m3 >>>> new source -> compiling RT0.m3 >>>> new source -> compiling Compiler.i3 >>>> new source -> compiling RuntimeError.m3 >>>> new source -> compiling Compiler.m3 >>>> new source -> compiling RTAllocator.i3 >>>> new source -> compiling RTType.i3 >>>> new source -> compiling Csetjmp.i3 >>>> new source -> compiling BasicCtypes.i3 >>>> new source -> compiling Ctypes.i3 >>>> new source -> compiling RTMachine.i3 >>>> new source -> compiling RTHeapDep.i3 >>>> new source -> compiling RTHeapRep.i3 >>>> new source -> compiling ThreadF.i3 >>>> new source -> compiling RTOS.i3 >>>> new source -> compiling RTMisc.i3 >>>> new source -> compiling RTHeap.i3 >>>> new source -> compiling Cstdlib.i3 >>>> new source -> compiling Cstddef.i3 >>>> new source -> compiling RTAllocCnts.i3 >>>> new source -> compiling RTAllocator.m3 >>>> new source -> compiling RTAllocStats.i3 >>>> new source -> compiling Convert.i3 >>>> new source -> compiling TextClass.i3 >>>> new source -> compiling Text.i3 >>>> new source -> compiling RTProcedureSRC.i3 >>>> new source -> compiling Fingerprint.i3 >>>> new source -> compiling RTProcedure.i3 >>>> new source -> compiling RTStack.i3 >>>> new source -> compiling RTAllocStats.m3 >>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined runtime >>>> symbol !! (R >>>> THooks.AllocateTracedRef) >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Attempt to reference an illegal memory >> location. >>>> *** pc = 0x4c4a0d = StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- >> ------------------------------- >>>> 0x12f494 0x60b3ce SystemError + 0x66 in >> ..\src\runtime\NT386 >>>> \RTSignal.m3 >>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> 0x12f524 0x51beb8 GenRecord + 0x73 in >> ..\src\builtinOps\New.m3 >>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in >> ..\src\builtinOps\New.m3 >>>> 0x12f5c8 0x51b70f Gen + 0x12d in >> ..\src\builtinOps\New.m3 >>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in >> ..\src\builtinOps\New.m3 >>>> 0x12f600 0x550f08 Prep + 0x75 in >> ..\src\exprs\CallExpr.m3 >>>> 0x12f61c 0x54312d Prep + 0x54 in >> ..\src\exprs\Expr.m3 >>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in >> ..\src\stmts\AssignStmt.m3 >>>> 0x12f66c 0x54453b Compile + 0xd6 in >> ..\src\stmts\AssignStmt.m3 >>>> ......... ......... ... more frames ... >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core> >>>>> You need to recompile m3core before compiling >> with the new >>> compiler. >>>> >>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro >> Benavides D. wrote: >>>> >>>>> Hi all: >>>>> Im getting this runtiem error because the >> symbol >>>>> >>>>> missing version stamps -> compiling >> RTAllocStats.m3 >>>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined >>> runtime >>>>> symbol !! (R >>>>> THooks.AllocateTracedRef) >>>>> >>>>> AllocateTracedRef is not defined in the m3core >> version --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 21 02:49:21 2007 From: jay.krell at cornell.edu (Jay) Date: Fri, 21 Sep 2007 00:49:21 +0000 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <9243.42411.qm@web27110.mail.ukl.yahoo.com> References: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Message-ID: The "-d5.5" thing is a backup of the package repository. Indeed I find it annoying sometimes, but I mimiced upgrade.sh and I'd have to think it all through again before deleting/changing how it works. I think it makes it easier to back out of a broken change. If you end up with non-working stuff, you copy pkg-d5.5 back on top of pkg. I really strongly suspect update.cmd works. I don't remember if it upgrades...oh, sorry, wrong script I think. make-dist.cmd? How about that one? Whichever one creates .tar.bz2 files. That's the one I meant. Oops, sorry sorry sorry. :\ - Jay Date: Thu, 20 Sep 2007 22:53:35 +0200From: dabenavidesd at yahoo.esTo: hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compilerHi:The script upgarde.cmd produced compiler does recognize the LONGINT as a reserved word.I can get this error when compiling the m2libs of m2tom3 compiler:new source -> compiling SYSTEM.i3"..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT)1 error encounteredThanks again>On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote:> Hi:> Thanks for your suggestions. I have tried the> scripts/win/upgrade.cmd, and It does compile and then> you can execute do-cm3-std.cmd.>> However I noticed the that script exports a m3core pkg> to the repository with a m3core-d5.5 like suffix. Not> sure what is this for.>> I will test if it can recognize the LONGINT datatype.>> Also I have a question about Tony's suggestion. The> packages m3objfile and m3back are not ncessary on the> stages you mention for NT386 target?>Oh, yes, of course they are. Sorry, I forgot about that for NT386.>> Thanks>> --- Tony Hosking escribi?:>>> It strikes me that you may need to sequence as>> follows to avoid>> running into having a compiler that does not handle>> LONGINT.>>>> Using the "devel_LONGINT_start" tagged versions of>> m3core and libm3>> from CVS,>> using your original compiler, build and ship in the>> following order:>>>> m3core (devel_LONGINT_start)>> libm3 (devel_LONGINT_start)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the old>> m3core.>>>> Using the new compiler (in cm3/NT386), and the CVS>> head versions of>> m3core and libm3,>> build and ship in the following order:>>>> m3core (CVS head)>> libm3 (CVS head)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the new>> m3core.>>>> Copy this new compiler to your CM3 installation bin>> directory.>>>> Use this new compiler to rebuild the world.>>>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote:>>>>> Daniel, can you try just going back to 5.2.6 and>> running scripts\win>>> \update?>>> You should be able to build the current source the>> last "official">>> Win32 binaries, as long as you build in the>> correct order and all,>>> which the update.cmd does. You know, there's a>> certain mentality>>> around bootstrapping and keeping the connection>> back to the>>> previous version, that I upheld. As long as you>> are careful, you>>> can go from old binaries to new binaries, you>> don't have to get the>>> new binaries magically somewhere, though you do>> need the old>>> binaries magically from somewhere. :)>>>>>> Perhaps there's a regression. I can check "later".>>>>>> - Jay>>> Date: Wed, 19 Sep 2007 00:49:57 +0200>>> From: dabenavidesd at yahoo.es>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com>>> Subject: Re: [M3devel] NT386 with cm3-5.5>> bootstrap compiler>>>>>> Hi:>>>>>> I have compiled with the Jay produced 5.5>> bootstrap compiler, and>>> also with 5.1.3a,>>> 5.2.6 and get the same error.>>>>>> Thanks>>>>>>> You need to compile the new m3core with the old>> compiler so that the>>>> symbol is available to you when you compile using>> the new compiler.>>>> This is a classical bootstrapping problem.>>>>>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>> Hi:>>>> Thanks for your answer, I have done that and>> also I get the same>>>> runtime error>>>> in the same source file:>>>>>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3>>>> --- building in NT386 --->>>>>>>> ignoring ..\src\m3overrides>>>>>>>> new source -> compiling RTHooks.i3>>>> new source -> compiling RT0.i3>>>> new source -> compiling RuntimeError.i3>>>> new source -> compiling Word.i3>>>> new source -> compiling RTException.i3>>>> new source -> compiling RTHooks.m3>>>> new source -> compiling RT0.m3>>>> new source -> compiling Compiler.i3>>>> new source -> compiling RuntimeError.m3>>>> new source -> compiling Compiler.m3>>>> new source -> compiling RTAllocator.i3>>>> new source -> compiling RTType.i3>>>> new source -> compiling Csetjmp.i3>>>> new source -> compiling BasicCtypes.i3>>>> new source -> compiling Ctypes.i3>>>> new source -> compiling RTMachine.i3>>>> new source -> compiling RTHeapDep.i3>>>> new source -> compiling RTHeapRep.i3>>>> new source -> compiling ThreadF.i3>>>> new source -> compiling RTOS.i3>>>> new source -> compiling RTMisc.i3>>>> new source -> compiling RTHeap.i3>>>> new source -> compiling Cstdlib.i3>>>> new source -> compiling Cstddef.i3>>>> new source -> compiling RTAllocCnts.i3>>>> new source -> compiling RTAllocator.m3>>>> new source -> compiling RTAllocStats.i3>>>> new source -> compiling Convert.i3>>>> new source -> compiling TextClass.i3>>>> new source -> compiling Text.i3>>>> new source -> compiling RTProcedureSRC.i3>>>> new source -> compiling Fingerprint.i3>>>> new source -> compiling RTProcedure.i3>>>> new source -> compiling RTStack.i3>>>> new source -> compiling RTAllocStats.m3>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined runtime>>>> symbol !! (R>>>> THooks.AllocateTracedRef)>>>>>>>>>>>> ***>>>> *** runtime error:>>>> *** Attempt to reference an illegal memory>> location.>>>> *** pc = 0x4c4a0d = StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> ***>>>>>>>> Stack trace:>>>> FP PC Procedure>>>> --------- --------->> ------------------------------->>>> 0x12f494 0x60b3ce SystemError + 0x66 in>> ..\src\runtime\NT386>>>> \RTSignal.m3>>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> 0x12f524 0x51beb8 GenRecord + 0x73 in>> ..\src\builtinOps\New.m3>>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in>> ..\src\builtinOps\New.m3>>>> 0x12f5c8 0x51b70f Gen + 0x12d in>> ..\src\builtinOps\New.m3>>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in>> ..\src\builtinOps\New.m3>>>> 0x12f600 0x550f08 Prep + 0x75 in>> ..\src\exprs\CallExpr.m3>>>> 0x12f61c 0x54312d Prep + 0x54 in>> ..\src\exprs\Expr.m3>>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in>> ..\src\stmts\AssignStmt.m3>>>> 0x12f66c 0x54453b Compile + 0xd6 in>> ..\src\stmts\AssignStmt.m3>>>> ......... ......... ... more frames ...>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>>>>>> You need to recompile m3core before compiling>> with the new>>> compiler.>>>>>>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>>>> Hi all:>>>>> Im getting this runtiem error because the>> symbol>>>>>>>>>> missing version stamps -> compiling>> RTAllocStats.m3>>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined>>> runtime>>>>> symbol !! (R>>>>> THooks.AllocateTracedRef)>>>>>>>>>> AllocateTracedRef is not defined in the m3core>> version S? un Mejor Amante del Cine?Quieres saber c?mo? ?Deja que otras personas te ayuden! . _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 21 02:50:51 2007 From: jay.krell at cornell.edu (Jay) Date: Fri, 21 Sep 2007 00:50:51 +0000 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <9243.42411.qm@web27110.mail.ukl.yahoo.com> References: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Message-ID: As a follow up to confirm, look where I made changes since LONGINT, I believe make-dist in particular I had to make changes to to build the right packages in the right order. I'll look into upgrade/update sometime soon.. - Jay From: jay.krell at cornell.eduTo: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: RE: [M3devel] NT386 with cm3-5.5 bootstrap compilerDate: Fri, 21 Sep 2007 00:49:21 +0000 The "-d5.5" thing is a backup of the package repository. Indeed I find it annoying sometimes, but I mimiced upgrade.sh and I'd have to think it all through again before deleting/changing how it works. I think it makes it easier to back out of a broken change. If you end up with non-working stuff, you copy pkg-d5.5 back on top of pkg. I really strongly suspect update.cmd works. I don't remember if it upgrades...oh, sorry, wrong script I think.make-dist.cmd? How about that one?Whichever one creates .tar.bz2 files. That's the one I meant. Oops, sorry sorry sorry. :\ - Jay Date: Thu, 20 Sep 2007 22:53:35 +0200From: dabenavidesd at yahoo.esTo: hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compilerHi:The script upgarde.cmd produced compiler does recognize the LONGINT as a reserved word.I can get this error when compiling the m2libs of m2tom3 compiler:new source -> compiling SYSTEM.i3"..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT)1 error encounteredThanks again>On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote:> Hi:> Thanks for your suggestions. I have tried the> scripts/win/upgrade.cmd, and It does compile and then> you can execute do-cm3-std.cmd.>> However I noticed the that script exports a m3core pkg> to the repository with a m3core-d5.5 like suffix. Not> sure what is this for.>> I will test if it can recognize the LONGINT datatype.>> Also I have a question about Tony's suggestion. The> packages m3objfile and m3back are not ncessary on the> stages you mention for NT386 target?>Oh, yes, of course they are. Sorry, I forgot about that for NT386.>> Thanks>> --- Tony Hosking escribi?:>>> It strikes me that you may need to sequence as>> follows to avoid>> running into having a compiler that does not handle>> LONGINT.>>>> Using the "devel_LONGINT_start" tagged versions of>> m3core and libm3>> from CVS,>> using your original compiler, build and ship in the>> following order:>>>> m3core (devel_LONGINT_start)>> libm3 (devel_LONGINT_start)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the old>> m3core.>>>> Using the new compiler (in cm3/NT386), and the CVS>> head versions of>> m3core and libm3,>> build and ship in the following order:>>>> m3core (CVS head)>> libm3 (CVS head)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the new>> m3core.>>>> Copy this new compiler to your CM3 installation bin>> directory.>>>> Use this new compiler to rebuild the world.>>>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote:>>>>> Daniel, can you try just going back to 5.2.6 and>> running scripts\win>>> \update?>>> You should be able to build the current source the>> last "official">>> Win32 binaries, as long as you build in the>> correct order and all,>>> which the update.cmd does. You know, there's a>> certain mentality>>> around bootstrapping and keeping the connection>> back to the>>> previous version, that I upheld. As long as you>> are careful, you>>> can go from old binaries to new binaries, you>> don't have to get the>>> new binaries magically somewhere, though you do>> need the old>>> binaries magically from somewhere. :)>>>>>> Perhaps there's a regression. I can check "later".>>>>>> - Jay>>> Date: Wed, 19 Sep 2007 00:49:57 +0200>>> From: dabenavidesd at yahoo.es>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com>>> Subject: Re: [M3devel] NT386 with cm3-5.5>> bootstrap compiler>>>>>> Hi:>>>>>> I have compiled with the Jay produced 5.5>> bootstrap compiler, and>>> also with 5.1.3a,>>> 5.2.6 and get the same error.>>>>>> Thanks>>>>>>> You need to compile the new m3core with the old>> compiler so that the>>>> symbol is available to you when you compile using>> the new compiler.>>>> This is a classical bootstrapping problem.>>>>>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>> Hi:>>>> Thanks for your answer, I have done that and>> also I get the same>>>> runtime error>>>> in the same source file:>>>>>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3>>>> --- building in NT386 --->>>>>>>> ignoring ..\src\m3overrides>>>>>>>> new source -> compiling RTHooks.i3>>>> new source -> compiling RT0.i3>>>> new source -> compiling RuntimeError.i3>>>> new source -> compiling Word.i3>>>> new source -> compiling RTException.i3>>>> new source -> compiling RTHooks.m3>>>> new source -> compiling RT0.m3>>>> new source -> compiling Compiler.i3>>>> new source -> compiling RuntimeError.m3>>>> new source -> compiling Compiler.m3>>>> new source -> compiling RTAllocator.i3>>>> new source -> compiling RTType.i3>>>> new source -> compiling Csetjmp.i3>>>> new source -> compiling BasicCtypes.i3>>>> new source -> compiling Ctypes.i3>>>> new source -> compiling RTMachine.i3>>>> new source -> compiling RTHeapDep.i3>>>> new source -> compiling RTHeapRep.i3>>>> new source -> compiling ThreadF.i3>>>> new source -> compiling RTOS.i3>>>> new source -> compiling RTMisc.i3>>>> new source -> compiling RTHeap.i3>>>> new source -> compiling Cstdlib.i3>>>> new source -> compiling Cstddef.i3>>>> new source -> compiling RTAllocCnts.i3>>>> new source -> compiling RTAllocator.m3>>>> new source -> compiling RTAllocStats.i3>>>> new source -> compiling Convert.i3>>>> new source -> compiling TextClass.i3>>>> new source -> compiling Text.i3>>>> new source -> compiling RTProcedureSRC.i3>>>> new source -> compiling Fingerprint.i3>>>> new source -> compiling RTProcedure.i3>>>> new source -> compiling RTStack.i3>>>> new source -> compiling RTAllocStats.m3>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined runtime>>>> symbol !! (R>>>> THooks.AllocateTracedRef)>>>>>>>>>>>> ***>>>> *** runtime error:>>>> *** Attempt to reference an illegal memory>> location.>>>> *** pc = 0x4c4a0d = StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> ***>>>>>>>> Stack trace:>>>> FP PC Procedure>>>> --------- --------->> ------------------------------->>>> 0x12f494 0x60b3ce SystemError + 0x66 in>> ..\src\runtime\NT386>>>> \RTSignal.m3>>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> 0x12f524 0x51beb8 GenRecord + 0x73 in>> ..\src\builtinOps\New.m3>>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in>> ..\src\builtinOps\New.m3>>>> 0x12f5c8 0x51b70f Gen + 0x12d in>> ..\src\builtinOps\New.m3>>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in>> ..\src\builtinOps\New.m3>>>> 0x12f600 0x550f08 Prep + 0x75 in>> ..\src\exprs\CallExpr.m3>>>> 0x12f61c 0x54312d Prep + 0x54 in>> ..\src\exprs\Expr.m3>>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in>> ..\src\stmts\AssignStmt.m3>>>> 0x12f66c 0x54453b Compile + 0xd6 in>> ..\src\stmts\AssignStmt.m3>>>> ......... ......... ... more frames ...>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>>>>>> You need to recompile m3core before compiling>> with the new>>> compiler.>>>>>>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>>>> Hi all:>>>>> Im getting this runtiem error because the>> symbol>>>>>>>>>> missing version stamps -> compiling>> RTAllocStats.m3>>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined>>> runtime>>>>> symbol !! (R>>>>> THooks.AllocateTracedRef)>>>>>>>>>> AllocateTracedRef is not defined in the m3core>> version S? un Mejor Amante del Cine?Quieres saber c?mo? ?Deja que otras personas te ayuden! . Make your little one a shining star! Shine on! _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 21 17:15:40 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Sep 2007 11:15:40 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: References: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Message-ID: <9CFCC906-27F5-471D-9D12-463BE33E2A28@cs.purdue.edu> On Sep 20, 2007, at 8:50 PM, Jay wrote: > As a follow up to confirm, look where I made changes since > LONGINT, I believe make-dist in particular I had to make changes to > to build the right packages in the right order. I'll look into > upgrade/update sometime soon.. > > - Jay > > From: jay.krell at cornell.edu > To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; > m3devel at elegosoft.com > Subject: RE: [M3devel] NT386 with cm3-5.5 bootstrap compiler > Date: Fri, 21 Sep 2007 00:49:21 +0000 > > The "-d5.5" thing is a backup of the package repository. Indeed I > find it annoying sometimes, but I mimiced upgrade.sh and I'd have > to think it all through again before deleting/changing how it > works. I think it makes it easier to back out of a broken change. > If you end up with non-working stuff, you copy pkg-d5.5 back on top > of pkg. > > I really strongly suspect update.cmd works. I don't remember if it > upgrades...oh, sorry, wrong script I think. > make-dist.cmd? How about that one? > Whichever one creates .tar.bz2 files. That's the one I meant. Oops, > sorry sorry sorry. :\ > > > - Jay > Date: Thu, 20 Sep 2007 22:53:35 +0200 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compiler > > Hi: > > The script upgarde.cmd produced compiler does recognize the LONGINT > as a reserved word. > > I can get this error when compiling the m2libs of m2tom3 compiler: > > > new source -> compiling SYSTEM.i3 > "..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT) > 1 error encountered > I don't see this file in the distribution. I suspect it is something to do with upgrade.cmd. I assume it is defining LONGINT for compilers that don't support it, though I fail to understand why this would be necessary. > Thanks again > > > > >On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote: > > > Hi: > > Thanks for your suggestions. I have tried the > > scripts/win/upgrade.cmd, and It does compile and then > > you can execute do-cm3-std.cmd. > > > > However I noticed the that script exports a m3core pkg > > to the repository with a m3core-d5.5 like suffix. Not > > sure what is this for. > > > > I will test if it can recognize the LONGINT datatype. > > > > Also I have a question about Tony's suggestion. The > > packages m3objfile and m3back are not ncessary on the > > stages you mention for NT386 target? > > >Oh, yes, of course they are. Sorry, I forgot about that for NT386. > > > > > Thanks > > > > --- Tony Hosking escribi?: > > > >> It strikes me that you may need to sequence as > >> follows to avoid > >> running into having a compiler that does not handle > >> LONGINT. > >> > >> Using the "devel_LONGINT_start" tagged versions of > >> m3core and libm3 > >> from CVS, > >> using your original compiler, build and ship in the > >> following order: > >> > >> m3core (devel_LONGINT_start) > >> libm3 (devel_LONGINT_start) > >> m3middle > >> m3linker > >> m3front > >> m3quake > >> cm3 > >> > >> Now you have a new compiler linked against the old > >> m3core. > >> > >> Using the new compiler (in cm3/NT386), and the CVS > >> head versions of > >> m3core and libm3, > >> build and ship in the following order: > >> > >> m3core (CVS head) > >> libm3 (CVS head) > >> m3middle > >> m3linker > >> m3front > >> m3quake > >> cm3 > >> > >> Now you have a new compiler linked against the new > >> m3core. > >> > >> Copy this new compiler to your CM3 installation bin > >> directory. > >> > >> Use this new compiler to rebuild the world. > >> > >> > >> On Sep 18, 2007, at 8:41 PM, Jay wrote: > >> > >>> Daniel, can you try just going back to 5.2.6 and > >> running scripts\win > >>> \update? > >>> You should be able to build the current source the > >> last "official" > >>> Win32 binaries, as long as you build in the > >> correct order and all, > >>> which the update.cmd does. You know, there's a > >> certain mentality > >>> around bootstrapping and keeping the connection > >> back to the > >>> previous version, that I upheld. As long as you > >> are careful, you > >>> can go from old binaries to new binaries, you > >> don't have to get the > >>> new binaries magically somewhere, though you do > >> need the old > >>> binaries magically from somewhere. :) > >>> > >>> Perhaps there's a regression. I can check "later". > >>> > >>> - Jay > >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 > >>> From: dabenavidesd at yahoo.es > >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com > >>> Subject: Re: [M3devel] NT386 with cm3-5.5 > >> bootstrap compiler > >>> > >>> Hi: > >>> > >>> I have compiled with the Jay produced 5.5 > >> bootstrap compiler, and > >>> also with 5.1.3a, > >>> 5.2.6 and get the same error. > >>> > >>> Thanks > >>> > >>>> You need to compile the new m3core with the old > >> compiler so that the > >>>> symbol is available to you when you compile using > >> the new compiler. > >>>> This is a classical bootstrapping problem. > >>> > >>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro > >> Benavides D. wrote: > >>> > >>>> Hi: > >>>> Thanks for your answer, I have done that and > >> also I get the same > >>>> runtime error > >>>> in the same source file: > >>>> > >>>> > >>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > >>>> --- building in NT386 --- > >>>> > >>>> ignoring ..\src\m3overrides > >>>> > >>>> new source -> compiling RTHooks.i3 > >>>> new source -> compiling RT0.i3 > >>>> new source -> compiling RuntimeError.i3 > >>>> new source -> compiling Word.i3 > >>>> new source -> compiling RTException.i3 > >>>> new source -> compiling RTHooks.m3 > >>>> new source -> compiling RT0.m3 > >>>> new source -> compiling Compiler.i3 > >>>> new source -> compiling RuntimeError.m3 > >>>> new source -> compiling Compiler.m3 > >>>> new source -> compiling RTAllocator.i3 > >>>> new source -> compiling RTType.i3 > >>>> new source -> compiling Csetjmp.i3 > >>>> new source -> compiling BasicCtypes.i3 > >>>> new source -> compiling Ctypes.i3 > >>>> new source -> compiling RTMachine.i3 > >>>> new source -> compiling RTHeapDep.i3 > >>>> new source -> compiling RTHeapRep.i3 > >>>> new source -> compiling ThreadF.i3 > >>>> new source -> compiling RTOS.i3 > >>>> new source -> compiling RTMisc.i3 > >>>> new source -> compiling RTHeap.i3 > >>>> new source -> compiling Cstdlib.i3 > >>>> new source -> compiling Cstddef.i3 > >>>> new source -> compiling RTAllocCnts.i3 > >>>> new source -> compiling RTAllocator.m3 > >>>> new source -> compiling RTAllocStats.i3 > >>>> new source -> compiling Convert.i3 > >>>> new source -> compiling TextClass.i3 > >>>> new source -> compiling Text.i3 > >>>> new source -> compiling RTProcedureSRC.i3 > >>>> new source -> compiling Fingerprint.i3 > >>>> new source -> compiling RTProcedure.i3 > >>>> new source -> compiling RTStack.i3 > >>>> new source -> compiling RTAllocStats.m3 > >>>> "..\src\runtime\common\RTAllocStats.m3", line > >> 46: undefined runtime > >>>> symbol !! (R > >>>> THooks.AllocateTracedRef) > >>>> > >>>> > >>>> *** > >>>> *** runtime error: > >>>> *** Attempt to reference an illegal memory > >> location. > >>>> *** pc = 0x4c4a0d = StartCall + 0xf in > >> ..\src\values\Procedure.m3 > >>>> *** > >>>> > >>>> Stack trace: > >>>> FP PC Procedure > >>>> --------- --------- > >> ------------------------------- > >>>> 0x12f494 0x60b3ce SystemError + 0x66 in > >> ..\src\runtime\NT386 > >>>> \RTSignal.m3 > >>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in > >> ..\src\values\Procedure.m3 > >>>> 0x12f524 0x51beb8 GenRecord + 0x73 in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f5c8 0x51b70f Gen + 0x12d in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f600 0x550f08 Prep + 0x75 in > >> ..\src\exprs\CallExpr.m3 > >>>> 0x12f61c 0x54312d Prep + 0x54 in > >> ..\src\exprs\Expr.m3 > >>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in > >> ..\src\stmts\AssignStmt.m3 > >>>> 0x12f66c 0x54453b Compile + 0xd6 in > >> ..\src\stmts\AssignStmt.m3 > >>>> ......... ......... ... more frames ... > >>>> > >>>> C:\cm3-cvs\cm3\m3-libs\m3core> > >>>>> You need to recompile m3core before compiling > >> with the new > >>> compiler. > >>>> > >>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro > >> Benavides D. wrote: > >>>> > >>>>> Hi all: > >>>>> Im getting this runtiem error because the > >> symbol > >>>>> > >>>>> missing version stamps -> compiling > >> RTAllocStats.m3 > >>>>> "..\src\runtime\common\RTAllocStats.m3", line > >> 46: undefined > >>> runtime > >>>>> symbol !! (R > >>>>> THooks.AllocateTracedRef) > >>>>> > >>>>> AllocateTracedRef is not defined in the m3core > >> version > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . > > Make your little one a shining star! Shine on! > Make your little one a shining star! Shine on! From dabenavidesd at yahoo.es Fri Sep 21 18:18:08 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 21 Sep 2007 18:18:08 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <9CFCC906-27F5-471D-9D12-463BE33E2A28@cs.purdue.edu> Message-ID: <724862.70169.qm@web27112.mail.ukl.yahoo.com> Hi: Oh Im sorry I meant, that the compiler is working Ok with LONGINT, at least because is recognizing that LONGINT is a reserved word. SYSTEM.i3 is just source file of the m2tom3 Modula-2 to Modula-3 compiler; I used as a test for the cm3 compiler, beside it is an example of Modula-2 and Modula-3 using a common type LONGINT. Thanks --- Tony Hosking escribi?: > > On Sep 20, 2007, at 8:50 PM, Jay wrote: > > > As a follow up to confirm, look where I made > changes since > > LONGINT, I believe make-dist in particular I had > to make changes to > > to build the right packages in the right order. > I'll look into > > upgrade/update sometime soon.. > > > > - Jay > > > > From: jay.krell at cornell.edu > > To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; > > > m3devel at elegosoft.com > > Subject: RE: [M3devel] NT386 with cm3-5.5 > bootstrap compiler > > Date: Fri, 21 Sep 2007 00:49:21 +0000 > > > > The "-d5.5" thing is a backup of the package > repository. Indeed I > > find it annoying sometimes, but I mimiced > upgrade.sh and I'd have > > to think it all through again before > deleting/changing how it > > works. I think it makes it easier to back out of a > broken change. > > If you end up with non-working stuff, you copy > pkg-d5.5 back on top > > of pkg. > > > > I really strongly suspect update.cmd works. I > don't remember if it > > upgrades...oh, sorry, wrong script I think. > > make-dist.cmd? How about that one? > > Whichever one creates .tar.bz2 files. That's the > one I meant. Oops, > > sorry sorry sorry. :\ > > > > > > - Jay > > Date: Thu, 20 Sep 2007 22:53:35 +0200 > > From: dabenavidesd at yahoo.es > > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Subject: Re: [M3devel] NT386 with cm3-5.5 > bootstrap compiler > > > > Hi: > > > > The script upgrade.cmd produced compiler does > recognize the LONGINT > > as a reserved word. > > > > I can get this error when compiling the m2libs of > m2tom3 compiler: > > > > > > new source -> compiling SYSTEM.i3 > > "..\src\SYSTEM.i3", line 40: Reserved identifier > redefined (LONGINT) > > 1 error encountered > > > > I don't see this file in the distribution. I > suspect it is something > to do with upgrade.cmd. I assume it is defining > LONGINT for > compilers that don't support it, though I fail to > understand why this > would be necessary. > > > > Thanks again > > > > > > > > >On Sep 20, 2007, at 11:15 AM, Daniel Alejandro > Benavides D. wrote: > > > > > Hi: > > > Thanks for your suggestions. I have tried the > > > scripts/win/upgrade.cmd, and It does compile and > then > > > you can execute do-cm3-std.cmd. > > > > > > However I noticed the that script exports a > m3core pkg > > > to the repository with a m3core-d5.5 like > suffix. Not > > > sure what is this for. > > > > > > I will test if it can recognize the LONGINT > datatype. > > > > > > Also I have a question about Tony's suggestion. > The > > > packages m3objfile and m3back are not ncessary > on the > > > stages you mention for NT386 target? > > > > >Oh, yes, of course they are. Sorry, I forgot > about that for NT386. > > > > > > > > Thanks > > > > > > --- Tony Hosking > escribi?: > > > > > >> It strikes me that you may need to sequence as > > >> follows to avoid > > >> running into having a compiler that does not > handle > > >> LONGINT. > > >> > > >> Using the "devel_LONGINT_start" tagged versions > of > > >> m3core and libm3 > > >> from CVS, > > >> using your original compiler, build and ship in > the > > >> following order: > > >> > > >> m3core (devel_LONGINT_start) > > >> libm3 (devel_LONGINT_start) > > >> m3middle > > >> m3linker > > >> m3front > > >> m3quake > > >> cm3 > > >> > > >> Now you have a new compiler linked against the > old > > >> m3core. > > >> > > >> Using the new compiler (in cm3/NT386), and the > CVS > > >> head versions of > > >> m3core and libm3, > > >> build and ship in the following order: > > >> > > >> m3core (CVS head) > > >> libm3 (CVS head) > > >> m3middle > > >> m3linker > > >> m3front > > >> m3quake > > >> cm3 > > >> > > >> Now you have a new compiler linked against the > new > > >> m3core. > > >> > > >> Copy this new compiler to your CM3 installation > bin > > >> directory. > > >> > > >> Use this new compiler to rebuild the world. > > >> > > >> > > >> On Sep 18, 2007, at 8:41 PM, Jay wrote: > > >> > > >>> Daniel, can you try just going back to 5.2.6 > and > > >> running scripts\win > > >>> \update? > > >>> You should be able to build the current source > the > > >> last "official" > > >>> Win32 binaries, as long as you build in the > > >> correct order and all, > > >>> which the update.cmd does. You know, there's a > > >> certain mentality > > >>> around bootstrapping and keeping the > connection > > >> back to the > > >>> previous version, that I upheld. As long as > you > > >> are careful, you > > >>> can go from old binaries to new binaries, you > > >> don't have to get the > > >>> new binaries magically somewhere, though you > do > > >> need the old > > >>> binaries magically from somewhere. :) > > >>> > > >>> Perhaps there's a regression. I can check > "later". > > >>> > > >>> - Jay > > >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 > > >>> From: dabenavidesd at yahoo.es > > >>> To: hosking at cs.purdue.edu; > m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] NT386 with cm3-5.5 > > >> bootstrap compiler > > >>> > > >>> Hi: > > >>> > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From rodney.bates at wichita.edu Fri Sep 21 18:57:59 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 21 Sep 2007 11:57:59 -0500 Subject: [M3devel] A RT failure in ThreadPThread.Alert] Message-ID: <46F3F817.4000909@wichita.edu> I got a runtime failure in ThreadPThread.Alert, on this line: ---------------------------------------------------------------------------------- PROCEDURE Alert (t: T) = BEGIN WITH r = Upthread.mutex_lock(cm) DO <*ASSERT r=0*> END; t.alerted := TRUE; --> WITH r = Upthread.cond_signal(t.waitCond^) DO <*ASSERT r=0*> END; WITH r = Upthread.mutex_unlock(cm) DO <*ASSERT r=0*> END; END Alert; ------------------------------------------------------------------------------------ Here, t.waitCond is NIL and being dereferenced. I tried just making this silently tolerate NIL t.waitCond, and it made the immediate symptom go away, with no other immediately apparent problems. But this seems not very likely to be right. For one thing, there are several other places that assume waitCond is non-NIL. And, a quick reading revealed only one place that creates this object, which always allocates waitCond, no places that change it, and T is opaque and revealed only in this module. How could this happen? Here is a bit of debugger output: The display of t is at the bottom. ------------------------------------------------------------------------------------ *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 304 *** ------------------ EXCEPTION HANDLER STACK --------------------- 0xb5eb71dc TRY-EXCEPT {0xa893a19c} 0xb5eb72bc LOCK mutex = 0xb436e0e4 0xb5eb731c LOCK mutex = 0xb6ebbc44 ---------------------------------------------------------------- [Switching to Thread -1242858592 (LWP 8289)] Breakpoint 2, 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 272 ; PROCEDURE InnerRuntimeFailureDialog ( ) (m3gdb) bt #0 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 #1 0x08126c89 in RuntimeFailureDialog () at AssertDevel.m3:314 #2 0xb72e596f in InvokeExitors () at RTProcess.m3:40 #3 0xb72e59e3 in Crash (msg=NIL) at RTProcess.m3:61 #4 0xb72e3648 in EndError (crash=TRUE) at RTError.m3:115 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 #6 0xb72e3a46 in Crash (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE, rte=16_b73124c0) at RTException.m3:79 #7 0xb72e3770 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:39 #8 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #9 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #10 0xb72e3810 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:47 #11 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #12 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #13 0xb72cb223 in ReportFault (module=16_b731e020, info=9732) at RTHooks.m3:110 #14 0xb72fb697 in _m3_fault (arg=9732) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 #16 0xb7df741d in DisplayDir (v=16_b436e004) at FileBrowserVBT.m3:496 #17 0xb7df4d83 in Refresh (v=16_b436e004) at FileBrowserVBT.m3:210 #18 0xb7df5413 in Watcher (cl=16_b6ebbc9c) at FileBrowserVBT.m3:254 #19 0xb72f76f5 in RunThread (me=16_08e1c518) at ThreadPThread.m3:538 #20 0xb72f7403 in ThreadBase (param=16_08e1c518) at ThreadPThread.m3:519 #21 0xb707c540 in start_thread () from /lib/i686/libpthread.so.0 #22 0xb6fef55e in clone () from /lib/i686/libc.so.6 (m3gdb) frame 5 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 40 RTError.m3: No such file or directory. in RTError.m3 (m3gdb) p msgA $1 = (*16_b7318068*) "" (m3gdb) p msgB $2 = (*16_b73126d4*) "Attempt to reference an illegal memory location." (m3gdb) p msgC $3 = (*16_b7318068*) "" (m3gdb) frame 15 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 304 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) p t $4 = (*16_b3a9bdc8*) OBJECT act = 16_08e94678; closure = NIL; result = NIL; cond = 16_b3a9bdf4; waitingOn = NIL; nextWaiter = NIL; waitCond = NIL; alerted = TRUE; completed = TRUE; joined = FALSE; id = 73; END (m3gdb) -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Fri Sep 21 19:16:11 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Sep 2007 13:16:11 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <724862.70169.qm@web27112.mail.ukl.yahoo.com> References: <724862.70169.qm@web27112.mail.ukl.yahoo.com> Message-ID: <0E2AE424-55FE-4CE4-8223-DE9E2C162E74@cs.purdue.edu> Does this mean you no longer have trouble? On Sep 21, 2007, at 12:18 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Oh Im sorry I meant, that the compiler is working Ok > with LONGINT, at least because is recognizing that > LONGINT is a reserved word. > > SYSTEM.i3 is just source file of the m2tom3 Modula-2 > to Modula-3 compiler; I used as a test for the cm3 > compiler, beside it is an example of Modula-2 and > Modula-3 using a common type LONGINT. > > Thanks > > --- Tony Hosking escribi?: > >> >> On Sep 20, 2007, at 8:50 PM, Jay wrote: >> >>> As a follow up to confirm, look where I made >> changes since >>> LONGINT, I believe make-dist in particular I had >> to make changes to >>> to build the right packages in the right order. >> I'll look into >>> upgrade/update sometime soon.. >>> >>> - Jay >>> >>> From: jay.krell at cornell.edu >>> To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; >> >>> m3devel at elegosoft.com >>> Subject: RE: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> Date: Fri, 21 Sep 2007 00:49:21 +0000 >>> >>> The "-d5.5" thing is a backup of the package >> repository. Indeed I >>> find it annoying sometimes, but I mimiced >> upgrade.sh and I'd have >>> to think it all through again before >> deleting/changing how it >>> works. I think it makes it easier to back out of a >> broken change. >>> If you end up with non-working stuff, you copy >> pkg-d5.5 back on top >>> of pkg. >>> >>> I really strongly suspect update.cmd works. I >> don't remember if it >>> upgrades...oh, sorry, wrong script I think. >>> make-dist.cmd? How about that one? >>> Whichever one creates .tar.bz2 files. That's the >> one I meant. Oops, >>> sorry sorry sorry. :\ >>> >>> >>> - Jay >>> Date: Thu, 20 Sep 2007 22:53:35 +0200 >>> From: dabenavidesd at yahoo.es >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> >>> Hi: >>> >>> The script upgrade.cmd produced compiler does >> recognize the LONGINT >>> as a reserved word. >>> >>> I can get this error when compiling the m2libs of >> m2tom3 compiler: >>> >>> >>> new source -> compiling SYSTEM.i3 >>> "..\src\SYSTEM.i3", line 40: Reserved identifier >> redefined (LONGINT) >>> 1 error encountered >>> >> >> I don't see this file in the distribution. I >> suspect it is something >> to do with upgrade.cmd. I assume it is defining >> LONGINT for >> compilers that don't support it, though I fail to >> understand why this >> would be necessary. >> >> >>> Thanks again >>> >>> >>> >>>> On Sep 20, 2007, at 11:15 AM, Daniel Alejandro >> Benavides D. wrote: >>> >>>> Hi: >>>> Thanks for your suggestions. I have tried the >>>> scripts/win/upgrade.cmd, and It does compile and >> then >>>> you can execute do-cm3-std.cmd. >>>> >>>> However I noticed the that script exports a >> m3core pkg >>>> to the repository with a m3core-d5.5 like >> suffix. Not >>>> sure what is this for. >>>> >>>> I will test if it can recognize the LONGINT >> datatype. >>>> >>>> Also I have a question about Tony's suggestion. >> The >>>> packages m3objfile and m3back are not ncessary >> on the >>>> stages you mention for NT386 target? >>> >>>> Oh, yes, of course they are. Sorry, I forgot >> about that for NT386. >>> >>>> >>>> Thanks >>>> >>>> --- Tony Hosking >> escribi?: >>>> >>>>> It strikes me that you may need to sequence as >>>>> follows to avoid >>>>> running into having a compiler that does not >> handle >>>>> LONGINT. >>>>> >>>>> Using the "devel_LONGINT_start" tagged versions >> of >>>>> m3core and libm3 >>>>> from CVS, >>>>> using your original compiler, build and ship in >> the >>>>> following order: >>>>> >>>>> m3core (devel_LONGINT_start) >>>>> libm3 (devel_LONGINT_start) >>>>> m3middle >>>>> m3linker >>>>> m3front >>>>> m3quake >>>>> cm3 >>>>> >>>>> Now you have a new compiler linked against the >> old >>>>> m3core. >>>>> >>>>> Using the new compiler (in cm3/NT386), and the >> CVS >>>>> head versions of >>>>> m3core and libm3, >>>>> build and ship in the following order: >>>>> >>>>> m3core (CVS head) >>>>> libm3 (CVS head) >>>>> m3middle >>>>> m3linker >>>>> m3front >>>>> m3quake >>>>> cm3 >>>>> >>>>> Now you have a new compiler linked against the >> new >>>>> m3core. >>>>> >>>>> Copy this new compiler to your CM3 installation >> bin >>>>> directory. >>>>> >>>>> Use this new compiler to rebuild the world. >>>>> >>>>> >>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote: >>>>> >>>>>> Daniel, can you try just going back to 5.2.6 >> and >>>>> running scripts\win >>>>>> \update? >>>>>> You should be able to build the current source >> the >>>>> last "official" >>>>>> Win32 binaries, as long as you build in the >>>>> correct order and all, >>>>>> which the update.cmd does. You know, there's a >>>>> certain mentality >>>>>> around bootstrapping and keeping the >> connection >>>>> back to the >>>>>> previous version, that I upheld. As long as >> you >>>>> are careful, you >>>>>> can go from old binaries to new binaries, you >>>>> don't have to get the >>>>>> new binaries magically somewhere, though you >> do >>>>> need the old >>>>>> binaries magically from somewhere. :) >>>>>> >>>>>> Perhaps there's a regression. I can check >> "later". >>>>>> >>>>>> - Jay >>>>>> Date: Wed, 19 Sep 2007 00:49:57 +0200 >>>>>> From: dabenavidesd at yahoo.es >>>>>> To: hosking at cs.purdue.edu; >> m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] NT386 with cm3-5.5 >>>>> bootstrap compiler >>>>>> >>>>>> Hi: >>>>>> >> > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Fri Sep 21 19:27:10 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 21 Sep 2007 19:27:10 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <0E2AE424-55FE-4CE4-8223-DE9E2C162E74@cs.purdue.edu> Message-ID: <413596.25532.qm@web27105.mail.ukl.yahoo.com> Hi: Yes, exactly :) Thanks --- Tony Hosking escribi?: > Does this mean you no longer have trouble? > > On Sep 21, 2007, at 12:18 PM, Daniel Alejandro > Benavides D. wrote: > > > Hi: > > Oh Im sorry I meant, that the compiler is working > Ok > > with LONGINT, at least because is recognizing that > > LONGINT is a reserved word. > > > > SYSTEM.i3 is just source file of the m2tom3 > Modula-2 > > to Modula-3 compiler; I used as a test for the cm3 > > compiler, beside it is an example of Modula-2 and > > Modula-3 using a common type LONGINT. > > > > Thanks > > > > --- Tony Hosking > escribi?: > > > >> > >> On Sep 20, 2007, at 8:50 PM, Jay wrote: > >> > >>> As a follow up to confirm, look where I made > >> changes since > >>> LONGINT, I believe make-dist in particular I had > >> to make changes to > >>> to build the right packages in the right order. > >> I'll look into > >>> upgrade/update sometime soon.. > >>> > >>> - Jay > >>> > >>> From: jay.krell at cornell.edu > >>> To: dabenavidesd at yahoo.es; > hosking at cs.purdue.edu; > >> > >>> m3devel at elegosoft.com > >>> Subject: RE: [M3devel] NT386 with cm3-5.5 > >> bootstrap compiler > >>> Date: Fri, 21 Sep 2007 00:49:21 +0000 > >>> > >>> The "-d5.5" thing is a backup of the package > >> repository. Indeed I > >>> find it annoying sometimes, but I mimiced > >> upgrade.sh and I'd have > >>> to think it all through again before > >> deleting/changing how it > >>> works. I think it makes it easier to back out of > a > >> broken change. > >>> If you end up with non-working stuff, you copy > >> pkg-d5.5 back on top > >>> of pkg. > >>> > >>> I really strongly suspect update.cmd works. I > >> don't remember if it > >>> upgrades...oh, sorry, wrong script I think. > >>> make-dist.cmd? How about that one? > >>> Whichever one creates .tar.bz2 files. That's the > >> one I meant. Oops, > >>> sorry sorry sorry. :\ > >>> > >>> > >>> - Jay > >>> Date: Thu, 20 Sep 2007 22:53:35 +0200 > >>> From: dabenavidesd at yahoo.es > >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com > >>> Subject: Re: [M3devel] NT386 with cm3-5.5 > >> bootstrap compiler > >>> > >>> Hi: > >>> > >>> The script upgrade.cmd produced compiler does > >> recognize the LONGINT > >>> as a reserved word. > >>> > >>> I can get this error when compiling the m2libs > of > >> m2tom3 compiler: > >>> > >>> > >>> new source -> compiling SYSTEM.i3 > >>> "..\src\SYSTEM.i3", line 40: Reserved identifier > >> redefined (LONGINT) > >>> 1 error encountered > >>> > >> > >> I don't see this file in the distribution. I > >> suspect it is something > >> to do with upgrade.cmd. I assume it is defining > >> LONGINT for > >> compilers that don't support it, though I fail to > >> understand why this > >> would be necessary. > >> > >> > >>> Thanks again > >>> > >>> > >>> > >>>> On Sep 20, 2007, at 11:15 AM, Daniel Alejandro > >> Benavides D. wrote: > >>> > >>>> Hi: > >>>> Thanks for your suggestions. I have tried the > >>>> scripts/win/upgrade.cmd, and It does compile > and > >> then > >>>> you can execute do-cm3-std.cmd. > >>>> > >>>> However I noticed the that script exports a > >> m3core pkg > >>>> to the repository with a m3core-d5.5 like > >> suffix. Not > >>>> sure what is this for. > >>>> > >>>> I will test if it can recognize the LONGINT > >> datatype. > >>>> > >>>> Also I have a question about Tony's > suggestion. > >> The > >>>> packages m3objfile and m3back are not ncessary > >> on the > >>>> stages you mention for NT386 target? > >>> > >>>> Oh, yes, of course they are. Sorry, I forgot > >> about that for NT386. > >>> > >>>> > >>>> Thanks > >>>> > >>>> --- Tony Hosking > >> escribi?: > >>>> > >>>>> It strikes me that you may need to sequence as > >>>>> follows to avoid > >>>>> running into having a compiler that does not > >> handle > >>>>> LONGINT. > >>>>> > >>>>> Using the "devel_LONGINT_start" tagged > versions > >> of > >>>>> m3core and libm3 > >>>>> from CVS, > >>>>> using your original compiler, build and ship > in > >> the > >>>>> following order: > >>>>> > >>>>> m3core (devel_LONGINT_start) > >>>>> libm3 (devel_LONGINT_start) > >>>>> m3middle > >>>>> m3linker > >>>>> m3front > >>>>> m3quake > >>>>> cm3 > >>>>> > >>>>> Now you have a new compiler linked against > the > >> old > >>>>> m3core. > >>>>> > >>>>> Using the new compiler (in cm3/NT386), and the > >> CVS > >>>>> head versions of > >>>>> m3core and libm3, > >>>>> build and ship in the following order: > >>>>> > >>>>> m3core (CVS head) > >>>>> libm3 (CVS head) > >>>>> m3middle > >>>>> m3linker > >>>>> m3front > >>>>> m3quake > >>>>> cm3 > >>>>> > >>>>> Now you have a new compiler linked against the > >> new > >>>>> m3core. > >>>>> > >>>>> Copy this new compiler to your CM3 > installation > >> bin > >>>>> directory. > >>>>> > >>>>> Use this new compiler to rebuild the world. > >>>>> > >>>>> > >>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote: > >>>>> > >>>>>> Daniel, can you try just going back to 5.2.6 > >> and > >>>>> running scripts\win > >>>>>> \update? > >>>>>> You should be able to build the current > source > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 21 19:30:11 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Sep 2007 13:30:11 -0400 Subject: [M3devel] A RT failure in ThreadPThread.Alert] In-Reply-To: <46F3F817.4000909@wichita.edu> References: <46F3F817.4000909@wichita.edu> Message-ID: waitCond should be valid for all live threads. I'm assuming you are invoking Thread.Alert on a thread that is no longer alive. Indeed, you can see from the debug output that the thread has completed. I suppose we could silently ignore the alert for a completed thread, but I suspect this reveals some deeper problem with your code -- should you really issue an alert to a thread that is incapable of receiving it. I wonder if the alert flag is already set for that thread. In any case I suppose we can simply check for NIL in Alert. I've checked in code to do this. On Sep 21, 2007, at 12:57 PM, Rodney M. Bates wrote: > > > > I got a runtime failure in ThreadPThread.Alert, on this line: > > ---------------------------------------------------------------------- > ------------ > PROCEDURE Alert (t: T) = > BEGIN > WITH r = Upthread.mutex_lock(cm) DO <*ASSERT r=0*> END; > t.alerted := TRUE; > --> WITH r = Upthread.cond_signal(t.waitCond^) DO <*ASSERT r=0*> END; > WITH r = Upthread.mutex_unlock(cm) DO <*ASSERT r=0*> END; > END Alert; > ---------------------------------------------------------------------- > -------------- > Here, t.waitCond is NIL and being dereferenced. I tried just > making this > silently tolerate NIL t.waitCond, and it made the immediate symptom > go away, > with no other immediately apparent problems. But this seems not > very likely > to be right. For one thing, there are several other places that > assume > waitCond is non-NIL. And, a quick reading revealed only one place > that creates > this object, which always allocates waitCond, no places that change > it, and > T is opaque and revealed only in this module. How could this happen? > > > Here is a bit of debugger output: The display of t is at the bottom. > ---------------------------------------------------------------------- > -------------- > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 304 > *** > > ------------------ EXCEPTION HANDLER STACK --------------------- > 0xb5eb71dc TRY-EXCEPT {0xa893a19c} > 0xb5eb72bc LOCK mutex = 0xb436e0e4 > 0xb5eb731c LOCK mutex = 0xb6ebbc44 > ---------------------------------------------------------------- > [Switching to Thread -1242858592 (LWP 8289)] > > Breakpoint 2, 0x08126a38 in InnerRuntimeFailureDialog () at > AssertDevel.m3:272 > 272 ; PROCEDURE InnerRuntimeFailureDialog ( ) > (m3gdb) bt > #0 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 > #1 0x08126c89 in RuntimeFailureDialog () at AssertDevel.m3:314 > #2 0xb72e596f in InvokeExitors () at RTProcess.m3:40 > #3 0xb72e59e3 in Crash (msg=NIL) at RTProcess.m3:61 > #4 0xb72e3648 in EndError (crash=TRUE) at RTError.m3:115 > #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, > msgA=16_b7318068, msgB=16_b73126d4, > msgC=16_b7318068) at RTError.m3:40 > #6 0xb72e3a46 in Crash (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE, > rte=16_b73124c0) at RTException.m3:79 > #7 0xb72e3770 in DefaultBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:39 > #8 0xb72e36d4 in InvokeBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:25 > #9 0xb72f3397 in Raise (act= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END) at RTExFrame.m3:29 > #10 0xb72e3810 in DefaultBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:47 > #11 0xb72e36d4 in InvokeBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:25 > #12 0xb72f3397 in Raise (act= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END) at RTExFrame.m3:29 > #13 0xb72cb223 in ReportFault (module=16_b731e020, info=9732) at > RTHooks.m3:110 > #14 0xb72fb697 in _m3_fault (arg=9732) from /usr/local/cm3/pkg/ > m3core/LINUXLIBC6/libm3core.so.5 > #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 > #16 0xb7df741d in DisplayDir (v=16_b436e004) at FileBrowserVBT.m3:496 > #17 0xb7df4d83 in Refresh (v=16_b436e004) at FileBrowserVBT.m3:210 > #18 0xb7df5413 in Watcher (cl=16_b6ebbc9c) at FileBrowserVBT.m3:254 > #19 0xb72f76f5 in RunThread (me=16_08e1c518) at ThreadPThread.m3:538 > #20 0xb72f7403 in ThreadBase (param=16_08e1c518) at > ThreadPThread.m3:519 > #21 0xb707c540 in start_thread () from /lib/i686/libpthread.so.0 > #22 0xb6fef55e in clone () from /lib/i686/libc.so.6 > (m3gdb) frame 5 > #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, > msgA=16_b7318068, msgB=16_b73126d4, > msgC=16_b7318068) at RTError.m3:40 > 40 RTError.m3: No such file or directory. > in RTError.m3 > (m3gdb) p msgA > $1 = (*16_b7318068*) "" > (m3gdb) p msgB > $2 = (*16_b73126d4*) "Attempt to reference an illegal memory > location." > (m3gdb) p msgC > $3 = (*16_b7318068*) "" > (m3gdb) frame 15 > #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 > 304 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) p t > $4 = (*16_b3a9bdc8*) OBJECT act = 16_08e94678; closure = NIL; > result = NIL; cond = 16_b3a9bdf4; > waitingOn = NIL; nextWaiter = NIL; waitCond = NIL; alerted = > TRUE; completed = TRUE; > joined = FALSE; id = 73; END > (m3gdb) > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu > From rodney.bates at wichita.edu Sat Sep 22 04:51:36 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 21 Sep 2007 21:51:36 -0500 Subject: [M3devel] A RT failure in ThreadPThread.Alert] In-Reply-To: <7AE14F7D-216C-40B8-996E-0BC97875D4D9@cs.purdue.edu> References: <46F3F817.4000909@wichita.edu> <46F41CE8.9060804@wichita.edu> <7AE14F7D-216C-40B8-996E-0BC97875D4D9@cs.purdue.edu> Message-ID: <46F48338.8040304@wichita.edu> From a bit of code reading, it looks like: 1) FileBrowserVBT.m3 has been routinely doing this for a long time (Alerting a thread that has most likely already terminated), and 2) ThreadPosix tolerates this harmlessly. So, making ThreadPThread also tolerate it is probably the right fix. Tony Hosking wrote: > Hmmm. Perhaps there is a deeper problem. > > On Sep 21, 2007, at 3:35 PM, Rodney M. Bates wrote: > >> The Alert is coming from somewhere inside Trestle. I guess I need to >> look into that. >> >> Tony Hosking wrote: >> >>> waitCond should be valid for all live threads. I'm assuming you >>> are invoking Thread.Alert on a thread that is no longer alive. >>> Indeed, you can see from the debug output that the thread has >>> completed. I suppose we could silently ignore the alert for a >>> completed thread, but I suspect this reveals some deeper problem >>> with your code -- should you really issue an alert to a thread that >>> is incapable of receiving it. I wonder if the alert flag is >>> already set for that thread. In any case I suppose we can simply >>> check for NIL in Alert. I've checked in code to do this. >> >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Sat Sep 22 06:10:10 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 22 Sep 2007 00:10:10 -0400 Subject: [M3devel] A RT failure in ThreadPThread.Alert] In-Reply-To: <46F48338.8040304@wichita.edu> References: <46F3F817.4000909@wichita.edu> <46F41CE8.9060804@wichita.edu> <7AE14F7D-216C-40B8-996E-0BC97875D4D9@cs.purdue.edu> <46F48338.8040304@wichita.edu> Message-ID: <730D7378-3B00-4DB8-9DA5-75C55FCB74E0@cs.purdue.edu> The update I checked in earlier today does the trick. On Sep 21, 2007, at 10:51 PM, Rodney M. Bates wrote: > From a bit of code reading, it looks like: > > 1) FileBrowserVBT.m3 has been routinely doing this for a long time > (Alerting a thread that has most likely already terminated), and > > 2) ThreadPosix tolerates this harmlessly. > > So, making ThreadPThread also tolerate it is probably the right fix. > > Tony Hosking wrote: >> Hmmm. Perhaps there is a deeper problem. >> On Sep 21, 2007, at 3:35 PM, Rodney M. Bates wrote: >>> The Alert is coming from somewhere inside Trestle. I guess I >>> need to >>> look into that. >>> >>> Tony Hosking wrote: >>> >>>> waitCond should be valid for all live threads. I'm assuming >>>> you are invoking Thread.Alert on a thread that is no longer >>>> alive. Indeed, you can see from the debug output that the >>>> thread has completed. I suppose we could silently ignore the >>>> alert for a completed thread, but I suspect this reveals some >>>> deeper problem with your code -- should you really issue an >>>> alert to a thread that is incapable of receiving it. I wonder >>>> if the alert flag is already set for that thread. In any case >>>> I suppose we can simply check for NIL in Alert. I've checked >>>> in code to do this. >>> >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From dabenavidesd at yahoo.es Thu Sep 27 08:32:37 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 27 Sep 2007 08:32:37 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 Message-ID: <266390.74360.qm@web27112.mail.ukl.yahoo.com> Hi: I am testing some examples of Chapter 16 of Laszlo book, but the text shows me that now the NThreads example where 10 threads are being showing the IDs (1, 2, ... ,10). This is tested on ubuntu Dapper OS, which still allows the use of user space threads implementation. Attached are some animated gif files that show in (sorry have no web page available) LINUXLIBC6.gif exmaple execution of Systems level threads LINUXLIBC62.gif example execution of User space threads LINUXLIBC62a.gif example execution of User space threads after it ends Why the different versions of thread implementation are different, in terms of what showthread shows that all the threads are "locking" (9 almost all time) and 2 (the first and third form left to right) are "alive" in the Pthread case, and why in the user space threads case they are "alive" green color almost always if they are not running. The worst thing is the behaviour of the appication is very rare, It should be running until a key (enter) is pressed down; It just runs some seconds in pthread case. Besides why some many objects are shown in shownew with the user space threaded program. The linking information of ldd output is below. LINUXLIBC6 is current cvs compiled example LINUXLIBC&2 compiled with user spce threads. on LINUXLIBC6 with user space threads, June 9th the date It was compiled. danielb at danielb-desktop:~/code/m3/parallel$ ldd LINUXLIBC62/NThreads linux-gate.so.1 => (0xffffe000) libm3local.so.5 => /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 (0xb7faf000) libm3.so.5 => /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 (0xb7e90000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 (0xb760f000) libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb75d1000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb74a2000) /lib/ld-linux.so.2 (0xb7fbd000) on LINUXLIBC6 with system threads: danielb at danielb-desktop:~/code/m3/parallel$ ldd LINUXLIBC6/NThreads linux-gate.so.1 => (0xffffe000) libm3local.so.5 => /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 (0xb7f51000) libm3.so.5 => /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 (0xb7e1e000) libm3core.so.5 => /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 (0xb7592000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7544000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7415000) /lib/ld-linux.so.2 (0xb7f5f000) the source code is this MODULE NThreads EXPORTS Main; (*22.02.95. LB*) (* Program starts "N" threads which output their ID and terminate if a key is pressed (on some systems you have to press the return key). *) IMPORT Thread, SIO; FROM Scheduler IMPORT Yield; CONST N = 10; TYPE Threads = [1..N]; Closure = Thread.Closure OBJECT id: Threads; (*identifies thread*) OVERRIDES apply:= PrintId; END; (*Closure*) PROCEDURE PrintId(cl: Closure): REFANY = BEGIN REPEAT SIO.PutInt(cl.id); IF cl.id = LAST(Threads) THEN SIO.Nl() END; Yield(); (*yields to other threads*) UNTIL SIO.Available(); RETURN NIL; (*return value not used*) END PrintId; PROCEDURE Fork() = BEGIN FOR i:= FIRST(Threads) TO LAST(Threads) - 1 DO EVAL Thread.Fork(NEW(Closure, id:= i)) (*N-1 threads are generated*) END; EVAL PrintId(NEW(Closure, id:= LAST(Threads))); (*N-th thread = main*) END Fork; BEGIN Fork(); (*start all threads*) END NThreads. Thanks ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html -------------- next part -------------- A non-text attachment was scrubbed... Name: LINUXLIBC6.gif Type: image/gif Size: 169516 bytes Desc: 1808490959-LINUXLIBC6.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LINUXLIBC62.gif Type: image/gif Size: 170325 bytes Desc: 2366884796-LINUXLIBC62.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LINUXLIBC62a.gif Type: image/gif Size: 246626 bytes Desc: 225660904-LINUXLIBC62a.gif URL: From hosking at cs.purdue.edu Thu Sep 27 15:38:37 2007 From: hosking at cs.purdue.edu (Antony Hosking) Date: Thu, 27 Sep 2007 09:38:37 -0400 Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <266390.74360.qm@web27112.mail.ukl.yahoo.com> References: <266390.74360.qm@web27112.mail.ukl.yahoo.com> Message-ID: <35BC64D8-6381-43CC-B52A-666F7C2757BC@cs.purdue.edu> In the pthread implementation scheduling is performed by the OS so there is no way to say that any particular thread is *alive*, just that it is eligible to run should the scheduler choose to run it (indeed on an SMP more than one thread can run at a time). The user- thread implementation has its own scheduler, so it knows precisely which thread is running at any point in time. Are you saying there is a bug in the current pthread implementation? If so, then I'd like a more precise characterization that I can pursue and fix. On Sep 27, 2007, at 2:32 AM, Daniel Alejandro Benavides D. wrote: > Hi: > I am testing some examples of Chapter 16 of Laszlo > book, but the text shows me that now the NThreads > example where 10 threads are being showing the IDs (1, > 2, ... ,10). > This is tested on ubuntu Dapper OS, which still allows > the use of user space threads implementation. > Attached are some animated gif files that show in > (sorry have no web page available) > LINUXLIBC6.gif exmaple execution of Systems level > threads > LINUXLIBC62.gif example execution of User space > threads > LINUXLIBC62a.gif example execution of User space > threads after it ends > > Why the different versions of thread implementation > are different, in terms of what showthread shows that > all the threads are "locking" (9 almost all time) and > 2 (the first and third form left to right) are "alive" > in the Pthread case, and why in the user space threads > case they are "alive" green color almost always if > they are not running. > The worst thing is the behaviour of the appication is > very rare, It should be running until a key (enter) is > pressed down; It just runs some seconds in pthread > case. > > Besides why some many objects are shown in shownew > with the user space threaded program. > > The linking information of ldd output is below. > LINUXLIBC6 is current cvs compiled example > LINUXLIBC&2 compiled with user spce threads. > > on LINUXLIBC6 with user space threads, June 9th the > date It was compiled. > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > LINUXLIBC62/NThreads > linux-gate.so.1 => (0xffffe000) > libm3local.so.5 => > /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 > (0xb7faf000) > libm3.so.5 => > /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 > (0xb7e90000) > libm3core.so.5 => > /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > (0xb760f000) > libm3gcdefs.so.5 => > /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > (0xb75d1000) > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > (0xb74a2000) > /lib/ld-linux.so.2 (0xb7fbd000) > > > on LINUXLIBC6 with system threads: > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > LINUXLIBC6/NThreads > linux-gate.so.1 => (0xffffe000) > libm3local.so.5 => > /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 > (0xb7f51000) > libm3.so.5 => > /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 > (0xb7e1e000) > libm3core.so.5 => > /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 > (0xb7592000) > libpthread.so.0 => > /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > (0xb7544000) > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > (0xb7415000) > /lib/ld-linux.so.2 (0xb7f5f000) > > > the source code is this > > MODULE NThreads EXPORTS Main; > (*22.02.95. LB*) > (* Program starts "N" threads which output their ID > and terminate > if a key is pressed (on some systems you have to > press the return > key). > *) > > IMPORT Thread, SIO; > FROM Scheduler IMPORT Yield; > > CONST > N = 10; > TYPE > Threads = [1..N]; > Closure = Thread.Closure OBJECT > id: Threads; > (*identifies thread*) > OVERRIDES > apply:= PrintId; > END; (*Closure*) > > PROCEDURE PrintId(cl: Closure): REFANY = > BEGIN > REPEAT > SIO.PutInt(cl.id); > IF cl.id = LAST(Threads) THEN SIO.Nl() END; > Yield(); > (*yields to other threads*) > UNTIL SIO.Available(); > RETURN NIL; > (*return value not used*) > END PrintId; > > PROCEDURE Fork() = > BEGIN > FOR i:= FIRST(Threads) TO LAST(Threads) - 1 DO > EVAL Thread.Fork(NEW(Closure, id:= i)) > (*N-1 threads are generated*) > END; > EVAL PrintId(NEW(Closure, id:= LAST(Threads))); > (*N-th thread = main*) > END Fork; > > BEGIN > Fork(); > (*start all threads*) > END NThreads. > > > Thanks > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html > > > Antony Hosking | Associate Professor Dept of Computer Sciences | Office: (765) 494-6001 Purdue University | Mobile: (765) 427-5484 250 N. University Street | hosking at cs.purdue.edu West Lafayette, IN 47907-2066 | http://www.cs.purdue.edu/~hosking _--_|\ / \ \_.--._/ ) v / From dabenavidesd at yahoo.es Fri Sep 28 15:08:35 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 28 Sep 2007 15:08:35 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <35BC64D8-6381-43CC-B52A-666F7C2757BC@cs.purdue.edu> Message-ID: <757512.73957.qm@web27111.mail.ukl.yahoo.com> Hi: With @M3noincremental just runs for while 1 2 3 1 2 3 10 5 4 and in this state its like a freezed program, it does not respond to the keyboard input. With @M3nogenerational or @M3nogc runs just fine. What could be the problem? What else could be useful to do? Thanks --- Antony Hosking wrote: > In the pthread implementation scheduling is > performed by the OS so > there is no way to say that any particular thread is > *alive*, just > that it is eligible to run should the scheduler > choose to run it > (indeed on an SMP more than one thread can run at a > time). The user- > thread implementation has its own scheduler, so it > knows precisely > which thread is running at any point in time. > > Are you saying there is a bug in the current pthread > implementation? > If so, then I'd like a more precise characterization > that I can > pursue and fix. > > On Sep 27, 2007, at 2:32 AM, Daniel Alejandro > Benavides D. wrote: > > > Hi: > > I am testing some examples of Chapter 16 of Laszlo > > book, but the text shows me that now the NThreads > > example where 10 threads are being showing the IDs > (1, > > 2, ... ,10). > > This is tested on ubuntu Dapper OS, which still > allows > > the use of user space threads implementation. > > Attached are some animated gif files that show in > > (sorry have no web page available) > > LINUXLIBC6.gif exmaple execution of Systems level > > threads > > LINUXLIBC62.gif example execution of User space > > threads > > LINUXLIBC62a.gif example execution of User space > > threads after it ends > > > > Why the different versions of thread > implementation > > are different, in terms of what showthread shows > that > > all the threads are "locking" (9 almost all time) > and > > 2 (the first and third form left to right) are > "alive" > > in the Pthread case, and why in the user space > threads > > case they are "alive" green color almost always if > > they are not running. > > The worst thing is the behaviour of the appication > is > > very rare, It should be running until a key > (enter) is > > pressed down; It just runs some seconds in pthread > > case. > > > > Besides why some many objects are shown in shownew > > with the user space threaded program. > > > > The linking information of ldd output is below. > > LINUXLIBC6 is current cvs compiled example > > LINUXLIBC&2 compiled with user spce threads. > > > > on LINUXLIBC6 with user space threads, June 9th > the > > date It was compiled. > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > LINUXLIBC62/NThreads > > linux-gate.so.1 => (0xffffe000) > > libm3local.so.5 => > > > /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > (0xb7faf000) > > libm3.so.5 => > > /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 > > (0xb7e90000) > > libm3core.so.5 => > > > /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > (0xb760f000) > > libm3gcdefs.so.5 => > > /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) > > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > > (0xb75d1000) > > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > > (0xb74a2000) > > /lib/ld-linux.so.2 (0xb7fbd000) > > > > > > on LINUXLIBC6 with system threads: > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > LINUXLIBC6/NThreads > > linux-gate.so.1 => (0xffffe000) > > libm3local.so.5 => > > > /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > (0xb7f51000) > > libm3.so.5 => > > > /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 > > (0xb7e1e000) > > libm3core.so.5 => > > > /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > (0xb7592000) > > libpthread.so.0 => > > /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) > > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > > (0xb7544000) > > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > > (0xb7415000) > > /lib/ld-linux.so.2 (0xb7f5f000) > > > > > > the source code is this > > > > MODULE NThreads EXPORTS Main; > > (*22.02.95. LB*) > > (* Program starts "N" threads which output their > ID > > and terminate > > if a key is pressed (on some systems you have > to > > press the return > > key). > > *) > > > > IMPORT Thread, SIO; > > FROM Scheduler IMPORT Yield; > > > > CONST > > N = 10; > > TYPE > > Threads = [1..N]; > > Closure = Thread.Closure OBJECT > > id: Threads; > > (*identifies thread*) > > OVERRIDES > > apply:= PrintId; > > END; (*Closure*) > > > > PROCEDURE PrintId(cl: Closure): REFANY = > > BEGIN > > REPEAT > > SIO.PutInt(cl.id); > > IF cl.id = LAST(Threads) THEN SIO.Nl() END; > > Yield(); > > (*yields to other threads*) > > UNTIL SIO.Available(); > > RETURN NIL; > > (*return value not used*) > > END PrintId; > > > > PROCEDURE Fork() = > > BEGIN > > FOR i:= FIRST(Threads) TO LAST(Threads) - 1 DO > > EVAL Thread.Fork(NEW(Closure, id:= i)) > > (*N-1 threads are generated*) > > END; > > EVAL PrintId(NEW(Closure, id:= > LAST(Threads))); > > (*N-th thread = main*) > > END Fork; > > > > BEGIN > > Fork(); > > (*start all threads*) > > END NThreads. > > > > > > Thanks > > > > > > > > > ______________________________________________________________________ > > > ______________ > > S? un Mejor Amante del Cine > > ?Quieres saber c?mo? ?Deja que otras personas te > ayuden! > > > http://advision.webevents.yahoo.com/reto/entretenimiento.html > > > > > > > > Antony Hosking | Associate Professor > Dept of Computer Sciences | Office: (765) > 494-6001 > Purdue University | Mobile: (765) > 427-5484 > 250 N. University Street | > hosking at cs.purdue.edu > West Lafayette, IN 47907-2066 | > http://www.cs.purdue.edu/~hosking > _--_|\ > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Fri Sep 28 16:30:30 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 28 Sep 2007 16:30:30 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <757512.73957.qm@web27111.mail.ukl.yahoo.com> Message-ID: <860980.52128.qm@web27109.mail.ukl.yahoo.com> Hi: I debugged for a while the program with handle all nostop handle EXC_SOFTWARE stop handle EXC_BREAKPOINT stop getting this: Breakpoint 4, SignalHandler (sig=64, sip=16_b640ff9c, uap=16_b641001c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1254036560 (LWP 8072)] Breakpoint 3, SignalHandler (sig=64, sip=16_b540df8c, uap=16_b540e00c) at ThreadPThread.m3:1184 1184 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1237251152 (LWP 8067)] Breakpoint 3, SignalHandler (sig=64, sip=16_b640ff9c, uap=16_b641001c) at ThreadPThread.m3:1184 1184 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b640ff9c, uap=16_b641001c) at ThreadPThread.m3:1184 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb7505b8c in sched_yield () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7625fce in Yield () at ThreadPThread.m3:712 #5 0x0804b844 in PrintId (cl=16_b741b0a0) at NThreads.m3:25 #6 0xb7624b21 in RunThread (me=16_08054560) at ThreadPThread.m3:540 #7 0xb76247e6 in ThreadBase (param=16_08054560) at ThreadPThread.m3:521 #8 0xb75ad341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #9 0xb751f4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** [Switching to Thread -1228858448 (LWP 8066)] Breakpoint 4, SignalHandler (sig=64, sip=16_b6c10f9c, uap=16_b6c1101c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step Breakpoint 3, SignalHandler (sig=64, sip=16_b6c10f9c, uap=16_b6c1101c) at ThreadPThread.m3:1184 1184 in ThreadPThread.m3 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Program received signal SIG64, Real-time event 64. [Switching to Thread -1220465744 (LWP 8065)] Breakpoint 4, SignalHandler (sig=64, sip=16_b7411f9c, uap=16_b741201c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step 4 4 Program received signal SIGABRT, Aborted. 4Couldn't get registers: No such process. (m3gdb) ----------------------------------------------------- And then without modifying the signal set: (m3gdb) break NThreads.m3:10 Breakpoint 1 at 0x804b934: file NThreads.m3, line 10. (m3gdb) break ThreadPThread.m3:1180 No source file named ThreadPThread.m3. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 2 (ThreadPThread.m3:1180) pending. (m3gdb) run Starting program: /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads [Thread debugging using libthread_db enabled] [New Thread -1220532544 (LWP 8125)] Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, line 1180. Pending breakpoint "ThreadPThread.m3:1180" resolved [Switching to Thread -1220532544 (LWP 8125)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7010) at NThreads.m3:14 warning: Source file is more recent than executable. 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1220805712 (LWP 8131)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7058) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1229198416 (LWP 8132)] 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c70a0) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 1[New Thread -1237591120 (LWP 8133)] 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c70e8) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 2 1[New Thread -1245983824 (LWP 8134)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7130) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 3 2 1[New Thread -1254376528 (LWP 8135)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1254376528 (LWP 8135)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1237591120 (LWP 8133)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1229198416 (LWP 8132)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1220805712 (LWP 8131)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. [Switching to Thread -1254376528 (LWP 8135)] Breakpoint 3, SignalHandler (sig=64, sip=16_b53baf8c, uap=16_b53bb00c) at ThreadPThread.m3:1180 1180 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b53baf8c, uap=16_b53bb00c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb755f3c1 in __lll_mutex_unlock_wake () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb755c2df in _L_mutex_unlock_128 () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb53bb358 in ?? () #6 0xb75cecef in Release (m=16_b75fadf4) at ThreadPThread.m3:186 #7 0xb75cecef in Release (m=16_b73c0004) at ThreadPThread.m3:186 #8 0xb75d1aa9 in RunThread (me=16_08054700) at ThreadPThread.m3:536 #9 0xb75d17e6 in ThreadBase (param=16_08054700) at ThreadPThread.m3:521 #10 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #11 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. [Switching to Thread -1229198416 (LWP 8132)] Breakpoint 3, SignalHandler (sig=64, sip=16_b6bbdf9c, uap=16_b6bbe01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** [Switching to Thread -1237591120 (LWP 8133)] Breakpoint 3, SignalHandler (sig=64, sip=16_b63bcf9c, uap=16_b63bd01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b63bcf9c, uap=16_b63bd01c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb74b2b8c in sched_yield () from /lib/tls/i686/cmov/libc.so.6 #4 0xb75d2fce in Yield () at ThreadPThread.m3:712 #5 0x0804b844 in PrintId (cl=16_b73c70a0) at NThreads.m3:25 #6 0xb75d1b21 in RunThread (me=16_08054560) at ThreadPThread.m3:540 #7 0xb75d17e6 in ThreadBase (param=16_08054560) at ThreadPThread.m3:521 #8 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #9 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed.[Switching to Thread -1220805712 (LWP 8131)] Breakpoint 3, SignalHandler (sig=64, sip=16_b73bef9c, uap=16_b73bf01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b73bef9c, uap=16_b73bf01c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb74b2b8c in sched_yield () from /lib/tls/i686/cmov/libc.so.6 #4 0xb75d2fce in Yield () at ThreadPThread.m3:712 #5 0x0804b844 in PrintId (cl=16_b73c7010) at NThreads.m3:25 #6 0xb75d1b21 in RunThread (me=16_080543c0) at ThreadPThread.m3:540 #7 0xb75d17e6 in ThreadBase (param=16_080543c0) at ThreadPThread.m3:521 #8 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #9 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed. *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Program received signal SIG64, Real-time event 64. [Switching to Thread -1220532544 (LWP 8125)] 0xffffe410 in __kernel_vsyscall () (m3gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb755cc76 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb75d5ae0 in LockHeap () at ThreadPThread.m3:1370 #3 0xb75a13ca in GetUntracedRef (def=16_b75faf38) at RTAllocator.m3:240 #4 0xb75a0b4a in AllocateUntracedRef (defn=16_b75faf38) at RTAllocator.m3:146 #5 0xb75d2003 in Fork (closure=16_b73c7178) at ThreadPThread.m3:575 #6 0x0804b8b6 in Fork () at NThreads.m3:33 #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 #8 0xb75ba87a in RunMainBody (m=16_0804dc60) at RTLinker.m3:399 #9 0xb75b9174 in AddUnitI (m=16_0804dc60) at RTLinker.m3:113 #10 0xb75b920b in AddUnit (b={"NThreads_M3", Declared at: NThreads.m3:38}) at RTLinker.m3:122 #11 0x08048ea8 in main (argc=1, argv=0xbf860fd4, envp=0xbf860fdc) at _m3main.mc:4 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Breakpoint 3, SignalHandler (sig=64, sip=16_bf8607fc, uap=16_bf86087c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_bf8607fc, uap=16_bf86087c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb755cc76 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb75d5ae0 in LockHeap () at ThreadPThread.m3:1370 #5 0xb75a13ca in GetUntracedRef (def=16_b75faf38) at RTAllocator.m3:240 #6 0xb75a0b4a in AllocateUntracedRef (defn=16_b75faf38) at RTAllocator.m3:146 #7 0xb75d2003 in Fork (closure=16_b73c7178) at ThreadPThread.m3:575 #8 0x0804b8b6 in Fork () at NThreads.m3:33 #9 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 #10 0xb75ba87a in RunMainBody (m=16_0804dc60) at RTLinker.m3:399 #11 0xb75b9174 in AddUnitI (m=16_0804dc60) at RTLinker.m3:113 #12 0xb75b920b in AddUnit (b={"NThreads_M3", Declared at: NThreads.m3:38}) at RTLinker.m3:122 #13 0x08048ea8 in main (argc=1, argv=0xbf860fd4, envp=0xbf860fdc) at _m3main.mc:4 (m3gdb) cont Continuing. 4 Program received signal SIGABRT, Aborted. [Switching to Thread -1254376528 (LWP 8135)] 0xffffe410 in __kernel_vsyscall () (m3gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb742b9a1 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb742d2b9 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb75cb72f in Crash () at RTOS.m3:20 #4 0xb75be204 in Crash (msg=NIL) at RTProcess.m3:65 #5 0xb75bb965 in EndError (crash=TRUE) at RTError.m3:115 #6 0xb75bb61a in MsgS (file=16_b75fabf8, line=1184, msgA=16_b75f4e08, msgB=16_b75ef3b0, msgC=16_b75f4e08) at RTError.m3:40 #7 0xb75bbdf2 in Crash (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE, rte=16_b75ef260) at RTException.m3:79 #8 0xb75bbaee in DefaultBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:39 #9 0xb75bba33 in InvokeBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:25 #10 0xb75ccfa8 in Raise (act= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END) at RTExFrame.m3:29 #11 0xb75bbb8e in DefaultBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:47 #12 0xb75bba33 in InvokeBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:25 #13 0xb75ccfa8 in Raise (act= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END) at RTExFrame.m3:29 #14 0xb759fcff in ReportFault (module=16_b75fadc0, info=37888) at RTHooks.m3:110 #15 0xb75d62de in _m3_fault (arg=37888) from /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 #16 0xb75d4e8e in SignalHandler (sig=64, sip=16_b53baf8c, uap=16_b53bb00c) at ThreadPThread.m3:1184 #17 #18 0xffffe410 in __kernel_vsyscall () #19 0xb755f3c1 in __lll_mutex_unlock_wake () from /lib/tls/i686/cmov/libpthread.so.0 #20 0xb755c2df in _L_mutex_unlock_128 () from /lib/tls/i686/cmov/libpthread.so.0 #21 0xb53bb358 in ?? () ---Type to continue, or q to quit--- #22 0xb75cecef in Release (m=16_b75fadf4) at ThreadPThread.m3:186 #23 0xb75cecef in Release (m=16_b73c0004) at ThreadPThread.m3:186 #24 0xb75d1aa9 in RunThread (me=16_08054700) at ThreadPThread.m3:536 #25 0xb75d17e6 in ThreadBase (param=16_08054700) at ThreadPThread.m3:521 #26 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #27 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. 4Couldn't get registers: No such process. (m3gdb) Thanks --- "Daniel Alejandro Benavides D." wrote: > Hi: > With @M3noincremental just runs for while > > 1 2 3 1 2 3 10 > 5 4 > > and in this state its like a freezed program, it > does > not respond to the keyboard input. > > With @M3nogenerational or @M3nogc runs just fine. > > What could be the problem? What else could be useful > to do? > > Thanks > > --- Antony Hosking wrote: > > > In the pthread implementation scheduling is > > performed by the OS so > > there is no way to say that any particular thread > is > > *alive*, just > > that it is eligible to run should the scheduler > > choose to run it > > (indeed on an SMP more than one thread can run at > a > > time). The user- > > thread implementation has its own scheduler, so it > > knows precisely > > which thread is running at any point in time. > > > > Are you saying there is a bug in the current > pthread > > implementation? > > If so, then I'd like a more precise > characterization > > that I can > > pursue and fix. > > > > On Sep 27, 2007, at 2:32 AM, Daniel Alejandro > > Benavides D. wrote: > > > > > Hi: > > > I am testing some examples of Chapter 16 of > Laszlo > > > book, but the text shows me that now the > NThreads > > > example where 10 threads are being showing the > IDs > > (1, > > > 2, ... ,10). > > > This is tested on ubuntu Dapper OS, which still > > allows > > > the use of user space threads implementation. > > > Attached are some animated gif files that show > in > > > (sorry have no web page available) > > > LINUXLIBC6.gif exmaple execution of Systems > level > > > threads > > > LINUXLIBC62.gif example execution of User space > > > threads > > > LINUXLIBC62a.gif example execution of User space > > > threads after it ends > > > > > > Why the different versions of thread > > implementation > > > are different, in terms of what showthread shows > > that > > > all the threads are "locking" (9 almost all > time) > > and > > > 2 (the first and third form left to right) are > > "alive" > > > in the Pthread case, and why in the user space > > threads > > > case they are "alive" green color almost always > if > > > they are not running. > > > The worst thing is the behaviour of the > appication > > is > > > very rare, It should be running until a key > > (enter) is > > > pressed down; It just runs some seconds in > pthread > > > case. > > > > > > Besides why some many objects are shown in > shownew > > > with the user space threaded program. > > > > > > The linking information of ldd output is below. > > > LINUXLIBC6 is current cvs compiled example > > > LINUXLIBC&2 compiled with user spce threads. > > > > > > on LINUXLIBC6 with user space threads, June 9th > > the > > > date It was compiled. > > > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > > LINUXLIBC62/NThreads > > > linux-gate.so.1 => (0xffffe000) > > > libm3local.so.5 => > > > > > > /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > > (0xb7faf000) > > > libm3.so.5 => > > > /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 > > > (0xb7e90000) > > > libm3core.so.5 => > > > > > > /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > > (0xb760f000) > > > libm3gcdefs.so.5 => > > > /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) > > > libm.so.6 => > /lib/tls/i686/cmov/libm.so.6 > > > (0xb75d1000) > > > libc.so.6 => > /lib/tls/i686/cmov/libc.so.6 > > > (0xb74a2000) > > > /lib/ld-linux.so.2 (0xb7fbd000) > > > > > > > > > on LINUXLIBC6 with system threads: > > > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > > LINUXLIBC6/NThreads > > > linux-gate.so.1 => (0xffffe000) > > > libm3local.so.5 => > > > > > > /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > > (0xb7f51000) > > > libm3.so.5 => > > > > > > /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 > > > (0xb7e1e000) > > > libm3core.so.5 => > > > > > > /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > > (0xb7592000) > > > libpthread.so.0 => > > > /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) > > > libm.so.6 => > /lib/tls/i686/cmov/libm.so.6 > > > (0xb7544000) > > > libc.so.6 => > /lib/tls/i686/cmov/libc.so.6 > > > (0xb7415000) > > > /lib/ld-linux.so.2 (0xb7f5f000) > > > > > > > > > the source code is this > > > > > > MODULE NThreads EXPORTS Main; > > > (*22.02.95. LB*) > > > (* Program starts "N" threads which output their > > ID > > > and terminate > > > if a key is pressed (on some systems you have > > to > > > press the return > > > key). > > > *) > > > > > > IMPORT Thread, SIO; > > > FROM Scheduler IMPORT Yield; > > > > > > CONST > > > N = 10; > > > TYPE > > > Threads = [1..N]; > > > Closure = Thread.Closure OBJECT > > > id: Threads; > > > (*identifies thread*) > > > OVERRIDES > > > apply:= PrintId; > > > END; (*Closure*) > > > > > > PROCEDURE PrintId(cl: Closure): REFANY = > > > BEGIN > > > REPEAT > > > SIO.PutInt(cl.id); > > > IF cl.id = LAST(Threads) THEN SIO.Nl() > END; > > > Yield(); > > > (*yields to other threads*) > > > UNTIL SIO.Available(); > > > RETURN NIL; > > > (*return value not used*) > > > END PrintId; > > > > > > PROCEDURE Fork() = > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Fri Sep 28 17:02:59 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 28 Sep 2007 17:02:59 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <860980.52128.qm@web27109.mail.ukl.yahoo.com> Message-ID: <532140.63470.qm@web27105.mail.ukl.yahoo.com> Hi: I would like to know if it is necessary to turn down the garbage collection to debug a M3 program. I know running a program inside gdb in general could cause some runtime diferences withj normal execution, like the cout<< in C++, which is reliable under debugging conditions, but not in normal execution conditions in a program which calls it constantly (that happened me on 2005), so one can note that the behaviour would be better on debug conditions, thats why I think this is not maybe the problem on NThreads program (is easy to say that if we think that the runtime errors showed inside m3gdb are not present when the program executes normally), tough I debugged one more time to show other backtraces: (m3gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads Error in re-setting breakpoint 3: No source file named ThreadPThread.m3. Error in re-setting breakpoint 3: No source file named ThreadPThread.m3. Error in re-setting breakpoint 3: No source file named ThreadPThread.m3. Breakpoint 3 at 0xb7654dba: file ThreadPThread.m3, line 1180. [Thread debugging using libthread_db enabled] [New Thread -1220008256 (LWP 8474)] [Switching to Thread -1220008256 (LWP 8474)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447010) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1220281424 (LWP 8495)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447058) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1228674128 (LWP 8496)] 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb74470a0) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 1[New Thread -1237066832 (LWP 8497)] 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb74470e8) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 2 1[New Thread -1245459536 (LWP 8498)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447130) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 3 2 1[New Thread -1253852240 (LWP 8499)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1253852240 (LWP 8499)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. [Switching to Thread -1220008256 (LWP 8474)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1237066832 (LWP 8497)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1228674128 (LWP 8496)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1220281424 (LWP 8495)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. [Switching to Thread -1253852240 (LWP 8499)] Breakpoint 3, SignalHandler (sig=64, sip=16_b543af8c, uap=16_b543b00c) at ThreadPThread.m3:1180 1180 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b543af8c, uap=16_b543b00c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb75df3c1 in __lll_mutex_unlock_wake () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb75dc2df in _L_mutex_unlock_128 () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb543b358 in ?? () #6 0xb764ecef in Release (m=16_b767adf4) at ThreadPThread.m3:186 #7 0xb764ecef in Release (m=16_b7440004) at ThreadPThread.m3:186 #8 0xb7651aa9 in RunThread (me=16_08054700) at ThreadPThread.m3:536 #9 0xb76517e6 in ThreadBase (param=16_08054700) at ThreadPThread.m3:521 #10 0xb75da341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #11 0xb754c4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) step 1181 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1237066832 (LWP 8497)] Breakpoint 3, SignalHandler (sig=64, sip=16_b643cf9c, uap=16_b643d01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1228674128 (LWP 8496)] Breakpoint 3, SignalHandler (sig=64, sip=16_b6c3df9c, uap=16_b6c3e01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1220281424 (LWP 8495)] Breakpoint 3, SignalHandler (sig=64, sip=16_b743ef9c, uap=16_b743f01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Program received signal SIG64, Real-time event 64. [Switching to Thread -1220008256 (LWP 8474)] 0xffffe410 in __kernel_vsyscall () (m3gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb75dcc76 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7655ae0 in LockHeap () at ThreadPThread.m3:1370 #3 0xb76213ca in GetUntracedRef (def=16_b767af38) at RTAllocator.m3:240 #4 0xb7620b4a in AllocateUntracedRef (defn=16_b767af38) at RTAllocator.m3:146 #5 0xb7652003 in Fork (closure=16_b7447178) at ThreadPThread.m3:575 #6 0x0804b8b6 in Fork () at NThreads.m3:33 #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 #8 0xb763a87a in RunMainBody (m=16_0804dc60) at RTLinker.m3:399 #9 0xb7639174 in AddUnitI (m=16_0804dc60) at RTLinker.m3:113 #10 0xb763920b in AddUnit (b={"NThreads_M3", Declared at: NThreads.m3:38}) at RTLinker.m3:122 #11 0x08048ea8 in main (argc=1, argv=0xbfce0c04, envp=0xbfce0c0c) at _m3main.mc:4 (m3gdb) step Single stepping until exit from function __kernel_vsyscall, which has no line number information. SignalHandler (sig=64, sip=16_bfce042c, uap=16_bfce04ac) at ThreadPThread.m3:1157 1157 in ThreadPThread.m3 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** 1161 in ThreadPThread.m3 (m3gdb) step m3_Cerrno_GetErrno () at ../src/C/Common/CerrnoC.c:10 10 ../src/C/Common/CerrnoC.c: No such file or directory. in ../src/C/Common/CerrnoC.c Current language: auto; currently c (m3gdb) step 11 in ../src/C/Common/CerrnoC.c (m3gdb) step SignalHandler (sig=64, sip=16_bfce042c, uap=16_bfce04ac) at ThreadPThread.m3:1163 1163 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 Current language: auto; currently Modula-3 (m3gdb) step GetActivation () at ThreadPThread.m3:368 368 in ThreadPThread.m3 (m3gdb) step 369 in ThreadPThread.m3 (m3gdb) step SignalHandler (sig=64, sip=16_bfce042c, uap=16_bfce04ac) at ThreadPThread.m3:1166 1166 in ThreadPThread.m3 (m3gdb) step 1167 in ThreadPThread.m3 (m3gdb) step 1168 in ThreadPThread.m3 (m3gdb) step 1169 in ThreadPThread.m3 (m3gdb) step 1172 in ThreadPThread.m3 (m3gdb) step 1174 in ThreadPThread.m3 (m3gdb) step 1175 in ThreadPThread.m3 (m3gdb) step 1178 in ThreadPThread.m3 (m3gdb) step 4 4 4 4 4 4 Program received signal SIGABRT, Aborted. [Switching to Thread -1237066832 (LWP 8497)] 0xffffe410 in __kernel_vsyscall () (m3gdb) step Single stepping until exit from function __kernel_vsyscall, Thanks --- "Daniel Alejandro Benavides D." wrote: > Hi: > > I debugged for a while the program with > handle all nostop > handle EXC_SOFTWARE stop > handle EXC_BREAKPOINT stop > > getting this: > > Breakpoint 4, SignalHandler (sig=64, > sip=16_b640ff9c, > uap=16_b641001c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1254036560 (LWP 8072)] > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b540df8c, > uap=16_b540e00c) at ThreadPThread.m3:1184 > 1184 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1237251152 (LWP 8067)] > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b640ff9c, > uap=16_b641001c) at ThreadPThread.m3:1184 > 1184 in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b640ff9c, > uap=16_b641001c) at ThreadPThread.m3:1184 > #1 > #2 0xffffe410 in __kernel_vsyscall () > #3 0xb7505b8c in sched_yield () from > /lib/tls/i686/cmov/libc.so.6 > #4 0xb7625fce in Yield () at ThreadPThread.m3:712 > #5 0x0804b844 in PrintId (cl=16_b741b0a0) at > NThreads.m3:25 > #6 0xb7624b21 in RunThread (me=16_08054560) at > ThreadPThread.m3:540 > #7 0xb76247e6 in ThreadBase (param=16_08054560) at > ThreadPThread.m3:521 > #8 0xb75ad341 in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #9 0xb751f4ee in clone () from > /lib/tls/i686/cmov/libc.so.6 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file > "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > [Switching to Thread -1228858448 (LWP 8066)] > > Breakpoint 4, SignalHandler (sig=64, > sip=16_b6c10f9c, > uap=16_b6c1101c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b6c10f9c, > uap=16_b6c1101c) at ThreadPThread.m3:1184 > 1184 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file > "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220465744 (LWP 8065)] > > Breakpoint 4, SignalHandler (sig=64, > sip=16_b7411f9c, > uap=16_b741201c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > 4 4 > Program received signal SIGABRT, Aborted. > 4Couldn't get registers: No such process. > (m3gdb) > ----------------------------------------------------- > And then without modifying the signal set: > > (m3gdb) break NThreads.m3:10 > Breakpoint 1 at 0x804b934: file NThreads.m3, line > 10. > (m3gdb) break ThreadPThread.m3:1180 > No source file named ThreadPThread.m3. > Make breakpoint pending on future shared library > load? > (y or [n]) y > Breakpoint 2 (ThreadPThread.m3:1180) pending. > (m3gdb) run > Starting program: > /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads > [Thread debugging using libthread_db enabled] > [New Thread -1220532544 (LWP 8125)] > Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, > line 1180. > Pending breakpoint "ThreadPThread.m3:1180" resolved > [Switching to Thread -1220532544 (LWP 8125)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7010) at NThreads.m3:14 > warning: Source file is more recent than executable. > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1220805712 (LWP 8131)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7058) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1229198416 (LWP 8132)] > 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c70a0) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 1[New Thread -1237591120 (LWP 8133)] > 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c70e8) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 2 1[New Thread -1245983824 (LWP 8134)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7130) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 3 2 1[New Thread -1254376528 (LWP 8135)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at > NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1254376528 (LWP 8135)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1237591120 (LWP 8133)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1229198416 (LWP 8132)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220805712 (LWP 8131)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1254376528 (LWP 8135)] > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b53baf8c, > uap=16_b53bb00c) at ThreadPThread.m3:1180 > 1180 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b53baf8c, > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 28 17:35:25 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Sep 2007 11:35:25 -0400 Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <532140.63470.qm@web27105.mail.ukl.yahoo.com> References: <532140.63470.qm@web27105.mail.ukl.yahoo.com> Message-ID: On Sep 28, 2007, at 11:02 AM, Daniel Alejandro Benavides D. wrote: > Hi: > I would like to know if it is necessary to turn down > the garbage collection to debug a M3 program. > I know running a program inside gdb in general could > cause some runtime diferences withj normal execution, > like the cout<< in C++, which is reliable under > debugging conditions, but not in normal execution > conditions in a program which calls it constantly > (that happened me on 2005), so one can note that the > behaviour would be better on debug conditions, thats > why I think this is not maybe the problem on NThreads > program (is easy to say that if we think that the > runtime errors showed inside m3gdb are not present > when the program executes normally), tough I debugged > one more time to show other backtraces: Debugging with GC enabled should be fine, except that you will not necessarily see the same non-deterministic behavior as when it runs outside the debugger. Regarding the assert that is failing, that indicates that sigwait is returning an error, which seems odd. I will try this program on my own Linux system. > > (m3gdb) run > The program being debugged has been started already. > Start it from the beginning? (y or n) y > Starting program: > /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Breakpoint 3 at 0xb7654dba: file ThreadPThread.m3, > line 1180. > [Thread debugging using libthread_db enabled] > [New Thread -1220008256 (LWP 8474)] > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447010) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1220281424 (LWP 8495)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447058) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1228674128 (LWP 8496)] > 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470a0) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 1[New Thread -1237066832 (LWP 8497)] > 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470e8) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 2 1[New Thread -1245459536 (LWP 8498)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447130) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 3 2 1[New Thread -1253852240 (LWP 8499)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at > NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1253852240 (LWP 8499)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1228674128 (LWP 8496)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220281424 (LWP 8495)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1253852240 (LWP 8499)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > 1180 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > #1 > #2 0xffffe410 in __kernel_vsyscall () > #3 0xb75df3c1 in __lll_mutex_unlock_wake () from > /lib/tls/i686/cmov/libpthread.so.0 > #4 0xb75dc2df in _L_mutex_unlock_128 () from > /lib/tls/i686/cmov/libpthread.so.0 > #5 0xb543b358 in ?? () > #6 0xb764ecef in Release (m=16_b767adf4) at > ThreadPThread.m3:186 > #7 0xb764ecef in Release (m=16_b7440004) at > ThreadPThread.m3:186 > #8 0xb7651aa9 in RunThread (me=16_08054700) at > ThreadPThread.m3:536 > #9 0xb76517e6 in ThreadBase (param=16_08054700) at > ThreadPThread.m3:521 > #10 0xb75da341 in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #11 0xb754c4ee in clone () from > /lib/tls/i686/cmov/libc.so.6 > (m3gdb) step > 1181 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1237066832 (LWP 8497)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b643cf9c, > uap=16_b643d01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1228674128 (LWP 8496)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b6c3df9c, > uap=16_b6c3e01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1220281424 (LWP 8495)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b743ef9c, > uap=16_b743f01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220008256 (LWP 8474)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) where > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb75dcc76 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/tls/i686/cmov/libpthread.so.0 > #2 0xb7655ae0 in LockHeap () at ThreadPThread.m3:1370 > #3 0xb76213ca in GetUntracedRef (def=16_b767af38) at > RTAllocator.m3:240 > #4 0xb7620b4a in AllocateUntracedRef > (defn=16_b767af38) at RTAllocator.m3:146 > #5 0xb7652003 in Fork (closure=16_b7447178) at > ThreadPThread.m3:575 > #6 0x0804b8b6 in Fork () at NThreads.m3:33 > #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 > #8 0xb763a87a in RunMainBody (m=16_0804dc60) at > RTLinker.m3:399 > #9 0xb7639174 in AddUnitI (m=16_0804dc60) at > RTLinker.m3:113 > #10 0xb763920b in AddUnit (b={"NThreads_M3", Declared > at: NThreads.m3:38}) at RTLinker.m3:122 > #11 0x08048ea8 in main (argc=1, argv=0xbfce0c04, > envp=0xbfce0c0c) at _m3main.mc:4 > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > which has no line number information. > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1157 > 1157 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > 1161 in ThreadPThread.m3 > (m3gdb) step > m3_Cerrno_GetErrno () at ../src/C/Common/CerrnoC.c:10 > 10 ../src/C/Common/CerrnoC.c: No such file or > directory. > in ../src/C/Common/CerrnoC.c > Current language: auto; currently c > (m3gdb) step > 11 in ../src/C/Common/CerrnoC.c > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1163 > 1163 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > Current language: auto; currently Modula-3 > (m3gdb) step > GetActivation () at ThreadPThread.m3:368 > 368 in ThreadPThread.m3 > (m3gdb) step > 369 in ThreadPThread.m3 > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1166 > 1166 in ThreadPThread.m3 > (m3gdb) step > 1167 in ThreadPThread.m3 > (m3gdb) step > 1168 in ThreadPThread.m3 > (m3gdb) step > 1169 in ThreadPThread.m3 > (m3gdb) step > 1172 in ThreadPThread.m3 > (m3gdb) step > 1174 in ThreadPThread.m3 > (m3gdb) step > 1175 in ThreadPThread.m3 > (m3gdb) step > 1178 in ThreadPThread.m3 > (m3gdb) step > 4 4 4 4 4 4 > Program received signal SIGABRT, Aborted. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > > Thanks > > --- "Daniel Alejandro Benavides D." > wrote: > >> Hi: >> >> I debugged for a while the program with >> handle all nostop >> handle EXC_SOFTWARE stop >> handle EXC_BREAKPOINT stop >> >> getting this: >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1254036560 (LWP 8072)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b540df8c, >> uap=16_b540e00c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1237251152 (LWP 8067)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> #1 >> #2 0xffffe410 in __kernel_vsyscall () >> #3 0xb7505b8c in sched_yield () from >> /lib/tls/i686/cmov/libc.so.6 >> #4 0xb7625fce in Yield () at ThreadPThread.m3:712 >> #5 0x0804b844 in PrintId (cl=16_b741b0a0) at >> NThreads.m3:25 >> #6 0xb7624b21 in RunThread (me=16_08054560) at >> ThreadPThread.m3:540 >> #7 0xb76247e6 in ThreadBase (param=16_08054560) at >> ThreadPThread.m3:521 >> #8 0xb75ad341 in start_thread () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #9 0xb751f4ee in clone () from >> /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> [Switching to Thread -1228858448 (LWP 8066)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220465744 (LWP 8065)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b7411f9c, >> uap=16_b741201c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> 4 4 >> Program received signal SIGABRT, Aborted. >> 4Couldn't get registers: No such process. >> (m3gdb) >> > ----------------------------------------------------- >> And then without modifying the signal set: >> >> (m3gdb) break NThreads.m3:10 >> Breakpoint 1 at 0x804b934: file NThreads.m3, line >> 10. >> (m3gdb) break ThreadPThread.m3:1180 >> No source file named ThreadPThread.m3. >> Make breakpoint pending on future shared library >> load? >> (y or [n]) y >> Breakpoint 2 (ThreadPThread.m3:1180) pending. >> (m3gdb) run >> Starting program: >> /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads >> [Thread debugging using libthread_db enabled] >> [New Thread -1220532544 (LWP 8125)] >> Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, >> line 1180. >> Pending breakpoint "ThreadPThread.m3:1180" resolved >> [Switching to Thread -1220532544 (LWP 8125)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7010) at NThreads.m3:14 >> warning: Source file is more recent than executable. >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1220805712 (LWP 8131)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7058) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1229198416 (LWP 8132)] >> 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70a0) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 1[New Thread -1237591120 (LWP 8133)] >> 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70e8) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 2 1[New Thread -1245983824 (LWP 8134)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7130) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 3 2 1[New Thread -1254376528 (LWP 8135)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at >> NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1254376528 (LWP 8135)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1237591120 (LWP 8133)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1229198416 (LWP 8132)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220805712 (LWP 8131)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> [Switching to Thread -1254376528 (LWP 8135)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b53baf8c, >> uap=16_b53bb00c) at ThreadPThread.m3:1180 >> 1180 ThreadPThread.m3: No such file or directory. >> in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b53baf8c, >> > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 28 19:40:22 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Sep 2007 13:40:22 -0400 Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <532140.63470.qm@web27105.mail.ukl.yahoo.com> References: <532140.63470.qm@web27105.mail.ukl.yahoo.com> Message-ID: <11736B53-EB34-4501-ABAF-496CE88C9170@cs.purdue.edu> The nthreads program runs just fine on my Fedora Core system (modulo unpredictable scheduling which is to be expected for a program running with system threads). I wonder if the problems you are seeing come from an old version (non-NPTL) of libpthread on your Linux system? I have glibc 2.5.18. On Sep 28, 2007, at 11:02 AM, Daniel Alejandro Benavides D. wrote: > Hi: > I would like to know if it is necessary to turn down > the garbage collection to debug a M3 program. > I know running a program inside gdb in general could > cause some runtime diferences withj normal execution, > like the cout<< in C++, which is reliable under > debugging conditions, but not in normal execution > conditions in a program which calls it constantly > (that happened me on 2005), so one can note that the > behaviour would be better on debug conditions, thats > why I think this is not maybe the problem on NThreads > program (is easy to say that if we think that the > runtime errors showed inside m3gdb are not present > when the program executes normally), tough I debugged > one more time to show other backtraces: > > (m3gdb) run > The program being debugged has been started already. > Start it from the beginning? (y or n) y > Starting program: > /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Breakpoint 3 at 0xb7654dba: file ThreadPThread.m3, > line 1180. > [Thread debugging using libthread_db enabled] > [New Thread -1220008256 (LWP 8474)] > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447010) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1220281424 (LWP 8495)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447058) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1228674128 (LWP 8496)] > 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470a0) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 1[New Thread -1237066832 (LWP 8497)] > 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470e8) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 2 1[New Thread -1245459536 (LWP 8498)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447130) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 3 2 1[New Thread -1253852240 (LWP 8499)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at > NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1253852240 (LWP 8499)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1228674128 (LWP 8496)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220281424 (LWP 8495)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1253852240 (LWP 8499)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > 1180 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > #1 > #2 0xffffe410 in __kernel_vsyscall () > #3 0xb75df3c1 in __lll_mutex_unlock_wake () from > /lib/tls/i686/cmov/libpthread.so.0 > #4 0xb75dc2df in _L_mutex_unlock_128 () from > /lib/tls/i686/cmov/libpthread.so.0 > #5 0xb543b358 in ?? () > #6 0xb764ecef in Release (m=16_b767adf4) at > ThreadPThread.m3:186 > #7 0xb764ecef in Release (m=16_b7440004) at > ThreadPThread.m3:186 > #8 0xb7651aa9 in RunThread (me=16_08054700) at > ThreadPThread.m3:536 > #9 0xb76517e6 in ThreadBase (param=16_08054700) at > ThreadPThread.m3:521 > #10 0xb75da341 in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #11 0xb754c4ee in clone () from > /lib/tls/i686/cmov/libc.so.6 > (m3gdb) step > 1181 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1237066832 (LWP 8497)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b643cf9c, > uap=16_b643d01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1228674128 (LWP 8496)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b6c3df9c, > uap=16_b6c3e01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1220281424 (LWP 8495)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b743ef9c, > uap=16_b743f01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220008256 (LWP 8474)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) where > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb75dcc76 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/tls/i686/cmov/libpthread.so.0 > #2 0xb7655ae0 in LockHeap () at ThreadPThread.m3:1370 > #3 0xb76213ca in GetUntracedRef (def=16_b767af38) at > RTAllocator.m3:240 > #4 0xb7620b4a in AllocateUntracedRef > (defn=16_b767af38) at RTAllocator.m3:146 > #5 0xb7652003 in Fork (closure=16_b7447178) at > ThreadPThread.m3:575 > #6 0x0804b8b6 in Fork () at NThreads.m3:33 > #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 > #8 0xb763a87a in RunMainBody (m=16_0804dc60) at > RTLinker.m3:399 > #9 0xb7639174 in AddUnitI (m=16_0804dc60) at > RTLinker.m3:113 > #10 0xb763920b in AddUnit (b={"NThreads_M3", Declared > at: NThreads.m3:38}) at RTLinker.m3:122 > #11 0x08048ea8 in main (argc=1, argv=0xbfce0c04, > envp=0xbfce0c0c) at _m3main.mc:4 > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > which has no line number information. > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1157 > 1157 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > 1161 in ThreadPThread.m3 > (m3gdb) step > m3_Cerrno_GetErrno () at ../src/C/Common/CerrnoC.c:10 > 10 ../src/C/Common/CerrnoC.c: No such file or > directory. > in ../src/C/Common/CerrnoC.c > Current language: auto; currently c > (m3gdb) step > 11 in ../src/C/Common/CerrnoC.c > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1163 > 1163 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > Current language: auto; currently Modula-3 > (m3gdb) step > GetActivation () at ThreadPThread.m3:368 > 368 in ThreadPThread.m3 > (m3gdb) step > 369 in ThreadPThread.m3 > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1166 > 1166 in ThreadPThread.m3 > (m3gdb) step > 1167 in ThreadPThread.m3 > (m3gdb) step > 1168 in ThreadPThread.m3 > (m3gdb) step > 1169 in ThreadPThread.m3 > (m3gdb) step > 1172 in ThreadPThread.m3 > (m3gdb) step > 1174 in ThreadPThread.m3 > (m3gdb) step > 1175 in ThreadPThread.m3 > (m3gdb) step > 1178 in ThreadPThread.m3 > (m3gdb) step > 4 4 4 4 4 4 > Program received signal SIGABRT, Aborted. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > > Thanks > > --- "Daniel Alejandro Benavides D." > wrote: > >> Hi: >> >> I debugged for a while the program with >> handle all nostop >> handle EXC_SOFTWARE stop >> handle EXC_BREAKPOINT stop >> >> getting this: >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1254036560 (LWP 8072)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b540df8c, >> uap=16_b540e00c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1237251152 (LWP 8067)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> #1 >> #2 0xffffe410 in __kernel_vsyscall () >> #3 0xb7505b8c in sched_yield () from >> /lib/tls/i686/cmov/libc.so.6 >> #4 0xb7625fce in Yield () at ThreadPThread.m3:712 >> #5 0x0804b844 in PrintId (cl=16_b741b0a0) at >> NThreads.m3:25 >> #6 0xb7624b21 in RunThread (me=16_08054560) at >> ThreadPThread.m3:540 >> #7 0xb76247e6 in ThreadBase (param=16_08054560) at >> ThreadPThread.m3:521 >> #8 0xb75ad341 in start_thread () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #9 0xb751f4ee in clone () from >> /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> [Switching to Thread -1228858448 (LWP 8066)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220465744 (LWP 8065)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b7411f9c, >> uap=16_b741201c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> 4 4 >> Program received signal SIGABRT, Aborted. >> 4Couldn't get registers: No such process. >> (m3gdb) >> > ----------------------------------------------------- >> And then without modifying the signal set: >> >> (m3gdb) break NThreads.m3:10 >> Breakpoint 1 at 0x804b934: file NThreads.m3, line >> 10. >> (m3gdb) break ThreadPThread.m3:1180 >> No source file named ThreadPThread.m3. >> Make breakpoint pending on future shared library >> load? >> (y or [n]) y >> Breakpoint 2 (ThreadPThread.m3:1180) pending. >> (m3gdb) run >> Starting program: >> /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads >> [Thread debugging using libthread_db enabled] >> [New Thread -1220532544 (LWP 8125)] >> Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, >> line 1180. >> Pending breakpoint "ThreadPThread.m3:1180" resolved >> [Switching to Thread -1220532544 (LWP 8125)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7010) at NThreads.m3:14 >> warning: Source file is more recent than executable. >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1220805712 (LWP 8131)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7058) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1229198416 (LWP 8132)] >> 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70a0) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 1[New Thread -1237591120 (LWP 8133)] >> 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70e8) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 2 1[New Thread -1245983824 (LWP 8134)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7130) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 3 2 1[New Thread -1254376528 (LWP 8135)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at >> NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1254376528 (LWP 8135)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1237591120 (LWP 8133)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1229198416 (LWP 8132)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220805712 (LWP 8131)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> [Switching to Thread -1254376528 (LWP 8135)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b53baf8c, >> uap=16_b53bb00c) at ThreadPThread.m3:1180 >> 1180 ThreadPThread.m3: No such file or directory. >> in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b53baf8c, >> > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 28 19:59:32 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Sep 2007 13:59:32 -0400 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> <1B153BC7-A186-4F33-A019-91ADFEEC97FD@cs.purdue.edu> <90E9CEA8-6406-44E1-8265-9188B51B850D@cs.purdue.edu> Message-ID: <2559758D-5DE9-4CAF-B9D1-77F851B6310B@cs.purdue.edu> I forget if we tried the "paranoid" GC configuration or not. Can you run with @M3paranoidgc and see what happens? Again, I am unable to replicate the problems you are seeing, even on my Solaris 10 box. On Sep 26, 2007, at 2:03 PM, Alex Bochannek wrote: > I am back from vacation. I just updated my cm3 tree and did the usual > "do-cm3-core buildship; install-cm3-compiler upgrade; do-cm3-std > buildship" dance. I then did a make clean on cvsup and a make install. > > I not get reproducible core dumps every time I run it, with or without > GUI. cvsup startes and then cores: > > > -bash-3.00$ cvsup -g cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x51e9782c > *** > > Abort (core dumped) > -bash-3.00$ mdb core > $c > libc.so.1`_lwp_kill+8(6, 0, feea4af8, ffffffff, feee8284, 6) > libc.so.1`abort+0x110(fec1eeb0, 1, 48c988, a8390, feeeb298, 0) > RTOS__Crash+4(1, 1d, df7fb0, e09fa0, 533dbc, 0) > RTProcess__Crash+0x98(0, a, 10, 0, 0, 0) > RTError__EndError+0x58(1, fec1f20c, fec1f210, fec1f214, 0, 0) > RTError__ErrorPC+0x1d8(51e9782c, 531bbc, 0, 0, 1, 0) > RTError__MsgPC+0x38(51e9782c, 531bbc, 0, 0, 0, 0) > RTSignal__SegV+0x68(b, fec1f730, fec1f478, 1, 0, 1) > libc.so.1`__sighndlr+0xc(b, fec1f730, fec1f478, 44381c, 0, 1) > libc.so.1`call_user_handler+0x3b8(b, 0, 8, 0, fed11800, fec1f478) > 0x51e9782c(feba49b0, 2f, 7fffffff, 0, 0, 0) > SupMisc__PathLast+0x1c(feba49b0, fec660b0, 4924a0, 0, 0, 0) > TreeList__PutCollectionList+0x3a00(fedc8cd0, fedb29b8, 1, 0, > fedeb430, 0) > TreeList__ListCollection+0x4a4(fedc8cd0, fedb29b8, feeecbc0, > fed11800, 533b2c, 0 > ) > TreeList__Apply+0x2dc(fedc8cd0, 1000, feeecbc0, fed11800, 533b68, 0) > ThreadPThread__RunThread+0x3c4(d4a1e0, 0, 0, 0, 0, 1) > ThreadPThread__ThreadBase+0x44(d4a1e0, fec20000, 0, 0, 44bae4, 1) > libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) > > I am not sure if that is even in the Modula-3 libraries, but you can > probably tell. Here's the ls; ldd: > > -rwxr-xr-x 1 root other 5396444 Sep 26 10:56 /usr/local/ > bin/cvsup > libXaw.so.5 => /usr/lib/libXaw.so.5 > libXmu.so.4 => /usr/lib/libXmu.so.4 > libXext.so.0 => /usr/lib/libXext.so.0 > libXt.so.4 => /usr/lib/libXt.so.4 > libX11.so.4 => /usr/lib/libX11.so.4 > libsocket.so.1 => /lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libw.so.1 => /lib/libw.so.1 > libdl.so.1 => /lib/libdl.so.1 > libpthread.so.1 => /lib/libpthread.so.1 > libthread.so.1 => /lib/libthread.so.1 > librt.so.1 => /lib/librt.so.1 > libm.so.2 => /lib/libm.so.2 > libc.so.1 => /lib/libc.so.1 > libSM.so.6 => /usr/openwin/lib/libSM.so.6 > libICE.so.6 => /usr/openwin/lib/libICE.so.6 > libmp.so.2 => /lib/libmp.so.2 > libmd5.so.1 => /lib/libmd5.so.1 > libscf.so.1 => /lib/libscf.so.1 > libaio.so.1 => /lib/libaio.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libmd5_psr.so.1 > > Hope this helps. Let me know what else I shoudl try. > > Alex. From alexb at juniper.net Fri Sep 28 22:59:29 2007 From: alexb at juniper.net (Alex Bochannek) Date: Fri, 28 Sep 2007 13:59:29 -0700 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: <2559758D-5DE9-4CAF-B9D1-77F851B6310B@cs.purdue.edu> (Tony Hosking's message of "Fri\, 28 Sep 2007 13\:59\:32 -0400") References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> <1B153BC7-A186-4F33-A019-91ADFEEC97FD@cs.purdue.edu> <90E9CEA8-6406-44E1-8265-9188B51B850D@cs.purdue.edu> <2559758D-5DE9-4CAF-B9D1-77F851B6310B@cs.purdue.edu> Message-ID: Tony Hosking writes: > I forget if we tried the "paranoid" GC configuration or not. Can you > run with @M3paranoidgc and see what happens? Again, I am unable to > replicate the problems you are seeing, even on my Solaris 10 box. Here's what I get now: -bash-3.00$ cvsup @M3paranoidgc -g cvsupfile.cm3-g cvsupfile.cm3 Connected to birch.elegosoft.com Updating collection cm3/cvs SetAttrs cm3/COPYRIGHT-BSD,v SetAttrs cm3/COPYRIGHT-CMASS,v SetAttrs cm3/COPYRIGHT-COLUMBIA,v SetAttrs cm3/COPYRIGHT-DEC,v SetAttrs cm3/COPYRIGHT-JDP,v SetAttrs cm3/COPYRIGHT-PURDUE,v SetAttrs cm3/COPYRIGHT-XEROX,v SetAttrs cm3/COPYRIGHTS,v SetAttrs cm3/README,v SetAttrs cm3/caltech-parser/COPYRIGHT,v SetAttrs cm3/caltech-parser/Makefile,v SetAttrs cm3/caltech-parser/PkgTags,v *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/runtime/common/RTCollector.m3", line 1770 *** Abort (core dumped) -bash-3.00$ mdb core3paranoidgc -g cvsupfile.cm3 Loading modules: [ libc.so.1 ld.so.1 ] > $c libc.so.1`_lwp_kill+8(6, 0, feea4af8, ffffffff, feee8284, 6) libc.so.1`abort+0x110(febfdc58, 1, 48c988, a8390, feeeb298, 0) RTOS__Crash+4(0, 44, 48, 0, 1113a18, 1113340) RTProcess__Crash+0x98(0, 4, a, 1, 200000, 100000) RTError__EndError+0x58(1, 0, 52f500, 0, 180c508, 8) RTError__MsgS+0xe4(52dadc, 6ea, 52f500, 52b660, 52f500, 52dadc) RTException__Crash+0x354(febfeb1c, 0, 52b510, 1, 200000, 100000) RTException__DefaultBackstop+0xf8(febfeb1c, 0, 0, fffffff8, 4, 12345678) RTException__InvokeBackstop+0x4c(febfeb1c, 0, ffffffff, fffffff8, 0, febfe571) RTException__Raise+0xec(febfeb1c, febfe6f8, 0, 0, 0, 0) RTException__DefaultBackstop+0x1f4(febfeb1c, 0, 0, fffffff8, 4, 12345678) RTException__InvokeBackstop+0x4c(febfeb1c, 0, ffffffff, fffffff8, 0, febfeaa1) RTException__Raise+0xec(febfeb1c, febfefb0, 7f59f, 0, 0, 0) RTHooks__ReportFault+0x138(52dc50, dd40, fedb0420, 0, 0, d6a710) 0x431948(dd40, 0, fedb0420, fed11c00, feeecc08, 0) RTCollector__RefSanityCheck+0x1c4(fedb0420, feb5a0a4, fedb0420, 1, 1, 1) RTHeapMap__Walk+0x6c8(feb5a0a4, 53949b, fedb0420, 4, fed11c00, fed11d00) RTHeapMap__DoWalkRef+0xac(5394ec, feb5a0a0, fedb0420, fed11c00, 533b2c, 0) RTHeapMap__DoWalkRef+0x6c(53969c, feb5a0a0, fedb0420, 4, d4a26c, fed11d00) RTHeapMap__WalkRef+0x194(feb5a09c, fedb0420, 0, 1000, 0, 0) RTCollector__SanityCheck+0x79c(fedb0004, febfefb0, 7f59f, 0, 0, 0) RTCollector__After+0x40(fedb0004, feb41668, 7f5a0, 0, 0, d6a710) RTHeapRep__InvokeMonitors+0x208(0, 38161524, e5bab, 0, 0, febff090) RTCollector__CollectSomeInStateFive+0x5f8(ff000000, 0, ff000000, ff000000, 0, fed11d00) RTCollector__CollectSome+0x158(1, 1000, feeecbc0, fed11c00, 533dbc, 0) RTCollector__CollectEnough+0xcc(d4a268, 4, feb5de80, fed11c00, 533b2c, 0) RTHeapRep__AllocTraced+0x194(52a45c, 94, 4, febff32c, d4a26c, 94) RTAllocator__GetOpenArray+0x1bc(52a45c, febff43c, ff000000, ff000000, 0, fed11d00) RTHooks__AllocateOpenArray+0x1c(52a45c, febff43c, ff000000, ff000000, 0, 0) Text8__Create+0xdc(88, 1000, feeecbc0, fed11c00, 533b2c, 0) Text8__New+0x5c(febff674, 1f, 4, febff668, d4a26c, 98) Text__FromChars+0xc8(febff674, 1f, 4, febff790, d4a26c, 30) SupMisc__GetCmdLine+0x72c(feb383a4, feb5de34, 0, 0, 0, 0) FileStatus__RdGetRaw+0x830(feb393f0, feb5df68, feb5de80, fed11c00, 533b2c, 0) StatusFile__Get+0x5b0(feb38260, feb5de34, 0, 0, 533b2c, 0) Detailer__SendCheckoutDetails+0x380(fec5c8f0, fedb2220, feb5de34, 0, 0, 0) Detailer__SendDetails+0x5c(fec5c8f0, fedb2220, feb5de34, 0, 0, 0) Detailer__DetailCollection+0x1efc(fec5c8f0, fedb2220, feb38190, fed11c00, 533b2c, 0) Detailer__Apply+0x5d8(fec5c8f0, 1000, feeecbc0, fed11c00, 533b68, 0) ThreadPThread__RunThread+0x3c4(d4a238, 0, 0, 0, 0, 1) ThreadPThread__ThreadBase+0x44(d4a238, fec00000, 0, 0, 44bae4, 1) libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) I also still get errors with directory creation when there aren't any yet: -bash-3.00$ cvsup @M3paranoidgc -g cvsupfile.cm3 Connected to birch.elegosoft.com Updating collection cm3/cvs Checkout cm3/COPYRIGHT-BSD Checkout cm3/COPYRIGHT-CMASS Checkout cm3/COPYRIGHT-COLUMBIA Checkout cm3/COPYRIGHT-DEC Checkout cm3/COPYRIGHT-JDP Checkout cm3/COPYRIGHT-PURDUE Checkout cm3/COPYRIGHT-XEROX Checkout cm3/COPYRIGHTS Checkout cm3/README Updater failed: Cannot create directories leading to "/opt/cm3/cm3-cvs/cm3/caltech-parser/#cvs.cvsup-3705.10": Resource temporarily unavailable Alex. From hosking at cs.purdue.edu Fri Sep 7 19:03:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 07 Sep 2007 17:03:29 -0000 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> Message-ID: Sounds like we are losing some references somewhere and the GC is prematurely collecting live objects. Alex, are you running on a 64- bit SPARC v9? Perhaps the SaveRegsInStack code needs updating for that platform to use the flushw instruction instead of trap 3. As it is, I am not entirely satisfied with the difficulties I've seen getting meaningful stack information on Solaris for stopped threads, but without a reliable way to diagnose the problem I don't know what to do from this end. See additional comments below: On Sep 7, 2007, at 12:04 AM, Alex Bochannek wrote: > Tony, John, > > I ran the tests some more and noticed that there is always a problem > with directory creation. The error I had mentioned before: > > Updater failed: Cannot create directories leading to "/opt/cm3/cm3- > cvs/cm3/caltech-parser/#cvs.cvsup-15483.1": Resource temporarily > unavailable > > happens pretty reliably whenever a directory (in this case > caltech-parser) needs to be created regardless of the options > below. This is running as root and cvsup not running setuid. I copied > the directory structure froman existing tree to even get the > examples to > run. (There is also an unrelated question for John below, please > read on.) > > Tony Hosking writes: > >> We are using the native threads package here, unless Alex has built >> without it. Alex, can you try running with each of the following > > Here's what I have the cvsup linked against: > > ldd /usr/local/bin/cvsup > libXaw.so.5 => /usr/lib/libXaw.so.5 > libXmu.so.4 => /usr/lib/libXmu.so.4 > libXext.so.0 => /usr/lib/libXext.so.0 > libXt.so.4 => /usr/lib/libXt.so.4 > libX11.so.4 => /usr/lib/libX11.so.4 > libsocket.so.1 => /lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libw.so.1 => /lib/libw.so.1 > libdl.so.1 => /lib/libdl.so.1 > libpthread.so.1 => /lib/libpthread.so.1 > libthread.so.1 => /lib/libthread.so.1 > librt.so.1 => /lib/librt.so.1 > libm.so.2 => /lib/libm.so.2 > libc.so.1 => /lib/libc.so.1 > libSM.so.6 => /usr/openwin/lib/libSM.so.6 > libICE.so.6 => /usr/openwin/lib/libICE.so.6 > libmp.so.2 => /lib/libmp.so.2 > libmd5.so.1 => /lib/libmd5.so.1 > libscf.so.1 => /lib/libscf.so.1 > libaio.so.1 => /lib/libaio.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libmd5_psr.so.1 > >> flag combinations and report the results: >> >> @M3nogc > > With the nogc options cvsup pretty much always runs all the way to > completion. It takes a while, especially on an existing tree, but it > will complete without problems. When you say "pretty much" what do you mean? Does it sometimes get an error? Is it the one you note above? > Trying the following failed: > >> @M3noincremental @M3nogenerational @M3paranoidgc >> >> @M3noincremental @M3paranoidgc >> >> @M3nogenerational @M3paranoidgc >> >> @M3paranoidgc > > -bash-3.00$ /usr/local/bin/cvsup -g cvsupfile.cm3 > Connected to birch.elegosoft.com > Updating collection cm3/cvs > SetAttrs cm3/COPYRIGHT-BSD,v > SetAttrs cm3/COPYRIGHT-CMASS,v > SetAttrs cm3/COPYRIGHT-COLUMBIA,v > SetAttrs cm3/COPYRIGHT-DEC,v > SetAttrs cm3/COPYRIGHT-JDP,v > SetAttrs cm3/COPYRIGHT-PURDUE,v > SetAttrs cm3/COPYRIGHT-XEROX,v > SetAttrs cm3/COPYRIGHTS,v > SetAttrs cm3/README,v > SetAttrs cm3/caltech-parser/COPYRIGHT,v > SetAttrs cm3/caltech-parser/Makefile,v > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3 > *** We may have collected something prematurely. > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3noincremental @M3nogenerational > @M3paranoidgc -g cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3 > *** > Ditto > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3noincremental @M3paranoidgc -g > cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3 > *** Ditto > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3nogenerational @M3paranoidgc -g > cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", line 1770 > *** This is the collector complaining that it found a reference in the heap to an object that has been reclaimed. > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3paranoidgc -g cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x421638 = NoteStackLocations + 0xac in ../src/runtime/ > common/RTCollector.m3 > *** > Looks like a bad sp error. > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", line 688 > *** This is knock-on from the previous error. > > Abort > -bash-3.00$ > > > I hope this helps and that you can get to the bottom of this. > > I am trying to compile a new CVSup to see why I keep getting checksum > mismatches that result in very long transfer times. I didn't think > that > when CVSup runs on a busy repository, that I should get those a > lot, but > especially during tagging operations, it seems like I end up with > transferring the entire repository. > > Alex. From hosking at cs.purdue.edu Fri Sep 7 20:12:37 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 07 Sep 2007 18:12:37 -0000 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> Message-ID: <1B153BC7-A186-4F33-A019-91ADFEEC97FD@cs.purdue.edu> Hmm... What output do you get with "cm3cg --version"? On my machine I see: /p/sss/cm3/bin/cm3cg --version Modula-3 backend version 4.1.1 (sparc-sun-solaris2.8) compiled by GNU C version 4.1.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min- heapsize=131072 On Sep 7, 2007, at 1:51 PM, Alex Bochannek wrote: > Tony Hosking writes: > >> Sounds like we are losing some references somewhere and the GC is >> prematurely collecting live objects. Alex, are you running on a 64- >> bit SPARC v9? Perhaps the SaveRegsInStack code needs updating for > > Yes. > > -bash-3.00$ isainfo -kv; isainfo -v > 64-bit sparcv9 kernel modules > 64-bit sparcv9 applications > vis2 vis > 32-bit sparc applications > vis2 vis v8plus div32 mul32 > >> that platform to use the flushw instruction instead of trap 3. As it >> is, I am not entirely satisfied with the difficulties I've seen >> getting meaningful stack information on Solaris for stopped threads, >> but without a reliable way to diagnose the problem I don't know what >> to do from this end. See additional comments below: > >>> With the nogc options cvsup pretty much always runs all the way to >>> completion. It takes a while, especially on an existing tree, but it >>> will complete without problems. >> >> When you say "pretty much" what do you mean? Does it sometimes >> get an >> error? Is it the one you note above? > > I should have been more precise here. Every time I ran cvsup with > @M3nogc and I let it run to completion, it completed without > error. Since it took a while, I did interrupt it a few times during > testing. > > Alex. From jay.krell at cornell.edu Fri Sep 7 21:20:33 2007 From: jay.krell at cornell.edu (Jay) Date: Fri, 07 Sep 2007 19:20:33 -0000 Subject: [M3devel] mailing lists? Message-ID: m3devel and m3commit working? - Jay _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Sep 12 21:48:00 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 12 Sep 2007 19:48:00 -0000 Subject: [M3devel] Note on an obscure m3gdb/compiler interaction Message-ID: <46E8427A.4000607@wichita.edu> If you link in a library, all the code of the entire library is loaded into your address space, and all the debug data is available to m3gdb, even for modules in the library but not in the import/export closure of the main program. This means you can call procedures in such modules from m3gdb commands. However, there is initialization of global data that the compilers take care of only for modules in the closure. If you call something from m3gdb that is in memory but not initialized, various bad things can happen. As an example, you can always call RTTypeFP.FromFingerprint, because it is in libm3core. And this could be a useful thing to want to do during a debug session (e.g., when debugging something involving pickles). But if you do this when RTTypeFP is not in the closure, there will be a segment fault while trying allocate a heap object of a type whose type definition pointer in the global space of RTTypeFP is uninitialized. Even the needed type definition is present, but the needed pointer to it is not set up. For now, the only workaround is add an IMPORT of the needed module to the code and recompile, before trying the call from m3gdb. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jay.krell at cornell.edu Thu Sep 13 15:13:02 2007 From: jay.krell at cornell.edu (Jay) Date: Thu, 13 Sep 2007 13:13:02 -0000 Subject: [M3devel] testing...#1 (cornell) Message-ID: Seeing if these go through..it's been quite a few days not working.. I don't think the problem is on my end, but could be. (I do have a setup now that sends from one address, but "claims" another, and the claimed one works and forwards, providing flexibility...) - Jay _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 13 15:15:20 2007 From: jay.krell at cornell.edu (Jay) Date: Thu, 13 Sep 2007 13:15:20 -0000 Subject: [M3devel] testing...#2 (hotmail) Message-ID: sorry for the spam..I waited several days and send less spammy tests... (and some submits) - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.com; m3-support at elego.de; m3-support at elegosoft.comCC: "Tony Hosking" " ; " ronny.forberger at elegosoft.com " ; " rcoleburn at scires.com " ; " Daniel Alejandro Benavides D." "Subject: testing...#1 (cornell)Date: Thu, 13 Sep 2007 13:12:50 +0000 Seeing if these go through..it's been quite a few days not working..I don't think the problem is on my end, but could be.(I do have a setup now that sends from one address, but "claims" another, and the claimed one works and forwards, providing flexibility...) - Jay Make your little one a shining star! Shine on! _________________________________________________________________ Gear up for Halo? 3 with free downloads and an exclusive offer. It?s our way of saying thanks for using Windows Live?. http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Sep 14 04:02:49 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 14 Sep 2007 02:02:49 -0000 Subject: [M3devel] A RT failure in ThreadPThread.Alert Message-ID: <46E9EBD3.1060603@wichita.edu> I got a runtime failure in ThreadPThread.Alert, on this line: ---------------------------------------------------------------------------------- PROCEDURE Alert (t: T) = BEGIN WITH r = Upthread.mutex_lock(cm) DO <*ASSERT r=0*> END; t.alerted := TRUE; --> WITH r = Upthread.cond_signal(t.waitCond^) DO <*ASSERT r=0*> END; WITH r = Upthread.mutex_unlock(cm) DO <*ASSERT r=0*> END; END Alert; ------------------------------------------------------------------------------------ Here, t.waitCond is NIL and being dereferenced. Here is a bit of debugger output: The display of t is at the bottom. ------------------------------------------------------------------------------------ *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 304 *** ------------------ EXCEPTION HANDLER STACK --------------------- 0xb5eb71dc TRY-EXCEPT {0xa893a19c} 0xb5eb72bc LOCK mutex = 0xb436e0e4 0xb5eb731c LOCK mutex = 0xb6ebbc44 ---------------------------------------------------------------- [Switching to Thread -1242858592 (LWP 8289)] Breakpoint 2, 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 272 ; PROCEDURE InnerRuntimeFailureDialog ( ) (m3gdb) bt #0 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 #1 0x08126c89 in RuntimeFailureDialog () at AssertDevel.m3:314 #2 0xb72e596f in InvokeExitors () at RTProcess.m3:40 #3 0xb72e59e3 in Crash (msg=NIL) at RTProcess.m3:61 #4 0xb72e3648 in EndError (crash=TRUE) at RTError.m3:115 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 #6 0xb72e3a46 in Crash (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE, rte=16_b73124c0) at RTException.m3:79 #7 0xb72e3770 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:39 #8 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #9 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #10 0xb72e3810 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:47 #11 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #12 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #13 0xb72cb223 in ReportFault (module=16_b731e020, info=9732) at RTHooks.m3:110 #14 0xb72fb697 in _m3_fault (arg=9732) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 #16 0xb7df741d in DisplayDir (v=16_b436e004) at FileBrowserVBT.m3:496 #17 0xb7df4d83 in Refresh (v=16_b436e004) at FileBrowserVBT.m3:210 #18 0xb7df5413 in Watcher (cl=16_b6ebbc9c) at FileBrowserVBT.m3:254 #19 0xb72f76f5 in RunThread (me=16_08e1c518) at ThreadPThread.m3:538 #20 0xb72f7403 in ThreadBase (param=16_08e1c518) at ThreadPThread.m3:519 #21 0xb707c540 in start_thread () from /lib/i686/libpthread.so.0 #22 0xb6fef55e in clone () from /lib/i686/libc.so.6 (m3gdb) frame 5 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 40 RTError.m3: No such file or directory. in RTError.m3 (m3gdb) p msgA $1 = (*16_b7318068*) "" (m3gdb) p msgB $2 = (*16_b73126d4*) "Attempt to reference an illegal memory location." (m3gdb) p msgC $3 = (*16_b7318068*) "" (m3gdb) frame 15 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 304 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) p t $4 = (*16_b3a9bdc8*) OBJECT act = 16_08e94678; closure = NIL; result = NIL; cond = 16_b3a9bdf4; waitingOn = NIL; nextWaiter = NIL; waitCond = NIL; alerted = TRUE; completed = TRUE; joined = FALSE; id = 73; END (m3gdb) -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From ronny.forberger at elegosoft.com Sat Sep 15 12:55:24 2007 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Sat, 15 Sep 2007 10:55:24 -0000 Subject: [M3devel] is this working? In-Reply-To: References: Message-ID: <46EBBA13.7050106@elegosoft.com> Hi there, I just returned from holidays so I wasn't able to investigate the mailing lists problem at any earlier time. The messages indeed could not be processed by the HTML engine anymore, because there was some problem about the mailling list software package on our server, which I still don't understand why this happend. Nevertherless it should have returned to a working state now. Regards, Ronny j k schrieb: > I'm not seeing my mail to m3devel. One accidentally had no subject, > but that doesn't seem to the cause. > > - Jay > > ------------------------------------------------------------------------ > Invite your mail contacts to join your friends list with Windows Live > Spaces. It's easy! Try it! > -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12 D-13355 Berlin Tel. +49 30 32 29 71 34 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer Olaf Wagner; Sitz Berlin; Amtsgericht Berlin-Charlottenburg HRB 77719 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 16 04:39:09 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Sep 2007 02:39:09 -0000 Subject: [M3devel] FW: cm3/win32 micro status.. Message-ID: From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.com; m3-support at elego.de; m3-support at elegosoft.comSubject: cm3/win32 micro status..Date: Tue, 4 Sep 2007 09:08:18 +0000 fixed and /drastically/ churned hand.c problem reported by Daniel, though I went overboard in my way :) (send flames if you don't like and MAYBE I'll change my ways...)added MyHeapState to thread\win32\ThreadF.i3 to fix compilation of RTCollector.m3 fixed typo somewhere I think ThreadWin32.m3\MyHeapState to fix compileremove unimplemented MyAllocPool from thread\win32\ThreadF.i3 to fix compile Tony? Maybe you just forgot to commit the use of it?new release at ~jkrell\*.tar.bz2 on m3.elegosoft.com made with cm3\scripts\win\make-dist.cmd (have I mentioned this before? :) )mail not coming through here; I'll keep sending, covering my butt :)int64 support still MIA sorry I havebeen reading some of the relevant code, at this rate could be a week could be a year..Juno.exe starts up displays a bunch of stuff looks like it is "initializing"C:\cm3\bin>Juno.exe****** runtime error:*** <*ASSERT*> failed.*** file "..\src\winvbt\WinContext.m3", line 165***Stack trace: FP PC Procedure--------- --------- -------------------------------0x5aaf830 0xf41c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m30x5aaf8f8 0xf4fc1c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m30x5aafd54 0xf4db45 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m30x5aafdbc 0xf4843e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m30x5aafe04 0xf46d3d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m30x5aafe30 0x7e418734 0x5aafe98 0x7e418816 0x5aafef8 0x7e4189cd 0x5aaff08 0x7e4196c7 0x5aaff50 0xf4baf4 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3......... ......... ... more frames ...I have "cracked" my legitimate copy of CM3 4.1 cminstall and cm3 so cminstall doesn't prompt for license and cm3 doesn't care about license haven't automated, just poking in debugge Would like to hear about the legality here before telling people how, but, uh, really..if you can use the Windows ntsd/cdb debugger, it is quite easy.. You even have the source to cminstall. I'll probably automate applying the patch, or running an unpatched copy and patch it in memory or something. But again I'd like to know the legality, and if there is any need/interest in making a 4.1 binary distribution.Has anyone thought about versioning and .dlls with Modula-3?Like should exported names include typecodes?Or is it just that all the .dlls and .exes in the same directory shouldbe built and rebuilt together and that's it? - Get news, entertainment and everything you care about at Live.com. Check it out! _________________________________________________________________ Gear up for Halo? 3 with free downloads and an exclusive offer. It?s our way of saying thanks for using Windows Live?. http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 16 04:40:08 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Sep 2007 02:40:08 -0000 Subject: [M3devel] FW: hand.c In-Reply-To: <995081.11151.qm@web27115.mail.ukl.yahoo.com> References: <995081.11151.qm@web27115.mail.ukl.yahoo.com> Message-ID: I have since made some more of the changes. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: hand.cDate: Mon, 3 Sep 2007 23:15:04 +0000 I'm not seeing commit mail.Maybe my fault with the hotmail? I churned it relatively a lot. It's a small file.It compiles with older Microsoft C compilers -- optionally using __int64 instead of long long. (Visual C+ 8.0 worked as it was.) I would have factored out the LL suffixes, but, really, the vast majoriy, if not all, of the L and LL suffixes were unnecessary, right? I removed most of them.It is valid C++ now -- optional prototypes.There was a race condition in initialization, fixed.gcc -Wall complained about a safe signed/unsigned compare, fixed. Not changed: all these longs should be unsigned long, right? Or at least the bits, if not the input bit indices? Negative bit indices should be either rejected or converted to 0, and then treated as unsigned from there, right? _lowbits and _highbits should be extern const ? only on x86, right? I'm still checking if they are referenced for all targets or only x86 HighBits and LowBits should be, like..ok switched to #if LONG_MAX == 2147483647 extern const .. hard coded 32 bit values ... #elif LONG_MAX == 9223372036854775807 extern const .. hard coded 64 bit values ... #else either compute them like currently or #error #endif right? And if it is 32 bits, share the values of HighBits with _highbits, LowBits with _lowbits?They aren't /quite/ the same, but almost. _lowbits and _highbits have one extra value, the zeros at the ends I think it was. - Jay Get news, entertainment and everything you care about at Live.com. Check it out! _________________________________________________________________ Kick back and relax with hot games and cool activities at the Messenger Caf?. http://www.cafemessenger.com?ocid=TXT_TAGLM_SeptWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Sep 18 23:29:18 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 18 Sep 2007 23:29:18 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler Message-ID: <291833.75281.qm@web27114.mail.ukl.yahoo.com> Hi all: Im getting this runtiem error because the symbol missing version stamps -> compiling RTAllocStats.m3 "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime symbol !! (R THooks.AllocateTracedRef) AllocateTracedRef is not defined in the m3core version of this Dll (I guess the change is more new than the bootstrap compiler). How can avoid this issue? Thanks in advance C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd INSTALLROOT=C:\cm3 LIB=%INSTALLROOT%\LIB;%LIB% CM3ROOT=C:\\cm3-cvs\\cm3 call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override -DROOT=C:\\cm3-c vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner m3tools m3cgcat m3c ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph parseparams realgeo metry set slisp sortedtableextras table-list tempfiles tcp tapi === package C:\cm3-cvs\cm3\m3-win\import-libs === +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ --- building in NT386 --- unable to read ..\src\m3overrides, options "-override" and "-x" ignored. === package C:\cm3-cvs\cm3\m3-libs\m3core === +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ --- building in NT386 --- missing version stamps -> compiling RTAllocStats.m3 "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime symbol !! (R THooks.AllocateTracedRef) *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 ......... ......... ... more frames ... *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 failed with 0 *** error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override -DROOT=C :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner m3tools m3c gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp tapi failed C:\cm3-cvs\cm3\scripts\win> --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 19 00:25:14 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Sep 2007 18:25:14 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <291833.75281.qm@web27114.mail.ukl.yahoo.com> References: <291833.75281.qm@web27114.mail.ukl.yahoo.com> Message-ID: You need to recompile m3core before compiling with the new compiler. On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > Im getting this runtiem error because the symbol > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > AllocateTracedRef is not defined in the m3core version of this Dll > (I guess the change is more new than the bootstrap compiler). How > can avoid this issue? > > Thanks in advance > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > INSTALLROOT=C:\cm3 > LIB=%INSTALLROOT%\LIB;%LIB% > CM3ROOT=C:\\cm3-cvs\\cm3 > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > DROOT=C:\\cm3-c > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > m3tools m3cgcat m3c > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > parseparams realgeo > metry set slisp sortedtableextras table-list tempfiles tcp tapi > === package C:\cm3-cvs\cm3\m3-win\import-libs === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > unable to read ..\src\m3overrides, options "-override" and "-x" > ignored. > === package C:\cm3-cvs\cm3\m3-libs\m3core === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > failed with 0 *** > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > override -DROOT=C > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > m3scanner m3tools m3c > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > digraph parseparams > realgeometry set slisp sortedtableextras table-list tempfiles tcp > tapi failed > > C:\cm3-cvs\cm3\scripts\win> > > > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . From dabenavidesd at yahoo.es Wed Sep 19 00:30:16 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 19 Sep 2007 00:30:16 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: Message-ID: <248580.34013.qm@web27103.mail.ukl.yahoo.com> Hi: Thanks for your answer, I have done that and also I get the same runtime error in the same source file: C:\cm3-cvs\cm3\m3-libs\m3core>CM3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Csetjmp.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapDep.i3 new source -> compiling RTHeapRep.i3 new source -> compiling ThreadF.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime symbol !! (R THooks.AllocateTracedRef) *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 ......... ......... ... more frames ... C:\cm3-cvs\cm3\m3-libs\m3core> >You need to recompile m3core before compiling with the new compiler. >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > Im getting this runtiem error because the symbol > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > AllocateTracedRef is not defined in the m3core version of this Dll > (I guess the change is more new than the bootstrap compiler). How > can avoid this issue? > > Thanks in advance > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > INSTALLROOT=C:\cm3 > LIB=%INSTALLROOT%\LIB;%LIB% > CM3ROOT=C:\\cm3-cvs\\cm3 > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > DROOT=C:\\cm3-c > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > m3tools m3cgcat m3c > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > parseparams realgeo > metry set slisp sortedtableextras table-list tempfiles tcp tapi > === package C:\cm3-cvs\cm3\m3-win\import-libs === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > unable to read ..\src\m3overrides, options "-override" and "-x" > ignored. > === package C:\cm3-cvs\cm3\m3-libs\m3core === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > failed with 0 *** > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > override -DROOT=C > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > m3scanner m3tools m3c > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > digraph parseparams > realgeometry set slisp sortedtableextras table-list tempfiles tcp > tapi failed > > C:\cm3-cvs\cm3\scripts\win> > > > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 19 00:35:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Sep 2007 18:35:08 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <248580.34013.qm@web27103.mail.ukl.yahoo.com> References: <248580.34013.qm@web27103.mail.ukl.yahoo.com> Message-ID: You need to compile the new m3core with the old compiler so that the symbol is available to you when you compile using the new compiler. This is a classical bootstrapping problem. On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your answer, I have done that and also I get the same > runtime error > in the same source file: > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > new source -> compiling Compiler.m3 > new source -> compiling RTAllocator.i3 > new source -> compiling RTType.i3 > new source -> compiling Csetjmp.i3 > new source -> compiling BasicCtypes.i3 > new source -> compiling Ctypes.i3 > new source -> compiling RTMachine.i3 > new source -> compiling RTHeapDep.i3 > new source -> compiling RTHeapRep.i3 > new source -> compiling ThreadF.i3 > new source -> compiling RTOS.i3 > new source -> compiling RTMisc.i3 > new source -> compiling RTHeap.i3 > new source -> compiling Cstdlib.i3 > new source -> compiling Cstddef.i3 > new source -> compiling RTAllocCnts.i3 > new source -> compiling RTAllocator.m3 > new source -> compiling RTAllocStats.i3 > new source -> compiling Convert.i3 > new source -> compiling TextClass.i3 > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > > C:\cm3-cvs\cm3\m3-libs\m3core> > >You need to recompile m3core before compiling with the new compiler. > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > > > Hi all: > > Im getting this runtiem error because the symbol > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > AllocateTracedRef is not defined in the m3core version of this Dll > > (I guess the change is more new than the bootstrap compiler). How > > can avoid this issue? > > > > Thanks in advance > > > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > > INSTALLROOT=C:\cm3 > > LIB=%INSTALLROOT%\LIB;%LIB% > > CM3ROOT=C:\\cm3-cvs\\cm3 > > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > > DROOT=C:\\cm3-c > > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > > m3tools m3cgcat m3c > > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > > parseparams realgeo > > metry set slisp sortedtableextras table-list tempfiles tcp tapi > > === package C:\cm3-cvs\cm3\m3-win\import-libs === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > unable to read ..\src\m3overrides, options "-override" and "-x" > > ignored. > > === package C:\cm3-cvs\cm3\m3-libs\m3core === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > > > *** > > *** runtime error: > > *** Attempt to reference an illegal memory location. > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > *** > > > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > \RTSignal.m3 > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > ..\src\stmts\AssignStmt.m3 > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > ......... ......... ... more frames ... > > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > > failed with 0 *** > > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > > override -DROOT=C > > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > > m3scanner m3tools m3c > > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > > digraph parseparams > > realgeometry set slisp sortedtableextras table-list tempfiles tcp > > tapi failed > > > > C:\cm3-cvs\cm3\scripts\win> > > > > > > S? un Mejor Amante del Cine > > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > > > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . From dabenavidesd at yahoo.es Wed Sep 19 00:49:57 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 19 Sep 2007 00:49:57 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: Message-ID: <940950.96289.qm@web27108.mail.ukl.yahoo.com> Hi: I have compiled with the Jay produced 5.5 bootstrap compiler, and also with 5.1.3a, 5.2.6 and get the same error. Thanks >You need to compile the new m3core with the old compiler so that the >symbol is available to you when you compile using the new compiler. >This is a classical bootstrapping problem. >On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your answer, I have done that and also I get the same > runtime error > in the same source file: > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > new source -> compiling Compiler.m3 > new source -> compiling RTAllocator.i3 > new source -> compiling RTType.i3 > new source -> compiling Csetjmp.i3 > new source -> compiling BasicCtypes.i3 > new source -> compiling Ctypes.i3 > new source -> compiling RTMachine.i3 > new source -> compiling RTHeapDep.i3 > new source -> compiling RTHeapRep.i3 > new source -> compiling ThreadF.i3 > new source -> compiling RTOS.i3 > new source -> compiling RTMisc.i3 > new source -> compiling RTHeap.i3 > new source -> compiling Cstdlib.i3 > new source -> compiling Cstddef.i3 > new source -> compiling RTAllocCnts.i3 > new source -> compiling RTAllocator.m3 > new source -> compiling RTAllocStats.i3 > new source -> compiling Convert.i3 > new source -> compiling TextClass.i3 > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > > C:\cm3-cvs\cm3\m3-libs\m3core> > >You need to recompile m3core before compiling with the new compiler. > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > > > Hi all: > > Im getting this runtiem error because the symbol > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > AllocateTracedRef is not defined in the m3core version of this Dll > > (I guess the change is more new than the bootstrap compiler). How > > can avoid this issue? > > > > Thanks in advance > > > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > > INSTALLROOT=C:\cm3 > > LIB=%INSTALLROOT%\LIB;%LIB% > > CM3ROOT=C:\\cm3-cvs\\cm3 > > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > > DROOT=C:\\cm3-c > > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > > m3tools m3cgcat m3c > > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > > parseparams realgeo > > metry set slisp sortedtableextras table-list tempfiles tcp tapi > > === package C:\cm3-cvs\cm3\m3-win\import-libs === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > unable to read ..\src\m3overrides, options "-override" and "-x" > > ignored. > > === package C:\cm3-cvs\cm3\m3-libs\m3core === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > > > *** > > *** runtime error: > > *** Attempt to reference an illegal memory location. > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > *** > > > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > \RTSignal.m3 > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > ..\src\stmts\AssignStmt.m3 > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > ......... ......... ... more frames ... > > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > > failed with 0 *** > > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > > override -DROOT=C > > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > > m3scanner m3tools m3c > > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > > digraph parseparams > > realgeometry set slisp sortedtableextras table-list tempfiles tcp > > tapi failed > > > > C:\cm3-cvs\cm3\scripts\win> --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 19 02:41:09 2007 From: jay.krell at cornell.edu (Jay) Date: Wed, 19 Sep 2007 00:41:09 +0000 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <940950.96289.qm@web27108.mail.ukl.yahoo.com> References: <940950.96289.qm@web27108.mail.ukl.yahoo.com> Message-ID: Daniel, can you try just going back to 5.2.6 and running scripts\win\update? You should be able to build the current source the last "official" Win32 binaries, as long as you build in the correct order and all, which the update.cmd does. You know, there's a certain mentality around bootstrapping and keeping the connection back to the previous version, that I upheld. As long as you are careful, you can go from old binaries to new binaries, you don't have to get the new binaries magically somewhere, though you do need the old binaries magically from somewhere. :) Perhaps there's a regression. I can check "later". - Jay Date: Wed, 19 Sep 2007 00:49:57 +0200From: dabenavidesd at yahoo.esTo: hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compilerHi:I have compiled with the Jay produced 5.5 bootstrap compiler, and also with 5.1.3a, 5.2.6 and get the same error.Thanks>You need to compile the new m3core with the old compiler so that the >symbol is available to you when you compile using the new compiler. >This is a classical bootstrapping problem.>On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote:> Hi:> Thanks for your answer, I have done that and also I get the same > runtime error> in the same source file:>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3> --- building in NT386 --->> ignoring ..\src\m3overrides>> new source -> compiling RTHooks.i3> new source -> compiling RT0.i3> new source -> compiling RuntimeError.i3> new source -> compiling Word.i3> new source -> compiling RTException.i3> new source -> compiling RTHooks.m3> new source -> compiling RT0.m3> new source -> compiling Compiler.i3> new source -> compiling RuntimeError.m3> new source -> compiling Compiler.m3> new source -> compiling RTAllocator.i3> new source -> compiling RTType.i3> new source -> compiling Csetjmp.i3> new source -> compiling BasicCtypes.i3> new source -> compiling Ctypes.i3> new source -> compiling RTMachine.i3> new source -> compiling RTHeapDep.i3> new source -> compiling RTHeapRep.i3> new source -> compiling ThreadF.i3> new source -> compiling RTOS.i3> new source -> compiling RTMisc.i3> new source -> compiling RTHeap.i3> new source -> compiling Cstdlib.i3> new source -> compiling Cstddef.i3> new source -> compiling RTAllocCnts.i3> new source -> compiling RTAllocator.m3> new source -> compiling RTAllocStats.i3> new source -> compiling Convert.i3> new source -> compiling TextClass.i3> new source -> compiling Text.i3> new source -> compiling RTProcedureSRC.i3> new source -> compiling Fingerprint.i3> new source -> compiling RTProcedure.i3> new source -> compiling RTStack.i3> new source -> compiling RTAllocStats.m3> "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R> THooks.AllocateTracedRef)>>> ***> *** runtime error:> *** Attempt to reference an illegal memory location.> *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3> ***>> Stack trace:> FP PC Procedure> --------- --------- -------------------------------> 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3> 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3> 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3> 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3> 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3> 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3> 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3> 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3> 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3> 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3> ......... ......... ... more frames ...>> C:\cm3-cvs\cm3\m3-libs\m3core>> >You need to recompile m3core before compiling with the new compiler.>> >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote:>> > Hi all:> > Im getting this runtiem error because the symbol> >> > missing version stamps -> compiling RTAllocStats.m3> > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime> > symbol !! (R> > THooks.AllocateTracedRef)> >> > AllocateTracedRef is not defined in the m3core version of this Dll> > (I guess the change is more new than the bootstrap compiler). How> > can avoid this issue?> >> > Thanks in advance> >> > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd> > INSTALLROOT=C:\cm3> > LIB=%INSTALLROOT%\LIB;%LIB%> > CM3ROOT=C:\\cm3-cvs\\cm3> > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override -> > DROOT=C:\\cm3-c> > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner> > m3tools m3cgcat m3c> > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph> > parseparams realgeo> > metry set slisp sortedtableextras table-list tempfiles tcp tapi> > === package C:\cm3-cvs\cm3\m3-win\import-libs ===> > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++> > --- building in NT386 ---> >> > unable to read ..\src\m3overrides, options "-override" and "-x"> > ignored.> > === package C:\cm3-cvs\cm3\m3-libs\m3core ===> > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++> > --- building in NT386 ---> >> > missing version stamps -> compiling RTAllocStats.m3> > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime> > symbol !! (R> > THooks.AllocateTracedRef)> >> >> > ***> > *** runtime error:> > *** Attempt to reference an illegal memory location.> > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3> > ***> >> > Stack trace:> > FP PC Procedure> > --------- --------- -------------------------------> > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386> > \RTSignal.m3> > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3> > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3> > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3> > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3> > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3> > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3> > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3> > 0x12f63c 0x544d7f PrepForEmit + 0x81 in> ..\src\stmts\AssignStmt.m3> > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3> > ......... ......... ... more frames ...> > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3> > failed with 0 ***> > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -> > override -DROOT=C> > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake> > m3scanner m3tools m3c> > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector> > digraph parseparams> > realgeometry set slisp sortedtableextras table-list tempfiles tcp> > tapi failed> >> > C:\cm3-cvs\cm3\scripts\win> S? un Mejor Amante del Cine?Quieres saber c?mo? ?Deja que otras personas te ayuden! . _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 19 16:55:24 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 19 Sep 2007 10:55:24 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: References: <940950.96289.qm@web27108.mail.ukl.yahoo.com> Message-ID: <889F2EFF-2F38-4FB8-BBF2-08104548E060@cs.purdue.edu> It strikes me that you may need to sequence as follows to avoid running into having a compiler that does not handle LONGINT. Using the "devel_LONGINT_start" tagged versions of m3core and libm3 from CVS, using your original compiler, build and ship in the following order: m3core (devel_LONGINT_start) libm3 (devel_LONGINT_start) m3middle m3linker m3front m3quake cm3 Now you have a new compiler linked against the old m3core. Using the new compiler (in cm3/NT386), and the CVS head versions of m3core and libm3, build and ship in the following order: m3core (CVS head) libm3 (CVS head) m3middle m3linker m3front m3quake cm3 Now you have a new compiler linked against the new m3core. Copy this new compiler to your CM3 installation bin directory. Use this new compiler to rebuild the world. On Sep 18, 2007, at 8:41 PM, Jay wrote: > Daniel, can you try just going back to 5.2.6 and running scripts\win > \update? > You should be able to build the current source the last "official" > Win32 binaries, as long as you build in the correct order and all, > which the update.cmd does. You know, there's a certain mentality > around bootstrapping and keeping the connection back to the > previous version, that I upheld. As long as you are careful, you > can go from old binaries to new binaries, you don't have to get the > new binaries magically somewhere, though you do need the old > binaries magically from somewhere. :) > > Perhaps there's a regression. I can check "later". > > - Jay > Date: Wed, 19 Sep 2007 00:49:57 +0200 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compiler > > Hi: > > I have compiled with the Jay produced 5.5 bootstrap compiler, and > also with 5.1.3a, > 5.2.6 and get the same error. > > Thanks > > >You need to compile the new m3core with the old compiler so that the > >symbol is available to you when you compile using the new compiler. > >This is a classical bootstrapping problem. > > >On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote: > > > Hi: > > Thanks for your answer, I have done that and also I get the same > > runtime error > > in the same source file: > > > > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > new source -> compiling RT0.i3 > > new source -> compiling RuntimeError.i3 > > new source -> compiling Word.i3 > > new source -> compiling RTException.i3 > > new source -> compiling RTHooks.m3 > > new source -> compiling RT0.m3 > > new source -> compiling Compiler.i3 > > new source -> compiling RuntimeError.m3 > > new source -> compiling Compiler.m3 > > new source -> compiling RTAllocator.i3 > > new source -> compiling RTType.i3 > > new source -> compiling Csetjmp.i3 > > new source -> compiling BasicCtypes.i3 > > new source -> compiling Ctypes.i3 > > new source -> compiling RTMachine.i3 > > new source -> compiling RTHeapDep.i3 > > new source -> compiling RTHeapRep.i3 > > new source -> compiling ThreadF.i3 > > new source -> compiling RTOS.i3 > > new source -> compiling RTMisc.i3 > > new source -> compiling RTHeap.i3 > > new source -> compiling Cstdlib.i3 > > new source -> compiling Cstddef.i3 > > new source -> compiling RTAllocCnts.i3 > > new source -> compiling RTAllocator.m3 > > new source -> compiling RTAllocStats.i3 > > new source -> compiling Convert.i3 > > new source -> compiling TextClass.i3 > > new source -> compiling Text.i3 > > new source -> compiling RTProcedureSRC.i3 > > new source -> compiling Fingerprint.i3 > > new source -> compiling RTProcedure.i3 > > new source -> compiling RTStack.i3 > > new source -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > > > *** > > *** runtime error: > > *** Attempt to reference an illegal memory location. > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > *** > > > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > \RTSignal.m3 > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > ......... ......... ... more frames ... > > > > C:\cm3-cvs\cm3\m3-libs\m3core> > > >You need to recompile m3core before compiling with the new > compiler. > > > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > > > > > Hi all: > > > Im getting this runtiem error because the symbol > > > > > > missing version stamps -> compiling RTAllocStats.m3 > > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined > runtime > > > symbol !! (R > > > THooks.AllocateTracedRef) > > > > > > AllocateTracedRef is not defined in the m3core version of this Dll > > > (I guess the change is more new than the bootstrap compiler). How > > > can avoid this issue? > > > > > > Thanks in advance > > > > > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > > > INSTALLROOT=C:\cm3 > > > LIB=%INSTALLROOT%\LIB;%LIB% > > > CM3ROOT=C:\\cm3-cvs\\cm3 > > > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > > > DROOT=C:\\cm3-c > > > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > > > m3tools m3cgcat m3c > > > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > > > parseparams realgeo > > > metry set slisp sortedtableextras table-list tempfiles tcp tapi > > > === package C:\cm3-cvs\cm3\m3-win\import-libs === > > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > > --- building in NT386 --- > > > > > > unable to read ..\src\m3overrides, options "-override" and "-x" > > > ignored. > > > === package C:\cm3-cvs\cm3\m3-libs\m3core === > > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > > --- building in NT386 --- > > > > > > missing version stamps -> compiling RTAllocStats.m3 > > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined > runtime > > > symbol !! (R > > > THooks.AllocateTracedRef) > > > > > > > > > *** > > > *** runtime error: > > > *** Attempt to reference an illegal memory location. > > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > > *** > > > > > > Stack trace: > > > FP PC Procedure > > > --------- --------- ------------------------------- > > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > > \RTSignal.m3 > > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > > ..\src\stmts\AssignStmt.m3 > > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > > ......... ......... ... more frames ... > > > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > > > failed with 0 *** > > > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > > > override -DROOT=C > > > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > > > m3scanner m3tools m3c > > > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > > > digraph parseparams > > > realgeometry set slisp sortedtableextras table-list tempfiles tcp > > > tapi failed > > > > > > C:\cm3-cvs\cm3\scripts\win> > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . > > Make your little one a shining star! Shine on! From dabenavidesd at yahoo.es Thu Sep 20 17:15:01 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 20 Sep 2007 17:15:01 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <889F2EFF-2F38-4FB8-BBF2-08104548E060@cs.purdue.edu> Message-ID: <894591.8437.qm@web27109.mail.ukl.yahoo.com> Hi: Thanks for your suggestions. I have tried the scripts/win/upgrade.cmd, and It does compile and then you can execute do-cm3-std.cmd. However I noticed the that script exports a m3core pkg to the repository with a m3core-d5.5 like suffix. Not sure what is this for. I will test if it can recognize the LONGINT datatype. Also I have a question about Tony's suggestion. The packages m3objfile and m3back are not ncessary on the stages you mention for NT386 target? Thanks --- Tony Hosking escribi?: > It strikes me that you may need to sequence as > follows to avoid > running into having a compiler that does not handle > LONGINT. > > Using the "devel_LONGINT_start" tagged versions of > m3core and libm3 > from CVS, > using your original compiler, build and ship in the > following order: > > m3core (devel_LONGINT_start) > libm3 (devel_LONGINT_start) > m3middle > m3linker > m3front > m3quake > cm3 > > Now you have a new compiler linked against the old > m3core. > > Using the new compiler (in cm3/NT386), and the CVS > head versions of > m3core and libm3, > build and ship in the following order: > > m3core (CVS head) > libm3 (CVS head) > m3middle > m3linker > m3front > m3quake > cm3 > > Now you have a new compiler linked against the new > m3core. > > Copy this new compiler to your CM3 installation bin > directory. > > Use this new compiler to rebuild the world. > > > On Sep 18, 2007, at 8:41 PM, Jay wrote: > > > Daniel, can you try just going back to 5.2.6 and > running scripts\win > > \update? > > You should be able to build the current source the > last "official" > > Win32 binaries, as long as you build in the > correct order and all, > > which the update.cmd does. You know, there's a > certain mentality > > around bootstrapping and keeping the connection > back to the > > previous version, that I upheld. As long as you > are careful, you > > can go from old binaries to new binaries, you > don't have to get the > > new binaries magically somewhere, though you do > need the old > > binaries magically from somewhere. :) > > > > Perhaps there's a regression. I can check "later". > > > > - Jay > > Date: Wed, 19 Sep 2007 00:49:57 +0200 > > From: dabenavidesd at yahoo.es > > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Subject: Re: [M3devel] NT386 with cm3-5.5 > bootstrap compiler > > > > Hi: > > > > I have compiled with the Jay produced 5.5 > bootstrap compiler, and > > also with 5.1.3a, > > 5.2.6 and get the same error. > > > > Thanks > > > > >You need to compile the new m3core with the old > compiler so that the > > >symbol is available to you when you compile using > the new compiler. > > >This is a classical bootstrapping problem. > > > > >On Sep 18, 2007, at 6:30 PM, Daniel Alejandro > Benavides D. wrote: > > > > > Hi: > > > Thanks for your answer, I have done that and > also I get the same > > > runtime error > > > in the same source file: > > > > > > > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > > > --- building in NT386 --- > > > > > > ignoring ..\src\m3overrides > > > > > > new source -> compiling RTHooks.i3 > > > new source -> compiling RT0.i3 > > > new source -> compiling RuntimeError.i3 > > > new source -> compiling Word.i3 > > > new source -> compiling RTException.i3 > > > new source -> compiling RTHooks.m3 > > > new source -> compiling RT0.m3 > > > new source -> compiling Compiler.i3 > > > new source -> compiling RuntimeError.m3 > > > new source -> compiling Compiler.m3 > > > new source -> compiling RTAllocator.i3 > > > new source -> compiling RTType.i3 > > > new source -> compiling Csetjmp.i3 > > > new source -> compiling BasicCtypes.i3 > > > new source -> compiling Ctypes.i3 > > > new source -> compiling RTMachine.i3 > > > new source -> compiling RTHeapDep.i3 > > > new source -> compiling RTHeapRep.i3 > > > new source -> compiling ThreadF.i3 > > > new source -> compiling RTOS.i3 > > > new source -> compiling RTMisc.i3 > > > new source -> compiling RTHeap.i3 > > > new source -> compiling Cstdlib.i3 > > > new source -> compiling Cstddef.i3 > > > new source -> compiling RTAllocCnts.i3 > > > new source -> compiling RTAllocator.m3 > > > new source -> compiling RTAllocStats.i3 > > > new source -> compiling Convert.i3 > > > new source -> compiling TextClass.i3 > > > new source -> compiling Text.i3 > > > new source -> compiling RTProcedureSRC.i3 > > > new source -> compiling Fingerprint.i3 > > > new source -> compiling RTProcedure.i3 > > > new source -> compiling RTStack.i3 > > > new source -> compiling RTAllocStats.m3 > > > "..\src\runtime\common\RTAllocStats.m3", line > 46: undefined runtime > > > symbol !! (R > > > THooks.AllocateTracedRef) > > > > > > > > > *** > > > *** runtime error: > > > *** Attempt to reference an illegal memory > location. > > > *** pc = 0x4c4a0d = StartCall + 0xf in > ..\src\values\Procedure.m3 > > > *** > > > > > > Stack trace: > > > FP PC Procedure > > > --------- --------- > ------------------------------- > > > 0x12f494 0x60b3ce SystemError + 0x66 in > ..\src\runtime\NT386 > > > \RTSignal.m3 > > > 0x12f4c4 0x4c4a0d StartCall + 0xf in > ..\src\values\Procedure.m3 > > > 0x12f524 0x51beb8 GenRecord + 0x73 in > ..\src\builtinOps\New.m3 > > > 0x12f58c 0x51b8a3 GenRef + 0x111 in > ..\src\builtinOps\New.m3 > > > 0x12f5c8 0x51b70f Gen + 0x12d in > ..\src\builtinOps\New.m3 > > > 0x12f5e0 0x51b4a3 Prep + 0x15 in > ..\src\builtinOps\New.m3 > > > 0x12f600 0x550f08 Prep + 0x75 in > ..\src\exprs\CallExpr.m3 > > > 0x12f61c 0x54312d Prep + 0x54 in > ..\src\exprs\Expr.m3 > > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > ..\src\stmts\AssignStmt.m3 > > > 0x12f66c 0x54453b Compile + 0xd6 in > ..\src\stmts\AssignStmt.m3 > > > ......... ......... ... more frames ... > > > > > > C:\cm3-cvs\cm3\m3-libs\m3core> > > > >You need to recompile m3core before compiling > with the new > > compiler. > > > > > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro > Benavides D. wrote: > > > > > > > Hi all: > > > > Im getting this runtiem error because the > symbol > > > > > > > > missing version stamps -> compiling > RTAllocStats.m3 > > > > "..\src\runtime\common\RTAllocStats.m3", line > 46: undefined > > runtime > > > > symbol !! (R > > > > THooks.AllocateTracedRef) > > > > > > > > AllocateTracedRef is not defined in the m3core > version === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Thu Sep 20 18:15:26 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Sep 2007 12:15:26 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <894591.8437.qm@web27109.mail.ukl.yahoo.com> References: <894591.8437.qm@web27109.mail.ukl.yahoo.com> Message-ID: On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your suggestions. I have tried the > scripts/win/upgrade.cmd, and It does compile and then > you can execute do-cm3-std.cmd. > > However I noticed the that script exports a m3core pkg > to the repository with a m3core-d5.5 like suffix. Not > sure what is this for. > > I will test if it can recognize the LONGINT datatype. > > Also I have a question about Tony's suggestion. The > packages m3objfile and m3back are not ncessary on the > stages you mention for NT386 target? Oh, yes, of course they are. Sorry, I forgot about that for NT386. > > Thanks > > --- Tony Hosking escribi?: > >> It strikes me that you may need to sequence as >> follows to avoid >> running into having a compiler that does not handle >> LONGINT. >> >> Using the "devel_LONGINT_start" tagged versions of >> m3core and libm3 >> from CVS, >> using your original compiler, build and ship in the >> following order: >> >> m3core (devel_LONGINT_start) >> libm3 (devel_LONGINT_start) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the old >> m3core. >> >> Using the new compiler (in cm3/NT386), and the CVS >> head versions of >> m3core and libm3, >> build and ship in the following order: >> >> m3core (CVS head) >> libm3 (CVS head) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the new >> m3core. >> >> Copy this new compiler to your CM3 installation bin >> directory. >> >> Use this new compiler to rebuild the world. >> >> >> On Sep 18, 2007, at 8:41 PM, Jay wrote: >> >>> Daniel, can you try just going back to 5.2.6 and >> running scripts\win >>> \update? >>> You should be able to build the current source the >> last "official" >>> Win32 binaries, as long as you build in the >> correct order and all, >>> which the update.cmd does. You know, there's a >> certain mentality >>> around bootstrapping and keeping the connection >> back to the >>> previous version, that I upheld. As long as you >> are careful, you >>> can go from old binaries to new binaries, you >> don't have to get the >>> new binaries magically somewhere, though you do >> need the old >>> binaries magically from somewhere. :) >>> >>> Perhaps there's a regression. I can check "later". >>> >>> - Jay >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 >>> From: dabenavidesd at yahoo.es >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> >>> Hi: >>> >>> I have compiled with the Jay produced 5.5 >> bootstrap compiler, and >>> also with 5.1.3a, >>> 5.2.6 and get the same error. >>> >>> Thanks >>> >>>> You need to compile the new m3core with the old >> compiler so that the >>>> symbol is available to you when you compile using >> the new compiler. >>>> This is a classical bootstrapping problem. >>> >>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro >> Benavides D. wrote: >>> >>>> Hi: >>>> Thanks for your answer, I have done that and >> also I get the same >>>> runtime error >>>> in the same source file: >>>> >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3 >>>> --- building in NT386 --- >>>> >>>> ignoring ..\src\m3overrides >>>> >>>> new source -> compiling RTHooks.i3 >>>> new source -> compiling RT0.i3 >>>> new source -> compiling RuntimeError.i3 >>>> new source -> compiling Word.i3 >>>> new source -> compiling RTException.i3 >>>> new source -> compiling RTHooks.m3 >>>> new source -> compiling RT0.m3 >>>> new source -> compiling Compiler.i3 >>>> new source -> compiling RuntimeError.m3 >>>> new source -> compiling Compiler.m3 >>>> new source -> compiling RTAllocator.i3 >>>> new source -> compiling RTType.i3 >>>> new source -> compiling Csetjmp.i3 >>>> new source -> compiling BasicCtypes.i3 >>>> new source -> compiling Ctypes.i3 >>>> new source -> compiling RTMachine.i3 >>>> new source -> compiling RTHeapDep.i3 >>>> new source -> compiling RTHeapRep.i3 >>>> new source -> compiling ThreadF.i3 >>>> new source -> compiling RTOS.i3 >>>> new source -> compiling RTMisc.i3 >>>> new source -> compiling RTHeap.i3 >>>> new source -> compiling Cstdlib.i3 >>>> new source -> compiling Cstddef.i3 >>>> new source -> compiling RTAllocCnts.i3 >>>> new source -> compiling RTAllocator.m3 >>>> new source -> compiling RTAllocStats.i3 >>>> new source -> compiling Convert.i3 >>>> new source -> compiling TextClass.i3 >>>> new source -> compiling Text.i3 >>>> new source -> compiling RTProcedureSRC.i3 >>>> new source -> compiling Fingerprint.i3 >>>> new source -> compiling RTProcedure.i3 >>>> new source -> compiling RTStack.i3 >>>> new source -> compiling RTAllocStats.m3 >>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined runtime >>>> symbol !! (R >>>> THooks.AllocateTracedRef) >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Attempt to reference an illegal memory >> location. >>>> *** pc = 0x4c4a0d = StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- >> ------------------------------- >>>> 0x12f494 0x60b3ce SystemError + 0x66 in >> ..\src\runtime\NT386 >>>> \RTSignal.m3 >>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> 0x12f524 0x51beb8 GenRecord + 0x73 in >> ..\src\builtinOps\New.m3 >>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in >> ..\src\builtinOps\New.m3 >>>> 0x12f5c8 0x51b70f Gen + 0x12d in >> ..\src\builtinOps\New.m3 >>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in >> ..\src\builtinOps\New.m3 >>>> 0x12f600 0x550f08 Prep + 0x75 in >> ..\src\exprs\CallExpr.m3 >>>> 0x12f61c 0x54312d Prep + 0x54 in >> ..\src\exprs\Expr.m3 >>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in >> ..\src\stmts\AssignStmt.m3 >>>> 0x12f66c 0x54453b Compile + 0xd6 in >> ..\src\stmts\AssignStmt.m3 >>>> ......... ......... ... more frames ... >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core> >>>>> You need to recompile m3core before compiling >> with the new >>> compiler. >>>> >>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro >> Benavides D. wrote: >>>> >>>>> Hi all: >>>>> Im getting this runtiem error because the >> symbol >>>>> >>>>> missing version stamps -> compiling >> RTAllocStats.m3 >>>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined >>> runtime >>>>> symbol !! (R >>>>> THooks.AllocateTracedRef) >>>>> >>>>> AllocateTracedRef is not defined in the m3core >> version > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Thu Sep 20 22:53:35 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 20 Sep 2007 22:53:35 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: Message-ID: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Hi: The script upgarde.cmd produced compiler does recognize the LONGINT as a reserved word. I can get this error when compiling the m2libs of m2tom3 compiler: new source -> compiling SYSTEM.i3 "..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT) 1 error encountered Thanks again >On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your suggestions. I have tried the > scripts/win/upgrade.cmd, and It does compile and then > you can execute do-cm3-std.cmd. > > However I noticed the that script exports a m3core pkg > to the repository with a m3core-d5.5 like suffix. Not > sure what is this for. > > I will test if it can recognize the LONGINT datatype. > > Also I have a question about Tony's suggestion. The > packages m3objfile and m3back are not ncessary on the > stages you mention for NT386 target? >Oh, yes, of course they are. Sorry, I forgot about that for NT386. > > Thanks > > --- Tony Hosking escribi?: > >> It strikes me that you may need to sequence as >> follows to avoid >> running into having a compiler that does not handle >> LONGINT. >> >> Using the "devel_LONGINT_start" tagged versions of >> m3core and libm3 >> from CVS, >> using your original compiler, build and ship in the >> following order: >> >> m3core (devel_LONGINT_start) >> libm3 (devel_LONGINT_start) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the old >> m3core. >> >> Using the new compiler (in cm3/NT386), and the CVS >> head versions of >> m3core and libm3, >> build and ship in the following order: >> >> m3core (CVS head) >> libm3 (CVS head) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the new >> m3core. >> >> Copy this new compiler to your CM3 installation bin >> directory. >> >> Use this new compiler to rebuild the world. >> >> >> On Sep 18, 2007, at 8:41 PM, Jay wrote: >> >>> Daniel, can you try just going back to 5.2.6 and >> running scripts\win >>> \update? >>> You should be able to build the current source the >> last "official" >>> Win32 binaries, as long as you build in the >> correct order and all, >>> which the update.cmd does. You know, there's a >> certain mentality >>> around bootstrapping and keeping the connection >> back to the >>> previous version, that I upheld. As long as you >> are careful, you >>> can go from old binaries to new binaries, you >> don't have to get the >>> new binaries magically somewhere, though you do >> need the old >>> binaries magically from somewhere. :) >>> >>> Perhaps there's a regression. I can check "later". >>> >>> - Jay >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 >>> From: dabenavidesd at yahoo.es >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> >>> Hi: >>> >>> I have compiled with the Jay produced 5.5 >> bootstrap compiler, and >>> also with 5.1.3a, >>> 5.2.6 and get the same error. >>> >>> Thanks >>> >>>> You need to compile the new m3core with the old >> compiler so that the >>>> symbol is available to you when you compile using >> the new compiler. >>>> This is a classical bootstrapping problem. >>> >>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro >> Benavides D. wrote: >>> >>>> Hi: >>>> Thanks for your answer, I have done that and >> also I get the same >>>> runtime error >>>> in the same source file: >>>> >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3 >>>> --- building in NT386 --- >>>> >>>> ignoring ..\src\m3overrides >>>> >>>> new source -> compiling RTHooks.i3 >>>> new source -> compiling RT0.i3 >>>> new source -> compiling RuntimeError.i3 >>>> new source -> compiling Word.i3 >>>> new source -> compiling RTException.i3 >>>> new source -> compiling RTHooks.m3 >>>> new source -> compiling RT0.m3 >>>> new source -> compiling Compiler.i3 >>>> new source -> compiling RuntimeError.m3 >>>> new source -> compiling Compiler.m3 >>>> new source -> compiling RTAllocator.i3 >>>> new source -> compiling RTType.i3 >>>> new source -> compiling Csetjmp.i3 >>>> new source -> compiling BasicCtypes.i3 >>>> new source -> compiling Ctypes.i3 >>>> new source -> compiling RTMachine.i3 >>>> new source -> compiling RTHeapDep.i3 >>>> new source -> compiling RTHeapRep.i3 >>>> new source -> compiling ThreadF.i3 >>>> new source -> compiling RTOS.i3 >>>> new source -> compiling RTMisc.i3 >>>> new source -> compiling RTHeap.i3 >>>> new source -> compiling Cstdlib.i3 >>>> new source -> compiling Cstddef.i3 >>>> new source -> compiling RTAllocCnts.i3 >>>> new source -> compiling RTAllocator.m3 >>>> new source -> compiling RTAllocStats.i3 >>>> new source -> compiling Convert.i3 >>>> new source -> compiling TextClass.i3 >>>> new source -> compiling Text.i3 >>>> new source -> compiling RTProcedureSRC.i3 >>>> new source -> compiling Fingerprint.i3 >>>> new source -> compiling RTProcedure.i3 >>>> new source -> compiling RTStack.i3 >>>> new source -> compiling RTAllocStats.m3 >>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined runtime >>>> symbol !! (R >>>> THooks.AllocateTracedRef) >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Attempt to reference an illegal memory >> location. >>>> *** pc = 0x4c4a0d = StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- >> ------------------------------- >>>> 0x12f494 0x60b3ce SystemError + 0x66 in >> ..\src\runtime\NT386 >>>> \RTSignal.m3 >>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> 0x12f524 0x51beb8 GenRecord + 0x73 in >> ..\src\builtinOps\New.m3 >>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in >> ..\src\builtinOps\New.m3 >>>> 0x12f5c8 0x51b70f Gen + 0x12d in >> ..\src\builtinOps\New.m3 >>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in >> ..\src\builtinOps\New.m3 >>>> 0x12f600 0x550f08 Prep + 0x75 in >> ..\src\exprs\CallExpr.m3 >>>> 0x12f61c 0x54312d Prep + 0x54 in >> ..\src\exprs\Expr.m3 >>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in >> ..\src\stmts\AssignStmt.m3 >>>> 0x12f66c 0x54453b Compile + 0xd6 in >> ..\src\stmts\AssignStmt.m3 >>>> ......... ......... ... more frames ... >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core> >>>>> You need to recompile m3core before compiling >> with the new >>> compiler. >>>> >>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro >> Benavides D. wrote: >>>> >>>>> Hi all: >>>>> Im getting this runtiem error because the >> symbol >>>>> >>>>> missing version stamps -> compiling >> RTAllocStats.m3 >>>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined >>> runtime >>>>> symbol !! (R >>>>> THooks.AllocateTracedRef) >>>>> >>>>> AllocateTracedRef is not defined in the m3core >> version --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 21 02:49:21 2007 From: jay.krell at cornell.edu (Jay) Date: Fri, 21 Sep 2007 00:49:21 +0000 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <9243.42411.qm@web27110.mail.ukl.yahoo.com> References: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Message-ID: The "-d5.5" thing is a backup of the package repository. Indeed I find it annoying sometimes, but I mimiced upgrade.sh and I'd have to think it all through again before deleting/changing how it works. I think it makes it easier to back out of a broken change. If you end up with non-working stuff, you copy pkg-d5.5 back on top of pkg. I really strongly suspect update.cmd works. I don't remember if it upgrades...oh, sorry, wrong script I think. make-dist.cmd? How about that one? Whichever one creates .tar.bz2 files. That's the one I meant. Oops, sorry sorry sorry. :\ - Jay Date: Thu, 20 Sep 2007 22:53:35 +0200From: dabenavidesd at yahoo.esTo: hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compilerHi:The script upgarde.cmd produced compiler does recognize the LONGINT as a reserved word.I can get this error when compiling the m2libs of m2tom3 compiler:new source -> compiling SYSTEM.i3"..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT)1 error encounteredThanks again>On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote:> Hi:> Thanks for your suggestions. I have tried the> scripts/win/upgrade.cmd, and It does compile and then> you can execute do-cm3-std.cmd.>> However I noticed the that script exports a m3core pkg> to the repository with a m3core-d5.5 like suffix. Not> sure what is this for.>> I will test if it can recognize the LONGINT datatype.>> Also I have a question about Tony's suggestion. The> packages m3objfile and m3back are not ncessary on the> stages you mention for NT386 target?>Oh, yes, of course they are. Sorry, I forgot about that for NT386.>> Thanks>> --- Tony Hosking escribi?:>>> It strikes me that you may need to sequence as>> follows to avoid>> running into having a compiler that does not handle>> LONGINT.>>>> Using the "devel_LONGINT_start" tagged versions of>> m3core and libm3>> from CVS,>> using your original compiler, build and ship in the>> following order:>>>> m3core (devel_LONGINT_start)>> libm3 (devel_LONGINT_start)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the old>> m3core.>>>> Using the new compiler (in cm3/NT386), and the CVS>> head versions of>> m3core and libm3,>> build and ship in the following order:>>>> m3core (CVS head)>> libm3 (CVS head)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the new>> m3core.>>>> Copy this new compiler to your CM3 installation bin>> directory.>>>> Use this new compiler to rebuild the world.>>>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote:>>>>> Daniel, can you try just going back to 5.2.6 and>> running scripts\win>>> \update?>>> You should be able to build the current source the>> last "official">>> Win32 binaries, as long as you build in the>> correct order and all,>>> which the update.cmd does. You know, there's a>> certain mentality>>> around bootstrapping and keeping the connection>> back to the>>> previous version, that I upheld. As long as you>> are careful, you>>> can go from old binaries to new binaries, you>> don't have to get the>>> new binaries magically somewhere, though you do>> need the old>>> binaries magically from somewhere. :)>>>>>> Perhaps there's a regression. I can check "later".>>>>>> - Jay>>> Date: Wed, 19 Sep 2007 00:49:57 +0200>>> From: dabenavidesd at yahoo.es>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com>>> Subject: Re: [M3devel] NT386 with cm3-5.5>> bootstrap compiler>>>>>> Hi:>>>>>> I have compiled with the Jay produced 5.5>> bootstrap compiler, and>>> also with 5.1.3a,>>> 5.2.6 and get the same error.>>>>>> Thanks>>>>>>> You need to compile the new m3core with the old>> compiler so that the>>>> symbol is available to you when you compile using>> the new compiler.>>>> This is a classical bootstrapping problem.>>>>>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>> Hi:>>>> Thanks for your answer, I have done that and>> also I get the same>>>> runtime error>>>> in the same source file:>>>>>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3>>>> --- building in NT386 --->>>>>>>> ignoring ..\src\m3overrides>>>>>>>> new source -> compiling RTHooks.i3>>>> new source -> compiling RT0.i3>>>> new source -> compiling RuntimeError.i3>>>> new source -> compiling Word.i3>>>> new source -> compiling RTException.i3>>>> new source -> compiling RTHooks.m3>>>> new source -> compiling RT0.m3>>>> new source -> compiling Compiler.i3>>>> new source -> compiling RuntimeError.m3>>>> new source -> compiling Compiler.m3>>>> new source -> compiling RTAllocator.i3>>>> new source -> compiling RTType.i3>>>> new source -> compiling Csetjmp.i3>>>> new source -> compiling BasicCtypes.i3>>>> new source -> compiling Ctypes.i3>>>> new source -> compiling RTMachine.i3>>>> new source -> compiling RTHeapDep.i3>>>> new source -> compiling RTHeapRep.i3>>>> new source -> compiling ThreadF.i3>>>> new source -> compiling RTOS.i3>>>> new source -> compiling RTMisc.i3>>>> new source -> compiling RTHeap.i3>>>> new source -> compiling Cstdlib.i3>>>> new source -> compiling Cstddef.i3>>>> new source -> compiling RTAllocCnts.i3>>>> new source -> compiling RTAllocator.m3>>>> new source -> compiling RTAllocStats.i3>>>> new source -> compiling Convert.i3>>>> new source -> compiling TextClass.i3>>>> new source -> compiling Text.i3>>>> new source -> compiling RTProcedureSRC.i3>>>> new source -> compiling Fingerprint.i3>>>> new source -> compiling RTProcedure.i3>>>> new source -> compiling RTStack.i3>>>> new source -> compiling RTAllocStats.m3>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined runtime>>>> symbol !! (R>>>> THooks.AllocateTracedRef)>>>>>>>>>>>> ***>>>> *** runtime error:>>>> *** Attempt to reference an illegal memory>> location.>>>> *** pc = 0x4c4a0d = StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> ***>>>>>>>> Stack trace:>>>> FP PC Procedure>>>> --------- --------->> ------------------------------->>>> 0x12f494 0x60b3ce SystemError + 0x66 in>> ..\src\runtime\NT386>>>> \RTSignal.m3>>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> 0x12f524 0x51beb8 GenRecord + 0x73 in>> ..\src\builtinOps\New.m3>>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in>> ..\src\builtinOps\New.m3>>>> 0x12f5c8 0x51b70f Gen + 0x12d in>> ..\src\builtinOps\New.m3>>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in>> ..\src\builtinOps\New.m3>>>> 0x12f600 0x550f08 Prep + 0x75 in>> ..\src\exprs\CallExpr.m3>>>> 0x12f61c 0x54312d Prep + 0x54 in>> ..\src\exprs\Expr.m3>>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in>> ..\src\stmts\AssignStmt.m3>>>> 0x12f66c 0x54453b Compile + 0xd6 in>> ..\src\stmts\AssignStmt.m3>>>> ......... ......... ... more frames ...>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>>>>>> You need to recompile m3core before compiling>> with the new>>> compiler.>>>>>>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>>>> Hi all:>>>>> Im getting this runtiem error because the>> symbol>>>>>>>>>> missing version stamps -> compiling>> RTAllocStats.m3>>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined>>> runtime>>>>> symbol !! (R>>>>> THooks.AllocateTracedRef)>>>>>>>>>> AllocateTracedRef is not defined in the m3core>> version S? un Mejor Amante del Cine?Quieres saber c?mo? ?Deja que otras personas te ayuden! . _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 21 02:50:51 2007 From: jay.krell at cornell.edu (Jay) Date: Fri, 21 Sep 2007 00:50:51 +0000 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <9243.42411.qm@web27110.mail.ukl.yahoo.com> References: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Message-ID: As a follow up to confirm, look where I made changes since LONGINT, I believe make-dist in particular I had to make changes to to build the right packages in the right order. I'll look into upgrade/update sometime soon.. - Jay From: jay.krell at cornell.eduTo: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: RE: [M3devel] NT386 with cm3-5.5 bootstrap compilerDate: Fri, 21 Sep 2007 00:49:21 +0000 The "-d5.5" thing is a backup of the package repository. Indeed I find it annoying sometimes, but I mimiced upgrade.sh and I'd have to think it all through again before deleting/changing how it works. I think it makes it easier to back out of a broken change. If you end up with non-working stuff, you copy pkg-d5.5 back on top of pkg. I really strongly suspect update.cmd works. I don't remember if it upgrades...oh, sorry, wrong script I think.make-dist.cmd? How about that one?Whichever one creates .tar.bz2 files. That's the one I meant. Oops, sorry sorry sorry. :\ - Jay Date: Thu, 20 Sep 2007 22:53:35 +0200From: dabenavidesd at yahoo.esTo: hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compilerHi:The script upgarde.cmd produced compiler does recognize the LONGINT as a reserved word.I can get this error when compiling the m2libs of m2tom3 compiler:new source -> compiling SYSTEM.i3"..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT)1 error encounteredThanks again>On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote:> Hi:> Thanks for your suggestions. I have tried the> scripts/win/upgrade.cmd, and It does compile and then> you can execute do-cm3-std.cmd.>> However I noticed the that script exports a m3core pkg> to the repository with a m3core-d5.5 like suffix. Not> sure what is this for.>> I will test if it can recognize the LONGINT datatype.>> Also I have a question about Tony's suggestion. The> packages m3objfile and m3back are not ncessary on the> stages you mention for NT386 target?>Oh, yes, of course they are. Sorry, I forgot about that for NT386.>> Thanks>> --- Tony Hosking escribi?:>>> It strikes me that you may need to sequence as>> follows to avoid>> running into having a compiler that does not handle>> LONGINT.>>>> Using the "devel_LONGINT_start" tagged versions of>> m3core and libm3>> from CVS,>> using your original compiler, build and ship in the>> following order:>>>> m3core (devel_LONGINT_start)>> libm3 (devel_LONGINT_start)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the old>> m3core.>>>> Using the new compiler (in cm3/NT386), and the CVS>> head versions of>> m3core and libm3,>> build and ship in the following order:>>>> m3core (CVS head)>> libm3 (CVS head)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the new>> m3core.>>>> Copy this new compiler to your CM3 installation bin>> directory.>>>> Use this new compiler to rebuild the world.>>>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote:>>>>> Daniel, can you try just going back to 5.2.6 and>> running scripts\win>>> \update?>>> You should be able to build the current source the>> last "official">>> Win32 binaries, as long as you build in the>> correct order and all,>>> which the update.cmd does. You know, there's a>> certain mentality>>> around bootstrapping and keeping the connection>> back to the>>> previous version, that I upheld. As long as you>> are careful, you>>> can go from old binaries to new binaries, you>> don't have to get the>>> new binaries magically somewhere, though you do>> need the old>>> binaries magically from somewhere. :)>>>>>> Perhaps there's a regression. I can check "later".>>>>>> - Jay>>> Date: Wed, 19 Sep 2007 00:49:57 +0200>>> From: dabenavidesd at yahoo.es>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com>>> Subject: Re: [M3devel] NT386 with cm3-5.5>> bootstrap compiler>>>>>> Hi:>>>>>> I have compiled with the Jay produced 5.5>> bootstrap compiler, and>>> also with 5.1.3a,>>> 5.2.6 and get the same error.>>>>>> Thanks>>>>>>> You need to compile the new m3core with the old>> compiler so that the>>>> symbol is available to you when you compile using>> the new compiler.>>>> This is a classical bootstrapping problem.>>>>>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>> Hi:>>>> Thanks for your answer, I have done that and>> also I get the same>>>> runtime error>>>> in the same source file:>>>>>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3>>>> --- building in NT386 --->>>>>>>> ignoring ..\src\m3overrides>>>>>>>> new source -> compiling RTHooks.i3>>>> new source -> compiling RT0.i3>>>> new source -> compiling RuntimeError.i3>>>> new source -> compiling Word.i3>>>> new source -> compiling RTException.i3>>>> new source -> compiling RTHooks.m3>>>> new source -> compiling RT0.m3>>>> new source -> compiling Compiler.i3>>>> new source -> compiling RuntimeError.m3>>>> new source -> compiling Compiler.m3>>>> new source -> compiling RTAllocator.i3>>>> new source -> compiling RTType.i3>>>> new source -> compiling Csetjmp.i3>>>> new source -> compiling BasicCtypes.i3>>>> new source -> compiling Ctypes.i3>>>> new source -> compiling RTMachine.i3>>>> new source -> compiling RTHeapDep.i3>>>> new source -> compiling RTHeapRep.i3>>>> new source -> compiling ThreadF.i3>>>> new source -> compiling RTOS.i3>>>> new source -> compiling RTMisc.i3>>>> new source -> compiling RTHeap.i3>>>> new source -> compiling Cstdlib.i3>>>> new source -> compiling Cstddef.i3>>>> new source -> compiling RTAllocCnts.i3>>>> new source -> compiling RTAllocator.m3>>>> new source -> compiling RTAllocStats.i3>>>> new source -> compiling Convert.i3>>>> new source -> compiling TextClass.i3>>>> new source -> compiling Text.i3>>>> new source -> compiling RTProcedureSRC.i3>>>> new source -> compiling Fingerprint.i3>>>> new source -> compiling RTProcedure.i3>>>> new source -> compiling RTStack.i3>>>> new source -> compiling RTAllocStats.m3>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined runtime>>>> symbol !! (R>>>> THooks.AllocateTracedRef)>>>>>>>>>>>> ***>>>> *** runtime error:>>>> *** Attempt to reference an illegal memory>> location.>>>> *** pc = 0x4c4a0d = StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> ***>>>>>>>> Stack trace:>>>> FP PC Procedure>>>> --------- --------->> ------------------------------->>>> 0x12f494 0x60b3ce SystemError + 0x66 in>> ..\src\runtime\NT386>>>> \RTSignal.m3>>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> 0x12f524 0x51beb8 GenRecord + 0x73 in>> ..\src\builtinOps\New.m3>>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in>> ..\src\builtinOps\New.m3>>>> 0x12f5c8 0x51b70f Gen + 0x12d in>> ..\src\builtinOps\New.m3>>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in>> ..\src\builtinOps\New.m3>>>> 0x12f600 0x550f08 Prep + 0x75 in>> ..\src\exprs\CallExpr.m3>>>> 0x12f61c 0x54312d Prep + 0x54 in>> ..\src\exprs\Expr.m3>>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in>> ..\src\stmts\AssignStmt.m3>>>> 0x12f66c 0x54453b Compile + 0xd6 in>> ..\src\stmts\AssignStmt.m3>>>> ......... ......... ... more frames ...>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>>>>>> You need to recompile m3core before compiling>> with the new>>> compiler.>>>>>>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>>>> Hi all:>>>>> Im getting this runtiem error because the>> symbol>>>>>>>>>> missing version stamps -> compiling>> RTAllocStats.m3>>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined>>> runtime>>>>> symbol !! (R>>>>> THooks.AllocateTracedRef)>>>>>>>>>> AllocateTracedRef is not defined in the m3core>> version S? un Mejor Amante del Cine?Quieres saber c?mo? ?Deja que otras personas te ayuden! . Make your little one a shining star! Shine on! _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 21 17:15:40 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Sep 2007 11:15:40 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: References: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Message-ID: <9CFCC906-27F5-471D-9D12-463BE33E2A28@cs.purdue.edu> On Sep 20, 2007, at 8:50 PM, Jay wrote: > As a follow up to confirm, look where I made changes since > LONGINT, I believe make-dist in particular I had to make changes to > to build the right packages in the right order. I'll look into > upgrade/update sometime soon.. > > - Jay > > From: jay.krell at cornell.edu > To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; > m3devel at elegosoft.com > Subject: RE: [M3devel] NT386 with cm3-5.5 bootstrap compiler > Date: Fri, 21 Sep 2007 00:49:21 +0000 > > The "-d5.5" thing is a backup of the package repository. Indeed I > find it annoying sometimes, but I mimiced upgrade.sh and I'd have > to think it all through again before deleting/changing how it > works. I think it makes it easier to back out of a broken change. > If you end up with non-working stuff, you copy pkg-d5.5 back on top > of pkg. > > I really strongly suspect update.cmd works. I don't remember if it > upgrades...oh, sorry, wrong script I think. > make-dist.cmd? How about that one? > Whichever one creates .tar.bz2 files. That's the one I meant. Oops, > sorry sorry sorry. :\ > > > - Jay > Date: Thu, 20 Sep 2007 22:53:35 +0200 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compiler > > Hi: > > The script upgarde.cmd produced compiler does recognize the LONGINT > as a reserved word. > > I can get this error when compiling the m2libs of m2tom3 compiler: > > > new source -> compiling SYSTEM.i3 > "..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT) > 1 error encountered > I don't see this file in the distribution. I suspect it is something to do with upgrade.cmd. I assume it is defining LONGINT for compilers that don't support it, though I fail to understand why this would be necessary. > Thanks again > > > > >On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote: > > > Hi: > > Thanks for your suggestions. I have tried the > > scripts/win/upgrade.cmd, and It does compile and then > > you can execute do-cm3-std.cmd. > > > > However I noticed the that script exports a m3core pkg > > to the repository with a m3core-d5.5 like suffix. Not > > sure what is this for. > > > > I will test if it can recognize the LONGINT datatype. > > > > Also I have a question about Tony's suggestion. The > > packages m3objfile and m3back are not ncessary on the > > stages you mention for NT386 target? > > >Oh, yes, of course they are. Sorry, I forgot about that for NT386. > > > > > Thanks > > > > --- Tony Hosking escribi?: > > > >> It strikes me that you may need to sequence as > >> follows to avoid > >> running into having a compiler that does not handle > >> LONGINT. > >> > >> Using the "devel_LONGINT_start" tagged versions of > >> m3core and libm3 > >> from CVS, > >> using your original compiler, build and ship in the > >> following order: > >> > >> m3core (devel_LONGINT_start) > >> libm3 (devel_LONGINT_start) > >> m3middle > >> m3linker > >> m3front > >> m3quake > >> cm3 > >> > >> Now you have a new compiler linked against the old > >> m3core. > >> > >> Using the new compiler (in cm3/NT386), and the CVS > >> head versions of > >> m3core and libm3, > >> build and ship in the following order: > >> > >> m3core (CVS head) > >> libm3 (CVS head) > >> m3middle > >> m3linker > >> m3front > >> m3quake > >> cm3 > >> > >> Now you have a new compiler linked against the new > >> m3core. > >> > >> Copy this new compiler to your CM3 installation bin > >> directory. > >> > >> Use this new compiler to rebuild the world. > >> > >> > >> On Sep 18, 2007, at 8:41 PM, Jay wrote: > >> > >>> Daniel, can you try just going back to 5.2.6 and > >> running scripts\win > >>> \update? > >>> You should be able to build the current source the > >> last "official" > >>> Win32 binaries, as long as you build in the > >> correct order and all, > >>> which the update.cmd does. You know, there's a > >> certain mentality > >>> around bootstrapping and keeping the connection > >> back to the > >>> previous version, that I upheld. As long as you > >> are careful, you > >>> can go from old binaries to new binaries, you > >> don't have to get the > >>> new binaries magically somewhere, though you do > >> need the old > >>> binaries magically from somewhere. :) > >>> > >>> Perhaps there's a regression. I can check "later". > >>> > >>> - Jay > >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 > >>> From: dabenavidesd at yahoo.es > >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com > >>> Subject: Re: [M3devel] NT386 with cm3-5.5 > >> bootstrap compiler > >>> > >>> Hi: > >>> > >>> I have compiled with the Jay produced 5.5 > >> bootstrap compiler, and > >>> also with 5.1.3a, > >>> 5.2.6 and get the same error. > >>> > >>> Thanks > >>> > >>>> You need to compile the new m3core with the old > >> compiler so that the > >>>> symbol is available to you when you compile using > >> the new compiler. > >>>> This is a classical bootstrapping problem. > >>> > >>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro > >> Benavides D. wrote: > >>> > >>>> Hi: > >>>> Thanks for your answer, I have done that and > >> also I get the same > >>>> runtime error > >>>> in the same source file: > >>>> > >>>> > >>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > >>>> --- building in NT386 --- > >>>> > >>>> ignoring ..\src\m3overrides > >>>> > >>>> new source -> compiling RTHooks.i3 > >>>> new source -> compiling RT0.i3 > >>>> new source -> compiling RuntimeError.i3 > >>>> new source -> compiling Word.i3 > >>>> new source -> compiling RTException.i3 > >>>> new source -> compiling RTHooks.m3 > >>>> new source -> compiling RT0.m3 > >>>> new source -> compiling Compiler.i3 > >>>> new source -> compiling RuntimeError.m3 > >>>> new source -> compiling Compiler.m3 > >>>> new source -> compiling RTAllocator.i3 > >>>> new source -> compiling RTType.i3 > >>>> new source -> compiling Csetjmp.i3 > >>>> new source -> compiling BasicCtypes.i3 > >>>> new source -> compiling Ctypes.i3 > >>>> new source -> compiling RTMachine.i3 > >>>> new source -> compiling RTHeapDep.i3 > >>>> new source -> compiling RTHeapRep.i3 > >>>> new source -> compiling ThreadF.i3 > >>>> new source -> compiling RTOS.i3 > >>>> new source -> compiling RTMisc.i3 > >>>> new source -> compiling RTHeap.i3 > >>>> new source -> compiling Cstdlib.i3 > >>>> new source -> compiling Cstddef.i3 > >>>> new source -> compiling RTAllocCnts.i3 > >>>> new source -> compiling RTAllocator.m3 > >>>> new source -> compiling RTAllocStats.i3 > >>>> new source -> compiling Convert.i3 > >>>> new source -> compiling TextClass.i3 > >>>> new source -> compiling Text.i3 > >>>> new source -> compiling RTProcedureSRC.i3 > >>>> new source -> compiling Fingerprint.i3 > >>>> new source -> compiling RTProcedure.i3 > >>>> new source -> compiling RTStack.i3 > >>>> new source -> compiling RTAllocStats.m3 > >>>> "..\src\runtime\common\RTAllocStats.m3", line > >> 46: undefined runtime > >>>> symbol !! (R > >>>> THooks.AllocateTracedRef) > >>>> > >>>> > >>>> *** > >>>> *** runtime error: > >>>> *** Attempt to reference an illegal memory > >> location. > >>>> *** pc = 0x4c4a0d = StartCall + 0xf in > >> ..\src\values\Procedure.m3 > >>>> *** > >>>> > >>>> Stack trace: > >>>> FP PC Procedure > >>>> --------- --------- > >> ------------------------------- > >>>> 0x12f494 0x60b3ce SystemError + 0x66 in > >> ..\src\runtime\NT386 > >>>> \RTSignal.m3 > >>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in > >> ..\src\values\Procedure.m3 > >>>> 0x12f524 0x51beb8 GenRecord + 0x73 in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f5c8 0x51b70f Gen + 0x12d in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f600 0x550f08 Prep + 0x75 in > >> ..\src\exprs\CallExpr.m3 > >>>> 0x12f61c 0x54312d Prep + 0x54 in > >> ..\src\exprs\Expr.m3 > >>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in > >> ..\src\stmts\AssignStmt.m3 > >>>> 0x12f66c 0x54453b Compile + 0xd6 in > >> ..\src\stmts\AssignStmt.m3 > >>>> ......... ......... ... more frames ... > >>>> > >>>> C:\cm3-cvs\cm3\m3-libs\m3core> > >>>>> You need to recompile m3core before compiling > >> with the new > >>> compiler. > >>>> > >>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro > >> Benavides D. wrote: > >>>> > >>>>> Hi all: > >>>>> Im getting this runtiem error because the > >> symbol > >>>>> > >>>>> missing version stamps -> compiling > >> RTAllocStats.m3 > >>>>> "..\src\runtime\common\RTAllocStats.m3", line > >> 46: undefined > >>> runtime > >>>>> symbol !! (R > >>>>> THooks.AllocateTracedRef) > >>>>> > >>>>> AllocateTracedRef is not defined in the m3core > >> version > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . > > Make your little one a shining star! Shine on! > Make your little one a shining star! Shine on! From dabenavidesd at yahoo.es Fri Sep 21 18:18:08 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 21 Sep 2007 18:18:08 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <9CFCC906-27F5-471D-9D12-463BE33E2A28@cs.purdue.edu> Message-ID: <724862.70169.qm@web27112.mail.ukl.yahoo.com> Hi: Oh Im sorry I meant, that the compiler is working Ok with LONGINT, at least because is recognizing that LONGINT is a reserved word. SYSTEM.i3 is just source file of the m2tom3 Modula-2 to Modula-3 compiler; I used as a test for the cm3 compiler, beside it is an example of Modula-2 and Modula-3 using a common type LONGINT. Thanks --- Tony Hosking escribi?: > > On Sep 20, 2007, at 8:50 PM, Jay wrote: > > > As a follow up to confirm, look where I made > changes since > > LONGINT, I believe make-dist in particular I had > to make changes to > > to build the right packages in the right order. > I'll look into > > upgrade/update sometime soon.. > > > > - Jay > > > > From: jay.krell at cornell.edu > > To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; > > > m3devel at elegosoft.com > > Subject: RE: [M3devel] NT386 with cm3-5.5 > bootstrap compiler > > Date: Fri, 21 Sep 2007 00:49:21 +0000 > > > > The "-d5.5" thing is a backup of the package > repository. Indeed I > > find it annoying sometimes, but I mimiced > upgrade.sh and I'd have > > to think it all through again before > deleting/changing how it > > works. I think it makes it easier to back out of a > broken change. > > If you end up with non-working stuff, you copy > pkg-d5.5 back on top > > of pkg. > > > > I really strongly suspect update.cmd works. I > don't remember if it > > upgrades...oh, sorry, wrong script I think. > > make-dist.cmd? How about that one? > > Whichever one creates .tar.bz2 files. That's the > one I meant. Oops, > > sorry sorry sorry. :\ > > > > > > - Jay > > Date: Thu, 20 Sep 2007 22:53:35 +0200 > > From: dabenavidesd at yahoo.es > > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Subject: Re: [M3devel] NT386 with cm3-5.5 > bootstrap compiler > > > > Hi: > > > > The script upgrade.cmd produced compiler does > recognize the LONGINT > > as a reserved word. > > > > I can get this error when compiling the m2libs of > m2tom3 compiler: > > > > > > new source -> compiling SYSTEM.i3 > > "..\src\SYSTEM.i3", line 40: Reserved identifier > redefined (LONGINT) > > 1 error encountered > > > > I don't see this file in the distribution. I > suspect it is something > to do with upgrade.cmd. I assume it is defining > LONGINT for > compilers that don't support it, though I fail to > understand why this > would be necessary. > > > > Thanks again > > > > > > > > >On Sep 20, 2007, at 11:15 AM, Daniel Alejandro > Benavides D. wrote: > > > > > Hi: > > > Thanks for your suggestions. I have tried the > > > scripts/win/upgrade.cmd, and It does compile and > then > > > you can execute do-cm3-std.cmd. > > > > > > However I noticed the that script exports a > m3core pkg > > > to the repository with a m3core-d5.5 like > suffix. Not > > > sure what is this for. > > > > > > I will test if it can recognize the LONGINT > datatype. > > > > > > Also I have a question about Tony's suggestion. > The > > > packages m3objfile and m3back are not ncessary > on the > > > stages you mention for NT386 target? > > > > >Oh, yes, of course they are. Sorry, I forgot > about that for NT386. > > > > > > > > Thanks > > > > > > --- Tony Hosking > escribi?: > > > > > >> It strikes me that you may need to sequence as > > >> follows to avoid > > >> running into having a compiler that does not > handle > > >> LONGINT. > > >> > > >> Using the "devel_LONGINT_start" tagged versions > of > > >> m3core and libm3 > > >> from CVS, > > >> using your original compiler, build and ship in > the > > >> following order: > > >> > > >> m3core (devel_LONGINT_start) > > >> libm3 (devel_LONGINT_start) > > >> m3middle > > >> m3linker > > >> m3front > > >> m3quake > > >> cm3 > > >> > > >> Now you have a new compiler linked against the > old > > >> m3core. > > >> > > >> Using the new compiler (in cm3/NT386), and the > CVS > > >> head versions of > > >> m3core and libm3, > > >> build and ship in the following order: > > >> > > >> m3core (CVS head) > > >> libm3 (CVS head) > > >> m3middle > > >> m3linker > > >> m3front > > >> m3quake > > >> cm3 > > >> > > >> Now you have a new compiler linked against the > new > > >> m3core. > > >> > > >> Copy this new compiler to your CM3 installation > bin > > >> directory. > > >> > > >> Use this new compiler to rebuild the world. > > >> > > >> > > >> On Sep 18, 2007, at 8:41 PM, Jay wrote: > > >> > > >>> Daniel, can you try just going back to 5.2.6 > and > > >> running scripts\win > > >>> \update? > > >>> You should be able to build the current source > the > > >> last "official" > > >>> Win32 binaries, as long as you build in the > > >> correct order and all, > > >>> which the update.cmd does. You know, there's a > > >> certain mentality > > >>> around bootstrapping and keeping the > connection > > >> back to the > > >>> previous version, that I upheld. As long as > you > > >> are careful, you > > >>> can go from old binaries to new binaries, you > > >> don't have to get the > > >>> new binaries magically somewhere, though you > do > > >> need the old > > >>> binaries magically from somewhere. :) > > >>> > > >>> Perhaps there's a regression. I can check > "later". > > >>> > > >>> - Jay > > >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 > > >>> From: dabenavidesd at yahoo.es > > >>> To: hosking at cs.purdue.edu; > m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] NT386 with cm3-5.5 > > >> bootstrap compiler > > >>> > > >>> Hi: > > >>> > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From rodney.bates at wichita.edu Fri Sep 21 18:57:59 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 21 Sep 2007 11:57:59 -0500 Subject: [M3devel] A RT failure in ThreadPThread.Alert] Message-ID: <46F3F817.4000909@wichita.edu> I got a runtime failure in ThreadPThread.Alert, on this line: ---------------------------------------------------------------------------------- PROCEDURE Alert (t: T) = BEGIN WITH r = Upthread.mutex_lock(cm) DO <*ASSERT r=0*> END; t.alerted := TRUE; --> WITH r = Upthread.cond_signal(t.waitCond^) DO <*ASSERT r=0*> END; WITH r = Upthread.mutex_unlock(cm) DO <*ASSERT r=0*> END; END Alert; ------------------------------------------------------------------------------------ Here, t.waitCond is NIL and being dereferenced. I tried just making this silently tolerate NIL t.waitCond, and it made the immediate symptom go away, with no other immediately apparent problems. But this seems not very likely to be right. For one thing, there are several other places that assume waitCond is non-NIL. And, a quick reading revealed only one place that creates this object, which always allocates waitCond, no places that change it, and T is opaque and revealed only in this module. How could this happen? Here is a bit of debugger output: The display of t is at the bottom. ------------------------------------------------------------------------------------ *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 304 *** ------------------ EXCEPTION HANDLER STACK --------------------- 0xb5eb71dc TRY-EXCEPT {0xa893a19c} 0xb5eb72bc LOCK mutex = 0xb436e0e4 0xb5eb731c LOCK mutex = 0xb6ebbc44 ---------------------------------------------------------------- [Switching to Thread -1242858592 (LWP 8289)] Breakpoint 2, 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 272 ; PROCEDURE InnerRuntimeFailureDialog ( ) (m3gdb) bt #0 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 #1 0x08126c89 in RuntimeFailureDialog () at AssertDevel.m3:314 #2 0xb72e596f in InvokeExitors () at RTProcess.m3:40 #3 0xb72e59e3 in Crash (msg=NIL) at RTProcess.m3:61 #4 0xb72e3648 in EndError (crash=TRUE) at RTError.m3:115 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 #6 0xb72e3a46 in Crash (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE, rte=16_b73124c0) at RTException.m3:79 #7 0xb72e3770 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:39 #8 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #9 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #10 0xb72e3810 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:47 #11 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #12 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #13 0xb72cb223 in ReportFault (module=16_b731e020, info=9732) at RTHooks.m3:110 #14 0xb72fb697 in _m3_fault (arg=9732) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 #16 0xb7df741d in DisplayDir (v=16_b436e004) at FileBrowserVBT.m3:496 #17 0xb7df4d83 in Refresh (v=16_b436e004) at FileBrowserVBT.m3:210 #18 0xb7df5413 in Watcher (cl=16_b6ebbc9c) at FileBrowserVBT.m3:254 #19 0xb72f76f5 in RunThread (me=16_08e1c518) at ThreadPThread.m3:538 #20 0xb72f7403 in ThreadBase (param=16_08e1c518) at ThreadPThread.m3:519 #21 0xb707c540 in start_thread () from /lib/i686/libpthread.so.0 #22 0xb6fef55e in clone () from /lib/i686/libc.so.6 (m3gdb) frame 5 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 40 RTError.m3: No such file or directory. in RTError.m3 (m3gdb) p msgA $1 = (*16_b7318068*) "" (m3gdb) p msgB $2 = (*16_b73126d4*) "Attempt to reference an illegal memory location." (m3gdb) p msgC $3 = (*16_b7318068*) "" (m3gdb) frame 15 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 304 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) p t $4 = (*16_b3a9bdc8*) OBJECT act = 16_08e94678; closure = NIL; result = NIL; cond = 16_b3a9bdf4; waitingOn = NIL; nextWaiter = NIL; waitCond = NIL; alerted = TRUE; completed = TRUE; joined = FALSE; id = 73; END (m3gdb) -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Fri Sep 21 19:16:11 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Sep 2007 13:16:11 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <724862.70169.qm@web27112.mail.ukl.yahoo.com> References: <724862.70169.qm@web27112.mail.ukl.yahoo.com> Message-ID: <0E2AE424-55FE-4CE4-8223-DE9E2C162E74@cs.purdue.edu> Does this mean you no longer have trouble? On Sep 21, 2007, at 12:18 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Oh Im sorry I meant, that the compiler is working Ok > with LONGINT, at least because is recognizing that > LONGINT is a reserved word. > > SYSTEM.i3 is just source file of the m2tom3 Modula-2 > to Modula-3 compiler; I used as a test for the cm3 > compiler, beside it is an example of Modula-2 and > Modula-3 using a common type LONGINT. > > Thanks > > --- Tony Hosking escribi?: > >> >> On Sep 20, 2007, at 8:50 PM, Jay wrote: >> >>> As a follow up to confirm, look where I made >> changes since >>> LONGINT, I believe make-dist in particular I had >> to make changes to >>> to build the right packages in the right order. >> I'll look into >>> upgrade/update sometime soon.. >>> >>> - Jay >>> >>> From: jay.krell at cornell.edu >>> To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; >> >>> m3devel at elegosoft.com >>> Subject: RE: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> Date: Fri, 21 Sep 2007 00:49:21 +0000 >>> >>> The "-d5.5" thing is a backup of the package >> repository. Indeed I >>> find it annoying sometimes, but I mimiced >> upgrade.sh and I'd have >>> to think it all through again before >> deleting/changing how it >>> works. I think it makes it easier to back out of a >> broken change. >>> If you end up with non-working stuff, you copy >> pkg-d5.5 back on top >>> of pkg. >>> >>> I really strongly suspect update.cmd works. I >> don't remember if it >>> upgrades...oh, sorry, wrong script I think. >>> make-dist.cmd? How about that one? >>> Whichever one creates .tar.bz2 files. That's the >> one I meant. Oops, >>> sorry sorry sorry. :\ >>> >>> >>> - Jay >>> Date: Thu, 20 Sep 2007 22:53:35 +0200 >>> From: dabenavidesd at yahoo.es >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> >>> Hi: >>> >>> The script upgrade.cmd produced compiler does >> recognize the LONGINT >>> as a reserved word. >>> >>> I can get this error when compiling the m2libs of >> m2tom3 compiler: >>> >>> >>> new source -> compiling SYSTEM.i3 >>> "..\src\SYSTEM.i3", line 40: Reserved identifier >> redefined (LONGINT) >>> 1 error encountered >>> >> >> I don't see this file in the distribution. I >> suspect it is something >> to do with upgrade.cmd. I assume it is defining >> LONGINT for >> compilers that don't support it, though I fail to >> understand why this >> would be necessary. >> >> >>> Thanks again >>> >>> >>> >>>> On Sep 20, 2007, at 11:15 AM, Daniel Alejandro >> Benavides D. wrote: >>> >>>> Hi: >>>> Thanks for your suggestions. I have tried the >>>> scripts/win/upgrade.cmd, and It does compile and >> then >>>> you can execute do-cm3-std.cmd. >>>> >>>> However I noticed the that script exports a >> m3core pkg >>>> to the repository with a m3core-d5.5 like >> suffix. Not >>>> sure what is this for. >>>> >>>> I will test if it can recognize the LONGINT >> datatype. >>>> >>>> Also I have a question about Tony's suggestion. >> The >>>> packages m3objfile and m3back are not ncessary >> on the >>>> stages you mention for NT386 target? >>> >>>> Oh, yes, of course they are. Sorry, I forgot >> about that for NT386. >>> >>>> >>>> Thanks >>>> >>>> --- Tony Hosking >> escribi?: >>>> >>>>> It strikes me that you may need to sequence as >>>>> follows to avoid >>>>> running into having a compiler that does not >> handle >>>>> LONGINT. >>>>> >>>>> Using the "devel_LONGINT_start" tagged versions >> of >>>>> m3core and libm3 >>>>> from CVS, >>>>> using your original compiler, build and ship in >> the >>>>> following order: >>>>> >>>>> m3core (devel_LONGINT_start) >>>>> libm3 (devel_LONGINT_start) >>>>> m3middle >>>>> m3linker >>>>> m3front >>>>> m3quake >>>>> cm3 >>>>> >>>>> Now you have a new compiler linked against the >> old >>>>> m3core. >>>>> >>>>> Using the new compiler (in cm3/NT386), and the >> CVS >>>>> head versions of >>>>> m3core and libm3, >>>>> build and ship in the following order: >>>>> >>>>> m3core (CVS head) >>>>> libm3 (CVS head) >>>>> m3middle >>>>> m3linker >>>>> m3front >>>>> m3quake >>>>> cm3 >>>>> >>>>> Now you have a new compiler linked against the >> new >>>>> m3core. >>>>> >>>>> Copy this new compiler to your CM3 installation >> bin >>>>> directory. >>>>> >>>>> Use this new compiler to rebuild the world. >>>>> >>>>> >>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote: >>>>> >>>>>> Daniel, can you try just going back to 5.2.6 >> and >>>>> running scripts\win >>>>>> \update? >>>>>> You should be able to build the current source >> the >>>>> last "official" >>>>>> Win32 binaries, as long as you build in the >>>>> correct order and all, >>>>>> which the update.cmd does. You know, there's a >>>>> certain mentality >>>>>> around bootstrapping and keeping the >> connection >>>>> back to the >>>>>> previous version, that I upheld. As long as >> you >>>>> are careful, you >>>>>> can go from old binaries to new binaries, you >>>>> don't have to get the >>>>>> new binaries magically somewhere, though you >> do >>>>> need the old >>>>>> binaries magically from somewhere. :) >>>>>> >>>>>> Perhaps there's a regression. I can check >> "later". >>>>>> >>>>>> - Jay >>>>>> Date: Wed, 19 Sep 2007 00:49:57 +0200 >>>>>> From: dabenavidesd at yahoo.es >>>>>> To: hosking at cs.purdue.edu; >> m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] NT386 with cm3-5.5 >>>>> bootstrap compiler >>>>>> >>>>>> Hi: >>>>>> >> > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Fri Sep 21 19:27:10 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 21 Sep 2007 19:27:10 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <0E2AE424-55FE-4CE4-8223-DE9E2C162E74@cs.purdue.edu> Message-ID: <413596.25532.qm@web27105.mail.ukl.yahoo.com> Hi: Yes, exactly :) Thanks --- Tony Hosking escribi?: > Does this mean you no longer have trouble? > > On Sep 21, 2007, at 12:18 PM, Daniel Alejandro > Benavides D. wrote: > > > Hi: > > Oh Im sorry I meant, that the compiler is working > Ok > > with LONGINT, at least because is recognizing that > > LONGINT is a reserved word. > > > > SYSTEM.i3 is just source file of the m2tom3 > Modula-2 > > to Modula-3 compiler; I used as a test for the cm3 > > compiler, beside it is an example of Modula-2 and > > Modula-3 using a common type LONGINT. > > > > Thanks > > > > --- Tony Hosking > escribi?: > > > >> > >> On Sep 20, 2007, at 8:50 PM, Jay wrote: > >> > >>> As a follow up to confirm, look where I made > >> changes since > >>> LONGINT, I believe make-dist in particular I had > >> to make changes to > >>> to build the right packages in the right order. > >> I'll look into > >>> upgrade/update sometime soon.. > >>> > >>> - Jay > >>> > >>> From: jay.krell at cornell.edu > >>> To: dabenavidesd at yahoo.es; > hosking at cs.purdue.edu; > >> > >>> m3devel at elegosoft.com > >>> Subject: RE: [M3devel] NT386 with cm3-5.5 > >> bootstrap compiler > >>> Date: Fri, 21 Sep 2007 00:49:21 +0000 > >>> > >>> The "-d5.5" thing is a backup of the package > >> repository. Indeed I > >>> find it annoying sometimes, but I mimiced > >> upgrade.sh and I'd have > >>> to think it all through again before > >> deleting/changing how it > >>> works. I think it makes it easier to back out of > a > >> broken change. > >>> If you end up with non-working stuff, you copy > >> pkg-d5.5 back on top > >>> of pkg. > >>> > >>> I really strongly suspect update.cmd works. I > >> don't remember if it > >>> upgrades...oh, sorry, wrong script I think. > >>> make-dist.cmd? How about that one? > >>> Whichever one creates .tar.bz2 files. That's the > >> one I meant. Oops, > >>> sorry sorry sorry. :\ > >>> > >>> > >>> - Jay > >>> Date: Thu, 20 Sep 2007 22:53:35 +0200 > >>> From: dabenavidesd at yahoo.es > >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com > >>> Subject: Re: [M3devel] NT386 with cm3-5.5 > >> bootstrap compiler > >>> > >>> Hi: > >>> > >>> The script upgrade.cmd produced compiler does > >> recognize the LONGINT > >>> as a reserved word. > >>> > >>> I can get this error when compiling the m2libs > of > >> m2tom3 compiler: > >>> > >>> > >>> new source -> compiling SYSTEM.i3 > >>> "..\src\SYSTEM.i3", line 40: Reserved identifier > >> redefined (LONGINT) > >>> 1 error encountered > >>> > >> > >> I don't see this file in the distribution. I > >> suspect it is something > >> to do with upgrade.cmd. I assume it is defining > >> LONGINT for > >> compilers that don't support it, though I fail to > >> understand why this > >> would be necessary. > >> > >> > >>> Thanks again > >>> > >>> > >>> > >>>> On Sep 20, 2007, at 11:15 AM, Daniel Alejandro > >> Benavides D. wrote: > >>> > >>>> Hi: > >>>> Thanks for your suggestions. I have tried the > >>>> scripts/win/upgrade.cmd, and It does compile > and > >> then > >>>> you can execute do-cm3-std.cmd. > >>>> > >>>> However I noticed the that script exports a > >> m3core pkg > >>>> to the repository with a m3core-d5.5 like > >> suffix. Not > >>>> sure what is this for. > >>>> > >>>> I will test if it can recognize the LONGINT > >> datatype. > >>>> > >>>> Also I have a question about Tony's > suggestion. > >> The > >>>> packages m3objfile and m3back are not ncessary > >> on the > >>>> stages you mention for NT386 target? > >>> > >>>> Oh, yes, of course they are. Sorry, I forgot > >> about that for NT386. > >>> > >>>> > >>>> Thanks > >>>> > >>>> --- Tony Hosking > >> escribi?: > >>>> > >>>>> It strikes me that you may need to sequence as > >>>>> follows to avoid > >>>>> running into having a compiler that does not > >> handle > >>>>> LONGINT. > >>>>> > >>>>> Using the "devel_LONGINT_start" tagged > versions > >> of > >>>>> m3core and libm3 > >>>>> from CVS, > >>>>> using your original compiler, build and ship > in > >> the > >>>>> following order: > >>>>> > >>>>> m3core (devel_LONGINT_start) > >>>>> libm3 (devel_LONGINT_start) > >>>>> m3middle > >>>>> m3linker > >>>>> m3front > >>>>> m3quake > >>>>> cm3 > >>>>> > >>>>> Now you have a new compiler linked against > the > >> old > >>>>> m3core. > >>>>> > >>>>> Using the new compiler (in cm3/NT386), and the > >> CVS > >>>>> head versions of > >>>>> m3core and libm3, > >>>>> build and ship in the following order: > >>>>> > >>>>> m3core (CVS head) > >>>>> libm3 (CVS head) > >>>>> m3middle > >>>>> m3linker > >>>>> m3front > >>>>> m3quake > >>>>> cm3 > >>>>> > >>>>> Now you have a new compiler linked against the > >> new > >>>>> m3core. > >>>>> > >>>>> Copy this new compiler to your CM3 > installation > >> bin > >>>>> directory. > >>>>> > >>>>> Use this new compiler to rebuild the world. > >>>>> > >>>>> > >>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote: > >>>>> > >>>>>> Daniel, can you try just going back to 5.2.6 > >> and > >>>>> running scripts\win > >>>>>> \update? > >>>>>> You should be able to build the current > source > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 21 19:30:11 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Sep 2007 13:30:11 -0400 Subject: [M3devel] A RT failure in ThreadPThread.Alert] In-Reply-To: <46F3F817.4000909@wichita.edu> References: <46F3F817.4000909@wichita.edu> Message-ID: waitCond should be valid for all live threads. I'm assuming you are invoking Thread.Alert on a thread that is no longer alive. Indeed, you can see from the debug output that the thread has completed. I suppose we could silently ignore the alert for a completed thread, but I suspect this reveals some deeper problem with your code -- should you really issue an alert to a thread that is incapable of receiving it. I wonder if the alert flag is already set for that thread. In any case I suppose we can simply check for NIL in Alert. I've checked in code to do this. On Sep 21, 2007, at 12:57 PM, Rodney M. Bates wrote: > > > > I got a runtime failure in ThreadPThread.Alert, on this line: > > ---------------------------------------------------------------------- > ------------ > PROCEDURE Alert (t: T) = > BEGIN > WITH r = Upthread.mutex_lock(cm) DO <*ASSERT r=0*> END; > t.alerted := TRUE; > --> WITH r = Upthread.cond_signal(t.waitCond^) DO <*ASSERT r=0*> END; > WITH r = Upthread.mutex_unlock(cm) DO <*ASSERT r=0*> END; > END Alert; > ---------------------------------------------------------------------- > -------------- > Here, t.waitCond is NIL and being dereferenced. I tried just > making this > silently tolerate NIL t.waitCond, and it made the immediate symptom > go away, > with no other immediately apparent problems. But this seems not > very likely > to be right. For one thing, there are several other places that > assume > waitCond is non-NIL. And, a quick reading revealed only one place > that creates > this object, which always allocates waitCond, no places that change > it, and > T is opaque and revealed only in this module. How could this happen? > > > Here is a bit of debugger output: The display of t is at the bottom. > ---------------------------------------------------------------------- > -------------- > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 304 > *** > > ------------------ EXCEPTION HANDLER STACK --------------------- > 0xb5eb71dc TRY-EXCEPT {0xa893a19c} > 0xb5eb72bc LOCK mutex = 0xb436e0e4 > 0xb5eb731c LOCK mutex = 0xb6ebbc44 > ---------------------------------------------------------------- > [Switching to Thread -1242858592 (LWP 8289)] > > Breakpoint 2, 0x08126a38 in InnerRuntimeFailureDialog () at > AssertDevel.m3:272 > 272 ; PROCEDURE InnerRuntimeFailureDialog ( ) > (m3gdb) bt > #0 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 > #1 0x08126c89 in RuntimeFailureDialog () at AssertDevel.m3:314 > #2 0xb72e596f in InvokeExitors () at RTProcess.m3:40 > #3 0xb72e59e3 in Crash (msg=NIL) at RTProcess.m3:61 > #4 0xb72e3648 in EndError (crash=TRUE) at RTError.m3:115 > #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, > msgA=16_b7318068, msgB=16_b73126d4, > msgC=16_b7318068) at RTError.m3:40 > #6 0xb72e3a46 in Crash (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE, > rte=16_b73124c0) at RTException.m3:79 > #7 0xb72e3770 in DefaultBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:39 > #8 0xb72e36d4 in InvokeBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:25 > #9 0xb72f3397 in Raise (act= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END) at RTExFrame.m3:29 > #10 0xb72e3810 in DefaultBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:47 > #11 0xb72e36d4 in InvokeBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:25 > #12 0xb72f3397 in Raise (act= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END) at RTExFrame.m3:29 > #13 0xb72cb223 in ReportFault (module=16_b731e020, info=9732) at > RTHooks.m3:110 > #14 0xb72fb697 in _m3_fault (arg=9732) from /usr/local/cm3/pkg/ > m3core/LINUXLIBC6/libm3core.so.5 > #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 > #16 0xb7df741d in DisplayDir (v=16_b436e004) at FileBrowserVBT.m3:496 > #17 0xb7df4d83 in Refresh (v=16_b436e004) at FileBrowserVBT.m3:210 > #18 0xb7df5413 in Watcher (cl=16_b6ebbc9c) at FileBrowserVBT.m3:254 > #19 0xb72f76f5 in RunThread (me=16_08e1c518) at ThreadPThread.m3:538 > #20 0xb72f7403 in ThreadBase (param=16_08e1c518) at > ThreadPThread.m3:519 > #21 0xb707c540 in start_thread () from /lib/i686/libpthread.so.0 > #22 0xb6fef55e in clone () from /lib/i686/libc.so.6 > (m3gdb) frame 5 > #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, > msgA=16_b7318068, msgB=16_b73126d4, > msgC=16_b7318068) at RTError.m3:40 > 40 RTError.m3: No such file or directory. > in RTError.m3 > (m3gdb) p msgA > $1 = (*16_b7318068*) "" > (m3gdb) p msgB > $2 = (*16_b73126d4*) "Attempt to reference an illegal memory > location." > (m3gdb) p msgC > $3 = (*16_b7318068*) "" > (m3gdb) frame 15 > #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 > 304 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) p t > $4 = (*16_b3a9bdc8*) OBJECT act = 16_08e94678; closure = NIL; > result = NIL; cond = 16_b3a9bdf4; > waitingOn = NIL; nextWaiter = NIL; waitCond = NIL; alerted = > TRUE; completed = TRUE; > joined = FALSE; id = 73; END > (m3gdb) > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu > From rodney.bates at wichita.edu Sat Sep 22 04:51:36 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 21 Sep 2007 21:51:36 -0500 Subject: [M3devel] A RT failure in ThreadPThread.Alert] In-Reply-To: <7AE14F7D-216C-40B8-996E-0BC97875D4D9@cs.purdue.edu> References: <46F3F817.4000909@wichita.edu> <46F41CE8.9060804@wichita.edu> <7AE14F7D-216C-40B8-996E-0BC97875D4D9@cs.purdue.edu> Message-ID: <46F48338.8040304@wichita.edu> From a bit of code reading, it looks like: 1) FileBrowserVBT.m3 has been routinely doing this for a long time (Alerting a thread that has most likely already terminated), and 2) ThreadPosix tolerates this harmlessly. So, making ThreadPThread also tolerate it is probably the right fix. Tony Hosking wrote: > Hmmm. Perhaps there is a deeper problem. > > On Sep 21, 2007, at 3:35 PM, Rodney M. Bates wrote: > >> The Alert is coming from somewhere inside Trestle. I guess I need to >> look into that. >> >> Tony Hosking wrote: >> >>> waitCond should be valid for all live threads. I'm assuming you >>> are invoking Thread.Alert on a thread that is no longer alive. >>> Indeed, you can see from the debug output that the thread has >>> completed. I suppose we could silently ignore the alert for a >>> completed thread, but I suspect this reveals some deeper problem >>> with your code -- should you really issue an alert to a thread that >>> is incapable of receiving it. I wonder if the alert flag is >>> already set for that thread. In any case I suppose we can simply >>> check for NIL in Alert. I've checked in code to do this. >> >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Sat Sep 22 06:10:10 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 22 Sep 2007 00:10:10 -0400 Subject: [M3devel] A RT failure in ThreadPThread.Alert] In-Reply-To: <46F48338.8040304@wichita.edu> References: <46F3F817.4000909@wichita.edu> <46F41CE8.9060804@wichita.edu> <7AE14F7D-216C-40B8-996E-0BC97875D4D9@cs.purdue.edu> <46F48338.8040304@wichita.edu> Message-ID: <730D7378-3B00-4DB8-9DA5-75C55FCB74E0@cs.purdue.edu> The update I checked in earlier today does the trick. On Sep 21, 2007, at 10:51 PM, Rodney M. Bates wrote: > From a bit of code reading, it looks like: > > 1) FileBrowserVBT.m3 has been routinely doing this for a long time > (Alerting a thread that has most likely already terminated), and > > 2) ThreadPosix tolerates this harmlessly. > > So, making ThreadPThread also tolerate it is probably the right fix. > > Tony Hosking wrote: >> Hmmm. Perhaps there is a deeper problem. >> On Sep 21, 2007, at 3:35 PM, Rodney M. Bates wrote: >>> The Alert is coming from somewhere inside Trestle. I guess I >>> need to >>> look into that. >>> >>> Tony Hosking wrote: >>> >>>> waitCond should be valid for all live threads. I'm assuming >>>> you are invoking Thread.Alert on a thread that is no longer >>>> alive. Indeed, you can see from the debug output that the >>>> thread has completed. I suppose we could silently ignore the >>>> alert for a completed thread, but I suspect this reveals some >>>> deeper problem with your code -- should you really issue an >>>> alert to a thread that is incapable of receiving it. I wonder >>>> if the alert flag is already set for that thread. In any case >>>> I suppose we can simply check for NIL in Alert. I've checked >>>> in code to do this. >>> >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From dabenavidesd at yahoo.es Thu Sep 27 08:32:37 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 27 Sep 2007 08:32:37 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 Message-ID: <266390.74360.qm@web27112.mail.ukl.yahoo.com> Hi: I am testing some examples of Chapter 16 of Laszlo book, but the text shows me that now the NThreads example where 10 threads are being showing the IDs (1, 2, ... ,10). This is tested on ubuntu Dapper OS, which still allows the use of user space threads implementation. Attached are some animated gif files that show in (sorry have no web page available) LINUXLIBC6.gif exmaple execution of Systems level threads LINUXLIBC62.gif example execution of User space threads LINUXLIBC62a.gif example execution of User space threads after it ends Why the different versions of thread implementation are different, in terms of what showthread shows that all the threads are "locking" (9 almost all time) and 2 (the first and third form left to right) are "alive" in the Pthread case, and why in the user space threads case they are "alive" green color almost always if they are not running. The worst thing is the behaviour of the appication is very rare, It should be running until a key (enter) is pressed down; It just runs some seconds in pthread case. Besides why some many objects are shown in shownew with the user space threaded program. The linking information of ldd output is below. LINUXLIBC6 is current cvs compiled example LINUXLIBC&2 compiled with user spce threads. on LINUXLIBC6 with user space threads, June 9th the date It was compiled. danielb at danielb-desktop:~/code/m3/parallel$ ldd LINUXLIBC62/NThreads linux-gate.so.1 => (0xffffe000) libm3local.so.5 => /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 (0xb7faf000) libm3.so.5 => /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 (0xb7e90000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 (0xb760f000) libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb75d1000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb74a2000) /lib/ld-linux.so.2 (0xb7fbd000) on LINUXLIBC6 with system threads: danielb at danielb-desktop:~/code/m3/parallel$ ldd LINUXLIBC6/NThreads linux-gate.so.1 => (0xffffe000) libm3local.so.5 => /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 (0xb7f51000) libm3.so.5 => /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 (0xb7e1e000) libm3core.so.5 => /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 (0xb7592000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7544000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7415000) /lib/ld-linux.so.2 (0xb7f5f000) the source code is this MODULE NThreads EXPORTS Main; (*22.02.95. LB*) (* Program starts "N" threads which output their ID and terminate if a key is pressed (on some systems you have to press the return key). *) IMPORT Thread, SIO; FROM Scheduler IMPORT Yield; CONST N = 10; TYPE Threads = [1..N]; Closure = Thread.Closure OBJECT id: Threads; (*identifies thread*) OVERRIDES apply:= PrintId; END; (*Closure*) PROCEDURE PrintId(cl: Closure): REFANY = BEGIN REPEAT SIO.PutInt(cl.id); IF cl.id = LAST(Threads) THEN SIO.Nl() END; Yield(); (*yields to other threads*) UNTIL SIO.Available(); RETURN NIL; (*return value not used*) END PrintId; PROCEDURE Fork() = BEGIN FOR i:= FIRST(Threads) TO LAST(Threads) - 1 DO EVAL Thread.Fork(NEW(Closure, id:= i)) (*N-1 threads are generated*) END; EVAL PrintId(NEW(Closure, id:= LAST(Threads))); (*N-th thread = main*) END Fork; BEGIN Fork(); (*start all threads*) END NThreads. Thanks ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html -------------- next part -------------- A non-text attachment was scrubbed... Name: LINUXLIBC6.gif Type: image/gif Size: 169516 bytes Desc: 1808490959-LINUXLIBC6.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LINUXLIBC62.gif Type: image/gif Size: 170325 bytes Desc: 2366884796-LINUXLIBC62.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LINUXLIBC62a.gif Type: image/gif Size: 246626 bytes Desc: 225660904-LINUXLIBC62a.gif URL: From hosking at cs.purdue.edu Thu Sep 27 15:38:37 2007 From: hosking at cs.purdue.edu (Antony Hosking) Date: Thu, 27 Sep 2007 09:38:37 -0400 Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <266390.74360.qm@web27112.mail.ukl.yahoo.com> References: <266390.74360.qm@web27112.mail.ukl.yahoo.com> Message-ID: <35BC64D8-6381-43CC-B52A-666F7C2757BC@cs.purdue.edu> In the pthread implementation scheduling is performed by the OS so there is no way to say that any particular thread is *alive*, just that it is eligible to run should the scheduler choose to run it (indeed on an SMP more than one thread can run at a time). The user- thread implementation has its own scheduler, so it knows precisely which thread is running at any point in time. Are you saying there is a bug in the current pthread implementation? If so, then I'd like a more precise characterization that I can pursue and fix. On Sep 27, 2007, at 2:32 AM, Daniel Alejandro Benavides D. wrote: > Hi: > I am testing some examples of Chapter 16 of Laszlo > book, but the text shows me that now the NThreads > example where 10 threads are being showing the IDs (1, > 2, ... ,10). > This is tested on ubuntu Dapper OS, which still allows > the use of user space threads implementation. > Attached are some animated gif files that show in > (sorry have no web page available) > LINUXLIBC6.gif exmaple execution of Systems level > threads > LINUXLIBC62.gif example execution of User space > threads > LINUXLIBC62a.gif example execution of User space > threads after it ends > > Why the different versions of thread implementation > are different, in terms of what showthread shows that > all the threads are "locking" (9 almost all time) and > 2 (the first and third form left to right) are "alive" > in the Pthread case, and why in the user space threads > case they are "alive" green color almost always if > they are not running. > The worst thing is the behaviour of the appication is > very rare, It should be running until a key (enter) is > pressed down; It just runs some seconds in pthread > case. > > Besides why some many objects are shown in shownew > with the user space threaded program. > > The linking information of ldd output is below. > LINUXLIBC6 is current cvs compiled example > LINUXLIBC&2 compiled with user spce threads. > > on LINUXLIBC6 with user space threads, June 9th the > date It was compiled. > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > LINUXLIBC62/NThreads > linux-gate.so.1 => (0xffffe000) > libm3local.so.5 => > /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 > (0xb7faf000) > libm3.so.5 => > /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 > (0xb7e90000) > libm3core.so.5 => > /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > (0xb760f000) > libm3gcdefs.so.5 => > /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > (0xb75d1000) > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > (0xb74a2000) > /lib/ld-linux.so.2 (0xb7fbd000) > > > on LINUXLIBC6 with system threads: > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > LINUXLIBC6/NThreads > linux-gate.so.1 => (0xffffe000) > libm3local.so.5 => > /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 > (0xb7f51000) > libm3.so.5 => > /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 > (0xb7e1e000) > libm3core.so.5 => > /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 > (0xb7592000) > libpthread.so.0 => > /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > (0xb7544000) > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > (0xb7415000) > /lib/ld-linux.so.2 (0xb7f5f000) > > > the source code is this > > MODULE NThreads EXPORTS Main; > (*22.02.95. LB*) > (* Program starts "N" threads which output their ID > and terminate > if a key is pressed (on some systems you have to > press the return > key). > *) > > IMPORT Thread, SIO; > FROM Scheduler IMPORT Yield; > > CONST > N = 10; > TYPE > Threads = [1..N]; > Closure = Thread.Closure OBJECT > id: Threads; > (*identifies thread*) > OVERRIDES > apply:= PrintId; > END; (*Closure*) > > PROCEDURE PrintId(cl: Closure): REFANY = > BEGIN > REPEAT > SIO.PutInt(cl.id); > IF cl.id = LAST(Threads) THEN SIO.Nl() END; > Yield(); > (*yields to other threads*) > UNTIL SIO.Available(); > RETURN NIL; > (*return value not used*) > END PrintId; > > PROCEDURE Fork() = > BEGIN > FOR i:= FIRST(Threads) TO LAST(Threads) - 1 DO > EVAL Thread.Fork(NEW(Closure, id:= i)) > (*N-1 threads are generated*) > END; > EVAL PrintId(NEW(Closure, id:= LAST(Threads))); > (*N-th thread = main*) > END Fork; > > BEGIN > Fork(); > (*start all threads*) > END NThreads. > > > Thanks > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html > > > Antony Hosking | Associate Professor Dept of Computer Sciences | Office: (765) 494-6001 Purdue University | Mobile: (765) 427-5484 250 N. University Street | hosking at cs.purdue.edu West Lafayette, IN 47907-2066 | http://www.cs.purdue.edu/~hosking _--_|\ / \ \_.--._/ ) v / From dabenavidesd at yahoo.es Fri Sep 28 15:08:35 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 28 Sep 2007 15:08:35 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <35BC64D8-6381-43CC-B52A-666F7C2757BC@cs.purdue.edu> Message-ID: <757512.73957.qm@web27111.mail.ukl.yahoo.com> Hi: With @M3noincremental just runs for while 1 2 3 1 2 3 10 5 4 and in this state its like a freezed program, it does not respond to the keyboard input. With @M3nogenerational or @M3nogc runs just fine. What could be the problem? What else could be useful to do? Thanks --- Antony Hosking wrote: > In the pthread implementation scheduling is > performed by the OS so > there is no way to say that any particular thread is > *alive*, just > that it is eligible to run should the scheduler > choose to run it > (indeed on an SMP more than one thread can run at a > time). The user- > thread implementation has its own scheduler, so it > knows precisely > which thread is running at any point in time. > > Are you saying there is a bug in the current pthread > implementation? > If so, then I'd like a more precise characterization > that I can > pursue and fix. > > On Sep 27, 2007, at 2:32 AM, Daniel Alejandro > Benavides D. wrote: > > > Hi: > > I am testing some examples of Chapter 16 of Laszlo > > book, but the text shows me that now the NThreads > > example where 10 threads are being showing the IDs > (1, > > 2, ... ,10). > > This is tested on ubuntu Dapper OS, which still > allows > > the use of user space threads implementation. > > Attached are some animated gif files that show in > > (sorry have no web page available) > > LINUXLIBC6.gif exmaple execution of Systems level > > threads > > LINUXLIBC62.gif example execution of User space > > threads > > LINUXLIBC62a.gif example execution of User space > > threads after it ends > > > > Why the different versions of thread > implementation > > are different, in terms of what showthread shows > that > > all the threads are "locking" (9 almost all time) > and > > 2 (the first and third form left to right) are > "alive" > > in the Pthread case, and why in the user space > threads > > case they are "alive" green color almost always if > > they are not running. > > The worst thing is the behaviour of the appication > is > > very rare, It should be running until a key > (enter) is > > pressed down; It just runs some seconds in pthread > > case. > > > > Besides why some many objects are shown in shownew > > with the user space threaded program. > > > > The linking information of ldd output is below. > > LINUXLIBC6 is current cvs compiled example > > LINUXLIBC&2 compiled with user spce threads. > > > > on LINUXLIBC6 with user space threads, June 9th > the > > date It was compiled. > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > LINUXLIBC62/NThreads > > linux-gate.so.1 => (0xffffe000) > > libm3local.so.5 => > > > /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > (0xb7faf000) > > libm3.so.5 => > > /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 > > (0xb7e90000) > > libm3core.so.5 => > > > /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > (0xb760f000) > > libm3gcdefs.so.5 => > > /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) > > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > > (0xb75d1000) > > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > > (0xb74a2000) > > /lib/ld-linux.so.2 (0xb7fbd000) > > > > > > on LINUXLIBC6 with system threads: > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > LINUXLIBC6/NThreads > > linux-gate.so.1 => (0xffffe000) > > libm3local.so.5 => > > > /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > (0xb7f51000) > > libm3.so.5 => > > > /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 > > (0xb7e1e000) > > libm3core.so.5 => > > > /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > (0xb7592000) > > libpthread.so.0 => > > /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) > > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > > (0xb7544000) > > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > > (0xb7415000) > > /lib/ld-linux.so.2 (0xb7f5f000) > > > > > > the source code is this > > > > MODULE NThreads EXPORTS Main; > > (*22.02.95. LB*) > > (* Program starts "N" threads which output their > ID > > and terminate > > if a key is pressed (on some systems you have > to > > press the return > > key). > > *) > > > > IMPORT Thread, SIO; > > FROM Scheduler IMPORT Yield; > > > > CONST > > N = 10; > > TYPE > > Threads = [1..N]; > > Closure = Thread.Closure OBJECT > > id: Threads; > > (*identifies thread*) > > OVERRIDES > > apply:= PrintId; > > END; (*Closure*) > > > > PROCEDURE PrintId(cl: Closure): REFANY = > > BEGIN > > REPEAT > > SIO.PutInt(cl.id); > > IF cl.id = LAST(Threads) THEN SIO.Nl() END; > > Yield(); > > (*yields to other threads*) > > UNTIL SIO.Available(); > > RETURN NIL; > > (*return value not used*) > > END PrintId; > > > > PROCEDURE Fork() = > > BEGIN > > FOR i:= FIRST(Threads) TO LAST(Threads) - 1 DO > > EVAL Thread.Fork(NEW(Closure, id:= i)) > > (*N-1 threads are generated*) > > END; > > EVAL PrintId(NEW(Closure, id:= > LAST(Threads))); > > (*N-th thread = main*) > > END Fork; > > > > BEGIN > > Fork(); > > (*start all threads*) > > END NThreads. > > > > > > Thanks > > > > > > > > > ______________________________________________________________________ > > > ______________ > > S? un Mejor Amante del Cine > > ?Quieres saber c?mo? ?Deja que otras personas te > ayuden! > > > http://advision.webevents.yahoo.com/reto/entretenimiento.html > > > > > > > > Antony Hosking | Associate Professor > Dept of Computer Sciences | Office: (765) > 494-6001 > Purdue University | Mobile: (765) > 427-5484 > 250 N. University Street | > hosking at cs.purdue.edu > West Lafayette, IN 47907-2066 | > http://www.cs.purdue.edu/~hosking > _--_|\ > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Fri Sep 28 16:30:30 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 28 Sep 2007 16:30:30 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <757512.73957.qm@web27111.mail.ukl.yahoo.com> Message-ID: <860980.52128.qm@web27109.mail.ukl.yahoo.com> Hi: I debugged for a while the program with handle all nostop handle EXC_SOFTWARE stop handle EXC_BREAKPOINT stop getting this: Breakpoint 4, SignalHandler (sig=64, sip=16_b640ff9c, uap=16_b641001c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1254036560 (LWP 8072)] Breakpoint 3, SignalHandler (sig=64, sip=16_b540df8c, uap=16_b540e00c) at ThreadPThread.m3:1184 1184 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1237251152 (LWP 8067)] Breakpoint 3, SignalHandler (sig=64, sip=16_b640ff9c, uap=16_b641001c) at ThreadPThread.m3:1184 1184 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b640ff9c, uap=16_b641001c) at ThreadPThread.m3:1184 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb7505b8c in sched_yield () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7625fce in Yield () at ThreadPThread.m3:712 #5 0x0804b844 in PrintId (cl=16_b741b0a0) at NThreads.m3:25 #6 0xb7624b21 in RunThread (me=16_08054560) at ThreadPThread.m3:540 #7 0xb76247e6 in ThreadBase (param=16_08054560) at ThreadPThread.m3:521 #8 0xb75ad341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #9 0xb751f4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** [Switching to Thread -1228858448 (LWP 8066)] Breakpoint 4, SignalHandler (sig=64, sip=16_b6c10f9c, uap=16_b6c1101c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step Breakpoint 3, SignalHandler (sig=64, sip=16_b6c10f9c, uap=16_b6c1101c) at ThreadPThread.m3:1184 1184 in ThreadPThread.m3 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Program received signal SIG64, Real-time event 64. [Switching to Thread -1220465744 (LWP 8065)] Breakpoint 4, SignalHandler (sig=64, sip=16_b7411f9c, uap=16_b741201c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step 4 4 Program received signal SIGABRT, Aborted. 4Couldn't get registers: No such process. (m3gdb) ----------------------------------------------------- And then without modifying the signal set: (m3gdb) break NThreads.m3:10 Breakpoint 1 at 0x804b934: file NThreads.m3, line 10. (m3gdb) break ThreadPThread.m3:1180 No source file named ThreadPThread.m3. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 2 (ThreadPThread.m3:1180) pending. (m3gdb) run Starting program: /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads [Thread debugging using libthread_db enabled] [New Thread -1220532544 (LWP 8125)] Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, line 1180. Pending breakpoint "ThreadPThread.m3:1180" resolved [Switching to Thread -1220532544 (LWP 8125)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7010) at NThreads.m3:14 warning: Source file is more recent than executable. 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1220805712 (LWP 8131)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7058) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1229198416 (LWP 8132)] 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c70a0) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 1[New Thread -1237591120 (LWP 8133)] 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c70e8) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 2 1[New Thread -1245983824 (LWP 8134)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7130) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 3 2 1[New Thread -1254376528 (LWP 8135)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1254376528 (LWP 8135)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1237591120 (LWP 8133)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1229198416 (LWP 8132)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1220805712 (LWP 8131)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. [Switching to Thread -1254376528 (LWP 8135)] Breakpoint 3, SignalHandler (sig=64, sip=16_b53baf8c, uap=16_b53bb00c) at ThreadPThread.m3:1180 1180 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b53baf8c, uap=16_b53bb00c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb755f3c1 in __lll_mutex_unlock_wake () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb755c2df in _L_mutex_unlock_128 () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb53bb358 in ?? () #6 0xb75cecef in Release (m=16_b75fadf4) at ThreadPThread.m3:186 #7 0xb75cecef in Release (m=16_b73c0004) at ThreadPThread.m3:186 #8 0xb75d1aa9 in RunThread (me=16_08054700) at ThreadPThread.m3:536 #9 0xb75d17e6 in ThreadBase (param=16_08054700) at ThreadPThread.m3:521 #10 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #11 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. [Switching to Thread -1229198416 (LWP 8132)] Breakpoint 3, SignalHandler (sig=64, sip=16_b6bbdf9c, uap=16_b6bbe01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** [Switching to Thread -1237591120 (LWP 8133)] Breakpoint 3, SignalHandler (sig=64, sip=16_b63bcf9c, uap=16_b63bd01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b63bcf9c, uap=16_b63bd01c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb74b2b8c in sched_yield () from /lib/tls/i686/cmov/libc.so.6 #4 0xb75d2fce in Yield () at ThreadPThread.m3:712 #5 0x0804b844 in PrintId (cl=16_b73c70a0) at NThreads.m3:25 #6 0xb75d1b21 in RunThread (me=16_08054560) at ThreadPThread.m3:540 #7 0xb75d17e6 in ThreadBase (param=16_08054560) at ThreadPThread.m3:521 #8 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #9 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed.[Switching to Thread -1220805712 (LWP 8131)] Breakpoint 3, SignalHandler (sig=64, sip=16_b73bef9c, uap=16_b73bf01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b73bef9c, uap=16_b73bf01c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb74b2b8c in sched_yield () from /lib/tls/i686/cmov/libc.so.6 #4 0xb75d2fce in Yield () at ThreadPThread.m3:712 #5 0x0804b844 in PrintId (cl=16_b73c7010) at NThreads.m3:25 #6 0xb75d1b21 in RunThread (me=16_080543c0) at ThreadPThread.m3:540 #7 0xb75d17e6 in ThreadBase (param=16_080543c0) at ThreadPThread.m3:521 #8 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #9 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed. *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Program received signal SIG64, Real-time event 64. [Switching to Thread -1220532544 (LWP 8125)] 0xffffe410 in __kernel_vsyscall () (m3gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb755cc76 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb75d5ae0 in LockHeap () at ThreadPThread.m3:1370 #3 0xb75a13ca in GetUntracedRef (def=16_b75faf38) at RTAllocator.m3:240 #4 0xb75a0b4a in AllocateUntracedRef (defn=16_b75faf38) at RTAllocator.m3:146 #5 0xb75d2003 in Fork (closure=16_b73c7178) at ThreadPThread.m3:575 #6 0x0804b8b6 in Fork () at NThreads.m3:33 #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 #8 0xb75ba87a in RunMainBody (m=16_0804dc60) at RTLinker.m3:399 #9 0xb75b9174 in AddUnitI (m=16_0804dc60) at RTLinker.m3:113 #10 0xb75b920b in AddUnit (b={"NThreads_M3", Declared at: NThreads.m3:38}) at RTLinker.m3:122 #11 0x08048ea8 in main (argc=1, argv=0xbf860fd4, envp=0xbf860fdc) at _m3main.mc:4 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Breakpoint 3, SignalHandler (sig=64, sip=16_bf8607fc, uap=16_bf86087c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_bf8607fc, uap=16_bf86087c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb755cc76 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb75d5ae0 in LockHeap () at ThreadPThread.m3:1370 #5 0xb75a13ca in GetUntracedRef (def=16_b75faf38) at RTAllocator.m3:240 #6 0xb75a0b4a in AllocateUntracedRef (defn=16_b75faf38) at RTAllocator.m3:146 #7 0xb75d2003 in Fork (closure=16_b73c7178) at ThreadPThread.m3:575 #8 0x0804b8b6 in Fork () at NThreads.m3:33 #9 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 #10 0xb75ba87a in RunMainBody (m=16_0804dc60) at RTLinker.m3:399 #11 0xb75b9174 in AddUnitI (m=16_0804dc60) at RTLinker.m3:113 #12 0xb75b920b in AddUnit (b={"NThreads_M3", Declared at: NThreads.m3:38}) at RTLinker.m3:122 #13 0x08048ea8 in main (argc=1, argv=0xbf860fd4, envp=0xbf860fdc) at _m3main.mc:4 (m3gdb) cont Continuing. 4 Program received signal SIGABRT, Aborted. [Switching to Thread -1254376528 (LWP 8135)] 0xffffe410 in __kernel_vsyscall () (m3gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb742b9a1 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb742d2b9 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb75cb72f in Crash () at RTOS.m3:20 #4 0xb75be204 in Crash (msg=NIL) at RTProcess.m3:65 #5 0xb75bb965 in EndError (crash=TRUE) at RTError.m3:115 #6 0xb75bb61a in MsgS (file=16_b75fabf8, line=1184, msgA=16_b75f4e08, msgB=16_b75ef3b0, msgC=16_b75f4e08) at RTError.m3:40 #7 0xb75bbdf2 in Crash (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE, rte=16_b75ef260) at RTException.m3:79 #8 0xb75bbaee in DefaultBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:39 #9 0xb75bba33 in InvokeBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:25 #10 0xb75ccfa8 in Raise (act= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END) at RTExFrame.m3:29 #11 0xb75bbb8e in DefaultBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:47 #12 0xb75bba33 in InvokeBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:25 #13 0xb75ccfa8 in Raise (act= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END) at RTExFrame.m3:29 #14 0xb759fcff in ReportFault (module=16_b75fadc0, info=37888) at RTHooks.m3:110 #15 0xb75d62de in _m3_fault (arg=37888) from /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 #16 0xb75d4e8e in SignalHandler (sig=64, sip=16_b53baf8c, uap=16_b53bb00c) at ThreadPThread.m3:1184 #17 #18 0xffffe410 in __kernel_vsyscall () #19 0xb755f3c1 in __lll_mutex_unlock_wake () from /lib/tls/i686/cmov/libpthread.so.0 #20 0xb755c2df in _L_mutex_unlock_128 () from /lib/tls/i686/cmov/libpthread.so.0 #21 0xb53bb358 in ?? () ---Type to continue, or q to quit--- #22 0xb75cecef in Release (m=16_b75fadf4) at ThreadPThread.m3:186 #23 0xb75cecef in Release (m=16_b73c0004) at ThreadPThread.m3:186 #24 0xb75d1aa9 in RunThread (me=16_08054700) at ThreadPThread.m3:536 #25 0xb75d17e6 in ThreadBase (param=16_08054700) at ThreadPThread.m3:521 #26 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #27 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. 4Couldn't get registers: No such process. (m3gdb) Thanks --- "Daniel Alejandro Benavides D." wrote: > Hi: > With @M3noincremental just runs for while > > 1 2 3 1 2 3 10 > 5 4 > > and in this state its like a freezed program, it > does > not respond to the keyboard input. > > With @M3nogenerational or @M3nogc runs just fine. > > What could be the problem? What else could be useful > to do? > > Thanks > > --- Antony Hosking wrote: > > > In the pthread implementation scheduling is > > performed by the OS so > > there is no way to say that any particular thread > is > > *alive*, just > > that it is eligible to run should the scheduler > > choose to run it > > (indeed on an SMP more than one thread can run at > a > > time). The user- > > thread implementation has its own scheduler, so it > > knows precisely > > which thread is running at any point in time. > > > > Are you saying there is a bug in the current > pthread > > implementation? > > If so, then I'd like a more precise > characterization > > that I can > > pursue and fix. > > > > On Sep 27, 2007, at 2:32 AM, Daniel Alejandro > > Benavides D. wrote: > > > > > Hi: > > > I am testing some examples of Chapter 16 of > Laszlo > > > book, but the text shows me that now the > NThreads > > > example where 10 threads are being showing the > IDs > > (1, > > > 2, ... ,10). > > > This is tested on ubuntu Dapper OS, which still > > allows > > > the use of user space threads implementation. > > > Attached are some animated gif files that show > in > > > (sorry have no web page available) > > > LINUXLIBC6.gif exmaple execution of Systems > level > > > threads > > > LINUXLIBC62.gif example execution of User space > > > threads > > > LINUXLIBC62a.gif example execution of User space > > > threads after it ends > > > > > > Why the different versions of thread > > implementation > > > are different, in terms of what showthread shows > > that > > > all the threads are "locking" (9 almost all > time) > > and > > > 2 (the first and third form left to right) are > > "alive" > > > in the Pthread case, and why in the user space > > threads > > > case they are "alive" green color almost always > if > > > they are not running. > > > The worst thing is the behaviour of the > appication > > is > > > very rare, It should be running until a key > > (enter) is > > > pressed down; It just runs some seconds in > pthread > > > case. > > > > > > Besides why some many objects are shown in > shownew > > > with the user space threaded program. > > > > > > The linking information of ldd output is below. > > > LINUXLIBC6 is current cvs compiled example > > > LINUXLIBC&2 compiled with user spce threads. > > > > > > on LINUXLIBC6 with user space threads, June 9th > > the > > > date It was compiled. > > > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > > LINUXLIBC62/NThreads > > > linux-gate.so.1 => (0xffffe000) > > > libm3local.so.5 => > > > > > > /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > > (0xb7faf000) > > > libm3.so.5 => > > > /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 > > > (0xb7e90000) > > > libm3core.so.5 => > > > > > > /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > > (0xb760f000) > > > libm3gcdefs.so.5 => > > > /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) > > > libm.so.6 => > /lib/tls/i686/cmov/libm.so.6 > > > (0xb75d1000) > > > libc.so.6 => > /lib/tls/i686/cmov/libc.so.6 > > > (0xb74a2000) > > > /lib/ld-linux.so.2 (0xb7fbd000) > > > > > > > > > on LINUXLIBC6 with system threads: > > > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > > LINUXLIBC6/NThreads > > > linux-gate.so.1 => (0xffffe000) > > > libm3local.so.5 => > > > > > > /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > > (0xb7f51000) > > > libm3.so.5 => > > > > > > /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 > > > (0xb7e1e000) > > > libm3core.so.5 => > > > > > > /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > > (0xb7592000) > > > libpthread.so.0 => > > > /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) > > > libm.so.6 => > /lib/tls/i686/cmov/libm.so.6 > > > (0xb7544000) > > > libc.so.6 => > /lib/tls/i686/cmov/libc.so.6 > > > (0xb7415000) > > > /lib/ld-linux.so.2 (0xb7f5f000) > > > > > > > > > the source code is this > > > > > > MODULE NThreads EXPORTS Main; > > > (*22.02.95. LB*) > > > (* Program starts "N" threads which output their > > ID > > > and terminate > > > if a key is pressed (on some systems you have > > to > > > press the return > > > key). > > > *) > > > > > > IMPORT Thread, SIO; > > > FROM Scheduler IMPORT Yield; > > > > > > CONST > > > N = 10; > > > TYPE > > > Threads = [1..N]; > > > Closure = Thread.Closure OBJECT > > > id: Threads; > > > (*identifies thread*) > > > OVERRIDES > > > apply:= PrintId; > > > END; (*Closure*) > > > > > > PROCEDURE PrintId(cl: Closure): REFANY = > > > BEGIN > > > REPEAT > > > SIO.PutInt(cl.id); > > > IF cl.id = LAST(Threads) THEN SIO.Nl() > END; > > > Yield(); > > > (*yields to other threads*) > > > UNTIL SIO.Available(); > > > RETURN NIL; > > > (*return value not used*) > > > END PrintId; > > > > > > PROCEDURE Fork() = > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Fri Sep 28 17:02:59 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 28 Sep 2007 17:02:59 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <860980.52128.qm@web27109.mail.ukl.yahoo.com> Message-ID: <532140.63470.qm@web27105.mail.ukl.yahoo.com> Hi: I would like to know if it is necessary to turn down the garbage collection to debug a M3 program. I know running a program inside gdb in general could cause some runtime diferences withj normal execution, like the cout<< in C++, which is reliable under debugging conditions, but not in normal execution conditions in a program which calls it constantly (that happened me on 2005), so one can note that the behaviour would be better on debug conditions, thats why I think this is not maybe the problem on NThreads program (is easy to say that if we think that the runtime errors showed inside m3gdb are not present when the program executes normally), tough I debugged one more time to show other backtraces: (m3gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads Error in re-setting breakpoint 3: No source file named ThreadPThread.m3. Error in re-setting breakpoint 3: No source file named ThreadPThread.m3. Error in re-setting breakpoint 3: No source file named ThreadPThread.m3. Breakpoint 3 at 0xb7654dba: file ThreadPThread.m3, line 1180. [Thread debugging using libthread_db enabled] [New Thread -1220008256 (LWP 8474)] [Switching to Thread -1220008256 (LWP 8474)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447010) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1220281424 (LWP 8495)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447058) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1228674128 (LWP 8496)] 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb74470a0) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 1[New Thread -1237066832 (LWP 8497)] 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb74470e8) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 2 1[New Thread -1245459536 (LWP 8498)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447130) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 3 2 1[New Thread -1253852240 (LWP 8499)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1253852240 (LWP 8499)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. [Switching to Thread -1220008256 (LWP 8474)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1237066832 (LWP 8497)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1228674128 (LWP 8496)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1220281424 (LWP 8495)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. [Switching to Thread -1253852240 (LWP 8499)] Breakpoint 3, SignalHandler (sig=64, sip=16_b543af8c, uap=16_b543b00c) at ThreadPThread.m3:1180 1180 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b543af8c, uap=16_b543b00c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb75df3c1 in __lll_mutex_unlock_wake () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb75dc2df in _L_mutex_unlock_128 () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb543b358 in ?? () #6 0xb764ecef in Release (m=16_b767adf4) at ThreadPThread.m3:186 #7 0xb764ecef in Release (m=16_b7440004) at ThreadPThread.m3:186 #8 0xb7651aa9 in RunThread (me=16_08054700) at ThreadPThread.m3:536 #9 0xb76517e6 in ThreadBase (param=16_08054700) at ThreadPThread.m3:521 #10 0xb75da341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #11 0xb754c4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) step 1181 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1237066832 (LWP 8497)] Breakpoint 3, SignalHandler (sig=64, sip=16_b643cf9c, uap=16_b643d01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1228674128 (LWP 8496)] Breakpoint 3, SignalHandler (sig=64, sip=16_b6c3df9c, uap=16_b6c3e01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1220281424 (LWP 8495)] Breakpoint 3, SignalHandler (sig=64, sip=16_b743ef9c, uap=16_b743f01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Program received signal SIG64, Real-time event 64. [Switching to Thread -1220008256 (LWP 8474)] 0xffffe410 in __kernel_vsyscall () (m3gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb75dcc76 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7655ae0 in LockHeap () at ThreadPThread.m3:1370 #3 0xb76213ca in GetUntracedRef (def=16_b767af38) at RTAllocator.m3:240 #4 0xb7620b4a in AllocateUntracedRef (defn=16_b767af38) at RTAllocator.m3:146 #5 0xb7652003 in Fork (closure=16_b7447178) at ThreadPThread.m3:575 #6 0x0804b8b6 in Fork () at NThreads.m3:33 #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 #8 0xb763a87a in RunMainBody (m=16_0804dc60) at RTLinker.m3:399 #9 0xb7639174 in AddUnitI (m=16_0804dc60) at RTLinker.m3:113 #10 0xb763920b in AddUnit (b={"NThreads_M3", Declared at: NThreads.m3:38}) at RTLinker.m3:122 #11 0x08048ea8 in main (argc=1, argv=0xbfce0c04, envp=0xbfce0c0c) at _m3main.mc:4 (m3gdb) step Single stepping until exit from function __kernel_vsyscall, which has no line number information. SignalHandler (sig=64, sip=16_bfce042c, uap=16_bfce04ac) at ThreadPThread.m3:1157 1157 in ThreadPThread.m3 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** 1161 in ThreadPThread.m3 (m3gdb) step m3_Cerrno_GetErrno () at ../src/C/Common/CerrnoC.c:10 10 ../src/C/Common/CerrnoC.c: No such file or directory. in ../src/C/Common/CerrnoC.c Current language: auto; currently c (m3gdb) step 11 in ../src/C/Common/CerrnoC.c (m3gdb) step SignalHandler (sig=64, sip=16_bfce042c, uap=16_bfce04ac) at ThreadPThread.m3:1163 1163 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 Current language: auto; currently Modula-3 (m3gdb) step GetActivation () at ThreadPThread.m3:368 368 in ThreadPThread.m3 (m3gdb) step 369 in ThreadPThread.m3 (m3gdb) step SignalHandler (sig=64, sip=16_bfce042c, uap=16_bfce04ac) at ThreadPThread.m3:1166 1166 in ThreadPThread.m3 (m3gdb) step 1167 in ThreadPThread.m3 (m3gdb) step 1168 in ThreadPThread.m3 (m3gdb) step 1169 in ThreadPThread.m3 (m3gdb) step 1172 in ThreadPThread.m3 (m3gdb) step 1174 in ThreadPThread.m3 (m3gdb) step 1175 in ThreadPThread.m3 (m3gdb) step 1178 in ThreadPThread.m3 (m3gdb) step 4 4 4 4 4 4 Program received signal SIGABRT, Aborted. [Switching to Thread -1237066832 (LWP 8497)] 0xffffe410 in __kernel_vsyscall () (m3gdb) step Single stepping until exit from function __kernel_vsyscall, Thanks --- "Daniel Alejandro Benavides D." wrote: > Hi: > > I debugged for a while the program with > handle all nostop > handle EXC_SOFTWARE stop > handle EXC_BREAKPOINT stop > > getting this: > > Breakpoint 4, SignalHandler (sig=64, > sip=16_b640ff9c, > uap=16_b641001c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1254036560 (LWP 8072)] > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b540df8c, > uap=16_b540e00c) at ThreadPThread.m3:1184 > 1184 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1237251152 (LWP 8067)] > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b640ff9c, > uap=16_b641001c) at ThreadPThread.m3:1184 > 1184 in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b640ff9c, > uap=16_b641001c) at ThreadPThread.m3:1184 > #1 > #2 0xffffe410 in __kernel_vsyscall () > #3 0xb7505b8c in sched_yield () from > /lib/tls/i686/cmov/libc.so.6 > #4 0xb7625fce in Yield () at ThreadPThread.m3:712 > #5 0x0804b844 in PrintId (cl=16_b741b0a0) at > NThreads.m3:25 > #6 0xb7624b21 in RunThread (me=16_08054560) at > ThreadPThread.m3:540 > #7 0xb76247e6 in ThreadBase (param=16_08054560) at > ThreadPThread.m3:521 > #8 0xb75ad341 in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #9 0xb751f4ee in clone () from > /lib/tls/i686/cmov/libc.so.6 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file > "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > [Switching to Thread -1228858448 (LWP 8066)] > > Breakpoint 4, SignalHandler (sig=64, > sip=16_b6c10f9c, > uap=16_b6c1101c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b6c10f9c, > uap=16_b6c1101c) at ThreadPThread.m3:1184 > 1184 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file > "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220465744 (LWP 8065)] > > Breakpoint 4, SignalHandler (sig=64, > sip=16_b7411f9c, > uap=16_b741201c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > 4 4 > Program received signal SIGABRT, Aborted. > 4Couldn't get registers: No such process. > (m3gdb) > ----------------------------------------------------- > And then without modifying the signal set: > > (m3gdb) break NThreads.m3:10 > Breakpoint 1 at 0x804b934: file NThreads.m3, line > 10. > (m3gdb) break ThreadPThread.m3:1180 > No source file named ThreadPThread.m3. > Make breakpoint pending on future shared library > load? > (y or [n]) y > Breakpoint 2 (ThreadPThread.m3:1180) pending. > (m3gdb) run > Starting program: > /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads > [Thread debugging using libthread_db enabled] > [New Thread -1220532544 (LWP 8125)] > Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, > line 1180. > Pending breakpoint "ThreadPThread.m3:1180" resolved > [Switching to Thread -1220532544 (LWP 8125)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7010) at NThreads.m3:14 > warning: Source file is more recent than executable. > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1220805712 (LWP 8131)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7058) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1229198416 (LWP 8132)] > 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c70a0) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 1[New Thread -1237591120 (LWP 8133)] > 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c70e8) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 2 1[New Thread -1245983824 (LWP 8134)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7130) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 3 2 1[New Thread -1254376528 (LWP 8135)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at > NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1254376528 (LWP 8135)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1237591120 (LWP 8133)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1229198416 (LWP 8132)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220805712 (LWP 8131)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1254376528 (LWP 8135)] > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b53baf8c, > uap=16_b53bb00c) at ThreadPThread.m3:1180 > 1180 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b53baf8c, > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 28 17:35:25 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Sep 2007 11:35:25 -0400 Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <532140.63470.qm@web27105.mail.ukl.yahoo.com> References: <532140.63470.qm@web27105.mail.ukl.yahoo.com> Message-ID: On Sep 28, 2007, at 11:02 AM, Daniel Alejandro Benavides D. wrote: > Hi: > I would like to know if it is necessary to turn down > the garbage collection to debug a M3 program. > I know running a program inside gdb in general could > cause some runtime diferences withj normal execution, > like the cout<< in C++, which is reliable under > debugging conditions, but not in normal execution > conditions in a program which calls it constantly > (that happened me on 2005), so one can note that the > behaviour would be better on debug conditions, thats > why I think this is not maybe the problem on NThreads > program (is easy to say that if we think that the > runtime errors showed inside m3gdb are not present > when the program executes normally), tough I debugged > one more time to show other backtraces: Debugging with GC enabled should be fine, except that you will not necessarily see the same non-deterministic behavior as when it runs outside the debugger. Regarding the assert that is failing, that indicates that sigwait is returning an error, which seems odd. I will try this program on my own Linux system. > > (m3gdb) run > The program being debugged has been started already. > Start it from the beginning? (y or n) y > Starting program: > /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Breakpoint 3 at 0xb7654dba: file ThreadPThread.m3, > line 1180. > [Thread debugging using libthread_db enabled] > [New Thread -1220008256 (LWP 8474)] > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447010) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1220281424 (LWP 8495)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447058) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1228674128 (LWP 8496)] > 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470a0) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 1[New Thread -1237066832 (LWP 8497)] > 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470e8) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 2 1[New Thread -1245459536 (LWP 8498)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447130) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 3 2 1[New Thread -1253852240 (LWP 8499)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at > NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1253852240 (LWP 8499)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1228674128 (LWP 8496)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220281424 (LWP 8495)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1253852240 (LWP 8499)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > 1180 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > #1 > #2 0xffffe410 in __kernel_vsyscall () > #3 0xb75df3c1 in __lll_mutex_unlock_wake () from > /lib/tls/i686/cmov/libpthread.so.0 > #4 0xb75dc2df in _L_mutex_unlock_128 () from > /lib/tls/i686/cmov/libpthread.so.0 > #5 0xb543b358 in ?? () > #6 0xb764ecef in Release (m=16_b767adf4) at > ThreadPThread.m3:186 > #7 0xb764ecef in Release (m=16_b7440004) at > ThreadPThread.m3:186 > #8 0xb7651aa9 in RunThread (me=16_08054700) at > ThreadPThread.m3:536 > #9 0xb76517e6 in ThreadBase (param=16_08054700) at > ThreadPThread.m3:521 > #10 0xb75da341 in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #11 0xb754c4ee in clone () from > /lib/tls/i686/cmov/libc.so.6 > (m3gdb) step > 1181 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1237066832 (LWP 8497)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b643cf9c, > uap=16_b643d01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1228674128 (LWP 8496)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b6c3df9c, > uap=16_b6c3e01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1220281424 (LWP 8495)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b743ef9c, > uap=16_b743f01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220008256 (LWP 8474)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) where > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb75dcc76 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/tls/i686/cmov/libpthread.so.0 > #2 0xb7655ae0 in LockHeap () at ThreadPThread.m3:1370 > #3 0xb76213ca in GetUntracedRef (def=16_b767af38) at > RTAllocator.m3:240 > #4 0xb7620b4a in AllocateUntracedRef > (defn=16_b767af38) at RTAllocator.m3:146 > #5 0xb7652003 in Fork (closure=16_b7447178) at > ThreadPThread.m3:575 > #6 0x0804b8b6 in Fork () at NThreads.m3:33 > #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 > #8 0xb763a87a in RunMainBody (m=16_0804dc60) at > RTLinker.m3:399 > #9 0xb7639174 in AddUnitI (m=16_0804dc60) at > RTLinker.m3:113 > #10 0xb763920b in AddUnit (b={"NThreads_M3", Declared > at: NThreads.m3:38}) at RTLinker.m3:122 > #11 0x08048ea8 in main (argc=1, argv=0xbfce0c04, > envp=0xbfce0c0c) at _m3main.mc:4 > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > which has no line number information. > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1157 > 1157 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > 1161 in ThreadPThread.m3 > (m3gdb) step > m3_Cerrno_GetErrno () at ../src/C/Common/CerrnoC.c:10 > 10 ../src/C/Common/CerrnoC.c: No such file or > directory. > in ../src/C/Common/CerrnoC.c > Current language: auto; currently c > (m3gdb) step > 11 in ../src/C/Common/CerrnoC.c > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1163 > 1163 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > Current language: auto; currently Modula-3 > (m3gdb) step > GetActivation () at ThreadPThread.m3:368 > 368 in ThreadPThread.m3 > (m3gdb) step > 369 in ThreadPThread.m3 > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1166 > 1166 in ThreadPThread.m3 > (m3gdb) step > 1167 in ThreadPThread.m3 > (m3gdb) step > 1168 in ThreadPThread.m3 > (m3gdb) step > 1169 in ThreadPThread.m3 > (m3gdb) step > 1172 in ThreadPThread.m3 > (m3gdb) step > 1174 in ThreadPThread.m3 > (m3gdb) step > 1175 in ThreadPThread.m3 > (m3gdb) step > 1178 in ThreadPThread.m3 > (m3gdb) step > 4 4 4 4 4 4 > Program received signal SIGABRT, Aborted. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > > Thanks > > --- "Daniel Alejandro Benavides D." > wrote: > >> Hi: >> >> I debugged for a while the program with >> handle all nostop >> handle EXC_SOFTWARE stop >> handle EXC_BREAKPOINT stop >> >> getting this: >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1254036560 (LWP 8072)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b540df8c, >> uap=16_b540e00c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1237251152 (LWP 8067)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> #1 >> #2 0xffffe410 in __kernel_vsyscall () >> #3 0xb7505b8c in sched_yield () from >> /lib/tls/i686/cmov/libc.so.6 >> #4 0xb7625fce in Yield () at ThreadPThread.m3:712 >> #5 0x0804b844 in PrintId (cl=16_b741b0a0) at >> NThreads.m3:25 >> #6 0xb7624b21 in RunThread (me=16_08054560) at >> ThreadPThread.m3:540 >> #7 0xb76247e6 in ThreadBase (param=16_08054560) at >> ThreadPThread.m3:521 >> #8 0xb75ad341 in start_thread () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #9 0xb751f4ee in clone () from >> /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> [Switching to Thread -1228858448 (LWP 8066)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220465744 (LWP 8065)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b7411f9c, >> uap=16_b741201c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> 4 4 >> Program received signal SIGABRT, Aborted. >> 4Couldn't get registers: No such process. >> (m3gdb) >> > ----------------------------------------------------- >> And then without modifying the signal set: >> >> (m3gdb) break NThreads.m3:10 >> Breakpoint 1 at 0x804b934: file NThreads.m3, line >> 10. >> (m3gdb) break ThreadPThread.m3:1180 >> No source file named ThreadPThread.m3. >> Make breakpoint pending on future shared library >> load? >> (y or [n]) y >> Breakpoint 2 (ThreadPThread.m3:1180) pending. >> (m3gdb) run >> Starting program: >> /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads >> [Thread debugging using libthread_db enabled] >> [New Thread -1220532544 (LWP 8125)] >> Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, >> line 1180. >> Pending breakpoint "ThreadPThread.m3:1180" resolved >> [Switching to Thread -1220532544 (LWP 8125)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7010) at NThreads.m3:14 >> warning: Source file is more recent than executable. >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1220805712 (LWP 8131)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7058) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1229198416 (LWP 8132)] >> 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70a0) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 1[New Thread -1237591120 (LWP 8133)] >> 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70e8) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 2 1[New Thread -1245983824 (LWP 8134)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7130) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 3 2 1[New Thread -1254376528 (LWP 8135)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at >> NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1254376528 (LWP 8135)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1237591120 (LWP 8133)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1229198416 (LWP 8132)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220805712 (LWP 8131)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> [Switching to Thread -1254376528 (LWP 8135)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b53baf8c, >> uap=16_b53bb00c) at ThreadPThread.m3:1180 >> 1180 ThreadPThread.m3: No such file or directory. >> in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b53baf8c, >> > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 28 19:40:22 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Sep 2007 13:40:22 -0400 Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <532140.63470.qm@web27105.mail.ukl.yahoo.com> References: <532140.63470.qm@web27105.mail.ukl.yahoo.com> Message-ID: <11736B53-EB34-4501-ABAF-496CE88C9170@cs.purdue.edu> The nthreads program runs just fine on my Fedora Core system (modulo unpredictable scheduling which is to be expected for a program running with system threads). I wonder if the problems you are seeing come from an old version (non-NPTL) of libpthread on your Linux system? I have glibc 2.5.18. On Sep 28, 2007, at 11:02 AM, Daniel Alejandro Benavides D. wrote: > Hi: > I would like to know if it is necessary to turn down > the garbage collection to debug a M3 program. > I know running a program inside gdb in general could > cause some runtime diferences withj normal execution, > like the cout<< in C++, which is reliable under > debugging conditions, but not in normal execution > conditions in a program which calls it constantly > (that happened me on 2005), so one can note that the > behaviour would be better on debug conditions, thats > why I think this is not maybe the problem on NThreads > program (is easy to say that if we think that the > runtime errors showed inside m3gdb are not present > when the program executes normally), tough I debugged > one more time to show other backtraces: > > (m3gdb) run > The program being debugged has been started already. > Start it from the beginning? (y or n) y > Starting program: > /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Breakpoint 3 at 0xb7654dba: file ThreadPThread.m3, > line 1180. > [Thread debugging using libthread_db enabled] > [New Thread -1220008256 (LWP 8474)] > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447010) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1220281424 (LWP 8495)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447058) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1228674128 (LWP 8496)] > 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470a0) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 1[New Thread -1237066832 (LWP 8497)] > 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470e8) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 2 1[New Thread -1245459536 (LWP 8498)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447130) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 3 2 1[New Thread -1253852240 (LWP 8499)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at > NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1253852240 (LWP 8499)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1228674128 (LWP 8496)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220281424 (LWP 8495)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1253852240 (LWP 8499)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > 1180 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > #1 > #2 0xffffe410 in __kernel_vsyscall () > #3 0xb75df3c1 in __lll_mutex_unlock_wake () from > /lib/tls/i686/cmov/libpthread.so.0 > #4 0xb75dc2df in _L_mutex_unlock_128 () from > /lib/tls/i686/cmov/libpthread.so.0 > #5 0xb543b358 in ?? () > #6 0xb764ecef in Release (m=16_b767adf4) at > ThreadPThread.m3:186 > #7 0xb764ecef in Release (m=16_b7440004) at > ThreadPThread.m3:186 > #8 0xb7651aa9 in RunThread (me=16_08054700) at > ThreadPThread.m3:536 > #9 0xb76517e6 in ThreadBase (param=16_08054700) at > ThreadPThread.m3:521 > #10 0xb75da341 in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #11 0xb754c4ee in clone () from > /lib/tls/i686/cmov/libc.so.6 > (m3gdb) step > 1181 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1237066832 (LWP 8497)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b643cf9c, > uap=16_b643d01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1228674128 (LWP 8496)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b6c3df9c, > uap=16_b6c3e01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1220281424 (LWP 8495)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b743ef9c, > uap=16_b743f01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220008256 (LWP 8474)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) where > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb75dcc76 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/tls/i686/cmov/libpthread.so.0 > #2 0xb7655ae0 in LockHeap () at ThreadPThread.m3:1370 > #3 0xb76213ca in GetUntracedRef (def=16_b767af38) at > RTAllocator.m3:240 > #4 0xb7620b4a in AllocateUntracedRef > (defn=16_b767af38) at RTAllocator.m3:146 > #5 0xb7652003 in Fork (closure=16_b7447178) at > ThreadPThread.m3:575 > #6 0x0804b8b6 in Fork () at NThreads.m3:33 > #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 > #8 0xb763a87a in RunMainBody (m=16_0804dc60) at > RTLinker.m3:399 > #9 0xb7639174 in AddUnitI (m=16_0804dc60) at > RTLinker.m3:113 > #10 0xb763920b in AddUnit (b={"NThreads_M3", Declared > at: NThreads.m3:38}) at RTLinker.m3:122 > #11 0x08048ea8 in main (argc=1, argv=0xbfce0c04, > envp=0xbfce0c0c) at _m3main.mc:4 > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > which has no line number information. > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1157 > 1157 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > 1161 in ThreadPThread.m3 > (m3gdb) step > m3_Cerrno_GetErrno () at ../src/C/Common/CerrnoC.c:10 > 10 ../src/C/Common/CerrnoC.c: No such file or > directory. > in ../src/C/Common/CerrnoC.c > Current language: auto; currently c > (m3gdb) step > 11 in ../src/C/Common/CerrnoC.c > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1163 > 1163 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > Current language: auto; currently Modula-3 > (m3gdb) step > GetActivation () at ThreadPThread.m3:368 > 368 in ThreadPThread.m3 > (m3gdb) step > 369 in ThreadPThread.m3 > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1166 > 1166 in ThreadPThread.m3 > (m3gdb) step > 1167 in ThreadPThread.m3 > (m3gdb) step > 1168 in ThreadPThread.m3 > (m3gdb) step > 1169 in ThreadPThread.m3 > (m3gdb) step > 1172 in ThreadPThread.m3 > (m3gdb) step > 1174 in ThreadPThread.m3 > (m3gdb) step > 1175 in ThreadPThread.m3 > (m3gdb) step > 1178 in ThreadPThread.m3 > (m3gdb) step > 4 4 4 4 4 4 > Program received signal SIGABRT, Aborted. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > > Thanks > > --- "Daniel Alejandro Benavides D." > wrote: > >> Hi: >> >> I debugged for a while the program with >> handle all nostop >> handle EXC_SOFTWARE stop >> handle EXC_BREAKPOINT stop >> >> getting this: >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1254036560 (LWP 8072)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b540df8c, >> uap=16_b540e00c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1237251152 (LWP 8067)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> #1 >> #2 0xffffe410 in __kernel_vsyscall () >> #3 0xb7505b8c in sched_yield () from >> /lib/tls/i686/cmov/libc.so.6 >> #4 0xb7625fce in Yield () at ThreadPThread.m3:712 >> #5 0x0804b844 in PrintId (cl=16_b741b0a0) at >> NThreads.m3:25 >> #6 0xb7624b21 in RunThread (me=16_08054560) at >> ThreadPThread.m3:540 >> #7 0xb76247e6 in ThreadBase (param=16_08054560) at >> ThreadPThread.m3:521 >> #8 0xb75ad341 in start_thread () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #9 0xb751f4ee in clone () from >> /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> [Switching to Thread -1228858448 (LWP 8066)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220465744 (LWP 8065)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b7411f9c, >> uap=16_b741201c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> 4 4 >> Program received signal SIGABRT, Aborted. >> 4Couldn't get registers: No such process. >> (m3gdb) >> > ----------------------------------------------------- >> And then without modifying the signal set: >> >> (m3gdb) break NThreads.m3:10 >> Breakpoint 1 at 0x804b934: file NThreads.m3, line >> 10. >> (m3gdb) break ThreadPThread.m3:1180 >> No source file named ThreadPThread.m3. >> Make breakpoint pending on future shared library >> load? >> (y or [n]) y >> Breakpoint 2 (ThreadPThread.m3:1180) pending. >> (m3gdb) run >> Starting program: >> /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads >> [Thread debugging using libthread_db enabled] >> [New Thread -1220532544 (LWP 8125)] >> Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, >> line 1180. >> Pending breakpoint "ThreadPThread.m3:1180" resolved >> [Switching to Thread -1220532544 (LWP 8125)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7010) at NThreads.m3:14 >> warning: Source file is more recent than executable. >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1220805712 (LWP 8131)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7058) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1229198416 (LWP 8132)] >> 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70a0) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 1[New Thread -1237591120 (LWP 8133)] >> 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70e8) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 2 1[New Thread -1245983824 (LWP 8134)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7130) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 3 2 1[New Thread -1254376528 (LWP 8135)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at >> NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1254376528 (LWP 8135)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1237591120 (LWP 8133)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1229198416 (LWP 8132)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220805712 (LWP 8131)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> [Switching to Thread -1254376528 (LWP 8135)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b53baf8c, >> uap=16_b53bb00c) at ThreadPThread.m3:1180 >> 1180 ThreadPThread.m3: No such file or directory. >> in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b53baf8c, >> > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 28 19:59:32 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Sep 2007 13:59:32 -0400 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> <1B153BC7-A186-4F33-A019-91ADFEEC97FD@cs.purdue.edu> <90E9CEA8-6406-44E1-8265-9188B51B850D@cs.purdue.edu> Message-ID: <2559758D-5DE9-4CAF-B9D1-77F851B6310B@cs.purdue.edu> I forget if we tried the "paranoid" GC configuration or not. Can you run with @M3paranoidgc and see what happens? Again, I am unable to replicate the problems you are seeing, even on my Solaris 10 box. On Sep 26, 2007, at 2:03 PM, Alex Bochannek wrote: > I am back from vacation. I just updated my cm3 tree and did the usual > "do-cm3-core buildship; install-cm3-compiler upgrade; do-cm3-std > buildship" dance. I then did a make clean on cvsup and a make install. > > I not get reproducible core dumps every time I run it, with or without > GUI. cvsup startes and then cores: > > > -bash-3.00$ cvsup -g cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x51e9782c > *** > > Abort (core dumped) > -bash-3.00$ mdb core > $c > libc.so.1`_lwp_kill+8(6, 0, feea4af8, ffffffff, feee8284, 6) > libc.so.1`abort+0x110(fec1eeb0, 1, 48c988, a8390, feeeb298, 0) > RTOS__Crash+4(1, 1d, df7fb0, e09fa0, 533dbc, 0) > RTProcess__Crash+0x98(0, a, 10, 0, 0, 0) > RTError__EndError+0x58(1, fec1f20c, fec1f210, fec1f214, 0, 0) > RTError__ErrorPC+0x1d8(51e9782c, 531bbc, 0, 0, 1, 0) > RTError__MsgPC+0x38(51e9782c, 531bbc, 0, 0, 0, 0) > RTSignal__SegV+0x68(b, fec1f730, fec1f478, 1, 0, 1) > libc.so.1`__sighndlr+0xc(b, fec1f730, fec1f478, 44381c, 0, 1) > libc.so.1`call_user_handler+0x3b8(b, 0, 8, 0, fed11800, fec1f478) > 0x51e9782c(feba49b0, 2f, 7fffffff, 0, 0, 0) > SupMisc__PathLast+0x1c(feba49b0, fec660b0, 4924a0, 0, 0, 0) > TreeList__PutCollectionList+0x3a00(fedc8cd0, fedb29b8, 1, 0, > fedeb430, 0) > TreeList__ListCollection+0x4a4(fedc8cd0, fedb29b8, feeecbc0, > fed11800, 533b2c, 0 > ) > TreeList__Apply+0x2dc(fedc8cd0, 1000, feeecbc0, fed11800, 533b68, 0) > ThreadPThread__RunThread+0x3c4(d4a1e0, 0, 0, 0, 0, 1) > ThreadPThread__ThreadBase+0x44(d4a1e0, fec20000, 0, 0, 44bae4, 1) > libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) > > I am not sure if that is even in the Modula-3 libraries, but you can > probably tell. Here's the ls; ldd: > > -rwxr-xr-x 1 root other 5396444 Sep 26 10:56 /usr/local/ > bin/cvsup > libXaw.so.5 => /usr/lib/libXaw.so.5 > libXmu.so.4 => /usr/lib/libXmu.so.4 > libXext.so.0 => /usr/lib/libXext.so.0 > libXt.so.4 => /usr/lib/libXt.so.4 > libX11.so.4 => /usr/lib/libX11.so.4 > libsocket.so.1 => /lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libw.so.1 => /lib/libw.so.1 > libdl.so.1 => /lib/libdl.so.1 > libpthread.so.1 => /lib/libpthread.so.1 > libthread.so.1 => /lib/libthread.so.1 > librt.so.1 => /lib/librt.so.1 > libm.so.2 => /lib/libm.so.2 > libc.so.1 => /lib/libc.so.1 > libSM.so.6 => /usr/openwin/lib/libSM.so.6 > libICE.so.6 => /usr/openwin/lib/libICE.so.6 > libmp.so.2 => /lib/libmp.so.2 > libmd5.so.1 => /lib/libmd5.so.1 > libscf.so.1 => /lib/libscf.so.1 > libaio.so.1 => /lib/libaio.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libmd5_psr.so.1 > > Hope this helps. Let me know what else I shoudl try. > > Alex. From alexb at juniper.net Fri Sep 28 22:59:29 2007 From: alexb at juniper.net (Alex Bochannek) Date: Fri, 28 Sep 2007 13:59:29 -0700 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: <2559758D-5DE9-4CAF-B9D1-77F851B6310B@cs.purdue.edu> (Tony Hosking's message of "Fri\, 28 Sep 2007 13\:59\:32 -0400") References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> <1B153BC7-A186-4F33-A019-91ADFEEC97FD@cs.purdue.edu> <90E9CEA8-6406-44E1-8265-9188B51B850D@cs.purdue.edu> <2559758D-5DE9-4CAF-B9D1-77F851B6310B@cs.purdue.edu> Message-ID: Tony Hosking writes: > I forget if we tried the "paranoid" GC configuration or not. Can you > run with @M3paranoidgc and see what happens? Again, I am unable to > replicate the problems you are seeing, even on my Solaris 10 box. Here's what I get now: -bash-3.00$ cvsup @M3paranoidgc -g cvsupfile.cm3-g cvsupfile.cm3 Connected to birch.elegosoft.com Updating collection cm3/cvs SetAttrs cm3/COPYRIGHT-BSD,v SetAttrs cm3/COPYRIGHT-CMASS,v SetAttrs cm3/COPYRIGHT-COLUMBIA,v SetAttrs cm3/COPYRIGHT-DEC,v SetAttrs cm3/COPYRIGHT-JDP,v SetAttrs cm3/COPYRIGHT-PURDUE,v SetAttrs cm3/COPYRIGHT-XEROX,v SetAttrs cm3/COPYRIGHTS,v SetAttrs cm3/README,v SetAttrs cm3/caltech-parser/COPYRIGHT,v SetAttrs cm3/caltech-parser/Makefile,v SetAttrs cm3/caltech-parser/PkgTags,v *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/runtime/common/RTCollector.m3", line 1770 *** Abort (core dumped) -bash-3.00$ mdb core3paranoidgc -g cvsupfile.cm3 Loading modules: [ libc.so.1 ld.so.1 ] > $c libc.so.1`_lwp_kill+8(6, 0, feea4af8, ffffffff, feee8284, 6) libc.so.1`abort+0x110(febfdc58, 1, 48c988, a8390, feeeb298, 0) RTOS__Crash+4(0, 44, 48, 0, 1113a18, 1113340) RTProcess__Crash+0x98(0, 4, a, 1, 200000, 100000) RTError__EndError+0x58(1, 0, 52f500, 0, 180c508, 8) RTError__MsgS+0xe4(52dadc, 6ea, 52f500, 52b660, 52f500, 52dadc) RTException__Crash+0x354(febfeb1c, 0, 52b510, 1, 200000, 100000) RTException__DefaultBackstop+0xf8(febfeb1c, 0, 0, fffffff8, 4, 12345678) RTException__InvokeBackstop+0x4c(febfeb1c, 0, ffffffff, fffffff8, 0, febfe571) RTException__Raise+0xec(febfeb1c, febfe6f8, 0, 0, 0, 0) RTException__DefaultBackstop+0x1f4(febfeb1c, 0, 0, fffffff8, 4, 12345678) RTException__InvokeBackstop+0x4c(febfeb1c, 0, ffffffff, fffffff8, 0, febfeaa1) RTException__Raise+0xec(febfeb1c, febfefb0, 7f59f, 0, 0, 0) RTHooks__ReportFault+0x138(52dc50, dd40, fedb0420, 0, 0, d6a710) 0x431948(dd40, 0, fedb0420, fed11c00, feeecc08, 0) RTCollector__RefSanityCheck+0x1c4(fedb0420, feb5a0a4, fedb0420, 1, 1, 1) RTHeapMap__Walk+0x6c8(feb5a0a4, 53949b, fedb0420, 4, fed11c00, fed11d00) RTHeapMap__DoWalkRef+0xac(5394ec, feb5a0a0, fedb0420, fed11c00, 533b2c, 0) RTHeapMap__DoWalkRef+0x6c(53969c, feb5a0a0, fedb0420, 4, d4a26c, fed11d00) RTHeapMap__WalkRef+0x194(feb5a09c, fedb0420, 0, 1000, 0, 0) RTCollector__SanityCheck+0x79c(fedb0004, febfefb0, 7f59f, 0, 0, 0) RTCollector__After+0x40(fedb0004, feb41668, 7f5a0, 0, 0, d6a710) RTHeapRep__InvokeMonitors+0x208(0, 38161524, e5bab, 0, 0, febff090) RTCollector__CollectSomeInStateFive+0x5f8(ff000000, 0, ff000000, ff000000, 0, fed11d00) RTCollector__CollectSome+0x158(1, 1000, feeecbc0, fed11c00, 533dbc, 0) RTCollector__CollectEnough+0xcc(d4a268, 4, feb5de80, fed11c00, 533b2c, 0) RTHeapRep__AllocTraced+0x194(52a45c, 94, 4, febff32c, d4a26c, 94) RTAllocator__GetOpenArray+0x1bc(52a45c, febff43c, ff000000, ff000000, 0, fed11d00) RTHooks__AllocateOpenArray+0x1c(52a45c, febff43c, ff000000, ff000000, 0, 0) Text8__Create+0xdc(88, 1000, feeecbc0, fed11c00, 533b2c, 0) Text8__New+0x5c(febff674, 1f, 4, febff668, d4a26c, 98) Text__FromChars+0xc8(febff674, 1f, 4, febff790, d4a26c, 30) SupMisc__GetCmdLine+0x72c(feb383a4, feb5de34, 0, 0, 0, 0) FileStatus__RdGetRaw+0x830(feb393f0, feb5df68, feb5de80, fed11c00, 533b2c, 0) StatusFile__Get+0x5b0(feb38260, feb5de34, 0, 0, 533b2c, 0) Detailer__SendCheckoutDetails+0x380(fec5c8f0, fedb2220, feb5de34, 0, 0, 0) Detailer__SendDetails+0x5c(fec5c8f0, fedb2220, feb5de34, 0, 0, 0) Detailer__DetailCollection+0x1efc(fec5c8f0, fedb2220, feb38190, fed11c00, 533b2c, 0) Detailer__Apply+0x5d8(fec5c8f0, 1000, feeecbc0, fed11c00, 533b68, 0) ThreadPThread__RunThread+0x3c4(d4a238, 0, 0, 0, 0, 1) ThreadPThread__ThreadBase+0x44(d4a238, fec00000, 0, 0, 44bae4, 1) libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) I also still get errors with directory creation when there aren't any yet: -bash-3.00$ cvsup @M3paranoidgc -g cvsupfile.cm3 Connected to birch.elegosoft.com Updating collection cm3/cvs Checkout cm3/COPYRIGHT-BSD Checkout cm3/COPYRIGHT-CMASS Checkout cm3/COPYRIGHT-COLUMBIA Checkout cm3/COPYRIGHT-DEC Checkout cm3/COPYRIGHT-JDP Checkout cm3/COPYRIGHT-PURDUE Checkout cm3/COPYRIGHT-XEROX Checkout cm3/COPYRIGHTS Checkout cm3/README Updater failed: Cannot create directories leading to "/opt/cm3/cm3-cvs/cm3/caltech-parser/#cvs.cvsup-3705.10": Resource temporarily unavailable Alex. From hosking at cs.purdue.edu Fri Sep 7 19:03:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 07 Sep 2007 17:03:29 -0000 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> Message-ID: Sounds like we are losing some references somewhere and the GC is prematurely collecting live objects. Alex, are you running on a 64- bit SPARC v9? Perhaps the SaveRegsInStack code needs updating for that platform to use the flushw instruction instead of trap 3. As it is, I am not entirely satisfied with the difficulties I've seen getting meaningful stack information on Solaris for stopped threads, but without a reliable way to diagnose the problem I don't know what to do from this end. See additional comments below: On Sep 7, 2007, at 12:04 AM, Alex Bochannek wrote: > Tony, John, > > I ran the tests some more and noticed that there is always a problem > with directory creation. The error I had mentioned before: > > Updater failed: Cannot create directories leading to "/opt/cm3/cm3- > cvs/cm3/caltech-parser/#cvs.cvsup-15483.1": Resource temporarily > unavailable > > happens pretty reliably whenever a directory (in this case > caltech-parser) needs to be created regardless of the options > below. This is running as root and cvsup not running setuid. I copied > the directory structure froman existing tree to even get the > examples to > run. (There is also an unrelated question for John below, please > read on.) > > Tony Hosking writes: > >> We are using the native threads package here, unless Alex has built >> without it. Alex, can you try running with each of the following > > Here's what I have the cvsup linked against: > > ldd /usr/local/bin/cvsup > libXaw.so.5 => /usr/lib/libXaw.so.5 > libXmu.so.4 => /usr/lib/libXmu.so.4 > libXext.so.0 => /usr/lib/libXext.so.0 > libXt.so.4 => /usr/lib/libXt.so.4 > libX11.so.4 => /usr/lib/libX11.so.4 > libsocket.so.1 => /lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libw.so.1 => /lib/libw.so.1 > libdl.so.1 => /lib/libdl.so.1 > libpthread.so.1 => /lib/libpthread.so.1 > libthread.so.1 => /lib/libthread.so.1 > librt.so.1 => /lib/librt.so.1 > libm.so.2 => /lib/libm.so.2 > libc.so.1 => /lib/libc.so.1 > libSM.so.6 => /usr/openwin/lib/libSM.so.6 > libICE.so.6 => /usr/openwin/lib/libICE.so.6 > libmp.so.2 => /lib/libmp.so.2 > libmd5.so.1 => /lib/libmd5.so.1 > libscf.so.1 => /lib/libscf.so.1 > libaio.so.1 => /lib/libaio.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libmd5_psr.so.1 > >> flag combinations and report the results: >> >> @M3nogc > > With the nogc options cvsup pretty much always runs all the way to > completion. It takes a while, especially on an existing tree, but it > will complete without problems. When you say "pretty much" what do you mean? Does it sometimes get an error? Is it the one you note above? > Trying the following failed: > >> @M3noincremental @M3nogenerational @M3paranoidgc >> >> @M3noincremental @M3paranoidgc >> >> @M3nogenerational @M3paranoidgc >> >> @M3paranoidgc > > -bash-3.00$ /usr/local/bin/cvsup -g cvsupfile.cm3 > Connected to birch.elegosoft.com > Updating collection cm3/cvs > SetAttrs cm3/COPYRIGHT-BSD,v > SetAttrs cm3/COPYRIGHT-CMASS,v > SetAttrs cm3/COPYRIGHT-COLUMBIA,v > SetAttrs cm3/COPYRIGHT-DEC,v > SetAttrs cm3/COPYRIGHT-JDP,v > SetAttrs cm3/COPYRIGHT-PURDUE,v > SetAttrs cm3/COPYRIGHT-XEROX,v > SetAttrs cm3/COPYRIGHTS,v > SetAttrs cm3/README,v > SetAttrs cm3/caltech-parser/COPYRIGHT,v > SetAttrs cm3/caltech-parser/Makefile,v > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3 > *** We may have collected something prematurely. > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3noincremental @M3nogenerational > @M3paranoidgc -g cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3 > *** > Ditto > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3noincremental @M3paranoidgc -g > cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3 > *** Ditto > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3nogenerational @M3paranoidgc -g > cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", line 1770 > *** This is the collector complaining that it found a reference in the heap to an object that has been reclaimed. > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3paranoidgc -g cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x421638 = NoteStackLocations + 0xac in ../src/runtime/ > common/RTCollector.m3 > *** > Looks like a bad sp error. > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", line 688 > *** This is knock-on from the previous error. > > Abort > -bash-3.00$ > > > I hope this helps and that you can get to the bottom of this. > > I am trying to compile a new CVSup to see why I keep getting checksum > mismatches that result in very long transfer times. I didn't think > that > when CVSup runs on a busy repository, that I should get those a > lot, but > especially during tagging operations, it seems like I end up with > transferring the entire repository. > > Alex. From hosking at cs.purdue.edu Fri Sep 7 20:12:37 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 07 Sep 2007 18:12:37 -0000 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> Message-ID: <1B153BC7-A186-4F33-A019-91ADFEEC97FD@cs.purdue.edu> Hmm... What output do you get with "cm3cg --version"? On my machine I see: /p/sss/cm3/bin/cm3cg --version Modula-3 backend version 4.1.1 (sparc-sun-solaris2.8) compiled by GNU C version 4.1.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min- heapsize=131072 On Sep 7, 2007, at 1:51 PM, Alex Bochannek wrote: > Tony Hosking writes: > >> Sounds like we are losing some references somewhere and the GC is >> prematurely collecting live objects. Alex, are you running on a 64- >> bit SPARC v9? Perhaps the SaveRegsInStack code needs updating for > > Yes. > > -bash-3.00$ isainfo -kv; isainfo -v > 64-bit sparcv9 kernel modules > 64-bit sparcv9 applications > vis2 vis > 32-bit sparc applications > vis2 vis v8plus div32 mul32 > >> that platform to use the flushw instruction instead of trap 3. As it >> is, I am not entirely satisfied with the difficulties I've seen >> getting meaningful stack information on Solaris for stopped threads, >> but without a reliable way to diagnose the problem I don't know what >> to do from this end. See additional comments below: > >>> With the nogc options cvsup pretty much always runs all the way to >>> completion. It takes a while, especially on an existing tree, but it >>> will complete without problems. >> >> When you say "pretty much" what do you mean? Does it sometimes >> get an >> error? Is it the one you note above? > > I should have been more precise here. Every time I ran cvsup with > @M3nogc and I let it run to completion, it completed without > error. Since it took a while, I did interrupt it a few times during > testing. > > Alex. From jay.krell at cornell.edu Fri Sep 7 21:20:33 2007 From: jay.krell at cornell.edu (Jay) Date: Fri, 07 Sep 2007 19:20:33 -0000 Subject: [M3devel] mailing lists? Message-ID: m3devel and m3commit working? - Jay _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Sep 12 21:48:00 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 12 Sep 2007 19:48:00 -0000 Subject: [M3devel] Note on an obscure m3gdb/compiler interaction Message-ID: <46E8427A.4000607@wichita.edu> If you link in a library, all the code of the entire library is loaded into your address space, and all the debug data is available to m3gdb, even for modules in the library but not in the import/export closure of the main program. This means you can call procedures in such modules from m3gdb commands. However, there is initialization of global data that the compilers take care of only for modules in the closure. If you call something from m3gdb that is in memory but not initialized, various bad things can happen. As an example, you can always call RTTypeFP.FromFingerprint, because it is in libm3core. And this could be a useful thing to want to do during a debug session (e.g., when debugging something involving pickles). But if you do this when RTTypeFP is not in the closure, there will be a segment fault while trying allocate a heap object of a type whose type definition pointer in the global space of RTTypeFP is uninitialized. Even the needed type definition is present, but the needed pointer to it is not set up. For now, the only workaround is add an IMPORT of the needed module to the code and recompile, before trying the call from m3gdb. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jay.krell at cornell.edu Thu Sep 13 15:13:02 2007 From: jay.krell at cornell.edu (Jay) Date: Thu, 13 Sep 2007 13:13:02 -0000 Subject: [M3devel] testing...#1 (cornell) Message-ID: Seeing if these go through..it's been quite a few days not working.. I don't think the problem is on my end, but could be. (I do have a setup now that sends from one address, but "claims" another, and the claimed one works and forwards, providing flexibility...) - Jay _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 13 15:15:20 2007 From: jay.krell at cornell.edu (Jay) Date: Thu, 13 Sep 2007 13:15:20 -0000 Subject: [M3devel] testing...#2 (hotmail) Message-ID: sorry for the spam..I waited several days and send less spammy tests... (and some submits) - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.com; m3-support at elego.de; m3-support at elegosoft.comCC: "Tony Hosking" " ; " ronny.forberger at elegosoft.com " ; " rcoleburn at scires.com " ; " Daniel Alejandro Benavides D." "Subject: testing...#1 (cornell)Date: Thu, 13 Sep 2007 13:12:50 +0000 Seeing if these go through..it's been quite a few days not working..I don't think the problem is on my end, but could be.(I do have a setup now that sends from one address, but "claims" another, and the claimed one works and forwards, providing flexibility...) - Jay Make your little one a shining star! Shine on! _________________________________________________________________ Gear up for Halo? 3 with free downloads and an exclusive offer. It?s our way of saying thanks for using Windows Live?. http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Sep 14 04:02:49 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 14 Sep 2007 02:02:49 -0000 Subject: [M3devel] A RT failure in ThreadPThread.Alert Message-ID: <46E9EBD3.1060603@wichita.edu> I got a runtime failure in ThreadPThread.Alert, on this line: ---------------------------------------------------------------------------------- PROCEDURE Alert (t: T) = BEGIN WITH r = Upthread.mutex_lock(cm) DO <*ASSERT r=0*> END; t.alerted := TRUE; --> WITH r = Upthread.cond_signal(t.waitCond^) DO <*ASSERT r=0*> END; WITH r = Upthread.mutex_unlock(cm) DO <*ASSERT r=0*> END; END Alert; ------------------------------------------------------------------------------------ Here, t.waitCond is NIL and being dereferenced. Here is a bit of debugger output: The display of t is at the bottom. ------------------------------------------------------------------------------------ *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 304 *** ------------------ EXCEPTION HANDLER STACK --------------------- 0xb5eb71dc TRY-EXCEPT {0xa893a19c} 0xb5eb72bc LOCK mutex = 0xb436e0e4 0xb5eb731c LOCK mutex = 0xb6ebbc44 ---------------------------------------------------------------- [Switching to Thread -1242858592 (LWP 8289)] Breakpoint 2, 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 272 ; PROCEDURE InnerRuntimeFailureDialog ( ) (m3gdb) bt #0 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 #1 0x08126c89 in RuntimeFailureDialog () at AssertDevel.m3:314 #2 0xb72e596f in InvokeExitors () at RTProcess.m3:40 #3 0xb72e59e3 in Crash (msg=NIL) at RTProcess.m3:61 #4 0xb72e3648 in EndError (crash=TRUE) at RTError.m3:115 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 #6 0xb72e3a46 in Crash (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE, rte=16_b73124c0) at RTException.m3:79 #7 0xb72e3770 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:39 #8 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #9 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #10 0xb72e3810 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:47 #11 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #12 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #13 0xb72cb223 in ReportFault (module=16_b731e020, info=9732) at RTHooks.m3:110 #14 0xb72fb697 in _m3_fault (arg=9732) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 #16 0xb7df741d in DisplayDir (v=16_b436e004) at FileBrowserVBT.m3:496 #17 0xb7df4d83 in Refresh (v=16_b436e004) at FileBrowserVBT.m3:210 #18 0xb7df5413 in Watcher (cl=16_b6ebbc9c) at FileBrowserVBT.m3:254 #19 0xb72f76f5 in RunThread (me=16_08e1c518) at ThreadPThread.m3:538 #20 0xb72f7403 in ThreadBase (param=16_08e1c518) at ThreadPThread.m3:519 #21 0xb707c540 in start_thread () from /lib/i686/libpthread.so.0 #22 0xb6fef55e in clone () from /lib/i686/libc.so.6 (m3gdb) frame 5 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 40 RTError.m3: No such file or directory. in RTError.m3 (m3gdb) p msgA $1 = (*16_b7318068*) "" (m3gdb) p msgB $2 = (*16_b73126d4*) "Attempt to reference an illegal memory location." (m3gdb) p msgC $3 = (*16_b7318068*) "" (m3gdb) frame 15 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 304 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) p t $4 = (*16_b3a9bdc8*) OBJECT act = 16_08e94678; closure = NIL; result = NIL; cond = 16_b3a9bdf4; waitingOn = NIL; nextWaiter = NIL; waitCond = NIL; alerted = TRUE; completed = TRUE; joined = FALSE; id = 73; END (m3gdb) -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From ronny.forberger at elegosoft.com Sat Sep 15 12:55:24 2007 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Sat, 15 Sep 2007 10:55:24 -0000 Subject: [M3devel] is this working? In-Reply-To: References: Message-ID: <46EBBA13.7050106@elegosoft.com> Hi there, I just returned from holidays so I wasn't able to investigate the mailing lists problem at any earlier time. The messages indeed could not be processed by the HTML engine anymore, because there was some problem about the mailling list software package on our server, which I still don't understand why this happend. Nevertherless it should have returned to a working state now. Regards, Ronny j k schrieb: > I'm not seeing my mail to m3devel. One accidentally had no subject, > but that doesn't seem to the cause. > > - Jay > > ------------------------------------------------------------------------ > Invite your mail contacts to join your friends list with Windows Live > Spaces. It's easy! Try it! > -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12 D-13355 Berlin Tel. +49 30 32 29 71 34 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer Olaf Wagner; Sitz Berlin; Amtsgericht Berlin-Charlottenburg HRB 77719 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 16 04:39:09 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Sep 2007 02:39:09 -0000 Subject: [M3devel] FW: cm3/win32 micro status.. Message-ID: From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.com; m3-support at elego.de; m3-support at elegosoft.comSubject: cm3/win32 micro status..Date: Tue, 4 Sep 2007 09:08:18 +0000 fixed and /drastically/ churned hand.c problem reported by Daniel, though I went overboard in my way :) (send flames if you don't like and MAYBE I'll change my ways...)added MyHeapState to thread\win32\ThreadF.i3 to fix compilation of RTCollector.m3 fixed typo somewhere I think ThreadWin32.m3\MyHeapState to fix compileremove unimplemented MyAllocPool from thread\win32\ThreadF.i3 to fix compile Tony? Maybe you just forgot to commit the use of it?new release at ~jkrell\*.tar.bz2 on m3.elegosoft.com made with cm3\scripts\win\make-dist.cmd (have I mentioned this before? :) )mail not coming through here; I'll keep sending, covering my butt :)int64 support still MIA sorry I havebeen reading some of the relevant code, at this rate could be a week could be a year..Juno.exe starts up displays a bunch of stuff looks like it is "initializing"C:\cm3\bin>Juno.exe****** runtime error:*** <*ASSERT*> failed.*** file "..\src\winvbt\WinContext.m3", line 165***Stack trace: FP PC Procedure--------- --------- -------------------------------0x5aaf830 0xf41c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m30x5aaf8f8 0xf4fc1c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m30x5aafd54 0xf4db45 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m30x5aafdbc 0xf4843e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m30x5aafe04 0xf46d3d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m30x5aafe30 0x7e418734 0x5aafe98 0x7e418816 0x5aafef8 0x7e4189cd 0x5aaff08 0x7e4196c7 0x5aaff50 0xf4baf4 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3......... ......... ... more frames ...I have "cracked" my legitimate copy of CM3 4.1 cminstall and cm3 so cminstall doesn't prompt for license and cm3 doesn't care about license haven't automated, just poking in debugge Would like to hear about the legality here before telling people how, but, uh, really..if you can use the Windows ntsd/cdb debugger, it is quite easy.. You even have the source to cminstall. I'll probably automate applying the patch, or running an unpatched copy and patch it in memory or something. But again I'd like to know the legality, and if there is any need/interest in making a 4.1 binary distribution.Has anyone thought about versioning and .dlls with Modula-3?Like should exported names include typecodes?Or is it just that all the .dlls and .exes in the same directory shouldbe built and rebuilt together and that's it? - Get news, entertainment and everything you care about at Live.com. Check it out! _________________________________________________________________ Gear up for Halo? 3 with free downloads and an exclusive offer. It?s our way of saying thanks for using Windows Live?. http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 16 04:40:08 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Sep 2007 02:40:08 -0000 Subject: [M3devel] FW: hand.c In-Reply-To: <995081.11151.qm@web27115.mail.ukl.yahoo.com> References: <995081.11151.qm@web27115.mail.ukl.yahoo.com> Message-ID: I have since made some more of the changes. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: hand.cDate: Mon, 3 Sep 2007 23:15:04 +0000 I'm not seeing commit mail.Maybe my fault with the hotmail? I churned it relatively a lot. It's a small file.It compiles with older Microsoft C compilers -- optionally using __int64 instead of long long. (Visual C+ 8.0 worked as it was.) I would have factored out the LL suffixes, but, really, the vast majoriy, if not all, of the L and LL suffixes were unnecessary, right? I removed most of them.It is valid C++ now -- optional prototypes.There was a race condition in initialization, fixed.gcc -Wall complained about a safe signed/unsigned compare, fixed. Not changed: all these longs should be unsigned long, right? Or at least the bits, if not the input bit indices? Negative bit indices should be either rejected or converted to 0, and then treated as unsigned from there, right? _lowbits and _highbits should be extern const ? only on x86, right? I'm still checking if they are referenced for all targets or only x86 HighBits and LowBits should be, like..ok switched to #if LONG_MAX == 2147483647 extern const .. hard coded 32 bit values ... #elif LONG_MAX == 9223372036854775807 extern const .. hard coded 64 bit values ... #else either compute them like currently or #error #endif right? And if it is 32 bits, share the values of HighBits with _highbits, LowBits with _lowbits?They aren't /quite/ the same, but almost. _lowbits and _highbits have one extra value, the zeros at the ends I think it was. - Jay Get news, entertainment and everything you care about at Live.com. Check it out! _________________________________________________________________ Kick back and relax with hot games and cool activities at the Messenger Caf?. http://www.cafemessenger.com?ocid=TXT_TAGLM_SeptWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Sep 18 23:29:18 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 18 Sep 2007 23:29:18 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler Message-ID: <291833.75281.qm@web27114.mail.ukl.yahoo.com> Hi all: Im getting this runtiem error because the symbol missing version stamps -> compiling RTAllocStats.m3 "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime symbol !! (R THooks.AllocateTracedRef) AllocateTracedRef is not defined in the m3core version of this Dll (I guess the change is more new than the bootstrap compiler). How can avoid this issue? Thanks in advance C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd INSTALLROOT=C:\cm3 LIB=%INSTALLROOT%\LIB;%LIB% CM3ROOT=C:\\cm3-cvs\\cm3 call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override -DROOT=C:\\cm3-c vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner m3tools m3cgcat m3c ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph parseparams realgeo metry set slisp sortedtableextras table-list tempfiles tcp tapi === package C:\cm3-cvs\cm3\m3-win\import-libs === +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ --- building in NT386 --- unable to read ..\src\m3overrides, options "-override" and "-x" ignored. === package C:\cm3-cvs\cm3\m3-libs\m3core === +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ --- building in NT386 --- missing version stamps -> compiling RTAllocStats.m3 "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime symbol !! (R THooks.AllocateTracedRef) *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 ......... ......... ... more frames ... *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 failed with 0 *** error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override -DROOT=C :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner m3tools m3c gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles tcp tapi failed C:\cm3-cvs\cm3\scripts\win> --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 19 00:25:14 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Sep 2007 18:25:14 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <291833.75281.qm@web27114.mail.ukl.yahoo.com> References: <291833.75281.qm@web27114.mail.ukl.yahoo.com> Message-ID: You need to recompile m3core before compiling with the new compiler. On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > Im getting this runtiem error because the symbol > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > AllocateTracedRef is not defined in the m3core version of this Dll > (I guess the change is more new than the bootstrap compiler). How > can avoid this issue? > > Thanks in advance > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > INSTALLROOT=C:\cm3 > LIB=%INSTALLROOT%\LIB;%LIB% > CM3ROOT=C:\\cm3-cvs\\cm3 > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > DROOT=C:\\cm3-c > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > m3tools m3cgcat m3c > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > parseparams realgeo > metry set slisp sortedtableextras table-list tempfiles tcp tapi > === package C:\cm3-cvs\cm3\m3-win\import-libs === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > unable to read ..\src\m3overrides, options "-override" and "-x" > ignored. > === package C:\cm3-cvs\cm3\m3-libs\m3core === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > failed with 0 *** > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > override -DROOT=C > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > m3scanner m3tools m3c > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > digraph parseparams > realgeometry set slisp sortedtableextras table-list tempfiles tcp > tapi failed > > C:\cm3-cvs\cm3\scripts\win> > > > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . From dabenavidesd at yahoo.es Wed Sep 19 00:30:16 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 19 Sep 2007 00:30:16 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: Message-ID: <248580.34013.qm@web27103.mail.ukl.yahoo.com> Hi: Thanks for your answer, I have done that and also I get the same runtime error in the same source file: C:\cm3-cvs\cm3\m3-libs\m3core>CM3 --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 new source -> compiling Compiler.m3 new source -> compiling RTAllocator.i3 new source -> compiling RTType.i3 new source -> compiling Csetjmp.i3 new source -> compiling BasicCtypes.i3 new source -> compiling Ctypes.i3 new source -> compiling RTMachine.i3 new source -> compiling RTHeapDep.i3 new source -> compiling RTHeapRep.i3 new source -> compiling ThreadF.i3 new source -> compiling RTOS.i3 new source -> compiling RTMisc.i3 new source -> compiling RTHeap.i3 new source -> compiling Cstdlib.i3 new source -> compiling Cstddef.i3 new source -> compiling RTAllocCnts.i3 new source -> compiling RTAllocator.m3 new source -> compiling RTAllocStats.i3 new source -> compiling Convert.i3 new source -> compiling TextClass.i3 new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime symbol !! (R THooks.AllocateTracedRef) *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 ......... ......... ... more frames ... C:\cm3-cvs\cm3\m3-libs\m3core> >You need to recompile m3core before compiling with the new compiler. >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > Hi all: > Im getting this runtiem error because the symbol > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > AllocateTracedRef is not defined in the m3core version of this Dll > (I guess the change is more new than the bootstrap compiler). How > can avoid this issue? > > Thanks in advance > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > INSTALLROOT=C:\cm3 > LIB=%INSTALLROOT%\LIB;%LIB% > CM3ROOT=C:\\cm3-cvs\\cm3 > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > DROOT=C:\\cm3-c > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > m3tools m3cgcat m3c > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > parseparams realgeo > metry set slisp sortedtableextras table-list tempfiles tcp tapi > === package C:\cm3-cvs\cm3\m3-win\import-libs === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > unable to read ..\src\m3overrides, options "-override" and "-x" > ignored. > === package C:\cm3-cvs\cm3\m3-libs\m3core === > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > --- building in NT386 --- > > missing version stamps -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > failed with 0 *** > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > override -DROOT=C > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > m3scanner m3tools m3c > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > digraph parseparams > realgeometry set slisp sortedtableextras table-list tempfiles tcp > tapi failed > > C:\cm3-cvs\cm3\scripts\win> > > > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 19 00:35:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Sep 2007 18:35:08 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <248580.34013.qm@web27103.mail.ukl.yahoo.com> References: <248580.34013.qm@web27103.mail.ukl.yahoo.com> Message-ID: You need to compile the new m3core with the old compiler so that the symbol is available to you when you compile using the new compiler. This is a classical bootstrapping problem. On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your answer, I have done that and also I get the same > runtime error > in the same source file: > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > new source -> compiling Compiler.m3 > new source -> compiling RTAllocator.i3 > new source -> compiling RTType.i3 > new source -> compiling Csetjmp.i3 > new source -> compiling BasicCtypes.i3 > new source -> compiling Ctypes.i3 > new source -> compiling RTMachine.i3 > new source -> compiling RTHeapDep.i3 > new source -> compiling RTHeapRep.i3 > new source -> compiling ThreadF.i3 > new source -> compiling RTOS.i3 > new source -> compiling RTMisc.i3 > new source -> compiling RTHeap.i3 > new source -> compiling Cstdlib.i3 > new source -> compiling Cstddef.i3 > new source -> compiling RTAllocCnts.i3 > new source -> compiling RTAllocator.m3 > new source -> compiling RTAllocStats.i3 > new source -> compiling Convert.i3 > new source -> compiling TextClass.i3 > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > > C:\cm3-cvs\cm3\m3-libs\m3core> > >You need to recompile m3core before compiling with the new compiler. > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > > > Hi all: > > Im getting this runtiem error because the symbol > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > AllocateTracedRef is not defined in the m3core version of this Dll > > (I guess the change is more new than the bootstrap compiler). How > > can avoid this issue? > > > > Thanks in advance > > > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > > INSTALLROOT=C:\cm3 > > LIB=%INSTALLROOT%\LIB;%LIB% > > CM3ROOT=C:\\cm3-cvs\\cm3 > > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > > DROOT=C:\\cm3-c > > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > > m3tools m3cgcat m3c > > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > > parseparams realgeo > > metry set slisp sortedtableextras table-list tempfiles tcp tapi > > === package C:\cm3-cvs\cm3\m3-win\import-libs === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > unable to read ..\src\m3overrides, options "-override" and "-x" > > ignored. > > === package C:\cm3-cvs\cm3\m3-libs\m3core === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > > > *** > > *** runtime error: > > *** Attempt to reference an illegal memory location. > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > *** > > > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > \RTSignal.m3 > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > ..\src\stmts\AssignStmt.m3 > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > ......... ......... ... more frames ... > > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > > failed with 0 *** > > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > > override -DROOT=C > > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > > m3scanner m3tools m3c > > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > > digraph parseparams > > realgeometry set slisp sortedtableextras table-list tempfiles tcp > > tapi failed > > > > C:\cm3-cvs\cm3\scripts\win> > > > > > > S? un Mejor Amante del Cine > > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > > > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . From dabenavidesd at yahoo.es Wed Sep 19 00:49:57 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 19 Sep 2007 00:49:57 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: Message-ID: <940950.96289.qm@web27108.mail.ukl.yahoo.com> Hi: I have compiled with the Jay produced 5.5 bootstrap compiler, and also with 5.1.3a, 5.2.6 and get the same error. Thanks >You need to compile the new m3core with the old compiler so that the >symbol is available to you when you compile using the new compiler. >This is a classical bootstrapping problem. >On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your answer, I have done that and also I get the same > runtime error > in the same source file: > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > --- building in NT386 --- > > ignoring ..\src\m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > new source -> compiling Compiler.m3 > new source -> compiling RTAllocator.i3 > new source -> compiling RTType.i3 > new source -> compiling Csetjmp.i3 > new source -> compiling BasicCtypes.i3 > new source -> compiling Ctypes.i3 > new source -> compiling RTMachine.i3 > new source -> compiling RTHeapDep.i3 > new source -> compiling RTHeapRep.i3 > new source -> compiling ThreadF.i3 > new source -> compiling RTOS.i3 > new source -> compiling RTMisc.i3 > new source -> compiling RTHeap.i3 > new source -> compiling Cstdlib.i3 > new source -> compiling Cstddef.i3 > new source -> compiling RTAllocCnts.i3 > new source -> compiling RTAllocator.m3 > new source -> compiling RTAllocStats.i3 > new source -> compiling Convert.i3 > new source -> compiling TextClass.i3 > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R > THooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3 > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > ......... ......... ... more frames ... > > C:\cm3-cvs\cm3\m3-libs\m3core> > >You need to recompile m3core before compiling with the new compiler. > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > > > Hi all: > > Im getting this runtiem error because the symbol > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > AllocateTracedRef is not defined in the m3core version of this Dll > > (I guess the change is more new than the bootstrap compiler). How > > can avoid this issue? > > > > Thanks in advance > > > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > > INSTALLROOT=C:\cm3 > > LIB=%INSTALLROOT%\LIB;%LIB% > > CM3ROOT=C:\\cm3-cvs\\cm3 > > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > > DROOT=C:\\cm3-c > > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > > m3tools m3cgcat m3c > > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > > parseparams realgeo > > metry set slisp sortedtableextras table-list tempfiles tcp tapi > > === package C:\cm3-cvs\cm3\m3-win\import-libs === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > unable to read ..\src\m3overrides, options "-override" and "-x" > > ignored. > > === package C:\cm3-cvs\cm3\m3-libs\m3core === > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > --- building in NT386 --- > > > > missing version stamps -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > > > *** > > *** runtime error: > > *** Attempt to reference an illegal memory location. > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > *** > > > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > \RTSignal.m3 > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > ..\src\stmts\AssignStmt.m3 > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > ......... ......... ... more frames ... > > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > > failed with 0 *** > > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > > override -DROOT=C > > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > > m3scanner m3tools m3c > > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > > digraph parseparams > > realgeometry set slisp sortedtableextras table-list tempfiles tcp > > tapi failed > > > > C:\cm3-cvs\cm3\scripts\win> --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 19 02:41:09 2007 From: jay.krell at cornell.edu (Jay) Date: Wed, 19 Sep 2007 00:41:09 +0000 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <940950.96289.qm@web27108.mail.ukl.yahoo.com> References: <940950.96289.qm@web27108.mail.ukl.yahoo.com> Message-ID: Daniel, can you try just going back to 5.2.6 and running scripts\win\update? You should be able to build the current source the last "official" Win32 binaries, as long as you build in the correct order and all, which the update.cmd does. You know, there's a certain mentality around bootstrapping and keeping the connection back to the previous version, that I upheld. As long as you are careful, you can go from old binaries to new binaries, you don't have to get the new binaries magically somewhere, though you do need the old binaries magically from somewhere. :) Perhaps there's a regression. I can check "later". - Jay Date: Wed, 19 Sep 2007 00:49:57 +0200From: dabenavidesd at yahoo.esTo: hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compilerHi:I have compiled with the Jay produced 5.5 bootstrap compiler, and also with 5.1.3a, 5.2.6 and get the same error.Thanks>You need to compile the new m3core with the old compiler so that the >symbol is available to you when you compile using the new compiler. >This is a classical bootstrapping problem.>On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote:> Hi:> Thanks for your answer, I have done that and also I get the same > runtime error> in the same source file:>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3> --- building in NT386 --->> ignoring ..\src\m3overrides>> new source -> compiling RTHooks.i3> new source -> compiling RT0.i3> new source -> compiling RuntimeError.i3> new source -> compiling Word.i3> new source -> compiling RTException.i3> new source -> compiling RTHooks.m3> new source -> compiling RT0.m3> new source -> compiling Compiler.i3> new source -> compiling RuntimeError.m3> new source -> compiling Compiler.m3> new source -> compiling RTAllocator.i3> new source -> compiling RTType.i3> new source -> compiling Csetjmp.i3> new source -> compiling BasicCtypes.i3> new source -> compiling Ctypes.i3> new source -> compiling RTMachine.i3> new source -> compiling RTHeapDep.i3> new source -> compiling RTHeapRep.i3> new source -> compiling ThreadF.i3> new source -> compiling RTOS.i3> new source -> compiling RTMisc.i3> new source -> compiling RTHeap.i3> new source -> compiling Cstdlib.i3> new source -> compiling Cstddef.i3> new source -> compiling RTAllocCnts.i3> new source -> compiling RTAllocator.m3> new source -> compiling RTAllocStats.i3> new source -> compiling Convert.i3> new source -> compiling TextClass.i3> new source -> compiling Text.i3> new source -> compiling RTProcedureSRC.i3> new source -> compiling Fingerprint.i3> new source -> compiling RTProcedure.i3> new source -> compiling RTStack.i3> new source -> compiling RTAllocStats.m3> "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > symbol !! (R> THooks.AllocateTracedRef)>>> ***> *** runtime error:> *** Attempt to reference an illegal memory location.> *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3> ***>> Stack trace:> FP PC Procedure> --------- --------- -------------------------------> 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > \RTSignal.m3> 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3> 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3> 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3> 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3> 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3> 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3> 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3> 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3> 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3> ......... ......... ... more frames ...>> C:\cm3-cvs\cm3\m3-libs\m3core>> >You need to recompile m3core before compiling with the new compiler.>> >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote:>> > Hi all:> > Im getting this runtiem error because the symbol> >> > missing version stamps -> compiling RTAllocStats.m3> > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime> > symbol !! (R> > THooks.AllocateTracedRef)> >> > AllocateTracedRef is not defined in the m3core version of this Dll> > (I guess the change is more new than the bootstrap compiler). How> > can avoid this issue?> >> > Thanks in advance> >> > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd> > INSTALLROOT=C:\cm3> > LIB=%INSTALLROOT%\LIB;%LIB%> > CM3ROOT=C:\\cm3-cvs\\cm3> > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override -> > DROOT=C:\\cm3-c> > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner> > m3tools m3cgcat m3c> > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph> > parseparams realgeo> > metry set slisp sortedtableextras table-list tempfiles tcp tapi> > === package C:\cm3-cvs\cm3\m3-win\import-libs ===> > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++> > --- building in NT386 ---> >> > unable to read ..\src\m3overrides, options "-override" and "-x"> > ignored.> > === package C:\cm3-cvs\cm3\m3-libs\m3core ===> > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++> > --- building in NT386 ---> >> > missing version stamps -> compiling RTAllocStats.m3> > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime> > symbol !! (R> > THooks.AllocateTracedRef)> >> >> > ***> > *** runtime error:> > *** Attempt to reference an illegal memory location.> > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3> > ***> >> > Stack trace:> > FP PC Procedure> > --------- --------- -------------------------------> > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386> > \RTSignal.m3> > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3> > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3> > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3> > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3> > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3> > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3> > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3> > 0x12f63c 0x544d7f PrepForEmit + 0x81 in> ..\src\stmts\AssignStmt.m3> > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3> > ......... ......... ... more frames ...> > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3> > failed with 0 ***> > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -> > override -DROOT=C> > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake> > m3scanner m3tools m3c> > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector> > digraph parseparams> > realgeometry set slisp sortedtableextras table-list tempfiles tcp> > tapi failed> >> > C:\cm3-cvs\cm3\scripts\win> S? un Mejor Amante del Cine?Quieres saber c?mo? ?Deja que otras personas te ayuden! . _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 19 16:55:24 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 19 Sep 2007 10:55:24 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: References: <940950.96289.qm@web27108.mail.ukl.yahoo.com> Message-ID: <889F2EFF-2F38-4FB8-BBF2-08104548E060@cs.purdue.edu> It strikes me that you may need to sequence as follows to avoid running into having a compiler that does not handle LONGINT. Using the "devel_LONGINT_start" tagged versions of m3core and libm3 from CVS, using your original compiler, build and ship in the following order: m3core (devel_LONGINT_start) libm3 (devel_LONGINT_start) m3middle m3linker m3front m3quake cm3 Now you have a new compiler linked against the old m3core. Using the new compiler (in cm3/NT386), and the CVS head versions of m3core and libm3, build and ship in the following order: m3core (CVS head) libm3 (CVS head) m3middle m3linker m3front m3quake cm3 Now you have a new compiler linked against the new m3core. Copy this new compiler to your CM3 installation bin directory. Use this new compiler to rebuild the world. On Sep 18, 2007, at 8:41 PM, Jay wrote: > Daniel, can you try just going back to 5.2.6 and running scripts\win > \update? > You should be able to build the current source the last "official" > Win32 binaries, as long as you build in the correct order and all, > which the update.cmd does. You know, there's a certain mentality > around bootstrapping and keeping the connection back to the > previous version, that I upheld. As long as you are careful, you > can go from old binaries to new binaries, you don't have to get the > new binaries magically somewhere, though you do need the old > binaries magically from somewhere. :) > > Perhaps there's a regression. I can check "later". > > - Jay > Date: Wed, 19 Sep 2007 00:49:57 +0200 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compiler > > Hi: > > I have compiled with the Jay produced 5.5 bootstrap compiler, and > also with 5.1.3a, > 5.2.6 and get the same error. > > Thanks > > >You need to compile the new m3core with the old compiler so that the > >symbol is available to you when you compile using the new compiler. > >This is a classical bootstrapping problem. > > >On Sep 18, 2007, at 6:30 PM, Daniel Alejandro Benavides D. wrote: > > > Hi: > > Thanks for your answer, I have done that and also I get the same > > runtime error > > in the same source file: > > > > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > > --- building in NT386 --- > > > > ignoring ..\src\m3overrides > > > > new source -> compiling RTHooks.i3 > > new source -> compiling RT0.i3 > > new source -> compiling RuntimeError.i3 > > new source -> compiling Word.i3 > > new source -> compiling RTException.i3 > > new source -> compiling RTHooks.m3 > > new source -> compiling RT0.m3 > > new source -> compiling Compiler.i3 > > new source -> compiling RuntimeError.m3 > > new source -> compiling Compiler.m3 > > new source -> compiling RTAllocator.i3 > > new source -> compiling RTType.i3 > > new source -> compiling Csetjmp.i3 > > new source -> compiling BasicCtypes.i3 > > new source -> compiling Ctypes.i3 > > new source -> compiling RTMachine.i3 > > new source -> compiling RTHeapDep.i3 > > new source -> compiling RTHeapRep.i3 > > new source -> compiling ThreadF.i3 > > new source -> compiling RTOS.i3 > > new source -> compiling RTMisc.i3 > > new source -> compiling RTHeap.i3 > > new source -> compiling Cstdlib.i3 > > new source -> compiling Cstddef.i3 > > new source -> compiling RTAllocCnts.i3 > > new source -> compiling RTAllocator.m3 > > new source -> compiling RTAllocStats.i3 > > new source -> compiling Convert.i3 > > new source -> compiling TextClass.i3 > > new source -> compiling Text.i3 > > new source -> compiling RTProcedureSRC.i3 > > new source -> compiling Fingerprint.i3 > > new source -> compiling RTProcedure.i3 > > new source -> compiling RTStack.i3 > > new source -> compiling RTAllocStats.m3 > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined runtime > > symbol !! (R > > THooks.AllocateTracedRef) > > > > > > *** > > *** runtime error: > > *** Attempt to reference an illegal memory location. > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > *** > > > > Stack trace: > > FP PC Procedure > > --------- --------- ------------------------------- > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > \RTSignal.m3 > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in ..\src\stmts\AssignStmt.m3 > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > ......... ......... ... more frames ... > > > > C:\cm3-cvs\cm3\m3-libs\m3core> > > >You need to recompile m3core before compiling with the new > compiler. > > > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro Benavides D. wrote: > > > > > Hi all: > > > Im getting this runtiem error because the symbol > > > > > > missing version stamps -> compiling RTAllocStats.m3 > > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined > runtime > > > symbol !! (R > > > THooks.AllocateTracedRef) > > > > > > AllocateTracedRef is not defined in the m3core version of this Dll > > > (I guess the change is more new than the bootstrap compiler). How > > > can avoid this issue? > > > > > > Thanks in advance > > > > > > C:\cm3-cvs\cm3\scripts\win>do-cm3-base.cmd > > > INSTALLROOT=C:\cm3 > > > LIB=%INSTALLROOT%\LIB;%LIB% > > > CM3ROOT=C:\\cm3-cvs\\cm3 > > > call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build -override - > > > DROOT=C:\\cm3-c > > > vs\\cm3" import-libs m3core libm3 m3middle m3quake m3scanner > > > m3tools m3cgcat m3c > > > ggen m3bundle mklib dll2lib fix_nl libdump bitvector digraph > > > parseparams realgeo > > > metry set slisp sortedtableextras table-list tempfiles tcp tapi > > > === package C:\cm3-cvs\cm3\m3-win\import-libs === > > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > > --- building in NT386 --- > > > > > > unable to read ..\src\m3overrides, options "-override" and "-x" > > > ignored. > > > === package C:\cm3-cvs\cm3\m3-libs\m3core === > > > +++ "cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3" +++ > > > --- building in NT386 --- > > > > > > missing version stamps -> compiling RTAllocStats.m3 > > > "..\src\runtime\common\RTAllocStats.m3", line 46: undefined > runtime > > > symbol !! (R > > > THooks.AllocateTracedRef) > > > > > > > > > *** > > > *** runtime error: > > > *** Attempt to reference an illegal memory location. > > > *** pc = 0x4c4a0d = StartCall + 0xf in ..\src\values\Procedure.m3 > > > *** > > > > > > Stack trace: > > > FP PC Procedure > > > --------- --------- ------------------------------- > > > 0x12f494 0x60b3ce SystemError + 0x66 in ..\src\runtime\NT386 > > > \RTSignal.m3 > > > 0x12f4c4 0x4c4a0d StartCall + 0xf in ..\src\values\Procedure.m3 > > > 0x12f524 0x51beb8 GenRecord + 0x73 in ..\src\builtinOps\New.m3 > > > 0x12f58c 0x51b8a3 GenRef + 0x111 in ..\src\builtinOps\New.m3 > > > 0x12f5c8 0x51b70f Gen + 0x12d in ..\src\builtinOps\New.m3 > > > 0x12f5e0 0x51b4a3 Prep + 0x15 in ..\src\builtinOps\New.m3 > > > 0x12f600 0x550f08 Prep + 0x75 in ..\src\exprs\CallExpr.m3 > > > 0x12f61c 0x54312d Prep + 0x54 in ..\src\exprs\Expr.m3 > > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > > ..\src\stmts\AssignStmt.m3 > > > 0x12f66c 0x54453b Compile + 0xd6 in ..\src\stmts\AssignStmt.m3 > > > ......... ......... ... more frames ... > > > *** execution of cm3 -build -override -DROOT=C:\\cm3-cvs\\cm3 > > > failed with 0 *** > > > error : call C:\cm3-cvs\cm3\scripts\win\pkgmap -c "cm3 -build - > > > override -DROOT=C > > > :\\cm3-cvs\\cm3" import-libs m3core libm3 m3middle m3quake > > > m3scanner m3tools m3c > > > gcat m3cggen m3bundle mklib dll2lib fix_nl libdump bitvector > > > digraph parseparams > > > realgeometry set slisp sortedtableextras table-list tempfiles tcp > > > tapi failed > > > > > > C:\cm3-cvs\cm3\scripts\win> > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . > > Make your little one a shining star! Shine on! From dabenavidesd at yahoo.es Thu Sep 20 17:15:01 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 20 Sep 2007 17:15:01 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <889F2EFF-2F38-4FB8-BBF2-08104548E060@cs.purdue.edu> Message-ID: <894591.8437.qm@web27109.mail.ukl.yahoo.com> Hi: Thanks for your suggestions. I have tried the scripts/win/upgrade.cmd, and It does compile and then you can execute do-cm3-std.cmd. However I noticed the that script exports a m3core pkg to the repository with a m3core-d5.5 like suffix. Not sure what is this for. I will test if it can recognize the LONGINT datatype. Also I have a question about Tony's suggestion. The packages m3objfile and m3back are not ncessary on the stages you mention for NT386 target? Thanks --- Tony Hosking escribi?: > It strikes me that you may need to sequence as > follows to avoid > running into having a compiler that does not handle > LONGINT. > > Using the "devel_LONGINT_start" tagged versions of > m3core and libm3 > from CVS, > using your original compiler, build and ship in the > following order: > > m3core (devel_LONGINT_start) > libm3 (devel_LONGINT_start) > m3middle > m3linker > m3front > m3quake > cm3 > > Now you have a new compiler linked against the old > m3core. > > Using the new compiler (in cm3/NT386), and the CVS > head versions of > m3core and libm3, > build and ship in the following order: > > m3core (CVS head) > libm3 (CVS head) > m3middle > m3linker > m3front > m3quake > cm3 > > Now you have a new compiler linked against the new > m3core. > > Copy this new compiler to your CM3 installation bin > directory. > > Use this new compiler to rebuild the world. > > > On Sep 18, 2007, at 8:41 PM, Jay wrote: > > > Daniel, can you try just going back to 5.2.6 and > running scripts\win > > \update? > > You should be able to build the current source the > last "official" > > Win32 binaries, as long as you build in the > correct order and all, > > which the update.cmd does. You know, there's a > certain mentality > > around bootstrapping and keeping the connection > back to the > > previous version, that I upheld. As long as you > are careful, you > > can go from old binaries to new binaries, you > don't have to get the > > new binaries magically somewhere, though you do > need the old > > binaries magically from somewhere. :) > > > > Perhaps there's a regression. I can check "later". > > > > - Jay > > Date: Wed, 19 Sep 2007 00:49:57 +0200 > > From: dabenavidesd at yahoo.es > > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Subject: Re: [M3devel] NT386 with cm3-5.5 > bootstrap compiler > > > > Hi: > > > > I have compiled with the Jay produced 5.5 > bootstrap compiler, and > > also with 5.1.3a, > > 5.2.6 and get the same error. > > > > Thanks > > > > >You need to compile the new m3core with the old > compiler so that the > > >symbol is available to you when you compile using > the new compiler. > > >This is a classical bootstrapping problem. > > > > >On Sep 18, 2007, at 6:30 PM, Daniel Alejandro > Benavides D. wrote: > > > > > Hi: > > > Thanks for your answer, I have done that and > also I get the same > > > runtime error > > > in the same source file: > > > > > > > > > C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > > > --- building in NT386 --- > > > > > > ignoring ..\src\m3overrides > > > > > > new source -> compiling RTHooks.i3 > > > new source -> compiling RT0.i3 > > > new source -> compiling RuntimeError.i3 > > > new source -> compiling Word.i3 > > > new source -> compiling RTException.i3 > > > new source -> compiling RTHooks.m3 > > > new source -> compiling RT0.m3 > > > new source -> compiling Compiler.i3 > > > new source -> compiling RuntimeError.m3 > > > new source -> compiling Compiler.m3 > > > new source -> compiling RTAllocator.i3 > > > new source -> compiling RTType.i3 > > > new source -> compiling Csetjmp.i3 > > > new source -> compiling BasicCtypes.i3 > > > new source -> compiling Ctypes.i3 > > > new source -> compiling RTMachine.i3 > > > new source -> compiling RTHeapDep.i3 > > > new source -> compiling RTHeapRep.i3 > > > new source -> compiling ThreadF.i3 > > > new source -> compiling RTOS.i3 > > > new source -> compiling RTMisc.i3 > > > new source -> compiling RTHeap.i3 > > > new source -> compiling Cstdlib.i3 > > > new source -> compiling Cstddef.i3 > > > new source -> compiling RTAllocCnts.i3 > > > new source -> compiling RTAllocator.m3 > > > new source -> compiling RTAllocStats.i3 > > > new source -> compiling Convert.i3 > > > new source -> compiling TextClass.i3 > > > new source -> compiling Text.i3 > > > new source -> compiling RTProcedureSRC.i3 > > > new source -> compiling Fingerprint.i3 > > > new source -> compiling RTProcedure.i3 > > > new source -> compiling RTStack.i3 > > > new source -> compiling RTAllocStats.m3 > > > "..\src\runtime\common\RTAllocStats.m3", line > 46: undefined runtime > > > symbol !! (R > > > THooks.AllocateTracedRef) > > > > > > > > > *** > > > *** runtime error: > > > *** Attempt to reference an illegal memory > location. > > > *** pc = 0x4c4a0d = StartCall + 0xf in > ..\src\values\Procedure.m3 > > > *** > > > > > > Stack trace: > > > FP PC Procedure > > > --------- --------- > ------------------------------- > > > 0x12f494 0x60b3ce SystemError + 0x66 in > ..\src\runtime\NT386 > > > \RTSignal.m3 > > > 0x12f4c4 0x4c4a0d StartCall + 0xf in > ..\src\values\Procedure.m3 > > > 0x12f524 0x51beb8 GenRecord + 0x73 in > ..\src\builtinOps\New.m3 > > > 0x12f58c 0x51b8a3 GenRef + 0x111 in > ..\src\builtinOps\New.m3 > > > 0x12f5c8 0x51b70f Gen + 0x12d in > ..\src\builtinOps\New.m3 > > > 0x12f5e0 0x51b4a3 Prep + 0x15 in > ..\src\builtinOps\New.m3 > > > 0x12f600 0x550f08 Prep + 0x75 in > ..\src\exprs\CallExpr.m3 > > > 0x12f61c 0x54312d Prep + 0x54 in > ..\src\exprs\Expr.m3 > > > 0x12f63c 0x544d7f PrepForEmit + 0x81 in > ..\src\stmts\AssignStmt.m3 > > > 0x12f66c 0x54453b Compile + 0xd6 in > ..\src\stmts\AssignStmt.m3 > > > ......... ......... ... more frames ... > > > > > > C:\cm3-cvs\cm3\m3-libs\m3core> > > > >You need to recompile m3core before compiling > with the new > > compiler. > > > > > > >On Sep 18, 2007, at 5:29 PM, Daniel Alejandro > Benavides D. wrote: > > > > > > > Hi all: > > > > Im getting this runtiem error because the > symbol > > > > > > > > missing version stamps -> compiling > RTAllocStats.m3 > > > > "..\src\runtime\common\RTAllocStats.m3", line > 46: undefined > > runtime > > > > symbol !! (R > > > > THooks.AllocateTracedRef) > > > > > > > > AllocateTracedRef is not defined in the m3core > version === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Thu Sep 20 18:15:26 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 20 Sep 2007 12:15:26 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <894591.8437.qm@web27109.mail.ukl.yahoo.com> References: <894591.8437.qm@web27109.mail.ukl.yahoo.com> Message-ID: On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your suggestions. I have tried the > scripts/win/upgrade.cmd, and It does compile and then > you can execute do-cm3-std.cmd. > > However I noticed the that script exports a m3core pkg > to the repository with a m3core-d5.5 like suffix. Not > sure what is this for. > > I will test if it can recognize the LONGINT datatype. > > Also I have a question about Tony's suggestion. The > packages m3objfile and m3back are not ncessary on the > stages you mention for NT386 target? Oh, yes, of course they are. Sorry, I forgot about that for NT386. > > Thanks > > --- Tony Hosking escribi?: > >> It strikes me that you may need to sequence as >> follows to avoid >> running into having a compiler that does not handle >> LONGINT. >> >> Using the "devel_LONGINT_start" tagged versions of >> m3core and libm3 >> from CVS, >> using your original compiler, build and ship in the >> following order: >> >> m3core (devel_LONGINT_start) >> libm3 (devel_LONGINT_start) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the old >> m3core. >> >> Using the new compiler (in cm3/NT386), and the CVS >> head versions of >> m3core and libm3, >> build and ship in the following order: >> >> m3core (CVS head) >> libm3 (CVS head) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the new >> m3core. >> >> Copy this new compiler to your CM3 installation bin >> directory. >> >> Use this new compiler to rebuild the world. >> >> >> On Sep 18, 2007, at 8:41 PM, Jay wrote: >> >>> Daniel, can you try just going back to 5.2.6 and >> running scripts\win >>> \update? >>> You should be able to build the current source the >> last "official" >>> Win32 binaries, as long as you build in the >> correct order and all, >>> which the update.cmd does. You know, there's a >> certain mentality >>> around bootstrapping and keeping the connection >> back to the >>> previous version, that I upheld. As long as you >> are careful, you >>> can go from old binaries to new binaries, you >> don't have to get the >>> new binaries magically somewhere, though you do >> need the old >>> binaries magically from somewhere. :) >>> >>> Perhaps there's a regression. I can check "later". >>> >>> - Jay >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 >>> From: dabenavidesd at yahoo.es >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> >>> Hi: >>> >>> I have compiled with the Jay produced 5.5 >> bootstrap compiler, and >>> also with 5.1.3a, >>> 5.2.6 and get the same error. >>> >>> Thanks >>> >>>> You need to compile the new m3core with the old >> compiler so that the >>>> symbol is available to you when you compile using >> the new compiler. >>>> This is a classical bootstrapping problem. >>> >>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro >> Benavides D. wrote: >>> >>>> Hi: >>>> Thanks for your answer, I have done that and >> also I get the same >>>> runtime error >>>> in the same source file: >>>> >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3 >>>> --- building in NT386 --- >>>> >>>> ignoring ..\src\m3overrides >>>> >>>> new source -> compiling RTHooks.i3 >>>> new source -> compiling RT0.i3 >>>> new source -> compiling RuntimeError.i3 >>>> new source -> compiling Word.i3 >>>> new source -> compiling RTException.i3 >>>> new source -> compiling RTHooks.m3 >>>> new source -> compiling RT0.m3 >>>> new source -> compiling Compiler.i3 >>>> new source -> compiling RuntimeError.m3 >>>> new source -> compiling Compiler.m3 >>>> new source -> compiling RTAllocator.i3 >>>> new source -> compiling RTType.i3 >>>> new source -> compiling Csetjmp.i3 >>>> new source -> compiling BasicCtypes.i3 >>>> new source -> compiling Ctypes.i3 >>>> new source -> compiling RTMachine.i3 >>>> new source -> compiling RTHeapDep.i3 >>>> new source -> compiling RTHeapRep.i3 >>>> new source -> compiling ThreadF.i3 >>>> new source -> compiling RTOS.i3 >>>> new source -> compiling RTMisc.i3 >>>> new source -> compiling RTHeap.i3 >>>> new source -> compiling Cstdlib.i3 >>>> new source -> compiling Cstddef.i3 >>>> new source -> compiling RTAllocCnts.i3 >>>> new source -> compiling RTAllocator.m3 >>>> new source -> compiling RTAllocStats.i3 >>>> new source -> compiling Convert.i3 >>>> new source -> compiling TextClass.i3 >>>> new source -> compiling Text.i3 >>>> new source -> compiling RTProcedureSRC.i3 >>>> new source -> compiling Fingerprint.i3 >>>> new source -> compiling RTProcedure.i3 >>>> new source -> compiling RTStack.i3 >>>> new source -> compiling RTAllocStats.m3 >>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined runtime >>>> symbol !! (R >>>> THooks.AllocateTracedRef) >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Attempt to reference an illegal memory >> location. >>>> *** pc = 0x4c4a0d = StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- >> ------------------------------- >>>> 0x12f494 0x60b3ce SystemError + 0x66 in >> ..\src\runtime\NT386 >>>> \RTSignal.m3 >>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> 0x12f524 0x51beb8 GenRecord + 0x73 in >> ..\src\builtinOps\New.m3 >>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in >> ..\src\builtinOps\New.m3 >>>> 0x12f5c8 0x51b70f Gen + 0x12d in >> ..\src\builtinOps\New.m3 >>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in >> ..\src\builtinOps\New.m3 >>>> 0x12f600 0x550f08 Prep + 0x75 in >> ..\src\exprs\CallExpr.m3 >>>> 0x12f61c 0x54312d Prep + 0x54 in >> ..\src\exprs\Expr.m3 >>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in >> ..\src\stmts\AssignStmt.m3 >>>> 0x12f66c 0x54453b Compile + 0xd6 in >> ..\src\stmts\AssignStmt.m3 >>>> ......... ......... ... more frames ... >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core> >>>>> You need to recompile m3core before compiling >> with the new >>> compiler. >>>> >>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro >> Benavides D. wrote: >>>> >>>>> Hi all: >>>>> Im getting this runtiem error because the >> symbol >>>>> >>>>> missing version stamps -> compiling >> RTAllocStats.m3 >>>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined >>> runtime >>>>> symbol !! (R >>>>> THooks.AllocateTracedRef) >>>>> >>>>> AllocateTracedRef is not defined in the m3core >> version > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Thu Sep 20 22:53:35 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 20 Sep 2007 22:53:35 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: Message-ID: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Hi: The script upgarde.cmd produced compiler does recognize the LONGINT as a reserved word. I can get this error when compiling the m2libs of m2tom3 compiler: new source -> compiling SYSTEM.i3 "..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT) 1 error encountered Thanks again >On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote: > Hi: > Thanks for your suggestions. I have tried the > scripts/win/upgrade.cmd, and It does compile and then > you can execute do-cm3-std.cmd. > > However I noticed the that script exports a m3core pkg > to the repository with a m3core-d5.5 like suffix. Not > sure what is this for. > > I will test if it can recognize the LONGINT datatype. > > Also I have a question about Tony's suggestion. The > packages m3objfile and m3back are not ncessary on the > stages you mention for NT386 target? >Oh, yes, of course they are. Sorry, I forgot about that for NT386. > > Thanks > > --- Tony Hosking escribi?: > >> It strikes me that you may need to sequence as >> follows to avoid >> running into having a compiler that does not handle >> LONGINT. >> >> Using the "devel_LONGINT_start" tagged versions of >> m3core and libm3 >> from CVS, >> using your original compiler, build and ship in the >> following order: >> >> m3core (devel_LONGINT_start) >> libm3 (devel_LONGINT_start) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the old >> m3core. >> >> Using the new compiler (in cm3/NT386), and the CVS >> head versions of >> m3core and libm3, >> build and ship in the following order: >> >> m3core (CVS head) >> libm3 (CVS head) >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> Now you have a new compiler linked against the new >> m3core. >> >> Copy this new compiler to your CM3 installation bin >> directory. >> >> Use this new compiler to rebuild the world. >> >> >> On Sep 18, 2007, at 8:41 PM, Jay wrote: >> >>> Daniel, can you try just going back to 5.2.6 and >> running scripts\win >>> \update? >>> You should be able to build the current source the >> last "official" >>> Win32 binaries, as long as you build in the >> correct order and all, >>> which the update.cmd does. You know, there's a >> certain mentality >>> around bootstrapping and keeping the connection >> back to the >>> previous version, that I upheld. As long as you >> are careful, you >>> can go from old binaries to new binaries, you >> don't have to get the >>> new binaries magically somewhere, though you do >> need the old >>> binaries magically from somewhere. :) >>> >>> Perhaps there's a regression. I can check "later". >>> >>> - Jay >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 >>> From: dabenavidesd at yahoo.es >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> >>> Hi: >>> >>> I have compiled with the Jay produced 5.5 >> bootstrap compiler, and >>> also with 5.1.3a, >>> 5.2.6 and get the same error. >>> >>> Thanks >>> >>>> You need to compile the new m3core with the old >> compiler so that the >>>> symbol is available to you when you compile using >> the new compiler. >>>> This is a classical bootstrapping problem. >>> >>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro >> Benavides D. wrote: >>> >>>> Hi: >>>> Thanks for your answer, I have done that and >> also I get the same >>>> runtime error >>>> in the same source file: >>>> >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3 >>>> --- building in NT386 --- >>>> >>>> ignoring ..\src\m3overrides >>>> >>>> new source -> compiling RTHooks.i3 >>>> new source -> compiling RT0.i3 >>>> new source -> compiling RuntimeError.i3 >>>> new source -> compiling Word.i3 >>>> new source -> compiling RTException.i3 >>>> new source -> compiling RTHooks.m3 >>>> new source -> compiling RT0.m3 >>>> new source -> compiling Compiler.i3 >>>> new source -> compiling RuntimeError.m3 >>>> new source -> compiling Compiler.m3 >>>> new source -> compiling RTAllocator.i3 >>>> new source -> compiling RTType.i3 >>>> new source -> compiling Csetjmp.i3 >>>> new source -> compiling BasicCtypes.i3 >>>> new source -> compiling Ctypes.i3 >>>> new source -> compiling RTMachine.i3 >>>> new source -> compiling RTHeapDep.i3 >>>> new source -> compiling RTHeapRep.i3 >>>> new source -> compiling ThreadF.i3 >>>> new source -> compiling RTOS.i3 >>>> new source -> compiling RTMisc.i3 >>>> new source -> compiling RTHeap.i3 >>>> new source -> compiling Cstdlib.i3 >>>> new source -> compiling Cstddef.i3 >>>> new source -> compiling RTAllocCnts.i3 >>>> new source -> compiling RTAllocator.m3 >>>> new source -> compiling RTAllocStats.i3 >>>> new source -> compiling Convert.i3 >>>> new source -> compiling TextClass.i3 >>>> new source -> compiling Text.i3 >>>> new source -> compiling RTProcedureSRC.i3 >>>> new source -> compiling Fingerprint.i3 >>>> new source -> compiling RTProcedure.i3 >>>> new source -> compiling RTStack.i3 >>>> new source -> compiling RTAllocStats.m3 >>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined runtime >>>> symbol !! (R >>>> THooks.AllocateTracedRef) >>>> >>>> >>>> *** >>>> *** runtime error: >>>> *** Attempt to reference an illegal memory >> location. >>>> *** pc = 0x4c4a0d = StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> *** >>>> >>>> Stack trace: >>>> FP PC Procedure >>>> --------- --------- >> ------------------------------- >>>> 0x12f494 0x60b3ce SystemError + 0x66 in >> ..\src\runtime\NT386 >>>> \RTSignal.m3 >>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in >> ..\src\values\Procedure.m3 >>>> 0x12f524 0x51beb8 GenRecord + 0x73 in >> ..\src\builtinOps\New.m3 >>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in >> ..\src\builtinOps\New.m3 >>>> 0x12f5c8 0x51b70f Gen + 0x12d in >> ..\src\builtinOps\New.m3 >>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in >> ..\src\builtinOps\New.m3 >>>> 0x12f600 0x550f08 Prep + 0x75 in >> ..\src\exprs\CallExpr.m3 >>>> 0x12f61c 0x54312d Prep + 0x54 in >> ..\src\exprs\Expr.m3 >>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in >> ..\src\stmts\AssignStmt.m3 >>>> 0x12f66c 0x54453b Compile + 0xd6 in >> ..\src\stmts\AssignStmt.m3 >>>> ......... ......... ... more frames ... >>>> >>>> C:\cm3-cvs\cm3\m3-libs\m3core> >>>>> You need to recompile m3core before compiling >> with the new >>> compiler. >>>> >>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro >> Benavides D. wrote: >>>> >>>>> Hi all: >>>>> Im getting this runtiem error because the >> symbol >>>>> >>>>> missing version stamps -> compiling >> RTAllocStats.m3 >>>>> "..\src\runtime\common\RTAllocStats.m3", line >> 46: undefined >>> runtime >>>>> symbol !! (R >>>>> THooks.AllocateTracedRef) >>>>> >>>>> AllocateTracedRef is not defined in the m3core >> version --------------------------------- S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 21 02:49:21 2007 From: jay.krell at cornell.edu (Jay) Date: Fri, 21 Sep 2007 00:49:21 +0000 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <9243.42411.qm@web27110.mail.ukl.yahoo.com> References: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Message-ID: The "-d5.5" thing is a backup of the package repository. Indeed I find it annoying sometimes, but I mimiced upgrade.sh and I'd have to think it all through again before deleting/changing how it works. I think it makes it easier to back out of a broken change. If you end up with non-working stuff, you copy pkg-d5.5 back on top of pkg. I really strongly suspect update.cmd works. I don't remember if it upgrades...oh, sorry, wrong script I think. make-dist.cmd? How about that one? Whichever one creates .tar.bz2 files. That's the one I meant. Oops, sorry sorry sorry. :\ - Jay Date: Thu, 20 Sep 2007 22:53:35 +0200From: dabenavidesd at yahoo.esTo: hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compilerHi:The script upgarde.cmd produced compiler does recognize the LONGINT as a reserved word.I can get this error when compiling the m2libs of m2tom3 compiler:new source -> compiling SYSTEM.i3"..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT)1 error encounteredThanks again>On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote:> Hi:> Thanks for your suggestions. I have tried the> scripts/win/upgrade.cmd, and It does compile and then> you can execute do-cm3-std.cmd.>> However I noticed the that script exports a m3core pkg> to the repository with a m3core-d5.5 like suffix. Not> sure what is this for.>> I will test if it can recognize the LONGINT datatype.>> Also I have a question about Tony's suggestion. The> packages m3objfile and m3back are not ncessary on the> stages you mention for NT386 target?>Oh, yes, of course they are. Sorry, I forgot about that for NT386.>> Thanks>> --- Tony Hosking escribi?:>>> It strikes me that you may need to sequence as>> follows to avoid>> running into having a compiler that does not handle>> LONGINT.>>>> Using the "devel_LONGINT_start" tagged versions of>> m3core and libm3>> from CVS,>> using your original compiler, build and ship in the>> following order:>>>> m3core (devel_LONGINT_start)>> libm3 (devel_LONGINT_start)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the old>> m3core.>>>> Using the new compiler (in cm3/NT386), and the CVS>> head versions of>> m3core and libm3,>> build and ship in the following order:>>>> m3core (CVS head)>> libm3 (CVS head)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the new>> m3core.>>>> Copy this new compiler to your CM3 installation bin>> directory.>>>> Use this new compiler to rebuild the world.>>>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote:>>>>> Daniel, can you try just going back to 5.2.6 and>> running scripts\win>>> \update?>>> You should be able to build the current source the>> last "official">>> Win32 binaries, as long as you build in the>> correct order and all,>>> which the update.cmd does. You know, there's a>> certain mentality>>> around bootstrapping and keeping the connection>> back to the>>> previous version, that I upheld. As long as you>> are careful, you>>> can go from old binaries to new binaries, you>> don't have to get the>>> new binaries magically somewhere, though you do>> need the old>>> binaries magically from somewhere. :)>>>>>> Perhaps there's a regression. I can check "later".>>>>>> - Jay>>> Date: Wed, 19 Sep 2007 00:49:57 +0200>>> From: dabenavidesd at yahoo.es>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com>>> Subject: Re: [M3devel] NT386 with cm3-5.5>> bootstrap compiler>>>>>> Hi:>>>>>> I have compiled with the Jay produced 5.5>> bootstrap compiler, and>>> also with 5.1.3a,>>> 5.2.6 and get the same error.>>>>>> Thanks>>>>>>> You need to compile the new m3core with the old>> compiler so that the>>>> symbol is available to you when you compile using>> the new compiler.>>>> This is a classical bootstrapping problem.>>>>>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>> Hi:>>>> Thanks for your answer, I have done that and>> also I get the same>>>> runtime error>>>> in the same source file:>>>>>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3>>>> --- building in NT386 --->>>>>>>> ignoring ..\src\m3overrides>>>>>>>> new source -> compiling RTHooks.i3>>>> new source -> compiling RT0.i3>>>> new source -> compiling RuntimeError.i3>>>> new source -> compiling Word.i3>>>> new source -> compiling RTException.i3>>>> new source -> compiling RTHooks.m3>>>> new source -> compiling RT0.m3>>>> new source -> compiling Compiler.i3>>>> new source -> compiling RuntimeError.m3>>>> new source -> compiling Compiler.m3>>>> new source -> compiling RTAllocator.i3>>>> new source -> compiling RTType.i3>>>> new source -> compiling Csetjmp.i3>>>> new source -> compiling BasicCtypes.i3>>>> new source -> compiling Ctypes.i3>>>> new source -> compiling RTMachine.i3>>>> new source -> compiling RTHeapDep.i3>>>> new source -> compiling RTHeapRep.i3>>>> new source -> compiling ThreadF.i3>>>> new source -> compiling RTOS.i3>>>> new source -> compiling RTMisc.i3>>>> new source -> compiling RTHeap.i3>>>> new source -> compiling Cstdlib.i3>>>> new source -> compiling Cstddef.i3>>>> new source -> compiling RTAllocCnts.i3>>>> new source -> compiling RTAllocator.m3>>>> new source -> compiling RTAllocStats.i3>>>> new source -> compiling Convert.i3>>>> new source -> compiling TextClass.i3>>>> new source -> compiling Text.i3>>>> new source -> compiling RTProcedureSRC.i3>>>> new source -> compiling Fingerprint.i3>>>> new source -> compiling RTProcedure.i3>>>> new source -> compiling RTStack.i3>>>> new source -> compiling RTAllocStats.m3>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined runtime>>>> symbol !! (R>>>> THooks.AllocateTracedRef)>>>>>>>>>>>> ***>>>> *** runtime error:>>>> *** Attempt to reference an illegal memory>> location.>>>> *** pc = 0x4c4a0d = StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> ***>>>>>>>> Stack trace:>>>> FP PC Procedure>>>> --------- --------->> ------------------------------->>>> 0x12f494 0x60b3ce SystemError + 0x66 in>> ..\src\runtime\NT386>>>> \RTSignal.m3>>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> 0x12f524 0x51beb8 GenRecord + 0x73 in>> ..\src\builtinOps\New.m3>>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in>> ..\src\builtinOps\New.m3>>>> 0x12f5c8 0x51b70f Gen + 0x12d in>> ..\src\builtinOps\New.m3>>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in>> ..\src\builtinOps\New.m3>>>> 0x12f600 0x550f08 Prep + 0x75 in>> ..\src\exprs\CallExpr.m3>>>> 0x12f61c 0x54312d Prep + 0x54 in>> ..\src\exprs\Expr.m3>>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in>> ..\src\stmts\AssignStmt.m3>>>> 0x12f66c 0x54453b Compile + 0xd6 in>> ..\src\stmts\AssignStmt.m3>>>> ......... ......... ... more frames ...>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>>>>>> You need to recompile m3core before compiling>> with the new>>> compiler.>>>>>>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>>>> Hi all:>>>>> Im getting this runtiem error because the>> symbol>>>>>>>>>> missing version stamps -> compiling>> RTAllocStats.m3>>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined>>> runtime>>>>> symbol !! (R>>>>> THooks.AllocateTracedRef)>>>>>>>>>> AllocateTracedRef is not defined in the m3core>> version S? un Mejor Amante del Cine?Quieres saber c?mo? ?Deja que otras personas te ayuden! . _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 21 02:50:51 2007 From: jay.krell at cornell.edu (Jay) Date: Fri, 21 Sep 2007 00:50:51 +0000 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <9243.42411.qm@web27110.mail.ukl.yahoo.com> References: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Message-ID: As a follow up to confirm, look where I made changes since LONGINT, I believe make-dist in particular I had to make changes to to build the right packages in the right order. I'll look into upgrade/update sometime soon.. - Jay From: jay.krell at cornell.eduTo: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: RE: [M3devel] NT386 with cm3-5.5 bootstrap compilerDate: Fri, 21 Sep 2007 00:49:21 +0000 The "-d5.5" thing is a backup of the package repository. Indeed I find it annoying sometimes, but I mimiced upgrade.sh and I'd have to think it all through again before deleting/changing how it works. I think it makes it easier to back out of a broken change. If you end up with non-working stuff, you copy pkg-d5.5 back on top of pkg. I really strongly suspect update.cmd works. I don't remember if it upgrades...oh, sorry, wrong script I think.make-dist.cmd? How about that one?Whichever one creates .tar.bz2 files. That's the one I meant. Oops, sorry sorry sorry. :\ - Jay Date: Thu, 20 Sep 2007 22:53:35 +0200From: dabenavidesd at yahoo.esTo: hosking at cs.purdue.edu; m3devel at elegosoft.comSubject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compilerHi:The script upgarde.cmd produced compiler does recognize the LONGINT as a reserved word.I can get this error when compiling the m2libs of m2tom3 compiler:new source -> compiling SYSTEM.i3"..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT)1 error encounteredThanks again>On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote:> Hi:> Thanks for your suggestions. I have tried the> scripts/win/upgrade.cmd, and It does compile and then> you can execute do-cm3-std.cmd.>> However I noticed the that script exports a m3core pkg> to the repository with a m3core-d5.5 like suffix. Not> sure what is this for.>> I will test if it can recognize the LONGINT datatype.>> Also I have a question about Tony's suggestion. The> packages m3objfile and m3back are not ncessary on the> stages you mention for NT386 target?>Oh, yes, of course they are. Sorry, I forgot about that for NT386.>> Thanks>> --- Tony Hosking escribi?:>>> It strikes me that you may need to sequence as>> follows to avoid>> running into having a compiler that does not handle>> LONGINT.>>>> Using the "devel_LONGINT_start" tagged versions of>> m3core and libm3>> from CVS,>> using your original compiler, build and ship in the>> following order:>>>> m3core (devel_LONGINT_start)>> libm3 (devel_LONGINT_start)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the old>> m3core.>>>> Using the new compiler (in cm3/NT386), and the CVS>> head versions of>> m3core and libm3,>> build and ship in the following order:>>>> m3core (CVS head)>> libm3 (CVS head)>> m3middle>> m3linker>> m3front>> m3quake>> cm3>>>> Now you have a new compiler linked against the new>> m3core.>>>> Copy this new compiler to your CM3 installation bin>> directory.>>>> Use this new compiler to rebuild the world.>>>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote:>>>>> Daniel, can you try just going back to 5.2.6 and>> running scripts\win>>> \update?>>> You should be able to build the current source the>> last "official">>> Win32 binaries, as long as you build in the>> correct order and all,>>> which the update.cmd does. You know, there's a>> certain mentality>>> around bootstrapping and keeping the connection>> back to the>>> previous version, that I upheld. As long as you>> are careful, you>>> can go from old binaries to new binaries, you>> don't have to get the>>> new binaries magically somewhere, though you do>> need the old>>> binaries magically from somewhere. :)>>>>>> Perhaps there's a regression. I can check "later".>>>>>> - Jay>>> Date: Wed, 19 Sep 2007 00:49:57 +0200>>> From: dabenavidesd at yahoo.es>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com>>> Subject: Re: [M3devel] NT386 with cm3-5.5>> bootstrap compiler>>>>>> Hi:>>>>>> I have compiled with the Jay produced 5.5>> bootstrap compiler, and>>> also with 5.1.3a,>>> 5.2.6 and get the same error.>>>>>> Thanks>>>>>>> You need to compile the new m3core with the old>> compiler so that the>>>> symbol is available to you when you compile using>> the new compiler.>>>> This is a classical bootstrapping problem.>>>>>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>> Hi:>>>> Thanks for your answer, I have done that and>> also I get the same>>>> runtime error>>>> in the same source file:>>>>>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3>>>> --- building in NT386 --->>>>>>>> ignoring ..\src\m3overrides>>>>>>>> new source -> compiling RTHooks.i3>>>> new source -> compiling RT0.i3>>>> new source -> compiling RuntimeError.i3>>>> new source -> compiling Word.i3>>>> new source -> compiling RTException.i3>>>> new source -> compiling RTHooks.m3>>>> new source -> compiling RT0.m3>>>> new source -> compiling Compiler.i3>>>> new source -> compiling RuntimeError.m3>>>> new source -> compiling Compiler.m3>>>> new source -> compiling RTAllocator.i3>>>> new source -> compiling RTType.i3>>>> new source -> compiling Csetjmp.i3>>>> new source -> compiling BasicCtypes.i3>>>> new source -> compiling Ctypes.i3>>>> new source -> compiling RTMachine.i3>>>> new source -> compiling RTHeapDep.i3>>>> new source -> compiling RTHeapRep.i3>>>> new source -> compiling ThreadF.i3>>>> new source -> compiling RTOS.i3>>>> new source -> compiling RTMisc.i3>>>> new source -> compiling RTHeap.i3>>>> new source -> compiling Cstdlib.i3>>>> new source -> compiling Cstddef.i3>>>> new source -> compiling RTAllocCnts.i3>>>> new source -> compiling RTAllocator.m3>>>> new source -> compiling RTAllocStats.i3>>>> new source -> compiling Convert.i3>>>> new source -> compiling TextClass.i3>>>> new source -> compiling Text.i3>>>> new source -> compiling RTProcedureSRC.i3>>>> new source -> compiling Fingerprint.i3>>>> new source -> compiling RTProcedure.i3>>>> new source -> compiling RTStack.i3>>>> new source -> compiling RTAllocStats.m3>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined runtime>>>> symbol !! (R>>>> THooks.AllocateTracedRef)>>>>>>>>>>>> ***>>>> *** runtime error:>>>> *** Attempt to reference an illegal memory>> location.>>>> *** pc = 0x4c4a0d = StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> ***>>>>>>>> Stack trace:>>>> FP PC Procedure>>>> --------- --------->> ------------------------------->>>> 0x12f494 0x60b3ce SystemError + 0x66 in>> ..\src\runtime\NT386>>>> \RTSignal.m3>>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in>> ..\src\values\Procedure.m3>>>> 0x12f524 0x51beb8 GenRecord + 0x73 in>> ..\src\builtinOps\New.m3>>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in>> ..\src\builtinOps\New.m3>>>> 0x12f5c8 0x51b70f Gen + 0x12d in>> ..\src\builtinOps\New.m3>>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in>> ..\src\builtinOps\New.m3>>>> 0x12f600 0x550f08 Prep + 0x75 in>> ..\src\exprs\CallExpr.m3>>>> 0x12f61c 0x54312d Prep + 0x54 in>> ..\src\exprs\Expr.m3>>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in>> ..\src\stmts\AssignStmt.m3>>>> 0x12f66c 0x54453b Compile + 0xd6 in>> ..\src\stmts\AssignStmt.m3>>>> ......... ......... ... more frames ...>>>>>>>> C:\cm3-cvs\cm3\m3-libs\m3core>>>>>> You need to recompile m3core before compiling>> with the new>>> compiler.>>>>>>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro>> Benavides D. wrote:>>>>>>>>> Hi all:>>>>> Im getting this runtiem error because the>> symbol>>>>>>>>>> missing version stamps -> compiling>> RTAllocStats.m3>>>>> "..\src\runtime\common\RTAllocStats.m3", line>> 46: undefined>>> runtime>>>>> symbol !! (R>>>>> THooks.AllocateTracedRef)>>>>>>>>>> AllocateTracedRef is not defined in the m3core>> version S? un Mejor Amante del Cine?Quieres saber c?mo? ?Deja que otras personas te ayuden! . Make your little one a shining star! Shine on! _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 21 17:15:40 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Sep 2007 11:15:40 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: References: <9243.42411.qm@web27110.mail.ukl.yahoo.com> Message-ID: <9CFCC906-27F5-471D-9D12-463BE33E2A28@cs.purdue.edu> On Sep 20, 2007, at 8:50 PM, Jay wrote: > As a follow up to confirm, look where I made changes since > LONGINT, I believe make-dist in particular I had to make changes to > to build the right packages in the right order. I'll look into > upgrade/update sometime soon.. > > - Jay > > From: jay.krell at cornell.edu > To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; > m3devel at elegosoft.com > Subject: RE: [M3devel] NT386 with cm3-5.5 bootstrap compiler > Date: Fri, 21 Sep 2007 00:49:21 +0000 > > The "-d5.5" thing is a backup of the package repository. Indeed I > find it annoying sometimes, but I mimiced upgrade.sh and I'd have > to think it all through again before deleting/changing how it > works. I think it makes it easier to back out of a broken change. > If you end up with non-working stuff, you copy pkg-d5.5 back on top > of pkg. > > I really strongly suspect update.cmd works. I don't remember if it > upgrades...oh, sorry, wrong script I think. > make-dist.cmd? How about that one? > Whichever one creates .tar.bz2 files. That's the one I meant. Oops, > sorry sorry sorry. :\ > > > - Jay > Date: Thu, 20 Sep 2007 22:53:35 +0200 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] NT386 with cm3-5.5 bootstrap compiler > > Hi: > > The script upgarde.cmd produced compiler does recognize the LONGINT > as a reserved word. > > I can get this error when compiling the m2libs of m2tom3 compiler: > > > new source -> compiling SYSTEM.i3 > "..\src\SYSTEM.i3", line 40: Reserved identifier redefined (LONGINT) > 1 error encountered > I don't see this file in the distribution. I suspect it is something to do with upgrade.cmd. I assume it is defining LONGINT for compilers that don't support it, though I fail to understand why this would be necessary. > Thanks again > > > > >On Sep 20, 2007, at 11:15 AM, Daniel Alejandro Benavides D. wrote: > > > Hi: > > Thanks for your suggestions. I have tried the > > scripts/win/upgrade.cmd, and It does compile and then > > you can execute do-cm3-std.cmd. > > > > However I noticed the that script exports a m3core pkg > > to the repository with a m3core-d5.5 like suffix. Not > > sure what is this for. > > > > I will test if it can recognize the LONGINT datatype. > > > > Also I have a question about Tony's suggestion. The > > packages m3objfile and m3back are not ncessary on the > > stages you mention for NT386 target? > > >Oh, yes, of course they are. Sorry, I forgot about that for NT386. > > > > > Thanks > > > > --- Tony Hosking escribi?: > > > >> It strikes me that you may need to sequence as > >> follows to avoid > >> running into having a compiler that does not handle > >> LONGINT. > >> > >> Using the "devel_LONGINT_start" tagged versions of > >> m3core and libm3 > >> from CVS, > >> using your original compiler, build and ship in the > >> following order: > >> > >> m3core (devel_LONGINT_start) > >> libm3 (devel_LONGINT_start) > >> m3middle > >> m3linker > >> m3front > >> m3quake > >> cm3 > >> > >> Now you have a new compiler linked against the old > >> m3core. > >> > >> Using the new compiler (in cm3/NT386), and the CVS > >> head versions of > >> m3core and libm3, > >> build and ship in the following order: > >> > >> m3core (CVS head) > >> libm3 (CVS head) > >> m3middle > >> m3linker > >> m3front > >> m3quake > >> cm3 > >> > >> Now you have a new compiler linked against the new > >> m3core. > >> > >> Copy this new compiler to your CM3 installation bin > >> directory. > >> > >> Use this new compiler to rebuild the world. > >> > >> > >> On Sep 18, 2007, at 8:41 PM, Jay wrote: > >> > >>> Daniel, can you try just going back to 5.2.6 and > >> running scripts\win > >>> \update? > >>> You should be able to build the current source the > >> last "official" > >>> Win32 binaries, as long as you build in the > >> correct order and all, > >>> which the update.cmd does. You know, there's a > >> certain mentality > >>> around bootstrapping and keeping the connection > >> back to the > >>> previous version, that I upheld. As long as you > >> are careful, you > >>> can go from old binaries to new binaries, you > >> don't have to get the > >>> new binaries magically somewhere, though you do > >> need the old > >>> binaries magically from somewhere. :) > >>> > >>> Perhaps there's a regression. I can check "later". > >>> > >>> - Jay > >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 > >>> From: dabenavidesd at yahoo.es > >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com > >>> Subject: Re: [M3devel] NT386 with cm3-5.5 > >> bootstrap compiler > >>> > >>> Hi: > >>> > >>> I have compiled with the Jay produced 5.5 > >> bootstrap compiler, and > >>> also with 5.1.3a, > >>> 5.2.6 and get the same error. > >>> > >>> Thanks > >>> > >>>> You need to compile the new m3core with the old > >> compiler so that the > >>>> symbol is available to you when you compile using > >> the new compiler. > >>>> This is a classical bootstrapping problem. > >>> > >>>> On Sep 18, 2007, at 6:30 PM, Daniel Alejandro > >> Benavides D. wrote: > >>> > >>>> Hi: > >>>> Thanks for your answer, I have done that and > >> also I get the same > >>>> runtime error > >>>> in the same source file: > >>>> > >>>> > >>>> C:\cm3-cvs\cm3\m3-libs\m3core>CM3 > >>>> --- building in NT386 --- > >>>> > >>>> ignoring ..\src\m3overrides > >>>> > >>>> new source -> compiling RTHooks.i3 > >>>> new source -> compiling RT0.i3 > >>>> new source -> compiling RuntimeError.i3 > >>>> new source -> compiling Word.i3 > >>>> new source -> compiling RTException.i3 > >>>> new source -> compiling RTHooks.m3 > >>>> new source -> compiling RT0.m3 > >>>> new source -> compiling Compiler.i3 > >>>> new source -> compiling RuntimeError.m3 > >>>> new source -> compiling Compiler.m3 > >>>> new source -> compiling RTAllocator.i3 > >>>> new source -> compiling RTType.i3 > >>>> new source -> compiling Csetjmp.i3 > >>>> new source -> compiling BasicCtypes.i3 > >>>> new source -> compiling Ctypes.i3 > >>>> new source -> compiling RTMachine.i3 > >>>> new source -> compiling RTHeapDep.i3 > >>>> new source -> compiling RTHeapRep.i3 > >>>> new source -> compiling ThreadF.i3 > >>>> new source -> compiling RTOS.i3 > >>>> new source -> compiling RTMisc.i3 > >>>> new source -> compiling RTHeap.i3 > >>>> new source -> compiling Cstdlib.i3 > >>>> new source -> compiling Cstddef.i3 > >>>> new source -> compiling RTAllocCnts.i3 > >>>> new source -> compiling RTAllocator.m3 > >>>> new source -> compiling RTAllocStats.i3 > >>>> new source -> compiling Convert.i3 > >>>> new source -> compiling TextClass.i3 > >>>> new source -> compiling Text.i3 > >>>> new source -> compiling RTProcedureSRC.i3 > >>>> new source -> compiling Fingerprint.i3 > >>>> new source -> compiling RTProcedure.i3 > >>>> new source -> compiling RTStack.i3 > >>>> new source -> compiling RTAllocStats.m3 > >>>> "..\src\runtime\common\RTAllocStats.m3", line > >> 46: undefined runtime > >>>> symbol !! (R > >>>> THooks.AllocateTracedRef) > >>>> > >>>> > >>>> *** > >>>> *** runtime error: > >>>> *** Attempt to reference an illegal memory > >> location. > >>>> *** pc = 0x4c4a0d = StartCall + 0xf in > >> ..\src\values\Procedure.m3 > >>>> *** > >>>> > >>>> Stack trace: > >>>> FP PC Procedure > >>>> --------- --------- > >> ------------------------------- > >>>> 0x12f494 0x60b3ce SystemError + 0x66 in > >> ..\src\runtime\NT386 > >>>> \RTSignal.m3 > >>>> 0x12f4c4 0x4c4a0d StartCall + 0xf in > >> ..\src\values\Procedure.m3 > >>>> 0x12f524 0x51beb8 GenRecord + 0x73 in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f58c 0x51b8a3 GenRef + 0x111 in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f5c8 0x51b70f Gen + 0x12d in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f5e0 0x51b4a3 Prep + 0x15 in > >> ..\src\builtinOps\New.m3 > >>>> 0x12f600 0x550f08 Prep + 0x75 in > >> ..\src\exprs\CallExpr.m3 > >>>> 0x12f61c 0x54312d Prep + 0x54 in > >> ..\src\exprs\Expr.m3 > >>>> 0x12f63c 0x544d7f PrepForEmit + 0x81 in > >> ..\src\stmts\AssignStmt.m3 > >>>> 0x12f66c 0x54453b Compile + 0xd6 in > >> ..\src\stmts\AssignStmt.m3 > >>>> ......... ......... ... more frames ... > >>>> > >>>> C:\cm3-cvs\cm3\m3-libs\m3core> > >>>>> You need to recompile m3core before compiling > >> with the new > >>> compiler. > >>>> > >>>>> On Sep 18, 2007, at 5:29 PM, Daniel Alejandro > >> Benavides D. wrote: > >>>> > >>>>> Hi all: > >>>>> Im getting this runtiem error because the > >> symbol > >>>>> > >>>>> missing version stamps -> compiling > >> RTAllocStats.m3 > >>>>> "..\src\runtime\common\RTAllocStats.m3", line > >> 46: undefined > >>> runtime > >>>>> symbol !! (R > >>>>> THooks.AllocateTracedRef) > >>>>> > >>>>> AllocateTracedRef is not defined in the m3core > >> version > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! . > > Make your little one a shining star! Shine on! > Make your little one a shining star! Shine on! From dabenavidesd at yahoo.es Fri Sep 21 18:18:08 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 21 Sep 2007 18:18:08 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <9CFCC906-27F5-471D-9D12-463BE33E2A28@cs.purdue.edu> Message-ID: <724862.70169.qm@web27112.mail.ukl.yahoo.com> Hi: Oh Im sorry I meant, that the compiler is working Ok with LONGINT, at least because is recognizing that LONGINT is a reserved word. SYSTEM.i3 is just source file of the m2tom3 Modula-2 to Modula-3 compiler; I used as a test for the cm3 compiler, beside it is an example of Modula-2 and Modula-3 using a common type LONGINT. Thanks --- Tony Hosking escribi?: > > On Sep 20, 2007, at 8:50 PM, Jay wrote: > > > As a follow up to confirm, look where I made > changes since > > LONGINT, I believe make-dist in particular I had > to make changes to > > to build the right packages in the right order. > I'll look into > > upgrade/update sometime soon.. > > > > - Jay > > > > From: jay.krell at cornell.edu > > To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; > > > m3devel at elegosoft.com > > Subject: RE: [M3devel] NT386 with cm3-5.5 > bootstrap compiler > > Date: Fri, 21 Sep 2007 00:49:21 +0000 > > > > The "-d5.5" thing is a backup of the package > repository. Indeed I > > find it annoying sometimes, but I mimiced > upgrade.sh and I'd have > > to think it all through again before > deleting/changing how it > > works. I think it makes it easier to back out of a > broken change. > > If you end up with non-working stuff, you copy > pkg-d5.5 back on top > > of pkg. > > > > I really strongly suspect update.cmd works. I > don't remember if it > > upgrades...oh, sorry, wrong script I think. > > make-dist.cmd? How about that one? > > Whichever one creates .tar.bz2 files. That's the > one I meant. Oops, > > sorry sorry sorry. :\ > > > > > > - Jay > > Date: Thu, 20 Sep 2007 22:53:35 +0200 > > From: dabenavidesd at yahoo.es > > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > > Subject: Re: [M3devel] NT386 with cm3-5.5 > bootstrap compiler > > > > Hi: > > > > The script upgrade.cmd produced compiler does > recognize the LONGINT > > as a reserved word. > > > > I can get this error when compiling the m2libs of > m2tom3 compiler: > > > > > > new source -> compiling SYSTEM.i3 > > "..\src\SYSTEM.i3", line 40: Reserved identifier > redefined (LONGINT) > > 1 error encountered > > > > I don't see this file in the distribution. I > suspect it is something > to do with upgrade.cmd. I assume it is defining > LONGINT for > compilers that don't support it, though I fail to > understand why this > would be necessary. > > > > Thanks again > > > > > > > > >On Sep 20, 2007, at 11:15 AM, Daniel Alejandro > Benavides D. wrote: > > > > > Hi: > > > Thanks for your suggestions. I have tried the > > > scripts/win/upgrade.cmd, and It does compile and > then > > > you can execute do-cm3-std.cmd. > > > > > > However I noticed the that script exports a > m3core pkg > > > to the repository with a m3core-d5.5 like > suffix. Not > > > sure what is this for. > > > > > > I will test if it can recognize the LONGINT > datatype. > > > > > > Also I have a question about Tony's suggestion. > The > > > packages m3objfile and m3back are not ncessary > on the > > > stages you mention for NT386 target? > > > > >Oh, yes, of course they are. Sorry, I forgot > about that for NT386. > > > > > > > > Thanks > > > > > > --- Tony Hosking > escribi?: > > > > > >> It strikes me that you may need to sequence as > > >> follows to avoid > > >> running into having a compiler that does not > handle > > >> LONGINT. > > >> > > >> Using the "devel_LONGINT_start" tagged versions > of > > >> m3core and libm3 > > >> from CVS, > > >> using your original compiler, build and ship in > the > > >> following order: > > >> > > >> m3core (devel_LONGINT_start) > > >> libm3 (devel_LONGINT_start) > > >> m3middle > > >> m3linker > > >> m3front > > >> m3quake > > >> cm3 > > >> > > >> Now you have a new compiler linked against the > old > > >> m3core. > > >> > > >> Using the new compiler (in cm3/NT386), and the > CVS > > >> head versions of > > >> m3core and libm3, > > >> build and ship in the following order: > > >> > > >> m3core (CVS head) > > >> libm3 (CVS head) > > >> m3middle > > >> m3linker > > >> m3front > > >> m3quake > > >> cm3 > > >> > > >> Now you have a new compiler linked against the > new > > >> m3core. > > >> > > >> Copy this new compiler to your CM3 installation > bin > > >> directory. > > >> > > >> Use this new compiler to rebuild the world. > > >> > > >> > > >> On Sep 18, 2007, at 8:41 PM, Jay wrote: > > >> > > >>> Daniel, can you try just going back to 5.2.6 > and > > >> running scripts\win > > >>> \update? > > >>> You should be able to build the current source > the > > >> last "official" > > >>> Win32 binaries, as long as you build in the > > >> correct order and all, > > >>> which the update.cmd does. You know, there's a > > >> certain mentality > > >>> around bootstrapping and keeping the > connection > > >> back to the > > >>> previous version, that I upheld. As long as > you > > >> are careful, you > > >>> can go from old binaries to new binaries, you > > >> don't have to get the > > >>> new binaries magically somewhere, though you > do > > >> need the old > > >>> binaries magically from somewhere. :) > > >>> > > >>> Perhaps there's a regression. I can check > "later". > > >>> > > >>> - Jay > > >>> Date: Wed, 19 Sep 2007 00:49:57 +0200 > > >>> From: dabenavidesd at yahoo.es > > >>> To: hosking at cs.purdue.edu; > m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] NT386 with cm3-5.5 > > >> bootstrap compiler > > >>> > > >>> Hi: > > >>> > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From rodney.bates at wichita.edu Fri Sep 21 18:57:59 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 21 Sep 2007 11:57:59 -0500 Subject: [M3devel] A RT failure in ThreadPThread.Alert] Message-ID: <46F3F817.4000909@wichita.edu> I got a runtime failure in ThreadPThread.Alert, on this line: ---------------------------------------------------------------------------------- PROCEDURE Alert (t: T) = BEGIN WITH r = Upthread.mutex_lock(cm) DO <*ASSERT r=0*> END; t.alerted := TRUE; --> WITH r = Upthread.cond_signal(t.waitCond^) DO <*ASSERT r=0*> END; WITH r = Upthread.mutex_unlock(cm) DO <*ASSERT r=0*> END; END Alert; ------------------------------------------------------------------------------------ Here, t.waitCond is NIL and being dereferenced. I tried just making this silently tolerate NIL t.waitCond, and it made the immediate symptom go away, with no other immediately apparent problems. But this seems not very likely to be right. For one thing, there are several other places that assume waitCond is non-NIL. And, a quick reading revealed only one place that creates this object, which always allocates waitCond, no places that change it, and T is opaque and revealed only in this module. How could this happen? Here is a bit of debugger output: The display of t is at the bottom. ------------------------------------------------------------------------------------ *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 304 *** ------------------ EXCEPTION HANDLER STACK --------------------- 0xb5eb71dc TRY-EXCEPT {0xa893a19c} 0xb5eb72bc LOCK mutex = 0xb436e0e4 0xb5eb731c LOCK mutex = 0xb6ebbc44 ---------------------------------------------------------------- [Switching to Thread -1242858592 (LWP 8289)] Breakpoint 2, 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 272 ; PROCEDURE InnerRuntimeFailureDialog ( ) (m3gdb) bt #0 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 #1 0x08126c89 in RuntimeFailureDialog () at AssertDevel.m3:314 #2 0xb72e596f in InvokeExitors () at RTProcess.m3:40 #3 0xb72e59e3 in Crash (msg=NIL) at RTProcess.m3:61 #4 0xb72e3648 in EndError (crash=TRUE) at RTError.m3:115 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 #6 0xb72e3a46 in Crash (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE, rte=16_b73124c0) at RTException.m3:79 #7 0xb72e3770 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:39 #8 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #9 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #10 0xb72e3810 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:47 #11 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #12 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #13 0xb72cb223 in ReportFault (module=16_b731e020, info=9732) at RTHooks.m3:110 #14 0xb72fb697 in _m3_fault (arg=9732) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 #16 0xb7df741d in DisplayDir (v=16_b436e004) at FileBrowserVBT.m3:496 #17 0xb7df4d83 in Refresh (v=16_b436e004) at FileBrowserVBT.m3:210 #18 0xb7df5413 in Watcher (cl=16_b6ebbc9c) at FileBrowserVBT.m3:254 #19 0xb72f76f5 in RunThread (me=16_08e1c518) at ThreadPThread.m3:538 #20 0xb72f7403 in ThreadBase (param=16_08e1c518) at ThreadPThread.m3:519 #21 0xb707c540 in start_thread () from /lib/i686/libpthread.so.0 #22 0xb6fef55e in clone () from /lib/i686/libc.so.6 (m3gdb) frame 5 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 40 RTError.m3: No such file or directory. in RTError.m3 (m3gdb) p msgA $1 = (*16_b7318068*) "" (m3gdb) p msgB $2 = (*16_b73126d4*) "Attempt to reference an illegal memory location." (m3gdb) p msgC $3 = (*16_b7318068*) "" (m3gdb) frame 15 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 304 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) p t $4 = (*16_b3a9bdc8*) OBJECT act = 16_08e94678; closure = NIL; result = NIL; cond = 16_b3a9bdf4; waitingOn = NIL; nextWaiter = NIL; waitCond = NIL; alerted = TRUE; completed = TRUE; joined = FALSE; id = 73; END (m3gdb) -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Fri Sep 21 19:16:11 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Sep 2007 13:16:11 -0400 Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <724862.70169.qm@web27112.mail.ukl.yahoo.com> References: <724862.70169.qm@web27112.mail.ukl.yahoo.com> Message-ID: <0E2AE424-55FE-4CE4-8223-DE9E2C162E74@cs.purdue.edu> Does this mean you no longer have trouble? On Sep 21, 2007, at 12:18 PM, Daniel Alejandro Benavides D. wrote: > Hi: > Oh Im sorry I meant, that the compiler is working Ok > with LONGINT, at least because is recognizing that > LONGINT is a reserved word. > > SYSTEM.i3 is just source file of the m2tom3 Modula-2 > to Modula-3 compiler; I used as a test for the cm3 > compiler, beside it is an example of Modula-2 and > Modula-3 using a common type LONGINT. > > Thanks > > --- Tony Hosking escribi?: > >> >> On Sep 20, 2007, at 8:50 PM, Jay wrote: >> >>> As a follow up to confirm, look where I made >> changes since >>> LONGINT, I believe make-dist in particular I had >> to make changes to >>> to build the right packages in the right order. >> I'll look into >>> upgrade/update sometime soon.. >>> >>> - Jay >>> >>> From: jay.krell at cornell.edu >>> To: dabenavidesd at yahoo.es; hosking at cs.purdue.edu; >> >>> m3devel at elegosoft.com >>> Subject: RE: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> Date: Fri, 21 Sep 2007 00:49:21 +0000 >>> >>> The "-d5.5" thing is a backup of the package >> repository. Indeed I >>> find it annoying sometimes, but I mimiced >> upgrade.sh and I'd have >>> to think it all through again before >> deleting/changing how it >>> works. I think it makes it easier to back out of a >> broken change. >>> If you end up with non-working stuff, you copy >> pkg-d5.5 back on top >>> of pkg. >>> >>> I really strongly suspect update.cmd works. I >> don't remember if it >>> upgrades...oh, sorry, wrong script I think. >>> make-dist.cmd? How about that one? >>> Whichever one creates .tar.bz2 files. That's the >> one I meant. Oops, >>> sorry sorry sorry. :\ >>> >>> >>> - Jay >>> Date: Thu, 20 Sep 2007 22:53:35 +0200 >>> From: dabenavidesd at yahoo.es >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] NT386 with cm3-5.5 >> bootstrap compiler >>> >>> Hi: >>> >>> The script upgrade.cmd produced compiler does >> recognize the LONGINT >>> as a reserved word. >>> >>> I can get this error when compiling the m2libs of >> m2tom3 compiler: >>> >>> >>> new source -> compiling SYSTEM.i3 >>> "..\src\SYSTEM.i3", line 40: Reserved identifier >> redefined (LONGINT) >>> 1 error encountered >>> >> >> I don't see this file in the distribution. I >> suspect it is something >> to do with upgrade.cmd. I assume it is defining >> LONGINT for >> compilers that don't support it, though I fail to >> understand why this >> would be necessary. >> >> >>> Thanks again >>> >>> >>> >>>> On Sep 20, 2007, at 11:15 AM, Daniel Alejandro >> Benavides D. wrote: >>> >>>> Hi: >>>> Thanks for your suggestions. I have tried the >>>> scripts/win/upgrade.cmd, and It does compile and >> then >>>> you can execute do-cm3-std.cmd. >>>> >>>> However I noticed the that script exports a >> m3core pkg >>>> to the repository with a m3core-d5.5 like >> suffix. Not >>>> sure what is this for. >>>> >>>> I will test if it can recognize the LONGINT >> datatype. >>>> >>>> Also I have a question about Tony's suggestion. >> The >>>> packages m3objfile and m3back are not ncessary >> on the >>>> stages you mention for NT386 target? >>> >>>> Oh, yes, of course they are. Sorry, I forgot >> about that for NT386. >>> >>>> >>>> Thanks >>>> >>>> --- Tony Hosking >> escribi?: >>>> >>>>> It strikes me that you may need to sequence as >>>>> follows to avoid >>>>> running into having a compiler that does not >> handle >>>>> LONGINT. >>>>> >>>>> Using the "devel_LONGINT_start" tagged versions >> of >>>>> m3core and libm3 >>>>> from CVS, >>>>> using your original compiler, build and ship in >> the >>>>> following order: >>>>> >>>>> m3core (devel_LONGINT_start) >>>>> libm3 (devel_LONGINT_start) >>>>> m3middle >>>>> m3linker >>>>> m3front >>>>> m3quake >>>>> cm3 >>>>> >>>>> Now you have a new compiler linked against the >> old >>>>> m3core. >>>>> >>>>> Using the new compiler (in cm3/NT386), and the >> CVS >>>>> head versions of >>>>> m3core and libm3, >>>>> build and ship in the following order: >>>>> >>>>> m3core (CVS head) >>>>> libm3 (CVS head) >>>>> m3middle >>>>> m3linker >>>>> m3front >>>>> m3quake >>>>> cm3 >>>>> >>>>> Now you have a new compiler linked against the >> new >>>>> m3core. >>>>> >>>>> Copy this new compiler to your CM3 installation >> bin >>>>> directory. >>>>> >>>>> Use this new compiler to rebuild the world. >>>>> >>>>> >>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote: >>>>> >>>>>> Daniel, can you try just going back to 5.2.6 >> and >>>>> running scripts\win >>>>>> \update? >>>>>> You should be able to build the current source >> the >>>>> last "official" >>>>>> Win32 binaries, as long as you build in the >>>>> correct order and all, >>>>>> which the update.cmd does. You know, there's a >>>>> certain mentality >>>>>> around bootstrapping and keeping the >> connection >>>>> back to the >>>>>> previous version, that I upheld. As long as >> you >>>>> are careful, you >>>>>> can go from old binaries to new binaries, you >>>>> don't have to get the >>>>>> new binaries magically somewhere, though you >> do >>>>> need the old >>>>>> binaries magically from somewhere. :) >>>>>> >>>>>> Perhaps there's a regression. I can check >> "later". >>>>>> >>>>>> - Jay >>>>>> Date: Wed, 19 Sep 2007 00:49:57 +0200 >>>>>> From: dabenavidesd at yahoo.es >>>>>> To: hosking at cs.purdue.edu; >> m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] NT386 with cm3-5.5 >>>>> bootstrap compiler >>>>>> >>>>>> Hi: >>>>>> >> > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Fri Sep 21 19:27:10 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 21 Sep 2007 19:27:10 +0200 (CEST) Subject: [M3devel] NT386 with cm3-5.5 bootstrap compiler In-Reply-To: <0E2AE424-55FE-4CE4-8223-DE9E2C162E74@cs.purdue.edu> Message-ID: <413596.25532.qm@web27105.mail.ukl.yahoo.com> Hi: Yes, exactly :) Thanks --- Tony Hosking escribi?: > Does this mean you no longer have trouble? > > On Sep 21, 2007, at 12:18 PM, Daniel Alejandro > Benavides D. wrote: > > > Hi: > > Oh Im sorry I meant, that the compiler is working > Ok > > with LONGINT, at least because is recognizing that > > LONGINT is a reserved word. > > > > SYSTEM.i3 is just source file of the m2tom3 > Modula-2 > > to Modula-3 compiler; I used as a test for the cm3 > > compiler, beside it is an example of Modula-2 and > > Modula-3 using a common type LONGINT. > > > > Thanks > > > > --- Tony Hosking > escribi?: > > > >> > >> On Sep 20, 2007, at 8:50 PM, Jay wrote: > >> > >>> As a follow up to confirm, look where I made > >> changes since > >>> LONGINT, I believe make-dist in particular I had > >> to make changes to > >>> to build the right packages in the right order. > >> I'll look into > >>> upgrade/update sometime soon.. > >>> > >>> - Jay > >>> > >>> From: jay.krell at cornell.edu > >>> To: dabenavidesd at yahoo.es; > hosking at cs.purdue.edu; > >> > >>> m3devel at elegosoft.com > >>> Subject: RE: [M3devel] NT386 with cm3-5.5 > >> bootstrap compiler > >>> Date: Fri, 21 Sep 2007 00:49:21 +0000 > >>> > >>> The "-d5.5" thing is a backup of the package > >> repository. Indeed I > >>> find it annoying sometimes, but I mimiced > >> upgrade.sh and I'd have > >>> to think it all through again before > >> deleting/changing how it > >>> works. I think it makes it easier to back out of > a > >> broken change. > >>> If you end up with non-working stuff, you copy > >> pkg-d5.5 back on top > >>> of pkg. > >>> > >>> I really strongly suspect update.cmd works. I > >> don't remember if it > >>> upgrades...oh, sorry, wrong script I think. > >>> make-dist.cmd? How about that one? > >>> Whichever one creates .tar.bz2 files. That's the > >> one I meant. Oops, > >>> sorry sorry sorry. :\ > >>> > >>> > >>> - Jay > >>> Date: Thu, 20 Sep 2007 22:53:35 +0200 > >>> From: dabenavidesd at yahoo.es > >>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com > >>> Subject: Re: [M3devel] NT386 with cm3-5.5 > >> bootstrap compiler > >>> > >>> Hi: > >>> > >>> The script upgrade.cmd produced compiler does > >> recognize the LONGINT > >>> as a reserved word. > >>> > >>> I can get this error when compiling the m2libs > of > >> m2tom3 compiler: > >>> > >>> > >>> new source -> compiling SYSTEM.i3 > >>> "..\src\SYSTEM.i3", line 40: Reserved identifier > >> redefined (LONGINT) > >>> 1 error encountered > >>> > >> > >> I don't see this file in the distribution. I > >> suspect it is something > >> to do with upgrade.cmd. I assume it is defining > >> LONGINT for > >> compilers that don't support it, though I fail to > >> understand why this > >> would be necessary. > >> > >> > >>> Thanks again > >>> > >>> > >>> > >>>> On Sep 20, 2007, at 11:15 AM, Daniel Alejandro > >> Benavides D. wrote: > >>> > >>>> Hi: > >>>> Thanks for your suggestions. I have tried the > >>>> scripts/win/upgrade.cmd, and It does compile > and > >> then > >>>> you can execute do-cm3-std.cmd. > >>>> > >>>> However I noticed the that script exports a > >> m3core pkg > >>>> to the repository with a m3core-d5.5 like > >> suffix. Not > >>>> sure what is this for. > >>>> > >>>> I will test if it can recognize the LONGINT > >> datatype. > >>>> > >>>> Also I have a question about Tony's > suggestion. > >> The > >>>> packages m3objfile and m3back are not ncessary > >> on the > >>>> stages you mention for NT386 target? > >>> > >>>> Oh, yes, of course they are. Sorry, I forgot > >> about that for NT386. > >>> > >>>> > >>>> Thanks > >>>> > >>>> --- Tony Hosking > >> escribi?: > >>>> > >>>>> It strikes me that you may need to sequence as > >>>>> follows to avoid > >>>>> running into having a compiler that does not > >> handle > >>>>> LONGINT. > >>>>> > >>>>> Using the "devel_LONGINT_start" tagged > versions > >> of > >>>>> m3core and libm3 > >>>>> from CVS, > >>>>> using your original compiler, build and ship > in > >> the > >>>>> following order: > >>>>> > >>>>> m3core (devel_LONGINT_start) > >>>>> libm3 (devel_LONGINT_start) > >>>>> m3middle > >>>>> m3linker > >>>>> m3front > >>>>> m3quake > >>>>> cm3 > >>>>> > >>>>> Now you have a new compiler linked against > the > >> old > >>>>> m3core. > >>>>> > >>>>> Using the new compiler (in cm3/NT386), and the > >> CVS > >>>>> head versions of > >>>>> m3core and libm3, > >>>>> build and ship in the following order: > >>>>> > >>>>> m3core (CVS head) > >>>>> libm3 (CVS head) > >>>>> m3middle > >>>>> m3linker > >>>>> m3front > >>>>> m3quake > >>>>> cm3 > >>>>> > >>>>> Now you have a new compiler linked against the > >> new > >>>>> m3core. > >>>>> > >>>>> Copy this new compiler to your CM3 > installation > >> bin > >>>>> directory. > >>>>> > >>>>> Use this new compiler to rebuild the world. > >>>>> > >>>>> > >>>>> On Sep 18, 2007, at 8:41 PM, Jay wrote: > >>>>> > >>>>>> Daniel, can you try just going back to 5.2.6 > >> and > >>>>> running scripts\win > >>>>>> \update? > >>>>>> You should be able to build the current > source > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 21 19:30:11 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Sep 2007 13:30:11 -0400 Subject: [M3devel] A RT failure in ThreadPThread.Alert] In-Reply-To: <46F3F817.4000909@wichita.edu> References: <46F3F817.4000909@wichita.edu> Message-ID: waitCond should be valid for all live threads. I'm assuming you are invoking Thread.Alert on a thread that is no longer alive. Indeed, you can see from the debug output that the thread has completed. I suppose we could silently ignore the alert for a completed thread, but I suspect this reveals some deeper problem with your code -- should you really issue an alert to a thread that is incapable of receiving it. I wonder if the alert flag is already set for that thread. In any case I suppose we can simply check for NIL in Alert. I've checked in code to do this. On Sep 21, 2007, at 12:57 PM, Rodney M. Bates wrote: > > > > I got a runtime failure in ThreadPThread.Alert, on this line: > > ---------------------------------------------------------------------- > ------------ > PROCEDURE Alert (t: T) = > BEGIN > WITH r = Upthread.mutex_lock(cm) DO <*ASSERT r=0*> END; > t.alerted := TRUE; > --> WITH r = Upthread.cond_signal(t.waitCond^) DO <*ASSERT r=0*> END; > WITH r = Upthread.mutex_unlock(cm) DO <*ASSERT r=0*> END; > END Alert; > ---------------------------------------------------------------------- > -------------- > Here, t.waitCond is NIL and being dereferenced. I tried just > making this > silently tolerate NIL t.waitCond, and it made the immediate symptom > go away, > with no other immediately apparent problems. But this seems not > very likely > to be right. For one thing, there are several other places that > assume > waitCond is non-NIL. And, a quick reading revealed only one place > that creates > this object, which always allocates waitCond, no places that change > it, and > T is opaque and revealed only in this module. How could this happen? > > > Here is a bit of debugger output: The display of t is at the bottom. > ---------------------------------------------------------------------- > -------------- > > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 304 > *** > > ------------------ EXCEPTION HANDLER STACK --------------------- > 0xb5eb71dc TRY-EXCEPT {0xa893a19c} > 0xb5eb72bc LOCK mutex = 0xb436e0e4 > 0xb5eb731c LOCK mutex = 0xb6ebbc44 > ---------------------------------------------------------------- > [Switching to Thread -1242858592 (LWP 8289)] > > Breakpoint 2, 0x08126a38 in InnerRuntimeFailureDialog () at > AssertDevel.m3:272 > 272 ; PROCEDURE InnerRuntimeFailureDialog ( ) > (m3gdb) bt > #0 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 > #1 0x08126c89 in RuntimeFailureDialog () at AssertDevel.m3:314 > #2 0xb72e596f in InvokeExitors () at RTProcess.m3:40 > #3 0xb72e59e3 in Crash (msg=NIL) at RTProcess.m3:61 > #4 0xb72e3648 in EndError (crash=TRUE) at RTError.m3:115 > #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, > msgA=16_b7318068, msgB=16_b73126d4, > msgC=16_b7318068) at RTError.m3:40 > #6 0xb72e3a46 in Crash (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE, > rte=16_b73124c0) at RTException.m3:79 > #7 0xb72e3770 in DefaultBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:39 > #8 0xb72e36d4 in InvokeBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:25 > #9 0xb72f3397 in Raise (act= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END) at RTExFrame.m3:29 > #10 0xb72e3810 in DefaultBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:47 > #11 0xb72e36d4 in InvokeBackstop (a= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END, raises=FALSE) > at RTException.m3:25 > #12 0xb72f3397 in Raise (act= > RECORD exception = 16_b73124c0; arg = 16_0000000c; module = > 16_b731e020; line = 304; pc = NIL; > info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = > 16_00000004; END) at RTExFrame.m3:29 > #13 0xb72cb223 in ReportFault (module=16_b731e020, info=9732) at > RTHooks.m3:110 > #14 0xb72fb697 in _m3_fault (arg=9732) from /usr/local/cm3/pkg/ > m3core/LINUXLIBC6/libm3core.so.5 > #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 > #16 0xb7df741d in DisplayDir (v=16_b436e004) at FileBrowserVBT.m3:496 > #17 0xb7df4d83 in Refresh (v=16_b436e004) at FileBrowserVBT.m3:210 > #18 0xb7df5413 in Watcher (cl=16_b6ebbc9c) at FileBrowserVBT.m3:254 > #19 0xb72f76f5 in RunThread (me=16_08e1c518) at ThreadPThread.m3:538 > #20 0xb72f7403 in ThreadBase (param=16_08e1c518) at > ThreadPThread.m3:519 > #21 0xb707c540 in start_thread () from /lib/i686/libpthread.so.0 > #22 0xb6fef55e in clone () from /lib/i686/libc.so.6 > (m3gdb) frame 5 > #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, > msgA=16_b7318068, msgB=16_b73126d4, > msgC=16_b7318068) at RTError.m3:40 > 40 RTError.m3: No such file or directory. > in RTError.m3 > (m3gdb) p msgA > $1 = (*16_b7318068*) "" > (m3gdb) p msgB > $2 = (*16_b73126d4*) "Attempt to reference an illegal memory > location." > (m3gdb) p msgC > $3 = (*16_b7318068*) "" > (m3gdb) frame 15 > #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 > 304 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) p t > $4 = (*16_b3a9bdc8*) OBJECT act = 16_08e94678; closure = NIL; > result = NIL; cond = 16_b3a9bdf4; > waitingOn = NIL; nextWaiter = NIL; waitCond = NIL; alerted = > TRUE; completed = TRUE; > joined = FALSE; id = 73; END > (m3gdb) > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu > From rodney.bates at wichita.edu Sat Sep 22 04:51:36 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 21 Sep 2007 21:51:36 -0500 Subject: [M3devel] A RT failure in ThreadPThread.Alert] In-Reply-To: <7AE14F7D-216C-40B8-996E-0BC97875D4D9@cs.purdue.edu> References: <46F3F817.4000909@wichita.edu> <46F41CE8.9060804@wichita.edu> <7AE14F7D-216C-40B8-996E-0BC97875D4D9@cs.purdue.edu> Message-ID: <46F48338.8040304@wichita.edu> From a bit of code reading, it looks like: 1) FileBrowserVBT.m3 has been routinely doing this for a long time (Alerting a thread that has most likely already terminated), and 2) ThreadPosix tolerates this harmlessly. So, making ThreadPThread also tolerate it is probably the right fix. Tony Hosking wrote: > Hmmm. Perhaps there is a deeper problem. > > On Sep 21, 2007, at 3:35 PM, Rodney M. Bates wrote: > >> The Alert is coming from somewhere inside Trestle. I guess I need to >> look into that. >> >> Tony Hosking wrote: >> >>> waitCond should be valid for all live threads. I'm assuming you >>> are invoking Thread.Alert on a thread that is no longer alive. >>> Indeed, you can see from the debug output that the thread has >>> completed. I suppose we could silently ignore the alert for a >>> completed thread, but I suspect this reveals some deeper problem >>> with your code -- should you really issue an alert to a thread that >>> is incapable of receiving it. I wonder if the alert flag is >>> already set for that thread. In any case I suppose we can simply >>> check for NIL in Alert. I've checked in code to do this. >> >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Sat Sep 22 06:10:10 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 22 Sep 2007 00:10:10 -0400 Subject: [M3devel] A RT failure in ThreadPThread.Alert] In-Reply-To: <46F48338.8040304@wichita.edu> References: <46F3F817.4000909@wichita.edu> <46F41CE8.9060804@wichita.edu> <7AE14F7D-216C-40B8-996E-0BC97875D4D9@cs.purdue.edu> <46F48338.8040304@wichita.edu> Message-ID: <730D7378-3B00-4DB8-9DA5-75C55FCB74E0@cs.purdue.edu> The update I checked in earlier today does the trick. On Sep 21, 2007, at 10:51 PM, Rodney M. Bates wrote: > From a bit of code reading, it looks like: > > 1) FileBrowserVBT.m3 has been routinely doing this for a long time > (Alerting a thread that has most likely already terminated), and > > 2) ThreadPosix tolerates this harmlessly. > > So, making ThreadPThread also tolerate it is probably the right fix. > > Tony Hosking wrote: >> Hmmm. Perhaps there is a deeper problem. >> On Sep 21, 2007, at 3:35 PM, Rodney M. Bates wrote: >>> The Alert is coming from somewhere inside Trestle. I guess I >>> need to >>> look into that. >>> >>> Tony Hosking wrote: >>> >>>> waitCond should be valid for all live threads. I'm assuming >>>> you are invoking Thread.Alert on a thread that is no longer >>>> alive. Indeed, you can see from the debug output that the >>>> thread has completed. I suppose we could silently ignore the >>>> alert for a completed thread, but I suspect this reveals some >>>> deeper problem with your code -- should you really issue an >>>> alert to a thread that is incapable of receiving it. I wonder >>>> if the alert flag is already set for that thread. In any case >>>> I suppose we can simply check for NIL in Alert. I've checked >>>> in code to do this. >>> >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From dabenavidesd at yahoo.es Thu Sep 27 08:32:37 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 27 Sep 2007 08:32:37 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 Message-ID: <266390.74360.qm@web27112.mail.ukl.yahoo.com> Hi: I am testing some examples of Chapter 16 of Laszlo book, but the text shows me that now the NThreads example where 10 threads are being showing the IDs (1, 2, ... ,10). This is tested on ubuntu Dapper OS, which still allows the use of user space threads implementation. Attached are some animated gif files that show in (sorry have no web page available) LINUXLIBC6.gif exmaple execution of Systems level threads LINUXLIBC62.gif example execution of User space threads LINUXLIBC62a.gif example execution of User space threads after it ends Why the different versions of thread implementation are different, in terms of what showthread shows that all the threads are "locking" (9 almost all time) and 2 (the first and third form left to right) are "alive" in the Pthread case, and why in the user space threads case they are "alive" green color almost always if they are not running. The worst thing is the behaviour of the appication is very rare, It should be running until a key (enter) is pressed down; It just runs some seconds in pthread case. Besides why some many objects are shown in shownew with the user space threaded program. The linking information of ldd output is below. LINUXLIBC6 is current cvs compiled example LINUXLIBC&2 compiled with user spce threads. on LINUXLIBC6 with user space threads, June 9th the date It was compiled. danielb at danielb-desktop:~/code/m3/parallel$ ldd LINUXLIBC62/NThreads linux-gate.so.1 => (0xffffe000) libm3local.so.5 => /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 (0xb7faf000) libm3.so.5 => /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 (0xb7e90000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 (0xb760f000) libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb75d1000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb74a2000) /lib/ld-linux.so.2 (0xb7fbd000) on LINUXLIBC6 with system threads: danielb at danielb-desktop:~/code/m3/parallel$ ldd LINUXLIBC6/NThreads linux-gate.so.1 => (0xffffe000) libm3local.so.5 => /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 (0xb7f51000) libm3.so.5 => /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 (0xb7e1e000) libm3core.so.5 => /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 (0xb7592000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7544000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7415000) /lib/ld-linux.so.2 (0xb7f5f000) the source code is this MODULE NThreads EXPORTS Main; (*22.02.95. LB*) (* Program starts "N" threads which output their ID and terminate if a key is pressed (on some systems you have to press the return key). *) IMPORT Thread, SIO; FROM Scheduler IMPORT Yield; CONST N = 10; TYPE Threads = [1..N]; Closure = Thread.Closure OBJECT id: Threads; (*identifies thread*) OVERRIDES apply:= PrintId; END; (*Closure*) PROCEDURE PrintId(cl: Closure): REFANY = BEGIN REPEAT SIO.PutInt(cl.id); IF cl.id = LAST(Threads) THEN SIO.Nl() END; Yield(); (*yields to other threads*) UNTIL SIO.Available(); RETURN NIL; (*return value not used*) END PrintId; PROCEDURE Fork() = BEGIN FOR i:= FIRST(Threads) TO LAST(Threads) - 1 DO EVAL Thread.Fork(NEW(Closure, id:= i)) (*N-1 threads are generated*) END; EVAL PrintId(NEW(Closure, id:= LAST(Threads))); (*N-th thread = main*) END Fork; BEGIN Fork(); (*start all threads*) END NThreads. Thanks ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html -------------- next part -------------- A non-text attachment was scrubbed... Name: LINUXLIBC6.gif Type: image/gif Size: 169516 bytes Desc: 1808490959-LINUXLIBC6.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LINUXLIBC62.gif Type: image/gif Size: 170325 bytes Desc: 2366884796-LINUXLIBC62.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LINUXLIBC62a.gif Type: image/gif Size: 246626 bytes Desc: 225660904-LINUXLIBC62a.gif URL: From hosking at cs.purdue.edu Thu Sep 27 15:38:37 2007 From: hosking at cs.purdue.edu (Antony Hosking) Date: Thu, 27 Sep 2007 09:38:37 -0400 Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <266390.74360.qm@web27112.mail.ukl.yahoo.com> References: <266390.74360.qm@web27112.mail.ukl.yahoo.com> Message-ID: <35BC64D8-6381-43CC-B52A-666F7C2757BC@cs.purdue.edu> In the pthread implementation scheduling is performed by the OS so there is no way to say that any particular thread is *alive*, just that it is eligible to run should the scheduler choose to run it (indeed on an SMP more than one thread can run at a time). The user- thread implementation has its own scheduler, so it knows precisely which thread is running at any point in time. Are you saying there is a bug in the current pthread implementation? If so, then I'd like a more precise characterization that I can pursue and fix. On Sep 27, 2007, at 2:32 AM, Daniel Alejandro Benavides D. wrote: > Hi: > I am testing some examples of Chapter 16 of Laszlo > book, but the text shows me that now the NThreads > example where 10 threads are being showing the IDs (1, > 2, ... ,10). > This is tested on ubuntu Dapper OS, which still allows > the use of user space threads implementation. > Attached are some animated gif files that show in > (sorry have no web page available) > LINUXLIBC6.gif exmaple execution of Systems level > threads > LINUXLIBC62.gif example execution of User space > threads > LINUXLIBC62a.gif example execution of User space > threads after it ends > > Why the different versions of thread implementation > are different, in terms of what showthread shows that > all the threads are "locking" (9 almost all time) and > 2 (the first and third form left to right) are "alive" > in the Pthread case, and why in the user space threads > case they are "alive" green color almost always if > they are not running. > The worst thing is the behaviour of the appication is > very rare, It should be running until a key (enter) is > pressed down; It just runs some seconds in pthread > case. > > Besides why some many objects are shown in shownew > with the user space threaded program. > > The linking information of ldd output is below. > LINUXLIBC6 is current cvs compiled example > LINUXLIBC&2 compiled with user spce threads. > > on LINUXLIBC6 with user space threads, June 9th the > date It was compiled. > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > LINUXLIBC62/NThreads > linux-gate.so.1 => (0xffffe000) > libm3local.so.5 => > /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 > (0xb7faf000) > libm3.so.5 => > /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 > (0xb7e90000) > libm3core.so.5 => > /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > (0xb760f000) > libm3gcdefs.so.5 => > /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > (0xb75d1000) > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > (0xb74a2000) > /lib/ld-linux.so.2 (0xb7fbd000) > > > on LINUXLIBC6 with system threads: > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > LINUXLIBC6/NThreads > linux-gate.so.1 => (0xffffe000) > libm3local.so.5 => > /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 > (0xb7f51000) > libm3.so.5 => > /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 > (0xb7e1e000) > libm3core.so.5 => > /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 > (0xb7592000) > libpthread.so.0 => > /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > (0xb7544000) > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > (0xb7415000) > /lib/ld-linux.so.2 (0xb7f5f000) > > > the source code is this > > MODULE NThreads EXPORTS Main; > (*22.02.95. LB*) > (* Program starts "N" threads which output their ID > and terminate > if a key is pressed (on some systems you have to > press the return > key). > *) > > IMPORT Thread, SIO; > FROM Scheduler IMPORT Yield; > > CONST > N = 10; > TYPE > Threads = [1..N]; > Closure = Thread.Closure OBJECT > id: Threads; > (*identifies thread*) > OVERRIDES > apply:= PrintId; > END; (*Closure*) > > PROCEDURE PrintId(cl: Closure): REFANY = > BEGIN > REPEAT > SIO.PutInt(cl.id); > IF cl.id = LAST(Threads) THEN SIO.Nl() END; > Yield(); > (*yields to other threads*) > UNTIL SIO.Available(); > RETURN NIL; > (*return value not used*) > END PrintId; > > PROCEDURE Fork() = > BEGIN > FOR i:= FIRST(Threads) TO LAST(Threads) - 1 DO > EVAL Thread.Fork(NEW(Closure, id:= i)) > (*N-1 threads are generated*) > END; > EVAL PrintId(NEW(Closure, id:= LAST(Threads))); > (*N-th thread = main*) > END Fork; > > BEGIN > Fork(); > (*start all threads*) > END NThreads. > > > Thanks > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html > > > Antony Hosking | Associate Professor Dept of Computer Sciences | Office: (765) 494-6001 Purdue University | Mobile: (765) 427-5484 250 N. University Street | hosking at cs.purdue.edu West Lafayette, IN 47907-2066 | http://www.cs.purdue.edu/~hosking _--_|\ / \ \_.--._/ ) v / From dabenavidesd at yahoo.es Fri Sep 28 15:08:35 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 28 Sep 2007 15:08:35 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <35BC64D8-6381-43CC-B52A-666F7C2757BC@cs.purdue.edu> Message-ID: <757512.73957.qm@web27111.mail.ukl.yahoo.com> Hi: With @M3noincremental just runs for while 1 2 3 1 2 3 10 5 4 and in this state its like a freezed program, it does not respond to the keyboard input. With @M3nogenerational or @M3nogc runs just fine. What could be the problem? What else could be useful to do? Thanks --- Antony Hosking wrote: > In the pthread implementation scheduling is > performed by the OS so > there is no way to say that any particular thread is > *alive*, just > that it is eligible to run should the scheduler > choose to run it > (indeed on an SMP more than one thread can run at a > time). The user- > thread implementation has its own scheduler, so it > knows precisely > which thread is running at any point in time. > > Are you saying there is a bug in the current pthread > implementation? > If so, then I'd like a more precise characterization > that I can > pursue and fix. > > On Sep 27, 2007, at 2:32 AM, Daniel Alejandro > Benavides D. wrote: > > > Hi: > > I am testing some examples of Chapter 16 of Laszlo > > book, but the text shows me that now the NThreads > > example where 10 threads are being showing the IDs > (1, > > 2, ... ,10). > > This is tested on ubuntu Dapper OS, which still > allows > > the use of user space threads implementation. > > Attached are some animated gif files that show in > > (sorry have no web page available) > > LINUXLIBC6.gif exmaple execution of Systems level > > threads > > LINUXLIBC62.gif example execution of User space > > threads > > LINUXLIBC62a.gif example execution of User space > > threads after it ends > > > > Why the different versions of thread > implementation > > are different, in terms of what showthread shows > that > > all the threads are "locking" (9 almost all time) > and > > 2 (the first and third form left to right) are > "alive" > > in the Pthread case, and why in the user space > threads > > case they are "alive" green color almost always if > > they are not running. > > The worst thing is the behaviour of the appication > is > > very rare, It should be running until a key > (enter) is > > pressed down; It just runs some seconds in pthread > > case. > > > > Besides why some many objects are shown in shownew > > with the user space threaded program. > > > > The linking information of ldd output is below. > > LINUXLIBC6 is current cvs compiled example > > LINUXLIBC&2 compiled with user spce threads. > > > > on LINUXLIBC6 with user space threads, June 9th > the > > date It was compiled. > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > LINUXLIBC62/NThreads > > linux-gate.so.1 => (0xffffe000) > > libm3local.so.5 => > > > /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > (0xb7faf000) > > libm3.so.5 => > > /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 > > (0xb7e90000) > > libm3core.so.5 => > > > /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > (0xb760f000) > > libm3gcdefs.so.5 => > > /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) > > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > > (0xb75d1000) > > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > > (0xb74a2000) > > /lib/ld-linux.so.2 (0xb7fbd000) > > > > > > on LINUXLIBC6 with system threads: > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > LINUXLIBC6/NThreads > > linux-gate.so.1 => (0xffffe000) > > libm3local.so.5 => > > > /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > (0xb7f51000) > > libm3.so.5 => > > > /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 > > (0xb7e1e000) > > libm3core.so.5 => > > > /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > (0xb7592000) > > libpthread.so.0 => > > /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) > > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 > > (0xb7544000) > > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 > > (0xb7415000) > > /lib/ld-linux.so.2 (0xb7f5f000) > > > > > > the source code is this > > > > MODULE NThreads EXPORTS Main; > > (*22.02.95. LB*) > > (* Program starts "N" threads which output their > ID > > and terminate > > if a key is pressed (on some systems you have > to > > press the return > > key). > > *) > > > > IMPORT Thread, SIO; > > FROM Scheduler IMPORT Yield; > > > > CONST > > N = 10; > > TYPE > > Threads = [1..N]; > > Closure = Thread.Closure OBJECT > > id: Threads; > > (*identifies thread*) > > OVERRIDES > > apply:= PrintId; > > END; (*Closure*) > > > > PROCEDURE PrintId(cl: Closure): REFANY = > > BEGIN > > REPEAT > > SIO.PutInt(cl.id); > > IF cl.id = LAST(Threads) THEN SIO.Nl() END; > > Yield(); > > (*yields to other threads*) > > UNTIL SIO.Available(); > > RETURN NIL; > > (*return value not used*) > > END PrintId; > > > > PROCEDURE Fork() = > > BEGIN > > FOR i:= FIRST(Threads) TO LAST(Threads) - 1 DO > > EVAL Thread.Fork(NEW(Closure, id:= i)) > > (*N-1 threads are generated*) > > END; > > EVAL PrintId(NEW(Closure, id:= > LAST(Threads))); > > (*N-th thread = main*) > > END Fork; > > > > BEGIN > > Fork(); > > (*start all threads*) > > END NThreads. > > > > > > Thanks > > > > > > > > > ______________________________________________________________________ > > > ______________ > > S? un Mejor Amante del Cine > > ?Quieres saber c?mo? ?Deja que otras personas te > ayuden! > > > http://advision.webevents.yahoo.com/reto/entretenimiento.html > > > > > > > > Antony Hosking | Associate Professor > Dept of Computer Sciences | Office: (765) > 494-6001 > Purdue University | Mobile: (765) > 427-5484 > 250 N. University Street | > hosking at cs.purdue.edu > West Lafayette, IN 47907-2066 | > http://www.cs.purdue.edu/~hosking > _--_|\ > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Fri Sep 28 16:30:30 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 28 Sep 2007 16:30:30 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <757512.73957.qm@web27111.mail.ukl.yahoo.com> Message-ID: <860980.52128.qm@web27109.mail.ukl.yahoo.com> Hi: I debugged for a while the program with handle all nostop handle EXC_SOFTWARE stop handle EXC_BREAKPOINT stop getting this: Breakpoint 4, SignalHandler (sig=64, sip=16_b640ff9c, uap=16_b641001c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1254036560 (LWP 8072)] Breakpoint 3, SignalHandler (sig=64, sip=16_b540df8c, uap=16_b540e00c) at ThreadPThread.m3:1184 1184 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1237251152 (LWP 8067)] Breakpoint 3, SignalHandler (sig=64, sip=16_b640ff9c, uap=16_b641001c) at ThreadPThread.m3:1184 1184 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b640ff9c, uap=16_b641001c) at ThreadPThread.m3:1184 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb7505b8c in sched_yield () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7625fce in Yield () at ThreadPThread.m3:712 #5 0x0804b844 in PrintId (cl=16_b741b0a0) at NThreads.m3:25 #6 0xb7624b21 in RunThread (me=16_08054560) at ThreadPThread.m3:540 #7 0xb76247e6 in ThreadBase (param=16_08054560) at ThreadPThread.m3:521 #8 0xb75ad341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #9 0xb751f4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** [Switching to Thread -1228858448 (LWP 8066)] Breakpoint 4, SignalHandler (sig=64, sip=16_b6c10f9c, uap=16_b6c1101c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step Breakpoint 3, SignalHandler (sig=64, sip=16_b6c10f9c, uap=16_b6c1101c) at ThreadPThread.m3:1184 1184 in ThreadPThread.m3 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Program received signal SIG64, Real-time event 64. [Switching to Thread -1220465744 (LWP 8065)] Breakpoint 4, SignalHandler (sig=64, sip=16_b7411f9c, uap=16_b741201c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step 4 4 Program received signal SIGABRT, Aborted. 4Couldn't get registers: No such process. (m3gdb) ----------------------------------------------------- And then without modifying the signal set: (m3gdb) break NThreads.m3:10 Breakpoint 1 at 0x804b934: file NThreads.m3, line 10. (m3gdb) break ThreadPThread.m3:1180 No source file named ThreadPThread.m3. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 2 (ThreadPThread.m3:1180) pending. (m3gdb) run Starting program: /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads [Thread debugging using libthread_db enabled] [New Thread -1220532544 (LWP 8125)] Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, line 1180. Pending breakpoint "ThreadPThread.m3:1180" resolved [Switching to Thread -1220532544 (LWP 8125)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7010) at NThreads.m3:14 warning: Source file is more recent than executable. 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1220805712 (LWP 8131)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7058) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1229198416 (LWP 8132)] 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c70a0) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 1[New Thread -1237591120 (LWP 8133)] 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c70e8) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 2 1[New Thread -1245983824 (LWP 8134)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7130) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 3 2 1[New Thread -1254376528 (LWP 8135)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1254376528 (LWP 8135)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1237591120 (LWP 8133)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1229198416 (LWP 8132)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1220805712 (LWP 8131)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. [Switching to Thread -1254376528 (LWP 8135)] Breakpoint 3, SignalHandler (sig=64, sip=16_b53baf8c, uap=16_b53bb00c) at ThreadPThread.m3:1180 1180 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b53baf8c, uap=16_b53bb00c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb755f3c1 in __lll_mutex_unlock_wake () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb755c2df in _L_mutex_unlock_128 () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb53bb358 in ?? () #6 0xb75cecef in Release (m=16_b75fadf4) at ThreadPThread.m3:186 #7 0xb75cecef in Release (m=16_b73c0004) at ThreadPThread.m3:186 #8 0xb75d1aa9 in RunThread (me=16_08054700) at ThreadPThread.m3:536 #9 0xb75d17e6 in ThreadBase (param=16_08054700) at ThreadPThread.m3:521 #10 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #11 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. [Switching to Thread -1229198416 (LWP 8132)] Breakpoint 3, SignalHandler (sig=64, sip=16_b6bbdf9c, uap=16_b6bbe01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** [Switching to Thread -1237591120 (LWP 8133)] Breakpoint 3, SignalHandler (sig=64, sip=16_b63bcf9c, uap=16_b63bd01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b63bcf9c, uap=16_b63bd01c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb74b2b8c in sched_yield () from /lib/tls/i686/cmov/libc.so.6 #4 0xb75d2fce in Yield () at ThreadPThread.m3:712 #5 0x0804b844 in PrintId (cl=16_b73c70a0) at NThreads.m3:25 #6 0xb75d1b21 in RunThread (me=16_08054560) at ThreadPThread.m3:540 #7 0xb75d17e6 in ThreadBase (param=16_08054560) at ThreadPThread.m3:521 #8 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #9 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed.[Switching to Thread -1220805712 (LWP 8131)] Breakpoint 3, SignalHandler (sig=64, sip=16_b73bef9c, uap=16_b73bf01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b73bef9c, uap=16_b73bf01c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb74b2b8c in sched_yield () from /lib/tls/i686/cmov/libc.so.6 #4 0xb75d2fce in Yield () at ThreadPThread.m3:712 #5 0x0804b844 in PrintId (cl=16_b73c7010) at NThreads.m3:25 #6 0xb75d1b21 in RunThread (me=16_080543c0) at ThreadPThread.m3:540 #7 0xb75d17e6 in ThreadBase (param=16_080543c0) at ThreadPThread.m3:521 #8 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #9 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed. *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Program received signal SIG64, Real-time event 64. [Switching to Thread -1220532544 (LWP 8125)] 0xffffe410 in __kernel_vsyscall () (m3gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb755cc76 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb75d5ae0 in LockHeap () at ThreadPThread.m3:1370 #3 0xb75a13ca in GetUntracedRef (def=16_b75faf38) at RTAllocator.m3:240 #4 0xb75a0b4a in AllocateUntracedRef (defn=16_b75faf38) at RTAllocator.m3:146 #5 0xb75d2003 in Fork (closure=16_b73c7178) at ThreadPThread.m3:575 #6 0x0804b8b6 in Fork () at NThreads.m3:33 #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 #8 0xb75ba87a in RunMainBody (m=16_0804dc60) at RTLinker.m3:399 #9 0xb75b9174 in AddUnitI (m=16_0804dc60) at RTLinker.m3:113 #10 0xb75b920b in AddUnit (b={"NThreads_M3", Declared at: NThreads.m3:38}) at RTLinker.m3:122 #11 0x08048ea8 in main (argc=1, argv=0xbf860fd4, envp=0xbf860fdc) at _m3main.mc:4 (m3gdb) cont Continuing. *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Breakpoint 3, SignalHandler (sig=64, sip=16_bf8607fc, uap=16_bf86087c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_bf8607fc, uap=16_bf86087c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb755cc76 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb75d5ae0 in LockHeap () at ThreadPThread.m3:1370 #5 0xb75a13ca in GetUntracedRef (def=16_b75faf38) at RTAllocator.m3:240 #6 0xb75a0b4a in AllocateUntracedRef (defn=16_b75faf38) at RTAllocator.m3:146 #7 0xb75d2003 in Fork (closure=16_b73c7178) at ThreadPThread.m3:575 #8 0x0804b8b6 in Fork () at NThreads.m3:33 #9 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 #10 0xb75ba87a in RunMainBody (m=16_0804dc60) at RTLinker.m3:399 #11 0xb75b9174 in AddUnitI (m=16_0804dc60) at RTLinker.m3:113 #12 0xb75b920b in AddUnit (b={"NThreads_M3", Declared at: NThreads.m3:38}) at RTLinker.m3:122 #13 0x08048ea8 in main (argc=1, argv=0xbf860fd4, envp=0xbf860fdc) at _m3main.mc:4 (m3gdb) cont Continuing. 4 Program received signal SIGABRT, Aborted. [Switching to Thread -1254376528 (LWP 8135)] 0xffffe410 in __kernel_vsyscall () (m3gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb742b9a1 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb742d2b9 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb75cb72f in Crash () at RTOS.m3:20 #4 0xb75be204 in Crash (msg=NIL) at RTProcess.m3:65 #5 0xb75bb965 in EndError (crash=TRUE) at RTError.m3:115 #6 0xb75bb61a in MsgS (file=16_b75fabf8, line=1184, msgA=16_b75f4e08, msgB=16_b75ef3b0, msgC=16_b75f4e08) at RTError.m3:40 #7 0xb75bbdf2 in Crash (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE, rte=16_b75ef260) at RTException.m3:79 #8 0xb75bbaee in DefaultBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:39 #9 0xb75bba33 in InvokeBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:25 #10 0xb75ccfa8 in Raise (act= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END) at RTExFrame.m3:29 #11 0xb75bbb8e in DefaultBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:47 #12 0xb75bba33 in InvokeBackstop (a= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END, raises=FALSE) at RTException.m3:25 #13 0xb75ccfa8 in Raise (act= RECORD exception = 16_b75ef260; arg = 16_0000000c; module = 16_b75fadc0; line = 1184; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b75ef260; un_arg = NIL; END) at RTExFrame.m3:29 #14 0xb759fcff in ReportFault (module=16_b75fadc0, info=37888) at RTHooks.m3:110 #15 0xb75d62de in _m3_fault (arg=37888) from /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 #16 0xb75d4e8e in SignalHandler (sig=64, sip=16_b53baf8c, uap=16_b53bb00c) at ThreadPThread.m3:1184 #17 #18 0xffffe410 in __kernel_vsyscall () #19 0xb755f3c1 in __lll_mutex_unlock_wake () from /lib/tls/i686/cmov/libpthread.so.0 #20 0xb755c2df in _L_mutex_unlock_128 () from /lib/tls/i686/cmov/libpthread.so.0 #21 0xb53bb358 in ?? () ---Type to continue, or q to quit--- #22 0xb75cecef in Release (m=16_b75fadf4) at ThreadPThread.m3:186 #23 0xb75cecef in Release (m=16_b73c0004) at ThreadPThread.m3:186 #24 0xb75d1aa9 in RunThread (me=16_08054700) at ThreadPThread.m3:536 #25 0xb75d17e6 in ThreadBase (param=16_08054700) at ThreadPThread.m3:521 #26 0xb755a341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #27 0xb74cc4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) cont Continuing. 4Couldn't get registers: No such process. (m3gdb) Thanks --- "Daniel Alejandro Benavides D." wrote: > Hi: > With @M3noincremental just runs for while > > 1 2 3 1 2 3 10 > 5 4 > > and in this state its like a freezed program, it > does > not respond to the keyboard input. > > With @M3nogenerational or @M3nogc runs just fine. > > What could be the problem? What else could be useful > to do? > > Thanks > > --- Antony Hosking wrote: > > > In the pthread implementation scheduling is > > performed by the OS so > > there is no way to say that any particular thread > is > > *alive*, just > > that it is eligible to run should the scheduler > > choose to run it > > (indeed on an SMP more than one thread can run at > a > > time). The user- > > thread implementation has its own scheduler, so it > > knows precisely > > which thread is running at any point in time. > > > > Are you saying there is a bug in the current > pthread > > implementation? > > If so, then I'd like a more precise > characterization > > that I can > > pursue and fix. > > > > On Sep 27, 2007, at 2:32 AM, Daniel Alejandro > > Benavides D. wrote: > > > > > Hi: > > > I am testing some examples of Chapter 16 of > Laszlo > > > book, but the text shows me that now the > NThreads > > > example where 10 threads are being showing the > IDs > > (1, > > > 2, ... ,10). > > > This is tested on ubuntu Dapper OS, which still > > allows > > > the use of user space threads implementation. > > > Attached are some animated gif files that show > in > > > (sorry have no web page available) > > > LINUXLIBC6.gif exmaple execution of Systems > level > > > threads > > > LINUXLIBC62.gif example execution of User space > > > threads > > > LINUXLIBC62a.gif example execution of User space > > > threads after it ends > > > > > > Why the different versions of thread > > implementation > > > are different, in terms of what showthread shows > > that > > > all the threads are "locking" (9 almost all > time) > > and > > > 2 (the first and third form left to right) are > > "alive" > > > in the Pthread case, and why in the user space > > threads > > > case they are "alive" green color almost always > if > > > they are not running. > > > The worst thing is the behaviour of the > appication > > is > > > very rare, It should be running until a key > > (enter) is > > > pressed down; It just runs some seconds in > pthread > > > case. > > > > > > Besides why some many objects are shown in > shownew > > > with the user space threaded program. > > > > > > The linking information of ldd output is below. > > > LINUXLIBC6 is current cvs compiled example > > > LINUXLIBC&2 compiled with user spce threads. > > > > > > on LINUXLIBC6 with user space threads, June 9th > > the > > > date It was compiled. > > > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > > LINUXLIBC62/NThreads > > > linux-gate.so.1 => (0xffffe000) > > > libm3local.so.5 => > > > > > > /usr/local/cm3/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > > (0xb7faf000) > > > libm3.so.5 => > > > /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.so.5 > > > (0xb7e90000) > > > libm3core.so.5 => > > > > > > /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > > (0xb760f000) > > > libm3gcdefs.so.5 => > > > /usr/local/cm3/lib/libm3gcdefs.so.5 (0xb760d000) > > > libm.so.6 => > /lib/tls/i686/cmov/libm.so.6 > > > (0xb75d1000) > > > libc.so.6 => > /lib/tls/i686/cmov/libc.so.6 > > > (0xb74a2000) > > > /lib/ld-linux.so.2 (0xb7fbd000) > > > > > > > > > on LINUXLIBC6 with system threads: > > > > > > danielb at danielb-desktop:~/code/m3/parallel$ ldd > > > LINUXLIBC6/NThreads > > > linux-gate.so.1 => (0xffffe000) > > > libm3local.so.5 => > > > > > > /usr/local/cm3-cvs4/pkg/m3local/LINUXLIBC6/libm3local.so.5 > > > (0xb7f51000) > > > libm3.so.5 => > > > > > > /usr/local/cm3-cvs4/pkg/libm3/LINUXLIBC6/libm3.so.5 > > > (0xb7e1e000) > > > libm3core.so.5 => > > > > > > /usr/local/cm3-cvs4/pkg/m3core/LINUXLIBC6/libm3core.so.5 > > > (0xb7592000) > > > libpthread.so.0 => > > > /lib/tls/i686/cmov/libpthread.so.0 (0xb7567000) > > > libm.so.6 => > /lib/tls/i686/cmov/libm.so.6 > > > (0xb7544000) > > > libc.so.6 => > /lib/tls/i686/cmov/libc.so.6 > > > (0xb7415000) > > > /lib/ld-linux.so.2 (0xb7f5f000) > > > > > > > > > the source code is this > > > > > > MODULE NThreads EXPORTS Main; > > > (*22.02.95. LB*) > > > (* Program starts "N" threads which output their > > ID > > > and terminate > > > if a key is pressed (on some systems you have > > to > > > press the return > > > key). > > > *) > > > > > > IMPORT Thread, SIO; > > > FROM Scheduler IMPORT Yield; > > > > > > CONST > > > N = 10; > > > TYPE > > > Threads = [1..N]; > > > Closure = Thread.Closure OBJECT > > > id: Threads; > > > (*identifies thread*) > > > OVERRIDES > > > apply:= PrintId; > > > END; (*Closure*) > > > > > > PROCEDURE PrintId(cl: Closure): REFANY = > > > BEGIN > > > REPEAT > > > SIO.PutInt(cl.id); > > > IF cl.id = LAST(Threads) THEN SIO.Nl() > END; > > > Yield(); > > > (*yields to other threads*) > > > UNTIL SIO.Available(); > > > RETURN NIL; > > > (*return value not used*) > > > END PrintId; > > > > > > PROCEDURE Fork() = > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From dabenavidesd at yahoo.es Fri Sep 28 17:02:59 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 28 Sep 2007 17:02:59 +0200 (CEST) Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <860980.52128.qm@web27109.mail.ukl.yahoo.com> Message-ID: <532140.63470.qm@web27105.mail.ukl.yahoo.com> Hi: I would like to know if it is necessary to turn down the garbage collection to debug a M3 program. I know running a program inside gdb in general could cause some runtime diferences withj normal execution, like the cout<< in C++, which is reliable under debugging conditions, but not in normal execution conditions in a program which calls it constantly (that happened me on 2005), so one can note that the behaviour would be better on debug conditions, thats why I think this is not maybe the problem on NThreads program (is easy to say that if we think that the runtime errors showed inside m3gdb are not present when the program executes normally), tough I debugged one more time to show other backtraces: (m3gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads Error in re-setting breakpoint 3: No source file named ThreadPThread.m3. Error in re-setting breakpoint 3: No source file named ThreadPThread.m3. Error in re-setting breakpoint 3: No source file named ThreadPThread.m3. Breakpoint 3 at 0xb7654dba: file ThreadPThread.m3, line 1180. [Thread debugging using libthread_db enabled] [New Thread -1220008256 (LWP 8474)] [Switching to Thread -1220008256 (LWP 8474)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447010) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1220281424 (LWP 8495)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447058) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. [New Thread -1228674128 (LWP 8496)] 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb74470a0) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 1[New Thread -1237066832 (LWP 8497)] 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb74470e8) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 2 1[New Thread -1245459536 (LWP 8498)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447130) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. 3 2 1[New Thread -1253852240 (LWP 8499)] 3 2 1 Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1253852240 (LWP 8499)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. [Switching to Thread -1220008256 (LWP 8474)] Breakpoint 1, NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at NThreads.m3:14 14 Closure = Thread.Closure OBJECT (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1237066832 (LWP 8497)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1228674128 (LWP 8496)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. Program received signal SIG64, Real-time event 64. [Switching to Thread -1220281424 (LWP 8495)] 0xffffe410 in __kernel_vsyscall () (m3gdb) cont Continuing. [Switching to Thread -1253852240 (LWP 8499)] Breakpoint 3, SignalHandler (sig=64, sip=16_b543af8c, uap=16_b543b00c) at ThreadPThread.m3:1180 1180 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) where #0 SignalHandler (sig=64, sip=16_b543af8c, uap=16_b543b00c) at ThreadPThread.m3:1180 #1 #2 0xffffe410 in __kernel_vsyscall () #3 0xb75df3c1 in __lll_mutex_unlock_wake () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb75dc2df in _L_mutex_unlock_128 () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb543b358 in ?? () #6 0xb764ecef in Release (m=16_b767adf4) at ThreadPThread.m3:186 #7 0xb764ecef in Release (m=16_b7440004) at ThreadPThread.m3:186 #8 0xb7651aa9 in RunThread (me=16_08054700) at ThreadPThread.m3:536 #9 0xb76517e6 in ThreadBase (param=16_08054700) at ThreadPThread.m3:521 #10 0xb75da341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #11 0xb754c4ee in clone () from /lib/tls/i686/cmov/libc.so.6 (m3gdb) step 1181 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1237066832 (LWP 8497)] Breakpoint 3, SignalHandler (sig=64, sip=16_b643cf9c, uap=16_b643d01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1228674128 (LWP 8496)] Breakpoint 3, SignalHandler (sig=64, sip=16_b6c3df9c, uap=16_b6c3e01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step [Switching to Thread -1220281424 (LWP 8495)] Breakpoint 3, SignalHandler (sig=64, sip=16_b743ef9c, uap=16_b743f01c) at ThreadPThread.m3:1180 1180 in ThreadPThread.m3 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** Program received signal SIG64, Real-time event 64. [Switching to Thread -1220008256 (LWP 8474)] 0xffffe410 in __kernel_vsyscall () (m3gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb75dcc76 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7655ae0 in LockHeap () at ThreadPThread.m3:1370 #3 0xb76213ca in GetUntracedRef (def=16_b767af38) at RTAllocator.m3:240 #4 0xb7620b4a in AllocateUntracedRef (defn=16_b767af38) at RTAllocator.m3:146 #5 0xb7652003 in Fork (closure=16_b7447178) at ThreadPThread.m3:575 #6 0x0804b8b6 in Fork () at NThreads.m3:33 #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 #8 0xb763a87a in RunMainBody (m=16_0804dc60) at RTLinker.m3:399 #9 0xb7639174 in AddUnitI (m=16_0804dc60) at RTLinker.m3:113 #10 0xb763920b in AddUnit (b={"NThreads_M3", Declared at: NThreads.m3:38}) at RTLinker.m3:122 #11 0x08048ea8 in main (argc=1, argv=0xbfce0c04, envp=0xbfce0c0c) at _m3main.mc:4 (m3gdb) step Single stepping until exit from function __kernel_vsyscall, which has no line number information. SignalHandler (sig=64, sip=16_bfce042c, uap=16_bfce04ac) at ThreadPThread.m3:1157 1157 in ThreadPThread.m3 (m3gdb) step *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 1184 *** 1161 in ThreadPThread.m3 (m3gdb) step m3_Cerrno_GetErrno () at ../src/C/Common/CerrnoC.c:10 10 ../src/C/Common/CerrnoC.c: No such file or directory. in ../src/C/Common/CerrnoC.c Current language: auto; currently c (m3gdb) step 11 in ../src/C/Common/CerrnoC.c (m3gdb) step SignalHandler (sig=64, sip=16_bfce042c, uap=16_bfce04ac) at ThreadPThread.m3:1163 1163 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 Current language: auto; currently Modula-3 (m3gdb) step GetActivation () at ThreadPThread.m3:368 368 in ThreadPThread.m3 (m3gdb) step 369 in ThreadPThread.m3 (m3gdb) step SignalHandler (sig=64, sip=16_bfce042c, uap=16_bfce04ac) at ThreadPThread.m3:1166 1166 in ThreadPThread.m3 (m3gdb) step 1167 in ThreadPThread.m3 (m3gdb) step 1168 in ThreadPThread.m3 (m3gdb) step 1169 in ThreadPThread.m3 (m3gdb) step 1172 in ThreadPThread.m3 (m3gdb) step 1174 in ThreadPThread.m3 (m3gdb) step 1175 in ThreadPThread.m3 (m3gdb) step 1178 in ThreadPThread.m3 (m3gdb) step 4 4 4 4 4 4 Program received signal SIGABRT, Aborted. [Switching to Thread -1237066832 (LWP 8497)] 0xffffe410 in __kernel_vsyscall () (m3gdb) step Single stepping until exit from function __kernel_vsyscall, Thanks --- "Daniel Alejandro Benavides D." wrote: > Hi: > > I debugged for a while the program with > handle all nostop > handle EXC_SOFTWARE stop > handle EXC_BREAKPOINT stop > > getting this: > > Breakpoint 4, SignalHandler (sig=64, > sip=16_b640ff9c, > uap=16_b641001c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1254036560 (LWP 8072)] > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b540df8c, > uap=16_b540e00c) at ThreadPThread.m3:1184 > 1184 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1237251152 (LWP 8067)] > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b640ff9c, > uap=16_b641001c) at ThreadPThread.m3:1184 > 1184 in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b640ff9c, > uap=16_b641001c) at ThreadPThread.m3:1184 > #1 > #2 0xffffe410 in __kernel_vsyscall () > #3 0xb7505b8c in sched_yield () from > /lib/tls/i686/cmov/libc.so.6 > #4 0xb7625fce in Yield () at ThreadPThread.m3:712 > #5 0x0804b844 in PrintId (cl=16_b741b0a0) at > NThreads.m3:25 > #6 0xb7624b21 in RunThread (me=16_08054560) at > ThreadPThread.m3:540 > #7 0xb76247e6 in ThreadBase (param=16_08054560) at > ThreadPThread.m3:521 > #8 0xb75ad341 in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #9 0xb751f4ee in clone () from > /lib/tls/i686/cmov/libc.so.6 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file > "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > [Switching to Thread -1228858448 (LWP 8066)] > > Breakpoint 4, SignalHandler (sig=64, > sip=16_b6c10f9c, > uap=16_b6c1101c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b6c10f9c, > uap=16_b6c1101c) at ThreadPThread.m3:1184 > 1184 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file > "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220465744 (LWP 8065)] > > Breakpoint 4, SignalHandler (sig=64, > sip=16_b7411f9c, > uap=16_b741201c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > 4 4 > Program received signal SIGABRT, Aborted. > 4Couldn't get registers: No such process. > (m3gdb) > ----------------------------------------------------- > And then without modifying the signal set: > > (m3gdb) break NThreads.m3:10 > Breakpoint 1 at 0x804b934: file NThreads.m3, line > 10. > (m3gdb) break ThreadPThread.m3:1180 > No source file named ThreadPThread.m3. > Make breakpoint pending on future shared library > load? > (y or [n]) y > Breakpoint 2 (ThreadPThread.m3:1180) pending. > (m3gdb) run > Starting program: > /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads > [Thread debugging using libthread_db enabled] > [New Thread -1220532544 (LWP 8125)] > Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, > line 1180. > Pending breakpoint "ThreadPThread.m3:1180" resolved > [Switching to Thread -1220532544 (LWP 8125)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7010) at NThreads.m3:14 > warning: Source file is more recent than executable. > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1220805712 (LWP 8131)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7058) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1229198416 (LWP 8132)] > 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c70a0) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 1[New Thread -1237591120 (LWP 8133)] > 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c70e8) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 2 1[New Thread -1245983824 (LWP 8134)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7130) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 3 2 1[New Thread -1254376528 (LWP 8135)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at > NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb73c7178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1254376528 (LWP 8135)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1237591120 (LWP 8133)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1229198416 (LWP 8132)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220805712 (LWP 8131)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1254376528 (LWP 8135)] > > Breakpoint 3, SignalHandler (sig=64, > sip=16_b53baf8c, > uap=16_b53bb00c) at ThreadPThread.m3:1180 > 1180 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b53baf8c, > === message truncated === ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 28 17:35:25 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Sep 2007 11:35:25 -0400 Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <532140.63470.qm@web27105.mail.ukl.yahoo.com> References: <532140.63470.qm@web27105.mail.ukl.yahoo.com> Message-ID: On Sep 28, 2007, at 11:02 AM, Daniel Alejandro Benavides D. wrote: > Hi: > I would like to know if it is necessary to turn down > the garbage collection to debug a M3 program. > I know running a program inside gdb in general could > cause some runtime diferences withj normal execution, > like the cout<< in C++, which is reliable under > debugging conditions, but not in normal execution > conditions in a program which calls it constantly > (that happened me on 2005), so one can note that the > behaviour would be better on debug conditions, thats > why I think this is not maybe the problem on NThreads > program (is easy to say that if we think that the > runtime errors showed inside m3gdb are not present > when the program executes normally), tough I debugged > one more time to show other backtraces: Debugging with GC enabled should be fine, except that you will not necessarily see the same non-deterministic behavior as when it runs outside the debugger. Regarding the assert that is failing, that indicates that sigwait is returning an error, which seems odd. I will try this program on my own Linux system. > > (m3gdb) run > The program being debugged has been started already. > Start it from the beginning? (y or n) y > Starting program: > /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Breakpoint 3 at 0xb7654dba: file ThreadPThread.m3, > line 1180. > [Thread debugging using libthread_db enabled] > [New Thread -1220008256 (LWP 8474)] > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447010) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1220281424 (LWP 8495)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447058) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1228674128 (LWP 8496)] > 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470a0) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 1[New Thread -1237066832 (LWP 8497)] > 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470e8) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 2 1[New Thread -1245459536 (LWP 8498)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447130) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 3 2 1[New Thread -1253852240 (LWP 8499)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at > NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1253852240 (LWP 8499)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1228674128 (LWP 8496)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220281424 (LWP 8495)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1253852240 (LWP 8499)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > 1180 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > #1 > #2 0xffffe410 in __kernel_vsyscall () > #3 0xb75df3c1 in __lll_mutex_unlock_wake () from > /lib/tls/i686/cmov/libpthread.so.0 > #4 0xb75dc2df in _L_mutex_unlock_128 () from > /lib/tls/i686/cmov/libpthread.so.0 > #5 0xb543b358 in ?? () > #6 0xb764ecef in Release (m=16_b767adf4) at > ThreadPThread.m3:186 > #7 0xb764ecef in Release (m=16_b7440004) at > ThreadPThread.m3:186 > #8 0xb7651aa9 in RunThread (me=16_08054700) at > ThreadPThread.m3:536 > #9 0xb76517e6 in ThreadBase (param=16_08054700) at > ThreadPThread.m3:521 > #10 0xb75da341 in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #11 0xb754c4ee in clone () from > /lib/tls/i686/cmov/libc.so.6 > (m3gdb) step > 1181 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1237066832 (LWP 8497)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b643cf9c, > uap=16_b643d01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1228674128 (LWP 8496)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b6c3df9c, > uap=16_b6c3e01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1220281424 (LWP 8495)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b743ef9c, > uap=16_b743f01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220008256 (LWP 8474)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) where > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb75dcc76 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/tls/i686/cmov/libpthread.so.0 > #2 0xb7655ae0 in LockHeap () at ThreadPThread.m3:1370 > #3 0xb76213ca in GetUntracedRef (def=16_b767af38) at > RTAllocator.m3:240 > #4 0xb7620b4a in AllocateUntracedRef > (defn=16_b767af38) at RTAllocator.m3:146 > #5 0xb7652003 in Fork (closure=16_b7447178) at > ThreadPThread.m3:575 > #6 0x0804b8b6 in Fork () at NThreads.m3:33 > #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 > #8 0xb763a87a in RunMainBody (m=16_0804dc60) at > RTLinker.m3:399 > #9 0xb7639174 in AddUnitI (m=16_0804dc60) at > RTLinker.m3:113 > #10 0xb763920b in AddUnit (b={"NThreads_M3", Declared > at: NThreads.m3:38}) at RTLinker.m3:122 > #11 0x08048ea8 in main (argc=1, argv=0xbfce0c04, > envp=0xbfce0c0c) at _m3main.mc:4 > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > which has no line number information. > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1157 > 1157 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > 1161 in ThreadPThread.m3 > (m3gdb) step > m3_Cerrno_GetErrno () at ../src/C/Common/CerrnoC.c:10 > 10 ../src/C/Common/CerrnoC.c: No such file or > directory. > in ../src/C/Common/CerrnoC.c > Current language: auto; currently c > (m3gdb) step > 11 in ../src/C/Common/CerrnoC.c > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1163 > 1163 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > Current language: auto; currently Modula-3 > (m3gdb) step > GetActivation () at ThreadPThread.m3:368 > 368 in ThreadPThread.m3 > (m3gdb) step > 369 in ThreadPThread.m3 > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1166 > 1166 in ThreadPThread.m3 > (m3gdb) step > 1167 in ThreadPThread.m3 > (m3gdb) step > 1168 in ThreadPThread.m3 > (m3gdb) step > 1169 in ThreadPThread.m3 > (m3gdb) step > 1172 in ThreadPThread.m3 > (m3gdb) step > 1174 in ThreadPThread.m3 > (m3gdb) step > 1175 in ThreadPThread.m3 > (m3gdb) step > 1178 in ThreadPThread.m3 > (m3gdb) step > 4 4 4 4 4 4 > Program received signal SIGABRT, Aborted. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > > Thanks > > --- "Daniel Alejandro Benavides D." > wrote: > >> Hi: >> >> I debugged for a while the program with >> handle all nostop >> handle EXC_SOFTWARE stop >> handle EXC_BREAKPOINT stop >> >> getting this: >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1254036560 (LWP 8072)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b540df8c, >> uap=16_b540e00c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1237251152 (LWP 8067)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> #1 >> #2 0xffffe410 in __kernel_vsyscall () >> #3 0xb7505b8c in sched_yield () from >> /lib/tls/i686/cmov/libc.so.6 >> #4 0xb7625fce in Yield () at ThreadPThread.m3:712 >> #5 0x0804b844 in PrintId (cl=16_b741b0a0) at >> NThreads.m3:25 >> #6 0xb7624b21 in RunThread (me=16_08054560) at >> ThreadPThread.m3:540 >> #7 0xb76247e6 in ThreadBase (param=16_08054560) at >> ThreadPThread.m3:521 >> #8 0xb75ad341 in start_thread () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #9 0xb751f4ee in clone () from >> /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> [Switching to Thread -1228858448 (LWP 8066)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220465744 (LWP 8065)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b7411f9c, >> uap=16_b741201c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> 4 4 >> Program received signal SIGABRT, Aborted. >> 4Couldn't get registers: No such process. >> (m3gdb) >> > ----------------------------------------------------- >> And then without modifying the signal set: >> >> (m3gdb) break NThreads.m3:10 >> Breakpoint 1 at 0x804b934: file NThreads.m3, line >> 10. >> (m3gdb) break ThreadPThread.m3:1180 >> No source file named ThreadPThread.m3. >> Make breakpoint pending on future shared library >> load? >> (y or [n]) y >> Breakpoint 2 (ThreadPThread.m3:1180) pending. >> (m3gdb) run >> Starting program: >> /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads >> [Thread debugging using libthread_db enabled] >> [New Thread -1220532544 (LWP 8125)] >> Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, >> line 1180. >> Pending breakpoint "ThreadPThread.m3:1180" resolved >> [Switching to Thread -1220532544 (LWP 8125)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7010) at NThreads.m3:14 >> warning: Source file is more recent than executable. >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1220805712 (LWP 8131)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7058) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1229198416 (LWP 8132)] >> 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70a0) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 1[New Thread -1237591120 (LWP 8133)] >> 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70e8) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 2 1[New Thread -1245983824 (LWP 8134)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7130) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 3 2 1[New Thread -1254376528 (LWP 8135)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at >> NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1254376528 (LWP 8135)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1237591120 (LWP 8133)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1229198416 (LWP 8132)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220805712 (LWP 8131)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> [Switching to Thread -1254376528 (LWP 8135)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b53baf8c, >> uap=16_b53bb00c) at ThreadPThread.m3:1180 >> 1180 ThreadPThread.m3: No such file or directory. >> in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b53baf8c, >> > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 28 19:40:22 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Sep 2007 13:40:22 -0400 Subject: [M3devel] System and User space Threads on LINUXLIBC6 In-Reply-To: <532140.63470.qm@web27105.mail.ukl.yahoo.com> References: <532140.63470.qm@web27105.mail.ukl.yahoo.com> Message-ID: <11736B53-EB34-4501-ABAF-496CE88C9170@cs.purdue.edu> The nthreads program runs just fine on my Fedora Core system (modulo unpredictable scheduling which is to be expected for a program running with system threads). I wonder if the problems you are seeing come from an old version (non-NPTL) of libpthread on your Linux system? I have glibc 2.5.18. On Sep 28, 2007, at 11:02 AM, Daniel Alejandro Benavides D. wrote: > Hi: > I would like to know if it is necessary to turn down > the garbage collection to debug a M3 program. > I know running a program inside gdb in general could > cause some runtime diferences withj normal execution, > like the cout<< in C++, which is reliable under > debugging conditions, but not in normal execution > conditions in a program which calls it constantly > (that happened me on 2005), so one can note that the > behaviour would be better on debug conditions, thats > why I think this is not maybe the problem on NThreads > program (is easy to say that if we think that the > runtime errors showed inside m3gdb are not present > when the program executes normally), tough I debugged > one more time to show other backtraces: > > (m3gdb) run > The program being debugged has been started already. > Start it from the beginning? (y or n) y > Starting program: > /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Error in re-setting breakpoint 3: > No source file named ThreadPThread.m3. > Breakpoint 3 at 0xb7654dba: file ThreadPThread.m3, > line 1180. > [Thread debugging using libthread_db enabled] > [New Thread -1220008256 (LWP 8474)] > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447010) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1220281424 (LWP 8495)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447058) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > [New Thread -1228674128 (LWP 8496)] > 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470a0) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 1[New Thread -1237066832 (LWP 8497)] > 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb74470e8) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 2 1[New Thread -1245459536 (LWP 8498)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447130) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > 3 2 1[New Thread -1253852240 (LWP 8499)] > 3 2 1 > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > NThreads_M3_te29971a7_INIT (L_2=0xb7447178) at > NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1253852240 (LWP 8499)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1220008256 (LWP 8474)] > > Breakpoint 1, NThreads_M3_te29971a7_INIT > (L_2=0xb7447178) at NThreads.m3:14 > 14 Closure = Thread.Closure OBJECT > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1228674128 (LWP 8496)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220281424 (LWP 8495)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) cont > Continuing. > [Switching to Thread -1253852240 (LWP 8499)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > 1180 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > (m3gdb) where > #0 SignalHandler (sig=64, sip=16_b543af8c, > uap=16_b543b00c) at ThreadPThread.m3:1180 > #1 > #2 0xffffe410 in __kernel_vsyscall () > #3 0xb75df3c1 in __lll_mutex_unlock_wake () from > /lib/tls/i686/cmov/libpthread.so.0 > #4 0xb75dc2df in _L_mutex_unlock_128 () from > /lib/tls/i686/cmov/libpthread.so.0 > #5 0xb543b358 in ?? () > #6 0xb764ecef in Release (m=16_b767adf4) at > ThreadPThread.m3:186 > #7 0xb764ecef in Release (m=16_b7440004) at > ThreadPThread.m3:186 > #8 0xb7651aa9 in RunThread (me=16_08054700) at > ThreadPThread.m3:536 > #9 0xb76517e6 in ThreadBase (param=16_08054700) at > ThreadPThread.m3:521 > #10 0xb75da341 in start_thread () from > /lib/tls/i686/cmov/libpthread.so.0 > #11 0xb754c4ee in clone () from > /lib/tls/i686/cmov/libc.so.6 > (m3gdb) step > 1181 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1237066832 (LWP 8497)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b643cf9c, > uap=16_b643d01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1228674128 (LWP 8496)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b6c3df9c, > uap=16_b6c3e01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > [Switching to Thread -1220281424 (LWP 8495)] > > Breakpoint 3, SignalHandler (sig=64, sip=16_b743ef9c, > uap=16_b743f01c) at ThreadPThread.m3:1180 > 1180 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > > Program received signal SIG64, Real-time event 64. > [Switching to Thread -1220008256 (LWP 8474)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) where > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb75dcc76 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/tls/i686/cmov/libpthread.so.0 > #2 0xb7655ae0 in LockHeap () at ThreadPThread.m3:1370 > #3 0xb76213ca in GetUntracedRef (def=16_b767af38) at > RTAllocator.m3:240 > #4 0xb7620b4a in AllocateUntracedRef > (defn=16_b767af38) at RTAllocator.m3:146 > #5 0xb7652003 in Fork (closure=16_b7447178) at > ThreadPThread.m3:575 > #6 0x0804b8b6 in Fork () at NThreads.m3:33 > #7 0x0804b928 in NThreads (mode=1) at NThreads.m3:39 > #8 0xb763a87a in RunMainBody (m=16_0804dc60) at > RTLinker.m3:399 > #9 0xb7639174 in AddUnitI (m=16_0804dc60) at > RTLinker.m3:113 > #10 0xb763920b in AddUnit (b={"NThreads_M3", Declared > at: NThreads.m3:38}) at RTLinker.m3:122 > #11 0x08048ea8 in main (argc=1, argv=0xbfce0c04, > envp=0xbfce0c0c) at _m3main.mc:4 > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > which has no line number information. > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1157 > 1157 in ThreadPThread.m3 > (m3gdb) step > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", > line 1184 > *** > > 1161 in ThreadPThread.m3 > (m3gdb) step > m3_Cerrno_GetErrno () at ../src/C/Common/CerrnoC.c:10 > 10 ../src/C/Common/CerrnoC.c: No such file or > directory. > in ../src/C/Common/CerrnoC.c > Current language: auto; currently c > (m3gdb) step > 11 in ../src/C/Common/CerrnoC.c > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1163 > 1163 ThreadPThread.m3: No such file or directory. > in ThreadPThread.m3 > Current language: auto; currently Modula-3 > (m3gdb) step > GetActivation () at ThreadPThread.m3:368 > 368 in ThreadPThread.m3 > (m3gdb) step > 369 in ThreadPThread.m3 > (m3gdb) step > SignalHandler (sig=64, sip=16_bfce042c, > uap=16_bfce04ac) at ThreadPThread.m3:1166 > 1166 in ThreadPThread.m3 > (m3gdb) step > 1167 in ThreadPThread.m3 > (m3gdb) step > 1168 in ThreadPThread.m3 > (m3gdb) step > 1169 in ThreadPThread.m3 > (m3gdb) step > 1172 in ThreadPThread.m3 > (m3gdb) step > 1174 in ThreadPThread.m3 > (m3gdb) step > 1175 in ThreadPThread.m3 > (m3gdb) step > 1178 in ThreadPThread.m3 > (m3gdb) step > 4 4 4 4 4 4 > Program received signal SIGABRT, Aborted. > [Switching to Thread -1237066832 (LWP 8497)] > 0xffffe410 in __kernel_vsyscall () > (m3gdb) step > Single stepping until exit from function > __kernel_vsyscall, > > Thanks > > --- "Daniel Alejandro Benavides D." > wrote: > >> Hi: >> >> I debugged for a while the program with >> handle all nostop >> handle EXC_SOFTWARE stop >> handle EXC_BREAKPOINT stop >> >> getting this: >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1254036560 (LWP 8072)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b540df8c, >> uap=16_b540e00c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> [Switching to Thread -1237251152 (LWP 8067)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b640ff9c, >> uap=16_b641001c) at ThreadPThread.m3:1184 >> #1 >> #2 0xffffe410 in __kernel_vsyscall () >> #3 0xb7505b8c in sched_yield () from >> /lib/tls/i686/cmov/libc.so.6 >> #4 0xb7625fce in Yield () at ThreadPThread.m3:712 >> #5 0x0804b844 in PrintId (cl=16_b741b0a0) at >> NThreads.m3:25 >> #6 0xb7624b21 in RunThread (me=16_08054560) at >> ThreadPThread.m3:540 >> #7 0xb76247e6 in ThreadBase (param=16_08054560) at >> ThreadPThread.m3:521 >> #8 0xb75ad341 in start_thread () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #9 0xb751f4ee in clone () from >> /lib/tls/i686/cmov/libc.so.6 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> [Switching to Thread -1228858448 (LWP 8066)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b6c10f9c, >> uap=16_b6c1101c) at ThreadPThread.m3:1184 >> 1184 in ThreadPThread.m3 >> (m3gdb) step >> >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file >> "../src/thread/PTHREAD/ThreadPThread.m3", >> line 1184 >> *** >> >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220465744 (LWP 8065)] >> >> Breakpoint 4, SignalHandler (sig=64, >> sip=16_b7411f9c, >> uap=16_b741201c) at ThreadPThread.m3:1180 >> 1180 in ThreadPThread.m3 >> (m3gdb) step >> 4 4 >> Program received signal SIGABRT, Aborted. >> 4Couldn't get registers: No such process. >> (m3gdb) >> > ----------------------------------------------------- >> And then without modifying the signal set: >> >> (m3gdb) break NThreads.m3:10 >> Breakpoint 1 at 0x804b934: file NThreads.m3, line >> 10. >> (m3gdb) break ThreadPThread.m3:1180 >> No source file named ThreadPThread.m3. >> Make breakpoint pending on future shared library >> load? >> (y or [n]) y >> Breakpoint 2 (ThreadPThread.m3:1180) pending. >> (m3gdb) run >> Starting program: >> /home/danielb/code/m3/parallel/LINUXLIBC6/NThreads >> [Thread debugging using libthread_db enabled] >> [New Thread -1220532544 (LWP 8125)] >> Breakpoint 3 at 0xb75d4dba: file ThreadPThread.m3, >> line 1180. >> Pending breakpoint "ThreadPThread.m3:1180" resolved >> [Switching to Thread -1220532544 (LWP 8125)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7010) at NThreads.m3:14 >> warning: Source file is more recent than executable. >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1220805712 (LWP 8131)] >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7058) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> [New Thread -1229198416 (LWP 8132)] >> 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70a0) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 1[New Thread -1237591120 (LWP 8133)] >> 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c70e8) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 2 1[New Thread -1245983824 (LWP 8134)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7130) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> 3 2 1[New Thread -1254376528 (LWP 8135)] >> 3 2 1 >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> NThreads_M3_te29971a7_INIT (L_2=0xb73c7178) at >> NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Breakpoint 1, NThreads_M3_te29971a7_INIT >> (L_2=0xb73c7178) at NThreads.m3:14 >> 14 Closure = Thread.Closure OBJECT >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1254376528 (LWP 8135)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1237591120 (LWP 8133)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1229198416 (LWP 8132)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> >> Program received signal SIG64, Real-time event 64. >> [Switching to Thread -1220805712 (LWP 8131)] >> 0xffffe410 in __kernel_vsyscall () >> (m3gdb) cont >> Continuing. >> [Switching to Thread -1254376528 (LWP 8135)] >> >> Breakpoint 3, SignalHandler (sig=64, >> sip=16_b53baf8c, >> uap=16_b53bb00c) at ThreadPThread.m3:1180 >> 1180 ThreadPThread.m3: No such file or directory. >> in ThreadPThread.m3 >> (m3gdb) where >> #0 SignalHandler (sig=64, sip=16_b53baf8c, >> > === message truncated === > > > > > ______________________________________________________________________ > ______________ > S? un Mejor Amante del Cine > ?Quieres saber c?mo? ?Deja que otras personas te ayuden! > http://advision.webevents.yahoo.com/reto/entretenimiento.html From hosking at cs.purdue.edu Fri Sep 28 19:59:32 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 28 Sep 2007 13:59:32 -0400 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> <1B153BC7-A186-4F33-A019-91ADFEEC97FD@cs.purdue.edu> <90E9CEA8-6406-44E1-8265-9188B51B850D@cs.purdue.edu> Message-ID: <2559758D-5DE9-4CAF-B9D1-77F851B6310B@cs.purdue.edu> I forget if we tried the "paranoid" GC configuration or not. Can you run with @M3paranoidgc and see what happens? Again, I am unable to replicate the problems you are seeing, even on my Solaris 10 box. On Sep 26, 2007, at 2:03 PM, Alex Bochannek wrote: > I am back from vacation. I just updated my cm3 tree and did the usual > "do-cm3-core buildship; install-cm3-compiler upgrade; do-cm3-std > buildship" dance. I then did a make clean on cvsup and a make install. > > I not get reproducible core dumps every time I run it, with or without > GUI. cvsup startes and then cores: > > > -bash-3.00$ cvsup -g cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x51e9782c > *** > > Abort (core dumped) > -bash-3.00$ mdb core > $c > libc.so.1`_lwp_kill+8(6, 0, feea4af8, ffffffff, feee8284, 6) > libc.so.1`abort+0x110(fec1eeb0, 1, 48c988, a8390, feeeb298, 0) > RTOS__Crash+4(1, 1d, df7fb0, e09fa0, 533dbc, 0) > RTProcess__Crash+0x98(0, a, 10, 0, 0, 0) > RTError__EndError+0x58(1, fec1f20c, fec1f210, fec1f214, 0, 0) > RTError__ErrorPC+0x1d8(51e9782c, 531bbc, 0, 0, 1, 0) > RTError__MsgPC+0x38(51e9782c, 531bbc, 0, 0, 0, 0) > RTSignal__SegV+0x68(b, fec1f730, fec1f478, 1, 0, 1) > libc.so.1`__sighndlr+0xc(b, fec1f730, fec1f478, 44381c, 0, 1) > libc.so.1`call_user_handler+0x3b8(b, 0, 8, 0, fed11800, fec1f478) > 0x51e9782c(feba49b0, 2f, 7fffffff, 0, 0, 0) > SupMisc__PathLast+0x1c(feba49b0, fec660b0, 4924a0, 0, 0, 0) > TreeList__PutCollectionList+0x3a00(fedc8cd0, fedb29b8, 1, 0, > fedeb430, 0) > TreeList__ListCollection+0x4a4(fedc8cd0, fedb29b8, feeecbc0, > fed11800, 533b2c, 0 > ) > TreeList__Apply+0x2dc(fedc8cd0, 1000, feeecbc0, fed11800, 533b68, 0) > ThreadPThread__RunThread+0x3c4(d4a1e0, 0, 0, 0, 0, 1) > ThreadPThread__ThreadBase+0x44(d4a1e0, fec20000, 0, 0, 44bae4, 1) > libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) > > I am not sure if that is even in the Modula-3 libraries, but you can > probably tell. Here's the ls; ldd: > > -rwxr-xr-x 1 root other 5396444 Sep 26 10:56 /usr/local/ > bin/cvsup > libXaw.so.5 => /usr/lib/libXaw.so.5 > libXmu.so.4 => /usr/lib/libXmu.so.4 > libXext.so.0 => /usr/lib/libXext.so.0 > libXt.so.4 => /usr/lib/libXt.so.4 > libX11.so.4 => /usr/lib/libX11.so.4 > libsocket.so.1 => /lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libw.so.1 => /lib/libw.so.1 > libdl.so.1 => /lib/libdl.so.1 > libpthread.so.1 => /lib/libpthread.so.1 > libthread.so.1 => /lib/libthread.so.1 > librt.so.1 => /lib/librt.so.1 > libm.so.2 => /lib/libm.so.2 > libc.so.1 => /lib/libc.so.1 > libSM.so.6 => /usr/openwin/lib/libSM.so.6 > libICE.so.6 => /usr/openwin/lib/libICE.so.6 > libmp.so.2 => /lib/libmp.so.2 > libmd5.so.1 => /lib/libmd5.so.1 > libscf.so.1 => /lib/libscf.so.1 > libaio.so.1 => /lib/libaio.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libmd5_psr.so.1 > > Hope this helps. Let me know what else I shoudl try. > > Alex. From alexb at juniper.net Fri Sep 28 22:59:29 2007 From: alexb at juniper.net (Alex Bochannek) Date: Fri, 28 Sep 2007 13:59:29 -0700 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: <2559758D-5DE9-4CAF-B9D1-77F851B6310B@cs.purdue.edu> (Tony Hosking's message of "Fri\, 28 Sep 2007 13\:59\:32 -0400") References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> <1B153BC7-A186-4F33-A019-91ADFEEC97FD@cs.purdue.edu> <90E9CEA8-6406-44E1-8265-9188B51B850D@cs.purdue.edu> <2559758D-5DE9-4CAF-B9D1-77F851B6310B@cs.purdue.edu> Message-ID: Tony Hosking writes: > I forget if we tried the "paranoid" GC configuration or not. Can you > run with @M3paranoidgc and see what happens? Again, I am unable to > replicate the problems you are seeing, even on my Solaris 10 box. Here's what I get now: -bash-3.00$ cvsup @M3paranoidgc -g cvsupfile.cm3-g cvsupfile.cm3 Connected to birch.elegosoft.com Updating collection cm3/cvs SetAttrs cm3/COPYRIGHT-BSD,v SetAttrs cm3/COPYRIGHT-CMASS,v SetAttrs cm3/COPYRIGHT-COLUMBIA,v SetAttrs cm3/COPYRIGHT-DEC,v SetAttrs cm3/COPYRIGHT-JDP,v SetAttrs cm3/COPYRIGHT-PURDUE,v SetAttrs cm3/COPYRIGHT-XEROX,v SetAttrs cm3/COPYRIGHTS,v SetAttrs cm3/README,v SetAttrs cm3/caltech-parser/COPYRIGHT,v SetAttrs cm3/caltech-parser/Makefile,v SetAttrs cm3/caltech-parser/PkgTags,v *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/runtime/common/RTCollector.m3", line 1770 *** Abort (core dumped) -bash-3.00$ mdb core3paranoidgc -g cvsupfile.cm3 Loading modules: [ libc.so.1 ld.so.1 ] > $c libc.so.1`_lwp_kill+8(6, 0, feea4af8, ffffffff, feee8284, 6) libc.so.1`abort+0x110(febfdc58, 1, 48c988, a8390, feeeb298, 0) RTOS__Crash+4(0, 44, 48, 0, 1113a18, 1113340) RTProcess__Crash+0x98(0, 4, a, 1, 200000, 100000) RTError__EndError+0x58(1, 0, 52f500, 0, 180c508, 8) RTError__MsgS+0xe4(52dadc, 6ea, 52f500, 52b660, 52f500, 52dadc) RTException__Crash+0x354(febfeb1c, 0, 52b510, 1, 200000, 100000) RTException__DefaultBackstop+0xf8(febfeb1c, 0, 0, fffffff8, 4, 12345678) RTException__InvokeBackstop+0x4c(febfeb1c, 0, ffffffff, fffffff8, 0, febfe571) RTException__Raise+0xec(febfeb1c, febfe6f8, 0, 0, 0, 0) RTException__DefaultBackstop+0x1f4(febfeb1c, 0, 0, fffffff8, 4, 12345678) RTException__InvokeBackstop+0x4c(febfeb1c, 0, ffffffff, fffffff8, 0, febfeaa1) RTException__Raise+0xec(febfeb1c, febfefb0, 7f59f, 0, 0, 0) RTHooks__ReportFault+0x138(52dc50, dd40, fedb0420, 0, 0, d6a710) 0x431948(dd40, 0, fedb0420, fed11c00, feeecc08, 0) RTCollector__RefSanityCheck+0x1c4(fedb0420, feb5a0a4, fedb0420, 1, 1, 1) RTHeapMap__Walk+0x6c8(feb5a0a4, 53949b, fedb0420, 4, fed11c00, fed11d00) RTHeapMap__DoWalkRef+0xac(5394ec, feb5a0a0, fedb0420, fed11c00, 533b2c, 0) RTHeapMap__DoWalkRef+0x6c(53969c, feb5a0a0, fedb0420, 4, d4a26c, fed11d00) RTHeapMap__WalkRef+0x194(feb5a09c, fedb0420, 0, 1000, 0, 0) RTCollector__SanityCheck+0x79c(fedb0004, febfefb0, 7f59f, 0, 0, 0) RTCollector__After+0x40(fedb0004, feb41668, 7f5a0, 0, 0, d6a710) RTHeapRep__InvokeMonitors+0x208(0, 38161524, e5bab, 0, 0, febff090) RTCollector__CollectSomeInStateFive+0x5f8(ff000000, 0, ff000000, ff000000, 0, fed11d00) RTCollector__CollectSome+0x158(1, 1000, feeecbc0, fed11c00, 533dbc, 0) RTCollector__CollectEnough+0xcc(d4a268, 4, feb5de80, fed11c00, 533b2c, 0) RTHeapRep__AllocTraced+0x194(52a45c, 94, 4, febff32c, d4a26c, 94) RTAllocator__GetOpenArray+0x1bc(52a45c, febff43c, ff000000, ff000000, 0, fed11d00) RTHooks__AllocateOpenArray+0x1c(52a45c, febff43c, ff000000, ff000000, 0, 0) Text8__Create+0xdc(88, 1000, feeecbc0, fed11c00, 533b2c, 0) Text8__New+0x5c(febff674, 1f, 4, febff668, d4a26c, 98) Text__FromChars+0xc8(febff674, 1f, 4, febff790, d4a26c, 30) SupMisc__GetCmdLine+0x72c(feb383a4, feb5de34, 0, 0, 0, 0) FileStatus__RdGetRaw+0x830(feb393f0, feb5df68, feb5de80, fed11c00, 533b2c, 0) StatusFile__Get+0x5b0(feb38260, feb5de34, 0, 0, 533b2c, 0) Detailer__SendCheckoutDetails+0x380(fec5c8f0, fedb2220, feb5de34, 0, 0, 0) Detailer__SendDetails+0x5c(fec5c8f0, fedb2220, feb5de34, 0, 0, 0) Detailer__DetailCollection+0x1efc(fec5c8f0, fedb2220, feb38190, fed11c00, 533b2c, 0) Detailer__Apply+0x5d8(fec5c8f0, 1000, feeecbc0, fed11c00, 533b68, 0) ThreadPThread__RunThread+0x3c4(d4a238, 0, 0, 0, 0, 1) ThreadPThread__ThreadBase+0x44(d4a238, fec00000, 0, 0, 44bae4, 1) libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) I also still get errors with directory creation when there aren't any yet: -bash-3.00$ cvsup @M3paranoidgc -g cvsupfile.cm3 Connected to birch.elegosoft.com Updating collection cm3/cvs Checkout cm3/COPYRIGHT-BSD Checkout cm3/COPYRIGHT-CMASS Checkout cm3/COPYRIGHT-COLUMBIA Checkout cm3/COPYRIGHT-DEC Checkout cm3/COPYRIGHT-JDP Checkout cm3/COPYRIGHT-PURDUE Checkout cm3/COPYRIGHT-XEROX Checkout cm3/COPYRIGHTS Checkout cm3/README Updater failed: Cannot create directories leading to "/opt/cm3/cm3-cvs/cm3/caltech-parser/#cvs.cvsup-3705.10": Resource temporarily unavailable Alex. From hosking at cs.purdue.edu Fri Sep 7 19:03:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 07 Sep 2007 17:03:29 -0000 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> Message-ID: Sounds like we are losing some references somewhere and the GC is prematurely collecting live objects. Alex, are you running on a 64- bit SPARC v9? Perhaps the SaveRegsInStack code needs updating for that platform to use the flushw instruction instead of trap 3. As it is, I am not entirely satisfied with the difficulties I've seen getting meaningful stack information on Solaris for stopped threads, but without a reliable way to diagnose the problem I don't know what to do from this end. See additional comments below: On Sep 7, 2007, at 12:04 AM, Alex Bochannek wrote: > Tony, John, > > I ran the tests some more and noticed that there is always a problem > with directory creation. The error I had mentioned before: > > Updater failed: Cannot create directories leading to "/opt/cm3/cm3- > cvs/cm3/caltech-parser/#cvs.cvsup-15483.1": Resource temporarily > unavailable > > happens pretty reliably whenever a directory (in this case > caltech-parser) needs to be created regardless of the options > below. This is running as root and cvsup not running setuid. I copied > the directory structure froman existing tree to even get the > examples to > run. (There is also an unrelated question for John below, please > read on.) > > Tony Hosking writes: > >> We are using the native threads package here, unless Alex has built >> without it. Alex, can you try running with each of the following > > Here's what I have the cvsup linked against: > > ldd /usr/local/bin/cvsup > libXaw.so.5 => /usr/lib/libXaw.so.5 > libXmu.so.4 => /usr/lib/libXmu.so.4 > libXext.so.0 => /usr/lib/libXext.so.0 > libXt.so.4 => /usr/lib/libXt.so.4 > libX11.so.4 => /usr/lib/libX11.so.4 > libsocket.so.1 => /lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libw.so.1 => /lib/libw.so.1 > libdl.so.1 => /lib/libdl.so.1 > libpthread.so.1 => /lib/libpthread.so.1 > libthread.so.1 => /lib/libthread.so.1 > librt.so.1 => /lib/librt.so.1 > libm.so.2 => /lib/libm.so.2 > libc.so.1 => /lib/libc.so.1 > libSM.so.6 => /usr/openwin/lib/libSM.so.6 > libICE.so.6 => /usr/openwin/lib/libICE.so.6 > libmp.so.2 => /lib/libmp.so.2 > libmd5.so.1 => /lib/libmd5.so.1 > libscf.so.1 => /lib/libscf.so.1 > libaio.so.1 => /lib/libaio.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1 > /platform/SUNW,Sun-Fire-480R/lib/libmd5_psr.so.1 > >> flag combinations and report the results: >> >> @M3nogc > > With the nogc options cvsup pretty much always runs all the way to > completion. It takes a while, especially on an existing tree, but it > will complete without problems. When you say "pretty much" what do you mean? Does it sometimes get an error? Is it the one you note above? > Trying the following failed: > >> @M3noincremental @M3nogenerational @M3paranoidgc >> >> @M3noincremental @M3paranoidgc >> >> @M3nogenerational @M3paranoidgc >> >> @M3paranoidgc > > -bash-3.00$ /usr/local/bin/cvsup -g cvsupfile.cm3 > Connected to birch.elegosoft.com > Updating collection cm3/cvs > SetAttrs cm3/COPYRIGHT-BSD,v > SetAttrs cm3/COPYRIGHT-CMASS,v > SetAttrs cm3/COPYRIGHT-COLUMBIA,v > SetAttrs cm3/COPYRIGHT-DEC,v > SetAttrs cm3/COPYRIGHT-JDP,v > SetAttrs cm3/COPYRIGHT-PURDUE,v > SetAttrs cm3/COPYRIGHT-XEROX,v > SetAttrs cm3/COPYRIGHTS,v > SetAttrs cm3/README,v > SetAttrs cm3/caltech-parser/COPYRIGHT,v > SetAttrs cm3/caltech-parser/Makefile,v > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3 > *** We may have collected something prematurely. > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3noincremental @M3nogenerational > @M3paranoidgc -g cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3 > *** > Ditto > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3noincremental @M3paranoidgc -g > cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x715c4 = PutCollectionList + 0x6d4 in ../src/TreeList.m3 > *** Ditto > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3nogenerational @M3paranoidgc -g > cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", line 1770 > *** This is the collector complaining that it found a reference in the heap to an object that has been reclaimed. > Abort > -bash-3.00$ /usr/local/bin/cvsup @M3paranoidgc -g cvsupfile.cm3 > Connected to birch.elegosoft.com > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x421638 = NoteStackLocations + 0xac in ../src/runtime/ > common/RTCollector.m3 > *** > Looks like a bad sp error. > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", line 688 > *** This is knock-on from the previous error. > > Abort > -bash-3.00$ > > > I hope this helps and that you can get to the bottom of this. > > I am trying to compile a new CVSup to see why I keep getting checksum > mismatches that result in very long transfer times. I didn't think > that > when CVSup runs on a busy repository, that I should get those a > lot, but > especially during tagging operations, it seems like I end up with > transferring the entire repository. > > Alex. From hosking at cs.purdue.edu Fri Sep 7 20:12:37 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 07 Sep 2007 18:12:37 -0000 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> <4FAF9428-BE55-49E0-99FB-83049EF96828@cs.purdue.edu> <52B269BE-C2F8-4300-9517-50E7546EBBC9@cs.purdue.edu> <46E04F68.6030001@polstra.com> <8DA206BE-1EDE-4713-83DD-317417081E76@cs.purdue.edu> Message-ID: <1B153BC7-A186-4F33-A019-91ADFEEC97FD@cs.purdue.edu> Hmm... What output do you get with "cm3cg --version"? On my machine I see: /p/sss/cm3/bin/cm3cg --version Modula-3 backend version 4.1.1 (sparc-sun-solaris2.8) compiled by GNU C version 4.1.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min- heapsize=131072 On Sep 7, 2007, at 1:51 PM, Alex Bochannek wrote: > Tony Hosking writes: > >> Sounds like we are losing some references somewhere and the GC is >> prematurely collecting live objects. Alex, are you running on a 64- >> bit SPARC v9? Perhaps the SaveRegsInStack code needs updating for > > Yes. > > -bash-3.00$ isainfo -kv; isainfo -v > 64-bit sparcv9 kernel modules > 64-bit sparcv9 applications > vis2 vis > 32-bit sparc applications > vis2 vis v8plus div32 mul32 > >> that platform to use the flushw instruction instead of trap 3. As it >> is, I am not entirely satisfied with the difficulties I've seen >> getting meaningful stack information on Solaris for stopped threads, >> but without a reliable way to diagnose the problem I don't know what >> to do from this end. See additional comments below: > >>> With the nogc options cvsup pretty much always runs all the way to >>> completion. It takes a while, especially on an existing tree, but it >>> will complete without problems. >> >> When you say "pretty much" what do you mean? Does it sometimes >> get an >> error? Is it the one you note above? > > I should have been more precise here. Every time I ran cvsup with > @M3nogc and I let it run to completion, it completed without > error. Since it took a while, I did interrupt it a few times during > testing. > > Alex. From jay.krell at cornell.edu Fri Sep 7 21:20:33 2007 From: jay.krell at cornell.edu (Jay) Date: Fri, 07 Sep 2007 19:20:33 -0000 Subject: [M3devel] mailing lists? Message-ID: m3devel and m3commit working? - Jay _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Sep 12 21:48:00 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 12 Sep 2007 19:48:00 -0000 Subject: [M3devel] Note on an obscure m3gdb/compiler interaction Message-ID: <46E8427A.4000607@wichita.edu> If you link in a library, all the code of the entire library is loaded into your address space, and all the debug data is available to m3gdb, even for modules in the library but not in the import/export closure of the main program. This means you can call procedures in such modules from m3gdb commands. However, there is initialization of global data that the compilers take care of only for modules in the closure. If you call something from m3gdb that is in memory but not initialized, various bad things can happen. As an example, you can always call RTTypeFP.FromFingerprint, because it is in libm3core. And this could be a useful thing to want to do during a debug session (e.g., when debugging something involving pickles). But if you do this when RTTypeFP is not in the closure, there will be a segment fault while trying allocate a heap object of a type whose type definition pointer in the global space of RTTypeFP is uninitialized. Even the needed type definition is present, but the needed pointer to it is not set up. For now, the only workaround is add an IMPORT of the needed module to the code and recompile, before trying the call from m3gdb. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jay.krell at cornell.edu Thu Sep 13 15:13:02 2007 From: jay.krell at cornell.edu (Jay) Date: Thu, 13 Sep 2007 13:13:02 -0000 Subject: [M3devel] testing...#1 (cornell) Message-ID: Seeing if these go through..it's been quite a few days not working.. I don't think the problem is on my end, but could be. (I do have a setup now that sends from one address, but "claims" another, and the claimed one works and forwards, providing flexibility...) - Jay _________________________________________________________________ Capture your memories in an online journal! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 13 15:15:20 2007 From: jay.krell at cornell.edu (Jay) Date: Thu, 13 Sep 2007 13:15:20 -0000 Subject: [M3devel] testing...#2 (hotmail) Message-ID: sorry for the spam..I waited several days and send less spammy tests... (and some submits) - Jay From: jay.krell at cornell.eduTo: m3devel at elegosoft.com; m3-support at elego.de; m3-support at elegosoft.comCC: "Tony Hosking" " ; " ronny.forberger at elegosoft.com " ; " rcoleburn at scires.com " ; " Daniel Alejandro Benavides D." "Subject: testing...#1 (cornell)Date: Thu, 13 Sep 2007 13:12:50 +0000 Seeing if these go through..it's been quite a few days not working..I don't think the problem is on my end, but could be.(I do have a setup now that sends from one address, but "claims" another, and the claimed one works and forwards, providing flexibility...) - Jay Make your little one a shining star! Shine on! _________________________________________________________________ Gear up for Halo? 3 with free downloads and an exclusive offer. It?s our way of saying thanks for using Windows Live?. http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Fri Sep 14 04:02:49 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 14 Sep 2007 02:02:49 -0000 Subject: [M3devel] A RT failure in ThreadPThread.Alert Message-ID: <46E9EBD3.1060603@wichita.edu> I got a runtime failure in ThreadPThread.Alert, on this line: ---------------------------------------------------------------------------------- PROCEDURE Alert (t: T) = BEGIN WITH r = Upthread.mutex_lock(cm) DO <*ASSERT r=0*> END; t.alerted := TRUE; --> WITH r = Upthread.cond_signal(t.waitCond^) DO <*ASSERT r=0*> END; WITH r = Upthread.mutex_unlock(cm) DO <*ASSERT r=0*> END; END Alert; ------------------------------------------------------------------------------------ Here, t.waitCond is NIL and being dereferenced. Here is a bit of debugger output: The display of t is at the bottom. ------------------------------------------------------------------------------------ *** *** runtime error: *** Attempt to reference an illegal memory location. *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 304 *** ------------------ EXCEPTION HANDLER STACK --------------------- 0xb5eb71dc TRY-EXCEPT {0xa893a19c} 0xb5eb72bc LOCK mutex = 0xb436e0e4 0xb5eb731c LOCK mutex = 0xb6ebbc44 ---------------------------------------------------------------- [Switching to Thread -1242858592 (LWP 8289)] Breakpoint 2, 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 272 ; PROCEDURE InnerRuntimeFailureDialog ( ) (m3gdb) bt #0 0x08126a38 in InnerRuntimeFailureDialog () at AssertDevel.m3:272 #1 0x08126c89 in RuntimeFailureDialog () at AssertDevel.m3:314 #2 0xb72e596f in InvokeExitors () at RTProcess.m3:40 #3 0xb72e59e3 in Crash (msg=NIL) at RTProcess.m3:61 #4 0xb72e3648 in EndError (crash=TRUE) at RTError.m3:115 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 #6 0xb72e3a46 in Crash (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE, rte=16_b73124c0) at RTException.m3:79 #7 0xb72e3770 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:39 #8 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #9 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #10 0xb72e3810 in DefaultBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:47 #11 0xb72e36d4 in InvokeBackstop (a= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END, raises=FALSE) at RTException.m3:25 #12 0xb72f3397 in Raise (act= RECORD exception = 16_b73124c0; arg = 16_0000000c; module = 16_b731e020; line = 304; pc = NIL; info0 = NIL; info1 = NIL; un_except = 16_b73124c0; un_arg = 16_00000004; END) at RTExFrame.m3:29 #13 0xb72cb223 in ReportFault (module=16_b731e020, info=9732) at RTHooks.m3:110 #14 0xb72fb697 in _m3_fault (arg=9732) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 #16 0xb7df741d in DisplayDir (v=16_b436e004) at FileBrowserVBT.m3:496 #17 0xb7df4d83 in Refresh (v=16_b436e004) at FileBrowserVBT.m3:210 #18 0xb7df5413 in Watcher (cl=16_b6ebbc9c) at FileBrowserVBT.m3:254 #19 0xb72f76f5 in RunThread (me=16_08e1c518) at ThreadPThread.m3:538 #20 0xb72f7403 in ThreadBase (param=16_08e1c518) at ThreadPThread.m3:519 #21 0xb707c540 in start_thread () from /lib/i686/libpthread.so.0 #22 0xb6fef55e in clone () from /lib/i686/libc.so.6 (m3gdb) frame 5 #5 0xb72e3389 in MsgS (file=16_b731de58, line=304, msgA=16_b7318068, msgB=16_b73126d4, msgC=16_b7318068) at RTError.m3:40 40 RTError.m3: No such file or directory. in RTError.m3 (m3gdb) p msgA $1 = (*16_b7318068*) "" (m3gdb) p msgB $2 = (*16_b73126d4*) "Attempt to reference an illegal memory location." (m3gdb) p msgC $3 = (*16_b7318068*) "" (m3gdb) frame 15 #15 0xb72f5cd7 in Alert (t=16_b3a9bdc8) at ThreadPThread.m3:304 304 ThreadPThread.m3: No such file or directory. in ThreadPThread.m3 (m3gdb) p t $4 = (*16_b3a9bdc8*) OBJECT act = 16_08e94678; closure = NIL; result = NIL; cond = 16_b3a9bdf4; waitingOn = NIL; nextWaiter = NIL; waitCond = NIL; alerted = TRUE; completed = TRUE; joined = FALSE; id = 73; END (m3gdb) -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From ronny.forberger at elegosoft.com Sat Sep 15 12:55:24 2007 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Sat, 15 Sep 2007 10:55:24 -0000 Subject: [M3devel] is this working? In-Reply-To: References: Message-ID: <46EBBA13.7050106@elegosoft.com> Hi there, I just returned from holidays so I wasn't able to investigate the mailing lists problem at any earlier time. The messages indeed could not be processed by the HTML engine anymore, because there was some problem about the mailling list software package on our server, which I still don't understand why this happend. Nevertherless it should have returned to a working state now. Regards, Ronny j k schrieb: > I'm not seeing my mail to m3devel. One accidentally had no subject, > but that doesn't seem to the cause. > > - Jay > > ------------------------------------------------------------------------ > Invite your mail contacts to join your friends list with Windows Live > Spaces. It's easy! Try it! > -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12 D-13355 Berlin Tel. +49 30 32 29 71 34 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer Olaf Wagner; Sitz Berlin; Amtsgericht Berlin-Charlottenburg HRB 77719 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 16 04:39:09 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Sep 2007 02:39:09 -0000 Subject: [M3devel] FW: cm3/win32 micro status.. Message-ID: From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; m3devel at elegosoft.com; m3-support at elego.de; m3-support at elegosoft.comSubject: cm3/win32 micro status..Date: Tue, 4 Sep 2007 09:08:18 +0000 fixed and /drastically/ churned hand.c problem reported by Daniel, though I went overboard in my way :) (send flames if you don't like and MAYBE I'll change my ways...)added MyHeapState to thread\win32\ThreadF.i3 to fix compilation of RTCollector.m3 fixed typo somewhere I think ThreadWin32.m3\MyHeapState to fix compileremove unimplemented MyAllocPool from thread\win32\ThreadF.i3 to fix compile Tony? Maybe you just forgot to commit the use of it?new release at ~jkrell\*.tar.bz2 on m3.elegosoft.com made with cm3\scripts\win\make-dist.cmd (have I mentioned this before? :) )mail not coming through here; I'll keep sending, covering my butt :)int64 support still MIA sorry I havebeen reading some of the relevant code, at this rate could be a week could be a year..Juno.exe starts up displays a bunch of stuff looks like it is "initializing"C:\cm3\bin>Juno.exe****** runtime error:*** <*ASSERT*> failed.*** file "..\src\winvbt\WinContext.m3", line 165***Stack trace: FP PC Procedure--------- --------- -------------------------------0x5aaf830 0xf41c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m30x5aaf8f8 0xf4fc1c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m30x5aafd54 0xf4db45 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m30x5aafdbc 0xf4843e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m30x5aafe04 0xf46d3d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m30x5aafe30 0x7e418734 0x5aafe98 0x7e418816 0x5aafef8 0x7e4189cd 0x5aaff08 0x7e4196c7 0x5aaff50 0xf4baf4 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3......... ......... ... more frames ...I have "cracked" my legitimate copy of CM3 4.1 cminstall and cm3 so cminstall doesn't prompt for license and cm3 doesn't care about license haven't automated, just poking in debugge Would like to hear about the legality here before telling people how, but, uh, really..if you can use the Windows ntsd/cdb debugger, it is quite easy.. You even have the source to cminstall. I'll probably automate applying the patch, or running an unpatched copy and patch it in memory or something. But again I'd like to know the legality, and if there is any need/interest in making a 4.1 binary distribution.Has anyone thought about versioning and .dlls with Modula-3?Like should exported names include typecodes?Or is it just that all the .dlls and .exes in the same directory shouldbe built and rebuilt together and that's it? - Get news, entertainment and everything you care about at Live.com. Check it out! _________________________________________________________________ Gear up for Halo? 3 with free downloads and an exclusive offer. It?s our way of saying thanks for using Windows Live?. http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 16 04:40:08 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Sep 2007 02:40:08 -0000 Subject: [M3devel] FW: hand.c In-Reply-To: <995081.11151.qm@web27115.mail.ukl.yahoo.com> References: <995081.11151.qm@web27115.mail.ukl.yahoo.com> Message-ID: I have since made some more of the changes. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: hand.cDate: Mon, 3 Sep 2007 23:15:04 +0000 I'm not seeing commit mail.Maybe my fault with the hotmail? I churned it relatively a lot. It's a small file.It compiles with older Microsoft C compilers -- optionally using __int64 instead of long long. (Visual C+ 8.0 worked as it was.) I would have factored out the LL suffixes, but, really, the vast majoriy, if not all, of the L and LL suffixes were unnecessary, right? I removed most of them.It is valid C++ now -- optional prototypes.There was a race condition in initialization, fixed.gcc -Wall complained about a safe signed/unsigned compare, fixed. Not changed: all these longs should be unsigned long, right? Or at least the bits, if not the input bit indices? Negative bit indices should be either rejected or converted to 0, and then treated as unsigned from there, right? _lowbits and _highbits should be extern const ? only on x86, right? I'm still checking if they are referenced for all targets or only x86 HighBits and LowBits should be, like..ok switched to #if LONG_MAX == 2147483647 extern const .. hard coded 32 bit values ... #elif LONG_MAX == 9223372036854775807 extern const .. hard coded 64 bit values ... #else either compute them like currently or #error #endif right? And if it is 32 bits, share the values of HighBits with _highbits, LowBits with _lowbits?They aren't /quite/ the same, but almost. _lowbits and _highbits have one extra value, the zeros at the ends I think it was. - Jay Get news, entertainment and everything you care about at Live.com. Check it out! _________________________________________________________________ Kick back and relax with hot games and cool activities at the Messenger Caf?. http://www.cafemessenger.com?ocid=TXT_TAGLM_SeptWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: