[M3devel] Juno on Windows, some inconclusive investigation..

[Jay K]

I'm first debugging Juno with @M3nogc.


 

The assertion failure is due to:


PushPixmap
 => result := CreatePatternBrush(pst.pmtable[pm].hbmp)
    assert(result is success)

 hbmp is NULL.

 

 It is always the case that pm is 6 and this is the second created 

pixmap with index = 6,


 So you can change the creating code to print out the debugger command to set a write breakpoint.

 


It is NULLed here:

 


ChildEBP RetAddr
01c9f7d4 00fcdc94 m3ui!WinScrnPixmap__Free+0x2be [..\src\winvbt\WinScrnPixmap.m3 @ 178]
01c9f824 00fcde3a m3ui!DblBufferVBT__PaintVBTtoVBT+0x204 [..\src\split\DblBufferVBT.m3 @ 431]
01c9f8ac 00fcc890 m3ui!DblBufferVBT__Update+0x180 [..\src\split\DblBufferVBT.m3@ 451]
01c9f8c8 00fb1823 m3ui!DblBufferVBT__Sync+0x1b [..\src\split\DblBufferVBT.m3 @ 218]
01c9f900 00faab14 m3ui!VBTClass__SyncDefault+0x12d [..\src\vbt\VBTClass.m3 @ 797]
01c9f938 0041464d m3ui!VBT__Sync+0x120 [..\src\vbt\VBT.m3 @ 1167]
01c9f954 00415f30 Juno!Drawing__Sync+0x8a [..\src\Drawing.m3 @ 660]
01c9f978 0043e37d Juno!Drawing__Make+0x104 [..\src\Drawing.m3 @ 855]
01c9f9a4 004445db Juno!Source__Make+0xca [..\src\Source.m3 @ 278]
01c9f9e4 00448760 Juno!Juno__MakeCurrCmd+0x269 [..\src\Juno.m3 @ 89]
01c9fac0 00449e47 Juno!Juno__GetFile+0x904 [..\src\Juno.m3 @ 633]
01c9fb88 00fae88c Juno!Juno__Misc+0x5e2 [..\src\Juno.m3 @ 790]
01c9fbc0 00ffd038 m3ui!VBTClass__Misc+0xa5 [..\src\vbt\VBTClass.m3 @ 270]
01c9fc3c 00ff51a8 m3ui!ETAgent__MiscCode+0x2a9 [..\src\split\ETAgent.m3 @ 253]
01c9fc74 010005fa m3ui!JoinParent__Misc+0x4fd [..\src\split\JoinParent.m3 @ 458]
01c9fd40 00fae88c m3ui!DpyFilter__Misc+0x7da [..\src\trestle\DpyFilter.m3 @ 139]
01c9fd78 00f88c7c m3ui!VBTClass__Misc+0xa5 [..\src\vbt\VBTClass.m3 @ 270]
01c9fdbc 00f87ac5 m3ui!WinTrestle__ForgeVBTEvent+0x132 [..\src\winvbt\WinTrestle.m3 @ 1444]
01c9fdf8 7e418734 m3ui!WinTrestle__WindowProc+0x45f [..\src\winvbt\WinTrestle.m3 @ 1143]
01c9fe24 7e418816 user32!InternalCallWinProc+0x28
01c9fe8c 7e4189cd user32!UserCallWinProcCheckWow+0x150
01c9feec 7e4196c7 user32!DispatchMessageWorker+0x306
01c9fefc 00f8d1a0 user32!DispatchMessageA+0xf
01c9ff48 005eae2f m3ui!WinTrestle__MessengerApply+0x256 [..\src\winvbt\WinTrestle.m3 @ 2450]
01c9ff88 005eab77 m3core!ThreadWin32__RunThread+0x22e [..\src\thread\WIN32\ThreadWin32.m3 @ 543]

 

 

At the very least, that isn't "random heap corruption".
The X code looks similar.

 


If I alter the code in PushPixmap just slightly:


 

before:

    IF op >= 0 AND st.optable # NIL AND op < NUMBER(st.optable^) AND
 pst.pmtable # NIL AND pm < NUMBER (pst.pmtable^) THEN


 

after, added NIL check at the end:

    IF op >= 0 AND st.optable # NIL AND op < NUMBER(st.optable^) AND
 pst.pmtable # NIL AND pm < NUMBER (pst.pmtable^) AND pst.pmtable[pm].hbmp # NIL THEN

 

That Juno limps along much better.
No crash.
A fair amount of incorrect drawing occurs but a fair amount of correct drawing does too.

Any ideas?
Does the code the callstack includes look reasonable??
  Reasonably similar to X??
I'm being lazy and just partially debugging it.

 

 

I think this backs up that the historical assertion failure isn't terribly worrisome, but the
current behavior without @M3nogc is more troubling and different.

 

It might just a race in TrestleOnWindows?

The callstack with the assertion:

 

ChildEBP RetAddr
01c9f820 00f910c7 m3ui!WinContext__PushPixmap+0x4cb [..\src\winvbt\WinContext.m3 @ 167]
01c9f8e8 00f8edaf m3ui!WinPaint__PixmapCom+0x9ed [..\src\winvbt\WinPaint.m3 @ 712]
01c9fd44 00f891f3 m3ui!WinPaint__PaintBatch+0x25f [..\src\winvbt\WinPaint.m3 @ 51]
01c9fdb0 00f87919 m3ui!WinTrestle__PaintBatchVBT+0x13f [..\src\winvbt\WinTrestle.m3 @ 1574]
01c9fdf8 7e418734 m3ui!WinTrestle__WindowProc+0x763 [..\src\winvbt\WinTrestle.m3 @ 1163]
01c9fe24 7e418816 user32!InternalCallWinProc+0x28
01c9fe8c 7e4189cd user32!UserCallWinProcCheckWow+0x150
01c9feec 7e4196c7 user32!DispatchMessageWorker+0x306
01c9fefc 00f8ccf0 user32!DispatchMessageA+0xf
01c9ff48 005eae2f m3ui!WinTrestle__MessengerApply+0x256 [..\src\winvbt\WinTrestle.m3 @ 2450]
01c9ff88 005eab77 m3core!ThreadWin32__RunThread+0x22e [..\src\thread\WIN32\ThreadWin32.m3 @ 543]
01c9ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\ThreadWin32.m3 @ 511]
01c9ffec 00000000 kernel32!BaseThreadStart+0x37

0:003>

 

 

does take a lock in PaintBatch, similar to TrestleOnX.

 

 

I didn't look, but maybe the freeing path needs similar??


 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090928/b0db7755/attachment-0001.html>