<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I'm first debugging Juno with @M3nogc.<BR>
<BR> <BR>
The assertion failure is due to:<BR>
<BR>PushPixmap<BR> => result := CreatePatternBrush(pst.pmtable[pm].hbmp)<BR>    assert(result is success)<BR>
 hbmp is NULL.<BR>
 <BR>
 It is always the case that pm is 6 and this is the second created <BR>
pixmap with index = 6,<BR><BR>
 So you can change the creating code to print out the debugger command to set a write breakpoint.<BR>
 <BR>
<BR>It is NULLed here:<BR>
 <BR>
<BR>ChildEBP RetAddr<BR>01c9f7d4 00fcdc94 m3ui!WinScrnPixmap__Free+0x2be [..\src\winvbt\WinScrnPixmap.m3 @ 178]<BR>01c9f824 00fcde3a m3ui!DblBufferVBT__PaintVBTtoVBT+0x204 [..\src\split\DblBufferVBT.m3 @ 431]<BR>01c9f8ac 00fcc890 m3ui!DblBufferVBT__Update+0x180 [..\src\split\DblBufferVBT.m3@ 451]<BR>01c9f8c8 00fb1823 m3ui!DblBufferVBT__Sync+0x1b [..\src\split\DblBufferVBT.m3 @ 218]<BR>01c9f900 00faab14 m3ui!VBTClass__SyncDefault+0x12d [..\src\vbt\VBTClass.m3 @ 797]<BR>01c9f938 0041464d m3ui!VBT__Sync+0x120 [..\src\vbt\VBT.m3 @ 1167]<BR>01c9f954 00415f30 Juno!Drawing__Sync+0x8a [..\src\Drawing.m3 @ 660]<BR>01c9f978 0043e37d Juno!Drawing__Make+0x104 [..\src\Drawing.m3 @ 855]<BR>01c9f9a4 004445db Juno!Source__Make+0xca [..\src\Source.m3 @ 278]<BR>01c9f9e4 00448760 Juno!Juno__MakeCurrCmd+0x269 [..\src\Juno.m3 @ 89]<BR>01c9fac0 00449e47 Juno!Juno__GetFile+0x904 [..\src\Juno.m3 @ 633]<BR>01c9fb88 00fae88c Juno!Juno__Misc+0x5e2 [..\src\Juno.m3 @ 790]<BR>01c9fbc0 00ffd038 m3ui!VBTClass__Misc+0xa5 [..\src\vbt\VBTClass.m3 @ 270]<BR>01c9fc3c 00ff51a8 m3ui!ETAgent__MiscCode+0x2a9 [..\src\split\ETAgent.m3 @ 253]<BR>01c9fc74 010005fa m3ui!JoinParent__Misc+0x4fd [..\src\split\JoinParent.m3 @ 458]<BR>01c9fd40 00fae88c m3ui!DpyFilter__Misc+0x7da [..\src\trestle\DpyFilter.m3 @ 139]<BR>01c9fd78 00f88c7c m3ui!VBTClass__Misc+0xa5 [..\src\vbt\VBTClass.m3 @ 270]<BR>01c9fdbc 00f87ac5 m3ui!WinTrestle__ForgeVBTEvent+0x132 [..\src\winvbt\WinTrestle.m3 @ 1444]<BR>01c9fdf8 7e418734 m3ui!WinTrestle__WindowProc+0x45f [..\src\winvbt\WinTrestle.m3 @ 1143]<BR>01c9fe24 7e418816 user32!InternalCallWinProc+0x28<BR>01c9fe8c 7e4189cd user32!UserCallWinProcCheckWow+0x150<BR>01c9feec 7e4196c7 user32!DispatchMessageWorker+0x306<BR>01c9fefc 00f8d1a0 user32!DispatchMessageA+0xf<BR>01c9ff48 005eae2f m3ui!WinTrestle__MessengerApply+0x256 [..\src\winvbt\WinTrestle.m3 @ 2450]<BR>01c9ff88 005eab77 m3core!ThreadWin32__RunThread+0x22e [..\src\thread\WIN32\ThreadWin32.m3 @ 543]<BR>
 <BR>
 <BR>
At the very least, that isn't "random heap corruption".<BR>The X code looks similar.<BR>
 <BR>
<BR>If I alter the code in PushPixmap just slightly:<BR>
<BR> <BR>
before:<BR>
    IF op >= 0 AND st.optable # NIL AND op < NUMBER(st.optable^) AND<BR> pst.pmtable # NIL AND pm < NUMBER (pst.pmtable^) THEN<BR>
<BR> <BR>
after, added NIL check at the end:<BR>
    IF op >= 0 AND st.optable # NIL AND op < NUMBER(st.optable^) AND<BR> pst.pmtable # NIL AND pm < NUMBER (pst.pmtable^) AND pst.pmtable[pm].hbmp # NIL THEN<BR>
 <BR>
That Juno limps along much better.<BR>No crash.<BR>A fair amount of incorrect drawing occurs but a fair amount of correct drawing does too.<BR>
Any ideas?<BR>Does the code the callstack includes look reasonable??<BR>  Reasonably similar to X??<BR>I'm being lazy and just partially debugging it.<BR>
 <BR>
 <BR>
I think this backs up that the historical assertion failure isn't terribly worrisome, but the<BR>current behavior without @M3nogc is more troubling and different.<BR>
 <BR>
It might just a race in TrestleOnWindows?<BR>
The callstack with the assertion:<BR>
 <BR>
ChildEBP RetAddr<BR>01c9f820 00f910c7 m3ui!WinContext__PushPixmap+0x4cb [..\src\winvbt\WinContext.m3 @ 167]<BR>01c9f8e8 00f8edaf m3ui!WinPaint__PixmapCom+0x9ed [..\src\winvbt\WinPaint.m3 @ 712]<BR>01c9fd44 00f891f3 m3ui!WinPaint__PaintBatch+0x25f [..\src\winvbt\WinPaint.m3 @ 51]<BR>01c9fdb0 00f87919 m3ui!WinTrestle__PaintBatchVBT+0x13f [..\src\winvbt\WinTrestle.m3 @ 1574]<BR>01c9fdf8 7e418734 m3ui!WinTrestle__WindowProc+0x763 [..\src\winvbt\WinTrestle.m3 @ 1163]<BR>01c9fe24 7e418816 user32!InternalCallWinProc+0x28<BR>01c9fe8c 7e4189cd user32!UserCallWinProcCheckWow+0x150<BR>01c9feec 7e4196c7 user32!DispatchMessageWorker+0x306<BR>01c9fefc 00f8ccf0 user32!DispatchMessageA+0xf<BR>01c9ff48 005eae2f m3ui!WinTrestle__MessengerApply+0x256 [..\src\winvbt\WinTrestle.m3 @ 2450]<BR>01c9ff88 005eab77 m3core!ThreadWin32__RunThread+0x22e [..\src\thread\WIN32\ThreadWin32.m3 @ 543]<BR>01c9ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\ThreadWin32.m3 @ 511]<BR>01c9ffec 00000000 kernel32!BaseThreadStart+0x37<BR>
0:003><BR>
 <BR>
 <BR>
does take a lock in PaintBatch, similar to TrestleOnX.<BR>
 <BR>
 <BR>
I didn't look, but maybe the freeing path needs similar??<BR>
<BR> - Jay<BR><BR>                                         </body>
</html>