<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div><span class="Apple-style-span" style="font-size: medium;"><font class="Apple-style-span" color="#0000FF" face="'Gill Sans'">The thing is its not the heap lock that changed. Its the heap wait/broadcast that changed. Worst that could happen with those is that we get a deadlock. It should be benign w.r.to GC. The @M3paranoidgc assertion failure points to a deeper problem though. It says that something in the heap got corrupted. It is probably the same corruption as causes the failure with @M3nogc. It will be easiest to track down and fix that problem with @M3nogc. So, I suggest we focus on the current sources, using @M3nogc and figure out what is getting clobbered, and where. For example, what sets the field that you are asserting non-NIL to NIL?</font></span></div></span></span></span></span></span></span></span></span></div></span></div></span> </div><br><div><div>On 22 Sep 2009, at 23:51, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">Plus I think I narrowed the problem down to a 30 minute window, not just a day.<br>I build like 2:00 and 2:30 on the day of the heap/lock change.<br>But granted it might only be revealing some other problem, that was always there or recently introduced or long ago introduced...<br> <br> - Jay<br><br> <br><hr id="stopSpelling">From:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>To:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse?<br>Date: Wed, 23 Sep 2009 03:48:59 +0000<br><br>I'm "certain" these are ok but I can try without them.<br>One just changes the command line parameters to rc to a form that works with more toolsets. Rc probably isn't even used with Juno at all. Just put error() in the file to test it.<br> <br> <br>The other passes a struct by pointer instead of by value, through a C translation layer, because if you use the gcc backend, which nobody does, it names the functions wrong for the struct by value case. (gcc gets it right when compiling C).<br> <br> <br>You still aren't understanding me.<br> <br>We have a consistent failure before Feb 20, but it is deemed maybe ok.<br> It was maybe always that way. It is maybe unfinished code. Not heap corruption.<br> Though we don't know 100% and it does merit some investigation.<br> <br>After Feb 20 without @M3nogc we have a "more severe" and actually fairly consistent but not completely consistent failure -- heap corruption.<br> <br>After Feb 20 with @M3nogc acts the same as before Feb 20 without @M3nogc.<br> <br> <br> - Jay<br> <br>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> To:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> Date: Tue, 22 Sep 2009 22:46:30 -0400<br>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a>;<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse?<br>><span class="Apple-converted-space"> </span><br>> What about these?<br>> They appear to be Trestle and icon-related...<br>> 2009-02-18 11:14 jkrell<br>><span class="Apple-converted-space"> </span><br>> * m3-libs/m3core/src/win32/WinUser.i3,<br>> m3-libs/m3core/src/win32/WinUserC.c,<br>> m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/<span class="Apple-converted-space"> </span><br>> WinTrestle.m3:<br>><span class="Apple-converted-space"> </span><br>> workaround gcc backend bug that names<br>><span class="Apple-converted-space"> </span><br>> <*EXTERNAL WindowFromPoint:WINAPI*><br>> PROCEDURE WindowFromPoint (Point: POINT): HWND;<br>><span class="Apple-converted-space"> </span><br>> WindowFromPoint@4 instead of WindowFromPoint@8<br>><span class="Apple-converted-space"> </span><br>> by adding<br>><span class="Apple-converted-space"> </span><br>> <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*><br>> PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND;<br>><span class="Apple-converted-space"> </span><br>> HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point)<br>> {<br>> return WindowFromPoint(*Point);<br>> }<br>><span class="Apple-converted-space"> </span><br>> This lets I386_MINGW (NT386MINGNU) get further.<br>><span class="Apple-converted-space"> </span><br>> 2009-02-18 10:51 jkrell<br>><span class="Apple-converted-space"> </span><br>> * m3-sys/windowsResources/src/winRes.tmpl:<br>><span class="Apple-converted-space"> </span><br>> adapt to MinGW which has windres instead of rc with different<span class="Apple-converted-space"> </span><br>> command line usage; detect MinGW by checking if backend mode is<span class="Apple-converted-space"> </span><br>> integrated backend or not, not great..it should really be informed by<span class="Apple-converted-space"> </span><br>> a variable in the toplevel configuration -- CONFIG_HAS_RC and<span class="Apple-converted-space"> </span><br>> CONFIG_HAS_WINDRES?<br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> On 22 Sep 2009, at 22:25, Tony Hosking wrote:<br>><span class="Apple-converted-space"> </span><br>> > On 22 Sep 2009, at 21:51, Jay K wrote:<br>> ><br>> >> Tony there is something a bit gray that you are missing.<br>> ><br>> > Yes, clearly I am missing something.<br>> ><br>> >> The behavior with @M3nogc we don't necessarily consider bad/wrong/<span class="Apple-converted-space"> </span><br>> >> buggy.<br>> ><br>> > Right, it just takes GC out of the equation for what might be wrong.<br>> ><br>> >> It is a consistent assertion failure. Not an access violation.<br>> ><br>> > Good. We can debug that.<br>> ><br>> >> It could just be Trestle not being fully supported on Windows.<br>> >> Olaf says Trestle was never fully ported.<br>> ><br>> > I don't know enough about this to say either way.<br>> ><br>> >> I'm not sure anyone knows what is missing, and if Juno really<span class="Apple-converted-space"> </span><br>> >> demonstrates that or not.<br>> >><br>> >> However, versions before Feb 20 consistently act like current<span class="Apple-converted-space"> </span><br>> >> versions act with @M3nogc.<br>> >> Before Feb 20 without @M3nogc.<br>> >> Current with @M3nogc.<br>> ><br>> > What does this mean? That pre-2009-02 is just the same as<span class="Apple-converted-space"> </span><br>> > post-2009-02? How does that narrow anything down to that specific<span class="Apple-converted-space"> </span><br>> > time-frame?<br>> ><br>> >> What I'd like to see is current without @M3nogc to act just as bad<span class="Apple-converted-space"> </span><br>> >> but no worse than before Feb 20. I think the current behavior<span class="Apple-converted-space"> </span><br>> >> without @M3nogc is worse. It's just "fail vs. no fail".<br>> ><br>> > I still don't understand what this says about that particular time-<span class="Apple-converted-space"> </span><br>> > frame.<br>> ><br>> >> Now, that is apples and oranges. For example, I relatively<span class="Apple-converted-space"> </span><br>> >> recently changed the default initial allocation size and maybe<span class="Apple-converted-space"> </span><br>> >> incremental allocation sizes. In particular..I forget the exact<span class="Apple-converted-space"> </span><br>> >> details but I think changed from malloc to VirtualAlloc, and<span class="Apple-converted-space"> </span><br>> >> VirtualAlloc allocates in 64K chunks. I guess I should review<span class="Apple-converted-space"> </span><br>> >> that..but that was more recent I think, after Feb 20. I have to<span class="Apple-converted-space"> </span><br>> >> check.<br>> >> The code was a bit flawed somehow and I improved it somehow. I<span class="Apple-converted-space"> </span><br>> >> forget. Almost everything is subject to rerererereview when there<span class="Apple-converted-space"> </span><br>> >> is a bug, granted.<br>> >><br>> >><br>> >> I agree as well that Feb 20 might have just uncovered a preexisting<span class="Apple-converted-space"> </span><br>> >> problem.<br>> >><br>> >><br>> >> But much is unclear and figuring this out I don't think will be<span class="Apple-converted-space"> </span><br>> >> easy. :(<br>> ><br>> > If we have a deterministic failure then it should be easy enough to<span class="Apple-converted-space"> </span><br>> > track down.<br>> ><br>> >><br>> >><br>> >> - Jay<br>> >><br>> >><br>> >><br>> >> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >> Date: Tue, 22 Sep 2009 21:40:27 -0400<br>> >> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back<span class="Apple-converted-space"> </span><br>> >> again -- cm3 status worse?<br>> >><br>> >><br>> >> On 22 Sep 2009, at 08:16, Jay K wrote:<br>> >><br>> >> Yes there is fairly definitely a problem on Windows and it dates, I<span class="Apple-converted-space"> </span><br>> >> think, to this change:<br>> >><br>> >><br>> >> 2009-02-16 02:20 hosking<br>> >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/<span class="Apple-converted-space"> </span><br>> >> 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/<span class="Apple-converted-space"> </span><br>> >> ThreadPThreadC.i3,<br>> >> thread/WIN32/ThreadWin32.m3:<br>> >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better<span class="Apple-converted-space"> </span><br>> >> match underlying pthread semantics.<br>> >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap<span class="Apple-converted-space"> </span><br>> >> is held.<br>> >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or<span class="Apple-converted-space"> </span><br>> >> not.<br>> >><br>> >> I'm not convinced that this change itself broke things, but perhaps<span class="Apple-converted-space"> </span><br>> >> instead exposed the brokenness. In any case, debugging this in the<span class="Apple-converted-space"> </span><br>> >> head will probably be easiest. If we have an example that<span class="Apple-converted-space"> </span><br>> >> deterministically breaks then I think we have a place to start. My<span class="Apple-converted-space"> </span><br>> >> suggestion for now, since it appears to trigger the problem, is to<span class="Apple-converted-space"> </span><br>> >> use @M3nogc.<br>> >><br>> >><br>> ><br>><span class="Apple-converted-space"> </span><br></div></span></blockquote></div><br></body></html>