<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Restoring the:<BR>
ThreadF.ProcessPools(ClosePool);<BR><BR>
fixes it. I think that was it. One of the ProcessPools uses. I have to retest it anyway -- applying the change to head instead of 2009-02-16 02:00Z.<BR>
<BR>
- Jay<BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com; hosking@cs.purdue.edu<BR>Subject: RE: [M3devel] Juno on NT (presumably canary for other problems)<BR>Date: Fri, 4 Sep 2009 11:52:28 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z".<BR>So please review this change.<BR>I have reviewed it and tried to partly undo it, without luck yet.<BR>There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock<BR>and now I think happens right away. I tried restoring that, but again, no luck for me.<BR> <BR>Thanks,<BR> - Jay<BR> <BR>
<HR id=EC_stopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com; hosking@cs.purdue.edu<BR>Subject: RE: [M3devel] Juno on NT (presumably canary for other problems)<BR>Date: Fri, 4 Sep 2009 09:12:23 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
I have narrowed it down further to between 2/15/2009 and 2/18/2009.<BR>Next I will try old text code in head to see if it is that.<BR> <BR>Tony, can you double check this stuff:<BR> <BR>2009-02-16 02:20 hosking<BR><BR> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c,<BR> Csupport/little-endian/dtoa.c, convert/CConvert.i3,<BR> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3,<BR> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3,<BR> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3,<BR> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3,<BR> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3,<BR> thread/WIN32/ThreadWin32.m3:<BR><BR> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics.<BR> This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held.<BR> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not.<BR><BR><BR>Remember this is on NT so a lot of stuff isn't relevant, e.g. all the signal stuff (not sure how we pause world there, I'll check, I don't think it is actually possible..).<BR> <BR> <BR> - Jay<BR><BR> <BR>
<HR id=EC_EC_stopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Date: Fri, 4 Sep 2009 08:54:54 +0000<BR>Subject: [M3devel] Juno on NT (presumably canary for other problems)<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
short story:<BR><BR> <BR>I narrowed it down to between 2/15/2009 and 2/20/2009.<BR>I will keep digging.<BR> <BR>There are actually a lot of changes in that brief period.<BR>I will narrow it further.<BR> <BR> <BR>long story:<BR> <BR>Juno on NT, as canary for other problems.<BR>Juno on NT has three behaviors.<BR> <BR> <BR>Behavior #1<BR> <BR> <BR>The most common historical behavior, an assertion failure:<BR>C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe<BR><BR>***<BR>*** runtime error:<BR>*** <*ASSERT*> failed.<BR>*** file "..\src\winvbt\WinContext.m3", line 165<BR>***<BR>Stack trace:<BR> FP PC Procedure<BR>--------- --------- -------------------------------<BR>0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3<BR>0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3<BR>0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3<BR>0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3<BR>0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3<BR>0x1b3fe30 0x7e418734 <???><BR>0x1b3fe98 0x7e418816 <???><BR>0x1b3fef8 0x7e4189cd <???><BR>0x1b3ff08 0x7e4196c7 <???><BR>0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3<BR>......... ......... ... more frames ...<BR>(1860.1d80): Break instruction exception - code 80000003 (first chance)<BR>eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b<BR>eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc<BR>cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202<BR>ntdll!DbgBreakPoint:<BR>7c90120e cc int 3<BR>0:003> .lines<BR>Line number information will be loaded<BR>0:003> k999<BR>ChildEBP RetAddr<BR>01b3f5bc 005d52b7 ntdll!DbgBreakPoint<BR>01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29]<BR>01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess.<BR>m3 @ 66]<BR>01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m<BR>3 @ 118]<BR>01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @<BR>40]<BR>01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep<BR>tion.m3 @ 79]<BR>01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo<BR>n\RTException.m3 @ 39]<BR>01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common<BR>\RTException.m3 @ 25]<BR>01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr<BR>ame.m3 @ 29]<BR>01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo<BR>n\RTException.m3 @ 47]<BR>01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common<BR>\RTException.m3 @ 25]<BR>01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr<BR>ame.m3 @ 29]<BR>01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook<BR>s.m3 @ 110]<BR>01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1<BR>7]<BR>01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3<BR> @ 167]<BR>01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71<BR>2]<BR>01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5<BR>1]<BR>01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle<BR>.m3 @ 1574]<BR>01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3<BR> @ 1163]<BR>01b3fe30 7e418816 USER32!InternalCallWinProc+0x28<BR>01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150<BR>01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306<BR>01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf<BR>01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl<BR>e.m3 @ 2450]<BR>01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa<BR>dWin32.m3 @ 579]<BR>01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa<BR>dWin32.m3 @ 548]<BR>01b3ffec 00000000 kernel32!BaseThreadStart+0x37<BR>0:003><BR> <BR> <BR>This we shall blame on Trestle not fully being ported to Win32, I guess.<BR>At the very least, it seems to the behavior going back a while.<BR>You can occasionally see this in head, but usually you see #3.<BR> <BR><BR>Behavior #2<BR><BR>Sometimes, rarely, Juno hangs in startup on NT.<BR>I believe I have seen this both with fairly old and current versions.<BR>This occurs very rarely. I might look into it more after #3 is solved.<BR> <BR> <BR>Behavior #3<BR><BR> <BR>An access violation (SIGSEGV to Unix folks) during startup.<BR>This is the most common behavior with current source, going back a few months.<BR>It is almost always accessing address 00200000 and the instruction pointer is very<BR>often in Thread__Join, but neither are always true.<BR>Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL.<BR> <BR><BR>C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe<BR>(1ac4.1e9c): Access violation - code c0000005 (first chance)<BR>First chance exceptions are reported before any exception handling.<BR>This exception may be expected and handled.<BR>eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974<BR>eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc<BR>cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206<BR>m3core!Thread__Join+0x13f:<BR>005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=????????<BR>0:000> r ebx<BR>ebx=00200000<BR>0:000> .lines<BR>Line number information will be loaded<BR>0:000> k<BR>ChildEBP RetAddr<BR>0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3<BR>@ 710]<BR>0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile.<BR>m3 @ 256]<BR>0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730]<BR>0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813]<BR>0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793]<BR>0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140]<BR>0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174]<BR>0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263]<BR>0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134]<BR>0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi<BR>nker.m3 @ 399]<BR>0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker<BR>.m3 @ 113]<BR>0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker.<BR>m3 @ 122]<BR>0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4]<BR>0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c<BR>rt\src\crtexe.c @ 582]<BR>0012fff0 00000000 kernel32!BaseProcessStart+0x23<BR>0:000><BR> <BR>#4 sometimes other, for example:<BR>***<BR>*** runtime error:<BR>*** <*ASSERT*> failed.<BR>*** file "..\src\runtime\common\RTCollector.m3", line 411<BR>***<BR>Stack trace:<BR> FP PC Procedure<BR>--------- --------- -------------------------------<BR> 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3<BR> 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3<BR> 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3<BR> 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3<BR> 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m<BR>3<BR> 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3<BR> 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT<BR>Collector.m3<BR> 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3<BR> 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector.<BR>m3<BR> 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3<BR>......... ......... ... more frames ...<BR>(14b0.121c): Break instruction exception - code 80000003 (first chance)<BR><BR>for example:<BR>***<BR>*** runtime error:<BR>*** An array subscript was out of range.<BR>*** file "..\src\vbt\VBTRep.m3", line 644<BR>***<BR>Stack trace:<BR> FP PC Procedure<BR>--------- --------- -------------------------------<BR>0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3<BR>0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3<BR>0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3<BR>0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3<BR>0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3<BR>......... ......... ... more frames ...<BR>(1c3c.e3c): Break instruction exception - code 80000003 (first chance)<BR> <BR>I figure these are just a variation of #3.<BR><BR>Now, I finally learned how to give CVS a date to checkout or update.<BR>And NT builds very fast due to the integrated backend.<BR>So I have been building various dates.<BR><BR>The change between #3 and #1 happened around mid February 2009.<BR>Specifically, ignoring the rare #2, 2009/02/15 always fails an assert,<BR>#4 above is from 2009/02/20.<BR>And 2009/02/20 also access violates on 00200000 often.<BR> <BR><BR> - Jay<BR><BR></body>
</html>