From wagner at elegosoft.com Tue Sep 1 01:23:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 01:23:26 +0200 Subject: [M3devel] Pickling problem from 64 to 32 bit platforms In-Reply-To: <4A9C429B.9070308@cox.net> References: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> <4A9C429B.9070308@cox.net> Message-ID: <20090901012326.ey14b7i9bc484008@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Some initial observations: > > I don't understand the circumstances where this is happening. > "pickles from 64 to 32 bit" sounds to me like the pickle was written > on a 64-bit machine and read on a 32-bit machine. But the backtrace > seems to be of a run on a 64-bit machine, in part because of the > filename in the outermost frame: > > #38 0x0000000000408409 in _start () at ../sysdeps/x86_64/elf/start.S:113 > ^^^^^^ > > and in part, because all the hexadecimal addresses are 64-bit values. > > This example seems to be using version 1 of pickles: #5 > 0x000000000045ac12 in ReadRef (reader=16_00000000025b2018) at > ../src/pickle/ver1/Pickle.m3:529 > > ^^^^ > > Without some vetting, I can't say for sure, but I'm not sure this > version ever did all the > cross-target stuff completely. Did this case work earlier under the > same circumstances? > > The len parameter to String8.Hash has surely gone bad. Could there > something wrong > with operations on CARDINAL on 64-bit machines? What is the symptom > of the failure? What needs to be run to reproduce it? The tickets says: "Testing the network objects from 64 bit client to 32 bit target using Linux Debian Lenny. The perf test fails on any of the oc oq r rc object call tests." So I assume the test to be run is cm3/m3-comm/netobj/tests/perf; the client is a 64 bit machine, the server is a 32 bit machine, and we see a backtrace from the client. peter.mckinna at gmail.com who wrote the ticket may be able to provide more details. I cannot easily test this myself as I don't have the required machines close together anywhere. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Sep 1 11:45:33 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 11:45:33 +0200 Subject: [M3devel] last RC3 tasks Message-ID: <20090901114533.f2wgu748hwkg4gok@mail.elegosoft.com> Jay, I have moved the current version on the release branch from RC3 to pre-RC4. If you build any more packages for RC3, you have to explicitly set the version via the DS variable (originally datestamp for snapshots). I'd like to close the RC3 tasks in trac and retarget everything to the final release or RC4. However, there are some open issues: o I think we should offer packages for I386_DARWIN. Could you provide them? o There are some packages named pre-RC3 in the download area from you. These should probably be removed? o What's the status of the MSI installer for Windows? Automation can wait until RC4, but can we have a package on birch? o AMD64_FREEBSD looks rather incomplete and old. Have you run any tests on it? Should it be removed? When the packages are OK, I'd like to post a public announcement on comp.lang.modula3 and www.modula3.org. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Sep 1 13:02:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 13:02:03 +0200 Subject: [M3devel] last RC3 tasks In-Reply-To: <20090901114533.f2wgu748hwkg4gok@mail.elegosoft.com> References: <20090901114533.f2wgu748hwkg4gok@mail.elegosoft.com> Message-ID: <20090901130203.fhpolgatc4ks488g@mail.elegosoft.com> Quoting Olaf Wagner : > Jay, > > I have moved the current version on the release branch from RC3 to pre-RC4. > If you build any more packages for RC3, you have to explicitly set the > version via the DS variable (originally datestamp for snapshots). I made a mistake in the script: DS cannot be overwritten from the environment. Will fix tonight if nobody is faster. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Sep 1 14:56:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 14:56:28 +0200 Subject: [M3devel] p007 not terminating on NT386 Message-ID: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> It looks as if m3test p007 does not terminate any more on NT386. This used to work. I just found this --- p007 --- a whole bunch of threads - does the memory grow ? cd ..\src\p0\p007 && cm3 -silent -DM3TESTS >NT386\stdout.build.raw 2>NT386\stderr.build.raw running for more than 5 hours. The last successful run was http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Sep 1 15:51:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 09:51:23 -0400 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> Message-ID: <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> These thread problems are relatively new (similar to Jay's problems with AutoFlushWr...). Something quite bad must have happened recently to cause them. I took a quick look at ThreadPThread.m3 but didn't notice anything obviously wrong. Something else perhaps? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 1 Sep 2009, at 08:56, Olaf Wagner wrote: > It looks as if m3test p007 does not terminate any more on NT386. > This used to work. I just found this > > --- p007 --- a whole bunch of threads - does the memory grow ? > > cd ..\src\p0\p007 && cm3 -silent -DM3TESTS >NT386\stdout.build.raw > 2>NT386\stderr.build.raw > > running for more than 5 hours. > > The last successful run was > http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/ > . > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 1 16:13:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Sep 2009 14:13:06 +0000 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> Message-ID: AutoFlushWr: on non-I386_OPENBSD, it passed in the test runs, but generally hit assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe others. on I386_OPENBSD: it hangs The code was a bit hard for me to verify the correctness of. I replaced it with an easy to understand version and the non-I386_OPENBSD problems went away. The I386_OPENBSD hang remains. In particular, AutoFlushWr layers a Wr over a Wr, but if the underlying Wr is buffered, it strives to not add an additional buffering layer. If the underlying Wr is not buffered, it does add buffering. All Wrs have a few public fields to implement buffering. AutoFlushWr copies these fields back and forth. I think it was a) optimizing which fields to copy based on knowing which fields the toplevel Wr modified when b) I think it was doing some computation them that it should not have, instead of just copying them. I just have it basically copy all the fields all the time. There are just a few. Agreed, the I386_OPENBSD hang might be related. I think I might have to try out very old versions, like I'm doing (slowly!) for the formsedit crash. Maybe not, since the I386_OPENBSD hang is easy to reproduce and only involves two threads -- not too complicated. I think p007 also hangs on Cygwin, but it always has. I tried debugging it but Cygwin seemed like a mess. Granted, it hung with Cygwin whether or not I used pthreads or NT threads. Recentness isn't particularly clear I think, since I don't think these platforms have ever had good test coverage. But I did think regular NT386 was ok here. Later, - Jay ________________________________ > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 1 Sep 2009 09:51:23 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] p007 not terminating on NT386 > > These thread problems are relatively new (similar to Jay's problems with AutoFlushWr...). Something quite bad must have happened recently to cause them. I took a quick look at ThreadPThread.m3 but didn't notice anything obviously wrong. Something else perhaps? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 1 Sep 2009, at 08:56, Olaf Wagner wrote: > > It looks as if m3test p007 does not terminate any more on NT386. > This used to work. I just found this > > --- p007 --- a whole bunch of threads - does the memory grow ? > > cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw 2>NT386\stderr.build.raw > > running for more than 5 hours. > > The last successful run was > http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From hosking at cs.purdue.edu Tue Sep 1 16:54:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 10:54:26 -0400 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> Message-ID: <3B500B6D-168E-4BA7-819D-43E6C9D6BB03@cs.purdue.edu> On 1 Sep 2009, at 10:13, Jay K wrote: > > AutoFlushWr: > on non-I386_OPENBSD, it passed in the test runs, but generally hit > assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe > others. > on I386_OPENBSD: it hangs > > > The code was a bit hard for me to verify the correctness of. I > replaced it with an easy to understand version and the non- > I386_OPENBSD problems went away. The I386_OPENBSD hang remains. > > > In particular, AutoFlushWr layers a Wr over a Wr, but if the > underlying Wr is buffered, it strives to not add an additional > buffering layer. If the underlying Wr is not buffered, it does add > buffering. All Wrs have a few public fields to implement buffering. > AutoFlushWr copies these fields back and forth. I think it was a) > optimizing which fields to copy based on knowing which fields the > toplevel Wr modified when b) I think it was doing some computation > them that it should not have, instead of just copying them. I just > have it basically copy all the fields all the time. There are just a > few. OK, sounds like we all need to take a closer look at this code and satisfy ourselves that it is now correct. > Agreed, the I386_OPENBSD hang might be related. > I think I might have to try out very old versions, like I'm doing > (slowly!) for the formsedit crash. > Maybe not, since the I386_OPENBSD hang is easy to reproduce and only > involves two threads -- not too complicated. This is particularly weird, since it is clear that the main thread is trying to stop the other thread, but the other thread is not responding. I wonder if signal delivery to waiting threads is broken on OpenBSD? > I think p007 also hangs on Cygwin, but it always has. I tried > debugging it but Cygwin seemed like a mess. Granted, it hung with > Cygwin whether or not I used pthreads or NT threads. I have a feeling p007 is just buggy in itself -- it looks like there is a serious race in there. So, in this case I think the test is broken, not the platform. I'll try to clean it up. > Recentness isn't particularly clear I think, since I don't think > these platforms have ever had good test coverage. But I did think > regular NT386 was ok here. > > > Later, > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 1 Sep 2009 09:51:23 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] p007 not terminating on NT386 >> >> These thread problems are relatively new (similar to Jay's problems >> with AutoFlushWr...). Something quite bad must have happened >> recently to cause them. I took a quick look at ThreadPThread.m3 but >> didn't notice anything obviously wrong. Something else perhaps? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 1 Sep 2009, at 08:56, Olaf Wagner wrote: >> >> It looks as if m3test p007 does not terminate any more on NT386. >> This used to work. I just found this >> >> --- p007 --- a whole bunch of threads - does the memory grow ? >> >> cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw >> 2>NT386\stderr.build.raw >> >> running for more than 5 hours. >> >> The last successful run was >> http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/ >> . >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> From jay.krell at cornell.edu Tue Sep 1 19:47:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Sep 2009 17:47:13 +0000 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: <3B500B6D-168E-4BA7-819D-43E6C9D6BB03@cs.purdue.edu> References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> <3B500B6D-168E-4BA7-819D-43E6C9D6BB03@cs.purdue.edu> Message-ID: > take a closer look Sure. I'm suspicious of the entire approach actually. I understand that layering/pipelining Rd/Wr can be very nice, but I think there are better approaches here. 1) Don't layer a Wr over a Wr. Just have a worker thread and a table of weakrefs to Wr. Understandable downside to this approach is without an interception point, it doesn't know if a Wr has any data worth flushing, it would needlessly flush idle Wrs. or 2) Mark the upper Wr as not buffered -- not clear to me if adding buffering to unbuffered Wr is a goal. I'm not sure unbuffered Wr even makes sense, I have to reread it.. Underlying point is that, let's say I have a "counting Wr"..you know a Wr of very little but non-zero semantic. It seems too difficult imho to layer in a Wr that does very little. But again, I should reeread. Thank you for fixing the test case. I'll have to try Cygwin again here. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 1 Sep 2009 10:54:26 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] p007 not terminating on NT386 > > On 1 Sep 2009, at 10:13, Jay K wrote: > >> >> AutoFlushWr: >> on non-I386_OPENBSD, it passed in the test runs, but generally hit >> assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe >> others. >> on I386_OPENBSD: it hangs >> >> >> The code was a bit hard for me to verify the correctness of. I >> replaced it with an easy to understand version and the non- >> I386_OPENBSD problems went away. The I386_OPENBSD hang remains. >> >> >> In particular, AutoFlushWr layers a Wr over a Wr, but if the >> underlying Wr is buffered, it strives to not add an additional >> buffering layer. If the underlying Wr is not buffered, it does add >> buffering. All Wrs have a few public fields to implement buffering. >> AutoFlushWr copies these fields back and forth. I think it was a) >> optimizing which fields to copy based on knowing which fields the >> toplevel Wr modified when b) I think it was doing some computation >> them that it should not have, instead of just copying them. I just >> have it basically copy all the fields all the time. There are just a >> few. > > OK, sounds like we all need to take a closer look at this code and > satisfy ourselves that it is now correct. > >> Agreed, the I386_OPENBSD hang might be related. >> I think I might have to try out very old versions, like I'm doing >> (slowly!) for the formsedit crash. >> Maybe not, since the I386_OPENBSD hang is easy to reproduce and only >> involves two threads -- not too complicated. > > This is particularly weird, since it is clear that the main thread is > trying to stop the other thread, but the other thread is not > responding. I wonder if signal delivery to waiting threads is broken > on OpenBSD? > >> I think p007 also hangs on Cygwin, but it always has. I tried >> debugging it but Cygwin seemed like a mess. Granted, it hung with >> Cygwin whether or not I used pthreads or NT threads. > > I have a feeling p007 is just buggy in itself -- it looks like there > is a serious race in there. So, in this case I think the test is > broken, not the platform. I'll try to clean it up. > > >> Recentness isn't particularly clear I think, since I don't think >> these platforms have ever had good test coverage. But I did think >> regular NT386 was ok here. >> >> >> Later, >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 1 Sep 2009 09:51:23 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] p007 not terminating on NT386 >>> >>> These thread problems are relatively new (similar to Jay's problems >>> with AutoFlushWr...). Something quite bad must have happened >>> recently to cause them. I took a quick look at ThreadPThread.m3 but >>> didn't notice anything obviously wrong. Something else perhaps? >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 1 Sep 2009, at 08:56, Olaf Wagner wrote: >>> >>> It looks as if m3test p007 does not terminate any more on NT386. >>> This used to work. I just found this >>> >>> --- p007 --- a whole bunch of threads - does the memory grow ? >>> >>> cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw >>> 2>NT386\stderr.build.raw >>> >>> running for more than 5 hours. >>> >>> The last successful run was >>> http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/ >>> . >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> > From rcoleburn at scires.com Wed Sep 2 02:09:25 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Sep 2009 20:09:25 -0400 Subject: [M3devel] report on Windows XP builds/tests Message-ID: <4A9D7F7B.1E75.00D7.1@scires.com> Hi, I am back from vacation. I've updated my sandbox on WindowsXP to be current with the CVS head. I tried first to run Jay's "upgrade.py", but got the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py using c:\cm3\bin\cm3.exe PATH=c:\cm3\bin;%PATH% set CM3_TARGET=NT386 set CM3_INSTALL=c:\cm3 set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 set CM3_ROOT=C:/cm3/Sandbox/cm3 ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) C:\cm3\Sandbox\cm3\scripts\python> Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: C:\cm3\bin>mentor *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 ......... ......... ... more frames ... C:\cm3\bin>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 2284 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... C:\cm3\bin> Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. I will try to run some tests on Vista platform tomorrow. Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. Let me know how I can best assist with the release effort. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 2 02:29:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 20:29:59 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: <4A9D7F7B.1E75.00D7.1@scires.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> Message-ID: <0FA9C0AE-2B85-4574-A90F-1C1A81DE98BB@cs.purdue.edu> Possibly something very broken in mutexes? On 1 Sep 2009, at 20:09, Randy Coleburn wrote: > Hi, I am back from vacation. > > I've updated my sandbox on WindowsXP to be current with the CVS head. > > I tried first to run Jay's "upgrade.py", but got the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > using c:\cm3\bin\cm3.exe > PATH=c:\cm3\bin;%PATH% > set CM3_TARGET=NT386 > set CM3_INSTALL=c:\cm3 > set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- > install\NT386 > set CM3_ROOT=C:/cm3/Sandbox/cm3 > ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: > \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files > \Microsoft Platform SDK for Windows Server 2003 R2\Include) > C:\cm3\Sandbox\cm3\scripts\python> > > Next I tried my upgrade script and was successful. Then I used my > "do-cm3.cmd" script to rebuild all packages and was successful, > except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib > \test". > > In catching up on my email, I noticed Olaf had asked about mentor > and juno on Windows, so I tried running these. Juno starts up and > puts up a window, but quickly crashes. mentor crashes before any > window comes up and I also get a firewall request from Windows > asking whether to block the program--I suspect it is trying to > access the network, hence the firewall request. Here are the > runtime error reports: > > C:\cm3\bin>mentor > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime > \NT386\RTSignal.m3 > 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 > 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 > 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 > 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > > C:\cm3\bin>juno > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 2284 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime > \common\RTCollector.m3 > 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 > 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 > 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 > 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 > 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 > 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 > 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 > 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 > 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > C:\cm3\bin> > > Juno crashes on an ASSERT in the collector, while mentor seems to be > trying to lock a mutex that isn't properly initialized. I have not > looked at the source code to try and debug. Let me know if you want > me to pursue further. > > I've rebuilt some of my own programs and run some very basic tests. > So far, no problems detected. > > I will try to run some tests on Vista platform tomorrow. > > Maybe it would be prudent for me to compile and run some of the > tests ya'll have been implementing. I think the scripts for these > aren't native Windows, but if you can point me to some of these, > I'll try to translate for use on Windows. > > Let me know how I can best assist with the release effort. > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 2 03:33:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 01:33:41 +0000 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: <4A9D7F7B.1E75.00D7.1@scires.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> Message-ID: Is the message about errno.h correct? caltech-parser..hm.. you are up to date? I thought I had either fixed it, or filtered it out. Mutex/mentor I'll have to look at. - Jay Date: Tue, 1 Sep 2009 20:09:25 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] report on Windows XP builds/tests Hi, I am back from vacation. I've updated my sandbox on WindowsXP to be current with the CVS head. I tried first to run Jay's "upgrade.py", but got the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py using c:\cm3\bin\cm3.exe PATH=c:\cm3\bin;%PATH% set CM3_TARGET=NT386 set CM3_INSTALL=c:\cm3 set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 set CM3_ROOT=C:/cm3/Sandbox/cm3 ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) C:\cm3\Sandbox\cm3\scripts\python> Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: C:\cm3\bin>mentor *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 ......... ......... ... more frames ... C:\cm3\bin>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 2284 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... C:\cm3\bin> Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. I will try to run some tests on Vista platform tomorrow. Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. Let me know how I can best assist with the release effort. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Wed Sep 2 03:56:02 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Tue, 01 Sep 2009 20:56:02 -0500 Subject: [M3devel] Mentor error on LINUXLIBC6 Message-ID: <4A9DD0B2.4010505@esoteriq.org> I installed the RC3 core fine, worked well, but I was adding addition packages and tried running mentor. I get: mentor: error while loading shared library libobliqlibanim.so.5: cannot open shared object file: No such file or directory. I'm guessing this is because I didn't install the Obliq package...but why should I have to? From mbishop at esoteriq.org Wed Sep 2 03:58:06 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Tue, 01 Sep 2009 20:58:06 -0500 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <4A9DD0B2.4010505@esoteriq.org> References: <4A9DD0B2.4010505@esoteriq.org> Message-ID: <4A9DD12E.2080903@esoteriq.org> Martin Bishop wrote: > I installed the RC3 core fine, worked well, but I was adding addition > packages and tried running mentor. I get: > > mentor: error while loading shared library libobliqlibanim.so.5: > cannot open shared object file: No such file or directory. > > I'm guessing this is because I didn't install the Obliq package...but > why should I have to? > Oh, and another issue (might just be me?) when I use the install scripts in each package, they complain that "cm3" is not found. If it change it to /usr/local/cm3/bin/cm3, it works just fine. From hosking at cs.purdue.edu Wed Sep 2 04:06:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 22:06:07 -0400 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <4A9DD0B2.4010505@esoteriq.org> References: <4A9DD0B2.4010505@esoteriq.org> Message-ID: <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> Because mentor depends on obliq? If you didn't install the obliq package then it can't dynamically load the shard library. On 1 Sep 2009, at 21:56, Martin Bishop wrote: > I installed the RC3 core fine, worked well, but I was adding > addition packages and tried running mentor. I get: > > mentor: error while loading shared library libobliqlibanim.so.5: > cannot open shared object file: No such file or directory. > > I'm guessing this is because I didn't install the Obliq > package...but why should I have to? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Sep 2 04:53:10 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Sep 2009 22:53:10 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> Message-ID: <4A9DA5DB.1E75.00D7.1@scires.com> I tried upgrade.py again, and it seemed to work this time. I think I may have forgotten to run vcvars to setup the Visual C++ command line on my prior attempt. Sorry. Here is the compiler output for the "caltech-parser\parserlib\parserlib\test" build: --- processing package "caltech-parser\parserlib\parserlib\test" --- --- building in NT386 --- LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed I tried running juno and mentor again. I get different results each run. Interestingly, sometimes mentor didn't crash, instead giving me an error message about not having my HOME environment var set. I tried later to set this, but mentor still crashes. Once when I ran juno it complained that it tried to join a thread twice. Sounds like something is broken in the threading or GC, or the program is coded wrongly somehow. See below for some sample runs of mentor and juno: C:\cm3\Sandbox\cm3\scripts\win>mentor *** *** runtime error: *** Exception "FormsVBT.Error" not in RAISES list *** file "..\src\FormsVBT.m3", line 73 *** *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "..\src\runtime\common\RTType.m3", line 71 *** C:\cm3\Sandbox\cm3\scripts\win>mentor Error: the HOME environment variable is undefined. Please set it to the path of your home directory and try again. C:\cm3\Sandbox\cm3\scripts\win>mentor Error: the HOME environment variable is undefined. Please set it to the path of your home directory and try again. C:\cm3\Sandbox\cm3\scripts\win>mentor *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread\WIN32\ThreadWin32.m3 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 0x12fe88 0x4e32da RegisterView + 0x30 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 Here is another run of Juno. This one dies on a different line number in same module. C:\cm3\Sandbox\cm3\scripts\win>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 1087 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common\RTCollector.m3 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime\common\RTCollector.m3 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src\JunoCompile.m3 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src\JunoCompile.m3 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src\JunoCompile.m3 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src\JunoCompile.m3 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src\JunoCompile.m3 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src\JunoCompile.m3 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src\JunoCompile.m3 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... Regards, Randy Coleburn >>> Jay K 9/1/2009 9:33 PM >>> Is the message about errno.h correct? caltech-parser..hm.. you are up to date? I thought I had either fixed it, or filtered it out. Mutex/mentor I'll have to look at. - Jay Date: Tue, 1 Sep 2009 20:09:25 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] report on Windows XP builds/tests Hi, I am back from vacation. I've updated my sandbox on WindowsXP to be current with the CVS head. I tried first to run Jay's "upgrade.py", but got the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py using c:\cm3\bin\cm3.exe PATH=c:\cm3\bin;%PATH% set CM3_TARGET=NT386 set CM3_INSTALL=c:\cm3 set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 set CM3_ROOT=C:/cm3/Sandbox/cm3 ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) C:\cm3\Sandbox\cm3\scripts\python> Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: C:\cm3\bin>mentor *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 ......... ......... ... more frames ... C:\cm3\bin>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 2284 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... C:\cm3\bin> Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. I will try to run some tests on Vista platform tomorrow. Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. Let me know how I can best assist with the release effort. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 2 05:52:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 23:52:39 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: <4A9DA5DB.1E75.00D7.1@scires.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: mentor (and probably other GUI apps) lock up in ways I have not seen before (it has been a long time since I tried running it, but it always used to work for me without problems about the time that I was bedding down the native threads code so logs there might give the timeframe). I suspect something is quite broken, but don't know when the brokenness got introduced. Here is a backtrace for all threads: Thread 20 (process 84568 thread 0x4f07): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:669 #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:686 #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../ src/xvbt/XClientF.m3:105 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 19 (process 84568 thread 0x4e0b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../ src/Zeus.m3:328 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 18 (process 84568 thread 0x5c0b): #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:189 #1 0x0101ee7a in ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:324 #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') at ../ src/thread/PTHREAD/ThreadPThread.m3:670 #3 0x0101f77a in Thread__AlertPause (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ ThreadPThread.m3:700 #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../ src/Animate.m3:71 #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313 #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 #7 0x00020798 in ViewIncrementalReal__ShowPixel (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ ViewIncrementalReal.m3:567 #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../ src/Zeus.m3:331 #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #11 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #12 0x96373155 in _pthread_start () #13 0x96373012 in thread_start () Thread 17 (process 84568 thread 0x6f0f): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../ src/Zeus.m3:328 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 16 (process 84568 thread 0x425b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) at ../src/ZeusPanel.m3:1425 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 15 (process 84568 thread 0x310b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) at ../src/View.m3:74 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 14 (process 84568 thread 0x3003): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) at ../src/View.m3:74 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 13 (process 84568 thread 0x2f03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) at ../src/View.m3:74 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 12 (process 84568 thread 0x2e03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) at ../src/xvbt/XMessenger.m3:69 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 11 (process 84568 thread 0x2d03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) at ../src/xvbt/XInput.m3:102 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 10 (process 84568 thread 0x2a2b): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/unix/ Common/UnixC.c:301 #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ PTHREAD/ThreadPThread.m3:788 #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ PTHREAD/ThreadPThread.m3:827 #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ thread/PTHREAD/ThreadPThread.m3:730 #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) at ../src/xvbt/XInput.m3:63 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 9 (process 84568 thread 0x29f3): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 #7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/BresenhamIE.m3:227 #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../ src/bresenham/AlgBresenham.m3:55 #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../ src/bresenham/AlgBresenham.m3:86 #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) at ../ src/ZeusPanel.m3:1534 #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 8 (process 84568 thread 0x2803): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) at ../ src/formatter/Formatter.m3:615 #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 7 (process 84568 thread 0x2703): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) at ../ src/formatter/Formatter.m3:615 #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 6 (process 84568 thread 0x2603): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) at ../src/WorkerPool.m3:152 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 5 (process 84568 thread 0x2313): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../src/ unix/Common/UnixC.c:301 #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/ thread/PTHREAD/ThreadPThread.m3:788 #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=1 '\001') at ../src/thread/ PTHREAD/ThreadPThread.m3:827 #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ src/thread/PTHREAD/ThreadPThread.m3:743 #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/POSIX/ TCP.m3:234 #7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #9 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #10 0x96373155 in _pthread_start () #11 0x96373012 in thread_start () Thread 4 (process 84568 thread 0x2003): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:669 #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:686 #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) at ../src/lego/FileBrowserVBT.m3:259 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 3 (process 84568 thread 0x1f03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 2 (process 84568 thread 0x313): #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../ src/thread/PTHREAD/ThreadPThread.m3:669 #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:686 #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../ src/vbt/VBTRep.m3:460 #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #4 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #5 0x96373155 in _pthread_start () #6 0x96373012 in thread_start () Thread 1 (process 84568 local thread 0x2e03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../ src/trestle/Trestle.m3:884 #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ src/runtime/common/RTLinker.m3:400 #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at _m3main.mc:6 On 1 Sep 2009, at 22:53, Randy Coleburn wrote: > I tried upgrade.py again, and it seemed to work this time. I think > I may have forgotten to run vcvars to setup the Visual C++ command > line on my prior attempt. Sorry. > > Here is the compiler output for the "caltech-parser\parserlib > \parserlib\test" build: > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > > LIB_INSTALL is C:\cm3\lib > ignoring ..\src\m3overrides > > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o > CalcTok.i3 > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o > CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime > error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src > \Calc.t -o CalcTok.i3 > > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\NT386\m3make.args > > Fatal Error: package build failed > > I tried running juno and mentor again. I get different results each > run. Interestingly, sometimes mentor didn't crash, instead giving > me an error message about not having my HOME environment var set. I > tried later to set this, but mentor still crashes. Once when I ran > juno it complained that it tried to join a thread twice. Sounds > like something is broken in the threading or GC, or the program is > coded wrongly somehow. See below for some sample runs of mentor and > juno: > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** Exception "FormsVBT.Error" not in RAISES list > *** file "..\src\FormsVBT.m3", line 73 > *** > > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "..\src\runtime\common\RTType.m3", line 71 > *** > > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 > 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 > 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 > 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 > 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 > 0x12fe88 0x4e32da RegisterView + 0x30 in .. > \NT386\MinimaxViewGameTreeBObliqView.m3 > 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in .. > \NT386\MinimaxViewGameTreeBObliqView.m3 > > Here is another run of Juno. This one dies on a different line > number in same module. > > > C:\cm3\Sandbox\cm3\scripts\win>juno > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1087 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common > \RTCollector.m3 > 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime > \common\RTCollector.m3 > 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src > \JunoCompile.m3 > 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src > \JunoCompile.m3 > 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src > \JunoCompile.m3 > 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src > \JunoCompile.m3 > 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src > \JunoCompile.m3 > 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src > \JunoCompile.m3 > 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src > \JunoCompile.m3 > 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src > \JunoCompile.m3 > ......... ......... ... more frames ... > > Regards, > Randy Coleburn > > >>> Jay K 9/1/2009 9:33 PM >>> > Is the message about errno.h correct? > caltech-parser..hm.. you are up to date? I thought I had either > fixed it, or filtered it out. > Mutex/mentor I'll have to look at. > > - Jay > > Date: Tue, 1 Sep 2009 20:09:25 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] report on Windows XP builds/tests > > Hi, I am back from vacation. > > I've updated my sandbox on WindowsXP to be current with the CVS head. > > I tried first to run Jay's "upgrade.py", but got the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > using c:\cm3\bin\cm3.exe > PATH=c:\cm3\bin;%PATH% > set CM3_TARGET=NT386 > set CM3_INSTALL=c:\cm3 > set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- > install\NT386 > set CM3_ROOT=C:/cm3/Sandbox/cm3 > ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: > \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files > \Microsoft Platform SDK for Windows Server 2003 R2\Include) > C:\cm3\Sandbox\cm3\scripts\python> > > Next I tried my upgrade script and was successful. Then I used my > "do-cm3.cmd" script to rebuild all packages and was successful, > except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib > \test". > > In catching up on my email, I noticed Olaf had asked about mentor > and juno on Windows, so I tried running these. Juno starts up and > puts up a window, but quickly crashes. mentor crashes before any > window comes up and I also get a firewall request from Windows > asking whether to block the program--I suspect it is trying to > access the network, hence the firewall request. Here are the > runtime error reports: > > C:\cm3\bin>mentor > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime > \NT386\RTSignal.m3 > 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 > 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 > 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 > 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > > C:\cm3\bin>juno > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 2284 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime > \common\RTCollector.m3 > 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 > 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 > 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 > 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 > 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 > 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 > 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 > 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 > 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > C:\cm3\bin> > > Juno crashes on an ASSERT in the collector, while mentor seems to be > trying to lock a mutex that isn't properly initialized. I have not > looked at the source code to try and debug. Let me know if you want > me to pursue further. > > I've rebuilt some of my own programs and run some very basic tests. > So far, no problems detected. > > I will try to run some tests on Vista platform tomorrow. > > Maybe it would be prudent for me to compile and run some of the > tests ya'll have been implementing. I think the scripts for these > aren't native Windows, but if you can point me to some of these, > I'll try to translate for use on Windows. > > Let me know how I can best assist with the release effort. > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 2 06:00:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 04:00:12 +0000 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <4A9DD12E.2080903@esoteriq.org> References: <4A9DD0B2.4010505@esoteriq.org> <4A9DD12E.2080903@esoteriq.org> Message-ID: I had the same experience with cm3 not found. cm3 is expected to be on the path. Seems kind of reasonable? As to the need to have dependencies -- well, this is our simple cross platform package format. Ahem, if we just bundled everything together in one package, the dependency problem would go away. Granted, maybe that is yucky. - Jay > Date: Tue, 1 Sep 2009 20:58:06 -0500 > From: mbishop at esoteriq.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Mentor error on LINUXLIBC6 > > Martin Bishop wrote: > > I installed the RC3 core fine, worked well, but I was adding addition > > packages and tried running mentor. I get: > > > > mentor: error while loading shared library libobliqlibanim.so.5: > > cannot open shared object file: No such file or directory. > > > > I'm guessing this is because I didn't install the Obliq package...but > > why should I have to? > > > Oh, and another issue (might just be me?) when I use the install scripts > in each package, they complain that "cm3" is not found. If it change it > to /usr/local/cm3/bin/cm3, it works just fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 2 06:20:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 04:20:41 +0000 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: My fear is that I messed up when I factored sizeof(pthread_cond_t), sizeof(pthread_mutex_t), etc. out of the Modula-3 code. The code looks right, but it is easy to miss a level of indirection, or something. We also might as well wrap the last few that aren't wrapped, but no reason to believe that will fix anything. My dashed hope is/was that the compiler being written in Modula-3, including using multiple threads, for garbage collection, would be a good test of the overall system working. The caltech-parser problem looks familiar. I'll have to look again. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Tue, 1 Sep 2009 23:52:39 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] report on Windows XP builds/tests > > mentor (and probably other GUI apps) lock up in ways I have not seen before (it has been a long time since I tried running it, but it always used to work for me without problems about the time that I was bedding down the native threads code so logs there might give the timeframe). I suspect something is quite broken, but don't know when the brokenness got introduced. Here is a backtrace for all threads: > > Thread 20 (process 84568 thread 0x4f07): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:686 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../src/xvbt/XClientF.m3:105 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 19 (process 84568 thread 0x4e0b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../src/Zeus.m3:328 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 84568 thread 0x5c0b): > #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:189 > #1 0x0101ee7a in ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:324 > #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:670 > #3 0x0101f77a in Thread__AlertPause (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ThreadPThread.m3:700 > #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71 > #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #7 0x00020798 in ViewIncrementalReal__ShowPixel (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ViewIncrementalReal.m3:567 > #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 > #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../src/Zeus.m3:331 > #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #11 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #12 0x96373155 in _pthread_start () > #13 0x96373012 in thread_start () > > Thread 17 (process 84568 thread 0x6f0f): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../src/Zeus.m3:328 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 16 (process 84568 thread 0x425b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) at ../src/ZeusPanel.m3:1425 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 84568 thread 0x310b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) at ../src/View.m3:74 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 84568 thread 0x3003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) at ../src/View.m3:74 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 84568 thread 0x2f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) at ../src/View.m3:74 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 84568 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) at ../src/xvbt/XMessenger.m3:69 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 84568 thread 0x2d03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) at ../src/xvbt/XInput.m3:102 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 84568 thread 0x2a2b): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/unix/Common/UnixC.c:301 > #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:788 > #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:827 > #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:730 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) at ../src/xvbt/XInput.m3:63 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 84568 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) at ../src/ZeusPanel.m3:1534 > #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 84568 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) at ../src/formatter/Formatter.m3:615 > #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 84568 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) at ../src/formatter/Formatter.m3:615 > #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 84568 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) at ../src/WorkerPool.m3:152 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 84568 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../src/unix/Common/UnixC.c:301 > #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/thread/PTHREAD/ThreadPThread.m3:788 > #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:827 > #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:743 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 > #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #9 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 84568 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:686 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) at ../src/lego/FileBrowserVBT.m3:259 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 84568 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 84568 thread 0x313): > #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:686 > #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../src/vbt/VBTRep.m3:460 > #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #4 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #5 0x96373155 in _pthread_start () > #6 0x96373012 in thread_start () > > Thread 1 (process 84568 local thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:400 > #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at _m3main.mc:6 > > > On 1 Sep 2009, at 22:53, Randy Coleburn wrote: > > I tried upgrade.py again, and it seemed to work this time. I think I may have forgotten to run vcvars to setup the Visual C++ command line on my prior attempt. Sorry. > > Here is the compiler output for the "caltech-parser\parserlib\parserlib\test" build: > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > > LIB_INSTALL is C:\cm3\lib > ignoring ..\src\m3overrides > > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args > > Fatal Error: package build failed > > I tried running juno and mentor again. I get different results each run. Interestingly, sometimes mentor didn't crash, instead giving me an error message about not having my HOME environment var set. I tried later to set this, but mentor still crashes. Once when I ran juno it complained that it tried to join a thread twice. Sounds like something is broken in the threading or GC, or the program is coded wrongly somehow. See below for some sample runs of mentor and juno: > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** Exception "FormsVBT.Error" not in RAISES list > *** file "..\src\FormsVBT.m3", line 73 > *** > > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "..\src\runtime\common\RTType.m3", line 71 > *** > > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** failed. > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 > 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 > 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 > 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 > 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 > 0x12fe88 0x4e32da RegisterView + 0x30 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 > 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 > > Here is another run of Juno. This one dies on a different line number in same module. > > > C:\cm3\Sandbox\cm3\scripts\win>juno > > *** > *** runtime error: > *** failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1087 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common\RTCollector.m3 > 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime\common\RTCollector.m3 > 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src\JunoCompile.m3 > 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src\JunoCompile.m3 > 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src\JunoCompile.m3 > 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src\JunoCompile.m3 > 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src\JunoCompile.m3 > 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src\JunoCompile.m3 > 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src\JunoCompile.m3 > 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > Regards, > Randy Coleburn > >>>> Jay K> 9/1/2009 9:33 PM>>> > Is the message about errno.h correct? > caltech-parser..hm.. you are up to date? I thought I had either fixed it, or filtered it out. > Mutex/mentor I'll have to look at. > > - Jay > > ________________________________ > Date: Tue, 1 Sep 2009 20:09:25 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] report on Windows XP builds/tests > > Hi, I am back from vacation. > > I've updated my sandbox on WindowsXP to be current with the CVS head. > > I tried first to run Jay's "upgrade.py", but got the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > using c:\cm3\bin\cm3.exe > PATH=c:\cm3\bin;%PATH% > set CM3_TARGET=NT386 > set CM3_INSTALL=c:\cm3 > set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 > set CM3_ROOT=C:/cm3/Sandbox/cm3 > ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) > C:\cm3\Sandbox\cm3\scripts\python> > > Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". > > In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: > > C:\cm3\bin>mentor > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 > 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 > 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 > 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 > 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 > 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > > C:\cm3\bin>juno > > *** > *** runtime error: > *** failed. > *** file "..\src\runtime\common\RTCollector.m3", line 2284 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 > 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 > 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 > 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 > 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 > 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 > 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 > 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 > 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 > 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > C:\cm3\bin> > > Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. > > I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. > > I will try to run some tests on Vista platform tomorrow. > > Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. > > Let me know how I can best assist with the release effort. > > Regards, > Randy Coleburn > From hosking at cs.purdue.edu Wed Sep 2 06:52:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Sep 2009 00:52:15 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: On 2 Sep 2009, at 00:20, Jay K wrote: > My fear is that I messed up when I factored sizeof(pthread_cond_t), > sizeof(pthread_mutex_t), etc. out of the Modula-3 code. > The code looks right, but it is easy to miss a level of indirection, > or something. > We also might as well wrap the last few that aren't wrapped, but no > reason to believe that will fix anything. We'll need to look into this. The weird thing is that it *mostly* works. I'd have thought getting those wrong would break everywhere. Still, probably worth rechecking. > My dashed hope is/was that the compiler being written in Modula-3, > including using multiple threads, for garbage collection, would be a > good test of the overall system working. I don't think the compiler is a multi-threaded mutator. The GC piggybacks work on the mutator by default, rather than running in separate threads. > The caltech-parser problem looks familiar. I'll have to look again. > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: rcoleburn at scires.com >> Date: Tue, 1 Sep 2009 23:52:39 -0400 >> CC: m3devel at elegosoft.com; jay.krell at cornell.edu >> Subject: Re: [M3devel] report on Windows XP builds/tests >> >> mentor (and probably other GUI apps) lock up in ways I have not >> seen before (it has been a long time since I tried running it, but >> it always used to work for me without problems about the time that >> I was bedding down the native threads code so logs there might give >> the timeframe). I suspect something is quite broken, but don't know >> when the brokenness got introduced. Here is a backtrace for all >> threads: >> >> Thread 20 (process 84568 thread 0x4f07): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, >> rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:669 >> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:686 >> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../ >> src/xvbt/XClientF.m3:105 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 19 (process 84568 thread 0x4e0b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, >> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >> M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >> M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../ >> src/Zeus.m3:328 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 18 (process 84568 thread 0x5c0b): >> #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) >> at ../src/thread/PTHREAD/ThreadPThread.m3:189 >> #1 0x0101ee7a in ThreadPThread__XTestAlert >> (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:324 >> #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, >> M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') >> at ../src/thread/PTHREAD/ThreadPThread.m3:670 >> #3 0x0101f77a in Thread__AlertPause >> (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:700 >> #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, >> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) >> at ../src/Animate.m3:71 >> #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, >> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >> #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, >> M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 >> #7 0x00020798 in ViewIncrementalReal__ShowPixel >> (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ >> ViewIncrementalReal.m3:567 >> #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, >> M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 >> #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../ >> src/Zeus.m3:331 >> #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #11 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #12 0x96373155 in _pthread_start () >> #13 0x96373012 in thread_start () >> >> Thread 17 (process 84568 thread 0x6f0f): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, >> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >> M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >> M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../ >> src/Zeus.m3:328 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 16 (process 84568 thread 0x425b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, >> M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, >> M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) >> at ../src/ZeusPanel.m3:1425 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 15 (process 84568 thread 0x310b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) >> at ../src/View.m3:74 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 14 (process 84568 thread 0x3003): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) >> at ../src/View.m3:74 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 13 (process 84568 thread 0x2f03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) >> at ../src/View.m3:74 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 12 (process 84568 thread 0x2e03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, >> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >> M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) >> at ../src/xvbt/XMessenger.m3:69 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 11 (process 84568 thread 0x2d03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, >> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >> M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) >> at ../src/xvbt/XInput.m3:102 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 10 (process 84568 thread 0x2a2b): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, >> writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/ >> unix/Common/UnixC.c:301 >> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:788 >> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:827 >> #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, >> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:730 >> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) >> at ../src/xvbt/XInput.m3:63 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 9 (process 84568 thread 0x29f3): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, >> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, >> M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, >> M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 >> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, >> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 >> #7 0x000149a7 in BresenhamIE__ShowPixel >> (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/ >> BresenhamIE.m3:227 >> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, >> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >> at ../src/bresenham/AlgBresenham.m3:55 >> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../ >> src/bresenham/AlgBresenham.m3:86 >> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) >> at ../src/ZeusPanel.m3:1534 >> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #12 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 8 (process 84568 thread 0x2803): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, >> M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, >> M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >> Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, >> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) >> at ../src/formatter/Formatter.m3:615 >> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #12 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 7 (process 84568 thread 0x2703): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, >> M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, >> M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >> Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, >> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) >> at ../src/formatter/Formatter.m3:615 >> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #12 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 6 (process 84568 thread 0x2603): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, >> M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, >> M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) >> at ../src/WorkerPool.m3:152 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 5 (process 84568 thread 0x2313): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, >> writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../ >> src/unix/Common/UnixC.c:301 >> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:788 >> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:827 >> #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, >> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:743 >> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, >> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/ >> POSIX/TCP.m3:234 >> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >> (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 >> #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #9 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #10 0x96373155 in _pthread_start () >> #11 0x96373012 in thread_start () >> >> Thread 4 (process 84568 thread 0x2003): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, >> rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:669 >> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:686 >> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) >> at ../src/lego/FileBrowserVBT.m3:259 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 3 (process 84568 thread 0x1f03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, >> M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, >> M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00a839e2 in VTView__VFontCleanUpThread >> (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 2 (process 84568 thread 0x313): >> #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, >> M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../ >> src/thread/PTHREAD/ThreadPThread.m3:669 >> #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) >> at ../src/thread/PTHREAD/ThreadPThread.m3:686 >> #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../ >> src/vbt/VBTRep.m3:460 >> #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #4 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #5 0x96373155 in _pthread_start () >> #6 0x96373012 in thread_start () >> >> Thread 1 (process 84568 local thread 0x2e03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >> M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 >> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >> #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ >> src/runtime/common/RTLinker.m3:400 >> #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at >> _m3main.mc:6 >> >> >> On 1 Sep 2009, at 22:53, Randy Coleburn wrote: >> >> I tried upgrade.py again, and it seemed to work this time. I think >> I may have forgotten to run vcvars to setup the Visual C++ command >> line on my prior attempt. Sorry. >> >> Here is the compiler output for the "caltech-parser\parserlib >> \parserlib\test" build: >> >> --- processing package "caltech-parser\parserlib\parserlib\test" --- >> --- building in NT386 --- >> >> LIB_INSTALL is C:\cm3\lib >> ignoring ..\src\m3overrides >> >> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >> CalcTok.i3 >> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >> CalcTok.i3 >> The system cannot find the path specified. >> "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime >> error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok .. >> \src\Calc.t -o CalcTok.i3 >> >> --procedure-- -line- -file--- >> exec -- >> _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl >> _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl >> _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl >> _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl >> token 73 C:\cm3\pkg\parserlib\src\parser.tmpl >> include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib >> \test\src\m3makefile >> 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test >> \NT386\m3make.args >> >> Fatal Error: package build failed >> >> I tried running juno and mentor again. I get different results each >> run. Interestingly, sometimes mentor didn't crash, instead giving >> me an error message about not having my HOME environment var set. I >> tried later to set this, but mentor still crashes. Once when I ran >> juno it complained that it tried to join a thread twice. Sounds >> like something is broken in the threading or GC, or the program is >> coded wrongly somehow. See below for some sample runs of mentor and >> juno: >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> >> *** >> *** runtime error: >> *** Exception "FormsVBT.Error" not in RAISES list >> *** file "..\src\FormsVBT.m3", line 73 >> *** >> >> >> >> *** >> *** runtime error: >> *** An enumeration or subrange value was out of range. >> *** file "..\src\runtime\common\RTType.m3", line 71 >> *** >> >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> Error: the HOME environment variable is undefined. >> Please set it to the path of your home directory and try again. >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> Error: the HOME environment variable is undefined. >> Please set it to the path of your home directory and try again. >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread >> \WIN32\ThreadWin32.m3 >> 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 >> 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 >> 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 >> 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 >> 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 >> 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 >> 0x12fe88 0x4e32da RegisterView + 0x30 in .. >> \NT386\MinimaxViewGameTreeBObliqView.m3 >> 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in .. >> \NT386\MinimaxViewGameTreeBObliqView.m3 >> >> Here is another run of Juno. This one dies on a different line >> number in same module. >> >> >> C:\cm3\Sandbox\cm3\scripts\win>juno >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 1087 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common >> \RTCollector.m3 >> 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime >> \common\RTCollector.m3 >> 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src >> \JunoCompile.m3 >> 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src >> \JunoCompile.m3 >> 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src >> \JunoCompile.m3 >> 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src >> \JunoCompile.m3 >> 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src >> \JunoCompile.m3 >> 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src >> \JunoCompile.m3 >> 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src >> \JunoCompile.m3 >> 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src >> \JunoCompile.m3 >> ......... ......... ... more frames ... >> >> Regards, >> Randy Coleburn >> >>>>> Jay K> 9/1/2009 9:33 PM>>> >> Is the message about errno.h correct? >> caltech-parser..hm.. you are up to date? I thought I had either >> fixed it, or filtered it out. >> Mutex/mentor I'll have to look at. >> >> - Jay >> >> ________________________________ >> Date: Tue, 1 Sep 2009 20:09:25 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] report on Windows XP builds/tests >> >> Hi, I am back from vacation. >> >> I've updated my sandbox on WindowsXP to be current with the CVS head. >> >> I tried first to run Jay's "upgrade.py", but got the following error: >> >> C:\cm3\Sandbox\cm3\scripts\python>upgrade.py >> using c:\cm3\bin\cm3.exe >> PATH=c:\cm3\bin;%PATH% >> set CM3_TARGET=NT386 >> set CM3_INSTALL=c:\cm3 >> set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- >> install\NT386 >> set CM3_ROOT=C:/cm3/Sandbox/cm3 >> ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: >> \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files >> \Microsoft Platform SDK for Windows Server 2003 R2\Include) >> C:\cm3\Sandbox\cm3\scripts\python> >> >> Next I tried my upgrade script and was successful. Then I used my >> "do-cm3.cmd" script to rebuild all packages and was successful, >> except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib >> \test". >> >> In catching up on my email, I noticed Olaf had asked about mentor >> and juno on Windows, so I tried running these. Juno starts up and >> puts up a window, but quickly crashes. mentor crashes before any >> window comes up and I also get a firewall request from Windows >> asking whether to block the program--I suspect it is trying to >> access the network, hence the firewall request. Here are the >> runtime error reports: >> >> C:\cm3\bin>mentor >> >> *** >> *** runtime error: >> *** Attempt to reference an illegal memory location. >> *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread >> \WIN32\ThreadWin32.m3 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime >> \NT386\RTSignal.m3 >> 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread >> \WIN32\ThreadWin32.m3 >> 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 >> 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 >> 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >> 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >> 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 >> 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >> 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >> 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 >> ......... ......... ... more frames ... >> >> >> C:\cm3\bin>juno >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 2284 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common >> \RTCollector.m3 >> 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 >> 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 >> 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 >> 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 >> 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 >> 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 >> 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 >> 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 >> 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 >> ......... ......... ... more frames ... >> >> C:\cm3\bin> >> >> Juno crashes on an ASSERT in the collector, while mentor seems to >> be trying to lock a mutex that isn't properly initialized. I have >> not looked at the source code to try and debug. Let me know if you >> want me to pursue further. >> >> I've rebuilt some of my own programs and run some very basic tests. >> So far, no problems detected. >> >> I will try to run some tests on Vista platform tomorrow. >> >> Maybe it would be prudent for me to compile and run some of the >> tests ya'll have been implementing. I think the scripts for these >> aren't native Windows, but if you can point me to some of these, >> I'll try to translate for use on Windows. >> >> Let me know how I can best assist with the release effort. >> >> Regards, >> Randy Coleburn >> From jay.krell at cornell.edu Wed Sep 2 07:15:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 05:15:46 +0000 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: Yep, no matter what the problem is, that's my other dashed hope -- that'd it'd either work very little or very much, and not somewhere in between as it does. It seems a little surprising to see things only 4-aligned below, but I'd have to check the related sizes, if they are 4 then ok. I also checked the parameter order for calloc. calloc(n,1) could reasonably provide something unaligned, but calloc(1,n) that I use should be n or "max" aligned, whichever is smaller. I can't claim that I thought of this at the time, maybe I just got lucky. I'll /try/ to look at this shortly. Nice that it occurs on NT too. :) It could be something else entirely, but this an obvious area to double double double check, and if not too difficult, test with it reverted and sort of prove by showing the opposite behavior with the opposite state (which isn't conclusive, but you understand..) Hm noticably on NT I didn't make this change for dynamically allocated structures, only static ones. That part is also a little bit to be focused on, but /seemingly/ easier to get correct. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 2 Sep 2009 00:52:15 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] report on Windows XP builds/tests > > On 2 Sep 2009, at 00:20, Jay K wrote: > >> My fear is that I messed up when I factored sizeof(pthread_cond_t), >> sizeof(pthread_mutex_t), etc. out of the Modula-3 code. >> The code looks right, but it is easy to miss a level of indirection, >> or something. >> We also might as well wrap the last few that aren't wrapped, but no >> reason to believe that will fix anything. > > We'll need to look into this. The weird thing is that it *mostly* > works. I'd have thought getting those wrong would break everywhere. > Still, probably worth rechecking. > >> My dashed hope is/was that the compiler being written in Modula-3, >> including using multiple threads, for garbage collection, would be a >> good test of the overall system working. > > I don't think the compiler is a multi-threaded mutator. > > The GC piggybacks work on the mutator by default, rather than running > in separate threads. > >> The caltech-parser problem looks familiar. I'll have to look again. >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: rcoleburn at scires.com >>> Date: Tue, 1 Sep 2009 23:52:39 -0400 >>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu >>> Subject: Re: [M3devel] report on Windows XP builds/tests >>> >>> mentor (and probably other GUI apps) lock up in ways I have not >>> seen before (it has been a long time since I tried running it, but >>> it always used to work for me without problems about the time that >>> I was bedding down the native threads code so logs there might give >>> the timeframe). I suspect something is quite broken, but don't know >>> when the brokenness got introduced. Here is a backtrace for all >>> threads: >>> >>> Thread 20 (process 84568 thread 0x4f07): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, >>> rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:669 >>> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:686 >>> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../ >>> src/xvbt/XClientF.m3:105 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 19 (process 84568 thread 0x4e0b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, >>> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >>> M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >>> M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../ >>> src/Zeus.m3:328 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 18 (process 84568 thread 0x5c0b): >>> #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:189 >>> #1 0x0101ee7a in ThreadPThread__XTestAlert >>> (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:324 >>> #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, >>> M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') >>> at ../src/thread/PTHREAD/ThreadPThread.m3:670 >>> #3 0x0101f77a in Thread__AlertPause >>> (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:700 >>> #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, >>> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) >>> at ../src/Animate.m3:71 >>> #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, >>> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >>> #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, >>> M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 >>> #7 0x00020798 in ViewIncrementalReal__ShowPixel >>> (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >>> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ >>> ViewIncrementalReal.m3:567 >>> #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, >>> M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 >>> #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../ >>> src/Zeus.m3:331 >>> #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #11 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #12 0x96373155 in _pthread_start () >>> #13 0x96373012 in thread_start () >>> >>> Thread 17 (process 84568 thread 0x6f0f): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, >>> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >>> M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >>> M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../ >>> src/Zeus.m3:328 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 16 (process 84568 thread 0x425b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, >>> M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, >>> M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) >>> at ../src/ZeusPanel.m3:1425 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 15 (process 84568 thread 0x310b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) >>> at ../src/View.m3:74 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 14 (process 84568 thread 0x3003): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) >>> at ../src/View.m3:74 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 13 (process 84568 thread 0x2f03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) >>> at ../src/View.m3:74 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 12 (process 84568 thread 0x2e03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, >>> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >>> M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) >>> at ../src/xvbt/XMessenger.m3:69 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 11 (process 84568 thread 0x2d03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, >>> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >>> M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) >>> at ../src/xvbt/XInput.m3:102 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 10 (process 84568 thread 0x2a2b): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, >>> writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/ >>> unix/Common/UnixC.c:301 >>> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:788 >>> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, >>> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:827 >>> #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:730 >>> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) >>> at ../src/xvbt/XInput.m3:63 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 9 (process 84568 thread 0x29f3): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, >>> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, >>> M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, >>> M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 >>> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, >>> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >>> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 >>> #7 0x000149a7 in BresenhamIE__ShowPixel >>> (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >>> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/ >>> BresenhamIE.m3:227 >>> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, >>> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >>> at ../src/bresenham/AlgBresenham.m3:55 >>> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../ >>> src/bresenham/AlgBresenham.m3:86 >>> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) >>> at ../src/ZeusPanel.m3:1534 >>> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #12 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 8 (process 84568 thread 0x2803): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, >>> M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, >>> M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >>> Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, >>> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #12 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 7 (process 84568 thread 0x2703): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, >>> M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, >>> M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >>> Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, >>> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #12 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 6 (process 84568 thread 0x2603): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, >>> M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, >>> M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) >>> at ../src/WorkerPool.m3:152 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 5 (process 84568 thread 0x2313): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, >>> writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../ >>> src/unix/Common/UnixC.c:301 >>> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:788 >>> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, >>> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:827 >>> #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:743 >>> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, >>> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >>> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/ >>> POSIX/TCP.m3:234 >>> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >>> (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 >>> #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #9 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #10 0x96373155 in _pthread_start () >>> #11 0x96373012 in thread_start () >>> >>> Thread 4 (process 84568 thread 0x2003): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, >>> rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:669 >>> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:686 >>> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) >>> at ../src/lego/FileBrowserVBT.m3:259 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 3 (process 84568 thread 0x1f03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, >>> M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, >>> M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00a839e2 in VTView__VFontCleanUpThread >>> (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 2 (process 84568 thread 0x313): >>> #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, >>> M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../ >>> src/thread/PTHREAD/ThreadPThread.m3:669 >>> #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:686 >>> #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../ >>> src/vbt/VBTRep.m3:460 >>> #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #4 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #5 0x96373155 in _pthread_start () >>> #6 0x96373012 in thread_start () >>> >>> Thread 1 (process 84568 local thread 0x2e03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >>> M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 >>> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >>> #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ >>> src/runtime/common/RTLinker.m3:400 >>> #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at >>> _m3main.mc:6 >>> >>> >>> On 1 Sep 2009, at 22:53, Randy Coleburn wrote: >>> >>> I tried upgrade.py again, and it seemed to work this time. I think >>> I may have forgotten to run vcvars to setup the Visual C++ command >>> line on my prior attempt. Sorry. >>> >>> Here is the compiler output for the "caltech-parser\parserlib >>> \parserlib\test" build: >>> >>> --- processing package "caltech-parser\parserlib\parserlib\test" --- >>> --- building in NT386 --- >>> >>> LIB_INSTALL is C:\cm3\lib >>> ignoring ..\src\m3overrides >>> >>> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >>> CalcTok.i3 >>> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >>> CalcTok.i3 >>> The system cannot find the path specified. >>> "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime >>> error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok .. >>> \src\Calc.t -o CalcTok.i3 >>> >>> --procedure-- -line- -file--- >>> exec -- >>> _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl >>> _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl >>> _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl >>> _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl >>> token 73 C:\cm3\pkg\parserlib\src\parser.tmpl >>> include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib >>> \test\src\m3makefile >>> 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test >>> \NT386\m3make.args >>> >>> Fatal Error: package build failed >>> >>> I tried running juno and mentor again. I get different results each >>> run. Interestingly, sometimes mentor didn't crash, instead giving >>> me an error message about not having my HOME environment var set. I >>> tried later to set this, but mentor still crashes. Once when I ran >>> juno it complained that it tried to join a thread twice. Sounds >>> like something is broken in the threading or GC, or the program is >>> coded wrongly somehow. See below for some sample runs of mentor and >>> juno: >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> >>> *** >>> *** runtime error: >>> *** Exception "FormsVBT.Error" not in RAISES list >>> *** file "..\src\FormsVBT.m3", line 73 >>> *** >>> >>> >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "..\src\runtime\common\RTType.m3", line 71 >>> *** >>> >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> Error: the HOME environment variable is undefined. >>> Please set it to the path of your home directory and try again. >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> Error: the HOME environment variable is undefined. >>> Please set it to the path of your home directory and try again. >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 >>> 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 >>> 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 >>> 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 >>> 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 >>> 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 >>> 0x12fe88 0x4e32da RegisterView + 0x30 in .. >>> \NT386\MinimaxViewGameTreeBObliqView.m3 >>> 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in .. >>> \NT386\MinimaxViewGameTreeBObliqView.m3 >>> >>> Here is another run of Juno. This one dies on a different line >>> number in same module. >>> >>> >>> C:\cm3\Sandbox\cm3\scripts\win>juno >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\runtime\common\RTCollector.m3", line 1087 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common >>> \RTCollector.m3 >>> 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime >>> \common\RTCollector.m3 >>> 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src >>> \JunoCompile.m3 >>> 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src >>> \JunoCompile.m3 >>> 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src >>> \JunoCompile.m3 >>> 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src >>> \JunoCompile.m3 >>> 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src >>> \JunoCompile.m3 >>> 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src >>> \JunoCompile.m3 >>> 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src >>> \JunoCompile.m3 >>> 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src >>> \JunoCompile.m3 >>> ......... ......... ... more frames ... >>> >>> Regards, >>> Randy Coleburn >>> >>>>>> Jay K> 9/1/2009 9:33 PM>>> >>> Is the message about errno.h correct? >>> caltech-parser..hm.. you are up to date? I thought I had either >>> fixed it, or filtered it out. >>> Mutex/mentor I'll have to look at. >>> >>> - Jay >>> >>> ________________________________ >>> Date: Tue, 1 Sep 2009 20:09:25 -0400 >>> From: rcoleburn at scires.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] report on Windows XP builds/tests >>> >>> Hi, I am back from vacation. >>> >>> I've updated my sandbox on WindowsXP to be current with the CVS head. >>> >>> I tried first to run Jay's "upgrade.py", but got the following error: >>> >>> C:\cm3\Sandbox\cm3\scripts\python>upgrade.py >>> using c:\cm3\bin\cm3.exe >>> PATH=c:\cm3\bin;%PATH% >>> set CM3_TARGET=NT386 >>> set CM3_INSTALL=c:\cm3 >>> set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- >>> install\NT386 >>> set CM3_ROOT=C:/cm3/Sandbox/cm3 >>> ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: >>> \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files >>> \Microsoft Platform SDK for Windows Server 2003 R2\Include) >>> C:\cm3\Sandbox\cm3\scripts\python> >>> >>> Next I tried my upgrade script and was successful. Then I used my >>> "do-cm3.cmd" script to rebuild all packages and was successful, >>> except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib >>> \test". >>> >>> In catching up on my email, I noticed Olaf had asked about mentor >>> and juno on Windows, so I tried running these. Juno starts up and >>> puts up a window, but quickly crashes. mentor crashes before any >>> window comes up and I also get a firewall request from Windows >>> asking whether to block the program--I suspect it is trying to >>> access the network, hence the firewall request. Here are the >>> runtime error reports: >>> >>> C:\cm3\bin>mentor >>> >>> *** >>> *** runtime error: >>> *** Attempt to reference an illegal memory location. >>> *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime >>> \NT386\RTSignal.m3 >>> 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 >>> 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 >>> 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 >>> 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 >>> ......... ......... ... more frames ... >>> >>> >>> C:\cm3\bin>juno >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\runtime\common\RTCollector.m3", line 2284 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common >>> \RTCollector.m3 >>> 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 >>> 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 >>> 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 >>> 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 >>> 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 >>> 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 >>> 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 >>> 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 >>> 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 >>> ......... ......... ... more frames ... >>> >>> C:\cm3\bin> >>> >>> Juno crashes on an ASSERT in the collector, while mentor seems to >>> be trying to lock a mutex that isn't properly initialized. I have >>> not looked at the source code to try and debug. Let me know if you >>> want me to pursue further. >>> >>> I've rebuilt some of my own programs and run some very basic tests. >>> So far, no problems detected. >>> >>> I will try to run some tests on Vista platform tomorrow. >>> >>> Maybe it would be prudent for me to compile and run some of the >>> tests ya'll have been implementing. I think the scripts for these >>> aren't native Windows, but if you can point me to some of these, >>> I'll try to translate for use on Windows. >>> >>> Let me know how I can best assist with the release effort. >>> >>> Regards, >>> Randy Coleburn >>> > From wagner at elegosoft.com Wed Sep 2 08:39:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 08:39:23 +0200 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> References: <4A9DD0B2.4010505@esoteriq.org> <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> Message-ID: <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> Quoting Tony Hosking : > Because mentor depends on obliq? If you didn't install the obliq > package then it can't dynamically load the shard library. This is strange. mentor should be built standalone. Is build_standalone() broken on LINUXLIBC6? And I don't see a direct obliq dependency. Ah, that's in src/minimax/m3makefile; I've probably missed it when extracting the dependencies. > On 1 Sep 2009, at 21:56, Martin Bishop wrote: > >> I installed the RC3 core fine, worked well, but I was adding >> addition packages and tried running mentor. I get: >> >> mentor: error while loading shared library libobliqlibanim.so.5: >> cannot open shared object file: No such file or directory. >> >> I'm guessing this is because I didn't install the Obliq >> package...but why should I have to? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 2 08:45:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 06:45:36 +0000 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> References: <4A9DD0B2.4010505@esoteriq.org> <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> Message-ID: Why should mentor be standalone? - Jay ---------------------------------------- > Date: Wed, 2 Sep 2009 08:39:23 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Mentor error on LINUXLIBC6 > > Quoting Tony Hosking : > >> Because mentor depends on obliq? If you didn't install the obliq >> package then it can't dynamically load the shard library. > > This is strange. mentor should be built standalone. > Is build_standalone() broken on LINUXLIBC6? > > And I don't see a direct obliq dependency. Ah, that's in > src/minimax/m3makefile; I've probably missed it when extracting the > dependencies. > >> On 1 Sep 2009, at 21:56, Martin Bishop wrote: >> >>> I installed the RC3 core fine, worked well, but I was adding >>> addition packages and tried running mentor. I get: >>> >>> mentor: error while loading shared library libobliqlibanim.so.5: >>> cannot open shared object file: No such file or directory. >>> >>> I'm guessing this is because I didn't install the Obliq >>> package...but why should I have to? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Sep 2 08:49:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 08:49:47 +0200 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> Quoting Tony Hosking : > On 2 Sep 2009, at 00:20, Jay K wrote: > >> My fear is that I messed up when I factored sizeof(pthread_cond_t), >> sizeof(pthread_mutex_t), etc. out of the Modula-3 code. >> The code looks right, but it is easy to miss a level of >> indirection, or something. >> We also might as well wrap the last few that aren't wrapped, but no >> reason to believe that will fix anything. > > We'll need to look into this. The weird thing is that it *mostly* > works. I'd have thought getting those wrong would break everywhere. > Still, probably worth rechecking. If something this fundamental is broken in the runtime, we can probably forget all the RC3 packages built so far and just hope for RC4? Why has nobody noticed this before? We really need some more tests that are able to detect such breakage. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Sep 2 08:56:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 08:56:25 +0200 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: References: <4A9DD0B2.4010505@esoteriq.org> <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> Message-ID: <20090902085625.crri91x21ws800os@mail.elegosoft.com> Quoting Jay K : > Why should mentor be standalone? You are correct. build_standalone() is a local modification in one of my workspaces for debugging. Sorry for the confusion. Still the dependency seems to be missing in the documentation (anim --> obliq). Probably the sub-makefiles weren't processed :-( Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 2 09:11:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 07:11:28 +0000 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> Message-ID: we can't answer the question until we determine the problem! :) - Jay ---------------------------------------- > Date: Wed, 2 Sep 2009 08:49:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests > > Quoting Tony Hosking : > >> On 2 Sep 2009, at 00:20, Jay K wrote: >> >>> My fear is that I messed up when I factored sizeof(pthread_cond_t), >>> sizeof(pthread_mutex_t), etc. out of the Modula-3 code. >>> The code looks right, but it is easy to miss a level of >>> indirection, or something. >>> We also might as well wrap the last few that aren't wrapped, but no >>> reason to believe that will fix anything. >> >> We'll need to look into this. The weird thing is that it *mostly* >> works. I'd have thought getting those wrong would break everywhere. >> Still, probably worth rechecking. > > If something this fundamental is broken in the runtime, we can > probably forget all the RC3 packages built so far and just hope > for RC4? > > Why has nobody noticed this before? We really need some more tests > that are able to detect such breakage. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Sep 2 10:41:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 08:41:59 +0000 Subject: [M3devel] duplicate FileBrowserVBT.m3 Message-ID: C:\dev2\cm3.2\m3-lectern\lectern\src\FileBrowserVBT.m3 C:\dev2\cm3.2\m3-ui\vbtkit\src\lego\FileBrowserVBT.m3 These are nearly identical. I don't entirely believe the comment about directories on Windows. - directories to have timestamps - it is up to the file system, not the operating system, You can see ext3 file systems over the network from Windows via SMB, etc. (and you can see FAT and NTFS on Linux, Solaris, Mac, etc. via SMB, NFS, etc.) They should be merged. Probably m3-ui/vbtkit is where the merge should go. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 2 11:26:02 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 11:26:02 +0200 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> Message-ID: <20090902112602.eecq6rptkwk4k480@mail.elegosoft.com> Quoting Jay K : > we can't answer the question until we determine the problem! :) Of course. I have opened ticket #1070 in trac for this issue. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 2 11:30:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 09:30:08 +0000 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: <20090902112602.eecq6rptkwk4k480@mail.elegosoft.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> <20090902112602.eecq6rptkwk4k480@mail.elegosoft.com> Message-ID: er, now that I experience it, of course, it is worse. I see the intermittent hangs of Juno on I386_DARWIN. I see Juno and/or mentor always/usually crashing on NT. The Juno crash is particularly nice because it is always accessing the same invalid address, or a fixed offset from it (the invalid address is in a register and the instruction contains an offset). @M3nogc seems to perturb it. NT has fewer changes here. I'm going to try 5.7.0 and 5.7.1 snapshots. Getting daily or weekly snapshots automatically from Hudson would be nice. - Jay > Date: Wed, 2 Sep 2009 11:26:02 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests > > Quoting Jay K : > > > we can't answer the question until we determine the problem! :) > > Of course. > > I have opened ticket #1070 in trac for this issue. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Sep 3 00:46:42 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Sep 2009 18:46:42 -0400 Subject: [M3devel] cm3.cfg for Windows Message-ID: <4A9EBD88.1E75.00D7.1@scires.com> Jay: After running your "upgrade.py" I notice that the "cm3\bin\cm3.cfg" file has been replaced and now contains 134 lines instead of the 2 lines you had described earlier. Let me know if I should switch back to the 2-line variant you described earlier, or if the new 134-line file is the new way forward. Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 3 03:15:12 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 2 Sep 2009 18:15:12 -0700 Subject: [M3devel] cm3.cfg for Windows In-Reply-To: <4A9EBD88.1E75.00D7.1@scires.com> References: <4A9EBD88.1E75.00D7.1@scires.com> Message-ID: <3D5C4155-A36D-4E87-AAB5-6AAC2E18A7BE@hotmail.com> They are both valid. The larger one makes some guesses and delegates back to the cvs tree. It is nice for when you are actively editing the files and don't want to also copy them. It also will delegate to the installed ones and there its value is honoring the CM3_TARGET environment variable. Upgrade.py should probably have a command line option. Really upgrade is just a LITTLE more than do-pkg and might need some rethinking. It also copies cm3 for example which is really a workaround for cm3 not shipping itself. For you probably the two liner. - Jay (phone) On Sep 2, 2009, at 3:46 PM, "Randy Coleburn" wrote: > Jay: > > After running your "upgrade.py" I notice that the "cm3\bin\cm3.cfg" > file has been replaced and now contains 134 lines instead of the 2 > lines you had described earlier. > > Let me know if I should switch back to the 2-line variant you > described earlier, or if the new 134-line file is the new way forward. > > Regards, > Randy From michael.anderson at elego.de Wed Sep 2 13:07:43 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 02 Sep 2009 13:07:43 +0200 Subject: [M3devel] elego Server Maintenance 04.09.09 Message-ID: <20090902130743.pp6nlfuumo8k4008@mail.elego.de> Liebe Kollegen, Liebe Elego-Kunden, In der Nacht von Freitag, dem 04.09 auf Samstag, den 05.09 werden wir um 22.00 CET Uhr planmaessige Wartungsarbeiten an unseren Servern durchfuehren. Es kann zur kurzeitigen Unterbrechung mancher Dienste kommen. Voraussichtliche Dauer der Wartung: 120 Min. Wir bitten um Verst?ndnis. - die elego Admins On Friday, September 4 at 10 PM CET, we will perform scheduled maintenance on our servers. Brief interruptions of service may occur. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Sep 3 15:15:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Sep 2009 13:15:09 +0000 Subject: [M3devel] some data on Juno crash on Win32 Message-ID: summary: 5.7.0 and 5.7.1 of unknown date: both always fail 5.7.0 always fails an assert (various?) 5.7.1 sometimes fails an assert (various) 5.7.1 sometimes access violates, always on address 00200000, plus or minus 4. Current source always access violates, same address. Since 5.7.1 and current source always access violate (aka SIGSEGV) on the same location, every run, I'm more inclined to look at this. And then hope everything else is "the same" problem. But of course there might be multiple problems. It might be good to check for the hang in various from http://www.opencm3.net/uploaded-archives/index.html. Also see what all we can get from http://www.opencm3.net/snaps/snapshot-index.html. I'm going to see if I can get the index update with the many files I noticed in the file system. longer story: 5.7.0 visual glitch and usually: visual glitch might have been the problem with import the bit set data. *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x59cf830 0xf01c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x59cf8f8 0xf0fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x59cfd54 0xf0dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x59cfdbc 0xf085be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x59cfe04 0xf06ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x59cfe30 0x7e418734 0x59cfe98 0x7e418816 0x59cfef8 0x7e4189cd 0x59cff08 0x7e4196c7 0x59cff50 0xf0bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 5.7.1 no visual glitch and usually either same as above, or access violating accessing address 001ffffc or (6c4.13b8): Access violation - code c0000005 (first chance) m3core!RTCollector__Move+0x3d: 005beeb4 8b5e00 mov ebx,dword ptr [esi] ds:0023:001ffffc=???????? 0:007> r esi esi=001ffffc 0:007> k ChildEBP RetAddr WARNING: Stack unwind information not available. Following frames may be wrong. 0213e5c0 005badd1 m3core!RTCollector__Move+0x3d 0213e604 005ba6aa m3core!RTHeapMap__Walk+0x467 0213e628 005ba640 m3core!RTHeapMap__DoWalkRef+0x62 0213e654 005c0ab8 m3core!RTHeapMap__WalkRef+0x100 0213e67c 005c092c m3core!RTCollector__CleanBetween+0xdd 0213e6a8 005c0222 m3core!RTCollector__CleanPage+0x5b 0213e6fc 005bfc34 m3core!RTCollector__CollectSomeInStateZero+0x5b2 0213e710 005bf933 m3core!RTCollector__CollectSome+0x6e 0213e740 005c17cb m3core!RTCollector__CollectEnough+0x90 0213e7a0 005b7c23 m3core!RTHeapRep__AllocTraced+0xef 0213e7e4 005b74f8 m3core!RTAllocator__GetOpenArray+0x61 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3ui.dll - 0213e808 00f94c01 m3core!RTHooks__AllocateOpenArray+0x19 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3vbtkit.dll - 0213e85c 00ea330c m3ui!ScrnPixmap__NewRaw+0x16d 0213e898 00ea518b m3vbtkit!Image__InitGray+0x7f 0213e96c 00ea4b8a m3vbtkit!Image__pgm2+0x78 0213ea04 00ec2f4a m3vbtkit!Image__FromRd+0x179 0213ea48 00e93855 m3vbtkit!VBTKitResources__GetPixmap+0x9a 0213ea88 00e91058 m3vbtkit!ScrollerVBTClass__InitGraphics+0x18e *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3formsvbt.dll - 0213eac4 00e43fa2 m3vbtkit!ScrollerVBTClass__Init+0x58 0213ebf4 00e33106 m3formsvbt!FormsVBT__pTextEdit+0x9f5 don't believe that stack much, at least where the offsets are large. There are no symbols, just exports. *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 490 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x25efc5c 0x5d9eae CheckSlot + 0x28 in ..\src\thread\WIN32\ThreadWin32.m3 0x25efca0 0x5da9c8 Fork + 0x298 in ..\src\thread\WIN32\ThreadWin32.m3 0x25efcf0 0xf9240d Mark + 0x383 in ..\src\vbt\VBTRep.m3 0x25efd14 0xf88076 Mark + 0x4b in ..\src\vbt\VBT.m3 0x25efd34 0xfaccfd NewShape + 0xaa in ..\src\split\HVSplit.m3 0x25efd70 0xf87dca NewShape + 0x1d3 in ..\src\vbt\VBT.m3 0x25efd88 0xf8dc63 NewShapeDefault + 0x16 in ..\src\vbt\VBTClass.m3 0x25efdc4 0xf87dca NewShape + 0x1d3 in ..\src\vbt\VBT.m3 0x25efe20 0xfbee4d SetAndAlign + 0x1d1 in ..\src\split\TextVBT.m3 0x25efe38 0xfbf836 Redisplay + 0x15 in ..\src\split\TextVBT.m3 ......... ......... ... more frames ... more commonly accessing 00200000, er, well, notice the offset: (1350.f08): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000005 edx=0060b148 esi=011b8a3c edi=0120dfcc eip=005dabcf esp=0012f964 ebp=0012f98c iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3core.dll - m3core!Thread__Join+0x133: 005dabcf 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> k *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\juno-compiler.dll - ChildEBP RetAddr WARNING: Stack unwind information not available. Following frames may be wrong. 0012f98c 1000e2b1 m3core!Thread__Join+0x133 *** ERROR: Module load completed but symbols could not be loaded for Juno.exe 0012f9d0 0041c7e5 juno_compiler!JunoCompile__ProcDecl+0x1f5 0012fa08 0041d1cf Juno+0x1c7e5 0012fab4 0041d088 Juno+0x1d1cf 0012fae8 0043d425 Juno+0x1d088 0012fb28 0043d61e Juno+0x3d425 0012fbc8 0043df47 Juno+0x3d61e 0012fd70 0044b61e Juno+0x3df47 0012fee0 005c8d14 Juno+0x4b61e 0012ff24 005c82ec m3core!RTLinker__RunMainBody+0x25a 0012ff3c 005c8395 m3core!RTLinker__AddUnitI+0xf7 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 0012ff7c 004b0d74 Juno+0x1038 0012ffc0 7c817077 Juno+0xb0d74 0012fff0 00000000 kernel32!BaseProcessStart+0x23 *** *** runtime error: *** Thread client error: attempt to join with thread twice *** file "..\src\thread\WIN32\ThreadWin32.m3", line 708 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f954 0x5db678 Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 0x12f98c 0x5dab36 Join + 0x9a in ..\src\thread\WIN32\ThreadWin32.m3 0x12f9d0 0x1000e2b1 ProcDecl + 0x1f5 in ..\src\JunoCompile.m3 0x12fa08 0x41c7e5 Pass2 + 0x1a5 in ..\src\Editor.m3 0x12fab4 0x41d1cf Compile2 + 0x137 in ..\src\Editor.m3 0x12fae8 0x41d088 Compile + 0x53 in ..\src\Editor.m3 0x12fb28 0x43d425 CompileEditor + 0x2c in ..\src\Juno.m3 0x12fbc8 0x43d61e CompileModule + 0x12c in ..\src\Juno.m3 0x12fd70 0x43df47 CompileModules + 0x2d3 in ..\src\Juno.m3 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Sep 3 15:44:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 03 Sep 2009 15:44:36 +0200 Subject: [M3devel] some data on Juno crash on Win32 In-Reply-To: References: Message-ID: <20090903154436.w1aooqqaskg4scg4@mail.elegosoft.com> Quoting Jay K : > summary: 5.7.0 and 5.7.1 of unknown date: > > both always fail > > 5.7.0 always fails an assert (various?) > > 5.7.1 sometimes fails an assert (various) > > 5.7.1 sometimes access violates, always on address 00200000, plus or minus 4. > > Current source always access violates, same address. > > Since 5.7.1 and current source always access violate (aka SIGSEGV) > on the same > location, every run, I'm more inclined to look at this. This is all on Windows/NT386, isn't it? Or on POSIX platforms, too? I seem to remember that Juno always crashed on a PaintBrush operation on Windows, while the various mentor applications crashed at different points, but all relating to insufficient Trestle/Win support. On POSIX platforms both applications always ran OK AFAIR. Olaf > And then hope everything else is "the same" problem. > > But of course there might be multiple problems. > > It might be good to check for the hang in various from > http://www.opencm3.net/uploaded-archives/index.html. > > Also see what all we can get from > http://www.opencm3.net/snaps/snapshot-index.html. > > I'm going to see if I can get the index update with the many files I > noticed in the file system. The same file name pattern for all files would help here. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Sep 3 17:44:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Sep 2009 15:44:17 +0000 Subject: [M3devel] This is a pixmap? Message-ID: Does this look like a pixmap to anyone? This is the parameter to Win32 Join. PROCEDURE Join(t: T): REFANY = VAR res: REFANY; BEGIN LOCK threadMu DO IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; WHILE NOT t.completed DO Wait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; t.cond := NIL; IF perfOn THEN PerfChanged(t.id, State.dead) END; END; RETURN res; END Join; Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. t is at @ebp + here. The pointer then is 00200000 at the start of the second line of the second dump. If we can confirm this is pixmap, we can hunt more around in the gui code. 0:000> dd @ebp+8 0012f964 012ac6a8 02827bf4 02827974 02824c3c 0012f974 02829c40 02829c40 0012f98c 00000006 0012f984 011b9838 012ac6a8 0012f9fc 00000004 0012f994 10017170 000001c7 02829c40 0012f9d8 0012f9a4 0041ffea 02824c3c 02827bf4 02827974 0012f9b4 028250b8 02827974 02827904 02824dd8 0012f9c4 02824c3c 02827bf4 02824d9c 02824d9c 0012f9d4 02824dd8 0012fa8c 00420b98 028250b8 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> .lastevent Last event: ee0.13a4: Access violation - code c0000005 (first chance) debugger time: Thu Sep 3 07:43:12.390 2009 (GMT-7) 0:000> u . l1 m3core!Thread__Join+0x173: 005ebb01 8b5ffc mov ebx,dword ptr [edi-4] 0:000> r edi edi=00200000 0:000> Here is the entire bitmappy looking thing. 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> dd 012ac728 00200000 00200000 00200000 00200000 012ac738 00200000 00200000 00200000 00200000 012ac748 00200000 00200000 00200000 00200000 012ac758 00200000 00200000 00200000 00200000 012ac768 00200000 00200000 00200000 00200000 012ac778 00200000 00200000 00200000 00200000 012ac788 00200000 00200000 00200000 00200000 012ac798 00200000 00200000 00200000 00200000 0:000> 012ac7a8 00200000 00200000 00200000 00200000 012ac7b8 00200000 00200000 00200000 00200000 012ac7c8 00200000 00200000 00200000 00200000 012ac7d8 00200000 00200000 00200000 00200000 012ac7e8 00200000 00200000 00200000 00200000 012ac7f8 00200000 00200000 00200000 00200000 012ac808 00200000 00200000 00200000 00200000 012ac818 00200000 00200000 00200000 00200000 0:000> 012ac828 00200000 00200000 00200000 00200000 012ac838 00200000 00200000 00200000 00200000 012ac848 00200000 00200000 00200000 00200000 012ac858 00200000 00200000 00200000 00200000 012ac868 00200000 00200000 00200000 00200000 012ac878 00200000 00200000 00200000 00200000 012ac888 00200000 00200000 00200000 00200000 012ac898 00200000 00200000 00200000 00200000 0:000> 012ac8a8 00200000 00200000 00200000 00200000 012ac8b8 00200000 00200000 00200000 00200000 012ac8c8 00200000 00200000 00200000 00200000 012ac8d8 00200000 00200000 00200000 00200000 012ac8e8 00200000 00200000 00200000 00200000 012ac8f8 00200000 00200000 00200000 00200000 012ac908 00200000 00200000 00200000 00200000 012ac918 00200000 00200000 00200000 00200000 0:000> 012ac928 00200000 00200000 00200000 00200000 012ac938 00200000 00200000 00200000 00200000 012ac948 00200000 00200000 00200000 00200000 012ac958 00200000 00200000 00200000 00200000 012ac968 00200000 00200000 00200000 00200000 012ac978 00200000 00200000 00200000 00200000 012ac988 00200000 00200000 00200000 00200000 012ac998 00200000 00200000 00200000 00200000 0:000> 012ac9a8 00200000 00200000 00200000 00200000 012ac9b8 00200000 00200000 00200000 00200000 012ac9c8 00200000 00200000 00200000 00200000 012ac9d8 00200000 00200000 00200000 00200000 012ac9e8 00200000 00200000 00200000 00200000 012ac9f8 00200000 00200000 00200000 00200000 012aca08 00200000 00200000 00200000 00200000 012aca18 00200000 00200000 00200000 00200000 0:000> 012aca28 00200000 00200000 00200000 00200000 012aca38 00200000 00200000 00200000 00200000 012aca48 00200000 00200000 00200000 00200000 012aca58 00200000 00200000 00200000 00200000 012aca68 00200000 00200000 00200000 00200000 012aca78 00200000 00200000 00200000 00200000 012aca88 00200000 00200000 00200000 00200000 012aca98 00200000 00200000 00200000 00200000 0:000> 012acaa8 00200000 00200000 00200000 00200000 012acab8 00200000 00200000 00200000 00200000 012acac8 00200000 00200000 00200000 00200000 012acad8 00200000 00200000 00200000 00200000 012acae8 00200000 00200000 00200000 00200000 012acaf8 00200000 00200000 00200000 00200000 012acb08 00200000 00200000 00200000 00200000 012acb18 00200000 00200000 00200000 00200000 0:000> 012acb28 00200000 00200000 00200000 00200000 012acb38 00200000 00200000 00200000 00200000 012acb48 00200000 00200000 00200000 00200000 012acb58 00200000 00200000 00200000 00200000 012acb68 00200000 00200000 00200000 00200000 012acb78 00200000 00200000 00200000 00200000 012acb88 00200000 00200000 00200000 00200000 012acb98 00200000 00200000 00200000 00200000 0:000> 012acba8 00200000 00200000 00200000 00200000 012acbb8 00200000 00200000 00200000 00200000 012acbc8 00200000 00200000 00200000 00200000 012acbd8 00200000 00200000 00200000 00200000 012acbe8 00200000 00200000 00200000 00200000 012acbf8 00200000 00200000 00200000 00200000 012acc08 00200000 00200000 00200000 00200000 012acc18 00200000 00200000 00200000 00200000 0:000> 012acc28 00200000 00200000 00200000 00200000 012acc38 00200000 00200000 00200000 00200000 012acc48 00200000 00200000 00200000 00200000 012acc58 00200000 00200000 00200000 00200000 012acc68 00200000 00200000 00200000 00200000 012acc78 00200000 00200000 00200000 00200000 012acc88 00200000 00200000 00200000 00200000 012acc98 00200000 00200000 00200000 00200000 0:000> 012acca8 00200000 00200000 00200000 00200000 012accb8 00200000 00200000 00200000 00200000 012accc8 00200000 00200000 00200000 00200000 012accd8 00200000 00200000 00200000 00200000 012acce8 00200000 00200000 00200000 00200000 012accf8 00200000 00200000 00200000 00200000 012acd08 00200000 00200000 00200000 00200000 012acd18 00200000 00200000 00200000 00200000 0:000> 012acd28 00200000 00200000 00200000 00200000 012acd38 00200000 00200000 00200000 00200000 012acd48 00200000 00200000 00200000 00200000 012acd58 00200000 00200000 00200000 00200000 012acd68 00200000 00200000 00200000 00200000 012acd78 00200000 00200000 00200000 00200000 012acd88 00200000 00200000 00200000 00200000 012acd98 00200000 00200000 00200000 00200000 0:000> 012acda8 00200000 00200000 00200000 00200000 012acdb8 00200000 00200000 00200000 00200000 012acdc8 00200000 00200000 00200000 00200000 012acdd8 00200000 00200000 00200000 00200000 012acde8 00200000 00200000 00200000 00200000 012acdf8 00200000 00200000 00200000 00200000 012ace08 00200000 00200000 00200000 00200000 012ace18 00200000 00200000 00200000 00200000 0:000> 012ace28 00200000 00200000 00200000 00200000 012ace38 00200000 00200000 00200000 00200000 012ace48 00200000 00200000 00200000 00200000 012ace58 00200000 00200000 00200000 00200000 012ace68 00200000 00200000 00200000 00200000 012ace78 00200000 00200000 00200000 00200000 012ace88 00200000 00200000 00200000 00200000 012ace98 00200000 00200000 00200000 00200000 0:000> 012acea8 00200000 00200000 00200000 00200000 012aceb8 00200000 00200000 00200000 00200000 012acec8 00200000 00200000 00200000 00200000 012aced8 00200000 00200000 00200000 00200000 012acee8 00200000 00200000 00200000 00200000 012acef8 00200000 00200000 00200000 00200000 012acf08 00200000 00200000 00200000 00200000 012acf18 00200000 00200000 00200000 00200000 0:000> 012acf28 00200000 00200000 00200000 00200000 012acf38 00200000 00200000 00200000 00200000 012acf48 00200000 00200000 00200000 00200000 012acf58 00200000 00200000 00200000 00200000 012acf68 00200000 00200000 00200000 00200000 012acf78 00200000 00200000 00200000 00200000 012acf88 00200000 00200000 00200000 00200000 012acf98 00200000 00200000 00200000 00200000 0:000> 012acfa8 00200000 00200000 00200000 00200000 012acfb8 00200000 00200000 00200000 00200000 012acfc8 00200000 00200000 00200000 00200000 012acfd8 00200000 00200000 00200000 00200000 012acfe8 00200000 00200000 00200000 00200000 012acff8 00200000 00200000 00200000 00200000 012ad008 00200000 00200000 00200000 00200000 012ad018 00200000 00200000 00200000 00200000 0:000> 012ad028 00200000 00200000 00200000 00200000 012ad038 00200000 00200000 00200000 00200000 012ad048 00200000 00200000 00200000 00200000 012ad058 00200000 00200000 00200000 00200000 012ad068 00200000 00200000 00200000 00200000 012ad078 00200000 00200000 00200000 00200000 012ad088 00200000 00200000 00200000 00200000 012ad098 00200000 00200000 00200000 00200000 0:000> 012ad0a8 00200000 00200000 00200000 00200000 012ad0b8 00200000 00200000 00200000 00200000 012ad0c8 00200000 00200000 00200000 00200000 012ad0d8 00200000 00200000 00200000 00200000 012ad0e8 00200000 00200000 00200000 00200000 012ad0f8 00200000 00200000 00200000 00200000 012ad108 00200000 00200000 00200000 00200000 012ad118 00200000 00200000 00200000 00200000 0:000> 012ad128 00200000 00200000 00200000 00200000 012ad138 00200000 00200000 00200000 00200000 012ad148 00200000 00200000 00200000 00200000 012ad158 00200000 00200000 00200000 00200000 012ad168 00200000 00200000 00200000 00200000 012ad178 00200000 00200000 00200000 00200000 012ad188 00200000 00200000 00200000 00200000 012ad198 00200000 00200000 00200000 00200000 0:000> 012ad1a8 00200000 00200000 00200000 00200000 012ad1b8 00200000 00200000 00200000 00200000 012ad1c8 00200000 00200000 00200000 00200000 012ad1d8 00200000 00200000 00200000 00200000 012ad1e8 00200000 00200000 00200000 00200000 012ad1f8 00200000 00200000 00200000 00200000 012ad208 00200000 00200000 00200000 00200000 012ad218 00200000 00200000 00200000 00200000 0:000> 012ad228 00200000 00200000 00200000 00200000 012ad238 00200000 00200000 00200000 00200000 012ad248 00200000 00200000 00200000 00200000 012ad258 00200000 00200000 00200000 00200000 012ad268 00200000 00200000 00200000 00200000 012ad278 00200000 00200000 00200000 00200000 012ad288 00200000 00200000 00200000 00200000 012ad298 00200000 00200000 00200000 00200000 0:000> 012ad2a8 00200000 00200000 00200000 00200000 012ad2b8 00200000 00200000 00200000 00200000 012ad2c8 00200000 00200000 00200000 00200000 012ad2d8 00200000 00200000 00200000 00200000 012ad2e8 00200000 00200000 00200000 00200000 012ad2f8 00200000 00200000 00200000 00200000 012ad308 00200000 00200000 00200000 00200000 012ad318 00200000 00200000 00200000 00200000 0:000> 012ad328 00200000 00200000 00200000 00200000 012ad338 00200000 00200000 00200000 00200000 012ad348 00200000 00200000 00200000 00200000 012ad358 00200000 00200000 00200000 00200000 012ad368 00200000 00200000 00200000 00200000 012ad378 00200000 00200000 00200000 00200000 012ad388 00200000 00200000 00200000 00200000 012ad398 00200000 00200000 00200000 00200000 0:000> 012ad3a8 00200000 00200000 00200000 00200000 012ad3b8 00200000 00200000 00200000 00200000 012ad3c8 00200000 00200000 00200000 00200000 012ad3d8 00200000 00200000 00200000 00200000 012ad3e8 00200000 00200000 00200000 00200000 012ad3f8 00200000 00200000 00200000 00200000 012ad408 00200000 00200000 00200000 00200000 012ad418 00200000 00200000 00200000 00200000 0:000> 012ad428 00200000 00200000 00200000 00200000 012ad438 00200000 00200000 00200000 00200000 012ad448 00200000 00200000 00200000 00200000 012ad458 00200000 00200000 00200000 00200000 012ad468 00200000 00200000 00200000 00200000 012ad478 00200000 00200000 00200000 00200000 012ad488 00200000 00200000 00200000 00200000 012ad498 00200000 00200000 00200000 00200000 0:000> 012ad4a8 00200000 00200000 00200000 00200000 012ad4b8 00200000 00200000 00200000 00200000 012ad4c8 00200000 00200000 00200000 00200000 012ad4d8 00200000 00200000 00200000 00200000 012ad4e8 00200000 00200000 00200000 00200000 012ad4f8 00200000 00200000 00200000 00200000 012ad508 00200000 00200000 00200000 00200000 012ad518 00200000 00200000 00200000 00200000 0:000> 012ad528 00200000 00200000 00200000 00200000 012ad538 00200000 00200000 00200000 00200000 012ad548 00200000 00200000 00200000 00200000 012ad558 00200000 00200000 00200000 00200000 012ad568 00200000 00200000 00200000 00200000 012ad578 00200000 00200000 00200000 00200000 012ad588 00200000 00200000 00200000 00200000 012ad598 00200000 00200000 00200000 00200000 0:000> 012ad5a8 00200000 00200000 00200000 00200000 012ad5b8 00200000 00200000 00200000 00200000 012ad5c8 00200000 00200000 00200000 00200000 012ad5d8 00200000 00200000 00200000 00200000 012ad5e8 00200000 00200000 00200000 00200000 012ad5f8 00200000 00200000 00200000 00200000 012ad608 00200000 00200000 00200000 00200000 012ad618 00200000 00200000 00200000 00200000 0:000> 012ad628 00200000 00200000 00200000 00200000 012ad638 00200000 00200000 00200000 00200000 012ad648 00200000 00200000 00200000 00200000 012ad658 00200000 00200000 00200000 00200000 012ad668 00200000 00200000 00200000 00200000 012ad678 00200000 00200000 00200000 00200000 012ad688 00200000 00200000 00200000 00200000 012ad698 00200000 00200000 00200000 00200000 0:000> 012ad6a8 00200000 00200000 00200000 00200000 012ad6b8 00200000 00200000 00200000 00200000 012ad6c8 00200000 00200000 00200000 00200000 012ad6d8 00200000 00200000 00200000 00200000 012ad6e8 00200000 00200000 00200000 00200000 012ad6f8 00200000 00200000 00200000 00200000 012ad708 00200000 00200000 00200000 00200000 012ad718 00200000 00200000 00200000 00200000 0:000> 012ad728 00200000 00200000 00200000 00200000 012ad738 00200000 00200000 00200000 00200000 012ad748 00200000 00200000 00200000 00200000 012ad758 00200000 00200000 00200000 00200000 012ad768 00200000 00200000 00200000 00200000 012ad778 00200000 00200000 00200000 00200000 012ad788 00200000 00200000 00200000 00200000 012ad798 00200000 00200000 00200000 00200000 0:000> 012ad7a8 00200000 00200000 00200000 00200000 012ad7b8 00200000 00200000 00200000 00200000 012ad7c8 00200000 00200000 00200000 00200000 012ad7d8 00200000 00200000 00200000 00200000 012ad7e8 00200000 00200000 00200000 00200000 012ad7f8 00200000 00200000 00200000 00200000 012ad808 00200000 00200000 00200000 00200000 012ad818 00200000 00200000 00200000 00200000 0:000> 012ad828 00200000 00200000 00200000 00200000 012ad838 00200000 00200000 00200000 00200000 012ad848 00200000 00200000 00200000 00200000 012ad858 00200000 00200000 00200000 00200000 012ad868 00200000 00200000 00200000 00200000 012ad878 00200000 00200000 00200000 00200000 012ad888 00200000 00200000 00200000 00200000 012ad898 00200000 00200000 00200000 00200000 0:000> 012ad8a8 00200000 00200000 00200000 00200000 012ad8b8 00200000 00200000 00200000 00200000 012ad8c8 00200000 00200000 00200000 00200000 012ad8d8 00200000 00200000 00200000 00200000 012ad8e8 00200000 00200000 00200000 00200000 012ad8f8 00200000 00200000 00200000 00200000 012ad908 00200000 00200000 00200000 00200000 012ad918 00200000 00200000 00200000 00200000 0:000> 012ad928 00200000 00200000 00200000 00200000 012ad938 00200000 00200000 00200000 00200000 012ad948 00200000 00200000 00200000 00200000 012ad958 00200000 00200000 00200000 00200000 012ad968 00200000 00200000 00200000 00200000 012ad978 00200000 00200000 00200000 00200000 012ad988 00200000 00200000 00200000 00200000 012ad998 00200000 00200000 00200000 00200000 0:000> 012ad9a8 00200000 00200000 00200000 00200000 012ad9b8 00200000 00200000 00200000 00200000 012ad9c8 00200000 00200000 00200000 00200000 012ad9d8 00200000 00200000 00200000 00200000 012ad9e8 00200000 00200000 00200000 00200000 012ad9f8 00200000 00200000 00200000 00200000 012ada08 00200000 00200000 00200000 00200000 012ada18 00200000 00200000 00200000 00200000 0:000> 012ada28 00200000 00200000 00200000 00200000 012ada38 00200000 00200000 00200000 00200000 012ada48 00200000 00200000 00200000 00200000 012ada58 00200000 00200000 00200000 00200000 012ada68 00200000 00200000 00200000 00200000 012ada78 00200000 00200000 00200000 00200000 012ada88 00200000 00200000 00200000 00200000 012ada98 00200000 00200000 00200000 00200000 0:000> 012adaa8 00200000 00200000 00200000 00200000 012adab8 00200000 00200000 00200000 00200000 012adac8 00200000 00200000 00200000 00200000 012adad8 00200000 00200000 00200000 00200000 012adae8 00200000 00200000 00200000 00200000 012adaf8 00200000 00200000 00200000 00200000 012adb08 00200000 00200000 00200000 00200000 012adb18 00200000 00200000 00200000 00200000 0:000> 012adb28 00200000 00200000 00200000 00200000 012adb38 00200000 00200000 00200000 00200000 012adb48 00200000 00200000 00200000 00200000 012adb58 00200000 00200000 00200000 00200000 012adb68 00200000 00200000 00200000 00200000 012adb78 00200000 00200000 00200000 00200000 012adb88 00200000 00200000 00200000 00200000 012adb98 00200000 00200000 00200000 00200000 0:000> 012adba8 00200000 00200000 00200000 00200000 012adbb8 00200000 00200000 00200000 00200000 012adbc8 00200000 00200000 00200000 00200000 012adbd8 00200000 00200000 00200000 00200000 012adbe8 00200000 00200000 00200000 00200000 012adbf8 00200000 00200000 00200000 00200000 012adc08 00200000 00200000 00200000 00200000 012adc18 00200000 00200000 00200000 00200000 0:000> 012adc28 00200000 00200000 00200000 00200000 012adc38 00200000 00200000 00200000 00200000 012adc48 00200000 00200000 00200000 00200000 012adc58 00200000 00200000 00200000 00200000 012adc68 00200000 00200000 00200000 00200000 012adc78 00200000 00200000 00200000 00200000 012adc88 00200000 00200000 00200000 00200000 012adc98 00200000 00200000 00200000 00200000 0:000> 012adca8 00200000 00200000 00200000 00200000 012adcb8 00200000 00200000 00200000 00200000 012adcc8 00200000 00200000 00200000 00200000 012adcd8 00200000 00200000 00200000 00200000 012adce8 00200000 00200000 00200000 00200000 012adcf8 00200000 00200000 00200000 00200000 012add08 00200000 00200000 00200000 00200000 012add18 00200000 00200000 00200000 00200000 0:000> 012add28 00200000 00200000 00200000 00200000 012add38 00200000 00200000 00200000 00200000 012add48 00200000 00200000 00200000 00200000 012add58 00200000 00200000 00200000 00200000 012add68 00200000 00200000 00200000 00200000 012add78 00200000 00200000 00200000 00200000 012add88 00200000 00200000 00200000 00200000 012add98 00200000 00200000 00200000 00200000 0:000> 012adda8 00200000 00200000 00200000 00200000 012addb8 00200000 00200000 00200000 00200000 012addc8 00200000 00200000 00200000 00200000 012addd8 00200000 00200000 00200000 00200000 012adde8 00200000 00200000 00200000 00200000 012addf8 00200000 00200000 00200000 00200000 012ade08 00200000 00200000 00200000 00200000 012ade18 00200000 00200000 00200000 00200000 0:000> 012ade28 00200000 00200000 00200000 00200000 012ade38 00200000 00200000 00200000 00200000 012ade48 00200000 00200000 00200000 00200000 012ade58 00200000 00200000 00200000 00200000 012ade68 00200000 00200000 00200000 00200000 012ade78 00200000 00200000 00200000 00200000 012ade88 00200000 00200000 00200000 00200000 012ade98 00200000 00200000 00200000 00200000 0:000> 012adea8 00200000 00200000 00200000 00200000 012adeb8 00200000 00200000 00200000 00200000 012adec8 00200000 00200000 00200000 00200000 012aded8 00200000 00200000 00200000 00200000 012adee8 00200000 00200000 00200000 00200000 012adef8 00200000 00200000 00200000 00200000 012adf08 00200000 00200000 00200000 00200000 012adf18 00200000 00200000 00200000 00200000 0:000> 012adf28 00200000 00200000 00200000 00200000 012adf38 00200000 00200000 00200000 00200000 012adf48 00200000 00200000 00200000 00200000 012adf58 00200000 00200000 00200000 00200000 012adf68 00200000 00200000 00200000 00200000 012adf78 00200000 00200000 00200000 00200000 012adf88 00200000 00200000 00200000 00200000 012adf98 00200000 00200000 00200000 00200000 0:000> 012adfa8 00200000 00200000 00200000 00200000 012adfb8 00200000 00200000 00200000 00200000 012adfc8 00200000 00200000 00200000 00200000 012adfd8 00200000 00200000 00200000 00200000 012adfe8 00200000 00200000 00200000 00200000 012adff8 00200000 00200000 00200000 00200000 012ae008 00200000 00200000 00200000 00200000 012ae018 00200000 00200000 00200000 00200000 0:000> 012ae028 00200000 00200000 00200000 00200000 012ae038 00200000 00200000 00200000 00200000 012ae048 00200000 00200000 00200000 00200000 012ae058 00200000 00200000 00200000 00200000 012ae068 00200000 00200000 00200000 00200000 012ae078 00200000 00200000 00200000 00200000 012ae088 00200000 00200000 00200000 00200000 012ae098 00200000 00200000 00200000 00200000 0:000> 012ae0a8 00200000 00200000 00200000 00200000 012ae0b8 00200000 00200000 00200000 00200000 012ae0c8 00200000 00200000 00200000 00200000 012ae0d8 00200000 00200000 00200000 00200000 012ae0e8 00200000 00200000 00200000 00200000 012ae0f8 00200000 00200000 00200000 00200000 012ae108 00200000 00200000 00200000 00200000 012ae118 00200000 00200000 00200000 00200000 0:000> 012ae128 00200000 00200000 00200000 00200000 012ae138 00200000 00200000 00200000 00200000 012ae148 00200000 00200000 00200000 00200000 012ae158 00200000 00200000 00200000 00200000 012ae168 00200000 00200000 00200000 00200000 012ae178 00200000 00200000 00200000 00200000 012ae188 00200000 00200000 00200000 00200000 012ae198 00200000 00200000 00200000 00200000 0:000> 012ae1a8 00200000 00200000 00200000 00200000 012ae1b8 00200000 00200000 00200000 00200000 012ae1c8 00200000 00200000 00200000 00200000 012ae1d8 00200000 00200000 00200000 00200000 012ae1e8 00200000 00200000 00200000 00200000 012ae1f8 00200000 00200000 00200000 00200000 012ae208 00200000 00200000 00200000 00200000 012ae218 00200000 00200000 00200000 00200000 0:000> 012ae228 00200000 00200000 00200000 00200000 012ae238 00200000 00200000 00200000 00200000 012ae248 00200000 00200000 00200000 00200000 012ae258 00200000 00200000 00200000 00200000 012ae268 00200000 00200000 00200000 00200000 012ae278 00200000 00200000 00200000 00200000 012ae288 00200000 00200000 00200000 00200000 012ae298 00200000 00200000 00200000 00200000 0:000> 012ae2a8 00200000 00200000 00200000 00200000 012ae2b8 00200000 00200000 00200000 00200000 012ae2c8 00200000 00200000 00200000 00200000 012ae2d8 00200000 00200000 00200000 00200000 012ae2e8 00200000 00200000 00200000 00200000 012ae2f8 00200000 00200000 00200000 00200000 012ae308 00200000 00200000 00200000 00200000 012ae318 00200000 00200000 00200000 00200000 0:000> 012ae328 00200000 00200000 00200000 00200000 012ae338 00200000 00200000 00200000 00200000 012ae348 00200000 00200000 00200000 00200000 012ae358 00200000 00200000 00200000 00200000 012ae368 00200000 00200000 00200000 00200000 012ae378 00200000 00200000 00200000 00200000 012ae388 00200000 00200000 00200000 00200000 012ae398 00200000 00200000 00200000 00200000 0:000> 012ae3a8 00200000 00200000 00200000 00200000 012ae3b8 00200000 00200000 00200000 00200000 012ae3c8 00200000 00200000 00200000 00200000 012ae3d8 00200000 00200000 00200000 00200000 012ae3e8 00200000 00200000 00200000 00200000 012ae3f8 00200000 00200000 00200000 00200000 012ae408 00200000 00200000 00200000 00200000 012ae418 00200000 00200000 00200000 00200000 0:000> 012ae428 00200000 00200000 00200000 00200000 012ae438 00200000 00200000 00200000 00200000 012ae448 00200000 00200000 00200000 00200000 012ae458 00200000 00200000 00200000 00200000 012ae468 00200000 00200000 00200000 00200000 012ae478 00200000 00200000 00200000 00200000 012ae488 00200000 00200000 00200000 00200000 012ae498 00200000 00200000 00200000 00200000 0:000> 012ae4a8 00200000 00200000 00200000 00200000 012ae4b8 00200000 00200000 00200000 00200000 012ae4c8 00200000 00200000 00200000 00200000 012ae4d8 00200000 00200000 00200000 00200000 012ae4e8 00200000 00200000 00200000 00200000 012ae4f8 00200000 00200000 00200000 00200000 012ae508 00200000 00200000 00200000 00200000 012ae518 00200000 00200000 00200000 00200000 0:000> 012ae528 00200000 00200000 00200000 00200000 012ae538 00200000 00200000 00200000 00200000 012ae548 00200000 00200000 00200000 00200000 012ae558 00200000 00200000 00200000 00200000 012ae568 00200000 00200000 00200000 00200000 012ae578 00200000 00200000 00200000 00200000 012ae588 00200000 00200000 00200000 00200000 012ae598 00200000 00200000 00200000 00200000 0:000> 012ae5a8 00200000 00200000 00200000 00200000 012ae5b8 00200000 00200000 00200000 00200000 012ae5c8 00200000 00200000 00200000 00200000 012ae5d8 00200000 00200000 00200000 00200000 012ae5e8 00200000 00200000 00200000 00200000 012ae5f8 00200000 00200000 00200000 00200000 012ae608 00200000 00200000 00200000 00200000 012ae618 00200000 00200000 00200000 00200000 0:000> 012ae628 00200000 00200000 00200000 00200000 012ae638 00200000 00200000 00200000 00200000 012ae648 00200000 00200000 00200000 00200000 012ae658 00200000 00200000 00200000 00200000 012ae668 00200000 00200000 00200000 00200000 012ae678 00200000 00200000 00200000 00200000 012ae688 00200000 00200000 00200000 00200000 012ae698 00200000 00200000 00200000 00200000 0:000> 012ae6a8 00200000 00200000 00200000 00200000 012ae6b8 00200000 00200000 00200000 00200000 012ae6c8 00200000 00200000 00200000 00200000 012ae6d8 00200000 00200000 00200000 00200000 012ae6e8 00200000 00200000 00200000 00200000 012ae6f8 00200000 00200000 00200000 00200000 012ae708 00200000 00200000 00200000 00200000 012ae718 00200000 00200000 00200000 00200000 0:000> 012ae728 00200000 00200000 00200000 00200000 012ae738 00200000 00200000 00200000 00200000 012ae748 00200000 00200000 00200000 00200000 012ae758 00200000 00200000 00200000 00200000 012ae768 00200000 00200000 00200000 00200000 012ae778 00200000 00200000 00200000 00200000 012ae788 00200000 00200000 00200000 00200000 012ae798 00200000 00200000 00200000 00200000 0:000> 012ae7a8 00200000 00200000 00200000 00200000 012ae7b8 00200000 00200000 00200000 00200000 012ae7c8 00200000 00200000 00200000 00200000 012ae7d8 00200000 00200000 00200000 00200000 012ae7e8 00200000 00200000 00200000 00200000 012ae7f8 00200000 00200000 00200000 00200000 012ae808 00200000 00200000 00200000 00200000 012ae818 00200000 00200000 00200000 00200000 0:000> 012ae828 00200000 00200000 00200000 00200000 012ae838 00200000 00200000 00200000 00200000 012ae848 00200000 00200000 00200000 00200000 012ae858 00200000 00200000 00200000 00200000 012ae868 00200000 00200000 00200000 00200000 012ae878 00200000 00200000 00200000 00200000 012ae888 00200000 00200000 00200000 00200000 012ae898 00200000 00200000 00200000 00200000 0:000> 012ae8a8 00200000 00200000 00200000 00200000 012ae8b8 00200000 00200000 00200000 00200000 012ae8c8 00200000 00200000 00200000 00200000 012ae8d8 00200000 00200000 00200000 00200000 012ae8e8 00200000 00200000 00200000 00200000 012ae8f8 00200000 00200000 00200000 00200000 012ae908 00200000 00200000 00200000 00200000 012ae918 00200000 00200000 00200000 00200000 0:000> 012ae928 00200000 00200000 00200000 00200000 012ae938 00200000 00200000 00200000 00200000 012ae948 00200000 00200000 00200000 00200000 012ae958 00200000 00200000 00200000 00200000 012ae968 00200000 00200000 00200000 00200000 012ae978 00200000 00200000 00200000 00200000 012ae988 00200000 00200000 00200000 00200000 012ae998 00200000 00200000 00200000 00200000 0:000> 012ae9a8 00200000 00200000 00200000 00200000 012ae9b8 00200000 00200000 00200000 00200000 012ae9c8 00200000 00200000 00200000 00200000 012ae9d8 00200000 00200000 00200000 00200000 012ae9e8 00200000 00200000 00200000 00200000 012ae9f8 00200000 00200000 00200000 00200000 012aea08 00200000 00200000 00200000 00200000 012aea18 00200000 00200000 00200000 00200000 0:000> 012aea28 00200000 00200000 00200000 00200000 012aea38 00200000 00200000 00200000 00200000 012aea48 00200000 00200000 00200000 00200000 012aea58 00200000 00200000 00200000 00200000 012aea68 00200000 00200000 00200000 00200000 012aea78 00200000 00200000 00200000 00200000 012aea88 00200000 00200000 00200000 00200000 012aea98 00200000 00200000 00200000 00200000 0:000> 012aeaa8 00200000 00200000 00200000 00200000 012aeab8 00200000 00200000 00200000 00200000 012aeac8 00200000 00200000 00200000 00200000 012aead8 00200000 00200000 00200000 00200000 012aeae8 00200000 00200000 00200000 00200000 012aeaf8 00200000 00200000 00200000 00200000 012aeb08 00200000 00200000 00200000 00200000 012aeb18 00200000 00200000 00200000 00200000 0:000> 012aeb28 00200000 00200000 00200000 00200000 012aeb38 00200000 00200000 00200000 00200000 012aeb48 00200000 00200000 00200000 00200000 012aeb58 00200000 00200000 00200000 00200000 012aeb68 00200000 00200000 00200000 00200000 012aeb78 00200000 00200000 00200000 00200000 012aeb88 00200000 00200000 00200000 00200000 012aeb98 00200000 00200000 00200000 00200000 0:000> 012aeba8 00200000 00200000 00200000 00200000 012aebb8 00200000 00200000 00200000 00200000 012aebc8 00200000 00200000 00200000 00200000 012aebd8 00200000 00200000 00200000 00200000 012aebe8 00200000 00200000 00200000 00200000 012aebf8 00200000 00200000 00200000 00200000 012aec08 00200000 00200000 00200000 00200000 012aec18 00200000 00200000 00200000 00200000 0:000> 012aec28 00200000 00200000 00200000 00200000 012aec38 00200000 00200000 00200000 00200000 012aec48 00200000 00200000 00200000 00200000 012aec58 00200000 00200000 00200000 00200000 012aec68 00200000 00200000 00200000 00200000 012aec78 00200000 00200000 00200000 00200000 012aec88 00200000 00200000 00200000 00200000 012aec98 00200000 00200000 00200000 00200000 0:000> 012aeca8 00200000 00200000 00200000 00200000 012aecb8 00200000 00200000 00200000 00200000 012aecc8 00200000 00200000 00200000 00200000 012aecd8 00200000 00200000 00200000 00200000 012aece8 00200000 00200000 00200000 00200000 012aecf8 00200000 00200000 00200000 00200000 012aed08 00200000 00200000 00200000 00200000 012aed18 00200000 00200000 00200000 00200000 0:000> 012aed28 00200000 00200000 00200000 00200000 012aed38 00200000 00200000 00200000 00200000 012aed48 00200000 00200000 00200000 00200000 012aed58 00200000 00200000 00200000 00200000 012aed68 00200000 00200000 00200000 00200000 012aed78 00200000 00200000 00200000 00200000 012aed88 00200000 00200000 00200000 00200000 012aed98 00200000 00200000 00200000 00200000 0:000> 012aeda8 00200000 00200000 00200000 00200000 012aedb8 00200000 00200000 00200000 00200000 012aedc8 00200000 00200000 00200000 00200000 012aedd8 00200000 00200000 00200000 00200000 012aede8 00200000 00200000 00200000 00200000 012aedf8 00200000 00200000 00200000 00200000 012aee08 00200000 00200000 00200000 00200000 012aee18 00200000 00200000 00200000 00200000 0:000> 012aee28 00200000 00200000 00200000 00200000 012aee38 00200000 00200000 00200000 00200000 012aee48 00200000 00200000 00200000 00200000 012aee58 00200000 00200000 00200000 00200000 012aee68 00200000 00200000 00200000 00200000 012aee78 00200000 00200000 00200000 00200000 012aee88 00200000 00200000 00200000 00200000 012aee98 00200000 00200000 00200000 00200000 0:000> 012aeea8 00200000 00200000 00200000 00200000 012aeeb8 00200000 00200000 00200000 00200000 012aeec8 00200000 00200000 00200000 00200000 012aeed8 00200000 00200000 00200000 00200000 012aeee8 00200000 00200000 00200000 00200000 012aeef8 00200000 00200000 00200000 00200000 012aef08 00200000 00200000 00200000 00200000 012aef18 00200000 00200000 00200000 00200000 0:000> 012aef28 00200000 00200000 00200000 00200000 012aef38 00200000 00200000 00200000 00200000 012aef48 00200000 00200000 00200000 00200000 012aef58 00200000 00200000 00200000 00200000 012aef68 00200000 00200000 00200000 00200000 012aef78 00200000 00200000 00200000 00200000 012aef88 00200000 00200000 00200000 00200000 012aef98 00200000 00200000 00200000 00200000 0:000> 012aefa8 00200000 00200000 00200000 00200000 012aefb8 00200000 00200000 00200000 00200000 012aefc8 00200000 00200000 00200000 00200000 012aefd8 00200000 00200000 00200000 00200000 012aefe8 00200000 00200000 00200000 00200000 012aeff8 00200000 00200000 00200000 00200000 012af008 00200000 00200000 00200000 00200000 012af018 00200000 00200000 00200000 00200000 0:000> 012af028 00200000 00200000 00200000 00200000 012af038 00200000 00200000 00200000 00200000 012af048 00200000 00200000 00200000 00200000 012af058 00200000 00200000 00200000 00200000 012af068 00200000 00200000 00200000 00200000 012af078 00200000 00200000 00200000 00200000 012af088 00200000 00200000 00200000 00200000 012af098 00200000 00200000 00200000 00200000 0:000> 012af0a8 00200000 00200000 00200000 00200000 012af0b8 00200000 00200000 00200000 00200000 012af0c8 00200000 00200000 00200000 00200000 012af0d8 00200000 00200000 00200000 00200000 012af0e8 00200000 00200000 00200000 00200000 012af0f8 00200000 00200000 00200000 00200000 012af108 00200000 00200000 00200000 00200000 012af118 00200000 00200000 00200000 00200000 0:000> 012af128 00200000 00200000 00200000 00200000 012af138 00200000 00200000 00200000 00200000 012af148 00200000 00200000 00200000 00200000 012af158 00200000 00200000 00200000 00200000 012af168 00200000 00200000 00200000 00200000 012af178 00200000 00200000 00200000 00200000 012af188 00200000 00200000 00200000 00200000 012af198 00200000 00200000 00200000 00200000 0:000> 012af1a8 00200000 00200000 00200000 00200000 012af1b8 00200000 00200000 00200000 00200000 012af1c8 00200000 00200000 00200000 00200000 012af1d8 00200000 00200000 00200000 00200000 012af1e8 00200000 00200000 00200000 00200000 012af1f8 00200000 00200000 00200000 00200000 012af208 00200000 00200000 00200000 00200000 012af218 00200000 00200000 00200000 00200000 0:000> 012af228 00200000 00200000 00200000 00200000 012af238 00200000 00200000 00200000 00200000 012af248 00200000 00200000 00200000 00200000 012af258 00200000 00200000 00200000 00200000 012af268 00200000 00200000 00200000 00200000 012af278 00200000 00200000 00200000 00200000 012af288 00200000 00200000 00200000 00200000 012af298 00200000 00200000 00200000 00200000 0:000> 012af2a8 00200000 00200000 00200000 00200000 012af2b8 00200000 00200000 00200000 00200000 012af2c8 00200000 00200000 00200000 00200000 012af2d8 00200000 00200000 00200000 00200000 012af2e8 00200000 00200000 00200000 00200000 012af2f8 00200000 00200000 00200000 00200000 012af308 00200000 00200000 00200000 00200000 012af318 00200000 00200000 00200000 00200000 0:000> 012af328 00200000 00200000 00200000 00200000 012af338 00200000 00200000 00200000 00200000 012af348 00200000 00200000 00200000 00200000 012af358 00200000 00200000 00200000 00200000 012af368 00200000 00200000 00200000 00200000 012af378 00200000 00200000 00200000 00200000 012af388 00200000 00200000 00200000 00200000 012af398 00200000 00200000 00200000 00200000 0:000> 012af3a8 00200000 00200000 00200000 00200000 012af3b8 00200000 00200000 00200000 00200000 012af3c8 00200000 00200000 00200000 00200000 012af3d8 00200000 00200000 00200000 00200000 012af3e8 00200000 00200000 00200000 00200000 012af3f8 00200000 00200000 00200000 00200000 012af408 00200000 00200000 00200000 00200000 012af418 00200000 00200000 00200000 00200000 0:000> 012af428 00200000 00200000 00200000 00200000 012af438 00200000 00200000 00200000 00200000 012af448 00200000 00200000 00200000 00200000 012af458 00200000 00200000 00200000 00200000 012af468 00200000 00200000 00200000 00200000 012af478 00200000 00200000 00200000 00200000 012af488 00200000 00200000 00200000 00200000 012af498 00200000 00200000 00200000 00200000 0:000> 012af4a8 00200000 00200000 00200000 00200000 012af4b8 00200000 00200000 00200000 00200000 012af4c8 00200000 00200000 00200000 00200000 012af4d8 00200000 00200000 00200000 00200000 012af4e8 00200000 00200000 00200000 00200000 012af4f8 00200000 00200000 00200000 00200000 012af508 00200000 00200000 00200000 00200000 012af518 00200000 00200000 00200000 00200000 0:000> 012af528 00200000 00200000 00200000 00200000 012af538 00200000 00200000 00200000 00200000 012af548 00200000 00200000 00200000 00200000 012af558 00200000 00200000 00200000 00200000 012af568 00200000 00200000 00200000 00200000 012af578 00200000 00200000 00200000 00200000 012af588 00200000 00200000 00200000 00200000 012af598 00200000 00200000 00200000 00200000 0:000> 012af5a8 00200000 00200000 00200000 00200000 012af5b8 00200000 00200000 00200000 00200000 012af5c8 00200000 00200000 00200000 00200000 012af5d8 00200000 00200000 00200000 00200000 012af5e8 00200000 00200000 00200000 00200000 012af5f8 00200000 00200000 00200000 00200000 012af608 00200000 00200000 00200000 00200000 012af618 00200000 00200000 00200000 00200000 0:000> 012af628 00200000 00200000 00200000 00200000 012af638 00200000 00200000 00200000 00200000 012af648 00200000 00200000 00200000 00200000 012af658 00200000 00200000 00200000 00200000 012af668 00200000 00200000 00200000 00200000 012af678 00200000 00200000 00200000 00200000 012af688 00200000 00200000 00200000 00200000 012af698 00200000 00200000 00200000 00200000 0:000> 012af6a8 00200000 00200000 00200000 00200000 012af6b8 00200000 00200000 00200000 00200000 012af6c8 00200000 00200000 00200000 00200000 012af6d8 00200000 00200000 00200000 00200000 012af6e8 00200000 00200000 00200000 00200000 012af6f8 00200000 00200000 00200000 00200000 012af708 00200000 00200000 00200000 00200000 012af718 00200000 00200000 00200000 00200000 0:000> 012af728 00200000 00200000 00200000 00200000 012af738 00200000 00200000 00200000 00200000 012af748 00200000 00200000 00200000 00200000 012af758 00200000 00200000 00200000 00200000 012af768 00200000 00200000 00200000 00200000 012af778 00200000 00200000 00200000 00200000 012af788 00200000 00200000 00200000 00200000 012af798 00200000 00200000 00200000 00200000 0:000> 012af7a8 00200000 00200000 00200000 00200000 012af7b8 00200000 00200000 00200000 00200000 012af7c8 00200000 00200000 00200000 00200000 012af7d8 00200000 00200000 00200000 00200000 012af7e8 00200000 00200000 00200000 00200000 012af7f8 00200000 00200000 00200000 00200000 012af808 00200000 00200000 00200000 00200000 012af818 00200000 00200000 00200000 00200000 0:000> 012af828 00200000 00200000 00200000 00200000 012af838 00200000 00200000 00200000 00200000 012af848 00200000 00200000 00200000 00200000 012af858 00200000 00200000 00200000 00200000 012af868 00200000 00200000 00200000 00200000 012af878 00200000 00200000 00200000 00200000 012af888 00200000 00200000 00200000 00200000 012af898 00200000 00200000 00200000 00200000 0:000> 012af8a8 00200000 00200000 00200000 00200000 012af8b8 00200000 00200000 00200000 00200000 012af8c8 00200000 00200000 00200000 00200000 012af8d8 00200000 00200000 00200000 00200000 012af8e8 00200000 00200000 00200000 00200000 012af8f8 00200000 00200000 00200000 00200000 012af908 00200000 00200000 00200000 00200000 012af918 00200000 00200000 00200000 00200000 0:000> 012af928 00200000 00200000 00200000 00200000 012af938 00200000 00200000 00200000 00200000 012af948 00200000 00200000 00200000 00200000 012af958 00200000 00200000 00200000 00200000 012af968 00200000 00200000 00200000 00200000 012af978 00200000 00200000 00200000 00200000 012af988 00200000 00200000 00200000 00200000 012af998 00200000 00200000 00200000 00200000 0:000> 012af9a8 00200000 00200000 00200000 00200000 012af9b8 00200000 00200000 00200000 00200000 012af9c8 00200000 00200000 00200000 00200000 012af9d8 00200000 00200000 00200000 00200000 012af9e8 00200000 00200000 00200000 00200000 012af9f8 00200000 00200000 00200000 00200000 012afa08 00200000 00200000 00200000 00200000 012afa18 00200000 00200000 00200000 00200000 0:000> 012afa28 00200000 00200000 00200000 00200000 012afa38 00200000 00200000 00200000 00200000 012afa48 00200000 00200000 00200000 00200000 012afa58 00200000 00200000 00200000 00200000 012afa68 00200000 00200000 00200000 00200000 012afa78 00200000 00200000 00200000 00200000 012afa88 00200000 00200000 00200000 00200000 012afa98 00200000 00200000 00200000 00200000 0:000> 012afaa8 00200000 00200000 00200000 00200000 012afab8 00200000 00200000 00200000 00200000 012afac8 00200000 00200000 00200000 00200000 012afad8 00200000 00200000 00200000 00200000 012afae8 00200000 00200000 00200000 00200000 012afaf8 00200000 00200000 00200000 00200000 012afb08 00200000 00200000 00200000 00200000 012afb18 00200000 00200000 00200000 00200000 0:000> 012afb28 00200000 00200000 00200000 00200000 012afb38 00200000 00200000 00200000 00200000 012afb48 00200000 00200000 00200000 00200000 012afb58 00200000 00200000 00200000 00200000 012afb68 00200000 00200000 00200000 00200000 012afb78 00200000 00200000 00200000 00200000 012afb88 00200000 00200000 00200000 00200000 012afb98 00200000 00200000 00200000 00200000 0:000> 012afba8 00200000 00200000 00200000 00200000 012afbb8 00200000 00200000 00200000 00200000 012afbc8 00200000 00200000 00200000 00200000 012afbd8 00200000 00200000 00200000 00200000 012afbe8 00200000 00200000 00200000 00200000 012afbf8 00200000 00200000 00200000 00200000 012afc08 00200000 00200000 00200000 00200000 012afc18 00200000 00200000 00200000 00200000 0:000> 012afc28 00200000 00200000 00200000 00200000 012afc38 00200000 00200000 00200000 00200000 012afc48 00200000 00200000 00200000 00200000 012afc58 00200000 00200000 00200000 00200000 012afc68 00200000 00200000 00200000 00200000 012afc78 00200000 00200000 00200000 00200000 012afc88 00200000 00200000 00200000 00200000 012afc98 00200000 00200000 00200000 00200000 0:000> 012afca8 00200000 00200000 00200000 00200000 012afcb8 00200000 00200000 00200000 00200000 012afcc8 00200000 00200000 00200000 00200000 012afcd8 00200000 00200000 00200000 00200000 012afce8 00200000 00200000 00200000 00200000 012afcf8 00200000 00200000 00200000 00200000 012afd08 00200000 00200000 00200000 00200000 012afd18 00200000 00200000 00200000 00200000 0:000> 012afd28 00200000 00200000 00200000 00200000 012afd38 00200000 00200000 00200000 00200000 012afd48 00200000 00200000 00200000 00200000 012afd58 00200000 00200000 00200000 00200000 012afd68 00200000 00200000 00200000 00200000 012afd78 00200000 00200000 00200000 00200000 012afd88 00200000 00200000 00200000 00200000 012afd98 00200000 00200000 00200000 00200000 0:000> 012afda8 00200000 00200000 00200000 00200000 012afdb8 00200000 00200000 00200000 00200000 012afdc8 00200000 00200000 00200000 00200000 012afdd8 00200000 00200000 00200000 00200000 012afde8 00200000 00200000 00200000 00200000 012afdf8 00200000 00200000 00200000 00200000 012afe08 00200000 00200000 00200000 00200000 012afe18 00200000 00200000 00200000 00200000 0:000> 012afe28 00200000 00200000 00200000 00200000 012afe38 00200000 00200000 00200000 00200000 012afe48 00200000 00200000 00200000 00200000 012afe58 00200000 00200000 00200000 00200000 012afe68 00200000 00200000 00200000 00200000 012afe78 00200000 00200000 00200000 00200000 012afe88 00200000 00200000 00200000 00200000 012afe98 00200000 00200000 00200000 00200000 0:000> 012afea8 00200000 00200000 00200000 00200000 012afeb8 00200000 00200000 00200000 00200000 012afec8 00200000 00200000 00200000 00200000 012afed8 00200000 00200000 00200000 00200000 012afee8 00200000 00200000 00200000 00200000 012afef8 00200000 00200000 00200000 00200000 012aff08 00200000 00200000 00200000 00200000 012aff18 00200000 00200000 00200000 00200000 0:000> 012aff28 00200000 00200000 00200000 00200000 012aff38 00200000 00200000 00200000 00200000 012aff48 00200000 00200000 00200000 00200000 012aff58 00200000 00200000 00200000 00200000 012aff68 00200000 00200000 00200000 00200000 012aff78 00200000 00200000 00200000 00200000 012aff88 00200000 00200000 00200000 00200000 012aff98 00200000 00200000 00200000 00200000 0:000> 012affa8 00200000 00200000 00200000 00200000 012affb8 00200000 00200000 00200000 00200000 012affc8 00200000 00200000 00200000 00200000 012affd8 00200000 00200000 00200000 00200000 012affe8 00200000 00200000 00200000 00200000 012afff8 00200000 00200000 00000013 00000001 012b0008 00200026 012b0014 0000172e 00000000 012b0018 00000000 00000000 00000000 00000000 0:000> 012b0028 00000000 00000000 00000000 00000000 012b0038 00000000 00000000 00000000 00000000 012b0048 00000000 00000000 00000000 00000000 012b0058 00000000 00000000 00000000 00000000 012b0068 00000000 00000000 00000000 00000000 012b0078 00000000 00000000 00000000 00000000 012b0088 00000000 00000000 00000000 00000000 012b0098 00000000 00000000 00000000 00000000 0:000> 012b00a8 00000000 00000000 00000000 00000000 012b00b8 00000000 00000000 00000000 00000000 012b00c8 00000000 00000000 00000000 00000000 012b00d8 00000000 00000000 00000000 00000000 012b00e8 00000000 00000000 00000000 00000000 012b00f8 00000000 00000000 00000000 00000000 012b0108 00000000 00000000 00000000 00000000 012b0118 00000000 00000000 00000000 00000000 0:000> 012b0128 00000000 00000000 00000000 00000000 012b0138 00000000 00000000 00000000 00000000 012b0148 00000000 00000000 00000000 00000000 012b0158 00000000 00000000 00000000 00000000 012b0168 00000000 00000000 00000000 00000000 012b0178 00000000 00000000 00000000 00000000 012b0188 00000000 00000000 00000000 00000000 012b0198 00000000 00000000 00000000 00000000 0:000> 012b01a8 00000000 00000000 00000000 00000000 012b01b8 00000000 00000000 00000000 00000000 012b01c8 00000000 00000000 00000000 00000000 012b01d8 00000000 00000000 00000000 00000000 012b01e8 00000000 00000000 00000000 00000000 012b01f8 00000000 00000000 00000000 00000000 012b0208 00000000 00000000 00000000 00000000 012b0218 00000000 00000000 00000000 00000000 0:000> 012b0228 00000000 00000000 00000000 00000000 012b0238 00000000 00000000 00000000 00000000 012b0248 00000000 00000000 00000000 00000000 012b0258 00000000 00000000 00000000 00000000 012b0268 00000000 00000000 00000000 00000000 012b0278 00000000 00000000 00000000 00000000 012b0288 00000000 00000000 00000000 00000000 012b0298 00000000 00000000 00000000 00000000 0:000> 012b02a8 00000000 00000000 00000000 00000000 012b02b8 00000000 00000000 00000000 00000000 012b02c8 00000000 00000000 00000000 00000000 012b02d8 00000000 00000000 00000000 00000000 012b02e8 00000000 00000000 00000000 00000000 012b02f8 00000000 00000000 00000000 00000000 012b0308 00000000 00000000 00000000 00000000 012b0318 00000000 00000000 00000000 00000000 0:000> 012b0328 00000000 00000000 00000000 00000000 012b0338 00000000 00000000 00000000 00000000 012b0348 00000000 00000000 55000000 55005500 012b0358 55005500 55005500 55005500 55005500 012b0368 55005500 55005500 55005500 55005500 012b0378 55005500 55005500 55005500 55005500 012b0388 55005500 55005500 55005500 55005500 012b0398 55005500 55005500 55005500 55005500 0:000> 012b03a8 55005500 55005500 55005500 55005500 012b03b8 55005500 55005500 55005500 55005500 012b03c8 55005500 55005500 55005500 55005500 012b03d8 55005500 55005500 55005500 55005500 012b03e8 55005500 55005500 55005500 55005500 012b03f8 55005500 55005500 55005500 55005500 012b0408 55005500 55005500 55005500 55005500 012b0418 55005500 55005500 55005500 55005500 0:000> 012b0428 55005500 55005500 55005500 55005500 012b0438 55005500 55005500 55005500 55005500 012b0448 55005500 55005500 55005500 55005500 012b0458 55005500 55005500 00000000 55000000 012b0468 55000055 55000055 55000055 55000055 012b0478 55000055 55000055 55000055 55000055 012b0488 55000055 55000055 55000055 55000055 012b0498 55000055 55000055 55000055 55000055 0:000> 012b04a8 55000055 55000055 55000055 55000055 012b04b8 55000055 55000055 55000055 55000055 012b04c8 55000055 55000055 55000055 55000055 012b04d8 55000055 55000055 55000055 55000055 012b04e8 55000055 55000055 55000055 55000055 012b04f8 55000055 55000055 55000055 55000055 012b0508 55000055 55000055 55000055 55000055 012b0518 55000055 55000055 55000055 55000055 0:000> 012b0528 55000055 55000055 55000055 55000055 012b0538 55000055 55000055 55000055 55000055 012b0548 55000055 55000055 55000055 55000055 012b0558 55000055 55000055 55000055 55000055 012b0568 55000055 55000055 55000055 00000000 012b0578 00000000 00555555 00555555 00555555 012b0588 00555555 00555555 00555555 00555555 012b0598 00555555 00555555 00555555 00555555 0:000> 012b05a8 00555555 00555555 00555555 00555555 012b05b8 00555555 00555555 00555555 00555555 012b05c8 00555555 00555555 00555555 00555555 012b05d8 00555555 00555555 00555555 00555555 012b05e8 00555555 00555555 00555555 00555555 012b05f8 00555555 00555555 00555555 00555555 012b0608 00555555 00555555 00555555 00555555 012b0618 00555555 00555555 00555555 00555555 0:000> 012b0628 00555555 00555555 00555555 00555555 012b0638 00555555 00555555 00555555 00555555 012b0648 00555555 00555555 00555555 00555555 012b0658 00555555 00555555 00555555 00555555 012b0668 00555555 00555555 00555555 00555555 012b0678 00555555 00555555 00555555 00555555 012b0688 00000000 55000000 55005500 55005500 012b0698 55005500 55005500 55005500 55005500 0:000> 012b06a8 55005500 55005500 55005500 55005500 012b06b8 55005500 55005500 55005500 55005500 012b06c8 55005500 55005500 55005500 55005500 012b06d8 55005500 55005500 55005500 55005500 012b06e8 55005500 55005500 55005500 55005500 012b06f8 55005500 55005500 55005500 55005500 012b0708 55005500 55005500 55005500 55005500 012b0718 55005500 55005500 55005500 55005500 0:000> 012b0728 55005500 55005500 55005500 55005500 012b0738 55005500 55005500 55005500 55005500 012b0748 55005500 55005500 55005500 55005500 012b0758 55005500 55005500 55005500 55005500 012b0768 55005500 55005500 55005500 55005500 012b0778 55005500 55005500 55005500 55005500 012b0788 55005500 55005500 55005500 55005500 012b0798 55005500 00000000 00000000 00555500 0:000> 012b07a8 00555500 00555500 00555500 00555500 012b07b8 00555500 00555500 00555500 00555500 012b07c8 00555500 00555500 00555500 00555500 012b07d8 00555500 00555500 00555500 00555500 012b07e8 00555500 00555500 00555500 00555500 012b07f8 00555500 00555500 00555500 00555500 012b0808 00555500 00555500 00555500 00555500 012b0818 00555500 00555500 00555500 00555500 0:000> 012b0828 00555500 00555500 00555500 00555500 012b0838 00555500 00555500 00555500 00555500 012b0848 00555500 00555500 00555500 00555500 012b0858 00555500 00555500 00555500 00555500 012b0868 00555500 00555500 00555500 00555500 012b0878 00555500 00555500 00555500 00555500 012b0888 00555500 00555500 00555500 00555500 012b0898 00555500 00555500 00555500 00555500 0:000> 012b08a8 00555500 00555500 00000000 55000000 012b08b8 55550055 55550055 55550055 55550055 012b08c8 55550055 55550055 55550055 55550055 012b08d8 55550055 55550055 55550055 55550055 012b08e8 55550055 55550055 55550055 55550055 012b08f8 55550055 55550055 55550055 55550055 012b0908 55550055 55550055 55550055 55550055 012b0918 55550055 55550055 55550055 55550055 0:000> 012b0928 55550055 55550055 55550055 55550055 012b0938 55550055 55550055 55550055 55550055 012b0948 55550055 55550055 55550055 55550055 012b0958 55550055 55550055 55550055 55550055 012b0968 55550055 55550055 55550055 55550055 012b0978 55550055 55550055 55550055 55550055 012b0988 55550055 55550055 55550055 55550055 012b0998 55550055 55550055 55550055 55550055 0:000> 012b09a8 55550055 55550055 55550055 55550055 012b09b8 55550055 55550055 55550055 00000000 012b09c8 55000000 55005500 55005500 55005500 012b09d8 55005500 55005500 55005500 55005500 012b09e8 55005500 55005500 55005500 55005500 012b09f8 55005500 55005500 55005500 55005500 012b0a08 55005500 55005500 55005500 55005500 012b0a18 55005500 55005500 55005500 55005500 0:000> 012b0a28 55005500 55005500 55005500 55005500 012b0a38 55005500 55005500 55005500 55005500 012b0a48 55005500 55005500 55005500 55005500 012b0a58 55005500 55005500 55005500 55005500 012b0a68 55005500 55005500 55005500 55005500 012b0a78 55005500 55005500 55005500 55005500 012b0a88 55005500 55005500 55005500 55005500 012b0a98 55005500 55005500 55005500 55005500 0:000> 012b0aa8 55005500 55005500 55005500 55005500 012b0ab8 55005500 55005500 55005500 55005500 012b0ac8 55005500 55005500 55005500 55005500 012b0ad8 00000000 55000000 55000055 55000055 012b0ae8 55000055 55000055 55000055 55000055 012b0af8 55000055 55000055 55000055 55000055 012b0b08 55000055 55000055 55000055 55000055 012b0b18 55000055 55000055 55000055 55000055 0:000> 012b0b28 55000055 55000055 55000055 55000055 012b0b38 55000055 55000055 55000055 55000055 012b0b48 55000055 55000055 55000055 55000055 012b0b58 55000055 55000055 55000055 55000055 012b0b68 55000055 55000055 55000055 55000055 012b0b78 55000055 55000055 55000055 55000055 012b0b88 55000055 55000055 55000055 55000055 012b0b98 55000055 55000055 55000055 55000055 0:000> 012b0ba8 55000055 55000055 55000055 55000055 012b0bb8 55000055 55000055 55000055 55000055 012b0bc8 55000055 55000055 55000055 55000055 012b0bd8 55000055 55000055 55000055 55000055 012b0be8 55000055 00000000 00000000 00555555 012b0bf8 00555555 00555555 00555555 00555555 012b0c08 00555555 00555555 00555555 00555555 012b0c18 00555555 00555555 00555555 00555555 0:000> 012b0c28 00555555 00555555 00555555 00555555 012b0c38 00555555 00555555 00555555 00555555 012b0c48 00555555 00555555 00555555 00555555 012b0c58 00555555 00555555 00555555 00555555 012b0c68 00555555 00555555 00555555 00555555 012b0c78 00555555 00555555 00555555 00555555 012b0c88 00555555 00555555 00555555 00555555 012b0c98 00555555 00555555 00555555 00555555 0:000> 012b0ca8 00555555 00555555 00555555 00555555 012b0cb8 00555555 00555555 00555555 00555555 012b0cc8 00555555 00555555 00555555 00555555 012b0cd8 00555555 00555555 00555555 00555555 012b0ce8 00555555 00555555 00555555 00555555 012b0cf8 00555555 00555555 00000000 55000000 012b0d08 55005500 55005500 55005500 55005500 012b0d18 55005500 55005500 55005500 55005500 0:000> 012b0d28 55005500 55005500 55005500 55005500 012b0d38 55005500 55005500 55005500 55005500 012b0d48 55005500 55005500 55005500 55005500 012b0d58 55005500 55005500 55005500 55005500 012b0d68 55005500 55005500 55005500 55005500 012b0d78 55005500 55005500 55005500 55005500 012b0d88 55005500 55005500 55005500 55005500 012b0d98 55005500 55005500 55005500 55005500 0:000> 012b0da8 55005500 55005500 55005500 55005500 012b0db8 55005500 55005500 55005500 55005500 012b0dc8 55005500 55005500 55005500 55005500 012b0dd8 55005500 55005500 55005500 55005500 012b0de8 55005500 55005500 55005500 55005500 012b0df8 55005500 55005500 55005500 55005500 012b0e08 55005500 55005500 55005500 00000000 012b0e18 00000000 00555500 00555500 00555500 0:000> 012b0e28 00555500 00555500 00555500 00555500 012b0e38 00555500 00555500 00555500 00555500 012b0e48 00555500 00555500 00555500 00555500 012b0e58 00555500 00555500 00555500 00555500 012b0e68 00555500 00555500 00555500 00555500 012b0e78 00555500 00555500 00555500 00555500 012b0e88 00555500 00555500 00555500 00555500 012b0e98 00555500 00555500 00555500 00555500 0:000> 012b0ea8 00555500 00555500 00555500 00555500 012b0eb8 00555500 00555500 00555500 00555500 012b0ec8 00555500 00555500 00555500 00555500 012b0ed8 00555500 00555500 00555500 00555500 012b0ee8 00555500 00555500 00555500 00555500 012b0ef8 00555500 00555500 00555500 00555500 012b0f08 00555500 00555500 00555500 00555500 012b0f18 00555500 00555500 00555500 00555500 0:000> 012b0f28 00000000 55000000 55550055 55550055 012b0f38 55550055 55550055 55550055 55550055 012b0f48 55550055 55550055 55550055 55550055 012b0f58 55550055 55550055 55550055 55550055 012b0f68 55550055 55550055 55550055 55550055 012b0f78 55550055 55550055 55550055 55550055 012b0f88 55550055 55550055 55550055 55550055 012b0f98 55550055 55550055 55550055 55550055 0:000> 012b0fa8 55550055 55550055 55550055 55550055 012b0fb8 55550055 55550055 55550055 55550055 012b0fc8 55550055 55550055 55550055 55550055 012b0fd8 55550055 55550055 55550055 55550055 012b0fe8 55550055 55550055 55550055 55550055 012b0ff8 55550055 55550055 55550055 55550055 012b1008 55550055 55550055 55550055 55550055 012b1018 55550055 55550055 55550055 55550055 0:000> 012b1028 55550055 55550055 55550055 55550055 012b1038 55550055 00000000 55000000 55005500 012b1048 55005500 55005500 55005500 55005500 012b1058 55005500 55005500 55005500 55005500 012b1068 55005500 55005500 55005500 55005500 012b1078 55005500 55005500 55005500 55005500 012b1088 55005500 55005500 55005500 55005500 012b1098 55005500 55005500 55005500 55005500 0:000> 012b10a8 55005500 55005500 55005500 55005500 012b10b8 55005500 55005500 55005500 55005500 012b10c8 55005500 55005500 55005500 55005500 012b10d8 55005500 55005500 55005500 55005500 012b10e8 55005500 55005500 55005500 55005500 012b10f8 55005500 55005500 55005500 55005500 012b1108 55005500 55005500 55005500 55005500 012b1118 55005500 55005500 55005500 55005500 0:000> 012b1128 55005500 55005500 55005500 55005500 012b1138 55005500 55005500 55005500 55005500 012b1148 55005500 55005500 00000000 55000000 012b1158 55000055 55000055 55000055 55000055 012b1168 55000055 55000055 55000055 55000055 012b1178 55000055 55000055 55000055 55000055 012b1188 55000055 55000055 55000055 55000055 012b1198 55000055 55000055 55000055 55000055 0:000> 012b11a8 55000055 55000055 55000055 55000055 012b11b8 55000055 55000055 55000055 55000055 012b11c8 55000055 55000055 55000055 55000055 012b11d8 55000055 55000055 55000055 55000055 012b11e8 55000055 55000055 55000055 55000055 012b11f8 55000055 55000055 55000055 55000055 012b1208 55000055 55000055 55000055 55000055 012b1218 55000055 55000055 55000055 55000055 0:000> 012b1228 55000055 55000055 55000055 55000055 012b1238 55000055 55000055 55000055 55000055 012b1248 55000055 55000055 55000055 55000055 012b1258 55000055 55000055 55000055 00000000 012b1268 00000000 00555555 00555555 00555555 012b1278 00555555 00555555 00555555 00555555 012b1288 00555555 00555555 00555555 00555555 012b1298 00555555 00555555 00555555 00555555 0:000> 012b12a8 00555555 00555555 00555555 00555555 012b12b8 00555555 00555555 00555555 00555555 012b12c8 00555555 00555555 00555555 00555555 012b12d8 00555555 00555555 00555555 00555555 012b12e8 00555555 00555555 00555555 00555555 012b12f8 00555555 00555555 00555555 00555555 012b1308 00555555 00555555 00555555 00555555 012b1318 00555555 00555555 00555555 00555555 0:000> 012b1328 00555555 00555555 00555555 00555555 012b1338 00555555 00555555 00555555 00555555 012b1348 00555555 00555555 00555555 00555555 012b1358 00555555 00555555 00555555 00555555 012b1368 00555555 00555555 00555555 00555555 012b1378 00000000 55000000 55005500 55005500 012b1388 55005500 55005500 55005500 55005500 012b1398 55005500 55005500 55005500 55005500 0:000> 012b13a8 55005500 55005500 55005500 55005500 012b13b8 55005500 55005500 55005500 55005500 012b13c8 55005500 55005500 55005500 55005500 012b13d8 55005500 55005500 55005500 55005500 012b13e8 55005500 55005500 55005500 55005500 012b13f8 55005500 55005500 55005500 55005500 012b1408 55005500 55005500 55005500 55005500 012b1418 55005500 55005500 55005500 55005500 0:000> 012b1428 55005500 55005500 55005500 55005500 012b1438 55005500 55005500 55005500 55005500 012b1448 55005500 55005500 55005500 55005500 012b1458 55005500 55005500 55005500 55005500 012b1468 55005500 55005500 55005500 55005500 012b1478 55005500 55005500 55005500 55005500 012b1488 55005500 00000000 00000000 00555500 012b1498 00555500 00555500 00555500 00555500 0:000> 012b14a8 00555500 00555500 00555500 00555500 012b14b8 00555500 00555500 00555500 00555500 012b14c8 00555500 00555500 00555500 00555500 012b14d8 00555500 00555500 00555500 00555500 012b14e8 00555500 00555500 00555500 00555500 012b14f8 00555500 00555500 00555500 00555500 012b1508 00555500 00555500 00555500 00555500 012b1518 00555500 00555500 00555500 00555500 0:000> 012b1528 00555500 00555500 00555500 00555500 012b1538 00555500 00555500 00555500 00555500 012b1548 00555500 00555500 00555500 00555500 012b1558 00555500 00555500 00555500 00555500 012b1568 00555500 00555500 00555500 00555500 012b1578 00555500 00555500 00555500 00555500 012b1588 00555500 00555500 00555500 00555500 012b1598 00555500 00555500 00000000 55000000 0:000> 012b15a8 55550055 55550055 55550055 55550055 012b15b8 55550055 55550055 55550055 55550055 012b15c8 55550055 55550055 55550055 55550055 012b15d8 55550055 55550055 55550055 55550055 012b15e8 55550055 ff550055 ffffffff ffffffff 012b15f8 ffffffff 55550055 ffffffff ffffffff 012b1608 555500ff 55550055 55550055 55550055 012b1618 55550055 55550055 ffff0055 ffffffff 0:000> 012b1628 5555ffff 55550055 ff550055 ffffffff 012b1638 55ffffff 55550055 55550055 55550055 012b1648 55550055 55550055 55550055 55550055 012b1658 55550055 55550055 55550055 55550055 012b1668 55550055 55550055 55550055 55550055 012b1678 55550055 55550055 55550055 55550055 012b1688 55550055 55550055 55550055 55550055 012b1698 55550055 55550055 55550055 55550055 0:000> 012b16a8 55550055 55550055 55550055 00000000 012b16b8 55000000 55005500 55005500 55005500 012b16c8 55005500 55005500 55005500 55005500 012b16d8 55005500 55005500 55005500 55005500 012b16e8 55005500 55005500 55005500 55005500 012b16f8 55005500 55005500 55005500 ffffff00 012b1708 ffffffff 550055ff 55005500 ff005500 012b1718 55ffffff 55005500 55005500 55005500 0:000> 012b1728 55005500 55005500 55005500 ff005500 012b1738 ffffffff 55ffffff 55005500 55005500 012b1748 ffffff00 550055ff 55005500 55005500 012b1758 55005500 55005500 55005500 55005500 012b1768 55005500 ff005500 ffffffff 55ffffff 012b1778 55005500 55005500 55005500 55005500 012b1788 55005500 55005500 55005500 55005500 012b1798 55005500 55005500 55005500 55005500 0:000> 012b17a8 55005500 55005500 55005500 55005500 012b17b8 55005500 55005500 55005500 55005500 012b17c8 00000000 55000000 55000055 55000055 012b17d8 55000055 55000055 55000055 55000055 012b17e8 ffffff55 ffffffff ffffffff ffffffff 012b17f8 ffffffff ffffffff 55000055 55000055 012b1808 55000055 55000055 55000055 55000055 012b1818 ffff0055 ffffffff 55000055 55000055 0:000> 012b1828 55000055 5500ffff 55000055 55000055 012b1838 55000055 55000055 55000055 55000055 012b1848 55000055 ffffffff ffffffff 55000055 012b1858 55000055 ffff0055 55000055 55000055 012b1868 55000055 55000055 55000055 55000055 012b1878 55000055 55000055 ffffffff 550000ff 012b1888 ffffff55 5500ffff 55000055 55000055 012b1898 55000055 55000055 55000055 55000055 0:000> 012b18a8 55000055 55000055 55000055 55000055 012b18b8 ffffff55 55ffffff 55000055 55000055 012b18c8 55000055 55000055 55000055 55000055 012b18d8 55000055 00000000 00000000 00555555 012b18e8 00555555 00555555 00555555 00555555 012b18f8 00555555 ffffff55 ffffffff ffffffff 012b1908 ffffffff ffffffff ffffffff 00555555 012b1918 00555555 00555555 00555555 00555555 0:000> 012b1928 00555555 ffff5555 ffffffff 00555555 012b1938 00555555 00555555 0055ffff 00555555 012b1948 00555555 00555555 00555555 00555555 012b1958 00555555 00555555 ffffff55 ffffffff 012b1968 005555ff 00555555 ffff5555 00555555 012b1978 00555555 00555555 00555555 00555555 012b1988 00555555 00555555 ff555555 00ffffff 012b1998 00555555 ff555555 00ffffff 00555555 0:000> 012b19a8 00555555 00555555 00555555 00555555 012b19b8 00555555 00555555 00555555 00555555 012b19c8 ffff5555 ffffffff ffffffff 0055ffff 012b19d8 00555555 00555555 00555555 00555555 012b19e8 00555555 00555555 00000000 55000000 012b19f8 55005500 55005500 55005500 55005500 012b1a08 55005500 55005500 55005500 ffff5500 012b1a18 ffffffff ffffffff ffffffff 55005500 0:000> 012b1a28 55005500 55005500 00005500 55005500 012b1a38 55005500 55005500 ffff5500 ffffffff 012b1a48 55005500 55005500 55005500 5500ffff 012b1a58 55005500 00005500 00550055 00550000 012b1a68 55000055 55005500 55005500 ffffff00 012b1a78 ffffffff 550055ff 55005500 ffff5500 012b1a88 55005500 55005500 00550000 00000055 012b1a98 00550055 55005500 55005500 ffff5500 0:000> 012b1aa8 5500ffff 55005500 55005500 ffffffff 012b1ab8 55005500 55005500 00005500 00550055 012b1ac8 00550000 55000055 55005500 55005500 012b1ad8 55005500 ffffff00 ffffffff ffffffff 012b1ae8 ffffffff 55005500 55005500 55005500 012b1af8 55005500 55005500 55005500 00000000 012b1b08 00000000 00555500 00555500 00555500 012b1b18 00555500 00555500 00555500 00555500 0:000> 012b1b28 ff555500 ffffffff ffffffff 00ffffff 012b1b38 00555500 00555500 00555500 00005500 012b1b48 00555500 00555500 00555500 ffff5500 012b1b58 ffffffff 00555500 00555500 00555500 012b1b68 0055ffff 00555500 55555500 00550000 012b1b78 55550000 00550000 00555500 00555500 012b1b88 ffffff00 ffffffff 0055ffff 00555500 012b1b98 ffff5500 00555500 00555500 00005500 0:000> 012b1ba8 00000055 00005555 00555500 00555500 012b1bb8 ffffff00 0055ffff 00555500 00555500 012b1bc8 ffffffff 005555ff 00555500 55555500 012b1bd8 00550000 55550000 00550000 00555500 012b1be8 00555500 ff555500 ffffffff ffffffff 012b1bf8 ffffffff ffffffff 005555ff 00555500 012b1c08 00555500 00555500 00555500 00555500 012b1c18 00000000 55000000 55550055 55550055 0:000> 012b1c28 55550055 55550055 55550055 55550055 012b1c38 55550055 55550055 ffffffff ffffffff 012b1c48 5555ffff 55550055 55550055 55550055 012b1c58 00000055 55550000 55550055 55550055 012b1c68 ffff0055 ffffffff 55550055 55550055 012b1c78 55550055 5555ffff 55550055 55550055 012b1c88 00005555 55000000 55555555 55550055 012b1c98 55550055 55ffff55 ffffffff 55ffffff 0:000> 012b1ca8 55550055 ffff0055 55550055 55550055 012b1cb8 55555555 00000000 55555500 55550055 012b1cc8 55550055 ffffffff 555500ff 55550055 012b1cd8 55550055 ffffff55 5555ffff 55550055 012b1ce8 55550055 00005555 55000000 55555555 012b1cf8 55550055 55550055 ffff0055 ffffffff 012b1d08 ffffffff ffffffff ffffffff 5555ffff 012b1d18 55550055 55550055 55550055 55550055 0:000> 012b1d28 55550055 00000000 55000000 55005500 012b1d38 55005500 55005500 55005500 55005500 012b1d48 55005500 55005500 55005500 ffffffff 012b1d58 ffffffff 5500ffff 55005500 55005500 012b1d68 55005500 00000000 55000000 55005500 012b1d78 55005500 ffff5500 ffffffff 55005500 012b1d88 55005500 55005500 5500ffff 55005500 012b1d98 00005500 00000055 00000000 55000055 0:000> 012b1da8 55005500 55005500 55ffff00 ffffffff 012b1db8 ffffffff 55005500 ffff5500 55005500 012b1dc8 55005500 00550000 00000000 00550000 012b1dd8 55005500 ff005500 ffffffff 550055ff 012b1de8 55005500 55005500 ffffff00 55ffffff 012b1df8 55005500 00005500 00000055 00000000 012b1e08 55000055 55005500 55005500 ffff5500 012b1e18 ffffffff ffffffff ffffffff ffffffff 0:000> 012b1e28 5500ffff 55005500 55005500 55005500 012b1e38 55005500 55005500 00000000 55000000 012b1e48 55000055 55000055 55000055 55000055 012b1e58 55000055 55000055 55000055 55000055 012b1e68 ffffffff ffffffff 5500ffff 55000055 012b1e78 55000055 55000055 00000055 55000000 012b1e88 55000055 55000055 ffff0055 ffffffff 012b1e98 55000055 55000055 55000055 5500ffff 0:000> 012b1ea8 55000055 00000055 00005555 00000000 012b1eb8 55005555 55000055 55000055 55ffff55 012b1ec8 ffffff55 ffffffff 550000ff ffff0055 012b1ed8 55000055 55000055 55550055 00000000 012b1ee8 55550000 55000055 ff000055 ffffffff 012b1ef8 55000055 55000055 55000055 ffff0055 012b1f08 55ffffff 55000055 00000055 00005555 012b1f18 00000000 55005555 55000055 55000055 0:000> 012b1f28 ffffff55 ffffffff ffffffff ffffffff 012b1f38 ffffffff 55ffffff 55000055 55000055 012b1f48 55000055 55000055 55000055 00000000 012b1f58 00000000 00555555 00555555 00555555 012b1f68 00555555 00555555 00555555 00555555 012b1f78 00555555 ffffffff ffffffff 0055ffff 012b1f88 00555555 00555555 00555555 00000000 012b1f98 00000000 00555555 00555555 ffff5555 0:000> 012b1fa8 ffffffff 00555555 00555555 00555555 012b1fb8 0055ffff 00555555 55555555 00000000 012b1fc8 00000000 00555500 00555555 00555555 012b1fd8 00ffff55 ffff5555 ffffffff 005555ff 012b1fe8 ffff5555 00555555 00555555 00005555 012b1ff8 00000000 55000000 00555555 ff555555 012b2008 ffffffff 00555555 00555555 00555555 012b2018 ffff5555 00ffffff 00555555 55555555 0:000> 012b2028 00000000 00000000 00555500 00555555 012b2038 00555555 ffffffff 005555ff ffff5555 012b2048 ffffffff ffffffff 00ffffff 00555555 012b2058 00555555 00555555 00555555 00555555 012b2068 00000000 55000000 55005500 55005500 012b2078 55005500 55005500 55005500 55005500 012b2088 55005500 55005500 ffffffff ffffffff 012b2098 5500ffff 55005500 55005500 55005500 0:000> 012b20a8 00000000 55000000 55005500 55005500 012b20b8 ffff5500 ffffffff 55005500 55005500 012b20c8 55005500 5500ffff 55005500 00005500 012b20d8 00000055 00000000 55000055 55005500 012b20e8 55005500 55ffff00 ff005500 ffffffff 012b20f8 5500ffff ffff5500 55005500 55005500 012b2108 00550000 00000000 00550000 55005500 012b2118 ffff5500 ffffffff 55005500 55005500 0:000> 012b2128 55005500 ffff5500 ffffffff 55005500 012b2138 00005500 00000055 00000000 55000055 012b2148 55005500 55005500 55ffffff 55005500 012b2158 55005500 ffffffff ffffffff ffffffff 012b2168 55005500 55005500 55005500 55005500 012b2178 55005500 00000000 00000000 00555500 012b2188 00555500 00555500 00555500 00555500 012b2198 00555500 00555500 00555500 ffffffff 0:000> 012b21a8 ffffffff 0055ffff 00555500 00555500 012b21b8 00555500 00000000 00000000 00555500 012b21c8 00555500 ffff5500 ffffffff 00555500 012b21d8 00555500 00555500 0055ffff 00555500 012b21e8 55555500 00000000 00000000 00550000 012b21f8 00555500 00555500 00ffff00 00555500 012b2208 ffffffff 00ffffff ffff5500 00555500 012b2218 00555500 00005500 00000000 00000000 0:000> 012b2228 00555500 ffff5500 ffffffff 00555500 012b2238 00555500 00555500 ffff5500 ffffffff 012b2248 00555500 55555500 00000000 00000000 012b2258 00550000 00555500 ff555500 0055ffff 012b2268 00555500 00555500 ffffff00 ffffffff 012b2278 ffffffff 00555500 00555500 00555500 012b2288 00555500 00555500 00000000 55000000 012b2298 55550055 55550055 55550055 55550055 0:000> 012b22a8 55550055 55550055 55550055 55550055 012b22b8 ffffffff ffffffff 5555ffff 55550055 012b22c8 55550055 00000055 00000000 00000000 012b22d8 55550000 55550055 ffff0055 ffffffff 012b22e8 55550055 55550055 55550055 5555ffff 012b22f8 55550055 00550055 00000000 00000000 012b2308 55550000 55550055 55550055 55ffff55 012b2318 55550055 ffffff55 ffffffff ffff0055 0:000> 012b2328 55550055 55550055 00000055 00000000 012b2338 00000000 55550055 ffff0055 ffffffff 012b2348 55550055 55550055 55550055 ffff0055 012b2358 ffffffff 55550055 00550055 00000000 012b2368 00000000 55550000 55550055 ff550055 012b2378 555500ff 55550055 55550055 ffff0055 012b2388 ffffffff ffffffff 55550055 55550055 012b2398 55550055 55550055 55550055 00000000 0:000> 012b23a8 55000000 55005500 55005500 55005500 012b23b8 55005500 55005500 55005500 55005500 012b23c8 55005500 ffffffff ffffffff 5500ffff 012b23d8 55005500 55005500 00005500 00000000 012b23e8 00000000 55005500 55005500 ffff5500 012b23f8 ffffffff 55005500 55005500 55005500 012b2408 5500ffff 55005500 00005500 00000000 012b2418 00000000 55000000 55005500 55005500 0:000> 012b2428 55ffff00 55005500 ffffff00 ffffffff 012b2438 ffff55ff 55005500 55005500 00000000 012b2448 00000000 00000000 55005500 ffff5500 012b2458 ffffffff 55005500 55005500 55005500 012b2468 ffff5500 ffffffff 55005500 00005500 012b2478 00000000 00000000 55000000 55005500 012b2488 ffff5500 55005500 55005500 55005500 012b2498 ffff5500 ffffffff ffffffff 55005500 0:000> 012b24a8 55005500 55005500 55005500 55005500 012b24b8 00000000 55000000 55000055 55000055 012b24c8 55000055 55000055 55000055 55000055 012b24d8 55000055 55000055 ffffffff ffffffff 012b24e8 5500ffff 55000055 55000055 00000055 012b24f8 00000000 00000000 55000000 55000055 012b2508 ffff0055 ffffffff 55000055 55000055 012b2518 55000055 5500ffff 55000055 00000055 0:000> 012b2528 00000000 00000000 55000000 55000055 012b2538 55000055 55ffff55 55000055 ffff0055 012b2548 ffffffff ffff00ff 55000055 55000055 012b2558 00000055 00000000 00000000 55000055 012b2568 ffff0055 ffffffff 55000055 55000055 012b2578 55000055 ffff0055 ffffffff 55000055 012b2588 00000055 00000000 00000000 55000000 012b2598 55000055 55000055 55000055 55000055 0:000> 012b25a8 55000055 ff000055 ffffffff ffffffff 012b25b8 55000055 55000055 55000055 55000055 012b25c8 55000055 00000000 00000000 00555555 012b25d8 00555555 00555555 00555555 00555555 012b25e8 00555555 00555555 00555555 ffffffff 012b25f8 ffffffff 0055ffff 00555555 00555555 012b2608 00555555 00000000 00000000 00555555 012b2618 00555555 ffff5555 ffffffff 00555555 0:000> 012b2628 00555555 00555555 0055ffff 00555555 012b2638 55555555 00000000 00000000 00555500 012b2648 00555555 00555555 00ffff55 00555555 012b2658 ff555555 ffffffff ffffffff 00555555 012b2668 00555555 00005555 00000000 55000000 012b2678 00555555 ffff5555 ffffffff 00555555 012b2688 00555555 00555555 ffff5555 ffffffff 012b2698 00555555 55555555 00000000 00000000 0:000> 012b26a8 00555500 00555555 00555555 00555555 012b26b8 00555555 00555555 ff555555 ffffffff 012b26c8 ffffffff 00555555 00555555 00555555 012b26d8 00555555 00555555 00000000 55000000 012b26e8 55005500 55005500 55005500 55005500 012b26f8 55005500 55005500 55005500 55005500 012b2708 ffffffff ffffffff 5500ffff 55005500 012b2718 55005500 55005500 00000000 55000000 0:000> 012b2728 55005500 55005500 ffff5500 ffffffff 012b2738 55005500 55005500 55005500 5500ffff 012b2748 55005500 00005500 00000055 00000000 012b2758 55000055 55005500 55005500 55ffff00 012b2768 55005500 55005500 ffffffff ffffffff 012b2778 55005500 55005500 00550000 00000000 012b2788 00550000 55005500 ffff5500 ffffffff 012b2798 55005500 55005500 55005500 ffff5500 0:000> 012b27a8 ffffffff 55005500 00005500 00000055 012b27b8 00000000 55000055 55005500 55005500 012b27c8 55005500 55005500 55005500 ff005500 012b27d8 ffffffff 55ffffff 55005500 55005500 012b27e8 55005500 55005500 55005500 00000000 012b27f8 00000000 00555500 00555500 00555500 012b2808 00555500 00555500 00555500 00555500 012b2818 00555500 ffffffff ffffffff 0055ffff 0:000> 012b2828 00555500 00555500 00555500 00000000 012b2838 00000000 00555500 00555500 ffff5500 012b2848 ffffffff 00555500 00555500 00555500 012b2858 0055ffff 00555500 55555500 00000000 012b2868 00000000 00550000 00555500 00555500 012b2878 00ffff00 00555500 00555500 ffffff00 012b2888 ffffffff 00555500 00555500 00005500 012b2898 00000000 00000000 00555500 ff555500 0:000> 012b28a8 ffffffff 00555500 00555500 00555500 012b28b8 ffff5500 00ffffff 00555500 55555500 012b28c8 00000000 00000000 00550000 00555500 012b28d8 00555500 00555500 00555500 00555500 012b28e8 ff555500 ffffffff 00ffffff 00555500 012b28f8 00555500 00555500 00555500 00555500 012b2908 00000000 55000000 55550055 55550055 012b2918 55550055 55550055 55550055 55550055 0:000> 012b2928 55550055 55550055 ffffffff ffffffff 012b2938 5555ffff 55550055 55550055 55550055 012b2948 00000055 55550000 55550055 55550055 012b2958 ffff0055 ffffffff 55550055 55550055 012b2968 55550055 555500ff 55550055 55550055 012b2978 00005555 55000000 55555555 55550055 012b2988 55550055 55ffff55 55550055 55550055 012b2998 ffffff55 ffffffff 55550055 55550055 0:000> 012b29a8 55555555 00000000 55555500 55550055 012b29b8 ff550055 ffffffff 55550055 55550055 012b29c8 55550055 ffff0055 55ffffff 55550055 012b29d8 55550055 00005555 55000000 55555555 012b29e8 55550055 55550055 55550055 55550055 012b29f8 55550055 ff550055 ffffffff 55ffffff 012b2a08 55550055 55550055 55550055 55550055 012b2a18 55550055 00000000 55000000 55005500 0:000> 012b2a28 55005500 55005500 55005500 55005500 012b2a38 55005500 55005500 55005500 ffffffff 012b2a48 ffffffff 5500ffff 55005500 55005500 012b2a58 55005500 00000000 55000000 55005500 012b2a68 55005500 ff005500 ffffffff 55005500 012b2a78 55005500 ff005500 550055ff 55005500 012b2a88 00005500 00000055 00000000 55000055 012b2a98 55005500 55005500 55ffff00 55005500 0:000> 012b2aa8 55005500 ffff5500 ffffffff 55005500 012b2ab8 55005500 00550000 00000000 00550000 012b2ac8 55005500 ff005500 ffffffff 550055ff 012b2ad8 55005500 55005500 ffffff00 55ffffff 012b2ae8 55005500 00005500 00000055 00000000 012b2af8 55000055 55005500 55005500 55005500 012b2b08 55005500 55005500 ff005500 ffffffff 012b2b18 5500ffff 55005500 55005500 55005500 0:000> 012b2b28 55005500 55005500 00000000 55000000 012b2b38 55000055 55000055 55000055 55000055 012b2b48 55000055 55000055 55000055 55000055 012b2b58 ffffffff ffffffff 5500ffff 55000055 012b2b68 55000055 55000055 00000055 55000000 012b2b78 55000055 55000055 ff000055 ffffffff 012b2b88 550000ff 55000055 ff000055 550000ff 012b2b98 55000055 00000055 00005555 00000000 0:000> 012b2ba8 55005555 55000055 55000055 55ffff55 012b2bb8 55000055 55000055 ff000055 ffffffff 012b2bc8 55000055 55000055 55550055 00000000 012b2bd8 55550000 55000055 55000055 ffffffff 012b2be8 550000ff 55000055 55000055 ffffff55 012b2bf8 5500ffff 55000055 00000055 00005555 012b2c08 00000000 55005555 55000055 55000055 012b2c18 55000055 55000055 55000055 ffff0055 0:000> 012b2c28 ffffffff 5500ffff 55000055 55000055 012b2c38 55000055 55000055 55000055 00000000 012b2c48 00000000 00555555 00555555 00555555 012b2c58 00555555 00555555 00555555 00555555 012b2c68 00555555 ffffffff ffffffff 0055ffff 012b2c78 00555555 00555555 00555555 00005555 012b2c88 00555500 00555555 00555555 00555555 012b2c98 ffffffff 005555ff 00555555 ffff5555 0:000> 012b2ca8 00555555 00555555 55555555 00555500 012b2cb8 55550000 00555500 00555555 00555555 012b2cc8 00ffff55 00555555 00555555 00555555 012b2cd8 ffffffff 00555555 00555555 55005555 012b2ce8 00000055 55005555 00555555 00555555 012b2cf8 ffffff55 005555ff 00555555 00555555 012b2d08 ffffff55 005555ff 00555555 55555555 012b2d18 00555500 55550000 00555500 00555555 0:000> 012b2d28 00555555 00555555 00555555 00555555 012b2d38 ffff5555 ffffffff 005555ff 00555555 012b2d48 00555555 00555555 00555555 00555555 012b2d58 00000000 55000000 55005500 55005500 012b2d68 55005500 55005500 55005500 55005500 012b2d78 55005500 55005500 ffffffff ffffffff 012b2d88 5500ffff 55005500 55005500 55005500 012b2d98 00005500 55005500 55005500 55005500 0:000> 012b2da8 55005500 ffffff00 55ffffff 55005500 012b2db8 55ffff00 55005500 55005500 00005500 012b2dc8 00550055 00550000 55000055 55005500 012b2dd8 55005500 55ffff00 55005500 55005500 012b2de8 55005500 ffffff00 55005500 55005500 012b2df8 00550000 00000055 00550055 55005500 012b2e08 55005500 ffffff00 5500ffff 55005500 012b2e18 55005500 ffffffff 55005500 55005500 0:000> 012b2e28 00005500 00550055 00550000 55000055 012b2e38 55005500 55005500 55005500 55005500 012b2e48 55005500 ffff5500 ffffffff 55005500 012b2e58 55005500 55005500 55005500 55005500 012b2e68 55005500 00000000 00000000 00555500 012b2e78 00555500 00555500 00555500 00555500 012b2e88 00555500 00555500 00555500 ffffffff 012b2e98 ffffffff 0055ffff 00555500 00555500 0:000> 012b2ea8 00555500 00555500 00555500 00555500 012b2eb8 00555500 00555500 ffff5500 ffffffff 012b2ec8 ffffffff 0055ffff 00555500 00555500 012b2ed8 00555500 00555500 00555500 00555500 012b2ee8 00555500 00555500 ffffffff 00555500 012b2ef8 00555500 00555500 ffff5500 00555500 012b2f08 00555500 00555500 00555500 00555500 012b2f18 00555500 00555500 ff555500 00ffffff 0:000> 012b2f28 00555500 ff555500 00ffffff 00555500 012b2f38 00555500 00555500 00555500 00555500 012b2f48 00555500 00555500 00555500 00555500 012b2f58 00555500 00555500 ffffff00 ffffffff 012b2f68 00555500 00555500 00555500 00555500 012b2f78 00555500 00555500 00000000 55000000 012b2f88 55550055 55550055 55550055 55550055 012b2f98 55550055 55550055 55550055 55550055 0:000> 012b2fa8 ffffffff ffffffff 5555ffff 55550055 012b2fb8 55550055 55550055 55550055 55550055 012b2fc8 55550055 55550055 55550055 55550055 012b2fd8 ffffff55 55ffffff 55550055 55550055 012b2fe8 55550055 55550055 55550055 55550055 012b2ff8 55550055 55550055 ffff0055 ffffffff 012b3008 5555ffff 55550055 55550055 ffff0055 012b3018 55550055 55550055 55550055 55550055 0:000> 012b3028 55550055 55550055 55550055 55550055 012b3038 ffffffff 55550055 ffff0055 5555ffff 012b3048 55550055 55550055 55550055 55550055 012b3058 55550055 55550055 55550055 55550055 012b3068 55550055 55550055 55550055 ffffff55 012b3078 55ffffff 55550055 55550055 55550055 012b3088 55550055 55550055 55550055 00000000 012b3098 55000000 55005500 55005500 55005500 0:000> 012b30a8 55005500 55005500 55005500 55005500 012b30b8 55005500 ffffffff ffffffff 5500ffff 012b30c8 55005500 55005500 55005500 55005500 012b30d8 55005500 55005500 55005500 55005500 012b30e8 55005500 55005500 55005500 55005500 012b30f8 55005500 55005500 55005500 55005500 012b3108 55005500 55005500 55005500 55005500 012b3118 55005500 55005500 55005500 55005500 0:000> 012b3128 55005500 55005500 55005500 55005500 012b3138 55005500 55005500 55005500 55005500 012b3148 55005500 ff005500 ffffffff 55ffffff 012b3158 55005500 55005500 55005500 55005500 012b3168 55005500 55005500 55005500 55005500 012b3178 55005500 55005500 55005500 55005500 012b3188 ffffffff 5500ffff 55005500 55005500 012b3198 55005500 55005500 55005500 55005500 0:000> 012b31a8 00000000 55000000 55000055 55000055 012b31b8 55000055 55000055 55000055 55000055 012b31c8 55000055 55000055 ffffffff ffffffff 012b31d8 5500ffff 55000055 55000055 55000055 012b31e8 55000055 55000055 55000055 55000055 012b31f8 55000055 55000055 55000055 55000055 012b3208 55000055 55000055 55000055 55000055 012b3218 55000055 55000055 55000055 55000055 0:000> 012b3228 55000055 55000055 55000055 55000055 012b3238 55000055 55000055 55000055 55000055 012b3248 55000055 55000055 55000055 55000055 012b3258 55000055 55000055 55000055 55000055 012b3268 55000055 55000055 55000055 55000055 012b3278 55000055 55000055 55000055 55000055 012b3288 55000055 55000055 55000055 55000055 012b3298 ff000055 ffffffff 550000ff 55000055 0:000> 012b32a8 55000055 55000055 55000055 55000055 012b32b8 55000055 00000000 00000000 00555555 012b32c8 00555555 00555555 00555555 00555555 012b32d8 00555555 00555555 00555555 ffffffff 012b32e8 ffffffff 0055ffff 00555555 00555555 012b32f8 00555555 00555555 00555555 00555555 012b3308 00555555 00555555 00555555 00555555 012b3318 00555555 00555555 00555555 00555555 0:000> 012b3328 00555555 00555555 00555555 00555555 012b3338 00555555 00555555 00555555 00555555 012b3348 00555555 00555555 00555555 00555555 012b3358 00555555 00555555 00555555 00555555 012b3368 00555555 00555555 00555555 00555555 012b3378 00555555 00555555 00555555 00555555 012b3388 00555555 00555555 00555555 00555555 012b3398 00555555 00555555 00555555 00555555 0:000> 012b33a8 00555555 ff555555 ffffffff 00555555 012b33b8 00555555 00555555 00555555 00555555 012b33c8 00555555 00555555 00000000 55000000 012b33d8 55005500 55005500 55005500 55005500 012b33e8 55005500 55005500 55005500 55005500 012b33f8 ffffffff ffffffff 5500ffff 55005500 012b3408 55005500 55005500 55005500 55005500 012b3418 55005500 55005500 55005500 55005500 0:000> 012b3428 55005500 55005500 55005500 55005500 012b3438 55005500 55005500 55005500 55005500 012b3448 55005500 55005500 55005500 55005500 012b3458 55005500 55005500 55005500 55005500 012b3468 55005500 55005500 55005500 55005500 012b3478 55005500 55005500 55005500 55005500 012b3488 55005500 55005500 55005500 55005500 012b3498 55005500 55005500 55005500 55005500 0:000> 012b34a8 55005500 55005500 55005500 55005500 012b34b8 55005500 55005500 ffff5500 55ffffff 012b34c8 55005500 55005500 55005500 55005500 012b34d8 55005500 55005500 55005500 00000000 012b34e8 00000000 00555500 00555500 00555500 012b34f8 00555500 00555500 00555500 00555500 012b3508 00555500 ffffffff ffffffff 0055ffff 012b3518 00555500 00555500 00555500 00555500 0:000> 012b3528 00555500 00555500 00555500 00555500 012b3538 00555500 00555500 00555500 00555500 012b3548 00555500 00555500 00555500 00555500 012b3558 00555500 00555500 00555500 00555500 012b3568 00555500 00555500 00555500 00555500 012b3578 00555500 00555500 00555500 00555500 012b3588 00555500 00555500 00555500 00555500 012b3598 00555500 00555500 00555500 00555500 0:000> 012b35a8 00555500 00555500 00555500 00555500 012b35b8 00555500 00555500 00555500 00555500 012b35c8 00555500 00555500 00555500 ffffff00 012b35d8 005555ff 00555500 00555500 00555500 012b35e8 00555500 00555500 00555500 00555500 012b35f8 00000000 55000000 55550055 55550055 012b3608 55550055 55550055 55550055 55550055 012b3618 55550055 55550055 ffffffff ffffffff 0:000> 012b3628 5555ffff 55550055 55550055 55550055 012b3638 55550055 55550055 55550055 55550055 012b3648 55550055 55550055 55550055 55550055 012b3658 55550055 55550055 55550055 55550055 012b3668 55550055 55550055 55550055 55550055 012b3678 55550055 55550055 55550055 55550055 012b3688 55550055 55550055 55550055 55550055 012b3698 55550055 55550055 55550055 55550055 0:000> 012b36a8 55550055 55550055 55550055 55550055 012b36b8 55550055 55550055 55550055 55550055 012b36c8 55550055 55550055 55550055 55550055 012b36d8 55550055 55550055 55550055 55550055 012b36e8 ffffffff 55550055 55550055 55550055 012b36f8 55550055 55550055 55550055 55550055 012b3708 55550055 00000000 55000000 55005500 012b3718 55005500 55005500 55005500 55005500 0:000> 012b3728 55005500 55005500 55005500 ffffffff 012b3738 ffffffff 5500ffff 55005500 55005500 012b3748 55005500 55005500 55005500 55005500 012b3758 55005500 55005500 55005500 55005500 012b3768 55005500 55005500 55005500 55005500 012b3778 55005500 55005500 55005500 55005500 012b3788 55005500 55005500 55005500 55005500 012b3798 55005500 55005500 55005500 55005500 0:000> 012b37a8 55005500 55005500 55005500 55005500 012b37b8 55005500 55005500 55005500 55005500 012b37c8 55005500 55005500 55005500 55005500 012b37d8 55005500 55005500 55005500 55005500 012b37e8 55005500 55005500 55005500 55005500 012b37f8 55005500 55ffffff 55005500 55005500 012b3808 55005500 55ffff00 55005500 55005500 012b3818 55005500 55005500 00000000 55000000 0:000> 012b3828 55000055 55000055 55000055 55000055 012b3838 55000055 55000055 55000055 55000055 012b3848 ffffffff ffffffff 5500ffff 55000055 012b3858 55000055 55000055 55000055 55000055 012b3868 55000055 55000055 00000055 55000055 012b3878 55000055 55000055 55000055 55000055 012b3888 55000055 00000055 55000000 55000055 012b3898 55000055 55000055 55000055 55000055 0:000> 012b38a8 55000055 00000000 55000055 55000055 012b38b8 55000055 55000055 55000055 55000055 012b38c8 00000055 55000000 55000055 55000055 012b38d8 55000055 55000055 55000055 55000055 012b38e8 55000000 55000055 55000055 55000055 012b38f8 55000055 55000055 55000055 55000055 012b3908 55000055 ff000055 5500ffff 55000055 012b3918 55000055 55000055 5500ffff 55000055 0:000> 012b3928 55000055 55000055 55000055 00000000 012b3938 00000000 00555555 00555555 00555555 012b3948 00555555 00555555 00555555 00555555 012b3958 00555555 ffffffff ffffffff 0055ffff 012b3968 00555555 00555555 00555555 00555555 012b3978 00555555 00555555 00555555 00000000 012b3988 00550000 00555555 00555555 00555555 012b3998 00555555 00555555 00000055 00000000 0:000> 012b39a8 00555555 00555555 00555555 00555555 012b39b8 00555555 00555555 00000000 00555500 012b39c8 00555555 00555555 00555555 00555555 012b39d8 00555555 00000055 00000000 00555555 012b39e8 00555555 00555555 00555555 00555555 012b39f8 00555555 00000000 00555500 00555555 012b3a08 00555555 00555555 00555555 00555555 012b3a18 00555555 00555555 ffff5555 005555ff 0:000> 012b3a28 00555555 00555555 00555555 0055ffff 012b3a38 00555555 00555555 00555555 00555555 012b3a48 00000000 55000000 55005500 55005500 012b3a58 55005500 55005500 55005500 55005500 012b3a68 55005500 55005500 ffffffff ffffffff 012b3a78 5500ffff 55005500 55005500 55005500 012b3a88 55005500 55005500 55005500 00005500 012b3a98 00000000 55000000 55005500 55005500 0:000> 012b3aa8 55005500 55005500 55005500 00000000 012b3ab8 00000000 55005500 55005500 55005500 012b3ac8 55005500 55005500 00005500 00000000 012b3ad8 55000000 55005500 55005500 55005500 012b3ae8 55005500 00005500 00000000 00000000 012b3af8 55005500 55005500 55005500 55005500 012b3b08 55005500 00000000 00000000 55000000 012b3b18 55005500 55005500 55005500 55005500 0:000> 012b3b28 55005500 55005500 55005500 ffffff00 012b3b38 55005500 55005500 55005500 ff005500 012b3b48 5500ffff 55005500 55005500 55005500 012b3b58 55005500 00000000 00000000 00555500 012b3b68 00555500 00555500 00555500 00555500 012b3b78 00555500 00555500 00555500 ffffffff 012b3b88 ffffffff 0055ffff 00555500 00555500 012b3b98 00555500 00555500 00555500 00555500 0:000> 012b3ba8 00000000 00000000 00000000 00555500 012b3bb8 00555500 00555500 00555500 00005500 012b3bc8 00000000 00000000 00550000 00555500 012b3bd8 00555500 00555500 00555500 00000000 012b3be8 00000000 00000000 00555500 00555500 012b3bf8 00555500 00555500 00005500 00000000 012b3c08 00000000 00550000 00555500 00555500 012b3c18 00555500 00555500 00000000 00000000 0:000> 012b3c28 00000000 00555500 00555500 00555500 012b3c38 00555500 00555500 00555500 00555500 012b3c48 00ffffff 00555500 00555500 00555500 012b3c58 ffff5500 0055ffff 00555500 00555500 012b3c68 00555500 00555500 00000000 55000000 012b3c78 55550055 55550055 55550055 55550055 012b3c88 55550055 55550055 55550055 55550055 012b3c98 ffffffff ffffffff 5555ffff 55550055 0:000> 012b3ca8 55550055 55550055 55550055 55550055 012b3cb8 00550055 00000000 00000000 00000000 012b3cc8 55550000 55550055 55550055 55550055 012b3cd8 00000055 00000000 00000000 00000000 012b3ce8 55550055 55550055 55550055 00550055 012b3cf8 00000000 00000000 00000000 55550000 012b3d08 55550055 55550055 55550055 00000055 012b3d18 00000000 00000000 55000000 55550055 0:000> 012b3d28 55550055 55550055 00000055 00000000 012b3d38 00000000 00000000 55550000 55550055 012b3d48 55550055 55550055 55550055 55550055 012b3d58 ff550055 ffffffff ffffffff ffffffff 012b3d68 ffffffff ffffffff 555500ff 55550055 012b3d78 55550055 55550055 55550055 00000000 012b3d88 55000000 55005500 55005500 55005500 012b3d98 55005500 55005500 5500ff00 55005500 0:000> 012b3da8 55005500 ffffffff ffffffff 5500ffff 012b3db8 55005500 55005500 55005500 55005500 012b3dc8 55005500 00005500 00000000 00000000 012b3dd8 00000000 55000000 55005500 55005500 012b3de8 55005500 00000000 00000000 00000000 012b3df8 00000000 55005500 55005500 55005500 012b3e08 00000000 00000000 00000000 00000000 012b3e18 55000000 55005500 55005500 00005500 0:000> 012b3e28 00000000 55000000 00000000 00000000 012b3e38 55005500 55005500 55005500 00000000 012b3e48 00000000 00005500 00000000 55000000 012b3e58 55005500 55005500 55005500 55005500 012b3e68 55005500 ffff5500 ffffffff ffffffff 012b3e78 ffffffff ffffffff ffffffff 550055ff 012b3e88 55005500 55005500 55005500 55005500 012b3e98 00000000 55000000 55000055 55000055 0:000> 012b3ea8 55000055 55000055 ff000055 ffffffff 012b3eb8 55000055 55000055 ffffffff ffffffff 012b3ec8 5500ffff 55000055 55000055 55000055 012b3ed8 55000055 55000055 00000000 00000000 012b3ee8 55000000 00000000 00000000 55000000 012b3ef8 55000055 00000055 00000000 55000000 012b3f08 00000055 00000000 55000000 55000055 012b3f18 55000055 00000000 00000000 55000055 0:000> 012b3f28 00000000 00000000 55000055 55000055 012b3f38 00000055 00000000 55000000 00000055 012b3f48 00000000 55000000 55000055 55000055 012b3f58 00000000 00000000 00000055 00000000 012b3f68 00000000 55000055 55000055 55000055 012b3f78 55000055 55000055 ffffff55 ffffffff 012b3f88 ffffffff ffffffff ffffffff ffffffff 012b3f98 550000ff 55000055 55000055 55000055 0:000> 012b3fa8 55000055 00000000 00000000 00555555 012b3fb8 00555555 00555555 00555555 ffff5555 012b3fc8 ffffffff 005555ff 00555555 ffffffff 012b3fd8 ffffffff 0055ffff 00555555 00555555 012b3fe8 00555555 00555555 00555555 00000000 012b3ff8 00000000 00555555 00005555 00000000 012b4008 00550000 00555555 00000055 00000000 012b4018 00555500 00555555 00000000 00000000 0:000> 012b4028 00555555 00555555 00000000 00000000 012b4038 00555555 00000055 00000000 00550000 012b4048 00555555 00000000 00000000 00555500 012b4058 00555555 00000000 00000000 00555555 012b4068 00005555 00000000 00000000 00555555 012b4078 00000055 00000000 00555500 00555555 012b4088 00555555 00555555 00555555 ffffff55 012b4098 ffffffff ffffffff ffffffff ffffffff 0:000> 012b40a8 ffffffff 005555ff 00555555 00555555 012b40b8 00555555 00555555 00000000 55000000 012b40c8 55005500 55005500 55005500 55005500 012b40d8 ffffff00 ffffffff 5500ffff 55005500 012b40e8 ffffffff ffffffff 5500ffff 55005500 012b40f8 55005500 55005500 55005500 00005500 012b4108 00000000 55000000 55005500 00005500 012b4118 00000000 55000000 00005500 00000000 0:000> 012b4128 00000000 55005500 55005500 00000000 012b4138 00000000 55005500 00000000 00000000 012b4148 55000000 55005500 00005500 00000000 012b4158 55000000 00005500 00000000 55000000 012b4168 55005500 55005500 00000000 00000000 012b4178 55005500 00000000 00000000 55005500 012b4188 55005500 00005500 00000000 55000000 012b4198 55005500 55005500 55005500 55005500 0:000> 012b41a8 ffffffff ffffffff ffffffff ffffffff 012b41b8 ffffffff ffffffff 550055ff 55005500 012b41c8 55005500 55005500 55005500 00000000 012b41d8 00000000 00555500 00555500 00555500 012b41e8 00555500 ffffff00 ffffffff 0055ffff 012b41f8 00555500 ffffffff ffffffff 005555ff 012b4208 00555500 00555500 00555500 00555500 012b4218 00000000 00000000 00555500 00555500 0:000> 012b4228 00555500 00000000 00000000 00005500 012b4238 00000000 00550000 00555500 00555500 012b4248 00005500 00000000 00000000 00000000 012b4258 00000000 00555500 00555500 00555500 012b4268 00000000 00000000 00005500 00000000 012b4278 00550000 00555500 00555500 00005500 012b4288 00000000 00550000 00000000 00000000 012b4298 00555500 00555500 00555500 00000000 0:000> 012b42a8 00000000 00555500 00555500 00555500 012b42b8 ff555500 ffffffff ffffffff ffffffff 012b42c8 ffffffff ffffffff ffffffff 00555500 012b42d8 00555500 00555500 00555500 00555500 012b42e8 00000000 55000000 55550055 55550055 012b42f8 55550055 55550055 ffffff55 ffffffff 012b4308 5555ffff 55550055 ffffffff ffffffff 012b4318 555500ff 55550055 55550055 55550055 0:000> 012b4328 00550055 00000000 55000000 55550055 012b4338 55550055 55550055 00000055 00000000 012b4348 00000000 00000000 55550000 55550055 012b4358 55550055 55550055 00000000 00000000 012b4368 00000000 55000000 55550055 55550055 012b4378 55550055 00000055 00000000 00000000 012b4388 00000000 55550000 55550055 55550055 012b4398 00550055 00000000 00000000 00000000 0:000> 012b43a8 55550000 55550055 55550055 55550055 012b43b8 00000055 00000000 55550000 55550055 012b43c8 55550055 ffff0055 ffffffff ffffffff 012b43d8 ffffffff ffffffff ffffffff ffffffff 012b43e8 55550055 55550055 55550055 55550055 012b43f8 55550055 00000000 55000000 55005500 012b4408 55005500 55005500 55005500 ffffff00 012b4418 ffffffff 5500ffff 55005500 ffffffff 0:000> 012b4428 ffffffff 550055ff 55005500 55005500 012b4438 55005500 00000000 00000000 55000000 012b4448 55005500 55005500 55005500 00005500 012b4458 00000000 00000000 00000000 55005500 012b4468 55005500 55005500 55005500 00000000 012b4478 00000000 00000000 55005500 55005500 012b4488 55005500 55005500 00005500 00000000 012b4498 00000000 55000000 55005500 55005500 0:000> 012b44a8 55005500 55005500 00000000 00000000 012b44b8 00000000 55005500 55005500 55005500 012b44c8 55005500 00005500 00000000 55000000 012b44d8 55005500 55005500 ffffff00 ffffffff 012b44e8 ffffffff ffffffff ffffffff ffffffff 012b44f8 ffffffff 55005500 55005500 55005500 012b4508 55005500 55005500 00000000 55000000 012b4518 55000055 55000055 55000055 55000055 0:000> 012b4528 ffff0055 ffffffff 550000ff 55000055 012b4538 ffffffff ffffffff 55000055 55000055 012b4548 55000055 55000055 00000055 00000000 012b4558 55000055 55000055 55000055 55000055 012b4568 55000055 00000055 00000000 55000000 012b4578 55000055 55000055 55000055 55000055 012b4588 00000055 00000000 00000000 55000055 012b4598 55000055 55000055 55000055 55000055 0:000> 012b45a8 00000000 00000000 55000000 55000055 012b45b8 55000055 55000055 55000055 00000055 012b45c8 00000000 00000000 55000055 55000055 012b45d8 55000055 55000055 55000055 00000000 012b45e8 55000000 55000055 55000055 ffffff55 012b45f8 ffffffff ffffffff ffffffff ffffffff 012b4608 ffffffff ffffffff 55000055 55000055 012b4618 55000055 55000055 55000055 00000000 0:000> 012b4628 00000000 00555555 00555555 00555555 012b4638 00555555 ffff5555 ffffffff 00555555 012b4648 00555555 ffffffff 00ffffff 00555555 012b4658 00555555 00555555 00555555 00000055 012b4668 00000000 00555555 00555555 00555555 012b4678 00555555 00555555 00005555 00000000 012b4688 00555500 00555555 00555555 00555555 012b4698 00555555 00555555 00000000 00000000 0:000> 012b46a8 00555555 00555555 00555555 00555555 012b46b8 00555555 00005555 00000000 00555555 012b46c8 00555555 00555555 00555555 00555555 012b46d8 00555555 00000000 00550000 00555555 012b46e8 00555555 00555555 00555555 00555555 012b46f8 00000055 00000000 00555555 00555555 012b4708 00555555 00555555 00555555 00555555 012b4718 00555555 00555555 00555555 00555555 0:000> 012b4728 00555555 00555555 00555555 00555555 012b4738 00000000 55000000 55005500 55005500 012b4748 55005500 55005500 ff005500 ffffffff 012b4758 55005500 ff005500 ffffffff 55ffffff 012b4768 55005500 55005500 55005500 55005500 012b4778 00005500 55000000 55005500 55005500 012b4788 55005500 55005500 55005500 00005500 012b4798 55000000 55005500 55005500 55005500 0:000> 012b47a8 55005500 55005500 55005500 00000000 012b47b8 55005500 55005500 55005500 55005500 012b47c8 55005500 55005500 00005500 55000000 012b47d8 55005500 55005500 55005500 55005500 012b47e8 55005500 55005500 00000000 55005500 012b47f8 55005500 55005500 55005500 55005500 012b4808 55005500 00005500 55000000 55005500 012b4818 55005500 55005500 55005500 55005500 0:000> 012b4828 55005500 55005500 55005500 55005500 012b4838 55005500 55005500 55005500 55005500 012b4848 55005500 00000000 00000000 00555500 012b4858 00555500 00555500 00555500 00555500 012b4868 ffffffff 005555ff ffff5500 ffffffff 012b4878 005555ff 00555500 00555500 00555500 012b4888 00555500 00005500 00555500 00555500 012b4898 00555500 00555500 00555500 00555500 0:000> 012b48a8 00555500 00550000 00555500 00555500 012b48b8 00555500 00555500 00555500 00555500 012b48c8 00555500 00555500 00555500 00555500 012b48d8 00555500 00555500 00555500 00555500 012b48e8 00550000 00555500 00555500 00555500 012b48f8 00555500 00555500 00555500 00005500 012b4908 00555500 00555500 00555500 00555500 012b4918 00555500 00555500 00555500 00550000 0:000> 012b4928 00555500 00555500 00555500 00555500 012b4938 00555500 00555500 00555500 00555500 012b4948 00555500 00555500 00555500 00555500 012b4958 00555500 00555500 00000000 55000000 012b4968 55550055 55550055 55550055 55550055 012b4978 55550055 ffffff55 ffffffff ffffffff 012b4988 ffffffff 55550055 55550055 55550055 012b4998 55550055 55550055 55550055 55550055 0:000> 012b49a8 55550055 55550055 55550055 55550055 012b49b8 55550055 55550055 55550055 55550055 012b49c8 55550055 55550055 55550055 55550055 012b49d8 55550055 55550055 55550055 55550055 012b49e8 55550055 55550055 55550055 55550055 012b49f8 55550055 55550055 55550055 55550055 012b4a08 55550055 55550055 55550055 55550055 012b4a18 55550055 55550055 55550055 55550055 0:000> 012b4a28 55550055 55550055 55550055 55550055 012b4a38 55550055 55550055 55550055 55550055 012b4a48 55550055 55550055 55550055 55550055 012b4a58 55550055 55550055 55550055 55550055 012b4a68 55550055 55550055 55550055 00000000 012b4a78 55000000 55005500 55005500 55005500 012b4a88 55005500 55005500 55005500 ffffffff 012b4a98 ffffffff 550055ff 55005500 55005500 0:000> 012b4aa8 55005500 55005500 55005500 55005500 012b4ab8 55005500 55005500 55005500 55005500 012b4ac8 55005500 55005500 55005500 55005500 012b4ad8 55005500 55005500 55005500 55005500 012b4ae8 55005500 55005500 55005500 55005500 012b4af8 55005500 55005500 55005500 55005500 012b4b08 55005500 55005500 55005500 55005500 012b4b18 55005500 55005500 55005500 55005500 0:000> 012b4b28 55005500 55005500 55005500 55005500 012b4b38 55005500 55005500 55005500 55005500 012b4b48 55005500 55005500 55005500 55005500 012b4b58 55005500 55005500 55005500 55005500 012b4b68 55005500 55005500 55005500 55005500 012b4b78 55005500 55005500 55005500 55005500 012b4b88 00000000 55000000 55000055 55000055 012b4b98 55000055 55000055 55000055 55000055 0:000> 012b4ba8 55000055 55000055 55000055 55000055 012b4bb8 55000055 55000055 55000055 55000055 012b4bc8 55000055 55000055 55000055 55000055 012b4bd8 55000055 55000055 55000055 55000055 012b4be8 55000055 55000055 55000055 55000055 012b4bf8 55000055 55000055 55000055 55000055 012b4c08 55000055 55000055 55000055 55000055 012b4c18 55000055 55000055 55000055 55000055 0:000> 012b4c28 55000055 55000055 55000055 55000055 012b4c38 55000055 55000055 55000055 55000055 012b4c48 55000055 55000055 55000055 55000055 012b4c58 55000055 55000055 55000055 55000055 012b4c68 55000055 55000055 55000055 55000055 012b4c78 55000055 55000055 55000055 55000055 012b4c88 55000055 55000055 55000055 55000055 012b4c98 55000055 00000000 00000000 00555555 0:000> 012b4ca8 00555555 00555555 00555555 00555555 012b4cb8 00555555 00555555 00555555 00555555 012b4cc8 00555555 00555555 00555555 00555555 012b4cd8 00555555 00555555 00555555 00555555 012b4ce8 00555555 00555555 00555555 00555555 012b4cf8 00555555 00555555 00555555 00555555 012b4d08 00555555 00555555 00555555 00555555 012b4d18 00555555 00555555 00555555 00555555 0:000> 012b4d28 00555555 00555555 00555555 00555555 012b4d38 00555555 00555555 00555555 00555555 012b4d48 00555555 00555555 00555555 00555555 012b4d58 00555555 00555555 00555555 00555555 012b4d68 00555555 00555555 00555555 00555555 012b4d78 00555555 00555555 00555555 00555555 012b4d88 00555555 00555555 00555555 00555555 012b4d98 00555555 00555555 00555555 00555555 0:000> 012b4da8 00555555 00555555 00000000 55000000 012b4db8 55005500 55005500 55005500 55005500 012b4dc8 55005500 55005500 55005500 55005500 012b4dd8 55005500 55005500 55005500 55005500 012b4de8 55005500 55005500 55005500 55005500 012b4df8 55005500 55005500 55005500 55005500 012b4e08 55005500 55005500 55005500 55005500 012b4e18 55005500 55005500 55005500 55005500 0:000> 012b4e28 55005500 55005500 55005500 55005500 012b4e38 55005500 55005500 55005500 55005500 012b4e48 55005500 55005500 55005500 55005500 012b4e58 55005500 55005500 55005500 55005500 012b4e68 55005500 55005500 55005500 55005500 012b4e78 55005500 55005500 55005500 55005500 012b4e88 55005500 55005500 55005500 55005500 012b4e98 55005500 55005500 55005500 55005500 0:000> 012b4ea8 55005500 55005500 55005500 55005500 012b4eb8 55005500 55005500 55005500 00000000 012b4ec8 00000000 00555500 00555500 00555500 012b4ed8 00555500 00555500 00555500 00555500 012b4ee8 00555500 00555500 00555500 00555500 012b4ef8 00555500 00555500 00555500 00555500 012b4f08 00555500 00555500 00555500 00555500 012b4f18 00555500 00555500 00555500 00555500 0:000> 012b4f28 00555500 00555500 00555500 00555500 012b4f38 00555500 00555500 00555500 00555500 012b4f48 00555500 00555500 00555500 00555500 012b4f58 00555500 00555500 00555500 00555500 012b4f68 00555500 00555500 00555500 00555500 012b4f78 00555500 00555500 00555500 00555500 012b4f88 00555500 00555500 00555500 00555500 012b4f98 00555500 00555500 00555500 00555500 0:000> 012b4fa8 00555500 00555500 00555500 00555500 012b4fb8 00555500 00555500 00555500 00555500 012b4fc8 00555500 00555500 00555500 00555500 012b4fd8 00000000 55000000 55550055 55550055 012b4fe8 55550055 55550055 55550055 55550055 012b4ff8 55550055 55550055 55550055 55550055 012b5008 55550055 55550055 55550055 55550055 012b5018 55550055 55550055 55550055 55550055 0:000> 012b5028 55550055 55550055 55550055 55550055 012b5038 55550055 55550055 55550055 55550055 012b5048 55550055 55550055 55550055 55550055 012b5058 55550055 55550055 55550055 55550055 012b5068 55550055 55550055 55550055 55550055 012b5078 55550055 55550055 55550055 55550055 012b5088 55550055 55550055 55550055 55550055 012b5098 55550055 55550055 55550055 55550055 0:000> 012b50a8 55550055 55550055 55550055 55550055 012b50b8 55550055 55550055 55550055 55550055 012b50c8 55550055 55550055 55550055 55550055 012b50d8 55550055 55550055 55550055 55550055 012b50e8 55550055 00000000 55000000 55005500 012b50f8 55005500 55005500 55005500 55005500 012b5108 55005500 55005500 55005500 55005500 012b5118 55005500 55005500 55005500 55005500 0:000> 012b5128 55005500 55005500 55005500 55005500 012b5138 55005500 55005500 55005500 55005500 012b5148 55005500 55005500 55005500 55005500 012b5158 55005500 55005500 55005500 55005500 012b5168 55005500 55005500 55005500 55005500 012b5178 55005500 55005500 55005500 55005500 012b5188 55005500 55005500 55005500 55005500 012b5198 55005500 55005500 55005500 55005500 0:000> 012b51a8 55005500 55005500 55005500 55005500 012b51b8 55005500 55005500 55005500 55005500 012b51c8 55005500 55005500 55005500 55005500 012b51d8 55005500 55005500 55005500 55005500 012b51e8 55005500 55005500 55005500 55005500 012b51f8 55005500 55005500 00000000 55000000 012b5208 55000055 55000055 55000055 55000055 012b5218 55000055 55000055 55000055 55000055 0:000> 012b5228 55000055 55000055 55000055 55000055 012b5238 55000055 55000055 55000055 55000055 012b5248 55000055 55000055 55000055 55000055 012b5258 55000055 55000055 55000055 55000055 012b5268 55000055 55000055 55000055 55000055 012b5278 55000055 55000055 55000055 55000055 012b5288 55000055 55000055 55000055 55000055 012b5298 55000055 55000055 55000055 55000055 0:000> 012b52a8 55000055 55000055 55000055 55000055 012b52b8 55000055 55000055 55000055 55000055 012b52c8 55000055 55000055 55000055 55000055 012b52d8 55000055 55000055 55000055 55000055 012b52e8 55000055 55000055 55000055 55000055 012b52f8 55000055 55000055 55000055 55000055 012b5308 55000055 55000055 55000055 00000000 012b5318 00000000 00555555 00555555 00555555 0:000> 012b5328 00555555 00555555 00555555 00555555 012b5338 00555555 00555555 00555555 00555555 012b5348 00555555 00555555 00555555 00555555 012b5358 00555555 00555555 00555555 00555555 012b5368 00555555 00555555 00555555 00555555 012b5378 00555555 00555555 00555555 00555555 012b5388 00555555 00555555 00555555 00555555 012b5398 00555555 00555555 00555555 00555555 0:000> 012b53a8 00555555 00555555 00555555 00555555 012b53b8 00555555 00555555 00555555 00555555 012b53c8 00555555 00555555 00555555 00555555 012b53d8 00555555 00555555 00555555 00555555 012b53e8 00555555 00555555 00555555 00555555 012b53f8 00555555 00555555 00555555 00555555 012b5408 00555555 00555555 00555555 00555555 012b5418 00555555 00555555 00555555 00555555 0:000> 012b5428 00000000 55000000 55005500 55005500 012b5438 55005500 55005500 55005500 55005500 012b5448 55005500 55005500 55005500 55005500 012b5458 55005500 55005500 55005500 55005500 012b5468 55005500 55005500 55005500 55005500 012b5478 55005500 55005500 55005500 55005500 012b5488 55005500 55005500 55005500 55005500 012b5498 55005500 55005500 55005500 55005500 0:000> 012b54a8 55005500 55005500 55005500 55005500 012b54b8 55005500 55005500 55005500 55005500 012b54c8 55005500 55005500 55005500 55005500 012b54d8 55005500 55005500 55005500 55005500 012b54e8 55005500 55005500 55005500 55005500 012b54f8 55005500 55005500 55005500 55005500 012b5508 55005500 55005500 55005500 55005500 012b5518 55005500 55005500 55005500 55005500 0:000> 012b5528 55005500 55005500 55005500 55005500 012b5538 55005500 00000000 00000000 00555500 012b5548 00555500 00555500 00555500 00555500 012b5558 00555500 00555500 00555500 00555500 012b5568 00555500 00555500 00555500 00555500 012b5578 00555500 00555500 00555500 00555500 012b5588 00555500 00555500 00555500 00555500 012b5598 00555500 00555500 00555500 00555500 0:000> 012b55a8 00555500 00555500 00555500 00555500 012b55b8 00555500 00555500 00555500 00555500 012b55c8 00555500 00555500 00555500 00555500 012b55d8 00555500 00555500 00555500 00555500 012b55e8 00555500 00555500 00555500 00555500 012b55f8 00555500 00555500 00555500 00555500 012b5608 00555500 00555500 00555500 00555500 012b5618 00555500 00555500 00555500 00555500 0:000> 012b5628 00555500 00555500 00555500 00555500 012b5638 00555500 00555500 00555500 00555500 012b5648 00555500 00555500 00000000 55000000 012b5658 55550055 55550055 55550055 55550055 012b5668 55550055 55550055 55550055 55550055 012b5678 55550055 55550055 55550055 55550055 012b5688 55550055 55550055 55550055 55550055 012b5698 55550055 55550055 55550055 55550055 0:000> 012b56a8 55550055 55550055 55550055 55550055 012b56b8 55550055 55550055 55550055 55550055 012b56c8 55550055 55550055 55550055 55550055 012b56d8 55550055 55550055 55550055 55550055 012b56e8 55550055 55550055 55550055 55550055 012b56f8 55550055 55550055 55550055 55550055 012b5708 55550055 55550055 55550055 55550055 012b5718 55550055 55550055 55550055 55550055 0:000> 012b5728 55550055 55550055 55550055 55550055 012b5738 55550055 55550055 55550055 55550055 012b5748 55550055 55550055 55550055 55550055 012b5758 55550055 55550055 55550055 00000000 012b5768 55000000 55005500 55005500 55005500 012b5778 55005500 55005500 55005500 55005500 012b5788 55005500 55005500 55005500 55005500 012b5798 55005500 55005500 55005500 55005500 0:000> 012b57a8 55005500 55005500 55005500 55005500 012b57b8 55005500 55005500 55005500 55005500 012b57c8 55005500 55005500 55005500 55005500 012b57d8 55005500 55005500 55005500 55005500 012b57e8 55005500 55005500 55005500 55005500 012b57f8 55005500 55005500 55005500 55005500 012b5808 55005500 55005500 55005500 55005500 012b5818 55005500 55005500 55005500 55005500 0:000> 012b5828 55005500 55005500 55005500 55005500 012b5838 55005500 55005500 55005500 55005500 012b5848 55005500 55005500 55005500 55005500 012b5858 55005500 55005500 55005500 55005500 012b5868 55005500 55005500 55005500 55005500 012b5878 00000000 55000000 55000055 55000055 012b5888 55000055 55000055 55000055 55000055 012b5898 55000055 55000055 55000055 55000055 0:000> 012b58a8 55000055 55000055 55000055 55000055 012b58b8 55000055 55000055 55000055 55000055 012b58c8 55000055 55000055 55000055 55000055 012b58d8 55000055 55000055 55000055 55000055 012b58e8 55000055 55000055 55000055 55000055 012b58f8 55000055 55000055 55000055 55000055 012b5908 55000055 55000055 55000055 55000055 012b5918 55000055 55000055 55000055 55000055 0:000> 012b5928 55000055 55000055 55000055 55000055 012b5938 55000055 55000055 55000055 55000055 012b5948 55000055 55000055 55000055 55000055 012b5958 55000055 55000055 55000055 55000055 012b5968 55000055 55000055 55000055 55000055 012b5978 55000055 55000055 55000055 55000055 012b5988 55000055 00000000 00000000 00000000 012b5998 00000000 00000000 00000000 00000000 0:000> 012b59a8 00000000 00000000 00000000 00000000 012b59b8 00000000 00000000 00000000 00000000 012b59c8 00000000 00000000 00000000 00000000 012b59d8 00000000 00000000 00000000 00000000 012b59e8 00000000 00000000 00000000 00000000 012b59f8 00000000 00000000 00000000 00000000 012b5a08 00000000 00000000 00000000 00000000 012b5a18 00000000 00000000 00000000 00000000 0:000> 012b5a28 00000000 00000000 00000000 00000000 012b5a38 00000000 00000000 00000000 00000000 012b5a48 00000000 00000000 00000000 00000000 012b5a58 00000000 00000000 00000000 00000000 012b5a68 00000000 00000000 00000000 00000000 012b5a78 00000000 00000000 00000000 00000000 012b5a88 00000000 00000000 00000000 00000000 012b5a98 00000000 00000000 00000000 00000000 0:000> 012b5aa8 00000000 00000000 00000000 00000000 012b5ab8 00000000 00000000 00000000 00000000 012b5ac8 00000000 00000000 00000000 00000000 012b5ad8 00000000 00000000 00000000 00000000 012b5ae8 00000000 00000000 00000000 00000000 012b5af8 00000000 00000000 00000000 00000000 012b5b08 00000000 00000000 00000000 00000000 012b5b18 00000000 00000000 00000000 00000000 0:000> 012b5b28 00000000 00000000 00000000 00000000 012b5b38 00000000 00000000 00000000 00000000 012b5b48 00000000 00000000 00000000 00000000 012b5b58 00000000 00000000 00000000 00000000 012b5b68 00000000 00000000 00000000 00000000 012b5b78 00000000 00000000 00000000 00000000 012b5b88 00000000 00000000 00000000 00000000 012b5b98 00000000 00000000 00000000 00000000 0:000> 012b5ba8 00000000 00000000 00000000 00000000 012b5bb8 00000000 00000000 00000000 00000000 012b5bc8 00000000 00000000 00000000 00000000 012b5bd8 00000000 00000000 00000000 00000000 012b5be8 00000000 00000000 00000000 00000000 012b5bf8 00000000 00000000 00000000 00000000 012b5c08 00000000 00000000 00000000 00000000 012b5c18 00000000 00000000 00000000 00000000 0:000> 012b5c28 00000000 00000000 00000000 00000000 012b5c38 00000000 00000000 00000000 00000000 012b5c48 00000000 00000000 00000000 00000000 012b5c58 00000000 00000000 00000000 00000000 012b5c68 00000000 00000000 00000000 00000000 012b5c78 00000000 00000000 00000000 00000000 012b5c88 00000000 00000000 00000000 00000000 012b5c98 00000000 00000000 00000000 00000000 0:000> 012b5ca8 00000000 00000000 00000000 00000000 012b5cb8 00000000 00000000 00000000 00000000 012b5cc8 00000000 00200b16 00eb7e38 02216808 012b5cd8 00200898 01354828 00000000 00000000 012b5ce8 02214018 012b5d48 00000000 000002c2 012b5cf8 000000d5 0000012b 0118cd08 00000000 012b5d08 00000000 00000040 00000000 00000000 012b5d18 00000000 00000000 00000000 00000000 0:000> 012b5d28 02216830 c7c34f80 c7c34f80 c7c34f80 012b5d38 c7c34f80 00000000 00000000 002004ba 012b5d48 00000000 02216894 012b5e64 012b5cdc 012b5d58 00000056 00200470 00000000 022168ac 012b5d68 022168bc 0020052e 00e66248 00e63b70 012b5d78 00000000 011a0648 00e63b60 00200546 012b5d88 00e6609c 00e64e10 00000001 4061c71c 012b5d98 c7c34f80 c7c34f80 00200882 01353ec0 0:000> 012b5da8 00000000 00000000 02214018 012b5e64 012b5db8 00000000 000002c2 0000012b 00000137 012b5dc8 0118cd08 00000000 00000000 00000040 012b5dd8 00000000 00000000 00000000 00000000 012b5de8 00000000 00000000 012b5e10 c7c34f80 012b5df8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b5e08 c7c34f80 00200a3c 01340ff0 00000000 012b5e18 00000000 012b5da4 00000000 00000000 0:000> 012b5e28 000002c2 0000012b 00000137 0118cd08 012b5e38 00000000 00000000 00000040 00000000 012b5e48 00000000 00000000 00000000 00000052 012b5e58 00000000 00000000 002004ba 00000000 012b5e68 012b5d48 012b6118 012b5da4 0000000c 012b5e78 00200470 00000000 022168cc 022168bc 012b5e88 00200332 012b5e94 00000001 022168dc 012b5e98 00200470 00000000 0119e8cc 012b5eac 0:000> 012b5ea8 00200470 00000000 022168e8 012b5ebc 012b5eb8 00200470 00000000 022168dc 00000000 012b5ec8 00200470 00000000 012b5e9c 012b5e7c 012b5ed8 0020052e 00e66248 00e63b70 00000000 012b5ee8 011a0648 00e63b60 00200546 00e6609c 012b5ef8 00e63c80 00000001 c7c34f80 00000000 012b5f08 00000000 00200546 00e6609c 00e63900 012b5f18 00000000 c7c34f80 c7c34f80 c7c34f80 0:000> 012b5f28 00200470 00000000 022168dc 012b5ecc 012b5f38 00200470 00000000 022168dc 00000000 012b5f48 0020052e 00e66248 00e63b70 00000000 012b5f58 011a0648 00e63b60 00200548 00e6607c 012b5f68 00e64e10 00000001 022168dc 00200544 012b5f78 00e660bc 00e64564 00000000 40000000 012b5f88 00200544 00e660bc 00e64578 00000000 012b5f98 00000000 00200532 00e661e4 00e6458c 0:000> 012b5fa8 00000000 00000000 00200532 00e661e4 012b5fb8 00e645a4 00000000 00000001 00200532 012b5fc8 00e661e4 00e645b8 00000000 00000000 012b5fd8 00200534 01341518 00e64e10 00000000 012b5fe8 012b5ff8 00000001 00000001 00200540 012b5ff8 012b6000 00000003 012b5fa0 012b5fb4 012b6008 012b5fc8 00200548 00e6607c 00e6418c 012b6018 00000000 00000000 002008a0 01354e98 0:000> 012b6028 00000000 00000000 012b60ac 00000000 012b6038 00000000 000002c2 00000137 00000151 012b6048 0118cd08 00000000 00000000 00000040 012b6058 00000000 00000000 00000000 00000000 012b6068 022168dc 00000007 0119ff40 3f349f4a 012b6078 00000000 00000002 00000000 3f000000 012b6088 3f000000 000000b8 0000020a 00000137 012b6098 00000151 000000b8 0000014c 00000000 0:000> 012b60a8 00200898 01354828 00000000 00000000 012b60b8 02214018 012b6118 00000000 000002c2 012b60c8 00000137 00000151 0118cd08 00000000 012b60d8 00000000 00000040 00000000 00000000 012b60e8 00000000 00000000 00000000 00000000 012b60f8 012b6024 c7c34f80 c7c34f80 c7c34f80 012b6108 c7c34f80 00000000 00000000 002004ba 012b6118 00000000 012b5e64 012b6234 012b60ac 012b6128 0000001a 00200470 00000000 022168f8 012b6138 022168bc 0020052e 00e66248 00e63b70 012b6148 00000000 011a0648 00e63b60 00200546 012b6158 00e6609c 00e64e10 00000001 4061c71c 012b6168 c7c34f80 c7c34f80 00200882 01353ec0 012b6178 00000000 00000000 02214018 012b6234 012b6188 00000000 000002c2 00000151 0000015d 012b6198 0118cd08 00000000 00000000 00000040 012b61a8 00000000 00000000 00000000 00000000 012b61b8 00000000 00000000 012b61e0 c7c34f80 012b61c8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b61d8 c7c34f80 00200a3c 01340ff0 00000000 012b61e8 00000000 012b6174 00000000 00000000 012b61f8 000002c2 00000151 0000015d 0118cd08 012b6208 00000000 00000000 00000040 00000000 012b6218 00000000 00000000 00000000 00000052 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 3 17:45:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Sep 2009 15:45:39 +0000 Subject: [M3devel] some data on Juno crash on Win32 In-Reply-To: <20090903154436.w1aooqqaskg4scg4@mail.elegosoft.com> References: <20090903154436.w1aooqqaskg4scg4@mail.elegosoft.com> Message-ID: This is on NT. Posix often hangs. If I blow up the initial heap size by a factor of 100, to avoid any garbage collection occuring, the crashes and hangs go away. NT then just fails assertions. I think @M3nogc causes the same thing. So, duh, I think something is trashing the heap. Maybe the gui code. - Jay > Date: Thu, 3 Sep 2009 15:44:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] some data on Juno crash on Win32 > > Quoting Jay K : > > > summary: 5.7.0 and 5.7.1 of unknown date: > > > > both always fail > > > > 5.7.0 always fails an assert (various?) > > > > 5.7.1 sometimes fails an assert (various) > > > > 5.7.1 sometimes access violates, always on address 00200000, plus or minus 4. > > > > Current source always access violates, same address. > > > > Since 5.7.1 and current source always access violate (aka SIGSEGV) > > on the same > > location, every run, I'm more inclined to look at this. > > This is all on Windows/NT386, isn't it? Or on POSIX platforms, too? > I seem to remember that Juno always crashed on a PaintBrush operation > on Windows, while the various mentor applications crashed at > different points, but all relating to insufficient Trestle/Win > support. > > On POSIX platforms both applications always ran OK AFAIR. > > Olaf > > > And then hope everything else is "the same" problem. > > > > But of course there might be multiple problems. > > > > It might be good to check for the hang in various from > > http://www.opencm3.net/uploaded-archives/index.html. > > > > Also see what all we can get from > > http://www.opencm3.net/snaps/snapshot-index.html. > > > > I'm going to see if I can get the index update with the many files I > > noticed in the file system. > > The same file name pattern for all files would help here. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Sep 3 20:32:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 03 Sep 2009 20:32:27 +0200 Subject: [M3devel] RC3, RC4? Message-ID: <20090903203227.smcanrumcgo84w4o@mail.elegosoft.com> Hi again, I'm about to leave for my holidays and will be back again on September 22. I probably won't be able to check my email for about two weeks, nor will I further the CM3 release engineering in this time. For 5.8 RC3, packages for most target platforms have been built and are available on www.opencm3.net. But there is a possibly critical problem described in ticket #1070, which may make it necessary to rebuild all packages (which should then be named RC4). I trust that Jay and Tony and anybody else who is interested track down the problem and fix it, and update tickets and roadmap at https://projects.elego.de/cm3/roadmap appropriately. I hope to see a usable set of packages at my return :-) I'll have a look at my mail again later tonight and tomorrow morning, but won't do much more concerning CM3 now. If anybody wants to go on and build RC4, here is what should be done: 1. Apply the tag release_CM3_5_8_RC4 to an appropriate and consistent configuration in CVS containing all needed fixes. 2. Update cm3/scripts/version to 5.8.4 etc. 3. Insert the tag as default into scripts/make-dist.sh (optional). 4. Build installation packages on all target platforms, most easily done via the makedist-jobs in http://hudson.modula3.com:8080/view/makedist/. 5. When the packages are available, they should be tested with http://hudson.modula3.com:8080/view/test-install/. Of course, all regression test results available at http://hudson.modula3.com:8080/ should be examined before the build. 6. Update the release documentation in cm3/www/releng and cm3/www and install this on birch.elegosoft.com. If anybody needs access to Hudson or Trac, please refer to admins at elego.de; Kay, Mike or Michael will help you. That's it for now, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Sep 4 04:02:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 02:02:47 +0000 Subject: [M3devel] This is a pixmap? Message-ID: Trying again due to truncation. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: This is a pixmap? Date: Thu, 3 Sep 2009 15:44:17 +0000 Does this look like a pixmap to anyone? This is the parameter to Win32 Join. PROCEDURE Join(t: T): REFANY = VAR res: REFANY; BEGIN LOCK threadMu DO IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; WHILE NOT t.completed DO Wait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; t.cond := NIL; IF perfOn THEN PerfChanged(t.id, State.dead) END; END; RETURN res; END Join; Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. t is at @ebp + here. The pointer then is 00200000 at the start of the second line of the second dump. If we can confirm this is pixmap, we can hunt more around in the gui code. 0:000> dd @ebp+8 0012f964 012ac6a8 02827bf4 02827974 02824c3c 0012f974 02829c40 02829c40 0012f98c 00000006 0012f984 011b9838 012ac6a8 0012f9fc 00000004 0012f994 10017170 000001c7 02829c40 0012f9d8 0012f9a4 0041ffea 02824c3c 02827bf4 02827974 0012f9b4 028250b8 02827974 02827904 02824dd8 0012f9c4 02824c3c 02827bf4 02824d9c 02824d9c 0012f9d4 02824dd8 0012fa8c 00420b98 028250b8 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> .lastevent Last event: ee0.13a4: Access violation - code c0000005 (first chance) debugger time: Thu Sep 3 07:43:12.390 2009 (GMT-7) 0:000> u . l1 m3core!Thread__Join+0x173: 005ebb01 8b5ffc mov ebx,dword ptr [edi-4] 0:000> r edi edi=00200000 0:000> Here is the entire bitmappy looking thing. 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> dd 012ac728 00200000 00200000 00200000 00200000 012ac738 00200000 00200000 00200000 00200000 012ac748 00200000 00200000 00200000 00200000 012ac758 00200000 00200000 00200000 00200000 012ac768 00200000 00200000 00200000 00200000 012ac778 00200000 00200000 00200000 00200000 012ac788 00200000 00200000 00200000 00200000 012ac798 00200000 00200000 00200000 00200000 0:000> 012ac7a8 00200000 00200000 00200000 00200000 012ac7b8 00200000 00200000 00200000 00200000 012ac7c8 00200000 00200000 00200000 00200000 012ac7d8 00200000 00200000 00200000 00200000 012ac7e8 00200000 00200000 00200000 00200000 012ac7f8 00200000 00200000 00200000 00200000 012ac808 00200000 00200000 00200000 00200000 012ac818 00200000 00200000 00200000 00200000 0:000> 012ac828 00200000 00200000 00200000 00200000 012ac838 00200000 00200000 00200000 00200000 012ac848 00200000 00200000 00200000 00200000 012ac858 00200000 00200000 00200000 00200000 012ac868 00200000 00200000 00200000 00200000 012ac878 00200000 00200000 00200000 00200000 012ac888 00200000 00200000 00200000 00200000 012ac898 00200000 00200000 00200000 00200000 0:000> 012ac8a8 00200000 00200000 00200000 00200000 012ac8b8 00200000 00200000 00200000 00200000 012ac8c8 00200000 00200000 00200000 00200000 012ac8d8 00200000 00200000 00200000 00200000 012ac8e8 00200000 00200000 00200000 00200000 012ac8f8 00200000 00200000 00200000 00200000 012ac908 00200000 00200000 00200000 00200000 012ac918 00200000 00200000 00200000 00200000 0:000> 012ac928 00200000 00200000 00200000 00200000 012ac938 00200000 00200000 00200000 00200000 012ac948 00200000 00200000 00200000 00200000 012ac958 00200000 00200000 00200000 00200000 012ac968 00200000 00200000 00200000 00200000 012ac978 00200000 00200000 00200000 00200000 012ac988 00200000 00200000 00200000 00200000 012ac998 00200000 00200000 00200000 00200000 0:000> 012ac9a8 00200000 00200000 00200000 00200000 012ac9b8 00200000 00200000 00200000 00200000 012ac9c8 00200000 00200000 00200000 00200000 012ac9d8 00200000 00200000 00200000 00200000 012ac9e8 00200000 00200000 00200000 00200000 012ac9f8 00200000 00200000 00200000 00200000 012aca08 00200000 00200000 00200000 00200000 012aca18 00200000 00200000 00200000 00200000 0:000> 012aca28 00200000 00200000 00200000 00200000 012aca38 00200000 00200000 00200000 00200000 012aca48 00200000 00200000 00200000 00200000 012aca58 00200000 00200000 00200000 00200000 012aca68 00200000 00200000 00200000 00200000 012aca78 00200000 00200000 00200000 00200000 012aca88 00200000 00200000 00200000 00200000 012aca98 00200000 00200000 00200000 00200000 0:000> 012acaa8 00200000 00200000 00200000 00200000 012acab8 00200000 00200000 00200000 00200000 012acac8 00200000 00200000 00200000 00200000 012acad8 00200000 00200000 00200000 00200000 012acae8 00200000 00200000 00200000 00200000 012acaf8 00200000 00200000 00200000 00200000 012acb08 00200000 00200000 00200000 00200000 012acb18 00200000 00200000 00200000 00200000 0:000> 012acb28 00200000 00200000 00200000 00200000 012acb38 00200000 00200000 00200000 00200000 012acb48 00200000 00200000 00200000 00200000 012acb58 00200000 00200000 00200000 00200000 012acb68 00200000 00200000 00200000 00200000 012acb78 00200000 00200000 00200000 00200000 012acb88 00200000 00200000 00200000 00200000 012acb98 00200000 00200000 00200000 00200000 0:000> 012acba8 00200000 00200000 00200000 00200000 012acbb8 00200000 00200000 00200000 00200000 012acbc8 00200000 00200000 00200000 00200000 012acbd8 00200000 00200000 00200000 00200000 012acbe8 00200000 00200000 00200000 00200000 012acbf8 00200000 00200000 00200000 00200000 012acc08 00200000 00200000 00200000 00200000 012acc18 00200000 00200000 00200000 00200000 0:000> 012acc28 00200000 00200000 00200000 00200000 012acc38 00200000 00200000 00200000 00200000 012acc48 00200000 00200000 00200000 00200000 012acc58 00200000 00200000 00200000 00200000 012acc68 00200000 00200000 00200000 00200000 012acc78 00200000 00200000 00200000 00200000 012acc88 00200000 00200000 00200000 00200000 012acc98 00200000 00200000 00200000 00200000 0:000> 012acca8 00200000 00200000 00200000 00200000 012accb8 00200000 00200000 00200000 00200000 012accc8 00200000 00200000 00200000 00200000 012accd8 00200000 00200000 00200000 00200000 012acce8 00200000 00200000 00200000 00200000 012accf8 00200000 00200000 00200000 00200000 012acd08 00200000 00200000 00200000 00200000 012acd18 00200000 00200000 00200000 00200000 0:000> 012acd28 00200000 00200000 00200000 00200000 012acd38 00200000 00200000 00200000 00200000 012acd48 00200000 00200000 00200000 00200000 012acd58 00200000 00200000 00200000 00200000 012acd68 00200000 00200000 00200000 00200000 012acd78 00200000 00200000 00200000 00200000 012acd88 00200000 00200000 00200000 00200000 012acd98 00200000 00200000 00200000 00200000 0:000> 012acda8 00200000 00200000 00200000 00200000 012acdb8 00200000 00200000 00200000 00200000 012acdc8 00200000 00200000 00200000 00200000 012acdd8 00200000 00200000 00200000 00200000 012acde8 00200000 00200000 00200000 00200000 012acdf8 00200000 00200000 00200000 00200000 012ace08 00200000 00200000 00200000 00200000 012ace18 00200000 00200000 00200000 00200000 0:000> 012ace28 00200000 00200000 00200000 00200000 012ace38 00200000 00200000 00200000 00200000 012ace48 00200000 00200000 00200000 00200000 012ace58 00200000 00200000 00200000 00200000 012ace68 00200000 00200000 00200000 00200000 012ace78 00200000 00200000 00200000 00200000 012ace88 00200000 00200000 00200000 00200000 012ace98 00200000 00200000 00200000 00200000 0:000> 012acea8 00200000 00200000 00200000 00200000 012aceb8 00200000 00200000 00200000 00200000 012acec8 00200000 00200000 00200000 00200000 012aced8 00200000 00200000 00200000 00200000 012acee8 00200000 00200000 00200000 00200000 012acef8 00200000 00200000 00200000 00200000 012acf08 00200000 00200000 00200000 00200000 012acf18 00200000 00200000 00200000 00200000 0:000> 012acf28 00200000 00200000 00200000 00200000 012acf38 00200000 00200000 00200000 00200000 012acf48 00200000 00200000 00200000 00200000 012acf58 00200000 00200000 00200000 00200000 012acf68 00200000 00200000 00200000 00200000 012acf78 00200000 00200000 00200000 00200000 012acf88 00200000 00200000 00200000 00200000 012acf98 00200000 00200000 00200000 00200000 0:000> 012acfa8 00200000 00200000 00200000 00200000 012acfb8 00200000 00200000 00200000 00200000 012acfc8 00200000 00200000 00200000 00200000 012acfd8 00200000 00200000 00200000 00200000 012acfe8 00200000 00200000 00200000 00200000 012acff8 00200000 00200000 00200000 00200000 012ad008 00200000 00200000 00200000 00200000 012ad018 00200000 00200000 00200000 00200000 0:000> 012ad028 00200000 00200000 00200000 00200000 012ad038 00200000 00200000 00200000 00200000 012ad048 00200000 00200000 00200000 00200000 012ad058 00200000 00200000 00200000 00200000 012ad068 00200000 00200000 00200000 00200000 012ad078 00200000 00200000 00200000 00200000 012ad088 00200000 00200000 00200000 00200000 012ad098 00200000 00200000 00200000 00200000 0:000> 012ad0a8 00200000 00200000 00200000 00200000 012ad0b8 00200000 00200000 00200000 00200000 012ad0c8 00200000 00200000 00200000 00200000 012ad0d8 00200000 00200000 00200000 00200000 012ad0e8 00200000 00200000 00200000 00200000 012ad0f8 00200000 00200000 00200000 00200000 012ad108 00200000 00200000 00200000 00200000 012ad118 00200000 00200000 00200000 00200000 0:000> 012ad128 00200000 00200000 00200000 00200000 012ad138 00200000 00200000 00200000 00200000 012ad148 00200000 00200000 00200000 00200000 012ad158 00200000 00200000 00200000 00200000 012ad168 00200000 00200000 00200000 00200000 012ad178 00200000 00200000 00200000 00200000 012ad188 00200000 00200000 00200000 00200000 012ad198 00200000 00200000 00200000 00200000 0:000> 012ad1a8 00200000 00200000 00200000 00200000 012ad1b8 00200000 00200000 00200000 00200000 012ad1c8 00200000 00200000 00200000 00200000 012ad1d8 00200000 00200000 00200000 00200000 012ad1e8 00200000 00200000 00200000 00200000 012ad1f8 00200000 00200000 00200000 00200000 012ad208 00200000 00200000 00200000 00200000 012ad218 00200000 00200000 00200000 00200000 0:000> 012ad228 00200000 00200000 00200000 00200000 012ad238 00200000 00200000 00200000 00200000 012ad248 00200000 00200000 00200000 00200000 012ad258 00200000 00200000 00200000 00200000 012ad268 00200000 00200000 00200000 00200000 012ad278 00200000 00200000 00200000 00200000 012ad288 00200000 00200000 00200000 00200000 012ad298 00200000 00200000 00200000 00200000 0:000> 012ad2a8 00200000 00200000 00200000 00200000 012ad2b8 00200000 00200000 00200000 00200000 012ad2c8 00200000 00200000 00200000 00200000 012ad2d8 00200000 00200000 00200000 00200000 012ad2e8 00200000 00200000 00200000 00200000 012ad2f8 00200000 00200000 00200000 00200000 012ad308 00200000 00200000 00200000 00200000 012ad318 00200000 00200000 00200000 00200000 0:000> 012ad328 00200000 00200000 00200000 00200000 012ad338 00200000 00200000 00200000 00200000 012ad348 00200000 00200000 00200000 00200000 012ad358 00200000 00200000 00200000 00200000 012ad368 00200000 00200000 00200000 00200000 012ad378 00200000 00200000 00200000 00200000 012ad388 00200000 00200000 00200000 00200000 012ad398 00200000 00200000 00200000 00200000 0:000> 012ad3a8 00200000 00200000 00200000 00200000 012ad3b8 00200000 00200000 00200000 00200000 012ad3c8 00200000 00200000 00200000 00200000 012ad3d8 00200000 00200000 00200000 00200000 012ad3e8 00200000 00200000 00200000 00200000 012ad3f8 00200000 00200000 00200000 00200000 012ad408 00200000 00200000 00200000 00200000 012ad418 00200000 00200000 00200000 00200000 0:000> 012ad428 00200000 00200000 00200000 00200000 012ad438 00200000 00200000 00200000 00200000 012ad448 00200000 00200000 00200000 00200000 012ad458 00200000 00200000 00200000 00200000 012ad468 00200000 00200000 00200000 00200000 012ad478 00200000 00200000 00200000 00200000 012ad488 00200000 00200000 00200000 00200000 012ad498 00200000 00200000 00200000 00200000 0:000> 012ad4a8 00200000 00200000 00200000 00200000 012ad4b8 00200000 00200000 00200000 00200000 012ad4c8 00200000 00200000 00200000 00200000 012ad4d8 00200000 00200000 00200000 00200000 012ad4e8 00200000 00200000 00200000 00200000 012ad4f8 00200000 00200000 00200000 00200000 012ad508 00200000 00200000 00200000 00200000 012ad518 00200000 00200000 00200000 00200000 0:000> 012ad528 00200000 00200000 00200000 00200000 012ad538 00200000 00200000 00200000 00200000 012ad548 00200000 00200000 00200000 00200000 012ad558 00200000 00200000 00200000 00200000 012ad568 00200000 00200000 00200000 00200000 012ad578 00200000 00200000 00200000 00200000 012ad588 00200000 00200000 00200000 00200000 012ad598 00200000 00200000 00200000 00200000 0:000> 012ad5a8 00200000 00200000 00200000 00200000 012ad5b8 00200000 00200000 00200000 00200000 012ad5c8 00200000 00200000 00200000 00200000 012ad5d8 00200000 00200000 00200000 00200000 012ad5e8 00200000 00200000 00200000 00200000 012ad5f8 00200000 00200000 00200000 00200000 012ad608 00200000 00200000 00200000 00200000 012ad618 00200000 00200000 00200000 00200000 0:000> 012ad628 00200000 00200000 00200000 00200000 012ad638 00200000 00200000 00200000 00200000 012ad648 00200000 00200000 00200000 00200000 012ad658 00200000 00200000 00200000 00200000 012ad668 00200000 00200000 00200000 00200000 012ad678 00200000 00200000 00200000 00200000 012ad688 00200000 00200000 00200000 00200000 012ad698 00200000 00200000 00200000 00200000 0:000> 012ad6a8 00200000 00200000 00200000 00200000 012ad6b8 00200000 00200000 00200000 00200000 012ad6c8 00200000 00200000 00200000 00200000 012ad6d8 00200000 00200000 00200000 00200000 012ad6e8 00200000 00200000 00200000 00200000 012ad6f8 00200000 00200000 00200000 00200000 012ad708 00200000 00200000 00200000 00200000 012ad718 00200000 00200000 00200000 00200000 0:000> 012ad728 00200000 00200000 00200000 00200000 012ad738 00200000 00200000 00200000 00200000 012ad748 00200000 00200000 00200000 00200000 012ad758 00200000 00200000 00200000 00200000 012ad768 00200000 00200000 00200000 00200000 012ad778 00200000 00200000 00200000 00200000 012ad788 00200000 00200000 00200000 00200000 012ad798 00200000 00200000 00200000 00200000 0:000> 012ad7a8 00200000 00200000 00200000 00200000 012ad7b8 00200000 00200000 00200000 00200000 012ad7c8 00200000 00200000 00200000 00200000 012ad7d8 00200000 00200000 00200000 00200000 012ad7e8 00200000 00200000 00200000 00200000 012ad7f8 00200000 00200000 00200000 00200000 012ad808 00200000 00200000 00200000 00200000 012ad818 00200000 00200000 00200000 00200000 0:000> 012ad828 00200000 00200000 00200000 00200000 012ad838 00200000 00200000 00200000 00200000 012ad848 00200000 00200000 00200000 00200000 012ad858 00200000 00200000 00200000 00200000 012ad868 00200000 00200000 00200000 00200000 012ad878 00200000 00200000 00200000 00200000 012ad888 00200000 00200000 00200000 00200000 012ad898 00200000 00200000 00200000 00200000 0:000> 012ad8a8 00200000 00200000 00200000 00200000 012ad8b8 00200000 00200000 00200000 00200000 012ad8c8 00200000 00200000 00200000 00200000 012ad8d8 00200000 00200000 00200000 00200000 012ad8e8 00200000 00200000 00200000 00200000 012ad8f8 00200000 00200000 00200000 00200000 012ad908 00200000 00200000 00200000 00200000 012ad918 00200000 00200000 00200000 00200000 0:000> 012ad928 00200000 00200000 00200000 00200000 012ad938 00200000 00200000 00200000 00200000 012ad948 00200000 00200000 00200000 00200000 012ad958 00200000 00200000 00200000 00200000 012ad968 00200000 00200000 00200000 00200000 012ad978 00200000 00200000 00200000 00200000 012ad988 00200000 00200000 00200000 00200000 012ad998 00200000 00200000 00200000 00200000 0:000> 012ad9a8 00200000 00200000 00200000 00200000 012ad9b8 00200000 00200000 00200000 00200000 012ad9c8 00200000 00200000 00200000 00200000 012ad9d8 00200000 00200000 00200000 00200000 012ad9e8 00200000 00200000 00200000 00200000 012ad9f8 00200000 00200000 00200000 00200000 012ada08 00200000 00200000 00200000 00200000 012ada18 00200000 00200000 00200000 00200000 0:000> 012ada28 00200000 00200000 00200000 00200000 012ada38 00200000 00200000 00200000 00200000 012ada48 00200000 00200000 00200000 00200000 012ada58 00200000 00200000 00200000 00200000 012ada68 00200000 00200000 00200000 00200000 012ada78 00200000 00200000 00200000 00200000 012ada88 00200000 00200000 00200000 00200000 012ada98 00200000 00200000 00200000 00200000 0:000> 012adaa8 00200000 00200000 00200000 00200000 012adab8 00200000 00200000 00200000 00200000 012adac8 00200000 00200000 00200000 00200000 012adad8 00200000 00200000 00200000 00200000 012adae8 00200000 00200000 00200000 00200000 012adaf8 00200000 00200000 00200000 00200000 012adb08 00200000 00200000 00200000 00200000 012adb18 00200000 00200000 00200000 00200000 0:000> 012adb28 00200000 00200000 00200000 00200000 012adb38 00200000 00200000 00200000 00200000 012adb48 00200000 00200000 00200000 00200000 012adb58 00200000 00200000 00200000 00200000 012adb68 00200000 00200000 00200000 00200000 012adb78 00200000 00200000 00200000 00200000 012adb88 00200000 00200000 00200000 00200000 012adb98 00200000 00200000 00200000 00200000 0:000> 012adba8 00200000 00200000 00200000 00200000 012adbb8 00200000 00200000 00200000 00200000 012adbc8 00200000 00200000 00200000 00200000 012adbd8 00200000 00200000 00200000 00200000 012adbe8 00200000 00200000 00200000 00200000 012adbf8 00200000 00200000 00200000 00200000 012adc08 00200000 00200000 00200000 00200000 012adc18 00200000 00200000 00200000 00200000 0:000> 012adc28 00200000 00200000 00200000 00200000 012adc38 00200000 00200000 00200000 00200000 012adc48 00200000 00200000 00200000 00200000 012adc58 00200000 00200000 00200000 00200000 012adc68 00200000 00200000 00200000 00200000 012adc78 00200000 00200000 00200000 00200000 012adc88 00200000 00200000 00200000 00200000 012adc98 00200000 00200000 00200000 00200000 0:000> 012adca8 00200000 00200000 00200000 00200000 012adcb8 00200000 00200000 00200000 00200000 012adcc8 00200000 00200000 00200000 00200000 012adcd8 00200000 00200000 00200000 00200000 012adce8 00200000 00200000 00200000 00200000 012adcf8 00200000 00200000 00200000 00200000 012add08 00200000 00200000 00200000 00200000 012add18 00200000 00200000 00200000 00200000 0:000> 012add28 00200000 00200000 00200000 00200000 012add38 00200000 00200000 00200000 00200000 012add48 00200000 00200000 00200000 00200000 012add58 00200000 00200000 00200000 00200000 012add68 00200000 00200000 00200000 00200000 012add78 00200000 00200000 00200000 00200000 012add88 00200000 00200000 00200000 00200000 012add98 00200000 00200000 00200000 00200000 0:000> 012adda8 00200000 00200000 00200000 00200000 012addb8 00200000 00200000 00200000 00200000 012addc8 00200000 00200000 00200000 00200000 012addd8 00200000 00200000 00200000 00200000 012adde8 00200000 00200000 00200000 00200000 012addf8 00200000 00200000 00200000 00200000 012ade08 00200000 00200000 00200000 00200000 012ade18 00200000 00200000 00200000 00200000 0:000> 012ade28 00200000 00200000 00200000 00200000 012ade38 00200000 00200000 00200000 00200000 012ade48 00200000 00200000 00200000 00200000 012ade58 00200000 00200000 00200000 00200000 012ade68 00200000 00200000 00200000 00200000 012ade78 00200000 00200000 00200000 00200000 012ade88 00200000 00200000 00200000 00200000 012ade98 00200000 00200000 00200000 00200000 0:000> 012adea8 00200000 00200000 00200000 00200000 012adeb8 00200000 00200000 00200000 00200000 012adec8 00200000 00200000 00200000 00200000 012aded8 00200000 00200000 00200000 00200000 012adee8 00200000 00200000 00200000 00200000 012adef8 00200000 00200000 00200000 00200000 012adf08 00200000 00200000 00200000 00200000 012adf18 00200000 00200000 00200000 00200000 0:000> 012adf28 00200000 00200000 00200000 00200000 012adf38 00200000 00200000 00200000 00200000 012adf48 00200000 00200000 00200000 00200000 012adf58 00200000 00200000 00200000 00200000 012adf68 00200000 00200000 00200000 00200000 012adf78 00200000 00200000 00200000 00200000 012adf88 00200000 00200000 00200000 00200000 012adf98 00200000 00200000 00200000 00200000 0:000> 012adfa8 00200000 00200000 00200000 00200000 012adfb8 00200000 00200000 00200000 00200000 012adfc8 00200000 00200000 00200000 00200000 012adfd8 00200000 00200000 00200000 00200000 012adfe8 00200000 00200000 00200000 00200000 012adff8 00200000 00200000 00200000 00200000 012ae008 00200000 00200000 00200000 00200000 012ae018 00200000 00200000 00200000 00200000 0:000> 012ae028 00200000 00200000 00200000 00200000 012ae038 00200000 00200000 00200000 00200000 012ae048 00200000 00200000 00200000 00200000 012ae058 00200000 00200000 00200000 00200000 012ae068 00200000 00200000 00200000 00200000 012ae078 00200000 00200000 00200000 00200000 012ae088 00200000 00200000 00200000 00200000 012ae098 00200000 00200000 00200000 00200000 0:000> 012ae0a8 00200000 00200000 00200000 00200000 012ae0b8 00200000 00200000 00200000 00200000 012ae0c8 00200000 00200000 00200000 00200000 012ae0d8 00200000 00200000 00200000 00200000 012ae0e8 00200000 00200000 00200000 00200000 012ae0f8 00200000 00200000 00200000 00200000 012ae108 00200000 00200000 00200000 00200000 012ae118 00200000 00200000 00200000 00200000 0:000> 012ae128 00200000 00200000 00200000 00200000 012ae138 00200000 00200000 00200000 00200000 012ae148 00200000 00200000 00200000 00200000 012ae158 00200000 00200000 00200000 00200000 012ae168 00200000 00200000 00200000 00200000 012ae178 00200000 00200000 00200000 00200000 012ae188 00200000 00200000 00200000 00200000 012ae198 00200000 00200000 00200000 00200000 0:000> 012ae1a8 00200000 00200000 00200000 00200000 012ae1b8 00200000 00200000 00200000 00200000 012ae1c8 00200000 00200000 00200000 00200000 012ae1d8 00200000 00200000 00200000 00200000 012ae1e8 00200000 00200000 00200000 00200000 012ae1f8 00200000 00200000 00200000 00200000 012ae208 00200000 00200000 00200000 00200000 012ae218 00200000 00200000 00200000 00200000 0:000> 012ae228 00200000 00200000 00200000 00200000 012ae238 00200000 00200000 00200000 00200000 012ae248 00200000 00200000 00200000 00200000 012ae258 00200000 00200000 00200000 00200000 012ae268 00200000 00200000 00200000 00200000 012ae278 00200000 00200000 00200000 00200000 012ae288 00200000 00200000 00200000 00200000 012ae298 00200000 00200000 00200000 00200000 0:000> 012ae2a8 00200000 00200000 00200000 00200000 012ae2b8 00200000 00200000 00200000 00200000 012ae2c8 00200000 00200000 00200000 00200000 012ae2d8 00200000 00200000 00200000 00200000 012ae2e8 00200000 00200000 00200000 00200000 012ae2f8 00200000 00200000 00200000 00200000 012ae308 00200000 00200000 00200000 00200000 012ae318 00200000 00200000 00200000 00200000 0:000> 012ae328 00200000 00200000 00200000 00200000 012ae338 00200000 00200000 00200000 00200000 012ae348 00200000 00200000 00200000 00200000 012ae358 00200000 00200000 00200000 00200000 012ae368 00200000 00200000 00200000 00200000 012ae378 00200000 00200000 00200000 00200000 012ae388 00200000 00200000 00200000 00200000 012ae398 00200000 00200000 00200000 00200000 0:000> 012ae3a8 00200000 00200000 00200000 00200000 012ae3b8 00200000 00200000 00200000 00200000 012ae3c8 00200000 00200000 00200000 00200000 012ae3d8 00200000 00200000 00200000 00200000 012ae3e8 00200000 00200000 00200000 00200000 012ae3f8 00200000 00200000 00200000 00200000 012ae408 00200000 00200000 00200000 00200000 012ae418 00200000 00200000 00200000 00200000 0:000> 012ae428 00200000 00200000 00200000 00200000 012ae438 00200000 00200000 00200000 00200000 012ae448 00200000 00200000 00200000 00200000 012ae458 00200000 00200000 00200000 00200000 012ae468 00200000 00200000 00200000 00200000 012ae478 00200000 00200000 00200000 00200000 012ae488 00200000 00200000 00200000 00200000 012ae498 00200000 00200000 00200000 00200000 0:000> 012ae4a8 00200000 00200000 00200000 00200000 012ae4b8 00200000 00200000 00200000 00200000 012ae4c8 00200000 00200000 00200000 00200000 012ae4d8 00200000 00200000 00200000 00200000 012ae4e8 00200000 00200000 00200000 00200000 012ae4f8 00200000 00200000 00200000 00200000 012ae508 00200000 00200000 00200000 00200000 012ae518 00200000 00200000 00200000 00200000 0:000> 012ae528 00200000 00200000 00200000 00200000 012ae538 00200000 00200000 00200000 00200000 012ae548 00200000 00200000 00200000 00200000 012ae558 00200000 00200000 00200000 00200000 012ae568 00200000 00200000 00200000 00200000 012ae578 00200000 00200000 00200000 00200000 012ae588 00200000 00200000 00200000 00200000 012ae598 00200000 00200000 00200000 00200000 0:000> 012ae5a8 00200000 00200000 00200000 00200000 012ae5b8 00200000 00200000 00200000 00200000 012ae5c8 00200000 00200000 00200000 00200000 012ae5d8 00200000 00200000 00200000 00200000 012ae5e8 00200000 00200000 00200000 00200000 012ae5f8 00200000 00200000 00200000 00200000 012ae608 00200000 00200000 00200000 00200000 012ae618 00200000 00200000 00200000 00200000 0:000> 012ae628 00200000 00200000 00200000 00200000 012ae638 00200000 00200000 00200000 00200000 012ae648 00200000 00200000 00200000 00200000 012ae658 00200000 00200000 00200000 00200000 012ae668 00200000 00200000 00200000 00200000 012ae678 00200000 00200000 00200000 00200000 012ae688 00200000 00200000 00200000 00200000 012ae698 00200000 00200000 00200000 00200000 0:000> 012ae6a8 00200000 00200000 00200000 00200000 012ae6b8 00200000 00200000 00200000 00200000 012ae6c8 00200000 00200000 00200000 00200000 012ae6d8 00200000 00200000 00200000 00200000 012ae6e8 00200000 00200000 00200000 00200000 012ae6f8 00200000 00200000 00200000 00200000 012ae708 00200000 00200000 00200000 00200000 012ae718 00200000 00200000 00200000 00200000 0:000> 012ae728 00200000 00200000 00200000 00200000 012ae738 00200000 00200000 00200000 00200000 012ae748 00200000 00200000 00200000 00200000 012ae758 00200000 00200000 00200000 00200000 012ae768 00200000 00200000 00200000 00200000 012ae778 00200000 00200000 00200000 00200000 012ae788 00200000 00200000 00200000 00200000 012ae798 00200000 00200000 00200000 00200000 0:000> 012ae7a8 00200000 00200000 00200000 00200000 012ae7b8 00200000 00200000 00200000 00200000 012ae7c8 00200000 00200000 00200000 00200000 012ae7d8 00200000 00200000 00200000 00200000 012ae7e8 00200000 00200000 00200000 00200000 012ae7f8 00200000 00200000 00200000 00200000 012ae808 00200000 00200000 00200000 00200000 012ae818 00200000 00200000 00200000 00200000 0:000> 012ae828 00200000 00200000 00200000 00200000 012ae838 00200000 00200000 00200000 00200000 012ae848 00200000 00200000 00200000 00200000 012ae858 00200000 00200000 00200000 00200000 012ae868 00200000 00200000 00200000 00200000 012ae878 00200000 00200000 00200000 00200000 012ae888 00200000 00200000 00200000 00200000 012ae898 00200000 00200000 00200000 00200000 0:000> 012ae8a8 00200000 00200000 00200000 00200000 012ae8b8 00200000 00200000 00200000 00200000 012ae8c8 00200000 00200000 00200000 00200000 012ae8d8 00200000 00200000 00200000 00200000 012ae8e8 00200000 00200000 00200000 00200000 012ae8f8 00200000 00200000 00200000 00200000 012ae908 00200000 00200000 00200000 00200000 012ae918 00200000 00200000 00200000 00200000 0:000> 012ae928 00200000 00200000 00200000 00200000 012ae938 00200000 00200000 00200000 00200000 012ae948 00200000 00200000 00200000 00200000 012ae958 00200000 00200000 00200000 00200000 012ae968 00200000 00200000 00200000 00200000 012ae978 00200000 00200000 00200000 00200000 012ae988 00200000 00200000 00200000 00200000 012ae998 00200000 00200000 00200000 00200000 0:000> 012ae9a8 00200000 00200000 00200000 00200000 012ae9b8 00200000 00200000 00200000 00200000 012ae9c8 00200000 00200000 00200000 00200000 012ae9d8 00200000 00200000 00200000 00200000 012ae9e8 00200000 00200000 00200000 00200000 012ae9f8 00200000 00200000 00200000 00200000 012aea08 00200000 00200000 00200000 00200000 012aea18 00200000 00200000 00200000 00200000 0:000> 012aea28 00200000 00200000 00200000 00200000 012aea38 00200000 00200000 00200000 00200000 012aea48 00200000 00200000 00200000 00200000 012aea58 00200000 00200000 00200000 00200000 012aea68 00200000 00200000 00200000 00200000 012aea78 00200000 00200000 00200000 00200000 012aea88 00200000 00200000 00200000 00200000 012aea98 00200000 00200000 00200000 00200000 0:000> 012aeaa8 00200000 00200000 00200000 00200000 012aeab8 00200000 00200000 00200000 00200000 012aeac8 00200000 00200000 00200000 00200000 012aead8 00200000 00200000 00200000 00200000 012aeae8 00200000 00200000 00200000 00200000 012aeaf8 00200000 00200000 00200000 00200000 012aeb08 00200000 00200000 00200000 00200000 012aeb18 00200000 00200000 00200000 00200000 0:000> 012aeb28 00200000 00200000 00200000 00200000 012aeb38 00200000 00200000 00200000 00200000 012aeb48 00200000 00200000 00200000 00200000 012aeb58 00200000 00200000 00200000 00200000 012aeb68 00200000 00200000 00200000 00200000 012aeb78 00200000 00200000 00200000 00200000 012aeb88 00200000 00200000 00200000 00200000 012aeb98 00200000 00200000 00200000 00200000 0:000> 012aeba8 00200000 00200000 00200000 00200000 012aebb8 00200000 00200000 00200000 00200000 012aebc8 00200000 00200000 00200000 00200000 012aebd8 00200000 00200000 00200000 00200000 012aebe8 00200000 00200000 00200000 00200000 012aebf8 00200000 00200000 00200000 00200000 012aec08 00200000 00200000 00200000 00200000 012aec18 00200000 00200000 00200000 00200000 0:000> 012aec28 00200000 00200000 00200000 00200000 012aec38 00200000 00200000 00200000 00200000 012aec48 00200000 00200000 00200000 00200000 012aec58 00200000 00200000 00200000 00200000 012aec68 00200000 00200000 00200000 00200000 012aec78 00200000 00200000 00200000 00200000 012aec88 00200000 00200000 00200000 00200000 012aec98 00200000 00200000 00200000 00200000 0:000> 012aeca8 00200000 00200000 00200000 00200000 012aecb8 00200000 00200000 00200000 00200000 012aecc8 00200000 00200000 00200000 00200000 012aecd8 00200000 00200000 00200000 00200000 012aece8 00200000 00200000 00200000 00200000 012aecf8 00200000 00200000 00200000 00200000 012aed08 00200000 00200000 00200000 00200000 012aed18 00200000 00200000 00200000 00200000 0:000> 012aed28 00200000 00200000 00200000 00200000 012aed38 00200000 00200000 00200000 00200000 012aed48 00200000 00200000 00200000 00200000 012aed58 00200000 00200000 00200000 00200000 012aed68 00200000 00200000 00200000 00200000 012aed78 00200000 00200000 00200000 00200000 012aed88 00200000 00200000 00200000 00200000 012aed98 00200000 00200000 00200000 00200000 0:000> 012aeda8 00200000 00200000 00200000 00200000 012aedb8 00200000 00200000 00200000 00200000 012aedc8 00200000 00200000 00200000 00200000 012aedd8 00200000 00200000 00200000 00200000 012aede8 00200000 00200000 00200000 00200000 012aedf8 00200000 00200000 00200000 00200000 012aee08 00200000 00200000 00200000 00200000 012aee18 00200000 00200000 00200000 00200000 0:000> 012aee28 00200000 00200000 00200000 00200000 012aee38 00200000 00200000 00200000 00200000 012aee48 00200000 00200000 00200000 00200000 012aee58 00200000 00200000 00200000 00200000 012aee68 00200000 00200000 00200000 00200000 012aee78 00200000 00200000 00200000 00200000 012aee88 00200000 00200000 00200000 00200000 012aee98 00200000 00200000 00200000 00200000 0:000> 012aeea8 00200000 00200000 00200000 00200000 012aeeb8 00200000 00200000 00200000 00200000 012aeec8 00200000 00200000 00200000 00200000 012aeed8 00200000 00200000 00200000 00200000 012aeee8 00200000 00200000 00200000 00200000 012aeef8 00200000 00200000 00200000 00200000 012aef08 00200000 00200000 00200000 00200000 012aef18 00200000 00200000 00200000 00200000 0:000> 012aef28 00200000 00200000 00200000 00200000 012aef38 00200000 00200000 00200000 00200000 012aef48 00200000 00200000 00200000 00200000 012aef58 00200000 00200000 00200000 00200000 012aef68 00200000 00200000 00200000 00200000 012aef78 00200000 00200000 00200000 00200000 012aef88 00200000 00200000 00200000 00200000 012aef98 00200000 00200000 00200000 00200000 0:000> 012aefa8 00200000 00200000 00200000 00200000 012aefb8 00200000 00200000 00200000 00200000 012aefc8 00200000 00200000 00200000 00200000 012aefd8 00200000 00200000 00200000 00200000 012aefe8 00200000 00200000 00200000 00200000 012aeff8 00200000 00200000 00200000 00200000 012af008 00200000 00200000 00200000 00200000 012af018 00200000 00200000 00200000 00200000 0:000> 012af028 00200000 00200000 00200000 00200000 012af038 00200000 00200000 00200000 00200000 012af048 00200000 00200000 00200000 00200000 012af058 00200000 00200000 00200000 00200000 012af068 00200000 00200000 00200000 00200000 012af078 00200000 00200000 00200000 00200000 012af088 00200000 00200000 00200000 00200000 012af098 00200000 00200000 00200000 00200000 0:000> 012af0a8 00200000 00200000 00200000 00200000 012af0b8 00200000 00200000 00200000 00200000 012af0c8 00200000 00200000 00200000 00200000 012af0d8 00200000 00200000 00200000 00200000 012af0e8 00200000 00200000 00200000 00200000 012af0f8 00200000 00200000 00200000 00200000 012af108 00200000 00200000 00200000 00200000 012af118 00200000 00200000 00200000 00200000 0:000> 012af128 00200000 00200000 00200000 00200000 012af138 00200000 00200000 00200000 00200000 012af148 00200000 00200000 00200000 00200000 012af158 00200000 00200000 00200000 00200000 012af168 00200000 00200000 00200000 00200000 012af178 00200000 00200000 00200000 00200000 012af188 00200000 00200000 00200000 00200000 012af198 00200000 00200000 00200000 00200000 0:000> 012af1a8 00200000 00200000 00200000 00200000 012af1b8 00200000 00200000 00200000 00200000 012af1c8 00200000 00200000 00200000 00200000 012af1d8 00200000 00200000 00200000 00200000 012af1e8 00200000 00200000 00200000 00200000 012af1f8 00200000 00200000 00200000 00200000 012af208 00200000 00200000 00200000 00200000 012af218 00200000 00200000 00200000 00200000 0:000> 012af228 00200000 00200000 00200000 00200000 012af238 00200000 00200000 00200000 00200000 012af248 00200000 00200000 00200000 00200000 012af258 00200000 00200000 00200000 00200000 012af268 00200000 00200000 00200000 00200000 012af278 00200000 00200000 00200000 00200000 012af288 00200000 00200000 00200000 00200000 012af298 00200000 00200000 00200000 00200000 0:000> 012af2a8 00200000 00200000 00200000 00200000 012af2b8 00200000 00200000 00200000 00200000 012af2c8 00200000 00200000 00200000 00200000 012af2d8 00200000 00200000 00200000 00200000 012af2e8 00200000 00200000 00200000 00200000 012af2f8 00200000 00200000 00200000 00200000 012af308 00200000 00200000 00200000 00200000 012af318 00200000 00200000 00200000 00200000 0:000> 012af328 00200000 00200000 00200000 00200000 012af338 00200000 00200000 00200000 00200000 012af348 00200000 00200000 00200000 00200000 012af358 00200000 00200000 00200000 00200000 012af368 00200000 00200000 00200000 00200000 012af378 00200000 00200000 00200000 00200000 012af388 00200000 00200000 00200000 00200000 012af398 00200000 00200000 00200000 00200000 0:000> 012af3a8 00200000 00200000 00200000 00200000 012af3b8 00200000 00200000 00200000 00200000 012af3c8 00200000 00200000 00200000 00200000 012af3d8 00200000 00200000 00200000 00200000 012af3e8 00200000 00200000 00200000 00200000 012af3f8 00200000 00200000 00200000 00200000 012af408 00200000 00200000 00200000 00200000 012af418 00200000 00200000 00200000 00200000 0:000> 012af428 00200000 00200000 00200000 00200000 012af438 00200000 00200000 00200000 00200000 012af448 00200000 00200000 00200000 00200000 012af458 00200000 00200000 00200000 00200000 012af468 00200000 00200000 00200000 00200000 012af478 00200000 00200000 00200000 00200000 012af488 00200000 00200000 00200000 00200000 012af498 00200000 00200000 00200000 00200000 0:000> 012af4a8 00200000 00200000 00200000 00200000 012af4b8 00200000 00200000 00200000 00200000 012af4c8 00200000 00200000 00200000 00200000 012af4d8 00200000 00200000 00200000 00200000 012af4e8 00200000 00200000 00200000 00200000 012af4f8 00200000 00200000 00200000 00200000 012af508 00200000 00200000 00200000 00200000 012af518 00200000 00200000 00200000 00200000 0:000> 012af528 00200000 00200000 00200000 00200000 012af538 00200000 00200000 00200000 00200000 012af548 00200000 00200000 00200000 00200000 012af558 00200000 00200000 00200000 00200000 012af568 00200000 00200000 00200000 00200000 012af578 00200000 00200000 00200000 00200000 012af588 00200000 00200000 00200000 00200000 012af598 00200000 00200000 00200000 00200000 0:000> 012af5a8 00200000 00200000 00200000 00200000 012af5b8 00200000 00200000 00200000 00200000 012af5c8 00200000 00200000 00200000 00200000 012af5d8 00200000 00200000 00200000 00200000 012af5e8 00200000 00200000 00200000 00200000 012af5f8 00200000 00200000 00200000 00200000 012af608 00200000 00200000 00200000 00200000 012af618 00200000 00200000 00200000 00200000 0:000> 012af628 00200000 00200000 00200000 00200000 012af638 00200000 00200000 00200000 00200000 012af648 00200000 00200000 00200000 00200000 012af658 00200000 00200000 00200000 00200000 012af668 00200000 00200000 00200000 00200000 012af678 00200000 00200000 00200000 00200000 012af688 00200000 00200000 00200000 00200000 012af698 00200000 00200000 00200000 00200000 0:000> 012af6a8 00200000 00200000 00200000 00200000 012af6b8 00200000 00200000 00200000 00200000 012af6c8 00200000 00200000 00200000 00200000 012af6d8 00200000 00200000 00200000 00200000 012af6e8 00200000 00200000 00200000 00200000 012af6f8 00200000 00200000 00200000 00200000 012af708 00200000 00200000 00200000 00200000 012af718 00200000 00200000 00200000 00200000 0:000> 012af728 00200000 00200000 00200000 00200000 012af738 00200000 00200000 00200000 00200000 012af748 00200000 00200000 00200000 00200000 012af758 00200000 00200000 00200000 00200000 012af768 00200000 00200000 00200000 00200000 012af778 00200000 00200000 00200000 00200000 012af788 00200000 00200000 00200000 00200000 012af798 00200000 00200000 00200000 00200000 0:000> 012af7a8 00200000 00200000 00200000 00200000 012af7b8 00200000 00200000 00200000 00200000 012af7c8 00200000 00200000 00200000 00200000 012af7d8 00200000 00200000 00200000 00200000 012af7e8 00200000 00200000 00200000 00200000 012af7f8 00200000 00200000 00200000 00200000 012af808 00200000 00200000 00200000 00200000 012af818 00200000 00200000 00200000 00200000 0:000> 012af828 00200000 00200000 00200000 00200000 012af838 00200000 00200000 00200000 00200000 012af848 00200000 00200000 00200000 00200000 012af858 00200000 00200000 00200000 00200000 012af868 00200000 00200000 00200000 00200000 012af878 00200000 00200000 00200000 00200000 012af888 00200000 00200000 00200000 00200000 012af898 00200000 00200000 00200000 00200000 0:000> 012af8a8 00200000 00200000 00200000 00200000 012af8b8 00200000 00200000 00200000 00200000 012af8c8 00200000 00200000 00200000 00200000 012af8d8 00200000 00200000 00200000 00200000 012af8e8 00200000 00200000 00200000 00200000 012af8f8 00200000 00200000 00200000 00200000 012af908 00200000 00200000 00200000 00200000 012af918 00200000 00200000 00200000 00200000 0:000> 012af928 00200000 00200000 00200000 00200000 012af938 00200000 00200000 00200000 00200000 012af948 00200000 00200000 00200000 00200000 012af958 00200000 00200000 00200000 00200000 012af968 00200000 00200000 00200000 00200000 012af978 00200000 00200000 00200000 00200000 012af988 00200000 00200000 00200000 00200000 012af998 00200000 00200000 00200000 00200000 0:000> 012af9a8 00200000 00200000 00200000 00200000 012af9b8 00200000 00200000 00200000 00200000 012af9c8 00200000 00200000 00200000 00200000 012af9d8 00200000 00200000 00200000 00200000 012af9e8 00200000 00200000 00200000 00200000 012af9f8 00200000 00200000 00200000 00200000 012afa08 00200000 00200000 00200000 00200000 012afa18 00200000 00200000 00200000 00200000 0:000> 012afa28 00200000 00200000 00200000 00200000 012afa38 00200000 00200000 00200000 00200000 012afa48 00200000 00200000 00200000 00200000 012afa58 00200000 00200000 00200000 00200000 012afa68 00200000 00200000 00200000 00200000 012afa78 00200000 00200000 00200000 00200000 012afa88 00200000 00200000 00200000 00200000 012afa98 00200000 00200000 00200000 00200000 0:000> 012afaa8 00200000 00200000 00200000 00200000 012afab8 00200000 00200000 00200000 00200000 012afac8 00200000 00200000 00200000 00200000 012afad8 00200000 00200000 00200000 00200000 012afae8 00200000 00200000 00200000 00200000 012afaf8 00200000 00200000 00200000 00200000 012afb08 00200000 00200000 00200000 00200000 012afb18 00200000 00200000 00200000 00200000 0:000> 012afb28 00200000 00200000 00200000 00200000 012afb38 00200000 00200000 00200000 00200000 012afb48 00200000 00200000 00200000 00200000 012afb58 00200000 00200000 00200000 00200000 012afb68 00200000 00200000 00200000 00200000 012afb78 00200000 00200000 00200000 00200000 012afb88 00200000 00200000 00200000 00200000 012afb98 00200000 00200000 00200000 00200000 0:000> 012afba8 00200000 00200000 00200000 00200000 012afbb8 00200000 00200000 00200000 00200000 012afbc8 00200000 00200000 00200000 00200000 012afbd8 00200000 00200000 00200000 00200000 012afbe8 00200000 00200000 00200000 00200000 012afbf8 00200000 00200000 00200000 00200000 012afc08 00200000 00200000 00200000 00200000 012afc18 00200000 00200000 00200000 00200000 0:000> 012afc28 00200000 00200000 00200000 00200000 012afc38 00200000 00200000 00200000 00200000 012afc48 00200000 00200000 00200000 00200000 012afc58 00200000 00200000 00200000 00200000 012afc68 00200000 00200000 00200000 00200000 012afc78 00200000 00200000 00200000 00200000 012afc88 00200000 00200000 00200000 00200000 012afc98 00200000 00200000 00200000 00200000 0:000> 012afca8 00200000 00200000 00200000 00200000 012afcb8 00200000 00200000 00200000 00200000 012afcc8 00200000 00200000 00200000 00200000 012afcd8 00200000 00200000 00200000 00200000 012afce8 00200000 00200000 00200000 00200000 012afcf8 00200000 00200000 00200000 00200000 012afd08 00200000 00200000 00200000 00200000 012afd18 00200000 00200000 00200000 00200000 0:000> 012afd28 00200000 00200000 00200000 00200000 012afd38 00200000 00200000 00200000 00200000 012afd48 00200000 00200000 00200000 00200000 012afd58 00200000 00200000 00200000 00200000 012afd68 00200000 00200000 00200000 00200000 012afd78 00200000 00200000 00200000 00200000 012afd88 00200000 00200000 00200000 00200000 012afd98 00200000 00200000 00200000 00200000 0:000> 012afda8 00200000 00200000 00200000 00200000 012afdb8 00200000 00200000 00200000 00200000 012afdc8 00200000 00200000 00200000 00200000 012afdd8 00200000 00200000 00200000 00200000 012afde8 00200000 00200000 00200000 00200000 012afdf8 00200000 00200000 00200000 00200000 012afe08 00200000 00200000 00200000 00200000 012afe18 00200000 00200000 00200000 00200000 0:000> 012afe28 00200000 00200000 00200000 00200000 012afe38 00200000 00200000 00200000 00200000 012afe48 00200000 00200000 00200000 00200000 012afe58 00200000 00200000 00200000 00200000 012afe68 00200000 00200000 00200000 00200000 012afe78 00200000 00200000 00200000 00200000 012afe88 00200000 00200000 00200000 00200000 012afe98 00200000 00200000 00200000 00200000 0:000> 012afea8 00200000 00200000 00200000 00200000 012afeb8 00200000 00200000 00200000 00200000 012afec8 00200000 00200000 00200000 00200000 012afed8 00200000 00200000 00200000 00200000 012afee8 00200000 00200000 00200000 00200000 012afef8 00200000 00200000 00200000 00200000 012aff08 00200000 00200000 00200000 00200000 012aff18 00200000 00200000 00200000 00200000 0:000> 012aff28 00200000 00200000 00200000 00200000 012aff38 00200000 00200000 00200000 00200000 012aff48 00200000 00200000 00200000 00200000 012aff58 00200000 00200000 00200000 00200000 012aff68 00200000 00200000 00200000 00200000 012aff78 00200000 00200000 00200000 00200000 012aff88 00200000 00200000 00200000 00200000 012aff98 00200000 00200000 00200000 00200000 0:000> 012affa8 00200000 00200000 00200000 00200000 012affb8 00200000 00200000 00200000 00200000 012affc8 00200000 00200000 00200000 00200000 012affd8 00200000 00200000 00200000 00200000 012affe8 00200000 00200000 00200000 00200000 012afff8 00200000 00200000 00000013 00000001 012b0008 00200026 012b0014 0000172e 00000000 012b0018 00000000 00000000 00000000 00000000 0:000> 012b0028 00000000 00000000 00000000 00000000 012b0038 00000000 00000000 00000000 00000000 012b0048 00000000 00000000 00000000 00000000 012b0058 00000000 00000000 00000000 00000000 012b0068 00000000 00000000 00000000 00000000 012b0078 00000000 00000000 00000000 00000000 012b0088 00000000 00000000 00000000 00000000 012b0098 00000000 00000000 00000000 00000000 0:000> 012b00a8 00000000 00000000 00000000 00000000 012b00b8 00000000 00000000 00000000 00000000 012b00c8 00000000 00000000 00000000 00000000 012b00d8 00000000 00000000 00000000 00000000 012b00e8 00000000 00000000 00000000 00000000 012b00f8 00000000 00000000 00000000 00000000 012b0108 00000000 00000000 00000000 00000000 012b0118 00000000 00000000 00000000 00000000 0:000> 012b0128 00000000 00000000 00000000 00000000 012b0138 00000000 00000000 00000000 00000000 012b0148 00000000 00000000 00000000 00000000 012b0158 00000000 00000000 00000000 00000000 012b0168 00000000 00000000 00000000 00000000 012b0178 00000000 00000000 00000000 00000000 012b0188 00000000 00000000 00000000 00000000 012b0198 00000000 00000000 00000000 00000000 0:000> 012b01a8 00000000 00000000 00000000 00000000 012b01b8 00000000 00000000 00000000 00000000 012b01c8 00000000 00000000 00000000 00000000 012b01d8 00000000 00000000 00000000 00000000 012b01e8 00000000 00000000 00000000 00000000 012b01f8 00000000 00000000 00000000 00000000 012b0208 00000000 00000000 00000000 00000000 012b0218 00000000 00000000 00000000 00000000 0:000> 012b0228 00000000 00000000 00000000 00000000 012b0238 00000000 00000000 00000000 00000000 012b0248 00000000 00000000 00000000 00000000 012b0258 00000000 00000000 00000000 00000000 012b0268 00000000 00000000 00000000 00000000 012b0278 00000000 00000000 00000000 00000000 012b0288 00000000 00000000 00000000 00000000 012b0298 00000000 00000000 00000000 00000000 0:000> 012b02a8 00000000 00000000 00000000 00000000 012b02b8 00000000 00000000 00000000 00000000 012b02c8 00000000 00000000 00000000 00000000 012b02d8 00000000 00000000 00000000 00000000 012b02e8 00000000 00000000 00000000 00000000 012b02f8 00000000 00000000 00000000 00000000 012b0308 00000000 00000000 00000000 00000000 012b0318 00000000 00000000 00000000 00000000 0:000> 012b0328 00000000 00000000 00000000 00000000 012b0338 00000000 00000000 00000000 00000000 012b0348 00000000 00000000 55000000 55005500 012b0358 55005500 55005500 55005500 55005500 012b0368 55005500 55005500 55005500 55005500 012b0378 55005500 55005500 55005500 55005500 012b0388 55005500 55005500 55005500 55005500 012b0398 55005500 55005500 55005500 55005500 0:000> 012b03a8 55005500 55005500 55005500 55005500 012b03b8 55005500 55005500 55005500 55005500 012b03c8 55005500 55005500 55005500 55005500 012b03d8 55005500 55005500 55005500 55005500 012b03e8 55005500 55005500 55005500 55005500 012b03f8 55005500 55005500 55005500 55005500 012b0408 55005500 55005500 55005500 55005500 012b0418 55005500 55005500 55005500 55005500 0:000> 012b0428 55005500 55005500 55005500 55005500 012b0438 55005500 55005500 55005500 55005500 012b0448 55005500 55005500 55005500 55005500 012b0458 55005500 55005500 00000000 55000000 012b0468 55000055 55000055 55000055 55000055 012b0478 55000055 55000055 55000055 55000055 012b0488 55000055 55000055 55000055 55000055 012b0498 55000055 55000055 55000055 55000055 0:000> 012b04a8 55000055 55000055 55000055 55000055 012b04b8 55000055 55000055 55000055 55000055 012b04c8 55000055 55000055 55000055 55000055 012b04d8 55000055 55000055 55000055 55000055 012b04e8 55000055 55000055 55000055 55000055 012b04f8 55000055 55000055 55000055 55000055 012b0508 55000055 55000055 55000055 55000055 012b0518 55000055 55000055 55000055 55000055 0:000> 012b0528 55000055 55000055 55000055 55000055 012b0538 55000055 55000055 55000055 55000055 012b0548 55000055 55000055 55000055 55000055 012b0558 55000055 55000055 55000055 55000055 012b0568 55000055 55000055 55000055 00000000 012b0578 00000000 00555555 00555555 00555555 012b0588 00555555 00555555 00555555 00555555 012b0598 00555555 00555555 00555555 00555555 0:000> 012b05a8 00555555 00555555 00555555 00555555 012b05b8 00555555 00555555 00555555 00555555 012b05c8 00555555 00555555 00555555 00555555 012b05d8 00555555 00555555 00555555 00555555 012b05e8 00555555 00555555 00555555 00555555 012b05f8 00555555 00555555 00555555 00555555 012b0608 00555555 00555555 00555555 00555555 012b0618 00555555 00555555 00555555 00555555 0:000> 012b0628 00555555 00555555 00555555 00555555 012b0638 00555555 00555555 00555555 00555555 012b0648 00555555 00555555 00555555 00555555 012b0658 00555555 00555555 00555555 00555555 012b0668 00555555 00555555 00555555 00555555 012b0678 00555555 00555555 00555555 00555555 012b0688 00000000 55000000 55005500 55005500 012b0698 55005500 55005500 55005500 55005500 0:000> 012b06a8 55005500 55005500 55005500 55005500 012b06b8 55005500 55005500 55005500 55005500 012b06c8 55005500 55005500 55005500 55005500 012b06d8 55005500 55005500 55005500 55005500 012b06e8 55005500 55005500 55005500 55005500 012b06f8 55005500 55005500 55005500 55005500 012b0708 55005500 55005500 55005500 55005500 012b0718 55005500 55005500 55005500 55005500 0:000> 012b0728 55005500 55005500 55005500 55005500 012b0738 55005500 55005500 55005500 55005500 012b0748 55005500 55005500 55005500 55005500 012b0758 55005500 55005500 55005500 55005500 012b0768 55005500 55005500 55005500 55005500 012b0778 55005500 55005500 55005500 55005500 012b0788 55005500 55005500 55005500 55005500 012b0798 55005500 00000000 00000000 00555500 0:000> 012b07a8 00555500 00555500 00555500 00555500 012b07b8 00555500 00555500 00555500 00555500 012b07c8 00555500 00555500 00555500 00555500 012b07d8 00555500 00555500 00555500 00555500 012b07e8 00555500 00555500 00555500 00555500 012b07f8 00555500 00555500 00555500 00555500 012b0808 00555500 00555500 00555500 00555500 012b0818 00555500 00555500 00555500 00555500 0:000> 012b0828 00555500 00555500 00555500 00555500 012b0838 00555500 00555500 00555500 00555500 012b0848 00555500 00555500 00555500 00555500 012b0858 00555500 00555500 00555500 00555500 012b0868 00555500 00555500 00555500 00555500 012b0878 00555500 00555500 00555500 00555500 012b0888 00555500 00555500 00555500 00555500 012b0898 00555500 00555500 00555500 00555500 0:000> 012b08a8 00555500 00555500 00000000 55000000 012b08b8 55550055 55550055 55550055 55550055 012b08c8 55550055 55550055 55550055 55550055 012b08d8 55550055 55550055 55550055 55550055 012b08e8 55550055 55550055 55550055 55550055 012b08f8 55550055 55550055 55550055 55550055 012b0908 55550055 55550055 55550055 55550055 012b0918 55550055 55550055 55550055 55550055 0:000> 012b0928 55550055 55550055 55550055 55550055 012b0938 55550055 55550055 55550055 55550055 012b0948 55550055 55550055 55550055 55550055 012b0958 55550055 55550055 55550055 55550055 012b0968 55550055 55550055 55550055 55550055 012b0978 55550055 55550055 55550055 55550055 012b0988 55550055 55550055 55550055 55550055 012b0998 55550055 55550055 55550055 55550055 0:000> 012b09a8 55550055 55550055 55550055 55550055 012b09b8 55550055 55550055 55550055 00000000 012b09c8 55000000 55005500 55005500 55005500 012b09d8 55005500 55005500 55005500 55005500 012b09e8 55005500 55005500 55005500 55005500 012b09f8 55005500 55005500 55005500 55005500 012b0a08 55005500 55005500 55005500 55005500 012b0a18 55005500 55005500 55005500 55005500 0:000> 012b0a28 55005500 55005500 55005500 55005500 012b0a38 55005500 55005500 55005500 55005500 012b0a48 55005500 55005500 55005500 55005500 012b0a58 55005500 55005500 55005500 55005500 012b0a68 55005500 55005500 55005500 55005500 012b0a78 55005500 55005500 55005500 55005500 012b0a88 55005500 55005500 55005500 55005500 012b0a98 55005500 55005500 55005500 55005500 0:000> 012b0aa8 55005500 55005500 55005500 55005500 012b0ab8 55005500 55005500 55005500 55005500 012b0ac8 55005500 55005500 55005500 55005500 012b0ad8 00000000 55000000 55000055 55000055 012b0ae8 55000055 55000055 55000055 55000055 012b0af8 55000055 55000055 55000055 55000055 012b0b08 55000055 55000055 55000055 55000055 012b0b18 55000055 55000055 55000055 55000055 0:000> 012b0b28 55000055 55000055 55000055 55000055 012b0b38 55000055 55000055 55000055 55000055 012b0b48 55000055 55000055 55000055 55000055 012b0b58 55000055 55000055 55000055 55000055 012b0b68 55000055 55000055 55000055 55000055 012b0b78 55000055 55000055 55000055 55000055 012b0b88 55000055 55000055 55000055 55000055 012b0b98 55000055 55000055 55000055 55000055 0:000> 012b0ba8 55000055 55000055 55000055 55000055 012b0bb8 55000055 55000055 55000055 55000055 012b0bc8 55000055 55000055 55000055 55000055 012b0bd8 55000055 55000055 55000055 55000055 012b0be8 55000055 00000000 00000000 00555555 012b0bf8 00555555 00555555 00555555 00555555 012b0c08 00555555 00555555 00555555 00555555 012b0c18 00555555 00555555 00555555 00555555 0:000> 012b0c28 00555555 00555555 00555555 00555555 012b0c38 00555555 00555555 00555555 00555555 012b0c48 00555555 00555555 00555555 00555555 012b0c58 00555555 00555555 00555555 00555555 012b0c68 00555555 00555555 00555555 00555555 012b0c78 00555555 00555555 00555555 00555555 012b0c88 00555555 00555555 00555555 00555555 012b0c98 00555555 00555555 00555555 00555555 0:000> 012b0ca8 00555555 00555555 00555555 00555555 012b0cb8 00555555 00555555 00555555 00555555 012b0cc8 00555555 00555555 00555555 00555555 012b0cd8 00555555 00555555 00555555 00555555 012b0ce8 00555555 00555555 00555555 00555555 012b0cf8 00555555 00555555 00000000 55000000 012b0d08 55005500 55005500 55005500 55005500 012b0d18 55005500 55005500 55005500 55005500 0:000> 012b0d28 55005500 55005500 55005500 55005500 012b0d38 55005500 55005500 55005500 55005500 012b0d48 55005500 55005500 55005500 55005500 012b0d58 55005500 55005500 55005500 55005500 012b0d68 55005500 55005500 55005500 55005500 012b0d78 55005500 55005500 55005500 55005500 012b0d88 55005500 55005500 55005500 55005500 012b0d98 55005500 55005500 55005500 55005500 0:000> 012b0da8 55005500 55005500 55005500 55005500 012b0db8 55005500 55005500 55005500 55005500 012b0dc8 55005500 55005500 55005500 55005500 012b0dd8 55005500 55005500 55005500 55005500 012b0de8 55005500 55005500 55005500 55005500 012b0df8 55005500 55005500 55005500 55005500 012b0e08 55005500 55005500 55005500 00000000 012b0e18 00000000 00555500 00555500 00555500 0:000> 012b0e28 00555500 00555500 00555500 00555500 012b0e38 00555500 00555500 00555500 00555500 012b0e48 00555500 00555500 00555500 00555500 012b0e58 00555500 00555500 00555500 00555500 012b0e68 00555500 00555500 00555500 00555500 012b0e78 00555500 00555500 00555500 00555500 012b0e88 00555500 00555500 00555500 00555500 012b0e98 00555500 00555500 00555500 00555500 0:000> 012b0ea8 00555500 00555500 00555500 00555500 012b0eb8 00555500 00555500 00555500 00555500 012b0ec8 00555500 00555500 00555500 00555500 012b0ed8 00555500 00555500 00555500 00555500 012b0ee8 00555500 00555500 00555500 00555500 012b0ef8 00555500 00555500 00555500 00555500 012b0f08 00555500 00555500 00555500 00555500 012b0f18 00555500 00555500 00555500 00555500 0:000> 012b0f28 00000000 55000000 55550055 55550055 012b0f38 55550055 55550055 55550055 55550055 012b0f48 55550055 55550055 55550055 55550055 012b0f58 55550055 55550055 55550055 55550055 012b0f68 55550055 55550055 55550055 55550055 012b0f78 55550055 55550055 55550055 55550055 012b0f88 55550055 55550055 55550055 55550055 012b0f98 55550055 55550055 55550055 55550055 0:000> 012b0fa8 55550055 55550055 55550055 55550055 012b0fb8 55550055 55550055 55550055 55550055 012b0fc8 55550055 55550055 55550055 55550055 012b0fd8 55550055 55550055 55550055 55550055 012b0fe8 55550055 55550055 55550055 55550055 012b0ff8 55550055 55550055 55550055 55550055 012b1008 55550055 55550055 55550055 55550055 012b1018 55550055 55550055 55550055 55550055 0:000> 012b1028 55550055 55550055 55550055 55550055 012b1038 55550055 00000000 55000000 55005500 012b1048 55005500 55005500 55005500 55005500 012b1058 55005500 55005500 55005500 55005500 012b1068 55005500 55005500 55005500 55005500 012b1078 55005500 55005500 55005500 55005500 012b1088 55005500 55005500 55005500 55005500 012b1098 55005500 55005500 55005500 55005500 0:000> 012b10a8 55005500 55005500 55005500 55005500 012b10b8 55005500 55005500 55005500 55005500 012b10c8 55005500 55005500 55005500 55005500 012b10d8 55005500 55005500 55005500 55005500 012b10e8 55005500 55005500 55005500 55005500 012b10f8 55005500 55005500 55005500 55005500 012b1108 55005500 55005500 55005500 55005500 012b1118 55005500 55005500 55005500 55005500 0:000> 012b1128 55005500 55005500 55005500 55005500 012b1138 55005500 55005500 55005500 55005500 012b1148 55005500 55005500 00000000 55000000 012b1158 55000055 55000055 55000055 55000055 012b1168 55000055 55000055 55000055 55000055 012b1178 55000055 55000055 55000055 55000055 012b1188 55000055 55000055 55000055 55000055 012b1198 55000055 55000055 55000055 55000055 0:000> 012b11a8 55000055 55000055 55000055 55000055 012b11b8 55000055 55000055 55000055 55000055 012b11c8 55000055 55000055 55000055 55000055 012b11d8 55000055 55000055 55000055 55000055 012b11e8 55000055 55000055 55000055 55000055 012b11f8 55000055 55000055 55000055 55000055 012b1208 55000055 55000055 55000055 55000055 012b1218 55000055 55000055 55000055 55000055 0:000> 012b1228 55000055 55000055 55000055 55000055 012b1238 55000055 55000055 55000055 55000055 012b1248 55000055 55000055 55000055 55000055 012b1258 55000055 55000055 55000055 00000000 012b1268 00000000 00555555 00555555 00555555 012b1278 00555555 00555555 00555555 00555555 012b1288 00555555 00555555 00555555 00555555 012b1298 00555555 00555555 00555555 00555555 0:000> 012b12a8 00555555 00555555 00555555 00555555 012b12b8 00555555 00555555 00555555 00555555 012b12c8 00555555 00555555 00555555 00555555 012b12d8 00555555 00555555 00555555 00555555 012b12e8 00555555 00555555 00555555 00555555 012b12f8 00555555 00555555 00555555 00555555 012b1308 00555555 00555555 00555555 00555555 012b1318 00555555 00555555 00555555 00555555 0:000> 012b1328 00555555 00555555 00555555 00555555 012b1338 00555555 00555555 00555555 00555555 012b1348 00555555 00555555 00555555 00555555 012b1358 00555555 00555555 00555555 00555555 012b1368 00555555 00555555 00555555 00555555 012b1378 00000000 55000000 55005500 55005500 012b1388 55005500 55005500 55005500 55005500 012b1398 55005500 55005500 55005500 55005500 0:000> 012b13a8 55005500 55005500 55005500 55005500 012b13b8 55005500 55005500 55005500 55005500 012b13c8 55005500 55005500 55005500 55005500 012b13d8 55005500 55005500 55005500 55005500 012b13e8 55005500 55005500 55005500 55005500 012b13f8 55005500 55005500 55005500 55005500 012b1408 55005500 55005500 55005500 55005500 012b1418 55005500 55005500 55005500 55005500 0:000> 012b1428 55005500 55005500 55005500 55005500 012b1438 55005500 55005500 55005500 55005500 012b1448 55005500 55005500 55005500 55005500 012b1458 55005500 55005500 55005500 55005500 012b1468 55005500 55005500 55005500 55005500 012b1478 55005500 55005500 55005500 55005500 012b1488 55005500 00000000 00000000 00555500 012b1498 00555500 00555500 00555500 00555500 0:000> 012b14a8 00555500 00555500 00555500 00555500 012b14b8 00555500 00555500 00555500 00555500 012b14c8 00555500 00555500 00555500 00555500 012b14d8 00555500 00555500 00555500 00555500 012b14e8 00555500 00555500 00555500 00555500 012b14f8 00555500 00555500 00555500 00555500 012b1508 00555500 00555500 00555500 00555500 012b1518 00555500 00555500 00555500 00555500 0:000> 012b1528 00555500 00555500 00555500 00555500 012b1538 00555500 00555500 00555500 00555500 012b1548 00555500 00555500 00555500 00555500 012b1558 00555500 00555500 00555500 00555500 012b1568 00555500 00555500 00555500 00555500 012b1578 00555500 00555500 00555500 00555500 012b1588 00555500 00555500 00555500 00555500 012b1598 00555500 00555500 00000000 55000000 0:000> 012b15a8 55550055 55550055 55550055 55550055 012b15b8 55550055 55550055 55550055 55550055 012b15c8 55550055 55550055 55550055 55550055 012b15d8 55550055 55550055 55550055 55550055 012b15e8 55550055 ff550055 ffffffff ffffffff 012b15f8 ffffffff 55550055 ffffffff ffffffff 012b1608 555500ff 55550055 55550055 55550055 012b1618 55550055 55550055 ffff0055 ffffffff 0:000> 012b1628 5555ffff 55550055 ff550055 ffffffff 012b1638 55ffffff 55550055 55550055 55550055 012b1648 55550055 55550055 55550055 55550055 012b1658 55550055 55550055 55550055 55550055 012b1668 55550055 55550055 55550055 55550055 012b1678 55550055 55550055 55550055 55550055 012b1688 55550055 55550055 55550055 55550055 012b1698 55550055 55550055 55550055 55550055 0:000> 012b16a8 55550055 55550055 55550055 00000000 012b16b8 55000000 55005500 55005500 55005500 012b16c8 55005500 55005500 55005500 55005500 012b16d8 55005500 55005500 55005500 55005500 012b16e8 55005500 55005500 55005500 55005500 012b16f8 55005500 55005500 55005500 ffffff00 012b1708 ffffffff 550055ff 55005500 ff005500 012b1718 55ffffff 55005500 55005500 55005500 0:000> 012b1728 55005500 55005500 55005500 ff005500 012b1738 ffffffff 55ffffff 55005500 55005500 012b1748 ffffff00 550055ff 55005500 55005500 012b1758 55005500 55005500 55005500 55005500 012b1768 55005500 ff005500 ffffffff 55ffffff 012b1778 55005500 55005500 55005500 55005500 012b1788 55005500 55005500 55005500 55005500 012b1798 55005500 55005500 55005500 55005500 0:000> 012b17a8 55005500 55005500 55005500 55005500 012b17b8 55005500 55005500 55005500 55005500 012b17c8 00000000 55000000 55000055 55000055 012b17d8 55000055 55000055 55000055 55000055 012b17e8 ffffff55 ffffffff ffffffff ffffffff 012b17f8 ffffffff ffffffff 55000055 55000055 012b1808 55000055 55000055 55000055 55000055 012b1818 ffff0055 ffffffff 55000055 55000055 0:000> 012b1828 55000055 5500ffff 55000055 55000055 012b1838 55000055 55000055 55000055 55000055 012b1848 55000055 ffffffff ffffffff 55000055 012b1858 55000055 ffff0055 55000055 55000055 012b1868 55000055 55000055 55000055 55000055 012b1878 55000055 55000055 ffffffff 550000ff 012b1888 ffffff55 5500ffff 55000055 55000055 012b1898 55000055 55000055 55000055 55000055 0:000> 012b18a8 55000055 55000055 55000055 55000055 012b18b8 ffffff55 55ffffff 55000055 55000055 012b18c8 55000055 55000055 55000055 55000055 012b18d8 55000055 00000000 00000000 00555555 012b18e8 00555555 00555555 00555555 00555555 012b18f8 00555555 ffffff55 ffffffff ffffffff 012b1908 ffffffff ffffffff ffffffff 00555555 012b1918 00555555 00555555 00555555 00555555 0:000> 012b1928 00555555 ffff5555 ffffffff 00555555 012b1938 00555555 00555555 0055ffff 00555555 012b1948 00555555 00555555 00555555 00555555 012b1958 00555555 00555555 ffffff55 ffffffff 012b1968 005555ff 00555555 ffff5555 00555555 012b1978 00555555 00555555 00555555 00555555 012b1988 00555555 00555555 ff555555 00ffffff 012b1998 00555555 ff555555 00ffffff 00555555 0:000> 012b19a8 00555555 00555555 00555555 00555555 012b19b8 00555555 00555555 00555555 00555555 012b19c8 ffff5555 ffffffff ffffffff 0055ffff 012b19d8 00555555 00555555 00555555 00555555 012b19e8 00555555 00555555 00000000 55000000 012b19f8 55005500 55005500 55005500 55005500 012b1a08 55005500 55005500 55005500 ffff5500 012b1a18 ffffffff ffffffff ffffffff 55005500 0:000> 012b1a28 55005500 55005500 00005500 55005500 012b1a38 55005500 55005500 ffff5500 ffffffff 012b1a48 55005500 55005500 55005500 5500ffff 012b1a58 55005500 00005500 00550055 00550000 012b1a68 55000055 55005500 55005500 ffffff00 012b1a78 ffffffff 550055ff 55005500 ffff5500 012b1a88 55005500 55005500 00550000 00000055 012b1a98 00550055 55005500 55005500 ffff5500 0:000> 012b1aa8 5500ffff 55005500 55005500 ffffffff 012b1ab8 55005500 55005500 00005500 00550055 012b1ac8 00550000 55000055 55005500 55005500 012b1ad8 55005500 ffffff00 ffffffff ffffffff 012b1ae8 ffffffff 55005500 55005500 55005500 012b1af8 55005500 55005500 55005500 00000000 012b1b08 00000000 00555500 00555500 00555500 012b1b18 00555500 00555500 00555500 00555500 0:000> 012b1b28 ff555500 ffffffff ffffffff 00ffffff 012b1b38 00555500 00555500 00555500 00005500 012b1b48 00555500 00555500 00555500 ffff5500 012b1b58 ffffffff 00555500 00555500 00555500 012b1b68 0055ffff 00555500 55555500 00550000 012b1b78 55550000 00550000 00555500 00555500 012b1b88 ffffff00 ffffffff 0055ffff 00555500 012b1b98 ffff5500 00555500 00555500 00005500 0:000> 012b1ba8 00000055 00005555 00555500 00555500 012b1bb8 ffffff00 0055ffff 00555500 00555500 012b1bc8 ffffffff 005555ff 00555500 55555500 012b1bd8 00550000 55550000 00550000 00555500 012b1be8 00555500 ff555500 ffffffff ffffffff 012b1bf8 ffffffff ffffffff 005555ff 00555500 012b1c08 00555500 00555500 00555500 00555500 012b1c18 00000000 55000000 55550055 55550055 0:000> 012b1c28 55550055 55550055 55550055 55550055 012b1c38 55550055 55550055 ffffffff ffffffff 012b1c48 5555ffff 55550055 55550055 55550055 012b1c58 00000055 55550000 55550055 55550055 012b1c68 ffff0055 ffffffff 55550055 55550055 012b1c78 55550055 5555ffff 55550055 55550055 012b1c88 00005555 55000000 55555555 55550055 012b1c98 55550055 55ffff55 ffffffff 55ffffff 0:000> 012b1ca8 55550055 ffff0055 55550055 55550055 012b1cb8 55555555 00000000 55555500 55550055 012b1cc8 55550055 ffffffff 555500ff 55550055 012b1cd8 55550055 ffffff55 5555ffff 55550055 012b1ce8 55550055 00005555 55000000 55555555 012b1cf8 55550055 55550055 ffff0055 ffffffff 012b1d08 ffffffff ffffffff ffffffff 5555ffff 012b1d18 55550055 55550055 55550055 55550055 0:000> 012b1d28 55550055 00000000 55000000 55005500 012b1d38 55005500 55005500 55005500 55005500 012b1d48 55005500 55005500 55005500 ffffffff 012b1d58 ffffffff 5500ffff 55005500 55005500 012b1d68 55005500 00000000 55000000 55005500 012b1d78 55005500 ffff5500 ffffffff 55005500 012b1d88 55005500 55005500 5500ffff 55005500 012b1d98 00005500 00000055 00000000 55000055 0:000> 012b1da8 55005500 55005500 55ffff00 ffffffff 012b1db8 ffffffff 55005500 ffff5500 55005500 012b1dc8 55005500 00550000 00000000 00550000 012b1dd8 55005500 ff005500 ffffffff 550055ff 012b1de8 55005500 55005500 ffffff00 55ffffff 012b1df8 55005500 00005500 00000055 00000000 012b1e08 55000055 55005500 55005500 ffff5500 012b1e18 ffffffff ffffffff ffffffff ffffffff 0:000> 012b1e28 5500ffff 55005500 55005500 55005500 012b1e38 55005500 55005500 00000000 55000000 012b1e48 55000055 55000055 55000055 55000055 012b1e58 55000055 55000055 55000055 55000055 012b1e68 ffffffff ffffffff 5500ffff 55000055 012b1e78 55000055 55000055 00000055 55000000 012b1e88 55000055 55000055 ffff0055 ffffffff 012b1e98 55000055 55000055 55000055 5500ffff 0:000> 012b1ea8 55000055 00000055 00005555 00000000 012b1eb8 55005555 55000055 55000055 55ffff55 012b1ec8 ffffff55 ffffffff 550000ff ffff0055 012b1ed8 55000055 55000055 55550055 00000000 012b1ee8 55550000 55000055 ff000055 ffffffff 012b1ef8 55000055 55000055 55000055 ffff0055 012b1f08 55ffffff 55000055 00000055 00005555 012b1f18 00000000 55005555 55000055 55000055 0:000> 012b1f28 ffffff55 ffffffff ffffffff ffffffff 012b1f38 ffffffff 55ffffff 55000055 55000055 012b1f48 55000055 55000055 55000055 00000000 012b1f58 00000000 00555555 00555555 00555555 012b1f68 00555555 00555555 00555555 00555555 012b1f78 00555555 ffffffff ffffffff 0055ffff 012b1f88 00555555 00555555 00555555 00000000 012b1f98 00000000 00555555 00555555 ffff5555 0:000> 012b1fa8 ffffffff 00555555 00555555 00555555 012b1fb8 0055ffff 00555555 55555555 00000000 012b1fc8 00000000 00555500 00555555 00555555 012b1fd8 00ffff55 ffff5555 ffffffff 005555ff 012b1fe8 ffff5555 00555555 00555555 00005555 012b1ff8 00000000 55000000 00555555 ff555555 012b2008 ffffffff 00555555 00555555 00555555 012b2018 ffff5555 00ffffff 00555555 55555555 0:000> 012b2028 00000000 00000000 00555500 00555555 012b2038 00555555 ffffffff 005555ff ffff5555 012b2048 ffffffff ffffffff 00ffffff 00555555 012b2058 00555555 00555555 00555555 00555555 012b2068 00000000 55000000 55005500 55005500 012b2078 55005500 55005500 55005500 55005500 012b2088 55005500 55005500 ffffffff ffffffff 012b2098 5500ffff 55005500 55005500 55005500 0:000> 012b20a8 00000000 55000000 55005500 55005500 012b20b8 ffff5500 ffffffff 55005500 55005500 012b20c8 55005500 5500ffff 55005500 00005500 012b20d8 00000055 00000000 55000055 55005500 012b20e8 55005500 55ffff00 ff005500 ffffffff 012b20f8 5500ffff ffff5500 55005500 55005500 012b2108 00550000 00000000 00550000 55005500 012b2118 ffff5500 ffffffff 55005500 55005500 0:000> 012b2128 55005500 ffff5500 ffffffff 55005500 012b2138 00005500 00000055 00000000 55000055 012b2148 55005500 55005500 55ffffff 55005500 012b2158 55005500 ffffffff ffffffff ffffffff 012b2168 55005500 55005500 55005500 55005500 012b2178 55005500 00000000 00000000 00555500 012b2188 00555500 00555500 00555500 00555500 012b2198 00555500 00555500 00555500 ffffffff 0:000> 012b21a8 ffffffff 0055ffff 00555500 00555500 012b21b8 00555500 00000000 00000000 00555500 012b21c8 00555500 ffff5500 ffffffff 00555500 012b21d8 00555500 00555500 0055ffff 00555500 012b21e8 55555500 00000000 00000000 00550000 012b21f8 00555500 00555500 00ffff00 00555500 012b2208 ffffffff 00ffffff ffff5500 00555500 012b2218 00555500 00005500 00000000 00000000 0:000> 012b2228 00555500 ffff5500 ffffffff 00555500 012b2238 00555500 00555500 ffff5500 ffffffff 012b2248 00555500 55555500 00000000 00000000 012b2258 00550000 00555500 ff555500 0055ffff 012b2268 00555500 00555500 ffffff00 ffffffff 012b2278 ffffffff 00555500 00555500 00555500 012b2288 00555500 00555500 00000000 55000000 012b2298 55550055 55550055 55550055 55550055 0:000> 012b22a8 55550055 55550055 55550055 55550055 012b22b8 ffffffff ffffffff 5555ffff 55550055 012b22c8 55550055 00000055 00000000 00000000 012b22d8 55550000 55550055 ffff0055 ffffffff 012b22e8 55550055 55550055 55550055 5555ffff 012b22f8 55550055 00550055 00000000 00000000 012b2308 55550000 55550055 55550055 55ffff55 012b2318 55550055 ffffff55 ffffffff ffff0055 0:000> 012b2328 55550055 55550055 00000055 00000000 012b2338 00000000 55550055 ffff0055 ffffffff 012b2348 55550055 55550055 55550055 ffff0055 012b2358 ffffffff 55550055 00550055 00000000 012b2368 00000000 55550000 55550055 ff550055 012b2378 555500ff 55550055 55550055 ffff0055 012b2388 ffffffff ffffffff 55550055 55550055 012b2398 55550055 55550055 55550055 00000000 0:000> 012b23a8 55000000 55005500 55005500 55005500 012b23b8 55005500 55005500 55005500 55005500 012b23c8 55005500 ffffffff ffffffff 5500ffff 012b23d8 55005500 55005500 00005500 00000000 012b23e8 00000000 55005500 55005500 ffff5500 012b23f8 ffffffff 55005500 55005500 55005500 012b2408 5500ffff 55005500 00005500 00000000 012b2418 00000000 55000000 55005500 55005500 0:000> 012b2428 55ffff00 55005500 ffffff00 ffffffff 012b2438 ffff55ff 55005500 55005500 00000000 012b2448 00000000 00000000 55005500 ffff5500 012b2458 ffffffff 55005500 55005500 55005500 012b2468 ffff5500 ffffffff 55005500 00005500 012b2478 00000000 00000000 55000000 55005500 012b2488 ffff5500 55005500 55005500 55005500 012b2498 ffff5500 ffffffff ffffffff 55005500 0:000> 012b24a8 55005500 55005500 55005500 55005500 012b24b8 00000000 55000000 55000055 55000055 012b24c8 55000055 55000055 55000055 55000055 012b24d8 55000055 55000055 ffffffff ffffffff 012b24e8 5500ffff 55000055 55000055 00000055 012b24f8 00000000 00000000 55000000 55000055 012b2508 ffff0055 ffffffff 55000055 55000055 012b2518 55000055 5500ffff 55000055 00000055 0:000> 012b2528 00000000 00000000 55000000 55000055 012b2538 55000055 55ffff55 55000055 ffff0055 012b2548 ffffffff ffff00ff 55000055 55000055 012b2558 00000055 00000000 00000000 55000055 012b2568 ffff0055 ffffffff 55000055 55000055 012b2578 55000055 ffff0055 ffffffff 55000055 012b2588 00000055 00000000 00000000 55000000 012b2598 55000055 55000055 55000055 55000055 0:000> 012b25a8 55000055 ff000055 ffffffff ffffffff 012b25b8 55000055 55000055 55000055 55000055 012b25c8 55000055 00000000 00000000 00555555 012b25d8 00555555 00555555 00555555 00555555 012b25e8 00555555 00555555 00555555 ffffffff 012b25f8 ffffffff 0055ffff 00555555 00555555 012b2608 00555555 00000000 00000000 00555555 012b2618 00555555 ffff5555 ffffffff 00555555 0:000> 012b2628 00555555 00555555 0055ffff 00555555 012b2638 55555555 00000000 00000000 00555500 012b2648 00555555 00555555 00ffff55 00555555 012b2658 ff555555 ffffffff ffffffff 00555555 012b2668 00555555 00005555 00000000 55000000 012b2678 00555555 ffff5555 ffffffff 00555555 012b2688 00555555 00555555 ffff5555 ffffffff 012b2698 00555555 55555555 00000000 00000000 0:000> 012b26a8 00555500 00555555 00555555 00555555 012b26b8 00555555 00555555 ff555555 ffffffff 012b26c8 ffffffff 00555555 00555555 00555555 012b26d8 00555555 00555555 00000000 55000000 012b26e8 55005500 55005500 55005500 55005500 012b26f8 55005500 55005500 55005500 55005500 012b2708 ffffffff ffffffff 5500ffff 55005500 012b2718 55005500 55005500 00000000 55000000 0:000> 012b2728 55005500 55005500 ffff5500 ffffffff 012b2738 55005500 55005500 55005500 5500ffff 012b2748 55005500 00005500 00000055 00000000 012b2758 55000055 55005500 55005500 55ffff00 012b2768 55005500 55005500 ffffffff ffffffff 012b2778 55005500 55005500 00550000 00000000 012b2788 00550000 55005500 ffff5500 ffffffff 012b2798 55005500 55005500 55005500 ffff5500 0:000> 012b27a8 ffffffff 55005500 00005500 00000055 012b27b8 00000000 55000055 55005500 55005500 012b27c8 55005500 55005500 55005500 ff005500 012b27d8 ffffffff 55ffffff 55005500 55005500 012b27e8 55005500 55005500 55005500 00000000 012b27f8 00000000 00555500 00555500 00555500 012b2808 00555500 00555500 00555500 00555500 012b2818 00555500 ffffffff ffffffff 0055ffff 0:000> 012b2828 00555500 00555500 00555500 00000000 012b2838 00000000 00555500 00555500 ffff5500 012b2848 ffffffff 00555500 00555500 00555500 012b2858 0055ffff 00555500 55555500 00000000 012b2868 00000000 00550000 00555500 00555500 012b2878 00ffff00 00555500 00555500 ffffff00 012b2888 ffffffff 00555500 00555500 00005500 012b2898 00000000 00000000 00555500 ff555500 0:000> 012b28a8 ffffffff 00555500 00555500 00555500 012b28b8 ffff5500 00ffffff 00555500 55555500 012b28c8 00000000 00000000 00550000 00555500 012b28d8 00555500 00555500 00555500 00555500 012b28e8 ff555500 ffffffff 00ffffff 00555500 012b28f8 00555500 00555500 00555500 00555500 012b2908 00000000 55000000 55550055 55550055 012b2918 55550055 55550055 55550055 55550055 0:000> 012b2928 55550055 55550055 ffffffff ffffffff 012b2938 5555ffff 55550055 55550055 55550055 012b2948 00000055 55550000 55550055 55550055 012b2958 ffff0055 ffffffff 55550055 55550055 012b2968 55550055 555500ff 55550055 55550055 012b2978 00005555 55000000 55555555 55550055 012b2988 55550055 55ffff55 55550055 55550055 012b2998 ffffff55 ffffffff 55550055 55550055 0:000> 012b29a8 55555555 00000000 55555500 55550055 012b29b8 ff550055 ffffffff 55550055 55550055 012b29c8 55550055 ffff0055 55ffffff 55550055 012b29d8 55550055 00005555 55000000 55555555 012b29e8 55550055 55550055 55550055 55550055 012b29f8 55550055 ff550055 ffffffff 55ffffff 012b2a08 55550055 55550055 55550055 55550055 012b2a18 55550055 00000000 55000000 55005500 0:000> 012b2a28 55005500 55005500 55005500 55005500 012b2a38 55005500 55005500 55005500 ffffffff 012b2a48 ffffffff 5500ffff 55005500 55005500 012b2a58 55005500 00000000 55000000 55005500 012b2a68 55005500 ff005500 ffffffff 55005500 012b2a78 55005500 ff005500 550055ff 55005500 012b2a88 00005500 00000055 00000000 55000055 012b2a98 55005500 55005500 55ffff00 55005500 0:000> 012b2aa8 55005500 ffff5500 ffffffff 55005500 012b2ab8 55005500 00550000 00000000 00550000 012b2ac8 55005500 ff005500 ffffffff 550055ff 012b2ad8 55005500 55005500 ffffff00 55ffffff 012b2ae8 55005500 00005500 00000055 00000000 012b2af8 55000055 55005500 55005500 55005500 012b2b08 55005500 55005500 ff005500 ffffffff 012b2b18 5500ffff 55005500 55005500 55005500 0:000> 012b2b28 55005500 55005500 00000000 55000000 012b2b38 55000055 55000055 55000055 55000055 012b2b48 55000055 55000055 55000055 55000055 012b2b58 ffffffff ffffffff 5500ffff 55000055 012b2b68 55000055 55000055 00000055 55000000 012b2b78 55000055 55000055 ff000055 ffffffff 012b2b88 550000ff 55000055 ff000055 550000ff 012b2b98 55000055 00000055 00005555 00000000 0:000> 012b2ba8 55005555 55000055 55000055 55ffff55 012b2bb8 55000055 55000055 ff000055 ffffffff 012b2bc8 55000055 55000055 55550055 00000000 012b2bd8 55550000 55000055 55000055 ffffffff 012b2be8 550000ff 55000055 55000055 ffffff55 012b2bf8 5500ffff 55000055 00000055 00005555 012b2c08 00000000 55005555 55000055 55000055 012b2c18 55000055 55000055 55000055 ffff0055 0:000> 012b2c28 ffffffff 5500ffff 55000055 55000055 012b2c38 55000055 55000055 55000055 00000000 012b2c48 00000000 00555555 00555555 00555555 012b2c58 00555555 00555555 00555555 00555555 012b2c68 00555555 ffffffff ffffffff 0055ffff 012b2c78 00555555 00555555 00555555 00005555 012b2c88 00555500 00555555 00555555 00555555 012b2c98 ffffffff 005555ff 00555555 ffff5555 0:000> 012b2ca8 00555555 00555555 55555555 00555500 012b2cb8 55550000 00555500 00555555 00555555 012b2cc8 00ffff55 00555555 00555555 00555555 012b2cd8 ffffffff 00555555 00555555 55005555 012b2ce8 00000055 55005555 00555555 00555555 012b2cf8 ffffff55 005555ff 00555555 00555555 012b2d08 ffffff55 005555ff 00555555 55555555 012b2d18 00555500 55550000 00555500 00555555 0:000> 012b2d28 00555555 00555555 00555555 00555555 012b2d38 ffff5555 ffffffff 005555ff 00555555 012b2d48 00555555 00555555 00555555 00555555 012b2d58 00000000 55000000 55005500 55005500 012b2d68 55005500 55005500 55005500 55005500 012b2d78 55005500 55005500 ffffffff ffffffff 012b2d88 5500ffff 55005500 55005500 55005500 012b2d98 00005500 55005500 55005500 55005500 0:000> 012b2da8 55005500 ffffff00 55ffffff 55005500 012b2db8 55ffff00 55005500 55005500 00005500 012b2dc8 00550055 00550000 55000055 55005500 012b2dd8 55005500 55ffff00 55005500 55005500 012b2de8 55005500 ffffff00 55005500 55005500 012b2df8 00550000 00000055 00550055 55005500 012b2e08 55005500 ffffff00 5500ffff 55005500 012b2e18 55005500 ffffffff 55005500 55005500 0:000> 012b2e28 00005500 00550055 00550000 55000055 012b2e38 55005500 55005500 55005500 55005500 012b2e48 55005500 ffff5500 ffffffff 55005500 012b2e58 55005500 55005500 55005500 55005500 012b2e68 55005500 00000000 00000000 00555500 012b2e78 00555500 00555500 00555500 00555500 012b2e88 00555500 00555500 00555500 ffffffff 012b2e98 ffffffff 0055ffff 00555500 00555500 0:000> 012b2ea8 00555500 00555500 00555500 00555500 012b2eb8 00555500 00555500 ffff5500 ffffffff 012b2ec8 ffffffff 0055ffff 00555500 00555500 012b2ed8 00555500 00555500 00555500 00555500 012b2ee8 00555500 00555500 ffffffff 00555500 012b2ef8 00555500 00555500 ffff5500 00555500 012b2f08 00555500 00555500 00555500 00555500 012b2f18 00555500 00555500 ff555500 00ffffff 0:000> 012b2f28 00555500 ff555500 00ffffff 00555500 012b2f38 00555500 00555500 00555500 00555500 012b2f48 00555500 00555500 00555500 00555500 012b2f58 00555500 00555500 ffffff00 ffffffff 012b2f68 00555500 00555500 00555500 00555500 012b2f78 00555500 00555500 00000000 55000000 012b2f88 55550055 55550055 55550055 55550055 012b2f98 55550055 55550055 55550055 55550055 0:000> 012b2fa8 ffffffff ffffffff 5555ffff 55550055 012b2fb8 55550055 55550055 55550055 55550055 012b2fc8 55550055 55550055 55550055 55550055 012b2fd8 ffffff55 55ffffff 55550055 55550055 012b2fe8 55550055 55550055 55550055 55550055 012b2ff8 55550055 55550055 ffff0055 ffffffff 012b3008 5555ffff 55550055 55550055 ffff0055 012b3018 55550055 55550055 55550055 55550055 0:000> 012b3028 55550055 55550055 55550055 55550055 012b3038 ffffffff 55550055 ffff0055 5555ffff 012b3048 55550055 55550055 55550055 55550055 012b3058 55550055 55550055 55550055 55550055 012b3068 55550055 55550055 55550055 ffffff55 012b3078 55ffffff 55550055 55550055 55550055 012b3088 55550055 55550055 55550055 00000000 012b3098 55000000 55005500 55005500 55005500 0:000> 012b30a8 55005500 55005500 55005500 55005500 012b30b8 55005500 ffffffff ffffffff 5500ffff 012b30c8 55005500 55005500 55005500 55005500 012b30d8 55005500 55005500 55005500 55005500 012b30e8 55005500 55005500 55005500 55005500 012b30f8 55005500 55005500 55005500 55005500 012b3108 55005500 55005500 55005500 55005500 012b3118 55005500 55005500 55005500 55005500 0:000> 012b3128 55005500 55005500 55005500 55005500 012b3138 55005500 55005500 55005500 55005500 012b3148 55005500 ff005500 ffffffff 55ffffff 012b3158 55005500 55005500 55005500 55005500 012b3168 55005500 55005500 55005500 55005500 012b3178 55005500 55005500 55005500 55005500 012b3188 ffffffff 5500ffff 55005500 55005500 012b3198 55005500 55005500 55005500 55005500 0:000> 012b31a8 00000000 55000000 55000055 55000055 012b31b8 55000055 55000055 55000055 55000055 012b31c8 55000055 55000055 ffffffff ffffffff 012b31d8 5500ffff 55000055 55000055 55000055 012b31e8 55000055 55000055 55000055 55000055 012b31f8 55000055 55000055 55000055 55000055 012b3208 55000055 55000055 55000055 55000055 012b3218 55000055 55000055 55000055 55000055 0:000> 012b3228 55000055 55000055 55000055 55000055 012b3238 55000055 55000055 55000055 55000055 012b3248 55000055 55000055 55000055 55000055 012b3258 55000055 55000055 55000055 55000055 012b3268 55000055 55000055 55000055 55000055 012b3278 55000055 55000055 55000055 55000055 012b3288 55000055 55000055 55000055 55000055 012b3298 ff000055 ffffffff 550000ff 55000055 0:000> 012b32a8 55000055 55000055 55000055 55000055 012b32b8 55000055 00000000 00000000 00555555 012b32c8 00555555 00555555 00555555 00555555 012b32d8 00555555 00555555 00555555 ffffffff 012b32e8 ffffffff 0055ffff 00555555 00555555 012b32f8 00555555 00555555 00555555 00555555 012b3308 00555555 00555555 00555555 00555555 012b3318 00555555 00555555 00555555 00555555 0:000> 012b3328 00555555 00555555 00555555 00555555 012b3338 00555555 00555555 00555555 00555555 012b3348 00555555 00555555 00555555 00555555 012b3358 00555555 00555555 00555555 00555555 012b3368 00555555 00555555 00555555 00555555 012b3378 00555555 00555555 00555555 00555555 012b3388 00555555 00555555 00555555 00555555 012b3398 00555555 00555555 00555555 00555555 0:000> 012b33a8 00555555 ff555555 ffffffff 00555555 012b33b8 00555555 00555555 00555555 00555555 012b33c8 00555555 00555555 00000000 55000000 012b33d8 55005500 55005500 55005500 55005500 012b33e8 55005500 55005500 55005500 55005500 012b33f8 ffffffff ffffffff 5500ffff 55005500 012b3408 55005500 55005500 55005500 55005500 012b3418 55005500 55005500 55005500 55005500 0:000> 012b3428 55005500 55005500 55005500 55005500 012b3438 55005500 55005500 55005500 55005500 012b3448 55005500 55005500 55005500 55005500 012b3458 55005500 55005500 55005500 55005500 012b3468 55005500 55005500 55005500 55005500 012b3478 55005500 55005500 55005500 55005500 012b3488 55005500 55005500 55005500 55005500 012b3498 55005500 55005500 55005500 55005500 0:000> 012b34a8 55005500 55005500 55005500 55005500 012b34b8 55005500 55005500 ffff5500 55ffffff 012b34c8 55005500 55005500 55005500 55005500 012b34d8 55005500 55005500 55005500 00000000 012b34e8 00000000 00555500 00555500 00555500 012b34f8 00555500 00555500 00555500 00555500 012b3508 00555500 ffffffff ffffffff 0055ffff 012b3518 00555500 00555500 00555500 00555500 0:000> 012b3528 00555500 00555500 00555500 00555500 012b3538 00555500 00555500 00555500 00555500 012b3548 00555500 00555500 00555500 00555500 012b3558 00555500 00555500 00555500 00555500 012b3568 00555500 00555500 00555500 00555500 012b3578 00555500 00555500 00555500 00555500 012b3588 00555500 00555500 00555500 00555500 012b3598 00555500 00555500 00555500 00555500 0:000> 012b35a8 00555500 00555500 00555500 00555500 012b35b8 00555500 00555500 00555500 00555500 012b35c8 00555500 00555500 00555500 ffffff00 012b35d8 005555ff 00555500 00555500 00555500 012b35e8 00555500 00555500 00555500 00555500 012b35f8 00000000 55000000 55550055 55550055 012b3608 55550055 55550055 55550055 55550055 012b3618 55550055 55550055 ffffffff ffffffff 0:000> 012b3628 5555ffff 55550055 55550055 55550055 012b3638 55550055 55550055 55550055 55550055 012b3648 55550055 55550055 55550055 55550055 012b3658 55550055 55550055 55550055 55550055 012b3668 55550055 55550055 55550055 55550055 012b3678 55550055 55550055 55550055 55550055 012b3688 55550055 55550055 55550055 55550055 012b3698 55550055 55550055 55550055 55550055 0:000> 012b36a8 55550055 55550055 55550055 55550055 012b36b8 55550055 55550055 55550055 55550055 012b36c8 55550055 55550055 55550055 55550055 012b36d8 55550055 55550055 55550055 55550055 012b36e8 ffffffff 55550055 55550055 55550055 012b36f8 55550055 55550055 55550055 55550055 012b3708 55550055 00000000 55000000 55005500 012b3718 55005500 55005500 55005500 55005500 0:000> 012b3728 55005500 55005500 55005500 ffffffff 012b3738 ffffffff 5500ffff 55005500 55005500 012b3748 55005500 55005500 55005500 55005500 012b3758 55005500 55005500 55005500 55005500 012b3768 55005500 55005500 55005500 55005500 012b3778 55005500 55005500 55005500 55005500 012b3788 55005500 55005500 55005500 55005500 012b3798 55005500 55005500 55005500 55005500 0:000> 012b37a8 55005500 55005500 55005500 55005500 012b37b8 55005500 55005500 55005500 55005500 012b37c8 55005500 55005500 55005500 55005500 012b37d8 55005500 55005500 55005500 55005500 012b37e8 55005500 55005500 55005500 55005500 012b37f8 55005500 55ffffff 55005500 55005500 012b3808 55005500 55ffff00 55005500 55005500 012b3818 55005500 55005500 00000000 55000000 0:000> 012b3828 55000055 55000055 55000055 55000055 012b3838 55000055 55000055 55000055 55000055 012b3848 ffffffff ffffffff 5500ffff 55000055 012b3858 55000055 55000055 55000055 55000055 012b3868 55000055 55000055 00000055 55000055 012b3878 55000055 55000055 55000055 55000055 012b3888 55000055 00000055 55000000 55000055 012b3898 55000055 55000055 55000055 55000055 0:000> 012b38a8 55000055 00000000 55000055 55000055 012b38b8 55000055 55000055 55000055 55000055 012b38c8 00000055 55000000 55000055 55000055 012b38d8 55000055 55000055 55000055 55000055 012b38e8 55000000 55000055 55000055 55000055 012b38f8 55000055 55000055 55000055 55000055 012b3908 55000055 ff000055 5500ffff 55000055 012b3918 55000055 55000055 5500ffff 55000055 0:000> 012b3928 55000055 55000055 55000055 00000000 012b3938 00000000 00555555 00555555 00555555 012b3948 00555555 00555555 00555555 00555555 012b3958 00555555 ffffffff ffffffff 0055ffff 012b3968 00555555 00555555 00555555 00555555 012b3978 00555555 00555555 00555555 00000000 012b3988 00550000 00555555 00555555 00555555 012b3998 00555555 00555555 00000055 00000000 0:000> 012b39a8 00555555 00555555 00555555 00555555 012b39b8 00555555 00555555 00000000 00555500 012b39c8 00555555 00555555 00555555 00555555 012b39d8 00555555 00000055 00000000 00555555 012b39e8 00555555 00555555 00555555 00555555 012b39f8 00555555 00000000 00555500 00555555 012b3a08 00555555 00555555 00555555 00555555 012b3a18 00555555 00555555 ffff5555 005555ff 0:000> 012b3a28 00555555 00555555 00555555 0055ffff 012b3a38 00555555 00555555 00555555 00555555 012b3a48 00000000 55000000 55005500 55005500 012b3a58 55005500 55005500 55005500 55005500 012b3a68 55005500 55005500 ffffffff ffffffff 012b3a78 5500ffff 55005500 55005500 55005500 012b3a88 55005500 55005500 55005500 00005500 012b3a98 00000000 55000000 55005500 55005500 0:000> 012b3aa8 55005500 55005500 55005500 00000000 012b3ab8 00000000 55005500 55005500 55005500 012b3ac8 55005500 55005500 00005500 00000000 012b3ad8 55000000 55005500 55005500 55005500 012b3ae8 55005500 00005500 00000000 00000000 012b3af8 55005500 55005500 55005500 55005500 012b3b08 55005500 00000000 00000000 55000000 012b3b18 55005500 55005500 55005500 55005500 0:000> 012b3b28 55005500 55005500 55005500 ffffff00 012b3b38 55005500 55005500 55005500 ff005500 012b3b48 5500ffff 55005500 55005500 55005500 012b3b58 55005500 00000000 00000000 00555500 012b3b68 00555500 00555500 00555500 00555500 012b3b78 00555500 00555500 00555500 ffffffff 012b3b88 ffffffff 0055ffff 00555500 00555500 012b3b98 00555500 00555500 00555500 00555500 0:000> 012b3ba8 00000000 00000000 00000000 00555500 012b3bb8 00555500 00555500 00555500 00005500 012b3bc8 00000000 00000000 00550000 00555500 012b3bd8 00555500 00555500 00555500 00000000 012b3be8 00000000 00000000 00555500 00555500 012b3bf8 00555500 00555500 00005500 00000000 012b3c08 00000000 00550000 00555500 00555500 012b3c18 00555500 00555500 00000000 00000000 0:000> 012b3c28 00000000 00555500 00555500 00555500 012b3c38 00555500 00555500 00555500 00555500 012b3c48 00ffffff 00555500 00555500 00555500 012b3c58 ffff5500 0055ffff 00555500 00555500 012b3c68 00555500 00555500 00000000 55000000 012b3c78 55550055 55550055 55550055 55550055 012b3c88 55550055 55550055 55550055 55550055 012b3c98 ffffffff ffffffff 5555ffff 55550055 0:000> 012b3ca8 55550055 55550055 55550055 55550055 012b3cb8 00550055 00000000 00000000 00000000 012b3cc8 55550000 55550055 55550055 55550055 012b3cd8 00000055 00000000 00000000 00000000 012b3ce8 55550055 55550055 55550055 00550055 012b3cf8 00000000 00000000 00000000 55550000 012b3d08 55550055 55550055 55550055 00000055 012b3d18 00000000 00000000 55000000 55550055 0:000> 012b3d28 55550055 55550055 00000055 00000000 012b3d38 00000000 00000000 55550000 55550055 012b3d48 55550055 55550055 55550055 55550055 012b3d58 ff550055 ffffffff ffffffff ffffffff 012b3d68 ffffffff ffffffff 555500ff 55550055 012b3d78 55550055 55550055 55550055 00000000 012b3d88 55000000 55005500 55005500 55005500 012b3d98 55005500 55005500 5500ff00 55005500 0:000> 012b3da8 55005500 ffffffff ffffffff 5500ffff 012b3db8 55005500 55005500 55005500 55005500 012b3dc8 55005500 00005500 00000000 00000000 012b3dd8 00000000 55000000 55005500 55005500 012b3de8 55005500 00000000 00000000 00000000 012b3df8 00000000 55005500 55005500 55005500 012b3e08 00000000 00000000 00000000 00000000 012b3e18 55000000 55005500 55005500 00005500 0:000> 012b3e28 00000000 55000000 00000000 00000000 012b3e38 55005500 55005500 55005500 00000000 012b3e48 00000000 00005500 00000000 55000000 012b3e58 55005500 55005500 55005500 55005500 012b3e68 55005500 ffff5500 ffffffff ffffffff 012b3e78 ffffffff ffffffff ffffffff 550055ff 012b3e88 55005500 55005500 55005500 55005500 012b3e98 00000000 55000000 55000055 55000055 0:000> 012b3ea8 55000055 55000055 ff000055 ffffffff 012b3eb8 55000055 55000055 ffffffff ffffffff 012b3ec8 5500ffff 55000055 55000055 55000055 012b3ed8 55000055 55000055 00000000 00000000 012b3ee8 55000000 00000000 00000000 55000000 012b3ef8 55000055 00000055 00000000 55000000 012b3f08 00000055 00000000 55000000 55000055 012b3f18 55000055 00000000 00000000 55000055 0:000> 012b3f28 00000000 00000000 55000055 55000055 012b3f38 00000055 00000000 55000000 00000055 012b3f48 00000000 55000000 55000055 55000055 012b3f58 00000000 00000000 00000055 00000000 012b3f68 00000000 55000055 55000055 55000055 012b3f78 55000055 55000055 ffffff55 ffffffff 012b3f88 ffffffff ffffffff ffffffff ffffffff 012b3f98 550000ff 55000055 55000055 55000055 0:000> 012b3fa8 55000055 00000000 00000000 00555555 012b3fb8 00555555 00555555 00555555 ffff5555 012b3fc8 ffffffff 005555ff 00555555 ffffffff 012b3fd8 ffffffff 0055ffff 00555555 00555555 012b3fe8 00555555 00555555 00555555 00000000 012b3ff8 00000000 00555555 00005555 00000000 012b4008 00550000 00555555 00000055 00000000 012b4018 00555500 00555555 00000000 00000000 0:000> 012b4028 00555555 00555555 00000000 00000000 012b4038 00555555 00000055 00000000 00550000 012b4048 00555555 00000000 00000000 00555500 012b4058 00555555 00000000 00000000 00555555 012b4068 00005555 00000000 00000000 00555555 012b4078 00000055 00000000 00555500 00555555 012b4088 00555555 00555555 00555555 ffffff55 012b4098 ffffffff ffffffff ffffffff ffffffff 0:000> 012b40a8 ffffffff 005555ff 00555555 00555555 012b40b8 00555555 00555555 00000000 55000000 012b40c8 55005500 55005500 55005500 55005500 012b40d8 ffffff00 ffffffff 5500ffff 55005500 012b40e8 ffffffff ffffffff 5500ffff 55005500 012b40f8 55005500 55005500 55005500 00005500 012b4108 00000000 55000000 55005500 00005500 012b4118 00000000 55000000 00005500 00000000 0:000> 012b4128 00000000 55005500 55005500 00000000 012b4138 00000000 55005500 00000000 00000000 012b4148 55000000 55005500 00005500 00000000 012b4158 55000000 00005500 00000000 55000000 012b4168 55005500 55005500 00000000 00000000 012b4178 55005500 00000000 00000000 55005500 012b4188 55005500 00005500 00000000 55000000 012b4198 55005500 55005500 55005500 55005500 0:000> 012b41a8 ffffffff ffffffff ffffffff ffffffff 012b41b8 ffffffff ffffffff 550055ff 55005500 012b41c8 55005500 55005500 55005500 00000000 012b41d8 00000000 00555500 00555500 00555500 012b41e8 00555500 ffffff00 ffffffff 0055ffff 012b41f8 00555500 ffffffff ffffffff 005555ff 012b4208 00555500 00555500 00555500 00555500 012b4218 00000000 00000000 00555500 00555500 0:000> 012b4228 00555500 00000000 00000000 00005500 012b4238 00000000 00550000 00555500 00555500 012b4248 00005500 00000000 00000000 00000000 012b4258 00000000 00555500 00555500 00555500 012b4268 00000000 00000000 00005500 00000000 012b4278 00550000 00555500 00555500 00005500 012b4288 00000000 00550000 00000000 00000000 012b4298 00555500 00555500 00555500 00000000 0:000> 012b42a8 00000000 00555500 00555500 00555500 012b42b8 ff555500 ffffffff ffffffff ffffffff 012b42c8 ffffffff ffffffff ffffffff 00555500 012b42d8 00555500 00555500 00555500 00555500 012b42e8 00000000 55000000 55550055 55550055 012b42f8 55550055 55550055 ffffff55 ffffffff 012b4308 5555ffff 55550055 ffffffff ffffffff 012b4318 555500ff 55550055 55550055 55550055 0:000> 012b4328 00550055 00000000 55000000 55550055 012b4338 55550055 55550055 00000055 00000000 012b4348 00000000 00000000 55550000 55550055 012b4358 55550055 55550055 00000000 00000000 012b4368 00000000 55000000 55550055 55550055 012b4378 55550055 00000055 00000000 00000000 012b4388 00000000 55550000 55550055 55550055 012b4398 00550055 00000000 00000000 00000000 0:000> 012b43a8 55550000 55550055 55550055 55550055 012b43b8 00000055 00000000 55550000 55550055 012b43c8 55550055 ffff0055 ffffffff ffffffff 012b43d8 ffffffff ffffffff ffffffff ffffffff 012b43e8 55550055 55550055 55550055 55550055 012b43f8 55550055 00000000 55000000 55005500 012b4408 55005500 55005500 55005500 ffffff00 012b4418 ffffffff 5500ffff 55005500 ffffffff 0:000> 012b4428 ffffffff 550055ff 55005500 55005500 012b4438 55005500 00000000 00000000 55000000 012b4448 55005500 55005500 55005500 00005500 012b4458 00000000 00000000 00000000 55005500 012b4468 55005500 55005500 55005500 00000000 012b4478 00000000 00000000 55005500 55005500 012b4488 55005500 55005500 00005500 00000000 012b4498 00000000 55000000 55005500 55005500 0:000> 012b44a8 55005500 55005500 00000000 00000000 012b44b8 00000000 55005500 55005500 55005500 012b44c8 55005500 00005500 00000000 55000000 012b44d8 55005500 55005500 ffffff00 ffffffff 012b44e8 ffffffff ffffffff ffffffff ffffffff 012b44f8 ffffffff 55005500 55005500 55005500 012b4508 55005500 55005500 00000000 55000000 012b4518 55000055 55000055 55000055 55000055 0:000> 012b4528 ffff0055 ffffffff 550000ff 55000055 012b4538 ffffffff ffffffff 55000055 55000055 012b4548 55000055 55000055 00000055 00000000 012b4558 55000055 55000055 55000055 55000055 012b4568 55000055 00000055 00000000 55000000 012b4578 55000055 55000055 55000055 55000055 012b4588 00000055 00000000 00000000 55000055 012b4598 55000055 55000055 55000055 55000055 0:000> 012b45a8 00000000 00000000 55000000 55000055 012b45b8 55000055 55000055 55000055 00000055 012b45c8 00000000 00000000 55000055 55000055 012b45d8 55000055 55000055 55000055 00000000 012b45e8 55000000 55000055 55000055 ffffff55 012b45f8 ffffffff ffffffff ffffffff ffffffff 012b4608 ffffffff ffffffff 55000055 55000055 012b4618 55000055 55000055 55000055 00000000 0:000> 012b4628 00000000 00555555 00555555 00555555 012b4638 00555555 ffff5555 ffffffff 00555555 012b4648 00555555 ffffffff 00ffffff 00555555 012b4658 00555555 00555555 00555555 00000055 012b4668 00000000 00555555 00555555 00555555 012b4678 00555555 00555555 00005555 00000000 012b4688 00555500 00555555 00555555 00555555 012b4698 00555555 00555555 00000000 00000000 0:000> 012b46a8 00555555 00555555 00555555 00555555 012b46b8 00555555 00005555 00000000 00555555 012b46c8 00555555 00555555 00555555 00555555 012b46d8 00555555 00000000 00550000 00555555 012b46e8 00555555 00555555 00555555 00555555 012b46f8 00000055 00000000 00555555 00555555 012b4708 00555555 00555555 00555555 00555555 012b4718 00555555 00555555 00555555 00555555 0:000> 012b4728 00555555 00555555 00555555 00555555 012b4738 00000000 55000000 55005500 55005500 012b4748 55005500 55005500 ff005500 ffffffff 012b4758 55005500 ff005500 ffffffff 55ffffff 012b4768 55005500 55005500 55005500 55005500 012b4778 00005500 55000000 55005500 55005500 012b4788 55005500 55005500 55005500 00005500 012b4798 55000000 55005500 55005500 55005500 0:000> 012b47a8 55005500 55005500 55005500 00000000 012b47b8 55005500 55005500 55005500 55005500 012b47c8 55005500 55005500 00005500 55000000 012b47d8 55005500 55005500 55005500 55005500 012b47e8 55005500 55005500 00000000 55005500 012b47f8 55005500 55005500 55005500 55005500 012b4808 55005500 00005500 55000000 55005500 012b4818 55005500 55005500 55005500 55005500 0:000> 012b4828 55005500 55005500 55005500 55005500 012b4838 55005500 55005500 55005500 55005500 012b4848 55005500 00000000 00000000 00555500 012b4858 00555500 00555500 00555500 00555500 012b4868 ffffffff 005555ff ffff5500 ffffffff 012b4878 005555ff 00555500 00555500 00555500 012b4888 00555500 00005500 00555500 00555500 012b4898 00555500 00555500 00555500 00555500 0:000> 012b48a8 00555500 00550000 00555500 00555500 012b48b8 00555500 00555500 00555500 00555500 012b48c8 00555500 00555500 00555500 00555500 012b48d8 00555500 00555500 00555500 00555500 012b48e8 00550000 00555500 00555500 00555500 012b48f8 00555500 00555500 00555500 00005500 012b4908 00555500 00555500 00555500 00555500 012b4918 00555500 00555500 00555500 00550000 0:000> 012b4928 00555500 00555500 00555500 00555500 012b4938 00555500 00555500 00555500 00555500 012b4948 00555500 00555500 00555500 00555500 012b4958 00555500 00555500 00000000 55000000 012b4968 55550055 55550055 55550055 55550055 012b4978 55550055 ffffff55 ffffffff ffffffff 012b4988 ffffffff 55550055 55550055 55550055 012b4998 55550055 55550055 55550055 55550055 0:000> 012b49a8 55550055 55550055 55550055 55550055 012b49b8 55550055 55550055 55550055 55550055 012b49c8 55550055 55550055 55550055 55550055 012b49d8 55550055 55550055 55550055 55550055 012b49e8 55550055 55550055 55550055 55550055 012b49f8 55550055 55550055 55550055 55550055 012b4a08 55550055 55550055 55550055 55550055 012b4a18 55550055 55550055 55550055 55550055 0:000> 012b4a28 55550055 55550055 55550055 55550055 012b4a38 55550055 55550055 55550055 55550055 012b4a48 55550055 55550055 55550055 55550055 012b4a58 55550055 55550055 55550055 55550055 012b4a68 55550055 55550055 55550055 00000000 012b4a78 55000000 55005500 55005500 55005500 012b4a88 55005500 55005500 55005500 ffffffff 012b4a98 ffffffff 550055ff 55005500 55005500 0:000> 012b4aa8 55005500 55005500 55005500 55005500 012b4ab8 55005500 55005500 55005500 55005500 012b4ac8 55005500 55005500 55005500 55005500 012b4ad8 55005500 55005500 55005500 55005500 012b4ae8 55005500 55005500 55005500 55005500 012b4af8 55005500 55005500 55005500 55005500 012b4b08 55005500 55005500 55005500 55005500 012b4b18 55005500 55005500 55005500 55005500 0:000> 012b4b28 55005500 55005500 55005500 55005500 012b4b38 55005500 55005500 55005500 55005500 012b4b48 55005500 55005500 55005500 55005500 012b4b58 55005500 55005500 55005500 55005500 012b4b68 55005500 55005500 55005500 55005500 012b4b78 55005500 55005500 55005500 55005500 012b4b88 00000000 55000000 55000055 55000055 012b4b98 55000055 55000055 55000055 55000055 0:000> 012b4ba8 55000055 55000055 55000055 55000055 012b4bb8 55000055 55000055 55000055 55000055 012b4bc8 55000055 55000055 55000055 55000055 012b4bd8 55000055 55000055 55000055 55000055 012b4be8 55000055 55000055 55000055 55000055 012b4bf8 55000055 55000055 55000055 55000055 012b4c08 55000055 55000055 55000055 55000055 012b4c18 55000055 55000055 55000055 55000055 0:000> 012b4c28 55000055 55000055 55000055 55000055 012b4c38 55000055 55000055 55000055 55000055 012b4c48 55000055 55000055 55000055 55000055 012b4c58 55000055 55000055 55000055 55000055 012b4c68 55000055 55000055 55000055 55000055 012b4c78 55000055 55000055 55000055 55000055 012b4c88 55000055 55000055 55000055 55000055 012b4c98 55000055 00000000 00000000 00555555 0:000> 012b4ca8 00555555 00555555 00555555 00555555 012b4cb8 00555555 00555555 00555555 00555555 012b4cc8 00555555 00555555 00555555 00555555 012b4cd8 00555555 00555555 00555555 00555555 012b4ce8 00555555 00555555 00555555 00555555 012b4cf8 00555555 00555555 00555555 00555555 012b4d08 00555555 00555555 00555555 00555555 012b4d18 00555555 00555555 00555555 00555555 0:000> 012b4d28 00555555 00555555 00555555 00555555 012b4d38 00555555 00555555 00555555 00555555 012b4d48 00555555 00555555 00555555 00555555 012b4d58 00555555 00555555 00555555 00555555 012b4d68 00555555 00555555 00555555 00555555 012b4d78 00555555 00555555 00555555 00555555 012b4d88 00555555 00555555 00555555 00555555 012b4d98 00555555 00555555 00555555 00555555 0:000> 012b4da8 00555555 00555555 00000000 55000000 012b4db8 55005500 55005500 55005500 55005500 012b4dc8 55005500 55005500 55005500 55005500 012b4dd8 55005500 55005500 55005500 55005500 012b4de8 55005500 55005500 55005500 55005500 012b4df8 55005500 55005500 55005500 55005500 012b4e08 55005500 55005500 55005500 55005500 012b4e18 55005500 55005500 55005500 55005500 0:000> 012b4e28 55005500 55005500 55005500 55005500 012b4e38 55005500 55005500 55005500 55005500 012b4e48 55005500 55005500 55005500 55005500 012b4e58 55005500 55005500 55005500 55005500 012b4e68 55005500 55005500 55005500 55005500 012b4e78 55005500 55005500 55005500 55005500 012b4e88 55005500 55005500 55005500 55005500 012b4e98 55005500 55005500 55005500 55005500 0:000> 012b4ea8 55005500 55005500 55005500 55005500 012b4eb8 55005500 55005500 55005500 00000000 012b4ec8 00000000 00555500 00555500 00555500 012b4ed8 00555500 00555500 00555500 00555500 012b4ee8 00555500 00555500 00555500 00555500 012b4ef8 00555500 00555500 00555500 00555500 012b4f08 00555500 00555500 00555500 00555500 012b4f18 00555500 00555500 00555500 00555500 0:000> 012b4f28 00555500 00555500 00555500 00555500 012b4f38 00555500 00555500 00555500 00555500 012b4f48 00555500 00555500 00555500 00555500 012b4f58 00555500 00555500 00555500 00555500 012b4f68 00555500 00555500 00555500 00555500 012b4f78 00555500 00555500 00555500 00555500 012b4f88 00555500 00555500 00555500 00555500 012b4f98 00555500 00555500 00555500 00555500 0:000> 012b4fa8 00555500 00555500 00555500 00555500 012b4fb8 00555500 00555500 00555500 00555500 012b4fc8 00555500 00555500 00555500 00555500 012b4fd8 00000000 55000000 55550055 55550055 012b4fe8 55550055 55550055 55550055 55550055 012b4ff8 55550055 55550055 55550055 55550055 012b5008 55550055 55550055 55550055 55550055 012b5018 55550055 55550055 55550055 55550055 0:000> 012b5028 55550055 55550055 55550055 55550055 012b5038 55550055 55550055 55550055 55550055 012b5048 55550055 55550055 55550055 55550055 012b5058 55550055 55550055 55550055 55550055 012b5068 55550055 55550055 55550055 55550055 012b5078 55550055 55550055 55550055 55550055 012b5088 55550055 55550055 55550055 55550055 012b5098 55550055 55550055 55550055 55550055 0:000> 012b50a8 55550055 55550055 55550055 55550055 012b50b8 55550055 55550055 55550055 55550055 012b50c8 55550055 55550055 55550055 55550055 012b50d8 55550055 55550055 55550055 55550055 012b50e8 55550055 00000000 55000000 55005500 012b50f8 55005500 55005500 55005500 55005500 012b5108 55005500 55005500 55005500 55005500 012b5118 55005500 55005500 55005500 55005500 0:000> 012b5128 55005500 55005500 55005500 55005500 012b5138 55005500 55005500 55005500 55005500 012b5148 55005500 55005500 55005500 55005500 012b5158 55005500 55005500 55005500 55005500 012b5168 55005500 55005500 55005500 55005500 012b5178 55005500 55005500 55005500 55005500 012b5188 55005500 55005500 55005500 55005500 012b5198 55005500 55005500 55005500 55005500 0:000> 012b51a8 55005500 55005500 55005500 55005500 012b51b8 55005500 55005500 55005500 55005500 012b51c8 55005500 55005500 55005500 55005500 012b51d8 55005500 55005500 55005500 55005500 012b51e8 55005500 55005500 55005500 55005500 012b51f8 55005500 55005500 00000000 55000000 012b5208 55000055 55000055 55000055 55000055 012b5218 55000055 55000055 55000055 55000055 0:000> 012b5228 55000055 55000055 55000055 55000055 012b5238 55000055 55000055 55000055 55000055 012b5248 55000055 55000055 55000055 55000055 012b5258 55000055 55000055 55000055 55000055 012b5268 55000055 55000055 55000055 55000055 012b5278 55000055 55000055 55000055 55000055 012b5288 55000055 55000055 55000055 55000055 012b5298 55000055 55000055 55000055 55000055 0:000> 012b52a8 55000055 55000055 55000055 55000055 012b52b8 55000055 55000055 55000055 55000055 012b52c8 55000055 55000055 55000055 55000055 012b52d8 55000055 55000055 55000055 55000055 012b52e8 55000055 55000055 55000055 55000055 012b52f8 55000055 55000055 55000055 55000055 012b5308 55000055 55000055 55000055 00000000 012b5318 00000000 00555555 00555555 00555555 0:000> 012b5328 00555555 00555555 00555555 00555555 012b5338 00555555 00555555 00555555 00555555 012b5348 00555555 00555555 00555555 00555555 012b5358 00555555 00555555 00555555 00555555 012b5368 00555555 00555555 00555555 00555555 012b5378 00555555 00555555 00555555 00555555 012b5388 00555555 00555555 00555555 00555555 012b5398 00555555 00555555 00555555 00555555 0:000> 012b53a8 00555555 00555555 00555555 00555555 012b53b8 00555555 00555555 00555555 00555555 012b53c8 00555555 00555555 00555555 00555555 012b53d8 00555555 00555555 00555555 00555555 012b53e8 00555555 00555555 00555555 00555555 012b53f8 00555555 00555555 00555555 00555555 012b5408 00555555 00555555 00555555 00555555 012b5418 00555555 00555555 00555555 00555555 0:000> 012b5428 00000000 55000000 55005500 55005500 012b5438 55005500 55005500 55005500 55005500 012b5448 55005500 55005500 55005500 55005500 012b5458 55005500 55005500 55005500 55005500 012b5468 55005500 55005500 55005500 55005500 012b5478 55005500 55005500 55005500 55005500 012b5488 55005500 55005500 55005500 55005500 012b5498 55005500 55005500 55005500 55005500 0:000> 012b54a8 55005500 55005500 55005500 55005500 012b54b8 55005500 55005500 55005500 55005500 012b54c8 55005500 55005500 55005500 55005500 012b54d8 55005500 55005500 55005500 55005500 012b54e8 55005500 55005500 55005500 55005500 012b54f8 55005500 55005500 55005500 55005500 012b5508 55005500 55005500 55005500 55005500 012b5518 55005500 55005500 55005500 55005500 0:000> 012b5528 55005500 55005500 55005500 55005500 012b5538 55005500 00000000 00000000 00555500 012b5548 00555500 00555500 00555500 00555500 012b5558 00555500 00555500 00555500 00555500 012b5568 00555500 00555500 00555500 00555500 012b5578 00555500 00555500 00555500 00555500 012b5588 00555500 00555500 00555500 00555500 012b5598 00555500 00555500 00555500 00555500 0:000> 012b55a8 00555500 00555500 00555500 00555500 012b55b8 00555500 00555500 00555500 00555500 012b55c8 00555500 00555500 00555500 00555500 012b55d8 00555500 00555500 00555500 00555500 012b55e8 00555500 00555500 00555500 00555500 012b55f8 00555500 00555500 00555500 00555500 012b5608 00555500 00555500 00555500 00555500 012b5618 00555500 00555500 00555500 00555500 0:000> 012b5628 00555500 00555500 00555500 00555500 012b5638 00555500 00555500 00555500 00555500 012b5648 00555500 00555500 00000000 55000000 012b5658 55550055 55550055 55550055 55550055 012b5668 55550055 55550055 55550055 55550055 012b5678 55550055 55550055 55550055 55550055 012b5688 55550055 55550055 55550055 55550055 012b5698 55550055 55550055 55550055 55550055 0:000> 012b56a8 55550055 55550055 55550055 55550055 012b56b8 55550055 55550055 55550055 55550055 012b56c8 55550055 55550055 55550055 55550055 012b56d8 55550055 55550055 55550055 55550055 012b56e8 55550055 55550055 55550055 55550055 012b56f8 55550055 55550055 55550055 55550055 012b5708 55550055 55550055 55550055 55550055 012b5718 55550055 55550055 55550055 55550055 0:000> 012b5728 55550055 55550055 55550055 55550055 012b5738 55550055 55550055 55550055 55550055 012b5748 55550055 55550055 55550055 55550055 012b5758 55550055 55550055 55550055 00000000 012b5768 55000000 55005500 55005500 55005500 012b5778 55005500 55005500 55005500 55005500 012b5788 55005500 55005500 55005500 55005500 012b5798 55005500 55005500 55005500 55005500 0:000> 012b57a8 55005500 55005500 55005500 55005500 012b57b8 55005500 55005500 55005500 55005500 012b57c8 55005500 55005500 55005500 55005500 012b57d8 55005500 55005500 55005500 55005500 012b57e8 55005500 55005500 55005500 55005500 012b57f8 55005500 55005500 55005500 55005500 012b5808 55005500 55005500 55005500 55005500 012b5818 55005500 55005500 55005500 55005500 0:000> 012b5828 55005500 55005500 55005500 55005500 012b5838 55005500 55005500 55005500 55005500 012b5848 55005500 55005500 55005500 55005500 012b5858 55005500 55005500 55005500 55005500 012b5868 55005500 55005500 55005500 55005500 012b5878 00000000 55000000 55000055 55000055 012b5888 55000055 55000055 55000055 55000055 012b5898 55000055 55000055 55000055 55000055 0:000> 012b58a8 55000055 55000055 55000055 55000055 012b58b8 55000055 55000055 55000055 55000055 012b58c8 55000055 55000055 55000055 55000055 012b58d8 55000055 55000055 55000055 55000055 012b58e8 55000055 55000055 55000055 55000055 012b58f8 55000055 55000055 55000055 55000055 012b5908 55000055 55000055 55000055 55000055 012b5918 55000055 55000055 55000055 55000055 0:000> 012b5928 55000055 55000055 55000055 55000055 012b5938 55000055 55000055 55000055 55000055 012b5948 55000055 55000055 55000055 55000055 012b5958 55000055 55000055 55000055 55000055 012b5968 55000055 55000055 55000055 55000055 012b5978 55000055 55000055 55000055 55000055 012b5988 55000055 00000000 00000000 00000000 012b5998 00000000 00000000 00000000 00000000 0:000> 012b59a8 00000000 00000000 00000000 00000000 012b59b8 00000000 00000000 00000000 00000000 012b59c8 00000000 00000000 00000000 00000000 012b59d8 00000000 00000000 00000000 00000000 012b59e8 00000000 00000000 00000000 00000000 012b59f8 00000000 00000000 00000000 00000000 012b5a08 00000000 00000000 00000000 00000000 012b5a18 00000000 00000000 00000000 00000000 0:000> 012b5a28 00000000 00000000 00000000 00000000 012b5a38 00000000 00000000 00000000 00000000 012b5a48 00000000 00000000 00000000 00000000 012b5a58 00000000 00000000 00000000 00000000 012b5a68 00000000 00000000 00000000 00000000 012b5a78 00000000 00000000 00000000 00000000 012b5a88 00000000 00000000 00000000 00000000 012b5a98 00000000 00000000 00000000 00000000 0:000> 012b5aa8 00000000 00000000 00000000 00000000 012b5ab8 00000000 00000000 00000000 00000000 012b5ac8 00000000 00000000 00000000 00000000 012b5ad8 00000000 00000000 00000000 00000000 012b5ae8 00000000 00000000 00000000 00000000 012b5af8 00000000 00000000 00000000 00000000 012b5b08 00000000 00000000 00000000 00000000 012b5b18 00000000 00000000 00000000 00000000 0:000> 012b5b28 00000000 00000000 00000000 00000000 012b5b38 00000000 00000000 00000000 00000000 012b5b48 00000000 00000000 00000000 00000000 012b5b58 00000000 00000000 00000000 00000000 012b5b68 00000000 00000000 00000000 00000000 012b5b78 00000000 00000000 00000000 00000000 012b5b88 00000000 00000000 00000000 00000000 012b5b98 00000000 00000000 00000000 00000000 0:000> 012b5ba8 00000000 00000000 00000000 00000000 012b5bb8 00000000 00000000 00000000 00000000 012b5bc8 00000000 00000000 00000000 00000000 012b5bd8 00000000 00000000 00000000 00000000 012b5be8 00000000 00000000 00000000 00000000 012b5bf8 00000000 00000000 00000000 00000000 012b5c08 00000000 00000000 00000000 00000000 012b5c18 00000000 00000000 00000000 00000000 0:000> 012b5c28 00000000 00000000 00000000 00000000 012b5c38 00000000 00000000 00000000 00000000 012b5c48 00000000 00000000 00000000 00000000 012b5c58 00000000 00000000 00000000 00000000 012b5c68 00000000 00000000 00000000 00000000 012b5c78 00000000 00000000 00000000 00000000 012b5c88 00000000 00000000 00000000 00000000 012b5c98 00000000 00000000 00000000 00000000 0:000> 012b5ca8 00000000 00000000 00000000 00000000 012b5cb8 00000000 00000000 00000000 00000000 012b5cc8 00000000 00200b16 00eb7e38 02216808 012b5cd8 00200898 01354828 00000000 00000000 012b5ce8 02214018 012b5d48 00000000 000002c2 012b5cf8 000000d5 0000012b 0118cd08 00000000 012b5d08 00000000 00000040 00000000 00000000 012b5d18 00000000 00000000 00000000 00000000 0:000> 012b5d28 02216830 c7c34f80 c7c34f80 c7c34f80 012b5d38 c7c34f80 00000000 00000000 002004ba 012b5d48 00000000 02216894 012b5e64 012b5cdc 012b5d58 00000056 00200470 00000000 022168ac 012b5d68 022168bc 0020052e 00e66248 00e63b70 012b5d78 00000000 011a0648 00e63b60 00200546 012b5d88 00e6609c 00e64e10 00000001 4061c71c 012b5d98 c7c34f80 c7c34f80 00200882 01353ec0 0:000> 012b5da8 00000000 00000000 02214018 012b5e64 012b5db8 00000000 000002c2 0000012b 00000137 012b5dc8 0118cd08 00000000 00000000 00000040 012b5dd8 00000000 00000000 00000000 00000000 012b5de8 00000000 00000000 012b5e10 c7c34f80 012b5df8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b5e08 c7c34f80 00200a3c 01340ff0 00000000 012b5e18 00000000 012b5da4 00000000 00000000 0:000> 012b5e28 000002c2 0000012b 00000137 0118cd08 012b5e38 00000000 00000000 00000040 00000000 012b5e48 00000000 00000000 00000000 00000052 012b5e58 00000000 00000000 002004ba 00000000 012b5e68 012b5d48 012b6118 012b5da4 0000000c 012b5e78 00200470 00000000 022168cc 022168bc 012b5e88 00200332 012b5e94 00000001 022168dc 012b5e98 00200470 00000000 0119e8cc 012b5eac 0:000> 012b5ea8 00200470 00000000 022168e8 012b5ebc 012b5eb8 00200470 00000000 022168dc 00000000 012b5ec8 00200470 00000000 012b5e9c 012b5e7c 012b5ed8 0020052e 00e66248 00e63b70 00000000 012b5ee8 011a0648 00e63b60 00200546 00e6609c 012b5ef8 00e63c80 00000001 c7c34f80 00000000 012b5f08 00000000 00200546 00e6609c 00e63900 012b5f18 00000000 c7c34f80 c7c34f80 c7c34f80 0:000> 012b5f28 00200470 00000000 022168dc 012b5ecc 012b5f38 00200470 00000000 022168dc 00000000 012b5f48 0020052e 00e66248 00e63b70 00000000 012b5f58 011a0648 00e63b60 00200548 00e6607c 012b5f68 00e64e10 00000001 022168dc 00200544 012b5f78 00e660bc 00e64564 00000000 40000000 012b5f88 00200544 00e660bc 00e64578 00000000 012b5f98 00000000 00200532 00e661e4 00e6458c 0:000> 012b5fa8 00000000 00000000 00200532 00e661e4 012b5fb8 00e645a4 00000000 00000001 00200532 012b5fc8 00e661e4 00e645b8 00000000 00000000 012b5fd8 00200534 01341518 00e64e10 00000000 012b5fe8 012b5ff8 00000001 00000001 00200540 012b5ff8 012b6000 00000003 012b5fa0 012b5fb4 012b6008 012b5fc8 00200548 00e6607c 00e6418c 012b6018 00000000 00000000 002008a0 01354e98 0:000> 012b6028 00000000 00000000 012b60ac 00000000 012b6038 00000000 000002c2 00000137 00000151 012b6048 0118cd08 00000000 00000000 00000040 012b6058 00000000 00000000 00000000 00000000 012b6068 022168dc 00000007 0119ff40 3f349f4a 012b6078 00000000 00000002 00000000 3f000000 012b6088 3f000000 000000b8 0000020a 00000137 012b6098 00000151 000000b8 0000014c 00000000 0:000> 012b60a8 00200898 01354828 00000000 00000000 012b60b8 02214018 012b6118 00000000 000002c2 012b60c8 00000137 00000151 0118cd08 00000000 012b60d8 00000000 00000040 00000000 00000000 012b60e8 00000000 00000000 00000000 00000000 012b60f8 012b6024 c7c34f80 c7c34f80 c7c34f80 012b6108 c7c34f80 00000000 00000000 002004ba 012b6118 00000000 012b5e64 012b6234 012b60ac 012b6128 0000001a 00200470 00000000 022168f8 012b6138 022168bc 0020052e 00e66248 00e63b70 012b6148 00000000 011a0648 00e63b60 00200546 012b6158 00e6609c 00e64e10 00000001 4061c71c 012b6168 c7c34f80 c7c34f80 00200882 01353ec0 012b6178 00000000 00000000 02214018 012b6234 012b6188 00000000 000002c2 00000151 0000015d 012b6198 0118cd08 00000000 00000000 00000040 012b61a8 00000000 00000000 00000000 00000000 012b61b8 00000000 00000000 012b61e0 c7c34f80 012b61c8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b61d8 c7c34f80 00200a3c 01340ff0 00000000 012b61e8 00000000 012b6174 00000000 00000000 012b61f8 000002c2 00000151 0000015d 0118cd08 012b6208 00000000 00000000 00000040 00000000 012b6218 00000000 00000000 00000000 00000052 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 04:27:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 02:27:09 +0000 Subject: [M3devel] FW: This is a pixmap? Message-ID: resorting to an attachment since this is important and keeps getting truncated -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jay.krell at cornell.edu Fri Sep 4 10:33:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 08:33:36 +0000 Subject: [M3devel] updating web site? Message-ID: http://modula3.elegosoft.com/cm3/index.html (http://modula3.elegosoft.com/cm3/start.html) looks really bad, with the nested frame I believe I fixed this days ago: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/www/start.html.diff?r1=1.3.2.2;r2=1.3.2.3 How does one get the web site to update? Maybe use head instead of the release branch? Maybe I didn't move the tag forward? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 10:54:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) Message-ID: short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 11:12:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 09:12:23 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 13:52:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 11:52:28 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 16:06:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 14:06:08 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 16:07:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 14:07:46 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 16:40:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 14:40:49 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Sep 4 17:10:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 04 Sep 2009 11:10:53 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: <4AA0F5A7.1E75.00D7.1@scires.com> Jay said: >This we shall blame on Trestle not fully being ported to Win32, I guess. >At the very least, it seems to the behavior going back a while. >You can occasionally see this in head, but usually you see #3. I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 4 18:44:21 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Sep 2009 12:44:21 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non- Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote: > no..still unsolved..not sure if I misobserved or what..will have to > backtrack.. > > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:07:46 +0000 > > (Well, duh, it wasn't ProcessPools(SuspendPool), that just has > assertions) > > - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:06:08 +0000 > > Restoring the: > ThreadF.ProcessPools(ClosePool); > > 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. > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 11:52:28 +0000 > > I have narrowed it way down to between "2009-02-16 02:00Z" and -D > "2009-02-16 02:30Z". > So please review this change. > I have reviewed it and tried to partly undo it, without luck yet. > There is a semantic change in BroadcastHeap where the broadcast used > to happen upon the next unlock > and now I think happens right away. I tried restoring that, but > again, no luck for me. > > Thanks, > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 09:12:23 +0000 > > I have narrowed it down further to between 2/15/2009 and 2/18/2009. > Next I will try old text code in head to see if it is that. > > Tony, can you double check this stuff: > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > > 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..). > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 08:54:54 +0000 > Subject: [M3devel] Juno on NT (presumably canary for other problems) > > short story: > > > I narrowed it down to between 2/15/2009 and 2/20/2009. > I will keep digging. > > There are actually a lot of changes in that brief period. > I will narrow it further. > > > long story: > > Juno on NT, as canary for other problems. > Juno on NT has three behaviors. > > > Behavior #1 > > > The most common historical behavior, an assertion failure: > C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\winvbt\WinContext.m3", line 165 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt > \WinContext.m3 > 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 > 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 > 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe30 0x7e418734 > 0x1b3fe98 0x7e418816 > 0x1b3fef8 0x7e4189cd > 0x1b3ff08 0x7e4196c7 > 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt > \WinTrestle.m3 > ......... ......... ... more frames ... > (1860.1d80): Break instruction exception - code 80000003 (first > chance) > eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 > edi=005d526b > eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz > na po nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00000202 > ntdll!DbgBreakPoint: > 7c90120e cc int 3 > 0:003> .lines > Line number information will be loaded > 0:003> k999 > ChildEBP RetAddr > 01b3f5bc 005d52b7 ntdll!DbgBreakPoint > 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime > \WIN32\RTOS.m3 @ 29] > 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common > \RTProcess. > m3 @ 66] > 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime > \common\RTError.m > 3 @ 118] > 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common > \RTError.m3 @ > 40] > 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime > \common\RTExcep > tion.m3 @ 79] > 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src > \runtime\commo > n\RTException.m3 @ 39] > 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src > \runtime\commo > n\RTException.m3 @ 47] > 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime > \common\RTHook > s.m3 @ 110] > 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt > \WinContext.m3 @ 1 > 7] > 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt > \WinContext.m3 > @ 167] > 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt > \WinPaint.m3 @ 71 > 2] > 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt > \WinPaint.m3 @ 5 > 1] > 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt > \WinTrestle > .m3 @ 1574] > 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt > \WinTrestle.m3 > @ 1163] > 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 > 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 > 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 > 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf > 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src > \winvbt\WinTrestl > e.m3 @ 2450] > 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread > \WIN32\Threa > dWin32.m3 @ 579] > 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread > \WIN32\Threa > dWin32.m3 @ 548] > 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 > 0:003> > > > This we shall blame on Trestle not fully being ported to Win32, I > guess. > At the very least, it seems to the behavior going back a while. > You can occasionally see this in head, but usually you see #3. > > > Behavior #2 > > Sometimes, rarely, Juno hangs in startup on NT. > I believe I have seen this both with fairly old and current versions. > This occurs very rarely. I might look into it more after #3 is solved. > > > Behavior #3 > > > An access violation (SIGSEGV to Unix folks) during startup. > This is the most common behavior with current source, going back a > few months. > It is almost always accessing address 00200000 and the instruction > pointer is very > often in Thread__Join, but neither are always true. > Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. > > > C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe > (1ac4.1e9c): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 > edi=02812974 > eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > m3core!Thread__Join+0x13f: > 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds: > 0023:001ffffc=???????? > 0:000> r ebx > ebx=00200000 > 0:000> .lines > Line number information will be loaded > 0:000> k > ChildEBP RetAddr > 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread > \WIN32\ThreadWin32.m3 > @ 710] > 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src > \JunoCompile. > m3 @ 256] > 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] > 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] > 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] > 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] > 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ > 174] > 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ > 263] > 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] > 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime > \common\RTLi > nker.m3 @ 399] > 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime > \common\RTLinker > .m3 @ 113] > 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime > \common\RTLinker. > m3 @ 122] > 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] > 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld > \self_x86\c > rt\src\crtexe.c @ 582] > 0012fff0 00000000 kernel32!BaseProcessStart+0x23 > 0:000> > > #4 sometimes other, for example: > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 411 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common > \RTCollector.m3 > 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common > \RTCollector.m > 3 > 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common > \RTCollector.m3 > 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src > \runtime\common\RT > Collector.m3 > 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common > \RTCollector.m3 > 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common > \RTCollector. > m3 > 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common > \RTCollector.m3 > ......... ......... ... more frames ... > (14b0.121c): Break instruction exception - code 80000003 (first > chance) > > for example: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\src\vbt\VBTRep.m3", line 644 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 > 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 > 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 > 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > (1c3c.e3c): Break instruction exception - code 80000003 (first chance) > > I figure these are just a variation of #3. > > Now, I finally learned how to give CVS a date to checkout or update. > And NT builds very fast due to the integrated backend. > So I have been building various dates. > > The change between #3 and #1 happened around mid February 2009. > Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, > #4 above is from 2009/02/20. > And 2009/02/20 also access violates on 00200000 often. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 21:44:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 19:44:51 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: <4AA0F5A7.1E75.00D7.1@scires.com> References: <4AA0F5A7.1E75.00D7.1@scires.com> Message-ID: Randy, thanks, understood. Actually Juno does draw a bunch of fancy stuff before the assertion failure. And formsedit at least historically works, and I thought mentor but I'll have to retest after Tony fixes, and with old versions. Yes please test anything you can. I can get you an HP-UX toolset if you need..assumiing I can resolve why last I powered the machine on I couldn't see it on the network. At some point we might even get HP-UX in Hudson. :) - Jay Date: Fri, 4 Sep 2009 11:10:53 -0400 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay said: >This we shall blame on Trestle not fully being ported to Win32, I guess. >At the very least, it seems to the behavior going back a while. >You can occasionally see this in head, but usually you see #3. I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 21:42:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 19:42:58 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: > no..still unsolved..not sure if I misobserved or what..will have to backtrack.. To clarify, the problem is between "2009-02-16 02:00Z" and "2009-02-16 02:30Z", just that I don't know either of - a small change to "2009-02-16 02:30Z" to fix it - and applying such to head - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Date: Fri, 4 Sep 2009 14:40:49 +0000 Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Sep 4 22:21:47 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 04 Sep 2009 16:21:47 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: <4AA0F5A7.1E75.00D7.1@scires.com> Message-ID: <4AA13E82.1E75.00D7.1@scires.com> Jay: Yeah I see the Juno window start up on most runs, but then it crashes so quickly that you can't see much before the window disappears. I use formsedit quite a bit. I recall that back when we purchased Reactor/cm3 v4.1, that Farshad and company had to make some patches to formsedit because it crashed on certain platforms. Critical Mass provided us with the patched executables, but I never got the sources. Not sure if the patches got put into what we have now. There are some problems now with formsedit that I've documented in the past. One of the big ones has to deal with keeping the cursor placement in sync between what is shown on the display and what the program actually thinks, particularly when switching between mouse and keyboard movement. Similarly, I know that Reactor was a work in progress. Although I worked with Farshad to obtain the sources for the open source release as CM3IDE, I'm not confident that all the latest greatest sources actually made it to me in the version Farshad supplied. He had to dig back through some archives to obtain them. I've noticed some operational differences between my old "Reactor" and the new "CM3IDE". Monday is a holiday for me, so I'll try to devote some time this long weekend on running more tests. If you want me to run stuff on HP-UX, I'll have to pull the machine "out-of-moth-balls" so to speak because its been a long time since I've used it. I think I still have three HP-UX machines. One of them had a hard drive problem with one of its SCSI drives so that may take some to repair. I'll also try to look at some of the scripts ya'll are using for the automated tests and see if there is a way I can run some of these tests on XP and Vista (unless ya'll already have that covered on a VM for Hudson--let me know if I don't need to do this). Regards, Randy >>> Jay K 9/4/2009 3:44 PM >>> Randy, thanks, understood. Actually Juno does draw a bunch of fancy stuff before the assertion failure. And formsedit at least historically works, and I thought mentor but I'll have to retest after Tony fixes, and with old versions. Yes please test anything you can. I can get you an HP-UX toolset if you need..assumiing I can resolve why last I powered the machine on I couldn't see it on the network. At some point we might even get HP-UX in Hudson. :) - Jay Date: Fri, 4 Sep 2009 11:10:53 -0400 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay said: >This we shall blame on Trestle not fully being ported to Win32, I guess. >At the very least, it seems to the behavior going back a while. >You can occasionally see this in head, but usually you see #3. I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 23:20:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 21:20:13 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: <4AA13E82.1E75.00D7.1@scires.com> References: <4AA0F5A7.1E75.00D7.1@scires.com> <4AA13E82.1E75.00D7.1@scires.com> Message-ID: > unless ya'll already have that covered on a VM for Hudson We do. Another wouldn't hurt much though, except time/energy. Maybe document the setup. We had a bunch of problems, though some were due to wierdo missteps that I would have called out had I been paying close attention. That is, setup is more like "leave the defaults, don't do extra wierd stuff". CVSNT by default changes line endings, breaking all .sh files. Maybe there is a setting to fix it? I'm not sure. The documentation is very confusing on this point. It talks about a keyword setting on a per file basis. Or maybe a checkout/update option? So Cygwin text mode mounts were used, which partly fixes the problem, but leaves caltech-parser broken (it should be fixed to allow for \n, \r, or \r\n.). Had I noticed I would have avoided the text mode mount in the first place. Fixed by: Use Cygwin cvs as I've been using all along. Don't use textmode mounts, use the default. Also cygwin mount cygexec was being used. I don't know what that really does. No longer used. It's not the default. Cygwin sshd has a bug that breaks Visual C++ link.exe. Seriously. We switched to another sshd, and paid a small licensing fee. Sometimes reboot needed to get sshd/ssh/scp working. The initial setup up cm3 itself has some kinks as well that Olaf pledges to improve after the current release -- where to find a baseline cm3 to start with and possibly m3core/libm3. It's probably easier, though still a small pain, to run the Tinderbox stuff. I checked in a document detailing my experience. Tinderbox doesn't require Java or sshd. I would still avoid CVSNT unless that behavior can be remedied. - Jay ________________________________ > Date: Fri, 4 Sep 2009 16:21:47 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) > > > > > > > > > > Jay: > > > > Yeah I see the Juno window start up on most runs, but then it crashes so quickly that you can't see much before the window disappears. > > > > I use formsedit quite a bit. I recall that back when we purchased Reactor/cm3 v4.1, that Farshad and company had to make some patches to formsedit because it crashed on certain platforms. Critical Mass provided us with the patched executables, but I never got the sources. Not sure if the patches got put into what we have now. > > > > There are some problems now with formsedit that I've documented in the past. One of the big ones has to deal with keeping the cursor placement in sync between what is shown on the display and what the program actually thinks, particularly when switching between mouse and keyboard movement. > > > > Similarly, I know that Reactor was a work in progress. Although I worked with Farshad to obtain the sources for the open source release as CM3IDE, I'm not confident that all the latest greatest sources actually made it to me in the version Farshad supplied. He had to dig back through some archives to obtain them. I've noticed some operational differences between my old "Reactor" and the new "CM3IDE". > > > > Monday is a holiday for me, so I'll try to devote some time this long weekend on running more tests. If you want me to run stuff on HP-UX, I'll have to pull the machine "out-of-moth-balls" so to speak because its been a long time since I've used it. I think I still have three HP-UX machines. One of them had a hard drive problem with one of its SCSI drives so that may take some to repair. I'll also try to look at some of the scripts ya'll are using for the automated tests and see if there is a way I can run some of these tests on XP and Vista (unless ya'll already have that covered on a VM for Hudson--let me know if I don't need to do this). > > > > Regards, > > Randy > >>>> Jay K 9/4/2009 3:44 PM>>> > Randy, thanks, understood. Actually Juno does draw a bunch of fancy stuff before the assertion failure. And formsedit at least historically works, and I thought mentor but I'll have to retest after Tony fixes, and with old versions. Yes please test anything you can. I can get you an HP-UX toolset if you need..assumiing I can resolve why last I powered the machine on I couldn't see it on the network. At some point we might even get HP-UX in Hudson. :) > > - Jay > > > > > ________________________________ > > > Date: Fri, 4 Sep 2009 11:10:53 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) > > > > > Jay said: > >>This we shall blame on Trestle not fully being ported to Win32, I guess. >>At the very least, it seems to the behavior going back a while. >>You can occasionally see this in head, but usually you see #3. > > I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. > > > > Regards, > > Randy From jay.krell at cornell.edu Sun Sep 6 14:30:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Sep 2009 12:30:27 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Tony both of these timestamps are somewhat prone to hanging during Juno I386_DARWIN startup. But they don't crash, er..well they do both fail assertions in text, but I just put current source in to address that. I'm going to search backward for a time that doesn't hang. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 4 Sep 2009 12:44:21 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non-Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote:no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 6 16:04:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Sep 2009 14:04:55 +0000 Subject: [M3devel] XSharedMem.m3 Message-ID: The file m3-ui/ui/src/xvbt/XSharedMem.m3 has a bug. The function IsSameHost is wrong. What does it matter either way? Can the code that uses it just depend on the shared memory stuff working? Or is it important to know if really on the same machine? That is, can it just be hardcoded as TRUE and back progatate that assumption to its callers? Apple's X11 does like this: bash-3.2$ echo $DISPLAY /tmp/launch-gTYtJF/:0 which causes this IsSameHost code to fail. You can see I put in a band-aid a while ago, but it isn't really fixed. Why have I never heard of this problem in other X code? Because X seems to stink so I don't pay much attention to it.. Because X is little used on Macs? Little used in general? .. (note that Interix seems to lack some of this XSharedMem stuff, therefore so far no Modula-3 gui apps on it. Now that I see this optionality though, maybe it is easy to workaround?) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 6 18:11:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Sep 2009 16:11:28 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Tony, I386_DARWIN Juno is very prone to hang during startup going back at least until 2007/12/01. But they certainly don't always hang. I haven't found a version yet that doesn't hang. I'll look some more. I guess soon I should try other platforms? Sometimes there is a pause and it continues. Perhaps the hangs I'm just being too impatient on?? But, then, it's a bit inconsistent. Has it ever worked? Race condition in Juno maybe? It isn't always easy to build these old dates. Caveats: I'm using just current cm3cg. I started seeing as complain about older cm3cg output. Current config files. Build standalone (as current config files do with older compilers automatically, for "old" == missing the symlink functions). Patched XSharedMem/IsSameHost to always be FALSE, though TRUE would be correct, FALSE seems safe, I have to read that code.. Here is 2007/12/01 hung. It got as far as displaying "Curve" in the startup text that goes by. (gdb) thread apply all bt Thread 9 (process 32852 thread 0x294f): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1e8c in Thread__AlertWait () #5 0x00290988 in Formatter__Allocate () #6 0x00291137 in Formatter__Probe () #7 0x0029178e in Formatter__Peek () #8 0x00291677 in Formatter__PeekOp () #9 0x00291d18 in Formatter__PrintUntil () #10 0x002918d2 in Formatter__PrintTop () #11 0x002e3651 in ThreadPThread__RunThread () #12 0x002e33a3 in ThreadPThread__ThreadBase () #13 0x96f74155 in _pthread_start () #14 0x96f74012 in thread_start () Thread 8 (process 32852 thread 0x2603): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001aad83 in XMessenger__Messenger () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 7 (process 32852 thread 0x2503): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001b68da in XInput__FilterXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 6 (process 32852 thread 0x240f): #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () #1 0x96fc8261 in select () #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () #3 0x002e4b05 in ThreadPThread__XIOWait () #4 0x002e4614 in SchedulerPosix__IOWait () #5 0x001b65f5 in XInput__WaitForXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 5 (process 32852 thread 0x2303): #0 0x96f433a6 in mach_wait_until () #1 0x96fba3ad in nanosleep () #2 0x002e423c in ThreadPThread__XPause () #3 0x002e4393 in Thread__Pause () #4 0x0011113a in FileBrowserVBT__Watcher () #5 0x002e3651 in ThreadPThread__RunThread () #6 0x002e33a3 in ThreadPThread__ThreadBase () #7 0x96f74155 in _pthread_start () #8 0x96f74012 in thread_start () Thread 4 (process 32852 thread 0x2203): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001883f9 in VTView__VFontCleanUpThread () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 3 (process 32852 thread 0x2103): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001eb9c2 in VBTRep__MeterMaid () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 2 (process 32852 thread 0x313): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e65ec in RTOS__WaitHeap () #6 0x002d2d54 in RTCollector__WeakCleaner () #7 0x002e3651 in ThreadPThread__RunThread () #8 0x002e33a3 in ThreadPThread__ThreadBase () #9 0x96f74155 in _pthread_start () #10 0x96f74012 in thread_start () Thread 1 (process 32852 local thread 0x2d03): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e3ddb in Thread__Join () #6 0x0028f53d in Formatter__Close () #7 0x00079485 in JunoUnparse__Expr () #8 0x00021721 in Editor__Pass4 () #9 0x00022048 in EditorUI__CompileUI () #10 0x0003e7f8 in Juno__CompileEditor () #11 0x0003e98d in Juno__CompileModule () #12 0x0003f3be in Juno__CompileModules () #13 0x0004d43d in Juno_M3 () #14 0x002d71fa in RTLinker__RunMainBody () #15 0x002d67b0 in RTLinker__AddUnitI () #16 0x002d682e in RTLinker__AddUnit () #17 0x00003c88 in main () - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Sun, 6 Sep 2009 12:30:27 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Tony both of these timestamps are somewhat prone to hanging during Juno I386_DARWIN startup. But they don't crash, er..well they do both fail assertions in text, but I just put current source in to address that. I'm going to search backward for a time that doesn't hang. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 4 Sep 2009 12:44:21 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non-Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote:no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 03:49:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 01:49:28 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack. Current LINUXLIBC6 Juno doesn't seem to ever hang. So I conclude, with obvious non scientific firmness, that the Darwin-specific threading has never really worked and that the problem lies with it, not within the common code (or perhaps in the common code but only in how it mixes with the Darwin code). - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Sun, 6 Sep 2009 16:11:28 +0000 Tony, I386_DARWIN Juno is very prone to hang during startup going back at least until 2007/12/01. But they certainly don't always hang. I haven't found a version yet that doesn't hang. I'll look some more. I guess soon I should try other platforms? Sometimes there is a pause and it continues. Perhaps the hangs I'm just being too impatient on?? But, then, it's a bit inconsistent. Has it ever worked? Race condition in Juno maybe? It isn't always easy to build these old dates. Caveats: I'm using just current cm3cg. I started seeing as complain about older cm3cg output. Current config files. Build standalone (as current config files do with older compilers automatically, for "old" == missing the symlink functions). Patched XSharedMem/IsSameHost to always be FALSE, though TRUE would be correct, FALSE seems safe, I have to read that code.. Here is 2007/12/01 hung. It got as far as displaying "Curve" in the startup text that goes by. (gdb) thread apply all bt Thread 9 (process 32852 thread 0x294f): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1e8c in Thread__AlertWait () #5 0x00290988 in Formatter__Allocate () #6 0x00291137 in Formatter__Probe () #7 0x0029178e in Formatter__Peek () #8 0x00291677 in Formatter__PeekOp () #9 0x00291d18 in Formatter__PrintUntil () #10 0x002918d2 in Formatter__PrintTop () #11 0x002e3651 in ThreadPThread__RunThread () #12 0x002e33a3 in ThreadPThread__ThreadBase () #13 0x96f74155 in _pthread_start () #14 0x96f74012 in thread_start () Thread 8 (process 32852 thread 0x2603): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001aad83 in XMessenger__Messenger () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 7 (process 32852 thread 0x2503): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001b68da in XInput__FilterXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 6 (process 32852 thread 0x240f): #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () #1 0x96fc8261 in select () #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () #3 0x002e4b05 in ThreadPThread__XIOWait () #4 0x002e4614 in SchedulerPosix__IOWait () #5 0x001b65f5 in XInput__WaitForXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 5 (process 32852 thread 0x2303): #0 0x96f433a6 in mach_wait_until () #1 0x96fba3ad in nanosleep () #2 0x002e423c in ThreadPThread__XPause () #3 0x002e4393 in Thread__Pause () #4 0x0011113a in FileBrowserVBT__Watcher () #5 0x002e3651 in ThreadPThread__RunThread () #6 0x002e33a3 in ThreadPThread__ThreadBase () #7 0x96f74155 in _pthread_start () #8 0x96f74012 in thread_start () Thread 4 (process 32852 thread 0x2203): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001883f9 in VTView__VFontCleanUpThread () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 3 (process 32852 thread 0x2103): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001eb9c2 in VBTRep__MeterMaid () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 2 (process 32852 thread 0x313): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e65ec in RTOS__WaitHeap () #6 0x002d2d54 in RTCollector__WeakCleaner () #7 0x002e3651 in ThreadPThread__RunThread () #8 0x002e33a3 in ThreadPThread__ThreadBase () #9 0x96f74155 in _pthread_start () #10 0x96f74012 in thread_start () Thread 1 (process 32852 local thread 0x2d03): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e3ddb in Thread__Join () #6 0x0028f53d in Formatter__Close () #7 0x00079485 in JunoUnparse__Expr () #8 0x00021721 in Editor__Pass4 () #9 0x00022048 in EditorUI__CompileUI () #10 0x0003e7f8 in Juno__CompileEditor () #11 0x0003e98d in Juno__CompileModule () #12 0x0003f3be in Juno__CompileModules () #13 0x0004d43d in Juno_M3 () #14 0x002d71fa in RTLinker__RunMainBody () #15 0x002d67b0 in RTLinker__AddUnitI () #16 0x002d682e in RTLinker__AddUnit () #17 0x00003c88 in main () - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Sun, 6 Sep 2009 12:30:27 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Tony both of these timestamps are somewhat prone to hanging during Juno I386_DARWIN startup. But they don't crash, er..well they do both fail assertions in text, but I just put current source in to address that. I'm going to search backward for a time that doesn't hang. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 4 Sep 2009 12:44:21 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non-Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote:no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 04:34:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 02:34:29 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: [was truncated] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack. Current LINUXLIBC6 Juno doesn't seem to ever hang. So I conclude, with obvious non scientific firmness, that the Darwin-specific threading has never really worked and that the problem lies with it, not within the common code (or perhaps in the common code but only in how it mixes with the Darwin code). - Jay From: jay.krell at cornell.edu [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 05:18:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 03:18:40 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack. Current LINUXLIBC6 Juno doesn't seem to ever hang. So I conclude, with obvious non scientific firmness, that the Darwin-specific threading has never really worked and that the problem lies with it, not within the common code (or perhaps in the common code but only in how it mixes with the Darwin code). - Jay From: jay.krell at cornell.edu [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 11:33:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 09:33:39 +0000 Subject: [M3devel] (no subject) Message-ID: Tony, can you..um, trick question sort of, briefly explain the differences between pthreads and Modula-3 threads? The "trick" part is that, to an audience (me) who is not all that familiar with the nuances of either? I'll see if I can find my green book and other reference material (online). I understand the basics of threading very well, if that helps. Eh, not much to it really. I'm not super familiar with condition variables, as Win32 didn't historically have them. But I think I understand them. Specific questions: Can Modula-3 threads be implemented more directly upon pthreads? Why do we need to maintain a waiting list? Is "alert" the same as "cancel" in pthread vocabulary? Or almost the same? I understand..there might be a difficult problem..does Modula-3 allow catching an alert? I think so. Does Posix allow canceling a cancel? I think not. Posix allows, what I think of as try/finally, for alert. Modula-3 probably does too. Even though you can't stop the cancel, you can run "cleanup" code that runs before the cancel completes. However mapping Modula-3 to Posix here would be tricky. As I see things..any function with a try/finally would have to be contorted into a form that passes a pointer to itself, along with parameters, to C code that does pthread_cleanup_push/pop around calling the function pointer. At least given the Darwin implementation. Other implementations might simply be able to call push at the start and pop at the end. But on Darwin these functions are macros where push introduces a local variable that pop references. I guess maybe one could to the "reverse engineering" approach (just by reading the header). But it'd still be ugly. I have to do more research here. I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is thinner than the current ThreadPThread.m3 and see how it fairs, specifically if the Juno hangs go away. "writing" being an exaggeration because it should be very small. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 7 17:06:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Sep 2009 11:06:41 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: It used to work... :-) On 6 Sep 2009, at 21:49, Jay K wrote: > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack. > Current LINUXLIBC6 Juno doesn't seem to ever hang. > So I conclude, with obvious non scientific firmness, that the Darwin- > specific threading has never really worked and that the problem lies > with it, not within the common code (or perhaps in the common code > but only in how it mixes with the Darwin code). > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Sun, 6 Sep 2009 16:11:28 +0000 > > Tony, I386_DARWIN Juno is very prone to hang during startup going > back at least until 2007/12/01. > But they certainly don't always hang. > I haven't found a version yet that doesn't hang. I'll look some > more. I guess soon I should try other platforms? > Sometimes there is a pause and it continues. Perhaps the hangs I'm > just being too impatient on?? > But, then, it's a bit inconsistent. > Has it ever worked? > Race condition in Juno maybe? > It isn't always easy to build these old dates. > Caveats: > I'm using just current cm3cg. I started seeing as complain about > older cm3cg output. > Current config files. > Build standalone (as current config files do with older compilers > automatically, for "old" == missing the symlink functions). > Patched XSharedMem/IsSameHost to always be FALSE, though TRUE > would be correct, FALSE seems safe, I have to read that code.. > > Here is 2007/12/01 hung. > It got as far as displaying "Curve" in the startup text that goes by. > > (gdb) thread apply all bt > > Thread 9 (process 32852 thread 0x294f): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1e8c in Thread__AlertWait () > #5 0x00290988 in Formatter__Allocate () > #6 0x00291137 in Formatter__Probe () > #7 0x0029178e in Formatter__Peek () > #8 0x00291677 in Formatter__PeekOp () > #9 0x00291d18 in Formatter__PrintUntil () > #10 0x002918d2 in Formatter__PrintTop () > #11 0x002e3651 in ThreadPThread__RunThread () > #12 0x002e33a3 in ThreadPThread__ThreadBase () > #13 0x96f74155 in _pthread_start () > #14 0x96f74012 in thread_start () > > Thread 8 (process 32852 thread 0x2603): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001aad83 in XMessenger__Messenger () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 7 (process 32852 thread 0x2503): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001b68da in XInput__FilterXInput () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 6 (process 32852 thread 0x240f): > #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () > #1 0x96fc8261 in select () > #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () > #3 0x002e4b05 in ThreadPThread__XIOWait () > #4 0x002e4614 in SchedulerPosix__IOWait () > #5 0x001b65f5 in XInput__WaitForXInput () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 5 (process 32852 thread 0x2303): > #0 0x96f433a6 in mach_wait_until () > #1 0x96fba3ad in nanosleep () > #2 0x002e423c in ThreadPThread__XPause () > #3 0x002e4393 in Thread__Pause () > #4 0x0011113a in FileBrowserVBT__Watcher () > #5 0x002e3651 in ThreadPThread__RunThread () > #6 0x002e33a3 in ThreadPThread__ThreadBase () > #7 0x96f74155 in _pthread_start () > #8 0x96f74012 in thread_start () > > Thread 4 (process 32852 thread 0x2203): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001883f9 in VTView__VFontCleanUpThread () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 3 (process 32852 thread 0x2103): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001eb9c2 in VBTRep__MeterMaid () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > > Thread 2 (process 32852 thread 0x313): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x002e65ec in RTOS__WaitHeap () > #6 0x002d2d54 in RTCollector__WeakCleaner () > #7 0x002e3651 in ThreadPThread__RunThread () > #8 0x002e33a3 in ThreadPThread__ThreadBase () > #9 0x96f74155 in _pthread_start () > #10 0x96f74012 in thread_start () > > Thread 1 (process 32852 local thread 0x2d03): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x002e3ddb in Thread__Join () > #6 0x0028f53d in Formatter__Close () > #7 0x00079485 in JunoUnparse__Expr () > #8 0x00021721 in Editor__Pass4 () > #9 0x00022048 in EditorUI__CompileUI () > #10 0x0003e7f8 in Juno__CompileEditor () > #11 0x0003e98d in Juno__CompileModule () > #12 0x0003f3be in Juno__CompileModules () > #13 0x0004d43d in Juno_M3 () > #14 0x002d71fa in RTLinker__RunMainBody () > #15 0x002d67b0 in RTLinker__AddUnitI () > #16 0x002d682e in RTLinker__AddUnit () > #17 0x00003c88 in main () > > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 6 Sep 2009 12:30:27 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other > problems) > > Tony both of these timestamps are somewhat prone to hanging during > Juno I386_DARWIN startup. But they don't crash, er..well they do > both fail assertions in text, but I just put current source in to > address that. I'm going to search backward for a time that doesn't > hang. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 4 Sep 2009 12:44:21 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other > problems) > > Jay, > > I can rapidly diagnose any problems in the code you have been > messing with. Let me get a version on the head that "works" (at > least for non-Windows) and then we can move on to see what other > problems there may be in the WIndows part of the workd. > > -- Tony > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 4 Sep 2009, at 10:40, Jay K wrote: > > no..still unsolved..not sure if I misobserved or what..will have to > backtrack.. > > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:07:46 +0000 > > (Well, duh, it wasn't ProcessPools(SuspendPool), that just has > assertions) > > - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:06:08 +0000 > > Restoring the: > ThreadF.ProcessPools(ClosePool); > > 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. > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 11:52:28 +0000 > > I have narrowed it way down to between "2009-02-16 02:00Z" and -D > "2009-02-16 02:30Z". > So please review this change. > I have reviewed it and tried to partly undo it, without luck yet. > There is a semantic change in BroadcastHeap where the broadcast used > to happen upon the next unlock > and now I think happens right away. I tried restoring that, but > again, no luck for me. > > Thanks, > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 09:12:23 +0000 > > I have narrowed it down further to between 2/15/2009 and 2/18/2009. > Next I will try old text code in head to see if it is that. > > Tony, can you double check this stuff: > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > > 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..). > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 08:54:54 +0000 > Subject: [M3devel] Juno on NT (presumably canary for other problems) > > short story: > > > I narrowed it down to between 2/15/2009 and 2/20/2009. > I will keep digging. > > There are actually a lot of changes in that brief period. > I will narrow it further. > > > long story: > > Juno on NT, as canary for other problems. > Juno on NT has three behaviors. > > > Behavior #1 > > > The most common historical behavior, an assertion failure: > C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\winvbt\WinContext.m3", line 165 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt > \WinContext.m3 > 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 > 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 > 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe30 0x7e418734 > 0x1b3fe98 0x7e418816 > 0x1b3fef8 0x7e4189cd > 0x1b3ff08 0x7e4196c7 > 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt > \WinTrestle.m3 > ......... ......... ... more frames ... > (1860.1d80): Break instruction exception - code 80000003 (first > chance) > eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 > edi=005d526b > eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz > na po nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00000202 > ntdll!DbgBreakPoint: > 7c90120e cc int 3 > 0:003> .lines > Line number information will be loaded > 0:003> k999 > ChildEBP RetAddr > 01b3f5bc 005d52b7 ntdll!DbgBreakPoint > 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime > \WIN32\RTOS.m3 @ 29] > 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common > \RTProcess. > m3 @ 66] > 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime > \common\RTError.m > 3 @ 118] > 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common > \RTError.m3 @ > 40] > 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime > \common\RTExcep > tion.m3 @ 79] > 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src > \runtime\commo > n\RTException.m3 @ 39] > 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src > \runtime\commo > n\RTException.m3 @ 47] > 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime > \common\RTHook > s.m3 @ 110] > 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt > \WinContext.m3 @ 1 > 7] > 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt > \WinContext.m3 > @ 167] > 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt > \WinPaint.m3 @ 71 > 2] > 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt > \WinPaint.m3 @ 5 > 1] > 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt > \WinTrestle > .m3 @ 1574] > 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt > \WinTrestle.m3 > @ 1163] > 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 > 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 > 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 > 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf > 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src > \winvbt\WinTrestl > e.m3 @ 2450] > 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread > \WIN32\Threa > dWin32.m3 @ 579] > 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread > \WIN32\Threa > dWin32.m3 @ 548] > 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 > 0:003> > > > This we shall blame on Trestle not fully being ported to Win32, I > guess. > At the very least, it seems to the behavior going back a while. > You can occasionally see this in head, but usually you see #3. > > > Behavior #2 > > Sometimes, rarely, Juno hangs in startup on NT. > I believe I have seen this both with fairly old and current versions. > This occurs very rarely. I might look into it more after #3 is solved. > > > Behavior #3 > > > An access violation (SIGSEGV to Unix folks) during startup. > This is the most common behavior with current source, going back a > few months. > It is almost always accessing address 00200000 and the instruction > pointer is very > often in Thread__Join, but neither are always true. > Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. > > > C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe > (1ac4.1e9c): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 > edi=02812974 > eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > m3core!Thread__Join+0x13f: > 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds: > 0023:001ffffc=???????? > 0:000> r ebx > ebx=00200000 > 0:000> .lines > Line number information will be loaded > 0:000> k > ChildEBP RetAddr > 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread > \WIN32\ThreadWin32.m3 > @ 710] > 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src > \JunoCompile. > m3 @ 256] > 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] > 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] > 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] > 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] > 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ > 174] > 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ > 263] > 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] > 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime > \common\RTLi > nker.m3 @ 399] > 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime > \common\RTLinker > .m3 @ 113] > 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime > \common\RTLinker. > m3 @ 122] > 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] > 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld > \self_x86\c > rt\src\crtexe.c @ 582] > 0012fff0 00000000 kernel32!BaseProcessStart+0x23 > 0:000> > > #4 sometimes other, for example: > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 411 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common > \RTCollector.m3 > 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common > \RTCollector.m > 3 > 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common > \RTCollector.m3 > 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src > \runtime\common\RT > Collector.m3 > 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common > \RTCollector.m3 > 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common > \RTCollector. > m3 > 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common > \RTCollector.m3 > ......... ......... ... more frames ... > (14b0.121c): Break instruction exception - code 80000003 (first > chance) > > for example: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\src\vbt\VBTRep.m3", line 644 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 > 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 > 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 > 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > (1c3c.e3c): Break instruction exception - code 80000003 (first chance) > > I figure these are just a variation of #3. > > Now, I finally learned how to give CVS a date to checkout or update. > And NT builds very fast due to the integrated backend. > So I have been building various dates. > > The change between #3 and #1 happened around mid February 2009. > Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, > #4 above is from 2009/02/20. > And 2009/02/20 also access violates on 00200000 often. > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 7 17:17:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Sep 2009 11:17:50 -0400 Subject: [M3devel] (no subject) In-Reply-To: References: Message-ID: Jay, Before you go off half cocked and brew up some new threads system might I suggest that it would be better to find and fix the current problem. I am sceptical that there is a much thinner M3 thread implementation on top of pthreads than we currently have. I am in the process of tracking down the problem on I386_DARWIN (I see at least one thing broken right now, and will have a fix soon). In answer to your question, the wait list is to deal with M3 alerts, which are not the same as pthread cancellation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Sep 2009, at 05:33, Jay K wrote: > Tony, can you..um, trick question sort of, briefly explain the > differences between pthreads and Modula-3 threads? > The "trick" part is that, to an audience (me) who is not all that > familiar with the nuances of either? > I'll see if I can find my green book and other reference material > (online). > > > I understand the basics of threading very well, if that helps. > Eh, not much to it really. > > > I'm not super familiar with condition variables, as Win32 didn't > historically have them. > But I think I understand them. > > > Specific questions: > Can Modula-3 threads be implemented more directly upon pthreads? > > > Why do we need to maintain a waiting list? > > > Is "alert" the same as "cancel" in pthread vocabulary? Or almost > the same? > > > I understand..there might be a difficult problem..does Modula-3 > allow catching an alert? I think so. > Does Posix allow canceling a cancel? I think not. > > > Posix allows, what I think of as try/finally, for alert. Modula-3 > probably does too. Even though you can't stop the cancel, you can > run "cleanup" code that runs before the cancel completes. > > > However mapping Modula-3 to Posix here would be tricky. As I see > things..any function with a try/finally would have to be contorted > into a form that passes a pointer to itself, along with parameters, > to C code that does pthread_cleanup_push/pop around calling the > function pointer. At least given the Darwin implementation. Other > implementations might simply be able to call push at the start and > pop at the end. But on Darwin these functions are macros where push > introduces a local variable that pop references. I guess maybe one > could to the "reverse engineering" approach (just by reading the > header). But it'd still be ugly. > > > I have to do more research here. > > > I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is > thinner than the current ThreadPThread.m3 and see how it fairs, > specifically if the Juno hangs go away. > "writing" being an exaggeration because it should be very small. > > > Thanks, > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Sep 7 17:30:52 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 7 Sep 2009 15:30:52 +0000 (GMT) Subject: [M3devel] (no subject) Threads Primitives In-Reply-To: Message-ID: <258903.40993.qm@web23604.mail.ird.yahoo.com> Hi all: Please consider this reading:? "Synchronization Primitives for Threads" which has a formal definition and proof for threads primitives: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.1092 and? "Pthreads and Applications of Mutex-Abstraction" http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5367 Also the formal definition of the thread Interface from DEC SRC research Report 20 (revised in the Green book, Systems programming with Modula-3 as? Chapter 5): ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/abstracts/src-rr-020.html and? an introduction to programming with Threads DEC SRC research Report 35 (revised in the Green book, Systems programming with Modula-3 as? Chapter 4) ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/SRC-035.pdf Hope it helps --- El lun, 7/9/09, Jay K escribi?: De: Jay K Asunto: [M3devel] (no subject) Para: "Tony" , "m3devel" Fecha: lunes, 7 septiembre, 2009 4:33 #yiv792797967 .hmmessage P { margin:0px;padding:0px;} #yiv792797967 { font-size:10pt;font-family:Verdana;} Tony, can you..um, trick question sort of, briefly explain the differences between pthreads and Modula-3 threads? The "trick" part is that, to an audience (me) who is not all that familiar with the nuances of either? I'll see if I can find my green book and other reference material (online). I understand the basics of threading very well, if that helps. Eh, not much to it really. I'm not super familiar with condition variables, as Win32 didn't historically have them. But I think I understand them. Specific questions: ? Can Modula-3 threads be implemented more directly upon pthreads? ? Why do we need to maintain a waiting list? ? Is "alert" the same as "cancel" in pthread vocabulary? Or almost the same? ? I understand..there might be a difficult problem..does Modula-3 allow catching an alert? I think so. ? Does Posix allow canceling a cancel? I think not. ? Posix allows, what I think of as try/finally, for alert. Modula-3 probably does too. Even though you can't stop the cancel, you can run "cleanup" code that runs before the cancel completes. However mapping Modula-3 to Posix here would be tricky. As I see things..any function with a try/finally would have to be contorted into a form that passes a pointer to itself, along with parameters, to C code that does pthread_cleanup_push/pop around calling the function pointer. At least given the Darwin implementation. Other implementations might simply be able to call push at the start and pop at the end. But on Darwin these functions are macros where push introduces a local variable that pop references. I guess maybe one could to the "reverse engineering" approach (just by reading the header). But it'd still be ugly. I have to do more research here. I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is thinner than the current ThreadPThread.m3 and see how it fairs, specifically if the Juno hangs go away. "writing" being an exaggeration because it should be very small. Thanks, ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 18:03:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 16:03:21 +0000 Subject: [M3devel] Modula-3 threads vs. pthreads? In-Reply-To: References: Message-ID: To answer part of my question the same as you did, this (buggy -- race conditions) program demonstrates that Alert is catchable, whereas apparently pthread_cancel is not. MODULE Main; IMPORT IO, Thread; PROCEDURE ThreadMain (<* UNUSED *> closure: Thread.Closure): REFANY = VAR i := 0; BEGIN TRY LOOP TRY Thread.AlertPause(0.01D0); IO.PutInt(i); IO.Put("\n"); EXCEPT Thread.Alerted => IO.Put("Thread.Alerted 1\n"); INC(i, 1); IF i = 10 THEN (*RAISE Thread.Alerted;*) RETURN NIL; END; ELSE IO.Put("Thread.Alerted 3?\n"); END END; FINALLY IO.Put("Thread.Alerted 2\n"); END; RETURN NIL; END ThreadMain; VAR a := Thread.Fork(NEW(Thread.Closure, apply := ThreadMain)); BEGIN FOR i := 1 TO 10 DO Thread.Pause(1.0D0); Thread.Alert(a); END; EVAL Thread.Join(a); END Main. Thanks, - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: Date: Mon, 7 Sep 2009 11:17:50 -0400 Jay, Before you go off half cocked and brew up some new threads system might I suggest that it would be better to find and fix the current problem. I am sceptical that there is a much thinner M3 thread implementation on top of pthreads than we currently have. I am in the process of tracking down the problem on I386_DARWIN (I see at least one thing broken right now, and will have a fix soon). In answer to your question, the wait list is to deal with M3 alerts, which are not the same as pthread cancellation. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Sep 2009, at 05:33, Jay K wrote:Tony, can you..um, trick question sort of, briefly explain the differences between pthreads and Modula-3 threads? The "trick" part is that, to an audience (me) who is not all that familiar with the nuances of either? I'll see if I can find my green book and other reference material (online). I understand the basics of threading very well, if that helps. Eh, not much to it really. I'm not super familiar with condition variables, as Win32 didn't historically have them. But I think I understand them. Specific questions: Can Modula-3 threads be implemented more directly upon pthreads? Why do we need to maintain a waiting list? Is "alert" the same as "cancel" in pthread vocabulary? Or almost the same? I understand..there might be a difficult problem..does Modula-3 allow catching an alert? I think so. Does Posix allow canceling a cancel? I think not. Posix allows, what I think of as try/finally, for alert. Modula-3 probably does too. Even though you can't stop the cancel, you can run "cleanup" code that runs before the cancel completes. However mapping Modula-3 to Posix here would be tricky. As I see things..any function with a try/finally would have to be contorted into a form that passes a pointer to itself, along with parameters, to C code that does pthread_cleanup_push/pop around calling the function pointer. At least given the Darwin implementation. Other implementations might simply be able to call push at the start and pop at the end. But on Darwin these functions are macros where push introduces a local variable that pop references. I guess maybe one could to the "reverse engineering" approach (just by reading the header). But it'd still be ugly. I have to do more research here. I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is thinner than the current ThreadPThread.m3 and see how it fairs, specifically if the Juno hangs go away. "writing" being an exaggeration because it should be very small. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Mon Sep 7 14:22:03 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Mon, 07 Sep 2009 14:22:03 +0200 Subject: [M3devel] Server Maint. birch.elego.de tonight 22:00 CEST Message-ID: <20090907142203.thu0879lw4oosc8w@mail.elego.de> Hallo, Heute Abend um 22:00 Uhr CEST wird der Server birch.elego.de kurz herunterfahren um eine fehlerhafte Festplatte zu ersetzen. Betroffen werden www/ftp.elegosoft.com, die modula3 Websites, sowie die modula3 cvs Repositories and continuous-integration Dienste. Wir bitten um Verst?ndnis. - die elego Admins The server birch.elego.de will be taken offline for a short time this evening at 22:00 CEST in order to replace a failing disk drive. The internet sites www/ftp.elegosoft.de, www/ftp.elego.de, the modula3 sites, as well as the modula3 cvs repositories and continuous integration servers will be affected. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 8 03:22:29 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 7 Sep 2009 18:22:29 -0700 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: When did it work? I have looked quite a bit and have not found anything that works. - Jay (phone) On Sep 7, 2009, at 8:06 AM, Tony Hosking wrote: > It used to work... > > :-) > > On 6 Sep 2009, at 21:49, Jay K wrote: > >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of >> stack. >> Current LINUXLIBC6 Juno doesn't seem to ever hang. >> So I conclude, with obvious non scientific firmness, that the >> Darwin-specific threading has never really worked and that the >> problem lies with it, not within the common code (or perhaps in the >> common code but only in how it mixes with the Darwin code). >> >> - Jay >> >> >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Sun, 6 Sep 2009 16:11:28 +0000 >> >> Tony, I386_DARWIN Juno is very prone to hang during startup going >> back at least until 2007/12/01. >> But they certainly don't always hang. >> I haven't found a version yet that doesn't hang. I'll look some >> more. I guess soon I should try other platforms? >> Sometimes there is a pause and it continues. Perhaps the hangs >> I'm just being too impatient on?? >> But, then, it's a bit inconsistent. >> Has it ever worked? >> Race condition in Juno maybe? >> It isn't always easy to build these old dates. >> Caveats: >> I'm using just current cm3cg. I started seeing as complain about >> older cm3cg output. >> Current config files. >> Build standalone (as current config files do with older compilers >> automatically, for "old" == missing the symlink functions). >> Patched XSharedMem/IsSameHost to always be FALSE, though TRUE >> would be correct, FALSE seems safe, I have to read that code.. >> >> Here is 2007/12/01 hung. >> It got as far as displaying "Curve" in the startup text that goes by. >> >> (gdb) thread apply all bt >> >> Thread 9 (process 32852 thread 0x294f): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1e8c in Thread__AlertWait () >> #5 0x00290988 in Formatter__Allocate () >> #6 0x00291137 in Formatter__Probe () >> #7 0x0029178e in Formatter__Peek () >> #8 0x00291677 in Formatter__PeekOp () >> #9 0x00291d18 in Formatter__PrintUntil () >> #10 0x002918d2 in Formatter__PrintTop () >> #11 0x002e3651 in ThreadPThread__RunThread () >> #12 0x002e33a3 in ThreadPThread__ThreadBase () >> #13 0x96f74155 in _pthread_start () >> #14 0x96f74012 in thread_start () >> >> Thread 8 (process 32852 thread 0x2603): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001aad83 in XMessenger__Messenger () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 7 (process 32852 thread 0x2503): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001b68da in XInput__FilterXInput () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 6 (process 32852 thread 0x240f): >> #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () >> #1 0x96fc8261 in select () >> #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () >> #3 0x002e4b05 in ThreadPThread__XIOWait () >> #4 0x002e4614 in SchedulerPosix__IOWait () >> #5 0x001b65f5 in XInput__WaitForXInput () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 5 (process 32852 thread 0x2303): >> #0 0x96f433a6 in mach_wait_until () >> #1 0x96fba3ad in nanosleep () >> #2 0x002e423c in ThreadPThread__XPause () >> #3 0x002e4393 in Thread__Pause () >> #4 0x0011113a in FileBrowserVBT__Watcher () >> #5 0x002e3651 in ThreadPThread__RunThread () >> #6 0x002e33a3 in ThreadPThread__ThreadBase () >> #7 0x96f74155 in _pthread_start () >> #8 0x96f74012 in thread_start () >> >> Thread 4 (process 32852 thread 0x2203): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001883f9 in VTView__VFontCleanUpThread () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 3 (process 32852 thread 0x2103): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001eb9c2 in VBTRep__MeterMaid () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> >> Thread 2 (process 32852 thread 0x313): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x002e65ec in RTOS__WaitHeap () >> #6 0x002d2d54 in RTCollector__WeakCleaner () >> #7 0x002e3651 in ThreadPThread__RunThread () >> #8 0x002e33a3 in ThreadPThread__ThreadBase () >> #9 0x96f74155 in _pthread_start () >> #10 0x96f74012 in thread_start () >> >> Thread 1 (process 32852 local thread 0x2d03): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x002e3ddb in Thread__Join () >> #6 0x0028f53d in Formatter__Close () >> #7 0x00079485 in JunoUnparse__Expr () >> #8 0x00021721 in Editor__Pass4 () >> #9 0x00022048 in EditorUI__CompileUI () >> #10 0x0003e7f8 in Juno__CompileEditor () >> #11 0x0003e98d in Juno__CompileModule () >> #12 0x0003f3be in Juno__CompileModules () >> #13 0x0004d43d in Juno_M3 () >> #14 0x002d71fa in RTLinker__RunMainBody () >> #15 0x002d67b0 in RTLinker__AddUnitI () >> #16 0x002d682e in RTLinker__AddUnit () >> #17 0x00003c88 in main () >> >> >> - Jay >> >> >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 6 Sep 2009 12:30:27 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Juno on NT (presumably canary for other >> problems) >> >> Tony both of these timestamps are somewhat prone to hanging during >> Juno I386_DARWIN startup. But they don't crash, er..well they do >> both fail assertions in text, but I just put current source in to >> address that. I'm going to search backward for a time that doesn't >> hang. >> >> - Jay >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Fri, 4 Sep 2009 12:44:21 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Juno on NT (presumably canary for other >> problems) >> >> Jay, >> >> I can rapidly diagnose any problems in the code you have been >> messing with. Let me get a version on the head that "works" (at >> least for non-Windows) and then we can move on to see what other >> problems there may be in the WIndows part of the workd. >> >> -- Tony >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 4 Sep 2009, at 10:40, Jay K wrote: >> >> no..still unsolved..not sure if I misobserved or what..will have to >> backtrack.. >> >> >> - Jay >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 14:07:46 +0000 >> >> (Well, duh, it wasn't ProcessPools(SuspendPool), that just has >> assertions) >> >> - Jay >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 14:06:08 +0000 >> >> Restoring the: >> ThreadF.ProcessPools(ClosePool); >> >> 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. >> >> - Jay >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 11:52:28 +0000 >> >> I have narrowed it way down to between "2009-02-16 02:00Z" and -D >> "2009-02-16 02:30Z". >> So please review this change. >> I have reviewed it and tried to partly undo it, without luck yet. >> There is a semantic change in BroadcastHeap where the broadcast >> used to happen upon the next unlock >> and now I think happens right away. I tried restoring that, but >> again, no luck for me. >> >> Thanks, >> - Jay >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 09:12:23 +0000 >> >> I have narrowed it down further to between 2/15/2009 and 2/18/2009. >> Next I will try old text code in head to see if it is that. >> >> Tony, can you double check this stuff: >> >> 2009-02-16 02:20 hosking >> >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ >> dtoa.c, >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ >> ThreadPThreadC.i3, >> thread/WIN32/ThreadWin32.m3: >> >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better >> match underlying pthread semantics. >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap >> is held. >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or >> not. >> >> >> 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..). >> >> >> - Jay >> >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Fri, 4 Sep 2009 08:54:54 +0000 >> Subject: [M3devel] Juno on NT (presumably canary for other problems) >> >> short story: >> >> >> I narrowed it down to between 2/15/2009 and 2/20/2009. >> I will keep digging. >> >> There are actually a lot of changes in that brief period. >> I will narrow it further. >> >> >> long story: >> >> Juno on NT, as canary for other problems. >> Juno on NT has three behaviors. >> >> >> Behavior #1 >> >> >> The most common historical behavior, an assertion failure: >> C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "..\src\winvbt\WinContext.m3", line 165 >> *** >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt >> \WinContext.m3 >> 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 >> 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 >> 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt >> \WinTrestle.m3 >> 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt >> \WinTrestle.m3 >> 0x1b3fe30 0x7e418734 >> 0x1b3fe98 0x7e418816 >> 0x1b3fef8 0x7e4189cd >> 0x1b3ff08 0x7e4196c7 >> 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt >> \WinTrestle.m3 >> ......... ......... ... more frames ... >> (1860.1d80): Break instruction exception - code 80000003 (first >> chance) >> eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 >> edi=005d526b >> eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl >> nz na po nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00000202 >> ntdll!DbgBreakPoint: >> 7c90120e cc int 3 >> 0:003> .lines >> Line number information will be loaded >> 0:003> k999 >> ChildEBP RetAddr >> 01b3f5bc 005d52b7 ntdll!DbgBreakPoint >> 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime >> \WIN32\RTOS.m3 @ 29] >> 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime >> \common\RTProcess. >> m3 @ 66] >> 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime >> \common\RTError.m >> 3 @ 118] >> 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common >> \RTError.m3 @ >> 40] >> 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime >> \common\RTExcep >> tion.m3 @ 79] >> 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src >> \runtime\commo >> n\RTException.m3 @ 39] >> 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src >> \runtime\common >> \RTException.m3 @ 25] >> 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime >> \ex_frame\RTExFr >> ame.m3 @ 29] >> 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src >> \runtime\commo >> n\RTException.m3 @ 47] >> 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src >> \runtime\common >> \RTException.m3 @ 25] >> 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime >> \ex_frame\RTExFr >> ame.m3 @ 29] >> 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime >> \common\RTHook >> s.m3 @ 110] >> 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt >> \WinContext.m3 @ 1 >> 7] >> 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt >> \WinContext.m3 >> @ 167] >> 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt >> \WinPaint.m3 @ 71 >> 2] >> 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt >> \WinPaint.m3 @ 5 >> 1] >> 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src >> \winvbt\WinTrestle >> .m3 @ 1574] >> 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt >> \WinTrestle.m3 >> @ 1163] >> 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 >> 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 >> 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 >> 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf >> 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src >> \winvbt\WinTrestl >> e.m3 @ 2450] >> 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread >> \WIN32\Threa >> dWin32.m3 @ 579] >> 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread >> \WIN32\Threa >> dWin32.m3 @ 548] >> 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 >> 0:003> >> >> >> This we shall blame on Trestle not fully being ported to Win32, I >> guess. >> At the very least, it seems to the behavior going back a while. >> You can occasionally see this in head, but usually you see #3. >> >> >> Behavior #2 >> >> Sometimes, rarely, Juno hangs in startup on NT. >> I believe I have seen this both with fairly old and current versions. >> This occurs very rarely. I might look into it more after #3 is >> solved. >> >> >> Behavior #3 >> >> >> An access violation (SIGSEGV to Unix folks) during startup. >> This is the most common behavior with current source, going back a >> few months. >> It is almost always accessing address 00200000 and the instruction >> pointer is very >> often in Thread__Join, but neither are always true. >> Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. >> >> >> C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe >> (1ac4.1e9c): Access violation - code c0000005 (first chance) >> First chance exceptions are reported before any exception handling. >> This exception may be expected and handled. >> eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 >> edi=02812974 >> eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl >> nz na pe nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00010206 >> m3core!Thread__Join+0x13f: >> 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds: >> 0023:001ffffc=???????? >> 0:000> r ebx >> ebx=00200000 >> 0:000> .lines >> Line number information will be loaded >> 0:000> k >> ChildEBP RetAddr >> 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread >> \WIN32\ThreadWin32.m3 >> @ 710] >> 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src >> \JunoCompile. >> m3 @ 256] >> 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] >> 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ >> 813] >> 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] >> 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ >> 140] >> 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ >> 174] >> 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ >> 263] >> 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] >> 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime >> \common\RTLi >> nker.m3 @ 399] >> 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime >> \common\RTLinker >> .m3 @ 113] >> 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime >> \common\RTLinker. >> m3 @ 122] >> 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] >> 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools >> \crt_bld\self_x86\c >> rt\src\crtexe.c @ 582] >> 0012fff0 00000000 kernel32!BaseProcessStart+0x23 >> 0:000> >> >> #4 sometimes other, for example: >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 411 >> *** >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common >> \RTCollector.m3 >> 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common >> \RTHeapMap.m3 >> 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common >> \RTHeapMap.m3 >> 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common >> \RTHeapMap.m3 >> 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common >> \RTCollector.m >> 3 >> 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common >> \RTCollector.m3 >> 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src >> \runtime\common\RT >> Collector.m3 >> 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common >> \RTCollector.m3 >> 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common >> \RTCollector. >> m3 >> 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common >> \RTCollector.m3 >> ......... ......... ... more frames ... >> (14b0.121c): Break instruction exception - code 80000003 (first >> chance) >> >> for example: >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "..\src\vbt\VBTRep.m3", line 644 >> *** >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 >> 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 >> 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 >> 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread >> \WIN32\ThreadWin32.m3 >> 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread >> \WIN32\ThreadWin32.m3 >> ......... ......... ... more frames ... >> (1c3c.e3c): Break instruction exception - code 80000003 (first >> chance) >> >> I figure these are just a variation of #3. >> >> Now, I finally learned how to give CVS a date to checkout or update. >> And NT builds very fast due to the integrated backend. >> So I have been building various dates. >> >> The change between #3 and #1 happened around mid February 2009. >> Specifically, ignoring the rare #2, 2009/02/15 always fails an >> assert, >> #4 above is from 2009/02/20. >> And 2009/02/20 also access violates on 00200000 often. >> >> >> - Jay >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 07:58:53 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 01:58:53 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Here's the hang I see for juno running on I386_DARWIN. If the stack is overflowing this could cause a hang. Otherwise, I see nothing innately suspicious in these thread backtraces. Any ideas? Thread 8 (process 94794 thread 0x2a9f): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x17a6844, M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e7a6 in Thread__AlertWait (M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x0075cdf2 in Formatter__Allocate (M3_ACp9GL_t=0x16e99fc, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x0075cf0a in Formatter__Probe (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x0075d2b8 in Formatter__Peek (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x0075d2ff in Formatter__PeekOp (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x0075db25 in Formatter__PrintUntil (M3_ACp9GL_t=0x16e99fc, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x2162430) at ../src/ formatter/Formatter.m3:708 #10 0x0075dfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x17a6834) at ../ src/formatter/Formatter.m3:615 #11 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1527e00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1527e00) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 7 (process 94794 thread 0x2503): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x1705d88, M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044a0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044a0) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x004c1962 in XMessenger__Messenger (M3_EVlqQO_self=0x1705d78) at ../src/xvbt/XMessenger.m3:69 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1511f60) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1511f60) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 6 (process 94794 thread 0x2407): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x1705d38, M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044c0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044c0) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x004c7bc2 in XInput__FilterXInput (M3_DSd60P_self=0x1705d28) at ../src/xvbt/XInput.m3:102 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1511de0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1511de0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 5 (process 94794 thread 0x230f): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x00944503 in Unix__select (nfds=4, readfds=0x17a90c4, writefds=0x17a90d4, exceptfds=0x17a90e4, timeout=0x0) at ../src/unix/ Common/UnixC.c:301 #2 0x00941970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ PTHREAD/ThreadPThread.m3:788 #3 0x009416cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1705ce8, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ PTHREAD/ThreadPThread.m3:827 #4 0x009411b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ thread/PTHREAD/ThreadPThread.m3:730 #5 0x004c920b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1705cd8) at ../src/xvbt/XInput.m3:63 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1511d10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1511d10) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 4 (process 94794 thread 0x2203): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x00943cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x00940d7c in ThreadPThread__XPause (M3_BXP32l_self=0x1640ed8, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:669 #4 0x00940ef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:686 #5 0x0031bd53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1640ed0) at ../src/lego/FileBrowserVBT.m3:259 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1510200) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1510200) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 3 (process 94794 thread 0x2103): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x160c410, M3_AYIbX3_m=0x160c3ec, M3_Bl0jv4_c=0x160c3f8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x160c3ec, M3_Bl0jv4_c=0x160c3f8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0038d9e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x160c408) at ../src/vtext/VTView.m3:111 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x15103a0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x15103a0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 2 (process 94794 thread 0x1003): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x16079d8, M3_AYIbX3_m=0x1607998, M3_Bl0jv4_c=0x16079a4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x1607998, M3_Bl0jv4_c=0x16079a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x004fd3d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x16079cc) at ../ src/vbt/VBTRep.m3:439 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x150fdd0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x150fdd0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 1 (process 94794 thread 0x10b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x160000c, M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0075c592 in Formatter__WaitUntilEmpty (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_index=) at ../src/formatter/Formatter.m3:491 #6 0x0076092a in Formatter__Flush (M3_ACp9GL_t=0x16e99fc) at ../src/ formatter/Formatter.m3:219 #7 0x0014d2f3 in JunoUnparse__Unparse (M3_ACp9GL_fmt=0x16e99fc, M3_Dpy7Ic_ast=0x16e9520, M3_AcxOUs_tokens=2147483647, M3_AcxOUs_indent=0, M3_AcxOUs_prec=3, M3_AicXUJ_debug=0 '\0', M3_AicXUJ_private=1 '\001', M3_Dpy7Ic_errast=0x0) at ../src/ JunoUnparse.m3:1016 #8 0x0014d5f9 in JunoUnparse__Expr (M3_BxxOH1_wr=0x16e9548, M3_ATZ4pH_ast=0x16e9520, M3_Cwb5VA_tokens=, M3_Cwb5VA_indent=, M3_Cwb5VA_width=, M3_Cwb5VA_prec=, M3_AicXUJ_debug=0 '\0') at ../src/ JunoUnparse.m3:52 #9 0x0001da6e in Editor__Pass4 (M3_EchL3i_rt=0x16df008, M3_ALfX9C_ed=0x240ddbc, M3_ClYh8q_scp=0x161b7dc) at ../src/Editor.m3:904 #10 0x0002204d in EditorUI__CompileUI (M3_EchL3i_rt=0x16df008, M3_ALfX9C_te=0x240ddbc, M3_AcxOUs_time=0, M3_ClYh8q_scp=0x161b7dc) at ../src/Editor.m3:1007 #11 0x00046b70 in Juno__CompileEditor (M3_EchL3i_rt=0x16df008, M3_ALfX9C_ed=0x240ddbc, M3_AcxOUs_time=0, M3_ClYh8q_scp=0x16dedd8, M3_A0YqHX_modName=0xbfffe870, M3_EmmWP2_entity=0xbfffe86c, M3_AicXUJ_uniqueModName=1 '\001') at ../src/Juno.m3:140 #12 0x00046eeb in Juno__CompileModule (M3_BtMpDB_w=0x1764f78, M3_Bd56fi_mod=0x2408b00, M3_EkTcCb_rd=0x240d7d0, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:174 #13 0x00047b59 in Juno__CompileModules (M3_BtMpDB_w=0x1764f78, M3_EkTcCb_rd=0x17a35a4, M3_Al6NTd_modList=0xbfffec94, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #14 0x0004a9d9 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #15 0x0092fb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x5aee0) at ../ src/runtime/common/RTLinker.m3:399 #16 0x00002518 in main (argc=1, argv=0xbfffedec, envp=0xbfffedf4) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 08:09:28 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 02:09:28 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:668 #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:685 #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ src/xvbt/XClientF.m3:105 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103): #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ thread/PTHREAD/ThreadPThread.m3:319 #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../ src/thread/PTHREAD/ThreadPThread.m3:669 #2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ ThreadPThread.m3:699 #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ src/Animate.m3:71 #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313 #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ src/bresenham/ViewError.m3:548 #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ src/Zeus.m3:331 #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #11 0x96373155 in _pthread_start () #12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ src/Zeus.m3:328 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ src/Zeus.m3:328 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03): #0 0x963493dc in _pthread_testcancel () #1 0x96349275 in nanosleep$UNIX2003 () #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:668 #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ PTHREAD/ThreadPThread.m3:685 #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/ vtext/VTCaret.m3:149 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ Common/UnixC.c:301 #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ PTHREAD/ThreadPThread.m3:787 #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ PTHREAD/ThreadPThread.m3:826 #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ thread/PTHREAD/ThreadPThread.m3:729 #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 #7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../ src/bresenham/AlgBresenham.m3:55 #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ src/bresenham/AlgBresenham.m3:86 #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../ src/ZeusPanel.m3:1534 #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../ src/formatter/Formatter.m3:615 #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../ src/formatter/Formatter.m3:615 #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/ unix/Common/UnixC.c:301 #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/ thread/PTHREAD/ThreadPThread.m3:787 #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ src/thread/PTHREAD/ThreadPThread.m3:742 #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/ TCP.m3:234 #7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #10 0x96373155 in _pthread_start () #11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:668 #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:685 #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ src/vbt/VBTRep.m3:439 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ src/trestle/Trestle.m3:884 #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ src/runtime/common/RTLinker.m3:399 #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:09:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:09:31 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <20090908074840.EB4811A2079@async.async.caltech.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <20090908074840.EB4811A2079@async.async.caltech.edu> Message-ID: Nice thing about pthreads is everyone uses them. Whatever tools they have, we can use. ..Jay > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) > Date: Tue, 8 Sep 2009 00:48:40 -0700 > From: mika at async.async.caltech.edu > > > A nice thing about the user threads system is that it has a beautiful > deadlock detector... do you have anything like this in the pthreads > environment? > > Mika > > Tony Hosking writes: > > > >--Apple-Mail-13--794937978 > >Content-Type: text/plain; > > charset=US-ASCII; > > format=flowed; > > delsp=yes > >Content-Transfer-Encoding: 7bit > > > >Here's the hang backtrace for mentor. Again, all appears normal, > >except that all the threads are paused or waiting, which is > >suspicious. I'm stumped for now. > > > >Thread 21 (process 96727 thread 0x7403): > >#0 0x9634946e in __semwait_signal () > >#1 0x963492ef in nanosleep$UNIX2003 () > >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > >rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > >M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > >ThreadPThread.m3:668 > >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:685 > >#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > >src/xvbt/XClientF.m3:105 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 20 (process 96727 thread 0x7103): > >#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > >thread/PTHREAD/ThreadPThread.m3:319 > >#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > >M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../ > >src/thread/PTHREAD/ThreadPThread.m3:669 > >#2 0x01020024 in Thread__AlertPause > >(M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:699 > >#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > >M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > >src/Animate.m3:71 > >#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > >M3_BUucNs_duration=1) at ../src/MGV.m3:313 > >#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > >M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > >#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > >M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > >src/bresenham/ViewError.m3:548 > >#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > >M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > >#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > >src/Zeus.m3:331 > >#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#10 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#11 0x96373155 in _pthread_start () > >#12 0x96373012 in thread_start () > > > >Thread 19 (process 96727 thread 0x5d07): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > >M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > >M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > >M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > >src/Zeus.m3:328 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 18 (process 96727 thread 0x700b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > >M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > >M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > >M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > >src/Zeus.m3:328 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 17 (process 96727 thread 0x6e03): > >#0 0x963493dc in _pthread_testcancel () > >#1 0x96349275 in nanosleep$UNIX2003 () > >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > >rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > >M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > >ThreadPThread.m3:668 > >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:685 > >#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/ > >vtext/VTCaret.m3:149 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 16 (process 96727 thread 0x435b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > >M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > >M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > >at ../src/ZeusPanel.m3:1425 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 15 (process 96727 thread 0x420b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > >at ../src/View.m3:74 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 14 (process 96727 thread 0x4103): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > >at ../src/View.m3:74 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 13 (process 96727 thread 0x4003): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > >at ../src/View.m3:74 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 12 (process 96727 thread 0x2e03): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > >M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > >M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > >at ../src/xvbt/XMessenger.m3:69 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 11 (process 96727 thread 0x2b07): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > >M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > >M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > >at ../src/xvbt/XInput.m3:102 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 10 (process 96727 thread 0x2a23): > >#0 0x963916fa in select$DARWIN_EXTSN () > >#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > >writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > >Common/UnixC.c:301 > >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > >(M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:787 > >#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > >M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > >M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > >PTHREAD/ThreadPThread.m3:826 > >#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, > >M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ > >thread/PTHREAD/ThreadPThread.m3:729 > >#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > >at ../src/xvbt/XInput.m3:63 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 9 (process 96727 thread 0x29f3): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > >M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > >M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > >M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > >M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > >#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > >M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > >M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > >M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > >#7 0x000149a7 in BresenhamIE__ShowPixel > >(M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > >M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > >#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > >M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../ > >src/bresenham/AlgBresenham.m3:55 > >#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > >src/bresenham/AlgBresenham.m3:86 > >#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../ > >src/ZeusPanel.m3:1534 > >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#12 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#13 0x96373155 in _pthread_start () > >#14 0x96373012 in thread_start () > > > >Thread 8 (process 96727 thread 0x2803): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > >M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > >M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > >M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > >formatter/Formatter.m3:440 > >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > >M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > >M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > >formatter/Formatter.m3:708 > >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../ > >src/formatter/Formatter.m3:615 > >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#12 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#13 0x96373155 in _pthread_start () > >#14 0x96373012 in thread_start () > > > >Thread 7 (process 96727 thread 0x2703): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > >M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > >M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > >M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > >formatter/Formatter.m3:440 > >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > >M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > >M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > >formatter/Formatter.m3:708 > >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../ > >src/formatter/Formatter.m3:615 > >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#12 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#13 0x96373155 in _pthread_start () > >#14 0x96373012 in thread_start () > > > >Thread 6 (process 96727 thread 0x2603): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > >M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > >M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > >at ../src/WorkerPool.m3:152 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 5 (process 96727 thread 0x2313): > >#0 0x963916fa in select$DARWIN_EXTSN () > >#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > >writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/ > >unix/Common/UnixC.c:301 > >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > >(M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/ > >thread/PTHREAD/ThreadPThread.m3:787 > >#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > >M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > >M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > >#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= >type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > >src/thread/PTHREAD/ThreadPThread.m3:742 > >#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > >M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > >#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/ > >TCP.m3:234 > >#7 0x006dbc6b in LocalObjectSpace__SpaceAccept > >(M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > >#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#9 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#10 0x96373155 in _pthread_start () > >#11 0x96373012 in thread_start () > > > >Thread 4 (process 96727 thread 0x2003): > >#0 0x9634946e in __semwait_signal () > >#1 0x963492ef in nanosleep$UNIX2003 () > >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > >rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > >M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > >ThreadPThread.m3:668 > >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:685 > >#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > >at ../src/lego/FileBrowserVBT.m3:259 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 3 (process 96727 thread 0x1f03): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > >M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > >M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) > >at ../src/vtext/VTView.m3:111 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 2 (process 96727 thread 0xd07): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > >M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > >M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > >src/vbt/VBTRep.m3:439 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 1 (process 96727 thread 0x10b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > >M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > >#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > >#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > >src/runtime/common/RTLinker.m3:399 > >#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > >_m3main.mc:6 > > > > > >Antony Hosking | Associate Professor | Computer Science | Purdue > >University > >305 N. University Street | West Lafayette | IN 47907 | USA > >Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > >On 6 Sep 2009, at 23:18, Jay K wrote: > > > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> [was truncated again!] > >> > >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > >> stack > > > > > >--Apple-Mail-13--794937978 > >Content-Type: text/html; > > charset=US-ASCII > >Content-Transfer-Encoding: quoted-printable > > > > >-webkit-line-break: after-white-space; ">Here's the hang backtrace for = > >mentor.  Again, all appears normal, except that all the threads are = > >paused or waiting, which is suspicious.  I'm stumped for = > >now.

Thread 21 (process 96727 thread = > >0x7403):
#0  0x9634946e in __semwait_signal = > >()
#1  0x963492ef in nanosleep$UNIX2003 ()
#2 = > > 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb15d4db0, = > >rem=3D0xb15d4db8) at = > >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  0x0101fd7c = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1f3f880, M3_CtKayy_n=3D1, = > >M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  0x0101fef3 = > >in Thread__Pause (M3_CtKayy_n=3D1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  0x00bc9cf4 = > >in XClientF__MeterMaid (M3_AS2y1X_cl=3D0x1f3f870) at = > >../src/xvbt/XClientF.m3:105
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c441d0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c441d0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 20 (process 96727 thread = > >0x7103):
#0  ThreadPThread__XTestAlert = > >(M3_BXP32l_self=3D0x1e5c134) at = > >../src/thread/PTHREAD/ThreadPThread.m3:319
#1  0x0101fd9b = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e5c134, = > >M3_CtKayy_n=3D0.0056863520294427872, M3_AicXUJ_alertable=3D1 '\001') at = > >../src/thread/PTHREAD/ThreadPThread.m3:669
#2  0x01020024 = > >in Thread__AlertPause (M3_CtKayy_n=3D0.0056863520294427872) at = > >../src/thread/PTHREAD/ThreadPThread.m3:699
#3  0x008f9ea1 = > >in Animate__Do (M3_CCfZY3_t=3D0x1e7e3fc, M3_DsL7Zz_mg=3D0x0, = > >M3_AdEaVQ_v=3D0x1e5e0f8, M3_BUucNs_duration=3D1) at = > >../src/Animate.m3:71
#4  0x00909610 in MGV__Animation = > >(M3_AdEaVQ_v=3D0x1e5e0f8, M3_BUucNs_duration=3D1) at = > >../src/MGV.m3:313
#5  0x008921f9 in = > >GraphVBT__AnimateGraph (M3_Cj00zi_graph=3D0x1e5e00c, M3_BUucNs_t0=3D0, = > >M3_BUucNs_t1=3D1) at ../src/GraphVBT.m3:656
#6 = > > 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=3D0x1ed3060, = > >M3_AcxOUs_x=3D3, M3_AcxOUs_y=3D2, M3_AcxOUs_p1=3D6, M3_AcxOUs_p2=3D-2) = > >at ../src/bresenham/ViewError.m3:548
#7  0x0001529a in = > >BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D0x1ed3060, = > >M3_Af40ku_evt=3D0x1e08014) at = > >../I386_DARWIN/BresenhamIE.m3:101
#8  0x007abb9b in = > >Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c128) at = > >../src/Zeus.m3:331
#9  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fd80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#10 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3fd80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#11 0x96373155 in = > >_pthread_start ()
#12 0x96373012 in thread_start = > >()

Thread 19 (process 96727 thread = > >0x5d07):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c0bc, = > >M3_AYIbX3_m=3D0x1e3f9bc, M3_Bl0jv4_c=3D0x1edf34c, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc, = > >M3_Bl0jv4_c=3D0x1edf34c) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x007ab7f2 = > >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc, = > >M3_B74vJ1_view=3D0x1edf25c) at ../src/Zeus.m3:361
#6 = > > 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c0b0) at = > >../src/Zeus.m3:328
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fc80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3fc80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 18 (process 96727 thread = > >0x700b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c044, = > >M3_AYIbX3_m=3D0x1e3f9bc, M3_Bl0jv4_c=3D0x1ee3bac, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc, = > >M3_Bl0jv4_c=3D0x1ee3bac) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x007ab7f2 = > >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc, = > >M3_B74vJ1_view=3D0x1ee3b00) at ../src/Zeus.m3:361
#6 = > > 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c038) at = > >../src/Zeus.m3:328
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fa90) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3fa90) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 17 (process 96727 thread = > >0x6e03):
#0  0x963493dc in _pthread_testcancel = > >()
#1  0x96349275 in nanosleep$UNIX2003 ()
#2 = > > 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb134add0, = > >rem=3D0xb134add8) at = > >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  0x0101fd7c = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e54388, M3_CtKayy_n=3D0.5, = > >M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  0x0101fef3 = > >in Thread__Pause (M3_CtKayy_n=3D0.5) at = > >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  0x00a6f0c0 = > >in VTCaret__Blinker (M3_Axogco_arg=3D0x1e5437c) at = > >../src/vtext/VTCaret.m3:149
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3f9c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3f9c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 16 (process 96727 thread = > >0x435b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1df30c8, = > >M3_AYIbX3_m=3D0x1e3bb94, M3_Bl0jv4_c=3D0x1e3bbb0, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3bb94, = > >M3_Bl0jv4_c=3D0x1e3bbb0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x007baaa1 = > >in ZeusPanel__PanelThread (M3_CvdnuP_pc=3D0x1df30b8) at = > >../src/ZeusPanel.m3:1425
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c39830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c39830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 15 (process 96727 thread = > >0x420b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d67e68, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1d22688, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1d22688) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ee3b00) at = > >../src/trestle/Trestle.m3:884
#6  0x007a98b1 in = > >View__WaiterThread (M3_C7vPGX_waiter=3D0x1d67e5c) at = > >../src/View.m3:74
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c305c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c305c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 14 (process 96727 thread = > >0x4103):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ee32e4, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1edf3c4, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1edf3c4) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1edf25c) at = > >../src/trestle/Trestle.m3:884
#6  0x007a98b1 in = > >View__WaiterThread (M3_C7vPGX_waiter=3D0x1ee32d8) at = > >../src/View.m3:74
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38bf0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38bf0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 13 (process 96727 thread = > >0x4003):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1edb2e4, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1ed532c, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1ed532c) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ed3060) at = > >../src/trestle/Trestle.m3:884
#6  0x007a98b1 in = > >View__WaiterThread (M3_C7vPGX_waiter=3D0x1edb2d8) at = > >../src/View.m3:74
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38780) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38780) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 12 (process 96727 thread = > >0x2e03):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed52a4, = > >M3_AYIbX3_m=3D0x1ed327c, M3_Bl0jv4_c=3D0x1ed35f4, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c, = > >M3_Bl0jv4_c=3D0x1ed35f4) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00bb7962 = > >in XMessenger__Messenger (M3_EVlqQO_self=3D0x1ed5294) at = > >../src/xvbt/XMessenger.m3:69
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38420) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38420) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 11 (process 96727 thread = > >0x2b07):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed5254, = > >M3_AYIbX3_m=3D0x1ed327c, M3_Bl0jv4_c=3D0x1ed3614, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c, = > >M3_Bl0jv4_c=3D0x1ed3614) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00bbdbc2 = > >in XInput__FilterXInput (M3_DSd60P_self=3D0x1ed5244) at = > >../src/xvbt/XInput.m3:102
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38320) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38320) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 10 (process 96727 thread = > >0x2a23):
#0  0x963916fa in select$DARWIN_EXTSN = > >()
#1  0x01023503 in Unix__select (nfds=3D7, = > >readfds=3D0x2813d54, writefds=3D0x2813d64, exceptfds=3D0x2813d74, = > >timeout=3D0x0) at ../src/unix/Common/UnixC.c:301
#2 = > > 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 = > >(M3_Cwb5VA_nfd=3D<unknown type>, M3_A4bqCj_timeout=3D0x0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:787
#3  0x010206cc = > >in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1ed5204, = > >M3_Cwb5VA_fd=3D<unknown type>, M3_AicXUJ_read=3D1 '\001', = > >M3_CtKayy_interval=3D-1, M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:826
#4  0x010201b4 = > >in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3D<unknown type>, = > >M3_AicXUJ_read=3D1 '\001', M3_CtKayy_timeoutInterval=3D-1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:729
#5  0x00bbf20b = > >in XInput__WaitForXInput (M3_Bkyxhg_self=3D0x1ed51f4) at = > >../src/xvbt/XInput.m3:63
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38250) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38250) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 9 (process 96727 thread = > >0x29f3):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e3fafc, = > >M3_AYIbX3_m=3D0x1e3f9bc, M3_Bl0jv4_c=3D0x1e3f9c8, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3f9bc, = > >M3_Bl0jv4_c=3D0x1e3f9c8) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x007ab312 = > >in Zeus__AlgToViews (M3_CQpoHd_zeus=3D0x1e3ccfc, = > >M3_Ao6Rbg_initiator=3D0x1ecd9cc, M3_BMhQCx_dispatchProc=3D0x150e0, = > >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:306
#6 = > > 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D0x1ecd9cc, = > >M3_DsvzJ6_style=3D0 '\0', M3_AcxOUs_priority=3D1, = > >M3_Bd56fi_eventName=3D0x1d9d60, M3_BMhQCx_dispatchProc=3D0x150e0, = > >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:246
#7 = > > 0x000149a7 in BresenhamIE__ShowPixel = > >(M3_CfiRBL_initiator=3D0x1ecd9cc, M3_AcxOUs_x=3D3, M3_AcxOUs_y=3D2, = > >M3_AcxOUs_p1=3D6, M3_AcxOUs_p2=3D-2) at = > >../I386_DARWIN/BresenhamIE.m3:227
#8  0x000175b7 in = > >AlgBresenham__DrawLine (M3_ECecEc_alg=3D0x1ecd9cc, M3_AcxOUs_x1=3D0, = > >M3_AcxOUs_y1=3D0, M3_AcxOUs_x2=3D10, M3_AcxOUs_y2=3D6) at = > >../src/bresenham/AlgBresenham.m3:55
#9  0x0001788f in = > >AlgBresenham__Run (M3_ECecEc_alg=3D0x1ecd9cc) at = > >../src/bresenham/AlgBresenham.m3:86
#10 0x007bb729 in = > >ZeusPanel__AlgThread (M3_Dijbki_ac=3D0x1e3fae8) at = > >../src/ZeusPanel.m3:1534
#11 0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29fd0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c29fd0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >_pthread_start ()
#14 0x96373012 in thread_start = > >()

Thread 8 (process 96727 thread = > >0x2803):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d8e01c, = > >M3_AYIbX3_m=3D0x1d71fdc, M3_Bl0jv4_c=3D0x1d71fe8, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d71fdc, = > >M3_Bl0jv4_c=3D0x1d71fe8) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x00e3bdf2 = > >in Formatter__Allocate (M3_ACp9GL_t=3D0x1d71680, M3_DBiloZ_this=3D1 = > >'\001', M3_Cwb5VA_minSize=3D<unknown type>) at = > >../src/formatter/Formatter.m3:440
#6  0x00e3bf0a in = > >Formatter__Probe (M3_ACp9GL_t=3D0x1d71680, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:542
#7 = > > 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d71680, = > >M3_Cwb5VA_i=3D<unknown type>) at = > >../src/formatter/Formatter.m3:592
#8  0x00e3c2ff in = > >Formatter__PeekOp (M3_ACp9GL_t=3D0x1d71680, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:577
#9 = > > 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d71680, = > >M3_DOUxXw_mode=3D1 '\001', M3_ElBLGV_pos=3D0xb038ce90, = > >M3_Cwb5VA_maxL=3D<unknown type>, M3_CCuODf_op=3D0x1d72c08) at = > >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in = > >Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d8e00c) at = > >../src/formatter/Formatter.m3:615
#11 0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29140) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c29140) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >_pthread_start ()
#14 0x96373012 in thread_start = > >()

Thread 7 (process 96727 thread = > >0x2703):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d71618, = > >M3_AYIbX3_m=3D0x1d715ec, M3_Bl0jv4_c=3D0x1d715f8, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d715ec, = > >M3_Bl0jv4_c=3D0x1d715f8) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x00e3bdf2 = > >in Formatter__Allocate (M3_ACp9GL_t=3D0x1d70c90, M3_DBiloZ_this=3D1 = > >'\001', M3_Cwb5VA_minSize=3D<unknown type>) at = > >../src/formatter/Formatter.m3:440
#6  0x00e3bf0a in = > >Formatter__Probe (M3_ACp9GL_t=3D0x1d70c90, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:542
#7 = > > 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d70c90, = > >M3_Cwb5VA_i=3D<unknown type>) at = > >../src/formatter/Formatter.m3:592
#8  0x00e3c2ff in = > >Formatter__PeekOp (M3_ACp9GL_t=3D0x1d70c90, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:577
#9 = > > 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d70c90, = > >M3_DOUxXw_mode=3D1 '\001', M3_ElBLGV_pos=3D0xb030ae90, = > >M3_Cwb5VA_maxL=3D<unknown type>, M3_CCuODf_op=3D0x1d72c08) at = > >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in = > >Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d71608) at = > >../src/formatter/Formatter.m3:615
#11 0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c221e0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c221e0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >_pthread_start ()
#14 0x96373012 in thread_start = > >()

Thread 6 (process 96727 thread = > >0x2603):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d729bc, = > >M3_AYIbX3_m=3D0x1d728b4, M3_Bl0jv4_c=3D0x1d729a0, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d728b4, = > >M3_Bl0jv4_c=3D0x1d729a0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x0073de32 = > >in WorkerPool__ClericApply (M3_BSwVRC_self=3D0x1d729b0) at = > >../src/WorkerPool.m3:152
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28e10) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c28e10) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 5 (process 96727 thread = > >0x2313):
#0  0x963916fa in select$DARWIN_EXTSN = > >()
#1  0x01023503 in Unix__select (nfds=3D4, = > >readfds=3D0x1d74014, writefds=3D0x1d74024, exceptfds=3D0x1d74034, = > >timeout=3D0xb0206b20) at ../src/unix/Common/UnixC.c:301
#2 = > > 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 = > >(M3_Cwb5VA_nfd=3D<unknown type>, M3_A4bqCj_timeout=3D0xb0206b20) = > >at ../src/thread/PTHREAD/ThreadPThread.m3:787
#3 = > > 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1d585bc, = > >M3_Cwb5VA_fd=3D<unknown type>, M3_AicXUJ_read=3D1 '\001', = > >M3_CtKayy_interval=3D1.7976931348623157e+308, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823
#4 = > > 0x010202e7 in SchedulerPosix__IOAlertWait = > >(M3_Cwb5VA_fd=3D<unknown type>, M3_AicXUJ_read=3D1 '\001', = > >M3_CtKayy_timeoutInterval=3D-1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:742
#5  0x00dd3cc2 = > >in TCPMisc__Accept=46rom (M3_AahksS_c=3D0x1d58594, = > >M3_DoBjMZ_peer=3D0xb0206cb4) at ../src/POSIX/TCP.m3:458
#6 = > > 0x00dd3da8 in TCP__Accept (M3_AahksS_c=3D0x1d58594) at = > >../src/POSIX/TCP.m3:234
#7  0x006dbc6b in = > >LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=3D0x1d585b0) at = > >../src/LocalObjectSpace.m3:307
#8  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28d60) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#9  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c28d60) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#10 0x96373155 in = > >_pthread_start ()
#11 0x96373012 in thread_start = > >()

Thread 4 (process 96727 thread = > >0x2003):
#0  0x9634946e in __semwait_signal = > >()
#1  0x963492ef in nanosleep$UNIX2003 ()
#2 = > > 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb0184dd0, = > >rem=3D0xb0184dd8) at = > >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  0x0101fd7c = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1d0ba08, M3_CtKayy_n=3D1, = > >M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  0x0101fef3 = > >in Thread__Pause (M3_CtKayy_n=3D1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  0x00a11d53 = > >in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D0x1d0ba00) at = > >../src/lego/FileBrowserVBT.m3:259
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c21830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 3 (process 96727 thread = > >0x1f03):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d090d4, = > >M3_AYIbX3_m=3D0x1d090b0, M3_Bl0jv4_c=3D0x1d090bc, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d090b0, = > >M3_Bl0jv4_c=3D0x1d090bc) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00a839e2 = > >in VTView__VFontCleanUpThread (M3_EMTrVz_cl=3D0x1d090cc) at = > >../src/vtext/VTView.m3:111
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21310) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c21310) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 2 (process 96727 thread = > >0xd07):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d006c8, = > >M3_AYIbX3_m=3D0x1d00688, M3_Bl0jv4_c=3D0x1d00694, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00688, = > >M3_Bl0jv4_c=3D0x1d00694) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00bf33d2 = > >in VBTRep__MeterMaid (M3_EMTrVz_self=3D0x1d006bc) at = > >../src/vbt/VBTRep.m3:439
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21390) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c21390) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 1 (process 96727 thread = > >0x10b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d0000c, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1df3114, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1df3114) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1e3a204) at = > >../src/trestle/Trestle.m3:884
#6  0x007c09eb in = > >ZeusPanel__Interact (M3_Bd56fi_title=3D0x290db0, = > >M3_DYb95R_path=3D0x1d498c0) at ../src/ZeusPanel.m3:477
#7 = > > 0x001b0ede in Main_M3 (M3_AcxOUs_mode=3D1) at = > >../src/Main.m3:165
#8  0x0100eb1f in = > >RTLinker__RunMainBody (M3_DjPxE3_m=3D0x1d6060) at = > >../src/runtime/common/RTLinker.m3:399
#9  0x00002578 in = > >main (argc=3D1, argv=3D0xbfffedb8, envp=3D0xbfffedc0) at = > >_m3main.mc:6


>class=3D"Apple-style-span" style=3D"font-size: 12px; ">
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = > >-webkit-line-break: after-white-space; "> >style=3D"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; ">
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = > >-webkit-line-break: after-white-space; "> >style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; ">
>class=3D"Apple-style-span" color=3D"#0000FF"> >class=3D"Apple-style-span" face=3D"Gill Sans"> >class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = > >'Gill Sans'; "> >0, 255); font-family: 'Gill Sans'; ">Antony = > >Hosking >face=3D"Gill Sans"> >'Gill Sans'; "> >'Gill Sans'; "> | >class=3D"Apple-converted-space">  >class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; "> >class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; = > >">Associate Professor >style=3D"font-family: 'Gill Sans'; "> >style=3D"font-family: 'Gill Sans'; "> | Computer Science | Purdue = > >University
> face=3D"GillSans-Light"> >style=3D"font-family: GillSans-Light; ">305 N. University Street | West = > >Lafayette | IN 47907 | USA
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"> >class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = > >'Gill Sans'; "> >0, 255); font-family: 'Gill Sans'; ">Office >class=3D"Apple-style-span" face=3D"GillSans-Light"> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; = > >"> +1 765 494 6001 | >class=3D"Apple-converted-space">  >class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"> >class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = > >'Gill Sans'; "> >0, 255); font-family: 'Gill Sans'; ">Mobile >class=3D"Apple-style-span" face=3D"GillSans-Light"> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "> >class=3D"Apple-converted-space"> +1 765 427 = > >5484
>face=3D"GillSans-Light">
>class=3D"khtml-block-placeholder">
>>

>class=3D"Apple-interchange-newline">

>class=3D"Apple-interchange-newline">

On 6 Sep 2009, = > >at 23:18, Jay K wrote:

>class=3D"Apple-interchange-newline">
>type=3D"cite">









[was truncated = > >again!]

PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes = > >runs out of stack

= > > > >--Apple-Mail-13--794937978-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:16:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:16:41 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:50:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:50:08 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:53:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:53:34 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Wow. I've seen it hang for up to 30 seconds, but if I am patient, I can run it many times in a row with no infinite hang. This is with the stack size code removed. Now to try without it, and if it always proceeds after a possibly long wait, well..that's still pretty bad, but... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:50:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 11:00:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 09:00:07 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Hm..setting the stack 1meg never seems to hang now. I'll dig a bit more and try mentor too. Another thing different about Darwin, I should have pointed out, I think, it doesn't optimize by default like the others, meaning it will use more stack than the others. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:53:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Wow. I've seen it hang for up to 30 seconds, but if I am patient, I can run it many times in a row with no infinite hang. This is with the stack size code removed. Now to try without it, and if it always proceeds after a possibly long wait, well..that's still pretty bad, but... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:50:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 11:15:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 09:15:20 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Hm. I take that back. 1meg I might have been running Linux Juno in a nearby terminal. Without the stack code Juno does still often hang. I have seen it also pause a few seconds with one word in the status, then quite a while later advance to another, and then sit there. Usually after a minute I declare failure. But I have seen it progress after counting to 30. Arg this stinks.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 09:00:07 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm..setting the stack 1meg never seems to hang now. I'll dig a bit more and try mentor too. Another thing different about Darwin, I should have pointed out, I think, it doesn't optimize by default like the others, meaning it will use more stack than the others. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:53:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Wow. I've seen it hang for up to 30 seconds, but if I am patient, I can run it many times in a row with no infinite hang. This is with the stack size code removed. Now to try without it, and if it always proceeds after a possibly long wait, well..that's still pretty bad, but... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:50:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 12:07:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 10:07:16 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: > What is different about Darwin? > Well obviously the same world suspend works. Can we use the portable way instead?? sem_init returns ENOSYS on Darwin, so no. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 13:18:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 11:18:59 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <20090908082345.B34371A2079@async.async.caltech.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <20090908074840.EB4811A2079@async.async.caltech.edu> <20090908082345.B34371A2079@async.async.caltech.edu> Message-ID: Thanks. Well, userthreads on I386_DARWIN don't seem to work presently. == package /Users/jay/dev2/cm3/m3-sys/cm3ide == +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in I386_DARWIN --- ignoring ../src/m3overrides /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-/qk *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x464b7 = PushEFrame + 0x63 in ../src/thread/POSIX/ThreadPosix.m3 *** Maybe I'll look into that.. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) > Date: Tue, 8 Sep 2009 01:23:45 -0700 > From: mika at async.async.caltech.edu > > I really meant it as a debugging hint: > > if you deadlock the user threads you get an instant core dump, also lots > of diagnostics to stderr, which will tell you which LOCK or Thread.Acquire > is creating the dependency cycle. > > If you're debugging deadlocks, that's one way to look for them. > That being said I've never seen mentor or Juno hang on FreeBSD4... > > I haven't used the pthreads much (a bit, when porting to Linux and OS > X as well as when testing the new stuff on FreeBSD). Is it possible to > get deadlock detection with them? As I recall, it's not automatic the > way it is with the user threads. > > Mika > > Jay K writes: > >--_d2a2b05c-dd99-4149-b3de-8867976ffb79_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Nice thing about pthreads is everyone uses them. > >Whatever tools they have=2C we can use. > > > > ..Jay > > > >> To: hosking at cs.purdue.edu=3B jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other proble= > >ms)=20 > >> Date: Tue=2C 8 Sep 2009 00:48:40 -0700 > >> From: mika at async.async.caltech.edu > >>=20 > >>=20 > >> A nice thing about the user threads system is that it has a beautiful > >> deadlock detector... do you have anything like this in the pthreads > >> environment? > >>=20 > >> Mika > >>=20 > >> Tony Hosking writes: > >> > > >> >--Apple-Mail-13--794937978 > >> >Content-Type: text/plain=3B > >> > charset=3DUS-ASCII=3B > >> > format=3Dflowed=3B > >> > delsp=3Dyes > >> >Content-Transfer-Encoding: 7bit > >> > > >> >Here's the hang backtrace for mentor. Again=2C all appears normal=2C =20 > >> >except that all the threads are paused or waiting=2C which is =20 > >> >suspicious. I'm stumped for now. > >> > > >> >Thread 21 (process 96727 thread 0x7403): > >> >#0 0x9634946e in __semwait_signal () > >> >#1 0x963492ef in nanosleep$UNIX2003 () > >> >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb15d4db0=2C =20 > >> >rem=3D0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >> >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=3D0x1f3f880=2C = > >=20 > >> >M3_CtKayy_n=3D1=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHREA= > >D/=20 > >> >ThreadPThread.m3:668 > >> >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ../src/thread/=20 > >> >PTHREAD/ThreadPThread.m3:685 > >> >#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=3D0x1f3f870) at ../= > >=20 > >> >src/xvbt/XClientF.m3:105 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c441d0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c441d0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 20 (process 96727 thread 0x7103): > >> >#0 ThreadPThread__XTestAlert (M3_BXP32l_self=3D0x1e5c134) at ../src/=20 > >> >thread/PTHREAD/ThreadPThread.m3:319 > >> >#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e5c134=2C = > >=20 > >> >M3_CtKayy_n=3D0.0056863520294427872=2C M3_AicXUJ_alertable=3D1 '\001') a= > >t ../=20 > >> >src/thread/PTHREAD/ThreadPThread.m3:669 > >> >#2 0x01020024 in Thread__AlertPause =20 > >> >(M3_CtKayy_n=3D0.0056863520294427872) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:699 > >> >#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=3D0x1e7e3fc=2C =20 > >> >M3_DsL7Zz_mg=3D0x0=2C M3_AdEaVQ_v=3D0x1e5e0f8=2C M3_BUucNs_duration=3D1)= > > at ../=20 > >> >src/Animate.m3:71 > >> >#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=3D0x1e5e0f8=2C =20 > >> >M3_BUucNs_duration=3D1) at ../src/MGV.m3:313 > >> >#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=3D0x1e5e00c=2C= > > =20 > >> >M3_BUucNs_t0=3D0=2C M3_BUucNs_t1=3D1) at ../src/GraphVBT.m3:656 > >> >#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=3D0x1ed3060=2C =20 > >> >M3_AcxOUs_x=3D3=2C M3_AcxOUs_y=3D2=2C M3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2= > >=3D-2) at ../=20 > >> >src/bresenham/ViewError.m3:548 > >> >#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D0x1ed3060=2C = > >=20 > >> >M3_Af40ku_evt=3D0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > >> >#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c128) at ../=20 > >> >src/Zeus.m3:331 > >> >#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fd80) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#10 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3fd80) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#11 0x96373155 in _pthread_start () > >> >#12 0x96373012 in thread_start () > >> > > >> >Thread 19 (process 96727 thread 0x5d07): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c0bc=2C =20 > >> >M3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1edf34c=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc=2C =20 > >> >M3_Bl0jv4_c=3D0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc=2C = > >=20 > >> >M3_B74vJ1_view=3D0x1edf25c) at ../src/Zeus.m3:361 > >> >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c0b0) at ../=20 > >> >src/Zeus.m3:328 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fc80) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3fc80) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 18 (process 96727 thread 0x700b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c044=2C =20 > >> >M3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1ee3bac=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc=2C =20 > >> >M3_Bl0jv4_c=3D0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc=2C = > >=20 > >> >M3_B74vJ1_view=3D0x1ee3b00) at ../src/Zeus.m3:361 > >> >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c038) at ../=20 > >> >src/Zeus.m3:328 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fa90) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3fa90) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 17 (process 96727 thread 0x6e03): > >> >#0 0x963493dc in _pthread_testcancel () > >> >#1 0x96349275 in nanosleep$UNIX2003 () > >> >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb134add0=2C =20 > >> >rem=3D0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >> >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e54388=2C = > >=20 > >> >M3_CtKayy_n=3D0.5=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHR= > >EAD/=20 > >> >ThreadPThread.m3:668 > >> >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D0.5) at ../src/thread/=20 > >> >PTHREAD/ThreadPThread.m3:685 > >> >#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=3D0x1e5437c) at ../src= > >/=20 > >> >vtext/VTCaret.m3:149 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3f9c0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3f9c0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 16 (process 96727 thread 0x435b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1df30c8=2C =20 > >> >M3_AYIbX3_m=3D0x1e3bb94=2C M3_Bl0jv4_c=3D0x1e3bbb0=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3bb94=2C =20 > >> >M3_Bl0jv4_c=3D0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=3D0x1df30b8) =20 > >> >at ../src/ZeusPanel.m3:1425 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c39830) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c39830) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 15 (process 96727 thread 0x420b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d67e68=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1d22688=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ee3b00) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=3D0x1d67e5c) =20 > >> >at ../src/View.m3:74 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c305c0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c305c0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 14 (process 96727 thread 0x4103): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ee32e4=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1edf3c4=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1edf25c) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=3D0x1ee32d8) =20 > >> >at ../src/View.m3:74 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38bf0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38bf0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 13 (process 96727 thread 0x4003): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1edb2e4=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1ed532c=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ed3060) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=3D0x1edb2d8) =20 > >> >at ../src/View.m3:74 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38780) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38780) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 12 (process 96727 thread 0x2e03): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed52a4=2C =20 > >> >M3_AYIbX3_m=3D0x1ed327c=2C M3_Bl0jv4_c=3D0x1ed35f4=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c=2C =20 > >> >M3_Bl0jv4_c=3D0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=3D0x1ed5294) =20 > >> >at ../src/xvbt/XMessenger.m3:69 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38420) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38420) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 11 (process 96727 thread 0x2b07): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed5254=2C =20 > >> >M3_AYIbX3_m=3D0x1ed327c=2C M3_Bl0jv4_c=3D0x1ed3614=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c=2C =20 > >> >M3_Bl0jv4_c=3D0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=3D0x1ed5244) =20 > >> >at ../src/xvbt/XInput.m3:102 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38320) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38320) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 10 (process 96727 thread 0x2a23): > >> >#0 0x963916fa in select$DARWIN_EXTSN () > >> >#1 0x01023503 in Unix__select (nfds=3D7=2C readfds=3D0x2813d54=2C =20 > >> >writefds=3D0x2813d64=2C exceptfds=3D0x2813d74=2C timeout=3D0x0) at ../sr= > >c/unix/=20 > >> >Common/UnixC.c:301 > >> >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =20 > >> >(M3_Cwb5VA_nfd=3D=2C M3_A4bqCj_timeout=3D0x0) at ../src/th= > >read/=20 > >> >PTHREAD/ThreadPThread.m3:787 > >> >#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1ed5204=2C = > >=20 > >> >M3_Cwb5VA_fd=3D=2C M3_AicXUJ_read=3D1 '\001'=2C =20 > >> >M3_CtKayy_interval=3D-1=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/threa= > >d/=20 > >> >PTHREAD/ThreadPThread.m3:826 > >> >#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3D= > >=2C =20 > >> >M3_AicXUJ_read=3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D-1) at ../src/= > >=20 > >> >thread/PTHREAD/ThreadPThread.m3:729 > >> >#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=3D0x1ed51f4) =20 > >> >at ../src/xvbt/XInput.m3:63 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38250) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38250) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 9 (process 96727 thread 0x29f3): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e3fafc=2C =20 > >> >M3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1e3f9c8=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3f9bc=2C =20 > >> >M3_Bl0jv4_c=3D0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=3D0x1e3ccfc=2C =20 > >> >M3_Ao6Rbg_initiator=3D0x1ecd9cc=2C M3_BMhQCx_dispatchProc=3D0x150e0=2C = > >=20 > >> >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:306 > >> >#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D0x1ecd9cc=2C =20 > >> >M3_DsvzJ6_style=3D0 '\0'=2C M3_AcxOUs_priority=3D1=2C =20 > >> >M3_Bd56fi_eventName=3D0x1d9d60=2C M3_BMhQCx_dispatchProc=3D0x150e0=2C =20 > >> >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:246 > >> >#7 0x000149a7 in BresenhamIE__ShowPixel =20 > >> >(M3_CfiRBL_initiator=3D0x1ecd9cc=2C M3_AcxOUs_x=3D3=2C M3_AcxOUs_y=3D2= > >=2C =20 > >> >M3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2=3D-2) at ../I386_DARWIN/BresenhamIE.m3:= > >227 > >> >#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=3D0x1ecd9cc=2C = > >=20 > >> >M3_AcxOUs_x1=3D0=2C M3_AcxOUs_y1=3D0=2C M3_AcxOUs_x2=3D10=2C M3_AcxOUs_y= > >2=3D6) at ../=20 > >> >src/bresenham/AlgBresenham.m3:55 > >> >#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=3D0x1ecd9cc) at ../=20 > >> >src/bresenham/AlgBresenham.m3:86 > >> >#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=3D0x1e3fae8) at ../= > >=20 > >> >src/ZeusPanel.m3:1534 > >> >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29fd0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#12 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c29fd0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#13 0x96373155 in _pthread_start () > >> >#14 0x96373012 in thread_start () > >> > > >> >Thread 8 (process 96727 thread 0x2803): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d8e01c=2C =20 > >> >M3_AYIbX3_m=3D0x1d71fdc=2C M3_Bl0jv4_c=3D0x1d71fe8=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d71fdc=2C =20 > >> >M3_Bl0jv4_c=3D0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_DBiloZ_this=3D1 '\001'=2C M3_Cwb5VA_minSize=3D) at ../s= > >rc/=20 > >> >formatter/Formatter.m3:440 > >> >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:542 > >> >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:592 > >> >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:577 > >> >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_DOUxXw_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb038ce90=2C =20 > >> >M3_Cwb5VA_maxL=3D=2C M3_CCuODf_op=3D0x1d72c08) at ../src/= > >=20 > >> >formatter/Formatter.m3:708 > >> >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d8e00c) at ..= > >/=20 > >> >src/formatter/Formatter.m3:615 > >> >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29140) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#12 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c29140) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#13 0x96373155 in _pthread_start () > >> >#14 0x96373012 in thread_start () > >> > > >> >Thread 7 (process 96727 thread 0x2703): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d71618=2C =20 > >> >M3_AYIbX3_m=3D0x1d715ec=2C M3_Bl0jv4_c=3D0x1d715f8=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d715ec=2C =20 > >> >M3_Bl0jv4_c=3D0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_DBiloZ_this=3D1 '\001'=2C M3_Cwb5VA_minSize=3D) at ../s= > >rc/=20 > >> >formatter/Formatter.m3:440 > >> >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:542 > >> >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:592 > >> >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:577 > >> >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_DOUxXw_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb030ae90=2C =20 > >> >M3_Cwb5VA_maxL=3D=2C M3_CCuODf_op=3D0x1d72c08) at ../src/= > >=20 > >> >formatter/Formatter.m3:708 > >> >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d71608) at ..= > >/=20 > >> >src/formatter/Formatter.m3:615 > >> >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c221e0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#12 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c221e0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#13 0x96373155 in _pthread_start () > >> >#14 0x96373012 in thread_start () > >> > > >> >Thread 6 (process 96727 thread 0x2603): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d729bc=2C =20 > >> >M3_AYIbX3_m=3D0x1d728b4=2C M3_Bl0jv4_c=3D0x1d729a0=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d728b4=2C =20 > >> >M3_Bl0jv4_c=3D0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=3D0x1d729b0) = > >=20 > >> >at ../src/WorkerPool.m3:152 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28e10) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c28e10) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 5 (process 96727 thread 0x2313): > >> >#0 0x963916fa in select$DARWIN_EXTSN () > >> >#1 0x01023503 in Unix__select (nfds=3D4=2C readfds=3D0x1d74014=2C =20 > >> >writefds=3D0x1d74024=2C exceptfds=3D0x1d74034=2C timeout=3D0xb0206b20) a= > >t ../src/=20 > >> >unix/Common/UnixC.c:301 > >> >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =20 > >> >(M3_Cwb5VA_nfd=3D=2C M3_A4bqCj_timeout=3D0xb0206b20) at ..= > >/src/=20 > >> >thread/PTHREAD/ThreadPThread.m3:787 > >> >#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1d585bc=2C = > >=20 > >> >M3_Cwb5VA_fd=3D=2C M3_AicXUJ_read=3D1 '\001'=2C =20 > >> >M3_CtKayy_interval=3D1.7976931348623157e+308=2C M3_AicXUJ_alertable=3D1 = > >=20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > >> >#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3D >=20 > >> >type>=2C M3_AicXUJ_read=3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D-1) at= > > ../=20 > >> >src/thread/PTHREAD/ThreadPThread.m3:742 > >> >#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=3D0x1d58594=2C =20 > >> >M3_DoBjMZ_peer=3D0xb0206cb4) at ../src/POSIX/TCP.m3:458 > >> >#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=3D0x1d58594) at ../src/POSIX/= > >=20 > >> >TCP.m3:234 > >> >#7 0x006dbc6b in LocalObjectSpace__SpaceAccept =20 > >> >(M3_Dbz8GV_self=3D0x1d585b0) at ../src/LocalObjectSpace.m3:307 > >> >#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28d60) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#9 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c28d60) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#10 0x96373155 in _pthread_start () > >> >#11 0x96373012 in thread_start () > >> > > >> >Thread 4 (process 96727 thread 0x2003): > >> >#0 0x9634946e in __semwait_signal () > >> >#1 0x963492ef in nanosleep$UNIX2003 () > >> >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb0184dd0=2C =20 > >> >rem=3D0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >> >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=3D0x1d0ba08=2C = > >=20 > >> >M3_CtKayy_n=3D1=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHREA= > >D/=20 > >> >ThreadPThread.m3:668 > >> >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ../src/thread/=20 > >> >PTHREAD/ThreadPThread.m3:685 > >> >#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D0x1d0ba00) =20 > >> >at ../src/lego/FileBrowserVBT.m3:259 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21830) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c21830) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 3 (process 96727 thread 0x1f03): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d090d4=2C =20 > >> >M3_AYIbX3_m=3D0x1d090b0=2C M3_Bl0jv4_c=3D0x1d090bc=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d090b0=2C =20 > >> >M3_Bl0jv4_c=3D0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=3D0x1d090cc) = > >=20 > >> >at ../src/vtext/VTView.m3:111 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21310) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c21310) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 2 (process 96727 thread 0xd07): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d006c8=2C =20 > >> >M3_AYIbX3_m=3D0x1d00688=2C M3_Bl0jv4_c=3D0x1d00694=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00688=2C =20 > >> >M3_Bl0jv4_c=3D0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=3D0x1d006bc) at ../= > >=20 > >> >src/vbt/VBTRep.m3:439 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21390) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c21390) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 1 (process 96727 thread 0x10b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d0000c=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1df3114=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1e3a204) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=3D0x290db0=2C =20 > >> >M3_DYb95R_path=3D0x1d498c0) at ../src/ZeusPanel.m3:477 > >> >#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=3D1) at ../src/Main.m3:165 > >> >#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=3D0x1d6060) at ../= > >=20 > >> >src/runtime/common/RTLinker.m3:399 > >> >#9 0x00002578 in main (argc=3D1=2C argv=3D0xbfffedb8=2C envp=3D0xbfffed= > >c0) at =20 > >> >_m3main.mc:6 > >> > > >> > > >> >Antony Hosking | Associate Professor | Computer Science | Purdue =20 > >> >University > >> >305 N. University Street | West Lafayette | IN 47907 | USA > >> >Office +1 765 494 6001 | Mobile +1 765 427 5484 > >> > > >> > > >> > > >> > > >> >On 6 Sep 2009=2C at 23:18=2C Jay K wrote: > >> > > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> [was truncated again!] > >> >> > >> >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes runs out of = > >=20 > >> >> stack > >> > > >> > > >> >--Apple-Mail-13--794937978 > >> >Content-Type: text/html=3B > >> > charset=3DUS-ASCII > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > >=3B =3D > >> >-webkit-line-break: after-white-space=3B ">Here's the hang backtrace for= > > =3D > >> >mentor.  =3BAgain=2C all appears normal=2C except that all the threa= > >ds are =3D > >> >paused or waiting=2C which is suspicious.  =3BI'm stumped for =3D > >> >now.

Thread 21 (process 96727 thread =3D > >> >0x7403):
#0  =3B0x9634946e in __semwait_signal =3D > >> >()
#1  =3B0x963492ef in nanosleep$UNIX2003 ()
#2= > > =3D > >> > =3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb15d4db0=2C = > >=3D > >> >rem=3D3D0xb15d4db8) at =3D > >> >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  =3B0x0101fd= > >7c =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1f3f880=2C M3_CtKayy_n=3D= > >3D1=2C =3D > >> >M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  =3B0x0101fe= > >f3 =3D > >> >in Thread__Pause (M3_CtKayy_n=3D3D1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  =3B0x00bc9c= > >f4 =3D > >> >in XClientF__MeterMaid (M3_AS2y1X_cl=3D3D0x1f3f870) at =3D > >> >../src/xvbt/XClientF.m3:105
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c441d0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c441d0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 20 (process 96727 thread =3D > >> >0x7103):
#0  =3BThreadPThread__XTestAlert =3D > >> >(M3_BXP32l_self=3D3D0x1e5c134) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:319
#1  =3B0x0101fd= > >9b =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1e5c134=2C =3D > >> >M3_CtKayy_n=3D3D0.0056863520294427872=2C M3_AicXUJ_alertable=3D3D1 '\001= > >') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:669
#2  =3B0x010200= > >24 =3D > >> >in Thread__AlertPause (M3_CtKayy_n=3D3D0.0056863520294427872) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:699
#3  =3B0x008f9e= > >a1 =3D > >> >in Animate__Do (M3_CCfZY3_t=3D3D0x1e7e3fc=2C M3_DsL7Zz_mg=3D3D0x0=2C =3D > >> >M3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_duration=3D3D1) at =3D > >> >../src/Animate.m3:71
#4  =3B0x00909610 in MGV__Animation = > >=3D > >> >(M3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_duration=3D3D1) at =3D > >> >../src/MGV.m3:313
#5  =3B0x008921f9 in =3D > >> >GraphVBT__AnimateGraph (M3_Cj00zi_graph=3D3D0x1e5e00c=2C M3_BUucNs_t0=3D= > >3D0=2C =3D > >> >M3_BUucNs_t1=3D3D1) at ../src/GraphVBT.m3:656
#6 =3D > >> > =3B0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=3D3D0x1ed3060= > >=2C =3D > >> >M3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y=3D3D2=2C M3_AcxOUs_p1=3D3D6=2C M3_AcxOU= > >s_p2=3D3D-2) =3D > >> >at ../src/bresenham/ViewError.m3:548
#7  =3B0x0001529a in = > >=3D > >> >BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D3D0x1ed3060=2C =3D > >> >M3_Af40ku_evt=3D3D0x1e08014) at =3D > >> >../I386_DARWIN/BresenhamIE.m3:101
#8  =3B0x007abb9b in =3D > >> >Zeus__ViewThread (M3_BH3Tll_self=3D3D0x1e5c128) at =3D > >> >../src/Zeus.m3:331
#9  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fd80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#10 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3fd80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#11 0x96373155 in = > >=3D > >> >_pthread_start ()
#12 0x96373012 in thread_start =3D > >> >()

Thread 19 (process 96727 thread =3D > >> >0x5d07):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e5c0bc=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1edf34c=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1edf34c) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x007ab7= > >f2 =3D > >> >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D > >> >M3_B74vJ1_view=3D3D0x1edf25c) at ../src/Zeus.m3:361
#6 =3D > >> > =3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D3D0x1e5c0b0) at= > > =3D > >> >../src/Zeus.m3:328
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fc80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3fc80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 18 (process 96727 thread =3D > >> >0x700b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e5c044=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1ee3bac=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1ee3bac) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x007ab7= > >f2 =3D > >> >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D > >> >M3_B74vJ1_view=3D3D0x1ee3b00) at ../src/Zeus.m3:361
#6 =3D > >> > =3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D3D0x1e5c038) at= > > =3D > >> >../src/Zeus.m3:328
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fa90) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3fa90) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 17 (process 96727 thread =3D > >> >0x6e03):
#0  =3B0x963493dc in _pthread_testcancel =3D > >> >()
#1  =3B0x96349275 in nanosleep$UNIX2003 ()
#2= > > =3D > >> > =3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb134add0=2C = > >=3D > >> >rem=3D3D0xb134add8) at =3D > >> >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  =3B0x0101fd= > >7c =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1e54388=2C M3_CtKayy_n=3D= > >3D0.5=2C =3D > >> >M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  =3B0x0101fe= > >f3 =3D > >> >in Thread__Pause (M3_CtKayy_n=3D3D0.5) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  =3B0x00a6f0= > >c0 =3D > >> >in VTCaret__Blinker (M3_Axogco_arg=3D3D0x1e5437c) at =3D > >> >../src/vtext/VTCaret.m3:149
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3f9c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3f9c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 16 (process 96727 thread =3D > >> >0x435b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1df30c8=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3bb94=2C M3_Bl0jv4_c=3D3D0x1e3bbb0=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1e3bb94=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1e3bbb0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x007baa= > >a1 =3D > >> >in ZeusPanel__PanelThread (M3_CvdnuP_pc=3D3D0x1df30b8) at =3D > >> >../src/ZeusPanel.m3:1425
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c39830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c39830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 15 (process 96727 thread =3D > >> >0x420b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d67e68=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1d22688=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1d22688) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1ee3b00) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007a98b1 in =3D > >> >View__WaiterThread (M3_C7vPGX_waiter=3D3D0x1d67e5c) at =3D > >> >../src/View.m3:74
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c305c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c305c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 14 (process 96727 thread =3D > >> >0x4103):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ee32e4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1edf3c4=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1edf3c4) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1edf25c) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007a98b1 in =3D > >> >View__WaiterThread (M3_C7vPGX_waiter=3D3D0x1ee32d8) at =3D > >> >../src/View.m3:74
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38bf0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38bf0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 13 (process 96727 thread =3D > >> >0x4003):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1edb2e4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1ed532c=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1ed532c) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1ed3060) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007a98b1 in =3D > >> >View__WaiterThread (M3_C7vPGX_waiter=3D3D0x1edb2d8) at =3D > >> >../src/View.m3:74
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38780) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38780) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 12 (process 96727 thread =3D > >> >0x2e03):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed52a4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed35f4=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed327c=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1ed35f4) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00bb79= > >62 =3D > >> >in XMessenger__Messenger (M3_EVlqQO_self=3D3D0x1ed5294) at =3D > >> >../src/xvbt/XMessenger.m3:69
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38420) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38420) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 11 (process 96727 thread =3D > >> >0x2b07):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed5254=2C =3D > >> >M3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed3614=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed327c=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1ed3614) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00bbdb= > >c2 =3D > >> >in XInput__FilterXInput (M3_DSd60P_self=3D3D0x1ed5244) at =3D > >> >../src/xvbt/XInput.m3:102
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38320) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38320) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 10 (process 96727 thread =3D > >> >0x2a23):
#0  =3B0x963916fa in select$DARWIN_EXTSN =3D > >> >()
#1  =3B0x01023503 in Unix__select (nfds=3D3D7=2C =3D > >> >readfds=3D3D0x2813d54=2C writefds=3D3D0x2813d64=2C exceptfds=3D3D0x2813d= > >74=2C =3D > >> >timeout=3D3D0x0) at ../src/unix/Common/UnixC.c:301
#2 =3D > >> > =3B0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =3D > >> >(M3_Cwb5VA_nfd=3D3D<=3Bunknown type>=3B=2C M3_A4bqCj_timeout=3D3D0x0= > >) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:787
#3  =3B0x010206= > >cc =3D > >> >in ThreadPThread__XIOWait (M3_BXP32l_self=3D3D0x1ed5204=2C =3D > >> >M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C M3_AicXUJ_read=3D3D1 '\001'= > >=2C =3D > >> >M3_CtKayy_interval=3D3D-1=2C M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:826
#4  =3B0x010201= > >b4 =3D > >> >in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C = > >=3D > >> >M3_AicXUJ_read=3D3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D3D-1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:729
#5  =3B0x00bbf2= > >0b =3D > >> >in XInput__WaitForXInput (M3_Bkyxhg_self=3D3D0x1ed51f4) at =3D > >> >../src/xvbt/XInput.m3:63
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38250) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38250) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 9 (process 96727 thread =3D > >> >0x29f3):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e3fafc=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1e3f9c8=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1e3f9c8) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x007ab3= > >12 =3D > >> >in Zeus__AlgToViews (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D > >> >M3_Ao6Rbg_initiator=3D3D0x1ecd9cc=2C M3_BMhQCx_dispatchProc=3D3D0x150e0= > >=2C =3D > >> >M3_Af40ku_evtArgs=3D3D0x1e08014) at ../src/Zeus.m3:306
#6 =3D > >> > =3B0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D3D0x1ecd9cc= > >=2C =3D > >> >M3_DsvzJ6_style=3D3D0 '\0'=2C M3_AcxOUs_priority=3D3D1=2C =3D > >> >M3_Bd56fi_eventName=3D3D0x1d9d60=2C M3_BMhQCx_dispatchProc=3D3D0x150e0= > >=2C =3D > >> >M3_Af40ku_evtArgs=3D3D0x1e08014) at ../src/Zeus.m3:246
#7 =3D > >> > =3B0x000149a7 in BresenhamIE__ShowPixel =3D > >> >(M3_CfiRBL_initiator=3D3D0x1ecd9cc=2C M3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y= > >=3D3D2=2C =3D > >> >M3_AcxOUs_p1=3D3D6=2C M3_AcxOUs_p2=3D3D-2) at =3D > >> >../I386_DARWIN/BresenhamIE.m3:227
#8  =3B0x000175b7 in =3D > >> >AlgBresenham__DrawLine (M3_ECecEc_alg=3D3D0x1ecd9cc=2C M3_AcxOUs_x1=3D3D= > >0=2C =3D > >> >M3_AcxOUs_y1=3D3D0=2C M3_AcxOUs_x2=3D3D10=2C M3_AcxOUs_y2=3D3D6) at =3D > >> >../src/bresenham/AlgBresenham.m3:55
#9  =3B0x0001788f in = > >=3D > >> >AlgBresenham__Run (M3_ECecEc_alg=3D3D0x1ecd9cc) at =3D > >> >../src/bresenham/AlgBresenham.m3:86
#10 0x007bb729 in =3D > >> >ZeusPanel__AlgThread (M3_Dijbki_ac=3D3D0x1e3fae8) at =3D > >> >../src/ZeusPanel.m3:1534
#11 0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c29fd0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c29fd0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >=3D > >> >_pthread_start ()
#14 0x96373012 in thread_start =3D > >> >()

Thread 8 (process 96727 thread =3D > >> >0x2803):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d8e01c=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d71fdc=2C M3_Bl0jv4_c=3D3D0x1d71fe8=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1d71fdc=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1d71fe8) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x00e3bd= > >f2 =3D > >> >in Formatter__Allocate (M3_ACp9GL_t=3D3D0x1d71680=2C M3_DBiloZ_this=3D3D= > >1 =3D > >> >'\001'=2C M3_Cwb5VA_minSize=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:440
#6  =3B0x00e3bf0a in =3D > >> >Formatter__Probe (M3_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D<=3Bunk= > >nown =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:542
#7 =3D > >> > =3B0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d71680=2C =3D > >> >M3_Cwb5VA_i=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:592
#8  =3B0x00e3c2ff in =3D > >> >Formatter__PeekOp (M3_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D<=3Bun= > >known =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:577
#9 =3D > >> > =3B0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D3D0x1d71680= > >=2C =3D > >> >M3_DOUxXw_mode=3D3D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb038ce90=2C =3D > >> >M3_Cwb5VA_maxL=3D3D<=3Bunknown type>=3B=2C M3_CCuODf_op=3D3D0x1d72c0= > >8) at =3D > >> >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in =3D > >> >Formatter__PrintTop (M3_B5Nhtj_self=3D3D0x1d8e00c) at =3D > >> >../src/formatter/Formatter.m3:615
#11 0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c29140) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c29140) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >=3D > >> >_pthread_start ()
#14 0x96373012 in thread_start =3D > >> >()

Thread 7 (process 96727 thread =3D > >> >0x2703):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d71618=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d715ec=2C M3_Bl0jv4_c=3D3D0x1d715f8=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1d715ec=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1d715f8) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x00e3bd= > >f2 =3D > >> >in Formatter__Allocate (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_DBiloZ_this=3D3D= > >1 =3D > >> >'\001'=2C M3_Cwb5VA_minSize=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:440
#6  =3B0x00e3bf0a in =3D > >> >Formatter__Probe (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D<=3Bunk= > >nown =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:542
#7 =3D > >> > =3B0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d70c90=2C =3D > >> >M3_Cwb5VA_i=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:592
#8  =3B0x00e3c2ff in =3D > >> >Formatter__PeekOp (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D<=3Bun= > >known =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:577
#9 =3D > >> > =3B0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D3D0x1d70c90= > >=2C =3D > >> >M3_DOUxXw_mode=3D3D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb030ae90=2C =3D > >> >M3_Cwb5VA_maxL=3D3D<=3Bunknown type>=3B=2C M3_CCuODf_op=3D3D0x1d72c0= > >8) at =3D > >> >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in =3D > >> >Formatter__PrintTop (M3_B5Nhtj_self=3D3D0x1d71608) at =3D > >> >../src/formatter/Formatter.m3:615
#11 0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c221e0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c221e0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >=3D > >> >_pthread_start ()
#14 0x96373012 in thread_start =3D > >> >()

Thread 6 (process 96727 thread =3D > >> >0x2603):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d729bc=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d728b4=2C M3_Bl0jv4_c=3D3D0x1d729a0=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1d728b4=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1d729a0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x0073de= > >32 =3D > >> >in WorkerPool__ClericApply (M3_BSwVRC_self=3D3D0x1d729b0) at =3D > >> >../src/WorkerPool.m3:152
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c28e10) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c28e10) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 5 (process 96727 thread =3D > >> >0x2313):
#0  =3B0x963916fa in select$DARWIN_EXTSN =3D > >> >()
#1  =3B0x01023503 in Unix__select (nfds=3D3D4=2C =3D > >> >readfds=3D3D0x1d74014=2C writefds=3D3D0x1d74024=2C exceptfds=3D3D0x1d740= > >34=2C =3D > >> >timeout=3D3D0xb0206b20) at ../src/unix/Common/UnixC.c:301
#2 = > >=3D > >> > =3B0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =3D > >> >(M3_Cwb5VA_nfd=3D3D<=3Bunknown type>=3B=2C M3_A4bqCj_timeout=3D3D0xb= > >0206b20) =3D > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:787
#3 =3D > >> > =3B0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=3D3D0x1d585= > >bc=2C =3D > >> >M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C M3_AicXUJ_read=3D3D1 '\001'= > >=2C =3D > >> >M3_CtKayy_interval=3D3D1.7976931348623157e+308=2C M3_AicXUJ_alertable=3D= > >3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823
#4 =3D > >> > =3B0x010202e7 in SchedulerPosix__IOAlertWait =3D > >> >(M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C M3_AicXUJ_read=3D3D1 '\001= > >'=2C =3D > >> >M3_CtKayy_timeoutInterval=3D3D-1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:742
#5  =3B0x00dd3c= > >c2 =3D > >> >in TCPMisc__Accept=3D46rom (M3_AahksS_c=3D3D0x1d58594=2C =3D > >> >M3_DoBjMZ_peer=3D3D0xb0206cb4) at ../src/POSIX/TCP.m3:458
#6 = > >=3D > >> > =3B0x00dd3da8 in TCP__Accept (M3_AahksS_c=3D3D0x1d58594) at =3D > >> >../src/POSIX/TCP.m3:234
#7  =3B0x006dbc6b in =3D > >> >LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=3D3D0x1d585b0) at =3D > >> >../src/LocalObjectSpace.m3:307
#8  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c28d60) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#9  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c28d60) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#10 0x96373155 in = > >=3D > >> >_pthread_start ()
#11 0x96373012 in thread_start =3D > >> >()

Thread 4 (process 96727 thread =3D > >> >0x2003):
#0  =3B0x9634946e in __semwait_signal =3D > >> >()
#1  =3B0x963492ef in nanosleep$UNIX2003 ()
#2= > > =3D > >> > =3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb0184dd0=2C = > >=3D > >> >rem=3D3D0xb0184dd8) at =3D > >> >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  =3B0x0101fd= > >7c =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1d0ba08=2C M3_CtKayy_n=3D= > >3D1=2C =3D > >> >M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  =3B0x0101fe= > >f3 =3D > >> >in Thread__Pause (M3_CtKayy_n=3D3D1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  =3B0x00a11d= > >53 =3D > >> >in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D3D0x1d0ba00) at =3D > >> >../src/lego/FileBrowserVBT.m3:259
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 3 (process 96727 thread =3D > >> >0x1f03):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d090d4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d090b0=2C M3_Bl0jv4_c=3D3D0x1d090bc=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d090b0=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1d090bc) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00a839= > >e2 =3D > >> >in VTView__VFontCleanUpThread (M3_EMTrVz_cl=3D3D0x1d090cc) at =3D > >> >../src/vtext/VTView.m3:111
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21310) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21310) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 2 (process 96727 thread =3D > >> >0xd07):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d006c8=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00688=2C M3_Bl0jv4_c=3D3D0x1d00694=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00688=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1d00694) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00bf33= > >d2 =3D > >> >in VBTRep__MeterMaid (M3_EMTrVz_self=3D3D0x1d006bc) at =3D > >> >../src/vbt/VBTRep.m3:439
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21390) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21390) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 1 (process 96727 thread =3D > >> >0x10b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d0000c=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1df3114=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1df3114) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1e3a204) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007c09eb in =3D > >> >ZeusPanel__Interact (M3_Bd56fi_title=3D3D0x290db0=2C =3D > >> >M3_DYb95R_path=3D3D0x1d498c0) at ../src/ZeusPanel.m3:477
#7 = > >=3D > >> > =3B0x001b0ede in Main_M3 (M3_AcxOUs_mode=3D3D1) at =3D > >> >../src/Main.m3:165
#8  =3B0x0100eb1f in =3D > >> >RTLinker__RunMainBody (M3_DjPxE3_m=3D3D0x1d6060) at =3D > >> >../src/runtime/common/RTLinker.m3:399
#9  =3B0x00002578 in= > > =3D > >> >main (argc=3D3D1=2C argv=3D3D0xbfffedb8=2C envp=3D3D0xbfffedc0) at =3D > >> >_m3main.mc:6


>> >class=3D3D"Apple-style-span" style=3D3D"font-size: 12px=3B ">
>> >style=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode: space=3B =3D > >> >-webkit-line-break: after-white-space=3B "> >span" =3D > >> >style=3D3D"border-collapse: separate=3B -webkit-border-horizontal-spacin= > >g: =3D > >> >0px=3B -webkit-border-vertical-spacing: 0px=3B color: rgb(0=2C 0=2C 0)= > >=3B =3D > >> >font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B =3D > >> >font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B= > > =3D > >> >line-height: normal=3B -webkit-text-decorations-in-effect: none=3B =3D > >> >text-indent: 0px=3B -webkit-text-size-adjust: auto=3B text-transform: no= > >ne=3B =3D > >> >orphans: 2=3B white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "= > >>
>> >style=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode: space=3B =3D > >> >-webkit-line-break: after-white-space=3B "> >span" =3D > >> >style=3D3D"border-collapse: separate=3B -webkit-border-horizontal-spacin= > >g: =3D > >> >0px=3B -webkit-border-vertical-spacing: 0px=3B color: rgb(0=2C 0=2C 0)= > >=3B =3D > >> >font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B =3D > >> >font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B= > > =3D > >> >line-height: normal=3B -webkit-text-decorations-in-effect: none=3B =3D > >> >text-indent: 0px=3B -webkit-text-size-adjust: auto=3B text-transform: no= > >ne=3B =3D > >> >orphans: 2=3B white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "= > >> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B ">
>=3D > >> >class=3D3D"Apple-style-span" color=3D3D"#0000FF"> >> >class=3D3D"Apple-style-span" face=3D3D"Gill Sans"> >> >class=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B fon= > >t-family: =3D > >> >'Gill Sans'=3B "> >b(0=2C =3D > > >0=2C 255)=3B font-family: 'Gill Sans'=3B ">Antony =3D > >> >Hosking >=3D > >> >face=3D3D"Gill Sans"> >family: =3D > >> >'Gill Sans'=3B "> >ly: =3D > >> >'Gill Sans'=3B "> =3B= > >| >> >class=3D3D"Apple-converted-space"> =3B >> >class=3D3D"Apple-style-span" style=3D3D"font-family: 'Gill Sans'=3B "> >pan =3D > >> >class=3D3D"Apple-style-span" style=3D3D"font-family: 'Gill Sans'=3B =3D > >> >">Associate Professor >=3D > >> >style=3D3D"font-family: 'Gill Sans'=3B "> >an" =3D > >> >style=3D3D"font-family: 'Gill Sans'=3B "> =3B| Computer Science | Pu= > >rdue =3D > >> >University
>pan"=3D > >> > face=3D3D"GillSans-Light"> >> >style=3D3D"font-family: GillSans-Light=3B ">305 N. University Street | W= > >est =3D > >> >Lafayette | IN 47907 | USA
>> >class=3D3D"Apple-style-span" color=3D3D"#0000FF" face=3D3D"Gill Sans"> >pan =3D > >> >class=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B fon= > >t-family: =3D > >> >'Gill Sans'=3B "> >b(0=2C =3D > >> >0=2C 255)=3B font-family: 'Gill Sans'=3B ">Office >ont =3D > >> >class=3D3D"Apple-style-span" face=3D3D"GillSans-Light"> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B "= > >> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B = > >=3D > >> >"> =3B+1 765 494 6001 | >> >class=3D3D"Apple-converted-space"> =3B >ont =3D > >> >class=3D3D"Apple-style-span" color=3D3D"#0000FF" face=3D3D"Gill Sans"> >pan =3D > >> >class=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B fon= > >t-family: =3D > >> >'Gill Sans'=3B "> >b(0=2C =3D > >> >0=2C 255)=3B font-family: 'Gill Sans'=3B ">Mobile >ont =3D > >> >class=3D3D"Apple-style-span" face=3D3D"GillSans-Light"> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B "= > >> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B "= > >> >> >class=3D3D"Apple-converted-space"> =3B+1 765 427 =3D > >> >5484
>=3D > >> >face=3D3D"GillSans-Light">
>> >class=3D3D"khtml-block-placeholder">
>span=3D > >> >>

>> >class=3D3D"Apple-interchange-newline">
<= > >br =3D > >> >class=3D3D"Apple-interchange-newline">

On 6 Sep 2009= > >=2C =3D > >> >at 23:18=2C Jay K wrote:

>> >class=3D3D"Apple-interchange-newline">
>> >type=3D3D"cite">









[was truncated = > >=3D > >> >again!]

PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes= > > =3D > >> >runs out of stack

=3D > >> > > >> >--Apple-Mail-13--794937978-- > > > >--_d2a2b05c-dd99-4149-b3de-8867976ffb79_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Nice thing about pthreads is everyone uses them.
Whatever tools they hav= > >e=2C we can use.

 =3B ..Jay

>=3B To: hosking at cs.purdue.= > >edu=3B jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com
>=3B = > >Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems= > >)
>=3B Date: Tue=2C 8 Sep 2009 00:48:40 -0700
>=3B From: mika at as= > >ync.async.caltech.edu
>=3B
>=3B
>=3B A nice thing about th= > >e user threads system is that it has a beautiful
>=3B deadlock detecto= > >r... do you have anything like this in the pthreads
>=3B environment?<= > >br>>=3B
>=3B Mika
>=3B
>=3B Tony Hosking writes:
= > >>=3B >=3B
>=3B >=3B--Apple-Mail-13--794937978
>=3B >=3BCo= > >ntent-Type: text/plain=3B
>=3B >=3B charset=3DUS-ASCII=3B
>=3B > > = > >>=3B format=3Dflowed=3B
>=3B >=3B delsp=3Dyes
>=3B >=3BCon > >t= > >ent-Transfer-Encoding: 7bit
>=3B >=3B
>=3B >=3BHere's the han= > >g backtrace for mentor. Again=2C all appears normal=2C
>=3B >=3Be= > >xcept that all the threads are paused or waiting=2C which is
>=3B &g= > >t=3Bsuspicious. I'm stumped for now.
>=3B >=3B
>=3B >=3BThre= > >ad 21 (process 96727 thread 0x7403):
>=3B >=3B#0 0x9634946e in __se= > >mwait_signal ()
>=3B >=3B#1 0x963492ef in nanosleep$UNIX2003 ()
= > >>=3B >=3B#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb15d4db0= > >=2C
>=3B >=3Brem=3D0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThr= > >eadC.c:318
>=3B >=3B#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP3= > >2l_self=3D0x1f3f880=2C
>=3B >=3BM3_CtKayy_n=3D1=2C M3_AicXUJ_alert= > >able=3D0 '\0') at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:= > >668
>=3B >=3B#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ..= > >/src/thread/
>=3B >=3BPTHREAD/ThreadPThread.m3:685
>=3B >=3B= > >#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=3D0x1f3f870) at ../ >>>=3B >=3Bsrc/xvbt/XClientF.m3:105
>=3B >=3B#6 0x0101f243 in Th= > >readPThread__RunThread (M3_BeUkBA_me=3D0x1c441d0)
>=3B >=3Bat ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x0101ef74 in Th= > >readPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c441d0) at = > >../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >= > >=3B#8 0x96373155 in _pthread_start ()
>=3B >=3B#9 0x96373012 in th= > >read_start ()
>=3B >=3B
>=3B >=3BThread 20 (process 96727 thr= > >ead 0x7103):
>=3B >=3B#0 ThreadPThread__XTestAlert (M3_BXP32l_self= > >=3D0x1e5c134) at ../src/
>=3B >=3Bthread/PTHREAD/ThreadPThread.m3:3= > >19
>=3B >=3B#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self= > >=3D0x1e5c134=2C
>=3B >=3BM3_CtKayy_n=3D0.0056863520294427872=2C M3= > >_AicXUJ_alertable=3D1 '\001') at ../
>=3B >=3Bsrc/thread/PTHREAD/Th= > >readPThread.m3:669
>=3B >=3B#2 0x01020024 in Thread__AlertPause >r>>=3B >=3B(M3_CtKayy_n=3D0.0056863520294427872) at ../src/thread/PTHRE= > >AD/
>=3B >=3BThreadPThread.m3:699
>=3B >=3B#3 0x008f9ea1 in= > > Animate__Do (M3_CCfZY3_t=3D0x1e7e3fc=2C
>=3B >=3BM3_DsL7Zz_mg=3D0= > >x0=2C M3_AdEaVQ_v=3D0x1e5e0f8=2C M3_BUucNs_duration=3D1) at ../
>=3B = > >>=3Bsrc/Animate.m3:71
>=3B >=3B#4 0x00909610 in MGV__Animation (M= > >3_AdEaVQ_v=3D0x1e5e0f8=2C
>=3B >=3BM3_BUucNs_duration=3D1) at ../s= > >rc/MGV.m3:313
>=3B >=3B#5 0x008921f9 in GraphVBT__AnimateGraph (M3_= > >Cj00zi_graph=3D0x1e5e00c=2C
>=3B >=3BM3_BUucNs_t0=3D0=2C M3_BUucNs= > >_t1=3D1) at ../src/GraphVBT.m3:656
>=3B >=3B#6 0x00019be8 in ViewEr= > >ror__ShowPixel (M3_AoJTjZ_view=3D0x1ed3060=2C
>=3B >=3BM3_AcxOUs_x= > >=3D3=2C M3_AcxOUs_y=3D2=2C M3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2=3D-2) at ../ >r>>=3B >=3Bsrc/bresenham/ViewError.m3:548
>=3B >=3B#7 0x0001529= > >a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D0x1ed3060=2C
>=3B >= > >=3BM3_Af40ku_evt=3D0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101
>= > >=3B >=3B#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c128) a= > >t ../
>=3B >=3Bsrc/Zeus.m3:331
>=3B >=3B#9 0x0101f243 in Th= > >readPThread__RunThread (M3_BeUkBA_me=3D0x1c3fd80)
>=3B >=3Bat ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#10 0x0101ef74 in Th= > >readPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c3fd80) at = > >../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >= > >=3B#11 0x96373155 in _pthread_start ()
>=3B >=3B#12 0x96373012 in th= > >read_start ()
>=3B >=3B
>=3B >=3BThread 19 (process 96727 thr= > >ead 0x5d07):
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap (= > >)
>=3B >=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B#= > >2 0x963b9539 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in Thr= > >eadPThread__XWait (M3_BXP32l_self=3D0x1e5c0bc=2C
>=3B >=3BM3_AYIbX= > >3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1edf34c=2C M3_AicXUJ_alertable=3D1
= > >>=3B >=3B'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>= > >=3B >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc=2C = > >
>=3B >=3BM3_Bl0jv4_c=3D0x1edf34c) at ../src/thread/PTHREAD/ThreadPT= > >hread.m3:266
>=3B >=3B#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_C= > >QpoHd_zeus=3D0x1e3ccfc=2C
>=3B >=3BM3_B74vJ1_view=3D0x1edf25c) at = > >../src/Zeus.m3:361
>=3B >=3B#6 0x007abaa2 in Zeus__ViewThread (M3_B= > >H3Tll_self=3D0x1e5c0b0) at ../
>=3B >=3Bsrc/Zeus.m3:328
>=3B &= > >gt=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fc80) = > >
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B &= > >gt=3B#8 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWx= > >b1_param=3D0x1c3fc80) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThr= > >ead.m3:522
>=3B >=3B#9 0x96373155 in _pthread_start ()
>=3B &g= > >t=3B#10 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThre= > >ad 18 (process 96727 thread 0x700b):
>=3B >=3B#0 0x963422ce in sema= > >phore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread_cond_w= > >ait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>=3B >= > >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c044=2C <= > >br>>=3B >=3BM3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1ee3bac=2C M3_Ai= > >cXUJ_alertable=3D1
>=3B >=3B'\001') at ../src/thread/PTHREAD/Threa= > >dPThread.m3:226
>=3B >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYI= > >bX3_m=3D0x1e3f9bc=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1ee3bac) at ../src/t= > >hread/PTHREAD/ThreadPThread.m3:266
>=3B >=3B#5 0x007ab7f2 in Zeus__= > >WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc=2C
>=3B >=3BM3_B74vJ1= > >_view=3D0x1ee3b00) at ../src/Zeus.m3:361
>=3B >=3B#6 0x007abaa2 in = > >Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c038) at ../
>=3B >=3Bsrc/Z= > >eus.m3:328
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_B= > >eUkBA_me=3D0x1c3fa90)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThr= > >ead.m3:546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase >>>=3B >=3B(M3_AJWxb1_param=3D0x1c3fa90) at ../src/thread/PTHREAD/
&= > >gt=3B >=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread= > >_start ()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >= > >=3B
>=3B >=3BThread 17 (process 96727 thread 0x6e03):
>=3B >= > >=3B#0 0x963493dc in _pthread_testcancel ()
>=3B >=3B#1 0x96349275 = > >in nanosleep$UNIX2003 ()
>=3B >=3B#2 0x01022cc4 in ThreadPThread__N= > >anosleep (req=3D0xb134add0=2C
>=3B >=3Brem=3D0xb134add8) at ../src= > >/thread/PTHREAD/ThreadPThreadC.c:318
>=3B >=3B#3 0x0101fd7c in Thre= > >adPThread__XPause (M3_BXP32l_self=3D0x1e54388=2C
>=3B >=3BM3_CtKay= > >y_n=3D0.5=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHREAD/
&g= > >t=3B >=3BThreadPThread.m3:668
>=3B >=3B#4 0x0101fef3 in Thread__P= > >ause (M3_CtKayy_n=3D0.5) at ../src/thread/
>=3B >=3BPTHREAD/ThreadP= > >Thread.m3:685
>=3B >=3B#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco= > >_arg=3D0x1e5437c) at ../src/
>=3B >=3Bvtext/VTCaret.m3:149
>= > >=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3f= > >9c0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>= > >=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3= > >_AJWxb1_param=3D0x1c3f9c0) at ../src/thread/PTHREAD/
>=3B >=3BThrea= > >dPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthread_start ()
>= > >=3B >=3B#9 0x96373012 in thread_start ()
>=3B >=3B
>=3B >= > >=3BThread 16 (process 96727 thread 0x435b):
>=3B >=3B#0 0x963422ce = > >in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread= > >_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>= > >=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1df30c= > >8=2C
>=3B >=3BM3_AYIbX3_m=3D0x1e3bb94=2C M3_Bl0jv4_c=3D0x1e3bbb0= > >=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/thread/PTHREA= > >D/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread__Wait (M3_A= > >YIbX3_m=3D0x1e3bb94=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1e3bbb0) at ../src= > >/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x007baaa1 in Zeus= > >Panel__PanelThread (M3_CvdnuP_pc=3D0x1df30b8)
>=3B >=3Bat ../src/Z= > >eusPanel.m3:1425
>=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread= > > (M3_BeUkBA_me=3D0x1c39830)
>=3B >=3Bat ../src/thread/PTHREAD/Thre= > >adPThread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBas= > >e
>=3B >=3B(M3_AJWxb1_param=3D0x1c39830) at ../src/thread/PTHREAD/= > >
>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x96373155 in _p= > >thread_start ()
>=3B >=3B#9 0x96373012 in thread_start ()
>=3B= > > >=3B
>=3B >=3BThread 15 (process 96727 thread 0x420b):
>=3B = > >>=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0= > >x963742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthrea= > >d_cond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_B= > >XP32l_self=3D0x1d67e68=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_B= > >l0jv4_c=3D0x1d22688=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at .= > >./src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in= > > Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0= > >x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 = > > 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ee3b00) at ../
&g= > >t=3B >=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007a98b1 in Vie= > >w__WaiterThread (M3_C7vPGX_waiter=3D0x1d67e5c)
>=3B >=3Bat ../src/= > >View.m3:74
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_B= > >eUkBA_me=3D0x1c305c0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThr= > >ead.m3:546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase >>>=3B >=3B(M3_AJWxb1_param=3D0x1c305c0) at ../src/thread/PTHREAD/
&= > >gt=3B >=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread= > >_start ()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >= > >=3B
>=3B >=3BThread 14 (process 96727 thread 0x4103):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1ee32e4=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_Bl0j= > >v4_c=3D0x1edf3c4=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Th= > >read__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1e= > >df3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x= > >00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1edf25c) at ../
>= > >=3B >=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007a98b1 in View= > >__WaiterThread (M3_C7vPGX_waiter=3D0x1ee32d8)
>=3B >=3Bat ../src/V= > >iew.m3:74
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_Be= > >UkBA_me=3D0x1c38bf0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThre= > >ad.m3:546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase
= > >>=3B >=3B(M3_AJWxb1_param=3D0x1c38bf0) at ../src/thread/PTHREAD/
&g= > >t=3B >=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread_= > >start ()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >=3B= > >
>=3B >=3BThread 13 (process 96727 thread 0x4003):
>=3B >=3B#= > >0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742= > >c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_= > >wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_s= > >elf=3D0x1edb2e4=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c= > >=3D0x1ed532c=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/t= > >hread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread= > >__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1ed532= > >c) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x00c4= > >0602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ed3060) at ../
>=3B &g= > >t=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007a98b1 in View__Wait= > >erThread (M3_C7vPGX_waiter=3D0x1edb2d8)
>=3B >=3Bat ../src/View.m3= > >:74
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_m= > >e=3D0x1c38780)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:= > >546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase
>=3B= > > >=3B(M3_AJWxb1_param=3D0x1c38780) at ../src/thread/PTHREAD/
>=3B &= > >gt=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread_start = > >()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >=3B
&g= > >t=3B >=3BThread 12 (process 96727 thread 0x2e03):
>=3B >=3B#0 0x9= > >63422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in = > >_pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait (= > >)
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D= > >0x1ed52a4=2C
>=3B >=3BM3_AYIbX3_m=3D0x1ed327c=2C M3_Bl0jv4_c=3D0x1= > >ed35f4=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/thread/= > >PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread__Wait= > > (M3_AYIbX3_m=3D0x1ed327c=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1ed35f4) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x00bb7962 i= > >n XMessenger__Messenger (M3_EVlqQO_self=3D0x1ed5294)
>=3B >=3Bat .= > >./src/xvbt/XMessenger.m3:69
>=3B >=3B#6 0x0101f243 in ThreadPThread= > >__RunThread (M3_BeUkBA_me=3D0x1c38420)
>=3B >=3Bat ../src/thread/P= > >THREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread= > >__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c38420) at ../src/thre= > >ad/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x963= > >73155 in _pthread_start ()
>=3B >=3B#9 0x96373012 in thread_start (= > >)
>=3B >=3B
>=3B >=3BThread 11 (process 96727 thread 0x2b07):= > >
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B = > >>=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b953= > >9 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__= > >XWait (M3_BXP32l_self=3D0x1ed5254=2C
>=3B >=3BM3_AYIbX3_m=3D0x1ed3= > >27c=2C M3_Bl0jv4_c=3D0x1ed3614=2C M3_AicXUJ_alertable=3D0
>=3B >= > >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 = > >0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c=2C
>=3B >=3BM3= > >_Bl0jv4_c=3D0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>= > >=3B >=3B#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=3D0x1ed524= > >4)
>=3B >=3Bat ../src/xvbt/XInput.m3:102
>=3B >=3B#6 0x010= > >1f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38320)
>=3B &g= > >t=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x010= > >1ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1= > >c38320) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
= > >>=3B >=3B#8 0x96373155 in _pthread_start ()
>=3B >=3B#9 0x9637= > >3012 in thread_start ()
>=3B >=3B
>=3B >=3BThread 10 (process= > > 96727 thread 0x2a23):
>=3B >=3B#0 0x963916fa in select$DARWIN_EXTS= > >N ()
>=3B >=3B#1 0x01023503 in Unix__select (nfds=3D7=2C readfds=3D= > >0x2813d54=2C
>=3B >=3Bwritefds=3D0x2813d64=2C exceptfds=3D0x2813d7= > >4=2C timeout=3D0x0) at ../src/unix/
>=3B >=3BCommon/UnixC.c:301
= > >>=3B >=3B#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762
= > >>=3B >=3B(M3_Cwb5VA_nfd=3D<=3Bunknown type>=3B=2C M3_A4bqCj_timeout= > >=3D0x0) at ../src/thread/
>=3B >=3BPTHREAD/ThreadPThread.m3:787
= > >>=3B >=3B#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1= > >ed5204=2C
>=3B >=3BM3_Cwb5VA_fd=3D<=3Bunknown type>=3B=2C M3_A= > >icXUJ_read=3D1 '\001'=2C
>=3B >=3BM3_CtKayy_interval=3D-1=2C M3_Ai= > >cXUJ_alertable=3D0 '\0') at ../src/thread/
>=3B >=3BPTHREAD/ThreadP= > >Thread.m3:826
>=3B >=3B#4 0x010201b4 in SchedulerPosix__IOWait (M3_= > >Cwb5VA_fd=3D<=3Bunknown type>=3B=2C
>=3B >=3BM3_AicXUJ_read=3D= > >1 '\001'=2C M3_CtKayy_timeoutInterval=3D-1) at ../src/
>=3B >=3Bthr= > >ead/PTHREAD/ThreadPThread.m3:729
>=3B >=3B#5 0x00bbf20b in XInput__= > >WaitForXInput (M3_Bkyxhg_self=3D0x1ed51f4)
>=3B >=3Bat ../src/xvbt= > >/XInput.m3:63
>=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M= > >3_BeUkBA_me=3D0x1c38250)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadP= > >Thread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase = > >
>=3B >=3B(M3_AJWxb1_param=3D0x1c38250) at ../src/thread/PTHREAD/ >r>>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthr= > >ead_start ()
>=3B >=3B#9 0x96373012 in thread_start ()
>=3B &g= > >t=3B
>=3B >=3BThread 9 (process 96727 thread 0x29f3):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1e3fafc=2C
>=3B >=3BM3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0j= > >v4_c=3D0x1e3f9c8=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Th= > >read__Wait (M3_AYIbX3_m=3D0x1e3f9bc=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1e= > >3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x= > >007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=3D0x1e3ccfc=2C
>=3B >= > >=3BM3_Ao6Rbg_initiator=3D0x1ecd9cc=2C M3_BMhQCx_dispatchProc=3D0x150e0=2C = > >
>=3B >=3BM3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:306
&g= > >t=3B >=3B#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D0x1ecd9c= > >c=2C
>=3B >=3BM3_DsvzJ6_style=3D0 '\0'=2C M3_AcxOUs_priority=3D1= > >=2C
>=3B >=3BM3_Bd56fi_eventName=3D0x1d9d60=2C M3_BMhQCx_dispatchP= > >roc=3D0x150e0=2C
>=3B >=3BM3_Af40ku_evtArgs=3D0x1e08014) at ../src= > >/Zeus.m3:246
>=3B >=3B#7 0x000149a7 in BresenhamIE__ShowPixel
= > >>=3B >=3B(M3_CfiRBL_initiator=3D0x1ecd9cc=2C M3_AcxOUs_x=3D3=2C M3_AcxO= > >Us_y=3D2=2C
>=3B >=3BM3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2=3D-2) at ../= > >I386_DARWIN/BresenhamIE.m3:227
>=3B >=3B#8 0x000175b7 in AlgBresenh= > >am__DrawLine (M3_ECecEc_alg=3D0x1ecd9cc=2C
>=3B >=3BM3_AcxOUs_x1= > >=3D0=2C M3_AcxOUs_y1=3D0=2C M3_AcxOUs_x2=3D10=2C M3_AcxOUs_y2=3D6) at ../ <= > >br>>=3B >=3Bsrc/bresenham/AlgBresenham.m3:55
>=3B >=3B#9 0x0001= > >788f in AlgBresenham__Run (M3_ECecEc_alg=3D0x1ecd9cc) at ../
>=3B >= > >=3Bsrc/bresenham/AlgBresenham.m3:86
>=3B >=3B#10 0x007bb729 in ZeusP= > >anel__AlgThread (M3_Dijbki_ac=3D0x1e3fae8) at ../
>=3B >=3Bsrc/Zeus= > >Panel.m3:1534
>=3B >=3B#11 0x0101f243 in ThreadPThread__RunThread (M= > >3_BeUkBA_me=3D0x1c29fd0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadP= > >Thread.m3:546
>=3B >=3B#12 0x0101ef74 in ThreadPThread__ThreadBase = > >
>=3B >=3B(M3_AJWxb1_param=3D0x1c29fd0) at ../src/thread/PTHREAD/ >r>>=3B >=3BThreadPThread.m3:522
>=3B >=3B#13 0x96373155 in _pthr= > >ead_start ()
>=3B >=3B#14 0x96373012 in thread_start ()
>=3B &g= > >t=3B
>=3B >=3BThread 8 (process 96727 thread 0x2803):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1d8e01c=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d71fdc=2C M3_Bl0j= > >v4_c=3D0x1d71fe8=2C M3_AicXUJ_alertable=3D1
>=3B >=3B'\001') at ..= > >/src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d7a6 in = > >Thread__AlertWait (M3_AYIbX3_m=3D0x1d71fdc=2C
>=3B >=3BM3_Bl0jv4_c= > >=3D0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266
>=3B >= > >=3B#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=3D0x1d71680=2C
&= > >gt=3B >=3BM3_DBiloZ_this=3D1 '\001'=2C M3_Cwb5VA_minSize=3D<=3Bunknown = > >type>=3B) at ../src/
>=3B >=3Bformatter/Formatter.m3:440
>= > >=3B >=3B#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=3D0x1d71680=2C <= > >br>>=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>=3B) at ../src/formatter= > >/Formatter.m3:542
>=3B >=3B#7 0x00e3c2b8 in Formatter__Peek (M3_ACp= > >9GL_t=3D0x1d71680=2C
>=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>= > >=3B) at ../src/formatter/Formatter.m3:592
>=3B >=3B#8 0x00e3c2ff in= > > Formatter__PeekOp (M3_ACp9GL_t=3D0x1d71680=2C
>=3B >=3BM3_Cwb5VA_= > >i=3D<=3Bunknown type>=3B) at ../src/formatter/Formatter.m3:577
>= > >=3B >=3B#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d71680= > >=2C
>=3B >=3BM3_DOUxXw_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb038ce= > >90=2C
>=3B >=3BM3_Cwb5VA_maxL=3D<=3Bunknown type>=3B=2C M3_CCu= > >ODf_op=3D0x1d72c08) at ../src/
>=3B >=3Bformatter/Formatter.m3:708<= > >br>>=3B >=3B#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1= > >d8e00c) at ../
>=3B >=3Bsrc/formatter/Formatter.m3:615
>=3B &g= > >t=3B#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29140) = > >
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B &g= > >t=3B#12 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb= > >1_param=3D0x1c29140) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThre= > >ad.m3:522
>=3B >=3B#13 0x96373155 in _pthread_start ()
>=3B >= > >=3B#14 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThrea= > >d 7 (process 96727 thread 0x2703):
>=3B >=3B#0 0x963422ce in semaph= > >ore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread_cond_wai= > >t ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>=3B >= > >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d71618=2C <= > >br>>=3B >=3BM3_AYIbX3_m=3D0x1d715ec=2C M3_Bl0jv4_c=3D0x1d715f8=2C M3_Ai= > >cXUJ_alertable=3D1
>=3B >=3B'\001') at ../src/thread/PTHREAD/Threa= > >dPThread.m3:226
>=3B >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYI= > >bX3_m=3D0x1d715ec=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1d715f8) at ../src/t= > >hread/PTHREAD/ThreadPThread.m3:266
>=3B >=3B#5 0x00e3bdf2 in Format= > >ter__Allocate (M3_ACp9GL_t=3D0x1d70c90=2C
>=3B >=3BM3_DBiloZ_this= > >=3D1 '\001'=2C M3_Cwb5VA_minSize=3D<=3Bunknown type>=3B) at ../src/ >>>=3B >=3Bformatter/Formatter.m3:440
>=3B >=3B#6 0x00e3bf0a in = > >Formatter__Probe (M3_ACp9GL_t=3D0x1d70c90=2C
>=3B >=3BM3_Cwb5VA_i= > >=3D<=3Bunknown type>=3B) at ../src/formatter/Formatter.m3:542
>=3B= > > >=3B#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d70c90=2C
&= > >gt=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>=3B) at ../src/formatter/For= > >matter.m3:592
>=3B >=3B#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9G= > >L_t=3D0x1d70c90=2C
>=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>=3B= > >) at ../src/formatter/Formatter.m3:577
>=3B >=3B#9 0x00e3cb25 in Fo= > >rmatter__PrintUntil (M3_ACp9GL_t=3D0x1d70c90=2C
>=3B >=3BM3_DOUxXw= > >_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb030ae90=2C
>=3B >=3BM3_Cwb5= > >VA_maxL=3D<=3Bunknown type>=3B=2C M3_CCuODf_op=3D0x1d72c08) at ../src/ = > >
>=3B >=3Bformatter/Formatter.m3:708
>=3B >=3B#10 0x00e3cfc9 = > >in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d71608) at ../
>=3B >= > >=3Bsrc/formatter/Formatter.m3:615
>=3B >=3B#11 0x0101f243 in ThreadP= > >Thread__RunThread (M3_BeUkBA_me=3D0x1c221e0)
>=3B >=3Bat ../src/th= > >read/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#12 0x0101ef74 in ThreadP= > >Thread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c221e0) at ../sr= > >c/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >=3B#13= > > 0x96373155 in _pthread_start ()
>=3B >=3B#14 0x96373012 in thread_s= > >tart ()
>=3B >=3B
>=3B >=3BThread 6 (process 96727 thread 0x2= > >603):
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
&g= > >t=3B >=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x96= > >3b9539 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThr= > >ead__XWait (M3_BXP32l_self=3D0x1d729bc=2C
>=3B >=3BM3_AYIbX3_m=3D0= > >x1d728b4=2C M3_Bl0jv4_c=3D0x1d729a0=2C M3_AicXUJ_alertable=3D1
>=3B = > >>=3B'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >= > >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d728b4=2C
>= > >=3B >=3BM3_Bl0jv4_c=3D0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m= > >3:266
>=3B >=3B#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_= > >self=3D0x1d729b0)
>=3B >=3Bat ../src/WorkerPool.m3:152
>=3B &= > >gt=3B#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28e10) = > >
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B &= > >gt=3B#7 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWx= > >b1_param=3D0x1c28e10) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThr= > >ead.m3:522
>=3B >=3B#8 0x96373155 in _pthread_start ()
>=3B &g= > >t=3B#9 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThre= > >ad 5 (process 96727 thread 0x2313):
>=3B >=3B#0 0x963916fa in selec= > >t$DARWIN_EXTSN ()
>=3B >=3B#1 0x01023503 in Unix__select (nfds=3D4= > >=2C readfds=3D0x1d74014=2C
>=3B >=3Bwritefds=3D0x1d74024=2C except= > >fds=3D0x1d74034=2C timeout=3D0xb0206b20) at ../src/
>=3B >=3Bunix/C= > >ommon/UnixC.c:301
>=3B >=3B#2 0x01020970 in ThreadPThread__XIOWait_= > >_CallSelect.762
>=3B >=3B(M3_Cwb5VA_nfd=3D<=3Bunknown type>=3B= > >=2C M3_A4bqCj_timeout=3D0xb0206b20) at ../src/
>=3B >=3Bthread/PTHR= > >EAD/ThreadPThread.m3:787
>=3B >=3B#3 0x010206a8 in ThreadPThread__X= > >IOWait (M3_BXP32l_self=3D0x1d585bc=2C
>=3B >=3BM3_Cwb5VA_fd=3D<= > >=3Bunknown type>=3B=2C M3_AicXUJ_read=3D1 '\001'=2C
>=3B >=3BM3_= > >CtKayy_interval=3D1.7976931348623157e+308=2C M3_AicXUJ_alertable=3D1
&= > >gt=3B >=3B'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823
>=3B= > > >=3B#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3D<=3B= > >unknown
>=3B >=3Btype>=3B=2C M3_AicXUJ_read=3D1 '\001'=2C M3_CtK= > >ayy_timeoutInterval=3D-1) at ../
>=3B >=3Bsrc/thread/PTHREAD/Thread= > >PThread.m3:742
>=3B >=3B#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_Aa= > >hksS_c=3D0x1d58594=2C
>=3B >=3BM3_DoBjMZ_peer=3D0xb0206cb4) at ../= > >src/POSIX/TCP.m3:458
>=3B >=3B#6 0x00dd3da8 in TCP__Accept (M3_Aahk= > >sS_c=3D0x1d58594) at ../src/POSIX/
>=3B >=3BTCP.m3:234
>=3B &g= > >t=3B#7 0x006dbc6b in LocalObjectSpace__SpaceAccept
>=3B >=3B(M3_D= > >bz8GV_self=3D0x1d585b0) at ../src/LocalObjectSpace.m3:307
>=3B >=3B#= > >8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28d60)
&= > >gt=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#= > >9 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_par= > >am=3D0x1c28d60) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3= > >:522
>=3B >=3B#10 0x96373155 in _pthread_start ()
>=3B >=3B#1= > >1 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThread 4 (= > >process 96727 thread 0x2003):
>=3B >=3B#0 0x9634946e in __semwait_s= > >ignal ()
>=3B >=3B#1 0x963492ef in nanosleep$UNIX2003 ()
>=3B = > >>=3B#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb0184dd0=2C
= > >>=3B >=3Brem=3D0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:31= > >8
>=3B >=3B#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self= > >=3D0x1d0ba08=2C
>=3B >=3BM3_CtKayy_n=3D1=2C M3_AicXUJ_alertable=3D= > >0 '\0') at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:668
= > >>=3B >=3B#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ../src/th= > >read/
>=3B >=3BPTHREAD/ThreadPThread.m3:685
>=3B >=3B#5 0x0= > >0a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D0x1d0ba00)
>=3B &= > >gt=3Bat ../src/lego/FileBrowserVBT.m3:259
>=3B >=3B#6 0x0101f243 in= > > ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21830)
>=3B >=3Bat .= > >./src/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x0101ef74 in= > > ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c21830) = > >at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B &= > >gt=3B#8 0x96373155 in _pthread_start ()
>=3B >=3B#9 0x96373012 in = > >thread_start ()
>=3B >=3B
>=3B >=3BThread 3 (process 96727 th= > >read 0x1f03):
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap = > >()
>=3B >=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B= > >#2 0x963b9539 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in Th= > >readPThread__XWait (M3_BXP32l_self=3D0x1d090d4=2C
>=3B >=3BM3_AYIb= > >X3_m=3D0x1d090b0=2C M3_Bl0jv4_c=3D0x1d090bc=2C M3_AicXUJ_alertable=3D0 >>>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>=3B= > > >=3B#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d090b0=2C
>= > >=3B >=3BM3_Bl0jv4_c=3D0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m= > >3:277
>=3B >=3B#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTr= > >Vz_cl=3D0x1d090cc)
>=3B >=3Bat ../src/vtext/VTView.m3:111
>= > >=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21= > >310)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>= > >=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3= > >_AJWxb1_param=3D0x1c21310) at ../src/thread/PTHREAD/
>=3B >=3BThrea= > >dPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthread_start ()
>= > >=3B >=3B#9 0x96373012 in thread_start ()
>=3B >=3B
>=3B >= > >=3BThread 2 (process 96727 thread 0xd07):
>=3B >=3B#0 0x963422ce in= > > semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread_c= > >ond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>= > >=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d006c= > >8=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00688=2C M3_Bl0jv4_c=3D0x1d00694= > >=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/thread/PTHREA= > >D/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread__Wait (M3_A= > >YIbX3_m=3D0x1d00688=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1d00694) at ../src= > >/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x00bf33d2 in VBTR= > >ep__MeterMaid (M3_EMTrVz_self=3D0x1d006bc) at ../
>=3B >=3Bsrc/vbt/= > >VBTRep.m3:439
>=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M= > >3_BeUkBA_me=3D0x1c21390)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadP= > >Thread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase = > >
>=3B >=3B(M3_AJWxb1_param=3D0x1c21390) at ../src/thread/PTHREAD/ >r>>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthr= > >ead_start ()
>=3B >=3B#9 0x96373012 in thread_start ()
>=3B &g= > >t=3B
>=3B >=3BThread 1 (process 96727 thread 0x10b):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1d0000c=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_Bl0j= > >v4_c=3D0x1df3114=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Th= > >read__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1d= > >f3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x= > >00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1e3a204) at ../
>= > >=3B >=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007c09eb in Zeus= > >Panel__Interact (M3_Bd56fi_title=3D0x290db0=2C
>=3B >=3BM3_DYb95R_= > >path=3D0x1d498c0) at ../src/ZeusPanel.m3:477
>=3B >=3B#7 0x001b0ede= > > in Main_M3 (M3_AcxOUs_mode=3D1) at ../src/Main.m3:165
>=3B >=3B#8 = > >0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=3D0x1d6060) at ../
>= > >=3B >=3Bsrc/runtime/common/RTLinker.m3:399
>=3B >=3B#9 0x00002578= > > in main (argc=3D1=2C argv=3D0xbfffedb8=2C envp=3D0xbfffedc0) at
>= > >=3B >=3B_m3main.mc:6
>=3B >=3B
>=3B >=3B
>=3B >=3BAn= > >tony Hosking | Associate Professor | Computer Science | Purdue
>=3B = > >>=3BUniversity
>=3B >=3B305 N. University Street | West Lafayette = > >| IN 47907 | USA
>=3B >=3BOffice +1 765 494 6001 | Mobile +1 765 427= > > 5484
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B >r>>=3B >=3BOn 6 Sep 2009=2C at 23:18=2C Jay K wrote:
>=3B >=3B >r>>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>= > >=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B &g= > >t=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B&g= > >t=3B [was truncated again!]
>=3B >=3B>=3B
>=3B >=3B>=3B P= > >PC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes runs out of
&= > >gt=3B >=3B>=3B stack
>=3B >=3B
>=3B >=3B
>=3B >=3B= > >--Apple-Mail-13--794937978
>=3B >=3BContent-Type: text/html=3B
&g= > >t=3B >=3B charset=3DUS-ASCII
>=3B >=3BContent-Transfer-Encoding: q > >= > >uoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>=3B<=3Bbody= > > style=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode: space=3B =3D
>= > >=3B >=3B-webkit-line-break: after-white-space=3B ">=3BHere's the hang b= > >acktrace for =3D
>=3B >=3Bmentor. &=3Bnbsp=3BAgain=2C all appears= > > normal=2C except that all the threads are =3D
>=3B >=3Bpaused or wa= > >iting=2C which is suspicious. &=3Bnbsp=3BI'm stumped for =3D
>=3B &= > >gt=3Bnow.<=3Bdiv>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3B= > >div>=3BThread 21 (process 96727 thread =3D
>=3B >=3B0x7403):<=3B= > >/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x9634946e in __semwait_signal = > >=3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963= > >492ef in nanosleep$UNIX2003 ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb= > >15d4db0=2C =3D
>=3B >=3Brem=3D3D0xb15d4db8) at =3D
>=3B >=3B.= > >./src/thread/PTHREAD/ThreadPThreadC.c:318<=3B/div>=3B<=3Bdiv>=3B#3 = > >&=3Bnbsp=3B0x0101fd7c =3D
>=3B >=3Bin ThreadPThread__XPause (M3_B= > >XP32l_self=3D3D0x1f3f880=2C M3_CtKayy_n=3D3D1=2C =3D
>=3B >=3BM3_Aic= > >XUJ_alertable=3D3D0 '\0') at =3D
>=3B >=3B../src/thread/PTHREAD/Thre= > >adPThread.m3:668<=3B/div>=3B<=3Bdiv>=3B#4 &=3Bnbsp=3B0x0101fef3 = > >=3D
>=3B >=3Bin Thread__Pause (M3_CtKayy_n=3D3D1) at =3D
>=3B &= > >gt=3B../src/thread/PTHREAD/ThreadPThread.m3:685<=3B/div>=3B<=3Bdiv>= > >=3B#5 &=3Bnbsp=3B0x00bc9cf4 =3D
>=3B >=3Bin XClientF__MeterMaid (= > >M3_AS2y1X_cl=3D3D0x1f3f870) at =3D
>=3B >=3B../src/xvbt/XClientF.m3:= > >105<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>= > >=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c441d0) at =3D
&= > >gt=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<= > >=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThrea= > >d__ThreadBase (M3_AJWxb1_param=3D3D0x1c441d0) at =3D
>=3B >=3B../src= > >/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &= > >=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>= > >=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>=3B= > > >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<= > >=3Bdiv>=3BThread 20 (process 96727 thread =3D
>=3B >=3B0x7103):<= > >=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3BThreadPThread__XTestAlert =3D<= > >br>>=3B >=3B(M3_BXP32l_self=3D3D0x1e5c134) at =3D
>=3B >=3B../sr= > >c/thread/PTHREAD/ThreadPThread.m3:319<=3B/div>=3B<=3Bdiv>=3B#1 &= > >=3Bnbsp=3B0x0101fd9b =3D
>=3B >=3Bin ThreadPThread__XPause (M3_BXP32= > >l_self=3D3D0x1e5c134=2C =3D
>=3B >=3BM3_CtKayy_n=3D3D0.0056863520294= > >427872=2C M3_AicXUJ_alertable=3D3D1 '\001') at =3D
>=3B >=3B../src/t= > >hread/PTHREAD/ThreadPThread.m3:669<=3B/div>=3B<=3Bdiv>=3B#2 &=3B= > >nbsp=3B0x01020024 =3D
>=3B >=3Bin Thread__AlertPause (M3_CtKayy_n=3D= > >3D0.0056863520294427872) at =3D
>=3B >=3B../src/thread/PTHREAD/Threa= > >dPThread.m3:699<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x008f9ea1 = > >=3D
>=3B >=3Bin Animate__Do (M3_CCfZY3_t=3D3D0x1e7e3fc=2C M3_DsL7Zz_= > >mg=3D3D0x0=2C =3D
>=3B >=3BM3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_du= > >ration=3D3D1) at =3D
>=3B >=3B../src/Animate.m3:71<=3B/div>=3B&l= > >t=3Bdiv>=3B#4 &=3Bnbsp=3B0x00909610 in MGV__Animation =3D
>=3B &g= > >t=3B(M3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_duration=3D3D1) at =3D
>= > >=3B >=3B../src/MGV.m3:313<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B= > >0x008921f9 in =3D
>=3B >=3BGraphVBT__AnimateGraph (M3_Cj00zi_graph= > >=3D3D0x1e5e00c=2C M3_BUucNs_t0=3D3D0=2C =3D
>=3B >=3BM3_BUucNs_t1=3D= > >3D1) at ../src/GraphVBT.m3:656<=3B/div>=3B<=3Bdiv>=3B#6 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view= > >=3D3D0x1ed3060=2C =3D
>=3B >=3BM3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y=3D3D= > >2=2C M3_AcxOUs_p1=3D3D6=2C M3_AcxOUs_p2=3D3D-2) =3D
>=3B >=3Bat ../s= > >rc/bresenham/ViewError.m3:548<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp= > >=3B0x0001529a in =3D
>=3B >=3BBresenhamIE__OEDispatcher (M3_Ao6Rbg_v= > >=3D3D0x1ed3060=2C =3D
>=3B >=3BM3_Af40ku_evt=3D3D0x1e08014) at =3D >r>>=3B >=3B../I386_DARWIN/BresenhamIE.m3:101<=3B/div>=3B<=3Bdiv&g= > >t=3B#8 &=3Bnbsp=3B0x007abb9b in =3D
>=3B >=3BZeus__ViewThread (M3= > >_BH3Tll_self=3D3D0x1e5c128) at =3D
>=3B >=3B../src/Zeus.m3:331<=3B= > >/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >= > >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fd80) at =3D
>=3B &= > >gt=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>= > >=3B#10 0x0101ef74 in =3D
>=3B >=3BThreadPThread__ThreadBase (M3_AJWx= > >b1_param=3D3D0x1c3fd80) at =3D
>=3B >=3B../src/thread/PTHREAD/Thread= > >PThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#11 0x96373155 in =3D
>= > >=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#12 0x96373012 in= > > thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr= > >>=3B<=3B/div>=3B<=3Bdiv>=3BThread 19 (process 96727 thread =3D >>>=3B >=3B0x5d07):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963= > >422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B&= > >lt=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/di= > >v>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pt= > >hread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d18= > >9 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e5c0bc= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1edf= > >34c=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../src/thre= > >ad/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x= > >1e3f9bc=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1edf34c) at =3D
>=3B = > >>=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div>=3B<=3Bdiv&g= > >t=3B#5 &=3Bnbsp=3B0x007ab7f2 =3D
>=3B >=3Bin Zeus__WakeZeusAndSle= > >ep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D
>=3B >=3BM3_B74vJ1_view=3D3D= > >0x1edf25c) at ../src/Zeus.m3:361<=3B/div>=3B<=3Bdiv>=3B#6 =3D
&g= > >t=3B >=3B&=3Bnbsp=3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D3= > >D0x1e5c0b0) at =3D
>=3B >=3B../src/Zeus.m3:328<=3B/div>=3B<=3B= > >div>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__= > >RunThread (M3_BeUkBA_me=3D3D0x1c3fc80) at =3D
>=3B >=3B../src/thread= > >/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp= > >=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_p= > >aram=3D3D0x1c3fc80) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThr= > >ead.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373155 =3D >>>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#10 0x9637= > >3012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B&= > >lt=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 18 (process 96727 thread= > > =3D
>=3B >=3B0x700b):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp= > >=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/di= > >v>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()&= > >lt=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b95= > >39 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0= > >x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0= > >x1e5c044=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D= > >3D0x1ee3bac=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../= > >src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 = > >=3D
>=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX= > >3_m=3D3D0x1e3f9bc=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1ee3bac) at =3D<= > >br>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div>=3B&= > >lt=3Bdiv>=3B#5 &=3Bnbsp=3B0x007ab7f2 =3D
>=3B >=3Bin Zeus__Wake= > >ZeusAndSleep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D
>=3B >=3BM3_B74vJ1= > >_view=3D3D0x1ee3b00) at ../src/Zeus.m3:361<=3B/div>=3B<=3Bdiv>=3B#6= > > =3D
>=3B >=3B&=3Bnbsp=3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tl= > >l_self=3D3D0x1e5c038) at =3D
>=3B >=3B../src/Zeus.m3:328<=3B/div&g= > >t=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThrea= > >dPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fa90) at =3D
>=3B >=3B../= > >src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8 &a= > >mp=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3= > >_AJWxb1_param=3D3D0x1c3fa90) at =3D
>=3B >=3B../src/thread/PTHREAD/T= > >hreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x963731= > >55 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#= > >10 0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 17 (process 967= > >27 thread =3D
>=3B >=3B0x6e03):<=3B/div>=3B<=3Bdiv>=3B#0 &am= > >p=3Bnbsp=3B0x963493dc in _pthread_testcancel =3D
>=3B >=3B()<=3B/d= > >iv>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x96349275 in nanosleep$UNIX2003 ()= > ><=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x01022= > >cc4 in ThreadPThread__Nanosleep (req=3D3D0xb134add0=2C =3D
>=3B >=3B= > >rem=3D3D0xb134add8) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThr= > >eadC.c:318<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101fd7c =3D >>>=3B >=3Bin ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1e54388=2C M3_= > >CtKayy_n=3D3D0.5=2C =3D
>=3B >=3BM3_AicXUJ_alertable=3D3D0 '\0') at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:668<=3B/div>= > >=3B<=3Bdiv>=3B#4 &=3Bnbsp=3B0x0101fef3 =3D
>=3B >=3Bin Thread= > >__Pause (M3_CtKayy_n=3D3D0.5) at =3D
>=3B >=3B../src/thread/PTHREAD/= > >ThreadPThread.m3:685<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00a6f= > >0c0 =3D
>=3B >=3Bin VTCaret__Blinker (M3_Axogco_arg=3D3D0x1e5437c) a= > >t =3D
>=3B >=3B../src/vtext/VTCaret.m3:149<=3B/div>=3B<=3Bdiv&= > >gt=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunT= > >hread (M3_BeUkBA_me=3D3D0x1c3f9c0) at =3D
>=3B >=3B../src/thread/PTH= > >READ/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x= > >0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param= > >=3D3D0x1c3f9c0) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.= > >m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>= > >=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp= > >=3B0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 16 (process 967= > >27 thread =3D
>=3B >=3B0x435b):<=3B/div>=3B<=3Bdiv>=3B#0 &am= > >p=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()&= > >lt=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_= > >wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B= > >0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3B= > >nbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_se= > >lf=3D3D0x1df30c8=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1e3bb94=2C M3_Bl0= > >jv4_c=3D3D0x1e3bbb0=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') = > >at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>= > >=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIb= > >X3_m=3D3D0x1e3bb94=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1e3bbb0) at =3D= > >
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B= > ><=3Bdiv>=3B#5 &=3Bnbsp=3B0x007baaa1 =3D
>=3B >=3Bin ZeusPanel= > >__PanelThread (M3_CvdnuP_pc=3D3D0x1df30b8) at =3D
>=3B >=3B../src/Ze= > >usPanel.m3:1425<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 i= > >n =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c39830)= > > at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/di= > >v>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin Th= > >readPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c39830) at =3D
>=3B &g= > >t=3B../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>= > >=3B#8 &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<= > >=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D= > >
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div&= > >gt=3B<=3Bdiv>=3BThread 15 (process 96727 thread =3D
>=3B >=3B0x4= > >20b):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphor= > >e_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 = > >&=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv&= > >gt=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait (= > >)<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B &= > >gt=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d67e68=2C =3D
>=3B= > > >=3BM3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1d22688=2C M3_AicXUJ_= > >alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPT= > >hread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnb= > >sp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D
>=3B= > > >=3BM3_Bl0jv4_c=3D3D0x1d22688) at =3D
>=3B >=3B../src/thread/PTHR= > >EAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x0= > >0c40602 =3D
>=3B >=3Bin Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1ee3= > >b00) at =3D
>=3B >=3B../src/trestle/Trestle.m3:884<=3B/div>=3B&l= > >t=3Bdiv>=3B#6 &=3Bnbsp=3B0x007a98b1 in =3D
>=3B >=3BView__Waite= > >rThread (M3_C7vPGX_waiter=3D3D0x1d67e5c) at =3D
>=3B >=3B../src/View= > >.m3:74<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
= > >>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c305c0) at =3D >r>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B&l= > >t=3Bdiv>=3B#8 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThre= > >ad__ThreadBase (M3_AJWxb1_param=3D3D0x1c305c0) at =3D
>=3B >=3B../sr= > >c/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &= > >=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>= > >=3B<=3Bdiv>=3B#10 0x96373012 in thread_start =3D
>=3B >=3B()<= > >=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BTh= > >read 14 (process 96727 thread =3D
>=3B >=3B0x4103):<=3B/div>=3B&= > >lt=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D= > >
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742= > >c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B = > >>=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<= > >=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThrea= > >d__XWait (M3_BXP32l_self=3D3D0x1ee32e4=2C =3D
>=3B >=3BM3_AYIbX3_m= > >=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1edf3c4=2C M3_AicXUJ_alertable=3D3D0 = > >=3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226<= > >=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823= > > in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D
>=3B >=3BM3_Bl0jv= > >4_c=3D3D0x1edf3c4) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThre= > >ad.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00c40602 =3D
= > >>=3B >=3Bin Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1edf25c) at =3D
= > >>=3B >=3B../src/trestle/Trestle.m3:884<=3B/div>=3B<=3Bdiv>=3B#6= > > &=3Bnbsp=3B0x007a98b1 in =3D
>=3B >=3BView__WaiterThread (M3_C7v= > >PGX_waiter=3D3D0x1ee32d8) at =3D
>=3B >=3B../src/View.m3:74<=3B/di= > >v>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BTh= > >readPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38bf0) at =3D
>=3B >=3B= > >../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8= > > &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase = > >(M3_AJWxb1_param=3D3D0x1c38bf0) at =3D
>=3B >=3B../src/thread/PTHREA= > >D/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x963= > >73155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>= > >=3B#10 0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<= > >=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 13 (process= > > 96727 thread =3D
>=3B >=3B0x4003):<=3B/div>=3B<=3Bdiv>=3B#0= > > &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >= > >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread= > >_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bn= > >bsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &= > >amp=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP= > >32l_self=3D3D0x1edb2e4=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d00500=2C = > >M3_Bl0jv4_c=3D3D0x1ed532c=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B= > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdi= > >v>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_= > >AYIbX3_m=3D3D0x1d00500=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1ed532c) at= > > =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div&g= > >t=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00c40602 =3D
>=3B >=3Bin Trest= > >le__AwaitDelete (M3_BFdKo9_v=3D3D0x1ed3060) at =3D
>=3B >=3B../src/t= > >restle/Trestle.m3:884<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x007a= > >98b1 in =3D
>=3B >=3BView__WaiterThread (M3_C7vPGX_waiter=3D3D0x1edb= > >2d8) at =3D
>=3B >=3B../src/View.m3:74<=3B/div>=3B<=3Bdiv>= > >=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunThr= > >ead (M3_BeUkBA_me=3D3D0x1c38780) at =3D
>=3B >=3B../src/thread/PTHRE= > >AD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x01= > >01ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D= > >3D0x1c38780) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:= > >522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373155 =3D
>=3B= > > >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#10 0x96373012 in= > > thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr= > >>=3B<=3B/div>=3B<=3Bdiv>=3BThread 12 (process 96727 thread =3D >>>=3B >=3B0x2e03):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963= > >422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B&= > >lt=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/di= > >v>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pt= > >hread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d18= > >9 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed52a4= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed3= > >5f4=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread= > >/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed32= > >7c=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1ed35f4) at =3D
>=3B >= > >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>= > >=3B#5 &=3Bnbsp=3B0x00bb7962 =3D
>=3B >=3Bin XMessenger__Messenger= > > (M3_EVlqQO_self=3D3D0x1ed5294) at =3D
>=3B >=3B../src/xvbt/XMesseng= > >er.m3:69<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D >r>>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38420) at =3D= > >
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B= > ><=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPTh= > >read__ThreadBase (M3_AJWxb1_param=3D3D0x1c38420) at =3D
>=3B >=3B../= > >src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &a= > >mp=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div&g= > >t=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>= > >=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B&l= > >t=3Bdiv>=3BThread 11 (process 96727 thread =3D
>=3B >=3B0x2b07):&l= > >t=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_= > >signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3B= > >nbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2= > > =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B= > >/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin= > > ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed5254=2C =3D
>=3B >=3B= > >M3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed3614=2C M3_AicXUJ_alertab= > >le=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m= > >3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x= > >0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed327c=2C =3D
>=3B >=3B= > >M3_Bl0jv4_c=3D3D0x1ed3614) at =3D
>=3B >=3B../src/thread/PTHREAD/Thr= > >eadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00bbdbc2= > > =3D
>=3B >=3Bin XInput__FilterXInput (M3_DSd60P_self=3D3D0x1ed5244)= > > at =3D
>=3B >=3B../src/xvbt/XInput.m3:102<=3B/div>=3B<=3Bdiv&= > >gt=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunT= > >hread (M3_BeUkBA_me=3D3D0x1c38320) at =3D
>=3B >=3B../src/thread/PTH= > >READ/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x= > >0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param= > >=3D3D0x1c38320) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.= > >m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>= > >=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp= > >=3B0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 10 (process 967= > >27 thread =3D
>=3B >=3B0x2a23):<=3B/div>=3B<=3Bdiv>=3B#0 &am= > >p=3Bnbsp=3B0x963916fa in select$DARWIN_EXTSN =3D
>=3B >=3B()<=3B/d= > >iv>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x01023503 in Unix__select (nfds=3D= > >3D7=2C =3D
>=3B >=3Breadfds=3D3D0x2813d54=2C writefds=3D3D0x2813d64= > >=2C exceptfds=3D3D0x2813d74=2C =3D
>=3B >=3Btimeout=3D3D0x0) at ../s= > >rc/unix/Common/UnixC.c:301<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B &= > >gt=3B&=3Bnbsp=3B0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =3D= > >
>=3B >=3B(M3_Cwb5VA_nfd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C= > > M3_A4bqCj_timeout=3D3D0x0) at =3D
>=3B >=3B../src/thread/PTHREAD/Th= > >readPThread.m3:787<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x010206c= > >c =3D
>=3B >=3Bin ThreadPThread__XIOWait (M3_BXP32l_self=3D3D0x1ed52= > >04=2C =3D
>=3B >=3BM3_Cwb5VA_fd=3D3D&=3Blt=3Bunknown type&=3Bg= > >t=3B=2C M3_AicXUJ_read=3D3D1 '\001'=2C =3D
>=3B >=3BM3_CtKayy_interv= > >al=3D3D-1=2C M3_AicXUJ_alertable=3D3D0 '\0') at =3D
>=3B >=3B../src/= > >thread/PTHREAD/ThreadPThread.m3:826<=3B/div>=3B<=3Bdiv>=3B#4 &= > >=3Bnbsp=3B0x010201b4 =3D
>=3B >=3Bin SchedulerPosix__IOWait (M3_Cwb5= > >VA_fd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C =3D
>=3B >=3BM3_Ai= > >cXUJ_read=3D3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D3D-1) at =3D
>= > >=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:729<=3B/div>=3B<=3Bd= > >iv>=3B#5 &=3Bnbsp=3B0x00bbf20b =3D
>=3B >=3Bin XInput__WaitForX= > >Input (M3_Bkyxhg_self=3D3D0x1ed51f4) at =3D
>=3B >=3B../src/xvbt/XIn= > >put.m3:63<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D<= > >br>>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38250) at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>= > >=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin Thread= > >PThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38250) at =3D
>=3B >=3B= > >../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8= > > &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/di= > >v>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
&g= > >t=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B&= > >lt=3Bdiv>=3BThread 9 (process 96727 thread =3D
>=3B >=3B0x29f3):&l= > >t=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_= > >signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3B= > >nbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2= > > =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B= > >/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin= > > ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e3fafc=2C =3D
>=3B >=3B= > >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1e3f9c8=2C M3_AicXUJ_alertab= > >le=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m= > >3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x= > >0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C =3D
>=3B >=3B= > >M3_Bl0jv4_c=3D3D0x1e3f9c8) at =3D
>=3B >=3B../src/thread/PTHREAD/Thr= > >eadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x007ab312= > > =3D
>=3B >=3Bin Zeus__AlgToViews (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C = > >=3D
>=3B >=3BM3_Ao6Rbg_initiator=3D3D0x1ecd9cc=2C M3_BMhQCx_dispatch= > >Proc=3D3D0x150e0=2C =3D
>=3B >=3BM3_Af40ku_evtArgs=3D3D0x1e08014) at= > > ../src/Zeus.m3:306<=3B/div>=3B<=3Bdiv>=3B#6 =3D
>=3B >=3B&a= > >mp=3Bnbsp=3B0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D3D0x1ecd9cc= > >=2C =3D
>=3B >=3BM3_DsvzJ6_style=3D3D0 '\0'=2C M3_AcxOUs_priority=3D= > >3D1=2C =3D
>=3B >=3BM3_Bd56fi_eventName=3D3D0x1d9d60=2C M3_BMhQCx_di= > >spatchProc=3D3D0x150e0=2C =3D
>=3B >=3BM3_Af40ku_evtArgs=3D3D0x1e080= > >14) at ../src/Zeus.m3:246<=3B/div>=3B<=3Bdiv>=3B#7 =3D
>=3B &g= > >t=3B&=3Bnbsp=3B0x000149a7 in BresenhamIE__ShowPixel =3D
>=3B >=3B= > >(M3_CfiRBL_initiator=3D3D0x1ecd9cc=2C M3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y=3D3D= > >2=2C =3D
>=3B >=3BM3_AcxOUs_p1=3D3D6=2C M3_AcxOUs_p2=3D3D-2) at =3D<= > >br>>=3B >=3B../I386_DARWIN/BresenhamIE.m3:227<=3B/div>=3B<=3Bdiv&= > >gt=3B#8 &=3Bnbsp=3B0x000175b7 in =3D
>=3B >=3BAlgBresenham__DrawL= > >ine (M3_ECecEc_alg=3D3D0x1ecd9cc=2C M3_AcxOUs_x1=3D3D0=2C =3D
>=3B >= > >=3BM3_AcxOUs_y1=3D3D0=2C M3_AcxOUs_x2=3D3D10=2C M3_AcxOUs_y2=3D3D6) at =3D<= > >br>>=3B >=3B../src/bresenham/AlgBresenham.m3:55<=3B/div>=3B<=3Bdi= > >v>=3B#9 &=3Bnbsp=3B0x0001788f in =3D
>=3B >=3BAlgBresenham__Run= > > (M3_ECecEc_alg=3D3D0x1ecd9cc) at =3D
>=3B >=3B../src/bresenham/AlgB= > >resenham.m3:86<=3B/div>=3B<=3Bdiv>=3B#10 0x007bb729 in =3D
>= > >=3B >=3BZeusPanel__AlgThread (M3_Dijbki_ac=3D3D0x1e3fae8) at =3D
>= > >=3B >=3B../src/ZeusPanel.m3:1534<=3B/div>=3B<=3Bdiv>=3B#11 0x0101= > >f243 in =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c= > >29fd0) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<= > >=3B/div>=3B<=3Bdiv>=3B#12 0x0101ef74 in =3D
>=3B >=3BThreadPTh= > >read__ThreadBase (M3_AJWxb1_param=3D3D0x1c29fd0) at =3D
>=3B >=3B../= > >src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#13 0= > >x96373155 in =3D
>=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv= > >>=3B#14 0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B= > ><=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 8 (proce= > >ss 96727 thread =3D
>=3B >=3B0x2803):<=3B/div>=3B<=3Bdiv>=3B= > >#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >= > >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread= > >_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bn= > >bsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &= > >amp=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP= > >32l_self=3D3D0x1d8e01c=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d71fdc=2C = > >M3_Bl0jv4_c=3D3D0x1d71fe8=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B= > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3B= > >div>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWa= > >it (M3_AYIbX3_m=3D3D0x1d71fdc=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1d71= > >fe8) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:266<= > >=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00e3bdf2 =3D
>=3B >= > >=3Bin Formatter__Allocate (M3_ACp9GL_t=3D3D0x1d71680=2C M3_DBiloZ_this=3D3D= > >1 =3D
>=3B >=3B'\001'=2C M3_Cwb5VA_minSize=3D3D&=3Blt=3Bunknown t= > >ype&=3Bgt=3B) at =3D
>=3B >=3B../src/formatter/Formatter.m3:440&l= > >t=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x00e3bf0a in =3D
>=3B &= > >gt=3BFormatter__Probe (M3_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D&=3B= > >lt=3Bunknown =3D
>=3B >=3Btype&=3Bgt=3B) at ../src/formatter/Form= > >atter.m3:542<=3B/div>=3B<=3Bdiv>=3B#7 =3D
>=3B >=3B&=3Bnb= > >sp=3B0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d71680=2C =3D
>= > >=3B >=3BM3_Cwb5VA_i=3D3D&=3Blt=3Bunknown type&=3Bgt=3B) at =3D
&= > >gt=3B >=3B../src/formatter/Formatter.m3:592<=3B/div>=3B<=3Bdiv>= > >=3B#8 &=3Bnbsp=3B0x00e3c2ff in =3D
>=3B >=3BFormatter__PeekOp (M3= > >_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D&=3Blt=3Bunknown =3D
>= > >=3B >=3Btype&=3Bgt=3B) at ../src/formatter/Formatter.m3:577<=3B/div&= > >gt=3B<=3Bdiv>=3B#9 =3D
>=3B >=3B&=3Bnbsp=3B0x00e3cb25 in Form= > >atter__PrintUntil (M3_ACp9GL_t=3D3D0x1d71680=2C =3D
>=3B >=3BM3_DOUx= > >Xw_mode=3D3D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb038ce90=2C =3D
>=3B >= > >=3BM3_Cwb5VA_maxL=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_CCuODf_op= > >=3D3D0x1d72c08) at =3D
>=3B >=3B../src/formatter/Formatter.m3:708<= > >=3B/div>=3B<=3Bdiv>=3B#10 0x00e3cfc9 in =3D
>=3B >=3BFormatter= > >__PrintTop (M3_B5Nhtj_self=3D3D0x1d8e00c) at =3D
>=3B >=3B../src/for= > >matter/Formatter.m3:615<=3B/div>=3B<=3Bdiv>=3B#11 0x0101f243 in =3D= > >
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c29140) at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>= > >=3B<=3Bdiv>=3B#12 0x0101ef74 in =3D
>=3B >=3BThreadPThread__Thre= > >adBase (M3_AJWxb1_param=3D3D0x1c29140) at =3D
>=3B >=3B../src/thread= > >/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#13 0x96373155 = > >in =3D
>=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#14 = > >0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv&= > >gt=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 7 (process 96727 t= > >hread =3D
>=3B >=3B0x2703):<=3B/div>=3B<=3Bdiv>=3B#0 &=3B= > >nbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<= > >=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wa= > >it ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x= > >963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnb= > >sp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self= > >=3D3D0x1d71618=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d715ec=2C M3_Bl0jv= > >4_c=3D3D0x1d715f8=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') = > >at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>= > >=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3= > >_AYIbX3_m=3D3D0x1d715ec=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1d715f8) a= > >t =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div&= > >gt=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00e3bdf2 =3D
>=3B >=3Bin Form= > >atter__Allocate (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_DBiloZ_this=3D3D1 =3D
&= > >gt=3B >=3B'\001'=2C M3_Cwb5VA_minSize=3D3D&=3Blt=3Bunknown type&=3B= > >gt=3B) at =3D
>=3B >=3B../src/formatter/Formatter.m3:440<=3B/div&g= > >t=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x00e3bf0a in =3D
>=3B >=3BForma= > >tter__Probe (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D&=3Blt=3Bunkno= > >wn =3D
>=3B >=3Btype&=3Bgt=3B) at ../src/formatter/Formatter.m3:5= > >42<=3B/div>=3B<=3Bdiv>=3B#7 =3D
>=3B >=3B&=3Bnbsp=3B0x00e= > >3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d70c90=2C =3D
>=3B >=3B= > >M3_Cwb5VA_i=3D3D&=3Blt=3Bunknown type&=3Bgt=3B) at =3D
>=3B >= > >=3B../src/formatter/Formatter.m3:592<=3B/div>=3B<=3Bdiv>=3B#8 &= > >=3Bnbsp=3B0x00e3c2ff in =3D
>=3B >=3BFormatter__PeekOp (M3_ACp9GL_t= > >=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D&=3Blt=3Bunknown =3D
>=3B >=3Bt= > >ype&=3Bgt=3B) at ../src/formatter/Formatter.m3:577<=3B/div>=3B<=3B= > >div>=3B#9 =3D
>=3B >=3B&=3Bnbsp=3B0x00e3cb25 in Formatter__Prin= > >tUntil (M3_ACp9GL_t=3D3D0x1d70c90=2C =3D
>=3B >=3BM3_DOUxXw_mode=3D3= > >D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb030ae90=2C =3D
>=3B >=3BM3_Cwb5VA_= > >maxL=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_CCuODf_op=3D3D0x1d72c08= > >) at =3D
>=3B >=3B../src/formatter/Formatter.m3:708<=3B/div>=3B&= > >lt=3Bdiv>=3B#10 0x00e3cfc9 in =3D
>=3B >=3BFormatter__PrintTop (M3= > >_B5Nhtj_self=3D3D0x1d71608) at =3D
>=3B >=3B../src/formatter/Formatt= > >er.m3:615<=3B/div>=3B<=3Bdiv>=3B#11 0x0101f243 in =3D
>=3B >= > >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c221e0) at =3D
>=3B &= > >gt=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>= > >=3B#12 0x0101ef74 in =3D
>=3B >=3BThreadPThread__ThreadBase (M3_AJWx= > >b1_param=3D3D0x1c221e0) at =3D
>=3B >=3B../src/thread/PTHREAD/Thread= > >PThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#13 0x96373155 in =3D
>= > >=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#14 0x96373012 in= > > thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr= > >>=3B<=3B/div>=3B<=3Bdiv>=3BThread 6 (process 96727 thread =3D
= > >>=3B >=3B0x2603):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x9634= > >22ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B&l= > >t=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div= > >>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pth= > >read_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189= > > =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d729bc= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d728b4=2C M3_Bl0jv4_c=3D3D0x1d72= > >9a0=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../src/thre= > >ad/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x= > >1d728b4=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1d729a0) at =3D
>=3B = > >>=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div>=3B<=3Bdiv&g= > >t=3B#5 &=3Bnbsp=3B0x0073de32 =3D
>=3B >=3Bin WorkerPool__ClericAp= > >ply (M3_BSwVRC_self=3D3D0x1d729b0) at =3D
>=3B >=3B../src/WorkerPool= > >.m3:152<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D >>>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c28e10) at =3D<= > >br>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B&= > >lt=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThr= > >ead__ThreadBase (M3_AJWxb1_param=3D3D0x1c28e10) at =3D
>=3B >=3B../s= > >rc/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &am= > >p=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>= > >=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>=3B= > > >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<= > >=3Bdiv>=3BThread 5 (process 96727 thread =3D
>=3B >=3B0x2313):<= > >=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963916fa in select$DARWIN_EX= > >TSN =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0= > >x01023503 in Unix__select (nfds=3D3D4=2C =3D
>=3B >=3Breadfds=3D3D0x= > >1d74014=2C writefds=3D3D0x1d74024=2C exceptfds=3D3D0x1d74034=2C =3D
>= > >=3B >=3Btimeout=3D3D0xb0206b20) at ../src/unix/Common/UnixC.c:301<=3B/d= > >iv>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x01020970 in T= > >hreadPThread__XIOWait__CallSelect.762 =3D
>=3B >=3B(M3_Cwb5VA_nfd=3D= > >3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_A4bqCj_timeout=3D3D0xb0206b20)= > > =3D
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:787<=3B/di= > >v>=3B<=3Bdiv>=3B#3 =3D
>=3B >=3B&=3Bnbsp=3B0x010206a8 in Th= > >readPThread__XIOWait (M3_BXP32l_self=3D3D0x1d585bc=2C =3D
>=3B >=3BM= > >3_Cwb5VA_fd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_AicXUJ_read=3D3D= > >1 '\001'=2C =3D
>=3B >=3BM3_CtKayy_interval=3D3D1.7976931348623157e+= > >308=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../src/thre= > >ad/PTHREAD/ThreadPThread.m3:823<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x010202e7 in SchedulerPosix__IOAlertWait =3D
&g= > >t=3B >=3B(M3_Cwb5VA_fd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_Aic= > >XUJ_read=3D3D1 '\001'=2C =3D
>=3B >=3BM3_CtKayy_timeoutInterval=3D3D= > >-1) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:742<=3B= > >/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00dd3cc2 =3D
>=3B >=3Bin= > > TCPMisc__Accept=3D46rom (M3_AahksS_c=3D3D0x1d58594=2C =3D
>=3B >=3B= > >M3_DoBjMZ_peer=3D3D0xb0206cb4) at ../src/POSIX/TCP.m3:458<=3B/div>=3B&l= > >t=3Bdiv>=3B#6 =3D
>=3B >=3B&=3Bnbsp=3B0x00dd3da8 in TCP__Accept= > > (M3_AahksS_c=3D3D0x1d58594) at =3D
>=3B >=3B../src/POSIX/TCP.m3:234= > ><=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x006dbc6b in =3D
>=3B= > > >=3BLocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=3D3D0x1d585b0) at =3D<= > >br>>=3B >=3B../src/LocalObjectSpace.m3:307<=3B/div>=3B<=3Bdiv>= > >=3B#8 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunThr= > >ead (M3_BeUkBA_me=3D3D0x1c28d60) at =3D
>=3B >=3B../src/thread/PTHRE= > >AD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x01= > >01ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D= > >3D0x1c28d60) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:= > >522<=3B/div>=3B<=3Bdiv>=3B#10 0x96373155 in =3D
>=3B >=3B_pt= > >hread_start ()<=3B/div>=3B<=3Bdiv>=3B#11 0x96373012 in thread_start= > > =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/= > >div>=3B<=3Bdiv>=3BThread 4 (process 96727 thread =3D
>=3B >=3B= > >0x2003):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x9634946e in __sem= > >wait_signal =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3B= > >nbsp=3B0x963492ef in nanosleep$UNIX2003 ()<=3B/div>=3B<=3Bdiv>=3B#2= > > =3D
>=3B >=3B&=3Bnbsp=3B0x01022cc4 in ThreadPThread__Nanosleep (= > >req=3D3D0xb0184dd0=2C =3D
>=3B >=3Brem=3D3D0xb0184dd8) at =3D
>= > >=3B >=3B../src/thread/PTHREAD/ThreadPThreadC.c:318<=3B/div>=3B<=3Bd= > >iv>=3B#3 &=3Bnbsp=3B0x0101fd7c =3D
>=3B >=3Bin ThreadPThread__X= > >Pause (M3_BXP32l_self=3D3D0x1d0ba08=2C M3_CtKayy_n=3D3D1=2C =3D
>=3B &= > >gt=3BM3_AicXUJ_alertable=3D3D0 '\0') at =3D
>=3B >=3B../src/thread/P= > >THREAD/ThreadPThread.m3:668<=3B/div>=3B<=3Bdiv>=3B#4 &=3Bnbsp=3B= > >0x0101fef3 =3D
>=3B >=3Bin Thread__Pause (M3_CtKayy_n=3D3D1) at =3D<= > >br>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:685<=3B/div>=3B&= > >lt=3Bdiv>=3B#5 &=3Bnbsp=3B0x00a11d53 =3D
>=3B >=3Bin FileBrowse= > >rVBT__Watcher (M3_EMTrVz_cl=3D3D0x1d0ba00) at =3D
>=3B >=3B../src/le= > >go/FileBrowserVBT.m3:259<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0= > >101f243 in =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0= > >x1c21830) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546= > ><=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B &g= > >t=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21830) at =3D
= > >>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<= > >=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_sta= > >rt ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_s= > >tart =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<= > >=3B/div>=3B<=3Bdiv>=3BThread 3 (process 96727 thread =3D
>=3B &g= > >t=3B0x1f03):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in s= > >emaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv&g= > >t=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<= > >=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond= > >_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
&= > >gt=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d090d4=2C =3D >>>=3B >=3BM3_AYIbX3_m=3D3D0x1d090b0=2C M3_Bl0jv4_c=3D3D0x1d090bc=2C M3_= > >AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/T= > >hreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&a= > >mp=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d090b0=2C =3D >>>=3B >=3BM3_Bl0jv4_c=3D3D0x1d090bc) at =3D
>=3B >=3B../src/thre= > >ad/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbs= > >p=3B0x00a839e2 =3D
>=3B >=3Bin VTView__VFontCleanUpThread (M3_EMTrVz= > >_cl=3D3D0x1d090cc) at =3D
>=3B >=3B../src/vtext/VTView.m3:111<=3B/= > >div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3B= > >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21310) at =3D
>=3B >= > >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>= > >=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__Thread= > >Base (M3_AJWxb1_param=3D3D0x1c21310) at =3D
>=3B >=3B../src/thread/P= > >THREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B= > >0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdi= > >v>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>=3B >=3B()&l= > >t=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BT= > >hread 2 (process 96727 thread =3D
>=3B >=3B0xd07):<=3B/div>=3B&l= > >t=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D<= > >br>>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c= > >6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B &= > >gt=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3B= > >div>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__= > >XWait (M3_BXP32l_self=3D3D0x1d006c8=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D= > >0x1d00688=2C M3_Bl0jv4_c=3D3D0x1d00694=2C M3_AicXUJ_alertable=3D3D0 =3D
= > >>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div&= > >gt=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823 in Thre= > >ad__Wait (M3_AYIbX3_m=3D3D0x1d00688=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D= > >0x1d00694) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:27= > >7<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00bf33d2 =3D
>=3B &= > >gt=3Bin VBTRep__MeterMaid (M3_EMTrVz_self=3D3D0x1d006bc) at =3D
>=3B &= > >gt=3B../src/vbt/VBTRep.m3:439<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp= > >=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me= > >=3D3D0x1c21390) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.= > >m3:546<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>= > >=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21390) at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>= > >=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthre= > >ad_start ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in th= > >read_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>= > >=3B<=3B/div>=3B<=3Bdiv>=3BThread 1 (process 96727 thread =3D
>= > >=3B >=3B0x10b):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce= > > in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3B= > >div>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>= > >=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthrea= > >d_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 = > >=3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d0000c= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1df3= > >114=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread= > >/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d005= > >00=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1df3114) at =3D
>=3B >= > >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>= > >=3B#5 &=3Bnbsp=3B0x00c40602 =3D
>=3B >=3Bin Trestle__AwaitDelete = > >(M3_BFdKo9_v=3D3D0x1e3a204) at =3D
>=3B >=3B../src/trestle/Trestle.m= > >3:884<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x007c09eb in =3D
&= > >gt=3B >=3BZeusPanel__Interact (M3_Bd56fi_title=3D3D0x290db0=2C =3D
>= > >=3B >=3BM3_DYb95R_path=3D3D0x1d498c0) at ../src/ZeusPanel.m3:477<=3B/di= > >v>=3B<=3Bdiv>=3B#7 =3D
>=3B >=3B&=3Bnbsp=3B0x001b0ede in Ma= > >in_M3 (M3_AcxOUs_mode=3D3D1) at =3D
>=3B >=3B../src/Main.m3:165<= > >=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x0100eb1f in =3D
>=3B &g= > >t=3BRTLinker__RunMainBody (M3_DjPxE3_m=3D3D0x1d6060) at =3D
>=3B >= > >=3B../src/runtime/common/RTLinker.m3:399<=3B/div>=3B<=3Bdiv>=3B#9 &= > >amp=3Bnbsp=3B0x00002578 in =3D
>=3B >=3Bmain (argc=3D3D1=2C argv=3D3= > >D0xbfffedb8=2C envp=3D3D0xbfffedc0) at =3D
>=3B >=3B_m3main.mc:6<= > >=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3B/div>=3B&= > >lt=3Bdiv>=3B<=3Bbr>=3B<=3Bdiv>=3B <=3Bspan =3D
>=3B >=3B= > >class=3D3D"Apple-style-span" style=3D3D"font-size: 12px=3B ">=3B<=3Bdiv= > > =3D
>=3B >=3Bstyle=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode:= > > space=3B =3D
>=3B >=3B-webkit-line-break: after-white-space=3B ">= > >=3B<=3Bspan class=3D3D"Apple-style-span" =3D
>=3B >=3Bstyle=3D3D"b= > >order-collapse: separate=3B -webkit-border-horizontal-spacing: =3D
>= > >=3B >=3B0px=3B -webkit-border-vertical-spacing: 0px=3B color: rgb(0=2C 0= > >=2C 0)=3B =3D
>=3B >=3Bfont-family: Helvetica=3B font-size: 12px=3B = > >font-style: normal=3B =3D
>=3B >=3Bfont-variant: normal=3B font-weig= > >ht: normal=3B letter-spacing: normal=3B =3D
>=3B >=3Bline-height: no= > >rmal=3B -webkit-text-decorations-in-effect: none=3B =3D
>=3B >=3Btex= > >t-indent: 0px=3B -webkit-text-size-adjust: auto=3B text-transform: none=3B = > >=3D
>=3B >=3Borphans: 2=3B white-space: normal=3B widows: 2=3B word-= > >spacing: 0px=3B ">=3B<=3Bdiv =3D
>=3B >=3Bstyle=3D3D"word-wrap: = > >break-word=3B -webkit-nbsp-mode: space=3B =3D
>=3B >=3B-webkit-line-= > >break: after-white-space=3B ">=3B<=3Bspan class=3D3D"Apple-style-span" = > >=3D
>=3B >=3Bstyle=3D3D"border-collapse: separate=3B -webkit-border-= > >horizontal-spacing: =3D
>=3B >=3B0px=3B -webkit-border-vertical-spac= > >ing: 0px=3B color: rgb(0=2C 0=2C 0)=3B =3D
>=3B >=3Bfont-family: Hel= > >vetica=3B font-size: 12px=3B font-style: normal=3B =3D
>=3B >=3Bfont= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B =3D >>>=3B >=3Bline-height: normal=3B -webkit-text-decorations-in-effect: no= > >ne=3B =3D
>=3B >=3Btext-indent: 0px=3B -webkit-text-size-adjust: aut= > >o=3B text-transform: none=3B =3D
>=3B >=3Borphans: 2=3B white-space:= > > normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
>= > >=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separate= > >=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webkit-b= > >order-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-sp= > >an" style=3D3D"border-collapse: separate=3B =3D
>=3B >=3B-webkit-bor= > >der-horizontal-spacing: 0px=3B -webkit-border-vertical-spacing: =3D
>= > >=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-= > >size: 12px=3B =3D
>=3B >=3Bfont-style: normal=3B font-variant: norma= > >l=3B font-weight: normal=3B =3D
>=3B >=3Bletter-spacing: normal=3B l= > >ine-height: normal=3B =3D
>=3B >=3B-webkit-text-decorations-in-effec= > >t: none=3B text-indent: 0px=3B =3D
>=3B >=3B-webkit-text-size-adjust= > >: auto=3B text-transform: none=3B orphans: 2=3B =3D
>=3B >=3Bwhite-s= > >pace: normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
= > >>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separ= > >ate=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webki= > >t-border-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont= > >-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-sp= > >an" style=3D3D"border-collapse: separate=3B =3D
>=3B >=3B-webkit-bor= > >der-horizontal-spacing: 0px=3B -webkit-border-vertical-spacing: =3D
>= > >=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-= > >size: 12px=3B =3D
>=3B >=3Bfont-style: normal=3B font-variant: norma= > >l=3B font-weight: normal=3B =3D
>=3B >=3Bletter-spacing: normal=3B l= > >ine-height: normal=3B =3D
>=3B >=3B-webkit-text-decorations-in-effec= > >t: none=3B text-indent: 0px=3B =3D
>=3B >=3B-webkit-text-size-adjust= > >: auto=3B text-transform: none=3B orphans: 2=3B =3D
>=3B >=3Bwhite-s= > >pace: normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
= > >>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separ= > >ate=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webki= > >t-border-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont= > >-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-sp= > >an" style=3D3D"border-collapse: separate=3B =3D
>=3B >=3B-webkit-bor= > >der-horizontal-spacing: 0px=3B -webkit-border-vertical-spacing: =3D
>= > >=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-= > >size: 12px=3B =3D
>=3B >=3Bfont-style: normal=3B font-variant: norma= > >l=3B font-weight: normal=3B =3D
>=3B >=3Bletter-spacing: normal=3B l= > >ine-height: normal=3B =3D
>=3B >=3B-webkit-text-decorations-in-effec= > >t: none=3B text-indent: 0px=3B =3D
>=3B >=3B-webkit-text-size-adjust= > >: auto=3B text-transform: none=3B orphans: 2=3B =3D
>=3B >=3Bwhite-s= > >pace: normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
= > >>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separ= > >ate=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webki= > >t-border-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont= > >-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bdiv>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D= > >"Apple-style-span" color=3D3D"#0000FF">=3B<=3Bfont =3D
>=3B >=3B= > >class=3D3D"Apple-style-span" face=3D3D"Gill Sans">=3B<=3Bspan =3D
&g= > >t=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255= > >)=3B font-family: =3D
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan clas= > >s=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C =3D
>=3B >=3B0= > >=2C 255)=3B font-family: 'Gill Sans'=3B ">=3BAntony =3D
>=3B >=3BH= > >osking<=3B/span>=3B<=3B/span>=3B<=3B/font>=3B<=3B/font>=3B&= > >lt=3Bfont class=3D3D"Apple-style-span" =3D
>=3B >=3Bface=3D3D"Gill S= > >ans">=3B<=3Bspan class=3D3D"Apple-style-span" style=3D3D"font-family: = > >=3D
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan class=3D3D"Apple-style= > >-span" style=3D3D"font-family: =3D
>=3B >=3B'Gill Sans'=3B ">=3B&l= > >t=3Bspan class=3D3D"Apple-converted-space">=3B&=3Bnbsp=3B<=3B/span&g= > >t=3B|<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-converted-space">=3B= > >&=3Bnbsp=3B<=3B/span>=3B<=3B/span>=3B<=3B/span>=3B<=3Bspan= > > =3D
>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"font-family: '= > >Gill Sans'=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-= > >span" style=3D3D"font-family: 'Gill Sans'=3B =3D
>=3B >=3B">=3BAss= > >ociate Professor<=3B/span>=3B<=3B/span>=3B<=3Bspan class=3D3D"App= > >le-style-span" =3D
>=3B >=3Bstyle=3D3D"font-family: 'Gill Sans'=3B "= > >>=3B<=3Bspan class=3D3D"Apple-style-span" =3D
>=3B >=3Bstyle=3D3= > >D"font-family: 'Gill Sans'=3B ">=3B&=3Bnbsp=3B| Computer Science | Pur= > >due =3D
>=3B >=3BUniversity<=3B/span>=3B<=3B/span>=3B<=3B/= > >font>=3B<=3B/div>=3B<=3Bdiv>=3B<=3Bfont class=3D3D"Apple-style-= > >span"=3D
>=3B >=3B face=3D3D"GillSans-Light">=3B<=3Bspan class= > >=3D3D"Apple-style-span" =3D
>=3B >=3Bstyle=3D3D"font-family: GillSan= > >s-Light=3B ">=3B305 N. University Street | West =3D
>=3B >=3BLafay= > >ette | IN 47907 | USA<=3B/span>=3B<=3B/font>=3B<=3B/div>=3B<= > >=3Bdiv>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" col= > >or=3D3D"#0000FF" face=3D3D"Gill Sans">=3B<=3Bspan =3D
>=3B >=3Bc= > >lass=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B font-fa= > >mily: =3D
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan class=3D3D"Apple= > >-style-span" style=3D3D"color: rgb(0=2C =3D
>=3B >=3B0=2C 255)=3B fo= > >nt-family: 'Gill Sans'=3B ">=3BOffice<=3B/span>=3B<=3B/span>=3B&l= > >t=3B/font>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" = > >face=3D3D"GillSans-Light">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Ap= > >ple-style-span" style=3D3D"font-family: GillSans-Light=3B ">=3B<=3Bspan= > > =3D
>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"font-family: G= > >illSans-Light=3B =3D
>=3B >=3B">=3B&=3Bnbsp=3B+1 765 494 6001 |= > ><=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-converted-space">=3B&= > >=3Bnbsp=3B<=3B/span>=3B<=3B/span>=3B<=3B/span>=3B<=3B/font>= > >=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" color=3D3D"#= > >0000FF" face=3D3D"Gill Sans">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D= > >"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B font-family: =3D= > >
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan class=3D3D"Apple-style-sp= > >an" style=3D3D"color: rgb(0=2C =3D
>=3B >=3B0=2C 255)=3B font-family= > >: 'Gill Sans'=3B ">=3BMobile<=3B/span>=3B<=3B/span>=3B<=3B/font= > >>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" face=3D3D= > >"GillSans-Light">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style= > >-span" style=3D3D"font-family: GillSans-Light=3B ">=3B<=3Bspan =3D
&= > >gt=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-L= > >ight=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-converted-sp= > >ace">=3B&=3Bnbsp=3B<=3B/span>=3B+1 765 427 =3D
>=3B >=3B548= > >4<=3B/span>=3B<=3B/span>=3B<=3B/font>=3B<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bfont class=3D3D"Apple-style-span" =3D
>=3B >=3Bface=3D= > >3D"GillSans-Light">=3B<=3Bbr =3D
>=3B >=3Bclass=3D3D"khtml-block= > >-placeholder">=3B<=3B/font>=3B<=3B/div>=3B<=3B/span>=3B<=3B= > >/span>=3B<=3B/span>=3B<=3B/span=3D
>=3B >=3B>=3B<=3B/spa= > >n>=3B<=3B/span>=3B<=3B/span>=3B<=3Bbr =3D
>=3B >=3Bclass= > >=3D3D"Apple-interchange-newline">=3B<=3B/span>=3B<=3B/div>=3B<= > >=3B/span>=3B<=3B/div>=3B<=3B/span>=3B<=3Bbr =3D
>=3B >= > >=3Bclass=3D3D"Apple-interchange-newline">=3B <=3B/div>=3B<=3Bbr>= > >=3B<=3Bdiv>=3B<=3Bdiv>=3BOn 6 Sep 2009=2C =3D
>=3B >=3Bat 23= > >:18=2C Jay K wrote:<=3B/div>=3B<=3Bbr =3D
>=3B >=3Bclass=3D3D"= > >Apple-interchange-newline">=3B<=3Bblockquote =3D
>=3B >=3Btype= > >=3D3D"cite">=3B<=3Bdiv>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B&= > >lt=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3B= > >br>=3B[was truncated =3D
>=3B >=3Bagain!]<=3Bbr>=3B<=3Bbr>= > >=3BPPC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes =3D
>=3B = > >>=3Bruns out of stack<=3B/div>=3B<=3B/blockquote>=3B<=3B/div>= > >=3B<=3Bbr>=3B<=3B/div>=3B<=3B/body>=3B<=3B/html>=3B=3D
&= > >gt=3B >=3B
>=3B >=3B--Apple-Mail-13--794937978--
> >= > > > >--_d2a2b05c-dd99-4149-b3de-8867976ffb79_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 13:17:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 11:17:48 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Can a semaphore be reasonably synthesized from working pthreads constructs? At least to try eliminating this variable? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 10:07:16 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) > What is different about Darwin? > Well obviously the same world suspend works. Can we use the portable way instead?? sem_init returns ENOSYS on Darwin, so no. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 16:09:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 10:09:25 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote: > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 16:44:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 10:44:23 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: <07AC4F22-8D60-4A08-AF4B-5B058B1FE72B@cs.purdue.edu> On 8 Sep 2009, at 04:50, Jay K wrote: > Hm. > - Making SameHost FALSE on Linux didn't induce hang. > - I'm seeing Juno often "hang" for a few seconds without displaying > anything, but I wait, and then it comes up fine. And then the next > run works ok. I see both behaviors often. This is with the stack > size code removed from ThreadPThreadC.c. I'll try restoring it too. > > What is different about Darwin? > Well obviously the same world suspend works. Can we use the portable > way instead?? > I realize the portable way probably isn't as good? This is not a problem with the stop-the-world mechanisms. They work fine. I've stress-tested them heavily and not seen a problem in a long time. My recent changes just made it clearer what was going on (and fixed the bug I introduced last week that you ended up backing out). If you look at the stack traces, no thread is in stop-the-world code. I have a sneaking recollection of needing to configure some property of my X server on Darwin, way back when. I've tried searching the old mail logs to see if I can dig up a reference but the Zope archives are no longer on Elegosoft.com. What to do? > > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other > problems) > Date: Tue, 8 Sep 2009 08:16:41 +0000 > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 16:47:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 10:47:18 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: It is not a problem with the thread stop-the-world suspension code. No thread is in that path at the time of the hang. They are all quietly waiting for something to happen. Clearly they've missed something. I have one thread that looks suspicious sitting inside a call to Formatter__Flush. Clearly the consumer hasn't responded so it is quietly waiting. More investigation needed. On 8 Sep 2009, at 07:17, Jay K wrote: > Can a semaphore be reasonably synthesized from working pthreads > constructs? > At least to try eliminating this variable? > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 8 Sep 2009 10:07:16 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > > What is different about Darwin? > > Well obviously the same world suspend works. Can we use the > portable way instead?? > > sem_init returns ENOSYS on Darwin, so no. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other > problems) > Date: Tue, 8 Sep 2009 08:16:41 +0000 > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 17:51:36 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 8 Sep 2009 08:51:36 -0700 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/ XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: > What did you change? I wonder... > > To get things to work on Darwin I used to have to do "xhosts +" and > set "DISPLAY=:0.0". Is this no longer the case? > > On 8 Sep 2009, at 04:16, Jay K wrote: > >> Here is a wild wild guess: >> One thing unusual to Trestle on Darwin, I think, is that it always >> appears that X client and X server are different machines. >> Well, er, um, that is how I changed it to be when it was otherwise >> always going to fail. >> How did it work previously? However it did work, if those >> conditions are still present, it still has a chance of working. >> >> Coincidentally or not, the formsedit crashes I have reported are >> all/mostly with a separate X client and server. >> >> I'll see if I can induce a hang in the otherwise working LINUXLIBC6 >> by twiddling with this. >> >> The specific change I made in Darwin was in the IsSameHost code. >> Where it would previously hit an unhandled exception, I have it >> return FALSE. >> I'm pretty sure that using XSharedMemory is "just" an optimization, >> albeit a very good one. >> >> I looked at little at what the Juno threads are doing..and it >> doesn't really have to do with gui code. >> libm3/"formatter" is a usual producer/consumer thingy, signal when >> queue is empty or nonempty. >> We /might/ be able to demonstrate this hang without any of Trestle >> in the picture. Might. >> >> I haven't looked at Mentor but it looks more complicated below. >> I'll also see if the Juno NT crashes are gone. >> And I'll raise the stack but stack overflow is just another wild >> guess, right? >> >> On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack >> overflow. >> I raised the stack piecemeal up to 32meg, still overflow. At 64meg >> it ran out of memory. >> >> - Jay >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 8 Sep 2009 02:09:28 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other >> problems) >> >> Here's the hang backtrace for mentor. Again, all appears normal, >> except that all the threads are paused or waiting, which is >> suspicious. I'm stumped for now. >> >> Thread 21 (process 96727 thread 0x7403): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, >> rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:668 >> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:685 >> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) >> at ../src/xvbt/XClientF.m3:105 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 20 (process 96727 thread 0x7103): >> #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:319 >> #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, >> M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') >> at ../src/thread/PTHREAD/ThreadPThread.m3:669 >> #2 0x01020024 in Thread__AlertPause >> (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:699 >> #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, >> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) >> at ../src/Animate.m3:71 >> #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, >> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >> #5 0x008921f9 in GraphVBT__AnimateGraph >> (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../ >> src/GraphVBT.m3:656 >> #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, >> M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) >> at ../src/bresenham/ViewError.m3:548 >> #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, >> M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 >> #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ >> src/Zeus.m3:331 >> #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #10 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #11 0x96373155 in _pthread_start () >> #12 0x96373012 in thread_start () >> >> Thread 19 (process 96727 thread 0x5d07): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, >> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >> M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, >> M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ >> src/Zeus.m3:328 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 18 (process 96727 thread 0x700b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, >> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >> M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, >> M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ >> src/Zeus.m3:328 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 17 (process 96727 thread 0x6e03): >> #0 0x963493dc in _pthread_testcancel () >> #1 0x96349275 in nanosleep$UNIX2003 () >> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, >> rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, >> M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >> PTHREAD/ThreadPThread.m3:668 >> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:685 >> #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ >> src/vtext/VTCaret.m3:149 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 16 (process 96727 thread 0x435b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, >> M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, >> M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) >> at ../src/ZeusPanel.m3:1425 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 15 (process 96727 thread 0x420b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) >> at ../src/View.m3:74 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 14 (process 96727 thread 0x4103): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) >> at ../src/View.m3:74 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 13 (process 96727 thread 0x4003): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) >> at ../src/View.m3:74 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 12 (process 96727 thread 0x2e03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, >> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >> M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) >> at ../src/xvbt/XMessenger.m3:69 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 11 (process 96727 thread 0x2b07): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, >> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >> M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) >> at ../src/xvbt/XInput.m3:102 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 10 (process 96727 thread 0x2a23): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, >> writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/ >> unix/Common/UnixC.c:301 >> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:787 >> #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >> M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >> PTHREAD/ThreadPThread.m3:826 >> #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=> type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ >> src/thread/PTHREAD/ThreadPThread.m3:729 >> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) >> at ../src/xvbt/XInput.m3:63 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 9 (process 96727 thread 0x29f3): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, >> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, >> M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, >> M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 >> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, >> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 >> #7 0x000149a7 in BresenhamIE__ShowPixel >> (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, >> M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 >> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, >> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >> at ../src/bresenham/AlgBresenham.m3:55 >> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ >> src/bresenham/AlgBresenham.m3:86 >> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) >> at ../src/ZeusPanel.m3:1534 >> #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #12 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 8 (process 96727 thread 0x2803): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, >> M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, >> M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >> src/formatter/Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, >> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >> formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) >> at ../src/formatter/Formatter.m3:615 >> #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #12 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 7 (process 96727 thread 0x2703): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, >> M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, >> M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >> src/formatter/Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, >> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >> formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) >> at ../src/formatter/Formatter.m3:615 >> #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #12 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 6 (process 96727 thread 0x2603): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, >> M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, >> M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x0073de32 in WorkerPool__ClericApply >> (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 5 (process 96727 thread 0x2313): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, >> writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ >> src/unix/Common/UnixC.c:301 >> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ >> src/thread/PTHREAD/ThreadPThread.m3:787 >> #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 >> #4 0x010202e7 in SchedulerPosix__IOAlertWait >> (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >> M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:742 >> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, >> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ >> POSIX/TCP.m3:234 >> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >> (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 >> #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #9 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #10 0x96373155 in _pthread_start () >> #11 0x96373012 in thread_start () >> >> Thread 4 (process 96727 thread 0x2003): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, >> rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:668 >> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:685 >> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) >> at ../src/lego/FileBrowserVBT.m3:259 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 3 (process 96727 thread 0x1f03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, >> M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, >> M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00a839e2 in VTView__VFontCleanUpThread >> (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 2 (process 96727 thread 0xd07): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, >> M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, >> M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) >> at ../src/vbt/VBTRep.m3:439 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 1 (process 96727 thread 0x10b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >> M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 >> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >> #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) >> at ../src/runtime/common/RTLinker.m3:399 >> #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) >> at _m3main.mc:6 >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 6 Sep 2009, at 23:18, Jay K wrote: >> >> >> >> >> >> >> >> >> >> >> [was truncated again!] >> >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of >> stack >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 18:03:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 12:03:05 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> Message-ID: <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote: > That works? $Display gets set to something random looking by > default, an actual file, I don't change it. If what you do works my > change probably does not affect. See the function SameHost in m3-ui/ > ui/xvbt/XSharedMemory.i3. I added the code to predict if the network > stuff will succeed or fail since for me it always failed and was > fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. > > - Jay (phone) > > On Sep 8, 2009, at 7:09 AM, Tony Hosking > wrote: > >> What did you change? I wonder... >> >> To get things to work on Darwin I used to have to do "xhosts +" and >> set "DISPLAY=:0.0". Is this no longer the case? >> >> On 8 Sep 2009, at 04:16, Jay K wrote: >> >>> Here is a wild wild guess: >>> One thing unusual to Trestle on Darwin, I think, is that it >>> always appears that X client and X server are different machines. >>> Well, er, um, that is how I changed it to be when it was >>> otherwise always going to fail. >>> How did it work previously? However it did work, if those >>> conditions are still present, it still has a chance of working. >>> >>> Coincidentally or not, the formsedit crashes I have reported are >>> all/mostly with a separate X client and server. >>> >>> I'll see if I can induce a hang in the otherwise working >>> LINUXLIBC6 by twiddling with this. >>> >>> The specific change I made in Darwin was in the IsSameHost code. >>> Where it would previously hit an unhandled exception, I have it >>> return FALSE. >>> I'm pretty sure that using XSharedMemory is "just" an >>> optimization, albeit a very good one. >>> >>> I looked at little at what the Juno threads are doing..and it >>> doesn't really have to do with gui code. >>> libm3/"formatter" is a usual producer/consumer thingy, signal when >>> queue is empty or nonempty. >>> We /might/ be able to demonstrate this hang without any of Trestle >>> in the picture. Might. >>> >>> I haven't looked at Mentor but it looks more complicated below. >>> I'll also see if the Juno NT crashes are gone. >>> And I'll raise the stack but stack overflow is just another wild >>> guess, right? >>> >>> On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack >>> overflow. >>> I raised the stack piecemeal up to 32meg, still overflow. At 64meg >>> it ran out of memory. >>> >>> - Jay >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 8 Sep 2009 02:09:28 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other >>> problems) >>> >>> Here's the hang backtrace for mentor. Again, all appears normal, >>> except that all the threads are paused or waiting, which is >>> suspicious. I'm stumped for now. >>> >>> Thread 21 (process 96727 thread 0x7403): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, >>> rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:668 >>> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:685 >>> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) >>> at ../src/xvbt/XClientF.m3:105 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 20 (process 96727 thread 0x7103): >>> #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:319 >>> #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, >>> M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') >>> at ../src/thread/PTHREAD/ThreadPThread.m3:669 >>> #2 0x01020024 in Thread__AlertPause >>> (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:699 >>> #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, >>> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) >>> at ../src/Animate.m3:71 >>> #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, >>> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >>> #5 0x008921f9 in GraphVBT__AnimateGraph >>> (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../ >>> src/GraphVBT.m3:656 >>> #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, >>> M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) >>> at ../src/bresenham/ViewError.m3:548 >>> #7 0x0001529a in BresenhamIE__OEDispatcher >>> (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/ >>> BresenhamIE.m3:101 >>> #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) >>> at ../src/Zeus.m3:331 >>> #9 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #10 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #11 0x96373155 in _pthread_start () >>> #12 0x96373012 in thread_start () >>> >>> Thread 19 (process 96727 thread 0x5d07): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, >>> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >>> M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep >>> (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/ >>> Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) >>> at ../src/Zeus.m3:328 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 18 (process 96727 thread 0x700b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, >>> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >>> M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep >>> (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/ >>> Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) >>> at ../src/Zeus.m3:328 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 17 (process 96727 thread 0x6e03): >>> #0 0x963493dc in _pthread_testcancel () >>> #1 0x96349275 in nanosleep$UNIX2003 () >>> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, >>> rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, >>> M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:668 >>> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:685 >>> #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ >>> src/vtext/VTCaret.m3:149 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 16 (process 96727 thread 0x435b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, >>> M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, >>> M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) >>> at ../src/ZeusPanel.m3:1425 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 15 (process 96727 thread 0x420b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) >>> at ../src/View.m3:74 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 14 (process 96727 thread 0x4103): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) >>> at ../src/View.m3:74 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 13 (process 96727 thread 0x4003): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) >>> at ../src/View.m3:74 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 12 (process 96727 thread 0x2e03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, >>> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >>> M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) >>> at ../src/xvbt/XMessenger.m3:69 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 11 (process 96727 thread 0x2b07): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, >>> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >>> M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) >>> at ../src/xvbt/XInput.m3:102 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 10 (process 96727 thread 0x2a23): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, >>> writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/ >>> unix/Common/UnixC.c:301 >>> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:787 >>> #3 0x010206cc in ThreadPThread__XIOWait >>> (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:826 >>> #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=>> type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:729 >>> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) >>> at ../src/xvbt/XInput.m3:63 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 9 (process 96727 thread 0x29f3): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, >>> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, >>> M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, >>> M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 >>> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, >>> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >>> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 >>> #7 0x000149a7 in BresenhamIE__ShowPixel >>> (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, >>> M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/ >>> BresenhamIE.m3:227 >>> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, >>> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >>> at ../src/bresenham/AlgBresenham.m3:55 >>> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) >>> at ../src/bresenham/AlgBresenham.m3:86 >>> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) >>> at ../src/ZeusPanel.m3:1534 >>> #11 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #12 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 8 (process 96727 thread 0x2803): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, >>> M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, >>> M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >>> src/formatter/Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, >>> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >>> formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #12 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 7 (process 96727 thread 0x2703): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, >>> M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, >>> M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >>> src/formatter/Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, >>> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >>> formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #12 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 6 (process 96727 thread 0x2603): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, >>> M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, >>> M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x0073de32 in WorkerPool__ClericApply >>> (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 5 (process 96727 thread 0x2313): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, >>> writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ >>> src/unix/Common/UnixC.c:301 >>> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ >>> src/thread/PTHREAD/ThreadPThread.m3:787 >>> #3 0x010206a8 in ThreadPThread__XIOWait >>> (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e >>> +308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:823 >>> #4 0x010202e7 in SchedulerPosix__IOAlertWait >>> (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >>> M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:742 >>> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, >>> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >>> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ >>> POSIX/TCP.m3:234 >>> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >>> (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 >>> #8 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #9 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #10 0x96373155 in _pthread_start () >>> #11 0x96373012 in thread_start () >>> >>> Thread 4 (process 96727 thread 0x2003): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, >>> rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:668 >>> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:685 >>> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) >>> at ../src/lego/FileBrowserVBT.m3:259 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 3 (process 96727 thread 0x1f03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, >>> M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, >>> M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00a839e2 in VTView__VFontCleanUpThread >>> (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 2 (process 96727 thread 0xd07): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, >>> M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, >>> M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) >>> at ../src/vbt/VBTRep.m3:439 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 1 (process 96727 thread 0x10b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >>> M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 >>> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >>> #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) >>> at ../src/runtime/common/RTLinker.m3:399 >>> #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) >>> at _m3main.mc:6 >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 6 Sep 2009, at 23:18, Jay K wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [was truncated again!] >>> >>> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out >>> of stack >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 18:05:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 16:05:48 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: Ok I tried Display=:0.0 and xhost +, it works, same hang. You don't actually have to do that though, at least on 10.5. DISPLAY is set to some magic and X is started up on-demand as needed. Except for that SameHost problem.. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 12:03:05 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote:That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote:Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 18:09:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 16:09:21 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO self.waitCond should be c or self.waitingOn maybe?? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 16:05:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Ok I tried Display=:0.0 and xhost +, it works, same hang. You don't actually have to do that though, at least on 10.5. DISPLAY is set to some magic and X is started up on-demand as needed. Except for that SameHost problem.. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 12:03:05 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote:That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote:Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 18:11:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 12:11:23 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: Nope. I think we need to be more careful about the mutex. Considering the options right now... On 8 Sep 2009, at 12:09, Jay K wrote: > WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO > > > self.waitCond should be c or self.waitingOn maybe?? > > - Jay > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 8 Sep 2009 16:05:48 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Ok I tried Display=:0.0 and xhost +, it works, same hang. > You don't actually have to do that though, at least on 10.5. > DISPLAY is set to some magic and X is started up on-demand as needed. > Except for that SameHost problem.. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 12:03:05 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote: > > That works? $Display gets set to something random looking by > default, an actual file, I don't change it. If what you do works my > change probably does not affect. See the function SameHost in m3-ui/ > ui/xvbt/XSharedMemory.i3. I added the code to predict if the network > stuff will succeed or fail since for me it always failed and was > fatal. > > Yes, it works for me. > > PS I think I have found the problem: a thread not waking from a call > to wait, even though its condition has been signalled. A > longstanding bug inside XWait I think... Sigh. > > > - Jay (phone) > > On Sep 8, 2009, at 7:09 AM, Tony Hosking > wrote: > > What did you change? I wonder... > > To get things to work on Darwin I used to have to do "xhosts +" and > set "DISPLAY=:0.0". Is this no longer the case? > > On 8 Sep 2009, at 04:16, Jay K wrote: > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 18:13:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 16:13:36 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: er..I don't get the waitCond vs. waitingOn. Have to study it more or just wait for your fix. Maybe they are meant to be the same??? I don't know. (To be clear, with this level of uncertainty, I'm certainly not changing it.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 16:09:21 +0000 WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO self.waitCond should be c or self.waitingOn maybe?? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 16:05:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Ok I tried Display=:0.0 and xhost +, it works, same hang. You don't actually have to do that though, at least on 10.5. DISPLAY is set to some magic and X is started up on-demand as needed. Except for that SameHost problem.. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 12:03:05 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote:That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote:Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 18:23:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 12:23:56 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: <034E072F-DFA2-43D5-A925-A60FABF60169@cs.purdue.edu> Every thread has a waitCond, which is where we park it when it waits on a condition variable. To alert a thread we can simply signal its waitCond. This avoids having to broadcast on all of the threads waiting on a condition just to get the alerted one to notice. waitingOn is the M3 CV that it is waiting on, which is where the condition wait queue resides. On 8 Sep 2009, at 12:13, Jay K wrote: > er..I don't get the waitCond vs. waitingOn. Have to study it more or > just wait for your fix. > Maybe they are meant to be the same??? I don't know. > (To be clear, with this level of uncertainty, I'm certainly not > changing it.) > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other > problems) > Date: Tue, 8 Sep 2009 16:09:21 +0000 > > WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO > > > self.waitCond should be c or self.waitingOn maybe?? > > - Jay > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 8 Sep 2009 16:05:48 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Ok I tried Display=:0.0 and xhost +, it works, same hang. > You don't actually have to do that though, at least on 10.5. > DISPLAY is set to some magic and X is started up on-demand as needed. > Except for that SameHost problem.. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 12:03:05 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote: > > That works? $Display gets set to something random looking by > default, an actual file, I don't change it. If what you do works my > change probably does not affect. See the function SameHost in m3-ui/ > ui/xvbt/XSharedMemory.i3. I added the code to predict if the network > stuff will succeed or fail since for me it always failed and was > fatal. > > Yes, it works for me. > > PS I think I have found the problem: a thread not waking from a call > to wait, even though its condition has been signalled. A > longstanding bug inside XWait I think... Sigh. > > > - Jay (phone) > > On Sep 8, 2009, at 7:09 AM, Tony Hosking > wrote: > > What did you change? I wonder... > > To get things to work on Darwin I used to have to do "xhosts +" and > set "DISPLAY=:0.0". Is this no longer the case? > > On 8 Sep 2009, at 04:16, Jay K wrote: > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Wed Sep 9 22:12:57 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 09 Sep 2009 15:12:57 -0500 Subject: [M3devel] Modula-3 page that's actually up to date Message-ID: <4AA80C49.4040006@esoteriq.org> I just found this website: http://www.eiserloh.org/~peter/modula3/ and was amazed to see it's up to date. Nice little collection of links there. From mbishop at esoteriq.org Wed Sep 9 22:19:32 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 09 Sep 2009 15:19:32 -0500 Subject: [M3devel] Quake problem installing packages Message-ID: <4AA80DD4.3060209@esoteriq.org> Installing some of the packages (Math, some of m3devtools and devlib so far) result in this error: quake runtime error: undefined variable: symbolic_link_file Always the same problem, "undefined variable: symbolic_link_file" in .M3SHIP From mbishop at esoteriq.org Wed Sep 9 22:39:40 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 09 Sep 2009 15:39:40 -0500 Subject: [M3devel] Quake problem installing packages In-Reply-To: <4AA80DD4.3060209@esoteriq.org> References: <4AA80DD4.3060209@esoteriq.org> Message-ID: <4AA8128C.1040403@esoteriq.org> Sorry, diregard this, somehow my system is still using an old CM3 instead of 5.8. Sorry. Martin Bishop wrote: > Installing some of the packages (Math, some of m3devtools and devlib > so far) result in > this error: > > > quake runtime error: undefined variable: symbolic_link_file > > > Always the same problem, "undefined variable: symbolic_link_file" in > .M3SHIP > > From hosking at cs.purdue.edu Fri Sep 11 15:45:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Message-ID: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 16:24:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 14:24:06 +0000 Subject: [M3devel] RC merge In-Reply-To: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Fri Sep 11 18:14:07 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 11 Sep 2009 18:14:07 +0200 Subject: [M3devel] elego Maintenance 12.09 Message-ID: <20090911181407.vk17th56tc4c4k4s@mail.elego.de> Hello, On Saturday, Sept. 12 from 10 AM to 4 PM CEST, we will be performing maintenance at our Gustav-Meyer-Allee site. Among other planned procedures, a UPS battery replacement will require taking the following servers completely off line for approximately one hour: -new.elego.de -old.elego.de -fedora.elego.de -bdc1.elego.de -willow.elego.de -pine.elego.de The ESXi server madrona and its hosts will not be affected by this. The elego lan will be unreachable during the battery replacement and subsequent disruptions of some services should be expected until maintenance procedures are completed in the late afternoon. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Sep 11 18:46:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 12:46:19 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote: > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 22:05:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 20:05:52 +0000 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 11 22:43:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 16:43:29 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: <49A3CCD1-581E-46F9-B6EF-0F3FE2B581EC@cs.purdue.edu> On 11 Sep 2009, at 16:05, Jay K wrote: > Tony I'll double check if I see the hang. NT386 still crashes. That's ThreadWin32 right? > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 11 22:51:11 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 16:51:11 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote: > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 11 23:05:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 17:05:57 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4AAA8078.1E75.00D7.1@scires.com> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> Message-ID: <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:28:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:28:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> Message-ID: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:30:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:30:22 +0000 Subject: [M3devel] RC merge In-Reply-To: <49A3CCD1-581E-46F9-B6EF-0F3FE2B581EC@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <49A3CCD1-581E-46F9-B6EF-0F3FE2B581EC@cs.purdue.edu> Message-ID: Correct ThreadWin32 not ThreadPThread or ThreadPosix. I narrowed the problem down to a 30 minute window in Februrary (see older mail). I'll try again with recent changes (esp. if they are in common code, which I don't think they are) - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:43:29 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge On 11 Sep 2009, at 16:05, Jay K wrote:Tony I'll double check if I see the hang. NT386 still crashes. That's ThreadWin32 right? http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:33:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:33:32 +0000 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: ps: I think there's another funny thing here: I think you can have: INTERFACE FooInterface; PROCEDURE SafeFunction(); PROCEDURE UnsafeFunction()=ADDRESS; END FooInterface. Despite being in a safe interface, UnsafeFunction either can't be called from safe code, or at least its return value can't be used? Or at least can't be done anything with but compare to NIL? I think. Therefore this interface could be said to be "partially unsafe". Perhaps not a useful middle ground though. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] RC merge Date: Fri, 11 Sep 2009 21:26:00 +0000 Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be. I propose a few options: 1 - asis, probably not 2 - rename/merge ThreadUnsafe to ThreadInternal 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too 2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal 3 maybe gratuitously breaks folks but is a clean result 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:51:11 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote:Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:26:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:26:00 +0000 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be. I propose a few options: 1 - asis, probably not 2 - rename/merge ThreadUnsafe to ThreadInternal 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too 2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal 3 maybe gratuitously breaks folks but is a clean result 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:51:11 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote:Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Sat Sep 12 02:58:04 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 11 Sep 2009 19:58:04 -0500 Subject: [M3devel] Dual Pivot Quicksort problem Message-ID: <4AAAF21C.5030209@esoteriq.org> I saw a post on reddit about a Dual Pivot Quicksort, and I translated the code from Java to Modula-3. I have it all translated, and it builds, but I am having boundary issues. Somewhere on the second pass, the variable m2 is getting the value -2. Here's the code: MODULE DualPivot; IMPORT Insertion, Fmt; PROCEDURE Sort(VAR arr: ARRAY OF INTEGER) = BEGIN SortFromTo(arr, 0, NUMBER(arr)); END Sort; PROCEDURE SortFromTo(VAR arr: ARRAY OF INTEGER; from, to: INTEGER) = BEGIN RangeCheck(NUMBER(arr), from, to); DualPivotSort(arr, from, to - 1, 3); END SortFromTo; PROCEDURE RangeCheck(len, from, to: INTEGER) RAISES {BadArgument, IndexOutOfRange} = BEGIN IF from > to THEN RAISE BadArgument(Fmt.Int(from) & " > " & Fmt.Int(to) & "\n"); END; IF from < 0 THEN RAISE IndexOutOfRange("from"); END; IF to > len THEN RAISE IndexOutOfRange("to"); END; END RangeCheck; PROCEDURE Swap(VAR arr: ARRAY OF INTEGER; i, j: INTEGER) = VAR temp := arr[i]; BEGIN arr[i] := arr[j]; arr[j] := temp; END Swap; PROCEDURE DualPivotSort(VAR arr: ARRAY OF INTEGER; left, right, div: INTEGER) = VAR len := left - right; third := len DIV div; m1 := left + third; m2 := right - third; piv1: INTEGER; piv2: INTEGER; less := left + 1; great := right - 1; dist: INTEGER; BEGIN IF len < 27 THEN Insertion.Sort(arr); END; IF m1 <= left THEN m1 := left + 1; END; IF m2 >= right THEN m2 := right - 1; END; IF arr[m1] < arr[m2] THEN Swap(arr, m1, left); Swap(arr, m2, right); ELSE Swap(arr, m1, right); Swap(arr, m2, left); END; piv1 := arr[left]; piv2 := arr[right]; FOR k := less TO great DO IF arr[k] < piv1 THEN Swap(arr, k, less + 1); ELSIF arr[k] > piv2 THEN WHILE (k < great) AND (arr[great] > piv2) DO DEC(great); END; Swap(arr, k, great - 1); IF arr[k] < piv1 THEN Swap(arr, k, less + 1); END; END; END; dist := great - less; IF dist < 13 THEN INC(div); END; Swap(arr, less - 1, left); Swap(arr, great + 1, right); DualPivotSort(arr, left, less - 2, div); DualPivotSort(arr, great + 2, right, div); IF (dist > len - 13) AND (piv1 # piv2) THEN FOR k := less TO great DO IF arr[k] = piv1 THEN Swap(arr, k, less + 1); ELSIF arr[k] = piv2 THEN Swap(arr, k, great - 1); IF arr[k] = piv1 THEN Swap(arr, k, less + 1); END; END; END; END; IF piv1 < piv2 THEN DualPivotSort(arr, less, great, div); END; END DualPivotSort; BEGIN END DualPivot. Right now when I try to run I get: *** *** runtime error: *** An array subscript was out of range. *** file "../DualPivot.m3", line 61 *** Line 61 is: IF arr[m1] < arr[m2] THEN Anyone see what is happening? It's probably off by 1 (or more) errors, but I don't see them. From hosking at cs.purdue.edu Sat Sep 12 04:19:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 22:19:49 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> Yes, that was exactly my intention. I wasn't quite sure what your problem was with the code I had returning ADDRESS, but was willing to accede. It is "safe", but you can't use the result unless in UNSAFE code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 17:33, Jay K wrote: > ps: I think there's another funny thing here: > I think you can have: > > INTERFACE FooInterface; > > PROCEDURE SafeFunction(); > PROCEDURE UnsafeFunction()=ADDRESS; > > END FooInterface. > > Despite being in a safe interface, UnsafeFunction either can't be > called > from safe code, or at least its return value can't be used? Or at > least > can't be done anything with but compare to NIL? > I think. > Therefore this interface could be said to be "partially unsafe". > > Perhaps not a useful middle ground though. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC merge > Date: Fri, 11 Sep 2009 21:26:00 +0000 > > Yes and no. I agree I made a small mess. I'm not sure you have quite > described how it should be. > > I propose a few options: > 1 - asis, probably not > 2 - rename/merge ThreadUnsafe to ThreadInternal > 3 - move the part that external folks use, probably just MyId, to > Thread, and then move ThreadUnsafe back to ThreadF, maybe > ThreadInternal to ThreadF too > > 2 at least removes one interface that I added, reducing the three > similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF > and ThreadInternal > > 3 maybe gratuitously breaks folks but is a clean result > > 4 - like you said, make all ThreadF users unsafe; but IF it is just > MyId, and I'm not sure it is, which seems harmless, right? seems > wrong to make them unsafe. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 16:51:11 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Sorry, it looks like my commit failed last night because of need to > merge with your ThreadUnsafe stuff. > > FYI, we really should think about making ThreadF UNSAFE since anyone > invoking on it is exposed to dangerous parts of the run-time > system. Is there any need for it really to be safe? > > On 11 Sep 2009, at 16:05, Jay K wrote: > > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 04:20:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 22:20:57 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: I propose leave ThreadF safe, and revert back to MyHeapState:ADDRESS in ThreadF. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 17:26, Jay K wrote: > Yes and no. I agree I made a small mess. I'm not sure you have quite > described how it should be. > > I propose a few options: > 1 - asis, probably not > 2 - rename/merge ThreadUnsafe to ThreadInternal > 3 - move the part that external folks use, probably just MyId, to > Thread, and then move ThreadUnsafe back to ThreadF, maybe > ThreadInternal to ThreadF too > > 2 at least removes one interface that I added, reducing the three > similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF > and ThreadInternal > > 3 maybe gratuitously breaks folks but is a clean result > > 4 - like you said, make all ThreadF users unsafe; but IF it is just > MyId, and I'm not sure it is, which seems harmless, right? seems > wrong to make them unsafe. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 16:51:11 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Sorry, it looks like my commit failed last night because of need to > merge with your ThreadUnsafe stuff. > > FYI, we really should think about making ThreadF UNSAFE since anyone > invoking on it is exposed to dangerous parts of the run-time > system. Is there any need for it really to be safe? > > On 11 Sep 2009, at 16:05, Jay K wrote: > > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 04:21:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 22:21:44 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> Message-ID: <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: > They aren't really in Trestle or ThreadWin32. > Well, right, often they are in ThreadWin32. > But not always. > I think it is, like, classic heap/stack corruption, via non-classic > "locking not working" and gc moving stuff when it shouldn't. > I don't have good evidence, but it usually NOT a hang/deadlock or > assertion failure, it is usually an access violation (aka SEGSIGV) > which as I understand must be the result of bugs in unsafe code. > > I did narrow it down a 30 minute window. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Fri, 11 Sep 2009 17:05:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I have my suspicions that ThreadWin32 may have similar latent bugs > in synchronization similar to those I have recently shaken out of > the pthreads implementation. The good thing is that my > implementation there is based in part on ThreadWin32, so it can't be > too far off. It is inevitable with concurrent code that you will > get different behavior at each run. The easiest things to debug are > thread lockups, which can usually be diagnosed by staring at dumps > of all the thread state. Harder is actual crashes like you are > observing. If assertions can be used to monitor program invariants > then it usually can be narrowed down. Unfortunately, I am not in a > position to debug the ThreadWin32 code. Any help would be > appreciated. The question is whether the crashes you see are in > Trestle or ThreadWin32. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 12 05:37:44 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 11 Sep 2009 20:37:44 -0700 Subject: [M3devel] RC merge In-Reply-To: <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> Message-ID: <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> I don't like the caller to have to cast. - Jay (phone) On Sep 11, 2009, at 7:19 PM, Tony Hosking wrote: > Yes, that was exactly my intention. I wasn't quite sure what your > problem was with the code I had returning ADDRESS, but was willing > to accede. It is "safe", but you can't use the result unless in > UNSAFE code. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 17:33, Jay K wrote: > >> ps: I think there's another funny thing here: >> I think you can have: >> >> INTERFACE FooInterface; >> >> PROCEDURE SafeFunction(); >> PROCEDURE UnsafeFunction()=ADDRESS; >> >> END FooInterface. >> >> Despite being in a safe interface, UnsafeFunction either can't be >> called >> from safe code, or at least its return value can't be used? Or at >> least >> can't be done anything with but compare to NIL? >> I think. >> Therefore this interface could be said to be "partially unsafe". >> >> Perhaps not a useful middle ground though. >> >> - Jay >> >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC merge >> Date: Fri, 11 Sep 2009 21:26:00 +0000 >> >> Yes and no. I agree I made a small mess. I'm not sure you have >> quite described how it should be. >> >> I propose a few options: >> 1 - asis, probably not >> 2 - rename/merge ThreadUnsafe to ThreadInternal >> 3 - move the part that external folks use, probably just MyId, to >> Thread, and then move ThreadUnsafe back to ThreadF, maybe >> ThreadInternal to ThreadF too >> >> 2 at least removes one interface that I added, reducing the three >> similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF >> and ThreadInternal >> >> 3 maybe gratuitously breaks folks but is a clean result >> >> 4 - like you said, make all ThreadF users unsafe; but IF it is >> just MyId, and I'm not sure it is, which seems harmless, right? >> seems wrong to make them unsafe. >> >> - Jay >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Fri, 11 Sep 2009 16:51:11 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] RC merge >> >> Sorry, it looks like my commit failed last night because of need to >> merge with your ThreadUnsafe stuff. >> >> FYI, we really should think about making ThreadF UNSAFE since >> anyone invoking on it is exposed to dangerous parts of the run-time >> system. Is there any need for it really to be safe? >> >> On 11 Sep 2009, at 16:05, Jay K wrote: >> >> Tony I'll double check if I see the hang. NT386 still crashes. >> >> http://www.modula3.com/cm3/ChangeLog-2009 >> >> " >> 2009-09-08 05:54 hosking >> >> * m3-libs/m3core/src/: convert/CConvert.m3, >> runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, >> runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, >> runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, >> runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, >> runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, >> runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, >> thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, >> thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, >> thread/WIN32/ThreadWin32.m3: >> >> Tidy up use of thread.inCritical to only occur in allocation >> sequences and in >> thread stoppage. This simplifies reasoning. Refactored use of >> heap lock >> in the process. This may be better implemented on PTHREAD >> targets using a >> recursive pthread mutex instead of one we roll ourselves from a >> non-recursive >> mutex. >> >> Still witnessing random hangs in Juno and mentor on I386_DARWIN. >> Strange, I thought this was working previously. >> I wonder if there is some sort of race in the GUI code somewhere? >> " >> >> ?? >> - Jay >> >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Fri, 11 Sep 2009 12:46:19 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] RC merge >> >> No, the hangs in Juno and mentor are no longer there. I cannot >> reproduce them on I386_DARWIN. >> >> On 11 Sep 2009, at 10:24, Jay K wrote: >> >> But the hangs are still present, right? Worth merging without that >> fixed? >> >> How does one do it easily? >> I wish we used Perforce. :( >> >> - Jay >> >> >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Fri, 11 Sep 2009 09:45:23 -0400 >> Subject: [M3devel] RC merge >> >> Can someone merge my recent deep fixes to pthreads threading over >> to the release branch? I won't get a chance to do so until next >> Monday at the earliest. >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Sat Sep 12 06:01:05 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 11 Sep 2009 23:01:05 -0500 Subject: [M3devel] Dual Pivot Quicksort problem In-Reply-To: <4AAAF21C.5030209@esoteriq.org> References: <4AAAF21C.5030209@esoteriq.org> Message-ID: <4AAB1D01.3020403@esoteriq.org> Edited it some more, lots of silly mistakes in that old code. Now it almost works...it sorts the array sometimes, but other times gives me a bounds error. Any idea now? MODULE DualPivot; IMPORT Insertion, Fmt, IO; PROCEDURE Sort(VAR arr: ARRAY OF INTEGER) = BEGIN SortFromTo(arr, 0, NUMBER(arr)); END Sort; PROCEDURE SortFromTo(VAR arr: ARRAY OF INTEGER; from, to: INTEGER) = BEGIN RangeCheck(NUMBER(arr), from, to); DualPivotSort(arr, from, to - 1, 3); END SortFromTo; PROCEDURE RangeCheck(len, from, to: INTEGER) RAISES {BadArgument, IndexOutOfRange} = BEGIN IF from > to THEN RAISE BadArgument(Fmt.Int(from) & " > " & Fmt.Int(to) & "\n"); END; IF from < 0 THEN RAISE IndexOutOfRange("from"); END; IF to > len THEN RAISE IndexOutOfRange("to"); END; END RangeCheck; PROCEDURE Swap(VAR arr: ARRAY OF INTEGER; i, j: INTEGER) = VAR temp := arr[i]; BEGIN arr[i] := arr[j]; arr[j] := temp; END Swap; PROCEDURE DualPivotSort(VAR arr: ARRAY OF INTEGER; left, right, div: INTEGER) = VAR len := right - left; third := len DIV div; m1 := left + third; m2 := right - third; piv1: INTEGER; piv2: INTEGER; less := left + 1; great := right - 1; dist: INTEGER; BEGIN IF len < 27 THEN Insertion.Sort(arr); RETURN; END; IF m1 <= left THEN m1 := left + 1; END; IF m2 >= right THEN m2 := right - 1; END; IO.Put("DEBUG: m1 = " & Fmt.Int(m1) & " m2 = " & Fmt.Int(m2) & " left = " & Fmt.Int(left) & " right = " & Fmt.Int(right) & "\n"); IO.Put("DEBUG: len = " & Fmt.Int(len) & " third = " & Fmt.Int(third) & "\n"); IO.Put("***\n"); IF arr[m1] < arr[m2] THEN Swap(arr, m1, left); Swap(arr, m2, right); ELSE Swap(arr, m1, right); Swap(arr, m2, left); END; piv1 := arr[left]; piv2 := arr[right]; FOR k := less TO great DO IF arr[k] < piv1 THEN Swap(arr, k, less); INC(less); ELSIF arr[k] > piv2 THEN WHILE (k < great) AND (arr[great] > piv2) DO DEC(great); END; Swap(arr, k, great); DEC(great); IF arr[k] < piv1 THEN Swap(arr, k, less); INC(less); END; END; END; dist := great - less; IF dist < 13 THEN INC(div); END; Swap(arr, less - 1, left); Swap(arr, great + 1, right); DualPivotSort(arr, left, less - 2, div); DualPivotSort(arr, great + 2, right, div); IF (dist > len - 13) AND (piv1 # piv2) THEN FOR k := less TO great DO IF arr[k] = piv1 THEN Swap(arr, k, less); INC(less); ELSIF arr[k] = piv2 THEN Swap(arr, k, great); DEC(great); IF arr[k] = piv1 THEN Swap(arr, k, less); INC(less); END; END; END; END; IF piv1 < piv2 THEN DualPivotSort(arr, less, great, div); END; END DualPivotSort; BEGIN END DualPivot. Martin Bishop wrote: > I saw a post on reddit about a Dual Pivot Quicksort, and I translated > the code from Java to Modula-3. I have it all translated, and it > builds, but I am having boundary issues. Somewhere on the second > pass, the variable m2 is getting the value -2. Here's the code: > > ... > Right now when I try to run I get: > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../DualPivot.m3", line 61 > *** > > Line 61 is: IF arr[m1] < arr[m2] THEN > > Anyone see what is happening? It's probably off by 1 (or more) errors, > but I don't see them. > > From mbishop at esoteriq.org Sat Sep 12 06:12:17 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 11 Sep 2009 23:12:17 -0500 Subject: [M3devel] Dual Pivot Quicksort problem (FIXED) In-Reply-To: <4AAB1D01.3020403@esoteriq.org> References: <4AAAF21C.5030209@esoteriq.org> <4AAB1D01.3020403@esoteriq.org> Message-ID: <4AAB1FA1.6060202@esoteriq.org> Sorry to keep posting, but I just wanted to say I fixed the problem (it isn't even in this code, it was in the insertion sort module.) Martin Bishop wrote: > Edited it some more, lots of silly mistakes in that old code. Now it > almost works...it sorts the array sometimes, but other times gives me > a bounds error. Any idea now? > > MODULE DualPivot; > > IMPORT Insertion, Fmt, IO; > > PROCEDURE Sort(VAR arr: ARRAY OF INTEGER) = > BEGIN > SortFromTo(arr, 0, NUMBER(arr)); > END Sort; > > PROCEDURE SortFromTo(VAR arr: ARRAY OF INTEGER; from, to: INTEGER) = > BEGIN > RangeCheck(NUMBER(arr), from, to); > DualPivotSort(arr, from, to - 1, 3); > END SortFromTo; > > PROCEDURE RangeCheck(len, from, to: INTEGER) RAISES {BadArgument, > IndexOutOfRange} = > BEGIN > IF from > to THEN > RAISE BadArgument(Fmt.Int(from) & " > " & Fmt.Int(to) & "\n"); > END; > IF from < 0 THEN > RAISE IndexOutOfRange("from"); > END; > IF to > len THEN > RAISE IndexOutOfRange("to"); > END; > END RangeCheck; > > PROCEDURE Swap(VAR arr: ARRAY OF INTEGER; i, j: INTEGER) = > VAR temp := arr[i]; > BEGIN > arr[i] := arr[j]; > arr[j] := temp; > END Swap; > > PROCEDURE DualPivotSort(VAR arr: ARRAY OF INTEGER; left, right, div: > INTEGER) = > VAR > len := right - left; > third := len DIV div; > m1 := left + third; > m2 := right - third; > piv1: INTEGER; > piv2: INTEGER; > less := left + 1; > great := right - 1; > dist: INTEGER; > > BEGIN > IF len < 27 THEN > Insertion.Sort(arr); > RETURN; > END; > > IF m1 <= left THEN > m1 := left + 1; > END; > > IF m2 >= right THEN > m2 := right - 1; > END; > > IO.Put("DEBUG: m1 = " & Fmt.Int(m1) & " m2 = " & Fmt.Int(m2) & > " left = " & Fmt.Int(left) & " right = " & Fmt.Int(right) & "\n"); > IO.Put("DEBUG: len = " & Fmt.Int(len) & " third = " & > Fmt.Int(third) & "\n"); > IO.Put("***\n"); > > IF arr[m1] < arr[m2] THEN > Swap(arr, m1, left); > Swap(arr, m2, right); > ELSE > Swap(arr, m1, right); > Swap(arr, m2, left); > END; > > piv1 := arr[left]; > piv2 := arr[right]; > FOR k := less TO great DO > IF arr[k] < piv1 THEN > Swap(arr, k, less); > INC(less); > ELSIF arr[k] > piv2 THEN > WHILE (k < great) AND (arr[great] > piv2) DO > DEC(great); > END; > Swap(arr, k, great); > DEC(great); > IF arr[k] < piv1 THEN > Swap(arr, k, less); > INC(less); > END; > END; > END; > > dist := great - less; > > IF dist < 13 THEN > INC(div); > END; > > Swap(arr, less - 1, left); > Swap(arr, great + 1, right); > DualPivotSort(arr, left, less - 2, div); > DualPivotSort(arr, great + 2, right, div); > IF (dist > len - 13) AND (piv1 # piv2) THEN > FOR k := less TO great DO > IF arr[k] = piv1 THEN > Swap(arr, k, less); > INC(less); > ELSIF arr[k] = piv2 THEN > Swap(arr, k, great); > DEC(great); > IF arr[k] = piv1 THEN > Swap(arr, k, less); > INC(less); > END; > END; > END; > END; > > IF piv1 < piv2 THEN > DualPivotSort(arr, less, great, div); > END; > END DualPivotSort; > > BEGIN > END DualPivot. > > Martin Bishop wrote: >> I saw a post on reddit about a Dual Pivot Quicksort, and I translated >> the code from Java to Modula-3. I have it all translated, and it >> builds, but I am having boundary issues. Somewhere on the second >> pass, the variable m2 is getting the value -2. Here's the code: >> >> ... > >> Right now when I try to run I get: >> >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "../DualPivot.m3", line 61 >> *** >> >> Line 61 is: IF arr[m1] < arr[m2] THEN >> >> Anyone see what is happening? It's probably off by 1 (or more) >> errors, but I don't see them. >> >> > > From jay.krell at cornell.edu Sat Sep 12 10:53:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Sep 2009 08:53:01 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30: 2009-02-16 02:30 hosking * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, RTProcessPosixC.i3: Tidy up. 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 2009-02-16 02:02 hosking * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: Expose DoWalkRef. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 22:21:44 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 12 11:26:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Sep 2009 09:26:51 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: Tony, - You didn't like how I factored InitMutex and InitCondition via InitMutexHelper? - XWait doesn't have to initialize the mutex, because it must already be locked, and therefore initialized? Or is that a "safety hole"? Unsafe module trusting safe caller to have adhered to its interface but it might not have to so unsafe code has to do extra work to preserve safety? Reasonable to ASSERT instead? Or are asserts allowed to be removed and can't be used to guarantee safety? (I put them in C code used by Modula-3, but I can perhaps make the rules there.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Sat, 12 Sep 2009 08:53:01 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30: 2009-02-16 02:30 hosking * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, RTProcessPosixC.i3: Tidy up. 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 2009-02-16 02:02 hosking * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: Expose DoWalkRef. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 22:21:44 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 13:38:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Sep 2009 07:38:43 -0400 Subject: [M3devel] RC merge In-Reply-To: <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> Message-ID: <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> But in this case the caller is highly privileged code that is already UNSAFE, so who cares? On 11 Sep 2009, at 23:37, jay.krell at cornell.edu wrote: > I don't like the caller to have to cast. > > - Jay (phone) > > On Sep 11, 2009, at 7:19 PM, Tony Hosking > wrote: > >> Yes, that was exactly my intention. I wasn't quite sure what your >> problem was with the code I had returning ADDRESS, but was willing >> to accede. It is "safe", but you can't use the result unless in >> UNSAFE code. >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 11 Sep 2009, at 17:33, Jay K wrote: >> >>> ps: I think there's another funny thing here: >>> I think you can have: >>> >>> INTERFACE FooInterface; >>> >>> PROCEDURE SafeFunction(); >>> PROCEDURE UnsafeFunction()=ADDRESS; >>> >>> END FooInterface. >>> >>> Despite being in a safe interface, UnsafeFunction either can't be >>> called >>> from safe code, or at least its return value can't be used? Or at >>> least >>> can't be done anything with but compare to NIL? >>> I think. >>> Therefore this interface could be said to be "partially unsafe". >>> >>> Perhaps not a useful middle ground though. >>> >>> - Jay >>> >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC merge >>> Date: Fri, 11 Sep 2009 21:26:00 +0000 >>> >>> Yes and no. I agree I made a small mess. I'm not sure you have >>> quite described how it should be. >>> >>> I propose a few options: >>> 1 - asis, probably not >>> 2 - rename/merge ThreadUnsafe to ThreadInternal >>> 3 - move the part that external folks use, probably just MyId, to >>> Thread, and then move ThreadUnsafe back to ThreadF, maybe >>> ThreadInternal to ThreadF too >>> >>> 2 at least removes one interface that I added, reducing the three >>> similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, >>> ThreadF and ThreadInternal >>> >>> 3 maybe gratuitously breaks folks but is a clean result >>> >>> 4 - like you said, make all ThreadF users unsafe; but IF it is >>> just MyId, and I'm not sure it is, which seems harmless, right? >>> seems wrong to make them unsafe. >>> >>> - Jay >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Fri, 11 Sep 2009 16:51:11 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] RC merge >>> >>> Sorry, it looks like my commit failed last night because of need >>> to merge with your ThreadUnsafe stuff. >>> >>> FYI, we really should think about making ThreadF UNSAFE since >>> anyone invoking on it is exposed to dangerous parts of the run- >>> time system. Is there any need for it really to be safe? >>> >>> On 11 Sep 2009, at 16:05, Jay K wrote: >>> >>> Tony I'll double check if I see the hang. NT386 still crashes. >>> >>> http://www.modula3.com/cm3/ChangeLog-2009 >>> >>> " >>> 2009-09-08 05:54 hosking >>> >>> * m3-libs/m3core/src/: convert/CConvert.m3, >>> runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, >>> runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, >>> runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, >>> runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, >>> runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, >>> runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, >>> thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, >>> thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, >>> thread/WIN32/ThreadWin32.m3: >>> >>> Tidy up use of thread.inCritical to only occur in allocation >>> sequences and in >>> thread stoppage. This simplifies reasoning. Refactored use of >>> heap lock >>> in the process. This may be better implemented on PTHREAD >>> targets using a >>> recursive pthread mutex instead of one we roll ourselves from a >>> non-recursive >>> mutex. >>> >>> Still witnessing random hangs in Juno and mentor on I386_DARWIN. >>> Strange, I thought this was working previously. >>> I wonder if there is some sort of race in the GUI code somewhere? >>> " >>> >>> ?? >>> - Jay >>> >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Fri, 11 Sep 2009 12:46:19 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] RC merge >>> >>> No, the hangs in Juno and mentor are no longer there. I cannot >>> reproduce them on I386_DARWIN. >>> >>> On 11 Sep 2009, at 10:24, Jay K wrote: >>> >>> But the hangs are still present, right? Worth merging without that >>> fixed? >>> >>> How does one do it easily? >>> I wish we used Perforce. :( >>> >>> - Jay >>> >>> >>> From: hosking at cs.purdue.edu >>> To: m3devel at elegosoft.com >>> Date: Fri, 11 Sep 2009 09:45:23 -0400 >>> Subject: [M3devel] RC merge >>> >>> Can someone merge my recent deep fixes to pthreads threading over >>> to the release branch? I won't get a chance to do so until next >>> Monday at the earliest. >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 14:22:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Sep 2009 08:22:51 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: <1BBBFA10-B502-4985-9F3D-24E33D5927E6@cs.purdue.edu> On 12 Sep 2009, at 05:26, Jay K wrote: > Tony, > - You didn't like how I factored InitMutex and InitCondition via > InitMutexHelper? Please keep them separate in case implementation of Condition and Mutex diverge. I've been playing with these some lately and may yet make further changes. Having shared code makes it a real pain to change one and not the other. > - XWait doesn't have to initialize the mutex, because it must already > be locked, and therefore initialized? Or is that a "safety hole"? Just in case a client invokes Wait without holding the mutex. Perhaps better to check and die. I will adjust. > Unsafe module trusting safe caller to have adhered to its interface > but it might not have to so unsafe code has to do extra work to > preserve safety? > Reasonable to ASSERT instead? Or are asserts allowed to be removed ASSERTs can be removed by compiling without assertions for performance. > and can't be used to guarantee safety? Right. > (I put them in C code used by Modula-3, but I can perhaps make > the rules there.) C coded asserts cannot be turned off by the Modula-3 compiler. Only C compiler. > > - Jay > > > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sat, 12 Sep 2009 08:53:01 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I believe it was this 30 minute window, 2009-02-16 02:00 - > 2009-02-16 02:30: > > 2009-02-16 02:30 hosking > > * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, > RTProcessPosixC.i3: > > Tidy up. > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > 2009-02-16 02:02 hosking > > * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: > > Expose DoWalkRef. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 22:21:44 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Hmmm. Not sure. Do you have the code diffs? > > On 11 Sep 2009, at 17:28, Jay K wrote: > > They aren't really in Trestle or ThreadWin32. > Well, right, often they are in ThreadWin32. > But not always. > I think it is, like, classic heap/stack corruption, via non-classic > "locking not working" and gc moving stuff when it shouldn't. > I don't have good evidence, but it usually NOT a hang/deadlock or > assertion failure, it is usually an access violation (aka SEGSIGV) > which as I understand must be the result of bugs in unsafe code. > > I did narrow it down a 30 minute window. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Fri, 11 Sep 2009 17:05:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I have my suspicions that ThreadWin32 may have similar latent bugs > in synchronization similar to those I have recently shaken out of > the pthreads implementation. The good thing is that my > implementation there is based in part on ThreadWin32, so it can't be > too far off. It is inevitable with concurrent code that you will > get different behavior at each run. The easiest things to debug are > thread lockups, which can usually be diagnosed by staring at dumps > of all the thread state. Harder is actual crashes like you are > observing. If assertions can be used to monitor program invariants > then it usually can be narrowed down. Unfortunately, I am not in a > position to debug the ThreadWin32 code. Any help would be > appreciated. The question is whether the crashes you see are in > Trestle or ThreadWin32. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 14:24:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Sep 2009 08:24:48 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> Interesting. My suspicions are that I missed something in the ThreadWin32 conversion to implement LockHeap, WaitHeap sanely. I can't debug Windows threads easily, but I strongly suggest Windows threads are in need of a rewrite to improve concurrency by making use of mutex/CVs now that Win32 supports CVs. On 12 Sep 2009, at 04:53, Jay K wrote: > I believe it was this 30 minute window, 2009-02-16 02:00 - > 2009-02-16 02:30: > > 2009-02-16 02:30 hosking > > * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, > RTProcessPosixC.i3: > > Tidy up. > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > 2009-02-16 02:02 hosking > > * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: > > Expose DoWalkRef. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 22:21:44 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Hmmm. Not sure. Do you have the code diffs? > > On 11 Sep 2009, at 17:28, Jay K wrote: > > They aren't really in Trestle or ThreadWin32. > Well, right, often they are in ThreadWin32. > But not always. > I think it is, like, classic heap/stack corruption, via non-classic > "locking not working" and gc moving stuff when it shouldn't. > I don't have good evidence, but it usually NOT a hang/deadlock or > assertion failure, it is usually an access violation (aka SEGSIGV) > which as I understand must be the result of bugs in unsafe code. > > I did narrow it down a 30 minute window. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Fri, 11 Sep 2009 17:05:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I have my suspicions that ThreadWin32 may have similar latent bugs > in synchronization similar to those I have recently shaken out of > the pthreads implementation. The good thing is that my > implementation there is based in part on ThreadWin32, so it can't be > too far off. It is inevitable with concurrent code that you will > get different behavior at each run. The easiest things to debug are > thread lockups, which can usually be diagnosed by staring at dumps > of all the thread state. Harder is actual crashes like you are > observing. If assertions can be used to monitor program invariants > then it usually can be narrowed down. Unfortunately, I am not in a > position to debug the ThreadWin32 code. Any help would be > appreciated. The question is whether the crashes you see are in > Trestle or ThreadWin32. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 12 15:18:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Sep 2009 13:18:03 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> Message-ID: If you do that, can you make it decide at runtime to chose between a pre-Vista and Vista or newer implementation? If you want, I can create ThreadWin6.m3 that is actually identical to ThreadWin32.m3 and a runtime switch between them, and then you or maybe I can start changing ThreadWin6.m3. I'm going to try to "study" ThreadPThread.m3 to inform me on how to write both ThreadWinNoCV.m3 (fix) and ThreadWinCV.m3 (making up more names). Thanks, - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Sat, 12 Sep 2009 08:24:48 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Interesting. My suspicions are that I missed something in the ThreadWin32 conversion to implement LockHeap, WaitHeap sanely. I can't debug Windows threads easily, but I strongly suggest Windows threads are in need of a rewrite to improve concurrency by making use of mutex/CVs now that Win32 supports CVs. On 12 Sep 2009, at 04:53, Jay K wrote: I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30: 2009-02-16 02:30 hosking * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, RTProcessPosixC.i3: Tidy up. 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 2009-02-16 02:02 hosking * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: Expose DoWalkRef. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 22:21:44 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 02:16:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 00:16:00 +0000 Subject: [M3devel] AllocTraced? Message-ID: Tony, - I can confirm Darwin no longer hangs. - I'm manually merging head to release. - We have two similar functions called AllocTraced now. Any chance of renaming one or combining them into one? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 07:53:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 05:53:18 +0000 Subject: [M3devel] RC merge In-Reply-To: <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> Message-ID: Imagine you are a somewhat prolific fairly happy C or C++ programmer. The whole world is unsafe, but recieves a fair amount of static checking and is therefore largely correct and perhaps doesn't even suffer much from the lack of safety. void* GetFoo(void); void* GetBar(void); or Foo_t* GetFoo(void); Bar_t* GetBar(void); ? Definitely the second. Perhaps perhaps perhaps perhaps a function should be able to be declared to return an UNTRACED REF Foo.Something, without actually importing Foo or defining Something? Clearly the safety of an /interface/ is more subtle than a boolean. Some functions may be safe and others unsafe. Even some uses of functions. Imagine for example: PROCEDURE GetFoo(): UNTRACED REF Foo.Something; Perhas a safe function could call this function, as long as it only compares the return value to NIL? Actually storing it in a variable would require IMPORT Foo, and if FOO is declared UNSAFE, then that would pollute the caller. Or maybe merely declaring a variable of UNTRACED is enough to wreck safety? Either way, I do grant, that it probably isn't worth deciding or making any language changes whatsoever. It should suffice for programmers to partition any given bunch of code conceptual interface Foo into SAFE INTERFACE Foo and UNSAFE INTERFACE FooF or FooInternal or FooUnsafe. I think I shall rename ThreadUnsafe to ThreadInternal amd merge the two ThreadInternals into one, as long as the contents of each exist in all of them, even though, granted, there aren't callers of all of them. "Unsafe" is shorter but "Internal" seems maybe better. ThreadF will remain safe and very small. We could move its resulting lone function into Thread, but I think it isn't worth breaking any callers outside m3core. Furthermore I'll endeavor to remove ADDRESS as a return type in ThreadInternal, replacing it with actual types, in order to remove casts, and make the unsafe code get just a little bit more static safety/checking. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Sat, 12 Sep 2009 07:38:43 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge But in this case the caller is highly privileged code that is already UNSAFE, so who cares? On 11 Sep 2009, at 23:37, jay.krell at cornell.edu wrote: I don't like the caller to have to cast. - Jay (phone) On Sep 11, 2009, at 7:19 PM, Tony Hosking wrote: Yes, that was exactly my intention. I wasn't quite sure what your problem was with the code I had returning ADDRESS, but was willing to accede. It is "safe", but you can't use the result unless in UNSAFE code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 17:33, Jay K wrote: ps: I think there's another funny thing here: I think you can have: INTERFACE FooInterface; PROCEDURE SafeFunction(); PROCEDURE UnsafeFunction()=ADDRESS; END FooInterface. Despite being in a safe interface, UnsafeFunction either can't be called from safe code, or at least its return value can't be used? Or at least can't be done anything with but compare to NIL? I think. Therefore this interface could be said to be "partially unsafe". Perhaps not a useful middle ground though. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] RC merge Date: Fri, 11 Sep 2009 21:26:00 +0000 Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be. I propose a few options: 1 - asis, probably not 2 - rename/merge ThreadUnsafe to ThreadInternal 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too 2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal 3 maybe gratuitously breaks folks but is a clean result 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:51:11 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote: Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote: But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Sun Sep 13 08:06:31 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Sun, 13 Sep 2009 01:06:31 -0500 Subject: [M3devel] Generic Dual Pivot Quicksort Message-ID: <4AAC8BE7.4010906@esoteriq.org> I wrote a generic version of Vladimir Yaroslavskiy's Dual Pivot Quicksort (http://permalink.gmane.org/gmane.comp.java.openjdk.core-libs.devel/2628) There's no known errors, but let me know if you find any. http://mbishop.esoteriq.org/code/Modula-3/GenericDualPivot/ From jay.krell at cornell.edu Sun Sep 13 15:51:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 13:51:02 +0000 Subject: [M3devel] RC merge In-Reply-To: <20090913094450.31FEA1A207D@async.async.caltech.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> Message-ID: The functions are meant to be unsafe either way. ThreadF.i3 clearly had a safety hole before, but not due to the functions "in question". Good point about passing in ADDRESSes..but I'm not entirely sure I understand/agree. Can safe code ("directly") generate any ADDRESSes at all? Or only get them from unsafe code in the first place? ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? I'll check. IF safe code CAN generate ADDRESSes, then this was a hole: PROCEDURE SetCurrentHandlers(h: ADDRESS); and perhaps these: PROCEDURE SuspendOthers (); (* Suspend all threads except the caller's *) PROCEDURE ResumeOthers (); Though probably not the second, since safe code can trivially hang/deadlock on its own. The public safe ThreadF.i3 now just: (*-------------------------------------------------- showthreads support ---*) TYPE State = { alive (* can run *), waiting (* waiting for a condition via Wait *), locking (* waiting for a mutex to be unlocked *), pausing (* waiting until some time is arrived *), blocking (* waiting for some IO *), dying (* done, but not yet joined *), dead (* done and joined *) }; (*-------------------------------------------------------------- identity ---*) TYPE Id = INTEGER; PROCEDURE MyId(): Id RAISES {}; (* return Id of caller *) Everything else I moved to the non-public ThreadInternal.i3. > But in Modula-3 whether an interface is unsafe or not *is* a boolean. Understood, but I still think even in unsafe code, LOOPHOLE should be minimized. C and C++ programmers are often taught to minimize casts, esp. reinterpret_cast. I think that guidance carries over to Modula's LOOPHOLE, even if you are already unsafe for other reasons. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > Date: Sun, 13 Sep 2009 02:44:50 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: > ... > > > >Imagine you are a somewhat prolific fairly happy C or C++ programmer. The w= > >hole world is unsafe=2C but recieves a fair amount of static checking and i= > >s therefore largely correct and perhaps doesn't even suffer much from the l= > >ack of safety. > > > >=20 > > > > void* GetFoo(void)=3B=20 > > > > void* GetBar(void)=3B=20 > > > >=20 > > > >or > > > >=20 > > > > Foo_t* GetFoo(void)=3B=20 > > > > Bar_t* GetBar(void)=3B=20 > > > >=20 > > > >? > > > >=20 > > > >Definitely the second. > > > >=20 > > > >Perhaps perhaps perhaps perhaps a function should be able to be declared to= > > return an UNTRACED REF Foo.Something=2C without actually importing Foo or = > >defining Something? > > > >=20 > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > >Some functions may be safe and others unsafe. > > > >Even some uses of functions. > > > >Imagine for example: > > > >=20 > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > >=20 > > > >Perhas a safe function could call this function=2C as long as it only compa= > >res the return value to NIL? > > > >Actually storing it in a variable would require IMPORT Foo=2C and if FOO is= > > declared UNSAFE=2C then that would > > > >pollute the caller. Or maybe merely declaring a variable of UNTRACED is eno= > >ugh to wreck safety? > > But in Modula-3 whether an interface is unsafe or not *is* a boolean. > It's very clearly defined what it means in the Green Book. > > If you don't declare your GetFoo as UNSAFE you can write > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > in safe code. > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > it's safer, if there's a safety problem with manipulating the fields. > > An interface can hardly assume that it is the only one injecting objects > of type ADDRESS into the "safe world" so if you're allowing the safe world > to pass these objects back in your interface you have to sanity-check > them anyhow. You do not, however, need to worry about the fields having > been changed by the safe code. > > If you need some more subtle properties than that you probably ought > to be writing UNSAFE code in the first place. Or is there some trickery > you can do along the lines of what we came up with for small integers > in pointers? > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 19:11:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 17:11:59 +0000 Subject: [M3devel] RC merge In-Reply-To: <20090913161207.2AB3B1A207D@async.async.caltech.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <20090913161207.2AB3B1A207D@async.async.caltech.edu> Message-ID: Good point, previously I could say SetCurrentHandlers(MyFPState()) in safe code. Now you can't. There's still ADDRESS used in ThreadInternal.i3 requiring LOOPHOLE but it doesn't appear easy to fix. > Arguably, hanging other threads (with which one does not share mutexes etc) Mutexes aren't the entire story there I think. Imagine some homegrown spinlock that is exported?? In either case, these functions are moved to an unsafe interface, at least until/unless some safe code needs them. Thanks, - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > Date: Sun, 13 Sep 2009 09:12:07 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: > >--_11d51f7d-f47a-4693-89d2-6f3429314a09_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > ... > >Good point about passing in ADDRESSes..but I'm not entirely sure I understa= > >nd/agree. > >Can safe code ("directly") generate any ADDRESSes at all? Or only get them = > >from > >unsafe code in the first place? > >ADDRESS only comes from ADR=2C right? And ADR isn't allowed in safe? I'll c= > >heck. > > > >IF safe code CAN generate ADDRESSes=2C then this was a hole: > >PROCEDURE SetCurrentHandlers(h: ADDRESS)=3B > > > No safe code can't generate ADDRESSes without help. But certainly > safe code can import TWO of these "quasi-unsafe" interfaces, and mix > up which address came whence... so your example is probably still > unsafe. > > > > >and perhaps these: > >PROCEDURE SuspendOthers ()=3B > >(* Suspend all threads except the caller's *) > > > >PROCEDURE ResumeOthers ()=3B > > > >Though probably not the second=2C since safe code can trivially hang/deadlo= > >ck on its own. > > Yes hanging is not a safety violation by the Modula-3 definition. > Arguably, hanging other threads (with which one does not share mutexes etc) > perhaps should be a safety violation, but can it be guaranteed? > > ... > > > >> But in Modula-3 whether an interface is unsafe or not *is* a boolean. > > > >Understood=2C but I still think even in unsafe code=2C LOOPHOLE should be m= > >inimized. > >C and C++ programmers are often taught to minimize casts=2C esp. reinterpre= > >t_cast. > >I think that guidance carries over to Modula's LOOPHOLE=2C even if you are = > >already unsafe > >for other reasons. > > Agreed! > > Mika > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 13 19:39:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 13:39:39 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> Message-ID: ThreadF has always been a non-standard, internal, "unpublished", non- standard interface. At one point it wasn't even shipped (interface not Interface). Anyway, my argument was that as such we could freely leave it as it was. I would argue that ordinary programmers should never even use it (it contains some very nasty low-level code like the GC suspend routines). On 13 Sep 2009, at 01:53, Jay K wrote: > Imagine you are a somewhat prolific fairly happy C or C++ > programmer. The whole world is unsafe, but recieves a fair amount of > static checking and is therefore largely correct and perhaps doesn't > even suffer much from the lack of safety. > > void* GetFoo(void); > void* GetBar(void); > > or > > Foo_t* GetFoo(void); > Bar_t* GetBar(void); > > ? > > Definitely the second. > > Perhaps perhaps perhaps perhaps a function should be able to be > declared to return an UNTRACED REF Foo.Something, without actually > importing Foo or defining Something? > > Clearly the safety of an /interface/ is more subtle than a boolean. > Some functions may be safe and others unsafe. > Even some uses of functions. > Imagine for example: > > PROCEDURE GetFoo(): UNTRACED REF Foo.Something; > > Perhas a safe function could call this function, as long as it only > compares the return value to NIL? > Actually storing it in a variable would require IMPORT Foo, and if > FOO is declared UNSAFE, then that would > pollute the caller. Or maybe merely declaring a variable of UNTRACED > is enough to wreck safety? > > Either way, I do grant, that it probably isn't worth deciding or > making any language changes whatsoever. > > It should suffice for programmers to partition any given bunch of > code conceptual interface Foo > > into SAFE INTERFACE Foo and UNSAFE INTERFACE FooF or FooInternal or > FooUnsafe. > > I think I shall rename ThreadUnsafe to ThreadInternal amd merge the > two ThreadInternals into one, > as long as the contents of each exist in all of them, even though, > granted, there > aren't callers of all of them. > "Unsafe" is shorter but "Internal" seems maybe better. > > ThreadF will remain safe and very small. > We could move its resulting lone function into Thread, but I think > it isn't worth breaking > any callers outside m3core. > > Furthermore I'll endeavor to remove ADDRESS as a return type in > ThreadInternal, replacing > it with actual types, in order to remove casts, and make the unsafe > code get just a little > bit more static safety/checking. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sat, 12 Sep 2009 07:38:43 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > But in this case the caller is highly privileged code that is > already UNSAFE, so who cares? > > On 11 Sep 2009, at 23:37, jay.krell at cornell.edu wrote: > > I don't like the caller to have to cast. > > - Jay (phone) > > On Sep 11, 2009, at 7:19 PM, Tony Hosking > wrote: > > Yes, that was exactly my intention. I wasn't quite sure what your > problem was with the code I had returning ADDRESS, but was willing > to accede. It is "safe", but you can't use the result unless in > UNSAFE code. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 17:33, Jay K wrote: > > ps: I think there's another funny thing here: > I think you can have: > > INTERFACE FooInterface; > > PROCEDURE SafeFunction(); > PROCEDURE UnsafeFunction()=ADDRESS; > > END FooInterface. > > Despite being in a safe interface, UnsafeFunction either can't be > called > from safe code, or at least its return value can't be used? Or at > least > can't be done anything with but compare to NIL? > I think. > Therefore this interface could be said to be "partially unsafe". > > Perhaps not a useful middle ground though. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC merge > Date: Fri, 11 Sep 2009 21:26:00 +0000 > > Yes and no. I agree I made a small mess. I'm not sure you have quite > described how it should be. > > I propose a few options: > 1 - asis, probably not > 2 - rename/merge ThreadUnsafe to ThreadInternal > 3 - move the part that external folks use, probably just MyId, to > Thread, and then move ThreadUnsafe back to ThreadF, maybe > ThreadInternal to ThreadF too > > 2 at least removes one interface that I added, reducing the three > similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF > and ThreadInternal > > 3 maybe gratuitously breaks folks but is a clean result > > 4 - like you said, make all ThreadF users unsafe; but IF it is just > MyId, and I'm not sure it is, which seems harmless, right? seems > wrong to make them unsafe. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 16:51:11 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Sorry, it looks like my commit failed last night because of need to > merge with your ThreadUnsafe stuff. > > FYI, we really should think about making ThreadF UNSAFE since anyone > invoking on it is exposed to dangerous parts of the run-time > system. Is there any need for it really to be safe? > > On 11 Sep 2009, at 16:05, Jay K wrote: > > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 13 19:43:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 13:43:48 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> Message-ID: <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> Safe code can't do anything with a value of type ADDRESS except pass it around. It must use unsafe operations (NARROW) to turn it into something usable. I think you misunderstood ThreadF in the first place. It has always been logically unsafe, if not UNSAFE. I don't want ThreadF ever to come to be something that people outside the runtime system rely on. The Id type and MyId function is simply a convenience, but not and never has been part of the standard interfaces. Can we please just revert back to the way it has always been? On 13 Sep 2009, at 09:51, Jay K wrote: > The functions are meant to be unsafe either way. > ThreadF.i3 clearly had a safety hole before, but not due to the > functions "in question". > > Good point about passing in ADDRESSes..but I'm not entirely sure I > understand/agree. > Can safe code ("directly") generate any ADDRESSes at all? Or only > get them from > unsafe code in the first place? > ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? > I'll check. > > IF safe code CAN generate ADDRESSes, then this was a hole: > PROCEDURE SetCurrentHandlers(h: ADDRESS); > > and perhaps these: > PROCEDURE SuspendOthers (); > (* Suspend all threads except the caller's *) > > PROCEDURE ResumeOthers (); > > Though probably not the second, since safe code can trivially hang/ > deadlock on its own. > > The public safe ThreadF.i3 now just: > > (*-------------------------------------------------- showthreads > support ---*) > > TYPE > State = { > alive (* can run *), > waiting (* waiting for a condition via Wait *), > locking (* waiting for a mutex to be unlocked *), > pausing (* waiting until some time is arrived *), > blocking (* waiting for some IO *), > dying (* done, but not yet joined *), > dead (* done and joined *) > }; > > (*-------------------------------------------------------------- > identity ---*) > > TYPE > Id = INTEGER; > > PROCEDURE MyId(): Id RAISES {}; > (* return Id of caller *) > > > Everything else I moved to the non-public ThreadInternal.i3. > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > Understood, but I still think even in unsafe code, LOOPHOLE should > be minimized. > C and C++ programmers are often taught to minimize casts, esp. > reinterpret_cast. > I think that guidance carries over to Modula's LOOPHOLE, even if you > are already unsafe > for other reasons. > > - Jay > > > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] RC merge > > Date: Sun, 13 Sep 2009 02:44:50 -0700 > > From: mika at async.async.caltech.edu > > > > Jay K writes: > > ... > > > > > >Imagine you are a somewhat prolific fairly happy C or C++ > programmer. The w= > > >hole world is unsafe=2C but recieves a fair amount of static > checking and i= > > >s therefore largely correct and perhaps doesn't even suffer much > from the l= > > >ack of safety. > > > > > >=20 > > > > > > void* GetFoo(void)=3B=20 > > > > > > void* GetBar(void)=3B=20 > > > > > >=20 > > > > > >or > > > > > >=20 > > > > > > Foo_t* GetFoo(void)=3B=20 > > > > > > Bar_t* GetBar(void)=3B=20 > > > > > >=20 > > > > > >? > > > > > >=20 > > > > > >Definitely the second. > > > > > >=20 > > > > > >Perhaps perhaps perhaps perhaps a function should be able to be > declared to= > > > return an UNTRACED REF Foo.Something=2C without actually > importing Foo or = > > >defining Something? > > > > > >=20 > > > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > > > >Some functions may be safe and others unsafe. > > > > > >Even some uses of functions. > > > > > >Imagine for example: > > > > > >=20 > > > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > > > >=20 > > > > > >Perhas a safe function could call this function=2C as long as it > only compa= > > >res the return value to NIL? > > > > > >Actually storing it in a variable would require IMPORT Foo=2C and > if FOO is= > > > declared UNSAFE=2C then that would > > > > > >pollute the caller. Or maybe merely declaring a variable of > UNTRACED is eno= > > >ugh to wreck safety? > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > It's very clearly defined what it means in the Green Book. > > > > If you don't declare your GetFoo as UNSAFE you can write > > > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > > > in safe code. > > > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > > it's safer, if there's a safety problem with manipulating the > fields. > > > > An interface can hardly assume that it is the only one injecting > objects > > of type ADDRESS into the "safe world" so if you're allowing the > safe world > > to pass these objects back in your interface you have to sanity- > check > > them anyhow. You do not, however, need to worry about the fields > having > > been changed by the safe code. > > > > If you need some more subtle properties than that you probably ought > > to be writing UNSAFE code in the first place. Or is there some > trickery > > you can do along the lines of what we came up with for small > integers > > in pointers? > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 20:02:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 18:02:24 +0000 Subject: [M3devel] RC merge In-Reply-To: <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> Message-ID: > The Id type and MyId function is simply a convenience But what do we do about it? It is out there and being used. It ought not have been, but it was and is. The safety hole SetCurrentHandlers(WhateverState()) was also out there as I understand. Should break the existing users? And/or move MyId to Thread.i3? Or ThreadFSafe.i3? I really don't think the way it was is the best choice. At the very least, ThreadF should either be interface instead of Interface and/or UNSAFE. But those options have the collateral damage of breaking users of ThreadF.MyId. I chose a route that doesn't have that damage and contains any churn to within m3core. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Sun, 13 Sep 2009 13:43:48 -0400 CC: mika at async.async.caltech.edu; m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Safe code can't do anything with a value of type ADDRESS except pass it around. It must use unsafe operations (NARROW) to turn it into something usable. I think you misunderstood ThreadF in the first place. It has always been logically unsafe, if not UNSAFE. I don't want ThreadF ever to come to be something that people outside the runtime system rely on. The Id type and MyId function is simply a convenience, but not and never has been part of the standard interfaces. Can we please just revert back to the way it has always been? On 13 Sep 2009, at 09:51, Jay K wrote:The functions are meant to be unsafe either way. ThreadF.i3 clearly had a safety hole before, but not due to the functions "in question". Good point about passing in ADDRESSes..but I'm not entirely sure I understand/agree. Can safe code ("directly") generate any ADDRESSes at all? Or only get them from unsafe code in the first place? ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? I'll check. IF safe code CAN generate ADDRESSes, then this was a hole: PROCEDURE SetCurrentHandlers(h: ADDRESS); and perhaps these: PROCEDURE SuspendOthers (); (* Suspend all threads except the caller's *) PROCEDURE ResumeOthers (); Though probably not the second, since safe code can trivially hang/deadlock on its own. The public safe ThreadF.i3 now just: (*-------------------------------------------------- showthreads support ---*) TYPE State = { alive (* can run *), waiting (* waiting for a condition via Wait *), locking (* waiting for a mutex to be unlocked *), pausing (* waiting until some time is arrived *), blocking (* waiting for some IO *), dying (* done, but not yet joined *), dead (* done and joined *) }; (*-------------------------------------------------------------- identity ---*) TYPE Id = INTEGER; PROCEDURE MyId(): Id RAISES {}; (* return Id of caller *) Everything else I moved to the non-public ThreadInternal.i3. > But in Modula-3 whether an interface is unsafe or not *is* a boolean. Understood, but I still think even in unsafe code, LOOPHOLE should be minimized. C and C++ programmers are often taught to minimize casts, esp. reinterpret_cast. I think that guidance carries over to Modula's LOOPHOLE, even if you are already unsafe for other reasons. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > Date: Sun, 13 Sep 2009 02:44:50 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: > ... > > > >Imagine you are a somewhat prolific fairly happy C or C++ programmer. The w= > >hole world is unsafe=2C but recieves a fair amount of static checking and i= > >s therefore largely correct and perhaps doesn't even suffer much from the l= > >ack of safety. > > > >=20 > > > > void* GetFoo(void)=3B=20 > > > > void* GetBar(void)=3B=20 > > > >=20 > > > >or > > > >=20 > > > > Foo_t* GetFoo(void)=3B=20 > > > > Bar_t* GetBar(void)=3B=20 > > > >=20 > > > >? > > > >=20 > > > >Definitely the second. > > > >=20 > > > >Perhaps perhaps perhaps perhaps a function should be able to be declared to= > > return an UNTRACED REF Foo.Something=2C without actually importing Foo or = > >defining Something? > > > >=20 > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > >Some functions may be safe and others unsafe. > > > >Even some uses of functions. > > > >Imagine for example: > > > >=20 > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > >=20 > > > >Perhas a safe function could call this function=2C as long as it only compa= > >res the return value to NIL? > > > >Actually storing it in a variable would require IMPORT Foo=2C and if FOO is= > > declared UNSAFE=2C then that would > > > >pollute the caller. Or maybe merely declaring a variable of UNTRACED is eno= > >ugh to wreck safety? > > But in Modula-3 whether an interface is unsafe or not *is* a boolean. > It's very clearly defined what it means in the Green Book. > > If you don't declare your GetFoo as UNSAFE you can write > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > in safe code. > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > it's safer, if there's a safety problem with manipulating the fields. > > An interface can hardly assume that it is the only one injecting objects > of type ADDRESS into the "safe world" so if you're allowing the safe world > to pass these objects back in your interface you have to sanity-check > them anyhow. You do not, however, need to worry about the fields having > been changed by the safe code. > > If you need some more subtle properties than that you probably ought > to be writing UNSAFE code in the first place. Or is there some trickery > you can do along the lines of what we came up with for small integers > in pointers? > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 13 20:34:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 14:34:36 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> Message-ID: <78CFFD41-8D5D-4E4C-9A9D-A7DD29DB95A9@cs.purdue.edu> I'm happy with what you have done (small safe ThreadF, internal unsafe ThreadInternal). Thanks. On 13 Sep 2009, at 14:02, Jay K wrote: > > The Id type and MyId function is simply a convenience > > But what do we do about it? > It is out there and being used. > It ought not have been, but it was and is. > > The safety hole SetCurrentHandlers(WhateverState()) was also out > there as I understand. > > Should break the existing users? > And/or move MyId to Thread.i3? > Or ThreadFSafe.i3? > > I really don't think the way it was is the best choice. > At the very least, ThreadF should either be interface instead of > Interface and/or UNSAFE. > But those options have the collateral damage of breaking users of > ThreadF.MyId. > I chose a route that doesn't have that damage and contains any churn > to within m3core. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 13 Sep 2009 13:43:48 -0400 > CC: mika at async.async.caltech.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Safe code can't do anything with a value of type ADDRESS except pass > it around. It must use unsafe operations (NARROW) to turn it into > something usable. > > I think you misunderstood ThreadF in the first place. It has always > been logically unsafe, if not UNSAFE. I don't want ThreadF ever to > come to be something that people outside the runtime system rely > on. The Id type and MyId function is simply a convenience, but not > and never has been part of the standard interfaces. > > Can we please just revert back to the way it has always been? > > On 13 Sep 2009, at 09:51, Jay K wrote: > > The functions are meant to be unsafe either way. > ThreadF.i3 clearly had a safety hole before, but not due to the > functions "in question". > > Good point about passing in ADDRESSes..but I'm not entirely sure I > understand/agree. > Can safe code ("directly") generate any ADDRESSes at all? Or only > get them from > unsafe code in the first place? > ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? > I'll check. > > IF safe code CAN generate ADDRESSes, then this was a hole: > PROCEDURE SetCurrentHandlers(h: ADDRESS); > > and perhaps these: > PROCEDURE SuspendOthers (); > (* Suspend all threads except the caller's *) > > PROCEDURE ResumeOthers (); > > Though probably not the second, since safe code can trivially hang/ > deadlock on its own. > > The public safe ThreadF.i3 now just: > > (*-------------------------------------------------- showthreads > support ---*) > > TYPE > State = { > alive (* can run *), > waiting (* waiting for a condition via Wait *), > locking (* waiting for a mutex to be unlocked *), > pausing (* waiting until some time is arrived *), > blocking (* waiting for some IO *), > dying (* done, but not yet joined *), > dead (* done and joined *) > }; > > (*-------------------------------------------------------------- > identity ---*) > > TYPE > Id = INTEGER; > > PROCEDURE MyId(): Id RAISES {}; > (* return Id of caller *) > > > Everything else I moved to the non-public ThreadInternal.i3. > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > Understood, but I still think even in unsafe code, LOOPHOLE should > be minimized. > C and C++ programmers are often taught to minimize casts, esp. > reinterpret_cast. > I think that guidance carries over to Modula's LOOPHOLE, even if you > are already unsafe > for other reasons. > > - Jay > > > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] RC merge > > Date: Sun, 13 Sep 2009 02:44:50 -0700 > > From: mika at async.async.caltech.edu > > > > Jay K writes: > > ... > > > > > >Imagine you are a somewhat prolific fairly happy C or C++ > programmer. The w= > > >hole world is unsafe=2C but recieves a fair amount of static > checking and i= > > >s therefore largely correct and perhaps doesn't even suffer much > from the l= > > >ack of safety. > > > > > >=20 > > > > > > void* GetFoo(void)=3B=20 > > > > > > void* GetBar(void)=3B=20 > > > > > >=20 > > > > > >or > > > > > >=20 > > > > > > Foo_t* GetFoo(void)=3B=20 > > > > > > Bar_t* GetBar(void)=3B=20 > > > > > >=20 > > > > > >? > > > > > >=20 > > > > > >Definitely the second. > > > > > >=20 > > > > > >Perhaps perhaps perhaps perhaps a function should be able to be > declared to= > > > return an UNTRACED REF Foo.Something=2C without actually > importing Foo or = > > >defining Something? > > > > > >=20 > > > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > > > >Some functions may be safe and others unsafe. > > > > > >Even some uses of functions. > > > > > >Imagine for example: > > > > > >=20 > > > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > > > >=20 > > > > > >Perhas a safe function could call this function=2C as long as it > only compa= > > >res the return value to NIL? > > > > > >Actually storing it in a variable would require IMPORT Foo=2C and > if FOO is= > > > declared UNSAFE=2C then that would > > > > > >pollute the caller. Or maybe merely declaring a variable of > UNTRACED is eno= > > >ugh to wreck safety? > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > It's very clearly defined what it means in the Green Book. > > > > If you don't declare your GetFoo as UNSAFE you can write > > > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > > > in safe code. > > > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > > it's safer, if there's a safety problem with manipulating the > fields. > > > > An interface can hardly assume that it is the only one injecting > objects > > of type ADDRESS into the "safe world" so if you're allowing the > safe world > > to pass these objects back in your interface you have to sanity- > check > > them anyhow. You do not, however, need to worry about the fields > having > > been changed by the safe code. > > > > If you need some more subtle properties than that you probably ought > > to be writing UNSAFE code in the first place. Or is there some > trickery > > you can do along the lines of what we came up with for small > integers > > in pointers? > > > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 14 00:07:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 18:07:05 -0400 Subject: [M3devel] RC merge In-Reply-To: <20090913203005.67D011A2079@async.async.caltech.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> <20090913203005.67D011A2079@async.async.caltech.edu> Message-ID: <0B34162D-0E83-4163-ADF3-405FC0571731@cs.purdue.edu> It will stay in ThreadF. On 13 Sep 2009, at 16:30, Mika Nystrom wrote: > > ThreadF.MyId is something I have used in otherwise perfectly safe > code, > hope it doesn't go away! It's very nice to be able to distinguish > threads from each other without extra effort from the programmer. Is > this something that is sometimes hard to provide? > > Mika > > > Tony Hosking writes: >> >> --Apple-Mail-18--321278784 >> Content-Type: text/plain; >> charset=US-ASCII; >> format=flowed; >> delsp=yes >> Content-Transfer-Encoding: 7bit >> >> Safe code can't do anything with a value of type ADDRESS except pass >> it around. It must use unsafe operations (NARROW) to turn it into >> something usable. >> >> I think you misunderstood ThreadF in the first place. It has always >> been logically unsafe, if not UNSAFE. I don't want ThreadF ever to >> come to be something that people outside the runtime system rely on. >> The Id type and MyId function is simply a convenience, but not and >> never has been part of the standard interfaces. >> >> Can we please just revert back to the way it has always been? >> >> On 13 Sep 2009, at 09:51, Jay K wrote: >> >>> The functions are meant to be unsafe either way. >>> ThreadF.i3 clearly had a safety hole before, but not due to the >>> functions "in question". >>> >>> Good point about passing in ADDRESSes..but I'm not entirely sure I >>> understand/agree. >>> Can safe code ("directly") generate any ADDRESSes at all? Or only >>> get them from >>> unsafe code in the first place? >>> ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? >>> I'll check. >>> >>> IF safe code CAN generate ADDRESSes, then this was a hole: >>> PROCEDURE SetCurrentHandlers(h: ADDRESS); >>> >>> and perhaps these: >>> PROCEDURE SuspendOthers (); >>> (* Suspend all threads except the caller's *) >>> >>> PROCEDURE ResumeOthers (); >>> >>> Though probably not the second, since safe code can trivially hang/ >>> deadlock on its own. >>> >>> The public safe ThreadF.i3 now just: >>> >>> (*-------------------------------------------------- showthreads >>> support ---*) >>> >>> TYPE >>> State = { >>> alive (* can run *), >>> waiting (* waiting for a condition via Wait *), >>> locking (* waiting for a mutex to be unlocked *), >>> pausing (* waiting until some time is arrived *), >>> blocking (* waiting for some IO *), >>> dying (* done, but not yet joined *), >>> dead (* done and joined *) >>> }; >>> >>> (*-------------------------------------------------------------- >>> identity ---*) >>> >>> TYPE >>> Id = INTEGER; >>> >>> PROCEDURE MyId(): Id RAISES {}; >>> (* return Id of caller *) >>> >>> >>> Everything else I moved to the non-public ThreadInternal.i3. >>> >>> >>>> But in Modula-3 whether an interface is unsafe or not *is* a >>> boolean. >>> >>> Understood, but I still think even in unsafe code, LOOPHOLE should >>> be minimized. >>> C and C++ programmers are often taught to minimize casts, esp. >>> reinterpret_cast. >>> I think that guidance carries over to Modula's LOOPHOLE, even if you >>> are already unsafe >>> for other reasons. >>> >>> - Jay >>> >>> >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] RC merge >>>> Date: Sun, 13 Sep 2009 02:44:50 -0700 >>>> From: mika at async.async.caltech.edu >>>> >>>> Jay K writes: >>>> ... >>>>> >>>>> Imagine you are a somewhat prolific fairly happy C or C++ >>> programmer. The w= >>>>> hole world is unsafe=2C but recieves a fair amount of static >>> checking and i= >>>>> s therefore largely correct and perhaps doesn't even suffer much >>> from the l= >>>>> ack of safety. >>>>> >>>>> =20 >>>>> >>>>> void* GetFoo(void)=3B=20 >>>>> >>>>> void* GetBar(void)=3B=20 >>>>> >>>>> =20 >>>>> >>>>> or >>>>> >>>>> =20 >>>>> >>>>> Foo_t* GetFoo(void)=3B=20 >>>>> >>>>> Bar_t* GetBar(void)=3B=20 >>>>> >>>>> =20 >>>>> >>>>> ? >>>>> >>>>> =20 >>>>> >>>>> Definitely the second. >>>>> >>>>> =20 >>>>> >>>>> Perhaps perhaps perhaps perhaps a function should be able to be >>> declared to= >>>>> return an UNTRACED REF Foo.Something=2C without actually >>> importing Foo or = >>>>> defining Something? >>>>> >>>>> =20 >>>>> >>>>> Clearly the safety of an /interface/ is more subtle than a >>>>> boolean. >>>>> >>>>> Some functions may be safe and others unsafe. >>>>> >>>>> Even some uses of functions. >>>>> >>>>> Imagine for example: >>>>> >>>>> =20 >>>>> >>>>> PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B >>>>> >>>>> =20 >>>>> >>>>> Perhas a safe function could call this function=2C as long as it >>> only compa= >>>>> res the return value to NIL? >>>>> >>>>> Actually storing it in a variable would require IMPORT Foo=2C and >>> if FOO is= >>>>> declared UNSAFE=2C then that would >>>>> >>>>> pollute the caller. Or maybe merely declaring a variable of >>> UNTRACED is eno= >>>>> ugh to wreck safety? >>>> >>>> But in Modula-3 whether an interface is unsafe or not *is* a >>> boolean. >>>> It's very clearly defined what it means in the Green Book. >>>> >>>> If you don't declare your GetFoo as UNSAFE you can write >>>> >>>> VAR x := GetFoo; BEGIN (* manipulate fields of x *) END >>>> >>>> in safe code. >>>> >>>> Declaring GetFoo to return ADDRESS won't let you do that. Hence, >>>> it's safer, if there's a safety problem with manipulating the >>> fields. >>>> >>>> An interface can hardly assume that it is the only one injecting >>> objects >>>> of type ADDRESS into the "safe world" so if you're allowing the >>> safe world >>>> to pass these objects back in your interface you have to sanity- >>> check >>>> them anyhow. You do not, however, need to worry about the fields >>> having >>>> been changed by the safe code. >>>> >>>> If you need some more subtle properties than that you probably >>>> ought >>>> to be writing UNSAFE code in the first place. Or is there some >>> trickery >>>> you can do along the lines of what we came up with for small >>> integers >>>> in pointers? >>>> >>>> Mika >> >> >> --Apple-Mail-18--321278784 >> Content-Type: text/html; >> charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> >> > space; = >> -webkit-line-break: after-white-space; ">
> apple-content-edited=3D"true">> style=3D"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; ">
> break-word; -webkit-nbsp-mode: space; -webkit-line-break: = >> after-white-space; ">> style=3D"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; >> ">
> style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >> -webkit-line-break: after-white-space; ">> span" = >> style=3D"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; >> ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">
> class=3D"Apple-style-span" style=3D"font-size: medium;">> class=3D"Apple-style-span" color=3D"#0000FF" face=3D"'Gill >> Sans'">Safe = >> code can't do anything with a value of type ADDRESS except pass it = >> around.  It must use unsafe operations (NARROW) to turn it >> into = >> something usable.
> style-span"= >> color=3D"#0000FF" face=3D"'Gill Sans'">> span" = >> style=3D"font-size: medium;">
> class=3D"Apple-style-span" color=3D"#0000FF" face=3D"'Gill >> Sans'">> class=3D"Apple-style-span" style=3D"font-size: medium;">I think you = >> misunderstood ThreadF in the first place.  It has always been = >> logically unsafe, if not UNSAFE.  I don't want ThreadF ever to >> come = >> to be something that people outside the runtime system rely on. = >>  The Id type and MyId function is simply a convenience, but >> not and = >> never has been part of the standard = >> interfaces.
> span" = >> color=3D"#0000FF" face=3D"'Gill Sans'">> span" = >> style=3D"font-size: medium;">
> class=3D"Apple-style-span" color=3D"#0000FF" face=3D"'Gill >> Sans'">> class=3D"Apple-style-span" style=3D"font-size: medium;">Can we >> please = >> just revert back to the way it has always = >> been?
> span>
= >>

On 13 Sep >> 2009, at = >> 09:51, Jay K wrote:

> class=3D"Apple-interchange-newline">
> class=3D"Apple-style-span" style=3D"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; ">
> style=3D"font-size: 10pt; font-family: Verdana; ">The functions are = >> meant to be unsafe either way.
ThreadF.i3 clearly had a safety >> hole = >> before, but not due to the functions "in question".

Good >> point = >> about passing in ADDRESSes..but I'm not entirely sure I = >> understand/agree.
Can safe code ("directly") generate any >> ADDRESSes = >> at all? Or only get them from
unsafe code in the first = >> place?
ADDRESS only comes from ADR, right? And ADR isn't allowed >> in = >> safe? I'll check.

IF safe code CAN generate ADDRESSes, then >> this = >> was a hole:
PROCEDURE SetCurrentHandlers(h: ADDRESS);

and = >> perhaps these:
PROCEDURE SuspendOthers ();
(* Suspend all >> threads = >> except the caller's *)

PROCEDURE ResumeOthers >> ();

Though = >> probably not the second, since safe code can trivially hang/ >> deadlock on = >> its own.

The public safe ThreadF.i3 now = >> just:

(*-------------------------------------------------- = >> showthreads support ---*)

TYPE
  State =3D = >> {
        >> alive    = >> (* can run *),
        = >> waiting  (* waiting for a condition via Wait = >> *),
        locking  (* = >> waiting for a mutex to be unlocked = >> *),
        pausing  (* = >> waiting until some time is arrived = >> *),
        blocking (* >> waiting = >> for some IO *),
        = >> dying    (* done, but not yet joined = >> *),
        = >> dead     (* done and joined >> *)
    = >> };< >> br >> > >>
(*--------------------------------------------------------------= >> identity ---*)

TYPE
  Id =3D >> INTEGER;

PROCEDURE = >> MyId(): Id RAISES {};
(* return Id of caller >> *)


Everything = >> else I moved to the non-public ThreadInternal.i3.


> >> But in = >> Modula-3 whether an interface is unsafe or not *is* a = >> boolean.

Understood, but I still think even in unsafe code, = >> LOOPHOLE should be minimized.
C and C++ programmers are often >> taught = >> to minimize casts, esp. reinterpret_cast.
I think that guidance = >> carries over to Modula's LOOPHOLE, even if you are already >> unsafe
for = >> other reasons.

 - Jay


> To:> class=3D"Apple-converted-space"> > href=3D"mailto:jay.krell at cornell.edu">jay.krell at cornell.edu> a>
> = >> CC: 
> href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com> a>
> = >> Subject: Re: [M3devel] RC merge> class=3D"Apple-converted-space"> 
> Date: Sun, 13 >> Sep = >> 2009 02:44:50 -0700
> From:> class=3D"Apple-converted-space"> 
> href=3D"mailto:mika at async.async.caltech.edu">mika at async.async.caltech.edu >> <= >> /a>
> > span>
> = >> Jay K writes:
> ...
> >
> >Imagine you are >> a = >> somewhat prolific fairly happy C or C++ programmer. The >> w=3D
> = >> >hole world is unsafe=3D2C but recieves a fair amount of static = >> checking and i=3D
> >s therefore largely correct and >> perhaps = >> doesn't even suffer much from the l=3D
> >ack of = >> safety.
> >
> >=3D20
> >
> > >> void* = >> GetFoo(void)=3D3B=3D20
> >
> > void* = >> GetBar(void)=3D3B=3D20
> >
> >=3D20
> = >> >
> >or
> >
> >=3D20
> >> >
> = >> > Foo_t* GetFoo(void)=3D3B=3D20
> >
> > Bar_t* = >> GetBar(void)=3D3B=3D20
> >
> >=3D20
> = >> >
> >?
> >
> >=3D20
> >> >
> = >> >Definitely the second.
> >
> >=3D20
> = >> >
> >Perhaps perhaps perhaps perhaps a function should >> be = >> able to be declared to=3D
> > return an UNTRACED REF = >> Foo.Something=3D2C without actually importing Foo or =3D
> = >> >defining Something?
> >
> >=3D20
> = >> >
> >Clearly the safety of an /interface/ is more >> subtle = >> than a boolean.
> >
> >Some functions may be safe >> and = >> others unsafe.
> >
> >Even some uses of = >> functions.
> >
> >Imagine for example:
> = >> >
> >=3D20
> >
> >PROCEDURE GetFoo(): = >> UNTRACED REF Foo.Something=3D3B
> >
> >> >=3D20
> = >> >
> >Perhas a safe function could call this >> function=3D2C as = >> long as it only compa=3D
> >res the return value to = >> NIL?
> >
> >Actually storing it in a variable >> would = >> require IMPORT Foo=3D2C and if FOO is=3D
> > declared >> UNSAFE=3D2C= >> then that would
> >
> >pollute the caller. Or >> maybe = >> merely declaring a variable of UNTRACED is eno=3D
> >ugh >> to = >> wreck safety?
>> class=3D"Apple-converted-space"> 
> But in >> Modula-3 = >> whether an interface is unsafe or not *is* a boolean.
> It's >> very = >> clearly defined what it means in the Green Book.
>> class=3D"Apple-converted-space"> 
> If you don't = >> declare your GetFoo as UNSAFE you can write
>> class=3D"Apple-converted-space"> 
> VAR x :=3D >> GetFoo; = >> BEGIN (* manipulate fields of x *) END
>> class=3D"Apple-converted-space"> 
> in safe = >> code.
> > span>
> = >> Declaring GetFoo to return ADDRESS won't let you do that. >> Hence,
> = >> it's safer, if there's a safety problem with manipulating the = >> fields.
> > span>
>= >> An interface can hardly assume that it is the only one injecting = >> objects
> of type ADDRESS into the "safe world" so if you're = >> allowing the safe world
> to pass these objects back in your = >> interface you have to sanity-check
> them anyhow. You do not, = >> however, need to worry about the fields having
> been changed >> by = >> the safe code.
>> class=3D"Apple-converted-space"> 
> If you need >> some = >> more subtle properties than that you probably ought
> to be = >> writing UNSAFE code in the first place. Or is there some = >> trickery
> you can do along the lines of what we came up with >> for = >> small integers
> in pointers?
>> class=3D"Apple-converted-space"> 
> = >> Mika

= >> >> --Apple-Mail-18--321278784-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 16:17:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 14:17:23 +0000 Subject: [M3devel] $DISPLAY on Darwin In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> Message-ID: For the record, I don't think this statement about DISPLAY is true. I leave it at the default, which does resemble the wierd form shown. With older cm3 that does cause a problem and it probably/might cause some slow down (not using shared memory where it might otherwise be possible), but it seems to work ok. (I have made many errors in checkin comments, not always noted.) - Jay >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 16:39:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 14:39:11 +0000 Subject: [M3devel] CVS problems (and no checking mail) Message-ID: cvs commit: warning: editor session failed /usr/cvs/cm3/m3-ui/ui/src/xvbt/XSharedMem.m3,v <-- xvbt/XSharedMem.m3 new revision: 1.5; previous revision: 1.4 Can't locate Carp.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line 20. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/Data/Dumper.pm line 20. Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. Can't locate bytes.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. BEGIN failed--compilation aborted at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 16:43:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 14:43:16 +0000 Subject: [M3devel] CVS problems (and no checking mail) In-Reply-To: References: Message-ID: I see this "anywhere" (just checked two places): jbook2:src jay$ cvs -z3 commit -f -m "testing CVS triggers, no diff" m3makefile /usr/cvs/cm3/m3-libs/m3core/src/m3makefile,v <-- m3makefile new revision: 1.13; previous revision: 1.12 Can't locate Carp.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line 20. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/Data/Dumper.pm line 20. Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. Can't locate bytes.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. BEGIN failed--compilation aborted at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. - Jay From: jay.krell at cornell.edu To: m3-support at elego.de; m3devel at elegosoft.com Date: Wed, 16 Sep 2009 14:39:11 +0000 Subject: [M3devel] CVS problems (and no checking mail) cvs commit: warning: editor session failed /usr/cvs/cm3/m3-ui/ui/src/xvbt/XSharedMem.m3,v <-- xvbt/XSharedMem.m3 new revision: 1.5; previous revision: 1.4 Can't locate Carp.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line 20. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/Data/Dumper.pm line 20. Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. Can't locate bytes.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. BEGIN failed--compilation aborted at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 17:18:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 15:18:54 +0000 Subject: [M3devel] formsedit crash Message-ID: The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. I will confirm and further narrow this down over the next few days. I've been building various dates/versions and seeing how they act. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Wed Sep 16 20:14:01 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 16 Sep 2009 20:14:01 +0200 Subject: [M3devel] CVS problems (and no checking mail) In-Reply-To: References: Message-ID: <20090916201401.84slxeeg0kowgcgo@mail.elego.de> Hi Jay, This will be fixed shortly, sorry about that. Mike > > I see this "anywhere" (just checked two places): > > book2:src jay$ cvs -z3 commit -f -m "testing CVS triggers, no diff" > m3makefile > /usr/cvs/cm3/m3-libs/m3core/src/m3makefile,v <-- m3makefile > new revision: 1.13; previous revision: 1.12 > Can't locate Carp.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line > 20. > BEGIN failed--compilation aborted at > /usr/lib/perl/5.8/Data/Dumper.pm line 20. > Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. > Can't locate bytes.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. > Can't locate strict.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > BEGIN failed--compilation aborted at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > > > - Jay > > > > From: jay.krell at cornell.edu > To: m3-support at elego.de; m3devel at elegosoft.com > Date: Wed, 16 Sep 2009 14:39:11 +0000 > Subject: [M3devel] CVS problems (and no checking mail) > > > > > > > > > cvs commit: warning: editor session failed > /usr/cvs/cm3/m3-ui/ui/src/xvbt/XSharedMem.m3,v <-- xvbt/XSharedMem.m3 > new revision: 1.5; previous revision: 1.4 > Can't locate Carp.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line > 20. > BEGIN failed--compilation aborted at > /usr/lib/perl/5.8/Data/Dumper.pm line 20. > Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. > Can't locate bytes.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. > Can't locate strict.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > BEGIN failed--compilation aborted at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > > > > > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Sep 18 07:19:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 05:19:25 +0000 Subject: [M3devel] the so_linger inconsistency between Posix and Windows Message-ID: I've been reading up on SO_LINGER. Search the web.. There are two or three options, depending on how you view it. onoff=0 time=ignored onoff=1 time=non-zero onoff=1 time=0 You could view this as an example of the previous. The behavior is governed by additional bits. - does the socket of buffered unset data? - is the socket blocking? Some options result in the socket being "immediately" closed and unsent buffered data not being sent, and I think possibly the other side getting an error. Some options have close return immediately but send the buffered data in the "background". This I believe is the default. Some options have close block waiting for send to finish. This has pluses/minuses. The minus is -- what timeout to use? A plus and minus is, I believe, there is an opportunity for close to timeout and fail, letting the caller know that there was a failure to deliver data. It is good to know about failure, though you'd want to know if the code was ready to somehow handle the failure. onoff=0 seems "best". onoff=1, time=0 seems "bad". onoff=1, time="large" seems "ok", depending on how large. I think onoff=0 is the default. I will verify that with some getsockopt runs. If it is the default, I think we should just remove the setsockopt(so_linger) code. One might also imagine that 1 second is not a short time, so even the Windows code isn't far off from the Posix code. The only big change would be setting 1,0 or removing setting of 1,0. What I wish we had but don't know if we have, is some major Modula-3 user of sockets on both Posix and Windows, so that the change can be tested. I think there is a basic problem in networking code, of unreliability and inconsistent timing. You don't know how long to wait for something to occur, when to give up waiting and deciding it failed. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 18 09:49:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 07:49:18 +0000 Subject: [M3devel] formsedit crash Message-ID: I have it further narrowed down to the last two weeks of 1/2007. Which is just a few changes. I fear it is the switch from user threads to pthreads on 1/23/2007. I'll narrow it down further though, and then try user threads on Solaris (which will probably require repairing initialization order to make them work again anyway). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: formsedit crash Date: Wed, 16 Sep 2009 15:18:54 +0000 The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. I will confirm and further narrow this down over the next few days. I've been building various dates/versions and seeing how they act. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Sep 18 11:37:48 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 18 Sep 2009 11:37:48 +0200 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: <1253266668.2779.27.camel@faramir.m3w.org> I've had some funny race/thread-order conditions when I was switching to pthreads.... Someone lazy got too grooved in with fixed order of execution implied by how user threads work. It was in pp package and also somewhere I can't remember right now... Will look a bit through hm3 svn (dead in house spinoff of pm3 from times when all mainstream m3 had was user threads). On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > I have it further narrowed down to the last two weeks of 1/2007. > Which is just a few changes. > I fear it is the switch from user threads to pthreads on 1/23/2007. > I'll narrow it down further though, and then try user threads on > Solaris > (which will probably require repairing initialization order to make > them work > again anyway). > > - Jay > > > > ______________________________________________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: formsedit crash > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > The formsedit crash appears to have started between 12/1/2006 and > 3/1/2007. > I will confirm and further narrow this down over the next few days. > I've been building various dates/versions and seeing how they act. > > - Jay > > > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Sep 18 12:12:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 10:12:18 +0000 Subject: [M3devel] formsedit crash In-Reply-To: <1253266668.2779.27.camel@faramir.m3w.org> References: Message-ID: I thought about this a little..but..don't Modula-3 user threads preempt at arbitrary points? - Jay > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 18 Sep 2009 11:37:48 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] formsedit crash > > I've had some funny race/thread-order conditions when I was switching to > pthreads.... Someone lazy got too grooved in with fixed order of > execution implied by how user threads work. It was in pp package and > also somewhere I can't remember right now... Will look a bit through hm3 > svn (dead in house spinoff of pm3 from times when all mainstream m3 had > was user threads). > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > > I have it further narrowed down to the last two weeks of 1/2007. > > Which is just a few changes. > > I fear it is the switch from user threads to pthreads on 1/23/2007. > > I'll narrow it down further though, and then try user threads on > > Solaris > > (which will probably require repairing initialization order to make > > them work > > again anyway). > > > > - Jay > > > > > > > > ______________________________________________________________________ > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: formsedit crash > > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > > > The formsedit crash appears to have started between 12/1/2006 and > > 3/1/2007. > > I will confirm and further narrow this down over the next few days. > > I've been building various dates/versions and seeing how they act. > > > > - Jay > > > > > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 18 14:45:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Sep 2009 08:45:18 -0400 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: Jay, formsedit now works for me on I386_DARWIN. Not sure what you are trying to track down now. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 03:49, Jay K wrote: > I have it further narrowed down to the last two weeks of 1/2007. > Which is just a few changes. > I fear it is the switch from user threads to pthreads on 1/23/2007. > I'll narrow it down further though, and then try user threads on > Solaris > (which will probably require repairing initialization order to make > them work > again anyway). > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: formsedit crash > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > The formsedit crash appears to have started between 12/1/2006 and > 3/1/2007. > I will confirm and further narrow this down over the next few days. > I've been building various dates/versions and seeing how they act. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 18 14:47:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Sep 2009 08:47:44 -0400 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: Not exactly. The inCritical counter means there are lots of places that serialize. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 06:12, Jay K wrote: > I thought about this a little..but..don't Modula-3 user threads > preempt at arbitrary points? > > - Jay > > > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Fri, 18 Sep 2009 11:37:48 +0200 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] formsedit crash > > > > I've had some funny race/thread-order conditions when I was > switching to > > pthreads.... Someone lazy got too grooved in with fixed order of > > execution implied by how user threads work. It was in pp package and > > also somewhere I can't remember right now... Will look a bit > through hm3 > > svn (dead in house spinoff of pm3 from times when all mainstream > m3 had > > was user threads). > > > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > > > I have it further narrowed down to the last two weeks of 1/2007. > > > Which is just a few changes. > > > I fear it is the switch from user threads to pthreads on > 1/23/2007. > > > I'll narrow it down further though, and then try user threads on > > > Solaris > > > (which will probably require repairing initialization order to > make > > > them work > > > again anyway). > > > > > > - Jay > > > > > > > > > > > > > ______________________________________________________________________ > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Subject: formsedit crash > > > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > > > > > The formsedit crash appears to have started between 12/1/2006 and > > > 3/1/2007. > > > I will confirm and further narrow this down over the next few > days. > > > I've been building various dates/versions and seeing how they act. > > > > > > - Jay > > > > > > > > > > > > > > -- > > Dragi?a Duri? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 18 14:47:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Sep 2009 08:47:43 -0400 Subject: [M3devel] formsedit crash In-Reply-To: <1253266668.2779.27.camel@faramir.m3w.org> References: <1253266668.2779.27.camel@faramir.m3w.org> Message-ID: Indeed, I fixed one of these races sometime back when switching to pthreads. Should be in the logs. AFAIK formsedit now works. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 05:37, Dragi?a Duri? wrote: > I've had some funny race/thread-order conditions when I was > switching to > pthreads.... Someone lazy got too grooved in with fixed order of > execution implied by how user threads work. It was in pp package and > also somewhere I can't remember right now... Will look a bit through > hm3 > svn (dead in house spinoff of pm3 from times when all mainstream m3 > had > was user threads). > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: >> I have it further narrowed down to the last two weeks of 1/2007. >> Which is just a few changes. >> I fear it is the switch from user threads to pthreads on 1/23/2007. >> I'll narrow it down further though, and then try user threads on >> Solaris >> (which will probably require repairing initialization order to make >> them work >> again anyway). >> >> - Jay >> >> >> >> ______________________________________________________________________ >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: formsedit crash >> Date: Wed, 16 Sep 2009 15:18:54 +0000 >> >> The formsedit crash appears to have started between 12/1/2006 and >> 3/1/2007. >> I will confirm and further narrow this down over the next few days. >> I've been building various dates/versions and seeing how they act. >> >> - Jay >> >> >> >> > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 18 19:50:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 17:50:33 +0000 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: formsedit on SOLgnu very often fails. With current source. -bash-3.00$ ./formsedit *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 ** I added the assert. It is that a pointer is not NIL, on the line before it is dereferenced. I've also seen this on PPC_something (Darwin?) but haven't tried recently. I might say it fails less often now, but it does still fail. The range is now narrowed down to between Jan 20 and Feb 1 2007. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 18 Sep 2009 08:45:18 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] formsedit crash Jay, formsedit now works for me on I386_DARWIN. Not sure what you are trying to track down now. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 03:49, Jay K wrote:I have it further narrowed down to the last two weeks of 1/2007. Which is just a few changes. I fear it is the switch from user threads to pthreads on 1/23/2007. I'll narrow it down further though, and then try user threads on Solaris (which will probably require repairing initialization order to make them work again anyway). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: formsedit crash Date: Wed, 16 Sep 2009 15:18:54 +0000 The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. I will confirm and further narrow this down over the next few days. I've been building various dates/versions and seeing how they act. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 18 20:07:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 18:07:38 +0000 Subject: [M3devel] formsedit crash In-Reply-To: <20090918175906.8C4991A2094@async.async.caltech.edu> References: Message-ID: There was a problem around the RC2 timeframe where garbage collection was turned off entirely. It wasn't that way for a long time, but indeed it was a very bad thing. Segfault could be due to out of memory. I think what I've been seeing is different. I've built many versions of the source tree now, including current. And the below is my finding -- SOLgnu formsedit works for very many timestamps on or prior to Jan 20 2007 and fails for very many timestamps on or after Feb 1 2007, including current. (dates are US Pacific time, don't /quite/ match up to the ChangeLog, behind about 9 hours.) Whether or not PPC_DARWIN is broken on current, not yet determined. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] formsedit crash > Date: Fri, 18 Sep 2009 10:59:06 -0700 > From: mika at async.async.caltech.edu > > > I just wanted to add that I was having enormous problems with a Trestle > application on PPC_DARWIN using sources of about six weeks ago. It was > going catatonic and leaking memory at an alarming rate (and worked > perfectly on FreeBSD/i386 using an old PM3, didn't get around to trying > with new sources). Also the occasional segfault. > > Of course I thought it was my fault, but after reviewing my code carefully > I couldn't find anything wrong, and I updated CM3 today and it looks great---no more crashing or hanging. > > Mika > > Jay K writes: > > > > > >MIME-Version: 1.0 > > > >--_20828071-d627-4e2e-af04-2e79c7e91e22_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >formsedit on SOLgnu very often fails. With current source. > > > >-bash-3.00$ ./formsedit=20 > > > > > >*** > >*** runtime error: > >*** <*ASSERT*> failed. > >*** file "../src/lego/POSIX/ScrollerVBTClass.m3"=2C line 325 > >** > > > >I added the assert. It is that a pointer is not NIL=2C on the line > >before it is dereferenced. > > > >I've also seen this on PPC_something (Darwin?) but haven't tried recently. > >I might say it fails less often now=2C but it does still fail. > > > >The range is now narrowed down to between Jan 20 and Feb 1 2007. > > > > - Jay > > > >From: hosking at cs.purdue.edu > >To: jay.krell at cornell.edu > >Date: Fri=2C 18 Sep 2009 08:45:18 -0400 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] formsedit crash > > > >Jay=2C formsedit now works for me on I386_DARWIN. Not sure what you are tr= > >ying to track down now. > > Antony Hosking | Associate Professor | Computer Science | Purdue Universit= > >y305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 49= > >4 6001 | Mobile +1 765 427 5484=20 > >On 18 Sep 2009=2C at 03:49=2C Jay K wrote:I have it further narrowed down t= > >o the last two weeks of 1/2007. > >Which is just a few changes. > >I fear it is the switch from user threads to pthreads on 1/23/2007. > >I'll narrow it down further though=2C and then try user threads on Solaris > >(which will probably require repairing initialization order to make them wo= > >rk > >again anyway). > > > > - Jay > > > > > >From: jay.krell at cornell.edu > >To: m3devel at elegosoft.com > >Subject: formsedit crash > >Date: Wed=2C 16 Sep 2009 15:18:54 +0000 > > > >The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. > >I will confirm and further narrow this down over the next few days. > >I've been building various dates/versions and seeing how they act. > > > > - Jay > > > > > > > > > > > > = > > > >--_20828071-d627-4e2e-af04-2e79c7e91e22_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >formsedit on SOLgnu very often fails. With current source.

-bash-3.0= > >0$ ./formsedit


***
*** runtime error:
*** =3B =3B= > > =3B <=3B*ASSERT*>=3B failed.
*** =3B =3B =3B file "= > >../src/lego/POSIX/ScrollerVBTClass.m3"=2C line 325
**

I added the= > > assert. It is that a pointer is not NIL=2C on the line
before it is der= > >eferenced.

I've also seen this on PPC_something (Darwin?) but haven'= > >t tried recently.
I might say it fails less often now=2C but it does sti= > >ll fail.

The range is now narrowed down to between Jan 20 and Feb 1 = > >2007.

 =3B - Jay


From: hosking at cs= > >.purdue.edu
To: jay.krell at cornell.edu
Date: Fri=2C 18 Sep 2009 08:45:= > >18 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] formsedit c= > >rash

Jay=2C formsedit now works for me on I386_DARWIN.  =3BNot s= > >ure what you are trying to track down now.

>Apple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0= > >=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B">
>d=3B"> >e=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= > >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= > >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= > >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>word-wrap: break-word=3B"> >er-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica= > >=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-w= > >eight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-inde= > >nt: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px= > >=3B"> >=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B= > > font-style: normal=3B font-variant: normal=3B font-weight: normal=3B lette= > >r-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transf= > >orm: none=3B white-space: normal=3B word-spacing: 0px=3B"> >xApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0= > >=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B"> >" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= > >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= > >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= > >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= > >d-spacing: 0px=3B"> >apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= > >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= > >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= > >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= > >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= > >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= > >ne=3B white-space: normal=3B word-spacing: 0px=3B"> >style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B">
>lass=3D"ecxApple-style-span" face=3D"Gill Sans"> >le-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B"= > >> >font-family: 'Gill Sans'=3B">Antony Hosking >t class=3D"ecxApple-style-span" face=3D"Gill Sans"> >style-span" style=3D"font-family: 'Gill Sans'=3B"> >tyle-span" style=3D"font-family: 'Gill Sans'=3B"> >nverted-space"> =3B|&nb= > >sp=3B >-family: 'Gill Sans'=3B"> >family: 'Gill Sans'=3B">Associate Professor >Apple-style-span" style=3D"font-family: 'Gill Sans'=3B"> >pple-style-span" style=3D"font-family: 'Gill Sans'=3B"> =3B| Computer S= > >cience | Purdue University
>xApple-style-span" face=3D"GillSans-Light"> >an" style=3D"font-family: GillSans-Light=3B">305 N. University Street | Wes= > >t Lafayette | IN 47907 | USA
>e-style-span" color=3D"#0000ff" face=3D"Gill Sans"> >style-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'= > >=3B"> >=3B font-family: 'Gill Sans'=3B">Office >ecxApple-style-span" face=3D"GillSans-Light"> >span" style=3D"font-family: GillSans-Light=3B"> >e-span" style=3D"font-family: GillSans-Light=3B"> =3B+1 765 494 6001 |<= > >span class=3D"ecxApple-converted-space"> =3B >><= > >span class=3D"ecxApple-style-span" style=3D"color: rgb(0=2C 0=2C 255)=3B fo= > >nt-family: 'Gill Sans'=3B"> >or: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">Mobile= > > >ass=3D"ecxApple-style-span" style=3D"font-family: GillSans-Light=3B"> >class=3D"ecxApple-style-span" style=3D"font-family: GillSans-Light=3B"> >n class=3D"ecxApple-converted-space"> =3B+1 765 427 5484<= > >/span>
>s-Light">
>n>

>ine">

>line">

On 18 Sep 2009=2C at 03:49=2C Jay K wrote:
= > >
>ple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: medium=3B font-style: normal=3B = > >font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B li= > >ne-height: normal=3B text-indent: 0px=3B text-transform: none=3B white-spac= > >e: normal=3B word-spacing: 0px=3B">
>t-size: 10pt=3B font-family: Verdana=3B">I have it further narrowed down to= > > the last two weeks of 1/2007.
Which is just a few changes.
I fear it= > > is the switch from user threads to pthreads on 1/23/2007.
I'll narrow i= > >t down further though=2C and then try user threads on Solaris
(which wil= > >l probably require repairing initialization order to make them work
agai= > >n anyway).

 =3B- Jay



From:= > > =3B
>ay.krell at cornell.edu">jay.krell at cornell.edu
To: >le-converted-space"> =3B >>m3devel at elegosoft.com
Subject: formsedit crash
Date: Wed=2C 16 S= > >ep 2009 15:18:54 +0000

The formsedit crash appears to have started b= > >etween 12/1/2006 and 3/1/2007.
I will confirm and further narrow this do= > >wn over the next few days.
I've been building various dates/versions and= > > seeing how they act.

 =3B- Jay




= > >

> >= > > > >--_20828071-d627-4e2e-af04-2e79c7e91e22_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Sep 19 00:40:15 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 19 Sep 2009 00:40:15 +0200 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: <1253313616.6910.2.camel@faramir.m3w.org> Not only inCritical, user space threads are in circular list and scheduler runs (in circles :) ) through it. Meaning, if B comes after A and before C, it's always executed before C after A's timeslice- if ready. On Fri, 2009-09-18 at 08:47 -0400, Tony Hosking wrote: > Not exactly. The inCritical counter means there are lots of places > that serialize. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > On 18 Sep 2009, at 06:12, Jay K wrote: > > > I thought about this a little..but..don't Modula-3 user threads > > preempt at arbitrary points? > > > > - Jay > > > > > > > From: dragisha at m3w.org > > > To: jay.krell at cornell.edu > > > Date: Fri, 18 Sep 2009 11:37:48 +0200 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] formsedit crash > > > > > > I've had some funny race/thread-order conditions when I was > > switching to > > > pthreads.... Someone lazy got too grooved in with fixed order of > > > execution implied by how user threads work. It was in pp package > > and > > > also somewhere I can't remember right now... Will look a bit > > through hm3 > > > svn (dead in house spinoff of pm3 from times when all mainstream > > m3 had > > > was user threads). > > > > > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > > > > I have it further narrowed down to the last two weeks of 1/2007. > > > > Which is just a few changes. > > > > I fear it is the switch from user threads to pthreads on > > 1/23/2007. > > > > I'll narrow it down further though, and then try user threads on > > > > Solaris > > > > (which will probably require repairing initialization order to > > make > > > > them work > > > > again anyway). > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > From: jay.krell at cornell.edu > > > > To: m3devel at elegosoft.com > > > > Subject: formsedit crash > > > > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > > > > > > > The formsedit crash appears to have started between 12/1/2006 > > and > > > > 3/1/2007. > > > > I will confirm and further narrow this down over the next few > > days. > > > > I've been building various dates/versions and seeing how they > > act. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > -- > > > Dragi?a Duri? > > > > > > -- Dragi?a Duri? From mbishop at esoteriq.org Sat Sep 19 01:22:06 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 18 Sep 2009 18:22:06 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? Message-ID: <4AB4161E.6050900@esoteriq.org> Why does everything install into /usr/local/cm3/* ? I tried editing my PATH variable to get the cm3 binary in there, but I still have to 'source /etc/profile' with every shell. And if I symlink it, it causes problems. Is there a reason to not just install to normal positions like /usr/bin and /usr/lib, etc? Is it possible to tell cminstall where to install other the default /usr/local/cm3 ? From jay.krell at cornell.edu Sun Sep 20 01:31:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Sep 2009 23:31:18 +0000 Subject: [M3devel] Utime.struct_tm Message-ID: struct_tm = RECORD tm_sec: int; tm_min: int; tm_hour: int; tm_mday: int; tm_mon: int; tm_year: int; tm_wday: int; tm_yday: int; tm_isdst: int; (* here *) tm_gmtoff:INTEGER; tm_zone: char_star; END; ? The fields after tm_isdst are not always present, and perhaps not always in that order. Portable code, Modula-3, C, or otherwise, cannot refer to those last two fields. C can do it with #ifdefs or autoconf-assisted and with some alternative if they are not present. ? What to do? Generally the vast majority of platform-dependency should and has been removed from the system, for much easier (and therefore generally more correct) porting. ? Today we declare struct_tm per-target. Most targets do declare the fields, but: Cygwin, Irix, HP-UX, Interix, Solaris do not. "Most" therefore leaves at least Linux, *BSD, Darwin. I do hope to bring up a few more targets, which may contribute to one set or the other. ? And I just checked that Solaris really doesn't provide the fields in C, so we can claim that mainstream platforms are part of the "problem". ? There are a few options: - leave it as system-dependent; my least favorite - define it to have the common prefix and provide copying C wrappers This allows for some portable uses. You can't just define the common prefix and allow direct calls, as that would corrupt the stack where it is an output. This would not allow for embedding the struct in any target-defined structs, but that probably never occurs. - remove it from m3core and all functions that traffic in it -- localtime, mktime, etc. This is my favorite. ok? Anyone that needs this functionality can chose from using interface Date, or writing portable C. I'm going to go ahead and do this. ok? ? And in any case, rewrite m3-libs\m3core\src\time in #ifdef'ed C, at least wherever struct_tm is used. I'm going to go ahead and do this. ok? ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 20 03:23:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 01:23:06 +0000 Subject: [M3devel] porting documentation? Message-ID: Hey, I've started writing up some new porting instructions. Can I get someone to try testing them out? By actually porting to a new platform? While I haven't really looked into this, I'm betting that I386_DFLYBSD or AMD64_DFLYBSD might be a good first choice? (DragonFly BSD, suggested platform names welcome) I would suggest you - install it in a virtual machine - work from a system with fast fork (ie: anything other than Cygwin) Anyone who has ported CM3 in the past is barred from this invitation. :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 20 05:24:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 03:24:58 +0000 Subject: [M3devel] Juno/win32threads Message-ID: Tony, the behavior still seems the same. (a74.f50): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c edi=00200000 eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 m3core!Thread__Join+0x14b: 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds:0023:001ffffc=???????? 0:000> 0:000> r edi edi=00200000 Can you maybe debug this on birch? I can e.g. put debuggers at \bin\x86\cdb (just install them locally which involves some GUI, then tar/gz them up and untar/gz..you don't need the installer to run, can just copy them around) and then you can like: ssh hudson at birch.elegosoft.com ssh elego at localhost2 /cygdrive/c/bin/x86/cdb ./Juno.exe Just be sure not to run Juno outside of a debugger..not sure what will happen, but you won't be able to see it. Or, feel free to commit some version that uses RTIO a bunch and I can send you the output. Slow turnaround that way. Clearly nobody is using any of this stuff.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 00:28:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 22:28:21 +0000 Subject: [M3devel] time.h reentrancy? Message-ID: Does anyone understand how the time.h *_r functions are supposed to behave wrt the char* tm_zone field in struct tm? This interface seems broken. Posix doesn't include the tm_zone field, so it is self-consistent. I think therefore even though DateBsd.m3 uses the _r functions, it should serialize. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 00:54:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 22:54:09 +0000 Subject: [M3devel] time.h reentrancy? In-Reply-To: References: Message-ID: My plan here is roughly: copy Utime.i3 to UtimeInternal.i3. Keeping only functions that traffic in struct_tm. In Utime.i3 define a struct_tm that doesn't have tm_zone and tm_gmtoff. UtimeInternal.i3 define a struct_tm that does include tm_zone and tm_gmtoff. Provide UtimeInternal.i3 only on platforms that use DateBsd.m3. Utime.i3 will therefore be portable. Both of them will be implemented via copying wrappers though, since the order of the fields, and the exact size of the struct, is not portable. Probably as well only the *_r functions should be provided? Not clear, since the non *_r functions have optional extra side affects such as setting tznzme. Probably keep the non *_r functions but callers must know to (maybe) serialize them. As DatePosix.m3/DateBsd.m3 do. I think most libc implementations use thread locals here, so the need to serialize is nearly zero. However there are user threads and timezone/daylight/tzname to worry about, not sure they are thread locals, or only the "direct result buffers". This area is really a mess. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 20 Sep 2009 22:28:21 +0000 Subject: [M3devel] time.h reentrancy? Does anyone understand how the time.h *_r functions are supposed to behave wrt the char* tm_zone field in struct tm? This interface seems broken. Posix doesn't include the tm_zone field, so it is self-consistent. I think therefore even though DateBsd.m3 uses the _r functions, it should serialize. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 21 04:04:20 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Sep 2009 22:04:20 -0400 Subject: [M3devel] Juno/win32threads In-Reply-To: References: Message-ID: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> I don't think anything I changed affects Windows. On 19 Sep 2009, at 23:24, Jay K wrote: > Tony, the behavior still seems the same. > > (a74.f50): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c > edi=00200000 > eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl zr > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010246 > m3core!Thread__Join+0x14b: > 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: > 0023:001ffffc=???????? > 0:000> > 0:000> r edi > edi=00200000 > > > Can you maybe debug this on birch? > > I can e.g. put debuggers at \bin\x86\cdb > (just install them locally which involves some GUI, then tar/gz > them up and untar/gz..you don't need the installer to run, can just > copy them around) > and then you can like: > > ssh hudson at birch.elegosoft.com > ssh elego at localhost2 > /cygdrive/c/bin/x86/cdb ./Juno.exe > > Just be sure not to run Juno outside of a debugger..not sure what > will happen, but you won't be able to see it. > > Or, feel free to commit some version that uses RTIO a bunch and I > can send you the output. > Slow turnaround that way. > Clearly nobody is using any of this stuff.. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 06:14:32 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 20 Sep 2009 21:14:32 -0700 Subject: [M3devel] Juno/win32threads In-Reply-To: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> Message-ID: <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> Eh? Tony, the thread changes from around feb 20 that you recently 'unmerged'? These crashes seem to date from around Feb, more precise info in my other mails.. - Jay (phone) On Sep 20, 2009, at 7:04 PM, Tony Hosking wrote: > I don't think anything I changed affects Windows. > > On 19 Sep 2009, at 23:24, Jay K wrote: > >> Tony, the behavior still seems the same. >> >> (a74.f50): Access violation - code c0000005 (first chance) >> First chance exceptions are reported before any exception handling. >> This exception may be expected and handled. >> eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c >> edi=00200000 >> eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl >> zr na pe nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00010246 >> m3core!Thread__Join+0x14b: >> 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: >> 0023:001ffffc=???????? >> 0:000> >> 0:000> r edi >> edi=00200000 >> >> >> Can you maybe debug this on birch? >> >> I can e.g. put debuggers at \bin\x86\cdb >> (just install them locally which involves some GUI, then tar/gz >> them up and untar/gz..you don't need the installer to run, can just >> copy them around) >> and then you can like: >> >> ssh hudson at birch.elegosoft.com >> ssh elego at localhost2 >> /cygdrive/c/bin/x86/cdb ./Juno.exe >> >> Just be sure not to run Juno outside of a debugger..not sure what >> will happen, but you won't be able to see it. >> >> Or, feel free to commit some version that uses RTIO a bunch and I >> can send you the output. >> Slow turnaround that way. >> Clearly nobody is using any of this stuff.. >> >> - Jay >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 21 15:53:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Sep 2009 09:53:56 -0400 Subject: [M3devel] Juno/win32threads In-Reply-To: <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> Message-ID: <562F0E0F-C56D-4A8F-B845-2F9E86599C37@cs.purdue.edu> OK, I've lost track, since we've been discussing two different things: the problems with pthreads which I just fixed, and the Windows threading problem. What is the time-frame that I should be looking at for that problem? On 21 Sep 2009, at 00:14, jay.krell at cornell.edu wrote: > Eh? Tony, the thread changes from around feb 20 that you recently > 'unmerged'? These crashes seem to date from around Feb, more precise > info in my other mails.. > > - Jay (phone) > > On Sep 20, 2009, at 7:04 PM, Tony Hosking > wrote: > >> I don't think anything I changed affects Windows. >> >> On 19 Sep 2009, at 23:24, Jay K wrote: >> >>> Tony, the behavior still seems the same. >>> >>> (a74.f50): Access violation - code c0000005 (first chance) >>> First chance exceptions are reported before any exception handling. >>> This exception may be expected and handled. >>> eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c >>> edi=00200000 >>> eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl >>> zr na pe nc >>> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >>> efl=00010246 >>> m3core!Thread__Join+0x14b: >>> 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: >>> 0023:001ffffc=???????? >>> 0:000> >>> 0:000> r edi >>> edi=00200000 >>> >>> >>> Can you maybe debug this on birch? >>> >>> I can e.g. put debuggers at \bin\x86\cdb >>> (just install them locally which involves some GUI, then tar/gz >>> them up and untar/gz..you don't need the installer to run, can >>> just copy them around) >>> and then you can like: >>> >>> ssh hudson at birch.elegosoft.com >>> ssh elego at localhost2 >>> /cygdrive/c/bin/x86/cdb ./Juno.exe >>> >>> Just be sure not to run Juno outside of a debugger..not sure what >>> will happen, but you won't be able to see it. >>> >>> Or, feel free to commit some version that uses RTIO a bunch and I >>> can send you the output. >>> Slow turnaround that way. >>> Clearly nobody is using any of this stuff.. >>> >>> - Jay >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 21 16:03:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Sep 2009 10:03:32 -0400 Subject: [M3devel] Juno/win32threads In-Reply-To: <562F0E0F-C56D-4A8F-B845-2F9E86599C37@cs.purdue.edu> References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> <562F0E0F-C56D-4A8F-B845-2F9E86599C37@cs.purdue.edu> Message-ID: P.S. I did commit back some changes to ThreadWin32.m3 which backed out some of 1.30. Did you try those? On 21 Sep 2009, at 09:53, Tony Hosking wrote: > OK, I've lost track, since we've been discussing two different > things: the problems with pthreads which I just fixed, and the > Windows threading problem. What is the time-frame that I should be > looking at for that problem? > > On 21 Sep 2009, at 00:14, jay.krell at cornell.edu wrote: > >> Eh? Tony, the thread changes from around feb 20 that you recently >> 'unmerged'? These crashes seem to date from around Feb, more >> precise info in my other mails.. >> >> - Jay (phone) >> >> On Sep 20, 2009, at 7:04 PM, Tony Hosking >> wrote: >> >>> I don't think anything I changed affects Windows. >>> >>> On 19 Sep 2009, at 23:24, Jay K wrote: >>> >>>> Tony, the behavior still seems the same. >>>> >>>> (a74.f50): Access violation - code c0000005 (first chance) >>>> First chance exceptions are reported before any exception handling. >>>> This exception may be expected and handled. >>>> eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c >>>> edi=00200000 >>>> eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl >>>> zr na pe nc >>>> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >>>> efl=00010246 >>>> m3core!Thread__Join+0x14b: >>>> 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: >>>> 0023:001ffffc=???????? >>>> 0:000> >>>> 0:000> r edi >>>> edi=00200000 >>>> >>>> >>>> Can you maybe debug this on birch? >>>> >>>> I can e.g. put debuggers at \bin\x86\cdb >>>> (just install them locally which involves some GUI, then tar/gz >>>> them up and untar/gz..you don't need the installer to run, can >>>> just copy them around) >>>> and then you can like: >>>> >>>> ssh hudson at birch.elegosoft.com >>>> ssh elego at localhost2 >>>> /cygdrive/c/bin/x86/cdb ./Juno.exe >>>> >>>> Just be sure not to run Juno outside of a debugger..not sure what >>>> will happen, but you won't be able to see it. >>>> >>>> Or, feel free to commit some version that uses RTIO a bunch and I >>>> can send you the output. >>>> Slow turnaround that way. >>>> Clearly nobody is using any of this stuff.. >>>> >>>> - Jay >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Sep 21 16:25:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 21 Sep 2009 16:25:12 +0200 Subject: [M3devel] back again -- cm3 status worse? Message-ID: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> Hi all, I'm back again from my trip to France. Though there seems to have been lots of activity during my absence, the current status is worse than when I left: o tinderbox status is comletely red o Hudson builds fail due to syntax errors o no tickets have been closed or even changed Does anybody care to fix? It would be nice if we could at least backup to the status of when I left... A summary about the activities/changes would be welcome. I'll need some days to read all the mails. So long, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Sep 21 22:13:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Sep 2009 20:13:21 +0000 Subject: [M3devel] Juno/win32threads In-Reply-To: References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> Message-ID: Yes that's what I was referring to. You were already looking at the right timeframe, around Feb 20 2009. Earlier mail has a 30 minute window identified. -Jay From: hosking at cs.purdue.edu To: hosking at cs.purdue.edu Date: Mon, 21 Sep 2009 10:03:32 -0400 CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] Juno/win32threads P.S. I did commit back some changes to ThreadWin32.m3 which backed out some of 1.30. Did you try those? On 21 Sep 2009, at 09:53, Tony Hosking wrote: OK, I've lost track, since we've been discussing two different things: the problems with pthreads which I just fixed, and the Windows threading problem. What is the time-frame that I should be looking at for that problem? On 21 Sep 2009, at 00:14, jay.krell at cornell.edu wrote: Eh? Tony, the thread changes from around feb 20 that you recently 'unmerged'? These crashes seem to date from around Feb, more precise info in my other mails.. - Jay (phone) On Sep 20, 2009, at 7:04 PM, Tony Hosking wrote: I don't think anything I changed affects Windows. On 19 Sep 2009, at 23:24, Jay K wrote: Tony, the behavior still seems the same. (a74.f50): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c edi=00200000 eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 m3core!Thread__Join+0x14b: 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds:0023:001ffffc=???????? 0:000> 0:000> r edi edi=00200000 Can you maybe debug this on birch? I can e.g. put debuggers at \bin\x86\cdb (just install them locally which involves some GUI, then tar/gz them up and untar/gz..you don't need the installer to run, can just copy them around) and then you can like: ssh hudson at birch.elegosoft.com ssh elego at localhost2 /cygdrive/c/bin/x86/cdb ./Juno.exe Just be sure not to run Juno outside of a debugger..not sure what will happen, but you won't be able to see it. Or, feel free to commit some version that uses RTIO a bunch and I can send you the output. Slow turnaround that way. Clearly nobody is using any of this stuff.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 22:16:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Sep 2009 20:16:22 +0000 Subject: [M3devel] back again -- cm3 status worse? In-Reply-To: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> Message-ID: Welcome back! Things are definitely a bit better, even if the high level status looks worse. But there are still imho two severe problems needing fixing for this release. - longstanding pthread problem fixed by Tony -- Darwin hangs fixed fix ported to release (head has further diverged) - Win32 threading/gui still has a problem (Juno crashing, worse than its usual assertion failure due to incomplete Trestle) date the problem started identified (around Feb 20 2009, but more precise information is known) - approx date the Solaris formsedit problem started identified unfortunately it was the switch from userthreads to pthreads (approx Jan 20 2007, probably 23) Tony looking at it. - Solaris tests or hudson were hung somewhere, I couldn't figure out what was running (seemingly nothing), rebooted the machine - Solaris not liking date +%s in pkgmap.sh I checked in a fix but messed up, that's the red in Tinderbox, testing now - I commited .msi building on release, I think it'll work, based on the console output, but waiting for an RC4 download to test. still should do .deb building - Usysdep reduction, only in head, not for this release - Jay > Date: Mon, 21 Sep 2009 16:25:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] back again -- cm3 status worse? > > Hi all, > > I'm back again from my trip to France. Though there seems to have been > lots of activity during my absence, the current status is worse > than when I left: > > o tinderbox status is comletely red > o Hudson builds fail due to syntax errors > o no tickets have been closed or even changed > > Does anybody care to fix? It would be nice if we could at least backup > to the status of when I left... > > A summary about the activities/changes would be welcome. I'll need > some days to read all the mails. > > So long, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 13:21:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 13:21:46 +0200 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Hi Randy, Tony, Jay and all others, thanks for your updates. Things already look better in Hudson and Tinderbox; there may still be some script failures which need manual intervention. As this mail is relevant for all M3 committers, I've CC'ed it to m3devel, too. I understand that a major bug (race condition in pthreads) has been fixed, but there are still some problems in Windows' threads and Solaris' formsedit which are currently investigated. I'll try to add some information of your summaries to the Trac roadmap soon. I think the main problem currently for release engineering is in procedure: we all need to agree to use the same tools and rules for proper collaboration. I know that I may have introduced a bit much in this respect for the small M3 community, but the m3devel list really proved inadequate at least for me to accomplish the tasks related to release engineering for 5.8. So I suggest we use all the available tools (Tinderbox, Hudson, Trac) at least for this release (and may improve the tools and procedures later). Very likely I haven't provided enough information regarding the tool use and intended procedure though, so I'll try to sum up some important points for everybody (again?): o Release engineering is performed on the cm3_branch_release_5_8. This should decouple (stabilizing) bug fixes from potentially destabilizing other commits. CVS is still used for version control; the steps needed to perform merges to the release branch are 'cvs update -j rev' (two point merge) or 'cvs update -j rev -j rev' (three point merge, general case). All merges in CVS are performed in a local workspace and need to be committed explicitly (after local testing, at least proper compilation). o The continuous integration in Hudson I tried to set up during the recent months is currently tracking the release branch and should be used as an indicator for the release quality. o After every commit to the release branch the developer involved should observe the results in the Hudson CI. The lastok-build and release-build jobs on all platforms should succeed (color blue); some tests may be expected to fail (color yellow). None of the main jobs should be read at any time (network communication problems may lead to failures though, usually indicated by `failed to join the process' in the console log). In case of any regression (build failures, more test failures), the problem should either be fixed or the changes reverted (until something better is available). o Anybody logged-in to Hudson can also start jobs manually with the build button. This should be used with case though. In general, jobs should be triggered by CVS checkins. o Trac is used to manage the procedural aspects of the release engineering process, i.e. define milestones and create, change and close tickets for issues related to bugs and other tasks. It also contains a WiKi for project documentation and is integrated with CVS and Hudson. It should be easy to use, but the current setup still has some problems (manual administration needed). Everybody who participates in source changes should also have access to trac and update related tickets at the same time. Indeed, for release engineering there should be no commit at all without an associated ticket. o The release engineer's role I'm trying to perform for the current release does mainly include janitorial services like merging fixes, writing scripts for package builds and tests, performing builds and installation and other tests. This is more than enough work for one person; others are expected to analyze failures and collaborate by providing the changes and information needed via the established tools and procedures. I think the current setup, though still a bit fragile, should be a quite good base for building and documenting a usable CM3 release. I'm not able to perform the required tasks just based on the commit and m3devel mails (I'm often even unable to read them all, and doubt others will do better there). So please use all the installed tools as best as you can. As concrete steps to continue with the 5.8 release I suggest these: (1) Review of all open tickets and appropriate updates and comments. See https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+Release+5.8+RC3 and https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+release+5.8 (links from the roadmap page of trac) (2) Create missing tickets for problems not yet described. Add complete information (error messages, stack traces etc.). Jay's list suggest a couple of new tickets I think. (3) Abandon the RC3 pacakges and retarget everything to RC4 in two or three weeks. (4) Retarget the final release to the end of October (at least). Does this sound reasonable? All help and cooperations is greatly appreciated as usual. Especially anybody to help creating and updating tickets for everything reported on m3devel and m3commit would be welcome. Olaf Quoting Tony Hosking : > I am confident that pthread-based threading is now better than it has > ever been (there was a nasty race that has been thoroughly fixed, and > the logic is now much simpler to understand). It runs all the X11 > apps (juno, mentor, formsedit) without problems. In sum, I think > pthread threading is ready for prime-time. I have never made more > than trivial changes to the WIN32 threads implementation. I don't > know the current state of things there, but hope that our Windows > enthusiasts can test things thoroughly. > > On 21 Sep 2009, at 10:46, Randy Coleburn wrote: > >> Olaf: >> >> I ran a build last night on both XP and Vista. I have not noticed >> any new problems on these platforms. I note that Jay has added >> more commits since last night, so I haven't tried these yet. (I >> am pulling from the head branch for these builds.) >> >> Also, I note that Jay says he is going to rewrite some of the Date >> stuff into C--again I would like to ask why, but I don't want to >> be seen as causing problems. Perhaps he should say why he feels >> it necessary to recode in C versus fixing whatever problem exists >> in Modula-3. I would be willing to work on any Modula-3 coding >> problem if given the chance. >> >> I am concerned about all the message traffic of late about >> suspected problems with the threading. I use threads a lot and if >> they aren't working correctly this is going to be a real problem. >> I ran a quick test using one of my multithreaded programs, but >> didn't see any problem. Unfortunately, this program requires >> connection to some specialized hardware that I don't have access >> to in order to give it a real workout. >> >> Regards, >> Randy >> >>>>> Olaf Wagner 9/21/2009 10:25 AM >>> >> Hi all, >> >> I'm back again from my trip to France. Though there seems to have been >> lots of activity during my absence, the current status is worse >> than when I left: >> >> o tinderbox status is comletely red >> o Hudson builds fail due to syntax errors >> o no tickets have been closed or even changed >> >> Does anybody care to fix? It would be nice if we could at least backup >> to the status of when I left... >> >> A summary about the activities/changes would be welcome. I'll need >> some days to read all the mails. >> >> So long, >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 22 13:55:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 11:55:36 +0000 Subject: [M3devel] web page messed up Message-ID: Olaf, this page: http://www.modula3.com/cm3/index.html has a glaring problem right at the start. I checked in a fix weeks ago. How does one get the update to appear? I'm referring to the nested frames. Surely that was a typo. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 14:16:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 12:16:25 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 15:21:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 15:21:16 +0200 Subject: [M3devel] web page messed up In-Reply-To: References: Message-ID: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> Quoting Jay K : > Olaf, this page: > > http://www.modula3.com/cm3/index.html > > has a glaring problem right at the start. It displays OK for me using Firefox and Opera. What's the problem? I won't say it looks good, but it displays its info ;-) > I checked in a fix weeks ago. > How does one get the update to appear? Copy the file to the web servers root on birch. However, only do this if you are really sure (locally tested etc.). It's the same procedure as for the releng packages, only the path is shorter. > I'm referring to the nested frames. > > Surely that was a typo. > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Tue Sep 22 15:40:12 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 09:40:12 -0400 Subject: [M3devel] web page messed up In-Reply-To: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> References: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> Message-ID: <4AB89AD2.1E75.00D7.1@scires.com> In IE, I see a box on the home page with horizontal and vertical scroll bars. Inside the box it has News items. This box doesn't appear to be resizable, so it is much smaller than the rest of the window when the window is maximized. Not sure if this is the desired behavior, but I don't like it. I also don't like the sea-sick green color scheme. IMO it is harder to read the text. I liked the prior "yellow and white" scheme better than this one. But, you won't please everybody no matter what you do. To me the most important thing now is content, so you haven't heard me complaining about the colors (at least not until now, sorry). On Firefox on Vista, the News box has same behavior as in IE. --Randy >>> Olaf Wagner 9/22/2009 9:21 AM >>> Quoting Jay K : > Olaf, this page: > > http://www.modula3.com/cm3/index.html > > has a glaring problem right at the start. It displays OK for me using Firefox and Opera. What's the problem? I won't say it looks good, but it displays its info ;-) > I checked in a fix weeks ago. > How does one get the update to appear? Copy the file to the web servers root on birch. However, only do this if you are really sure (locally tested etc.). It's the same procedure as for the releng packages, only the path is shorter. > I'm referring to the nested frames. > > Surely that was a typo. > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 15:38:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 13:38:19 +0000 Subject: [M3devel] web page messed up In-Reply-To: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> References: Message-ID: It is bad for me in Firefox. The frames are nested. See: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/www/start.html.diff?r1=1.3.2.2;r2=1.3.2.3;f=u - Jay > Date: Tue, 22 Sep 2009 15:21:16 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: web page messed up > > Quoting Jay K : > > > Olaf, this page: > > > > http://www.modula3.com/cm3/index.html > > > > has a glaring problem right at the start. > > It displays OK for me using Firefox and Opera. What's the problem? > I won't say it looks good, but it displays its info ;-) > > > I checked in a fix weeks ago. > > How does one get the update to appear? > > Copy the file to the web servers root on birch. However, only do this > if you are really sure (locally tested etc.). It's the same procedure > as for the releng packages, only the path is shorter. > > > I'm referring to the nested frames. > > > > Surely that was a typo. > > > > - Jay > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 15:45:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 15:45:55 +0200 Subject: [M3devel] Fwd: Re: CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Message-ID: <20090922154555.d98ygvj34kwosogo@mail.elegosoft.com> Forward to list as it may be of interest for others: ----- Forwarded message from wagner at elegosoft.com ----- Date: Tue, 22 Sep 2009 15:44:05 +0200 From: Olaf Wagner Reply-To: Olaf Wagner Subject: Re: [M3devel] CM3 5.8 Release Engineering,was Re: back again -- cm3 status worse? To: Randy Coleburn Quoting Randy Coleburn : > Olaf: > > You stated the following about CVS: > >>>> Olaf Wagner wagner at elegosoft.com> 9/22/2009 7:21 AM >> ( >>>> mailto:wagner at elegosoft.com> ) > ... > o Release engineering is performed on the cm3_branch_release_5_8. > This should decouple (stabilizing) bug fixes from potentially > destabilizing other commits. CVS is still used for version control; > the steps needed to perform merges to the release branch are > 'cvs update -j rev' (two point merge) or 'cvs update -j rev -j rev' > (three point merge, general case). All merges in CVS are performed > in a local workspace and need to be committed explicitly (after > local testing, at least proper compilation). > ... > > I'm sorry, but I'm not fully up-to-speed on all these various CVS > options, particularly with branching and merging. I've tried to > better understand it by reading some of the TortoiseCVS > documentation, but alas, it leaves much to be desired. No problem, I'll try to explain it in more detail. > Am I to understand that we should continue to commit changes to the > repository as before (I suppose this is the HEAD branch), then for > those changes that pertain to the release, we have to merge the > changes from the head to the release branch using one of the options > you mention? Both options are possible: (a) fix on the main trunk, then merge into release branch (b) fix directly on the release branch, back merge after the release (or just later) Anyway the merge takes place in the local workspace and should be tested locally before commit. I'll care for (b) sometime after the release. > Not sure what 2-point and 3-point merges are all about. The general case when merging looks like this: a -> b -> c -> d -> e -> f (trunk head) \->p -> q -> r -> s (branch tip) Suppose you want to merge the changes from d to e into the branch. (1) You update your workspace to the branch: cvs up -r (2) You merge in the changes (`join'): cvs up -j d -j e (3) compile and test (4) Commit to the branch (thereby creating version t): cvs commit -m 'merge changes from d to e from the main trunk' This is called a three-point-merge because you explicitly specify the start, end, and target versions. If you leave out one of the -j options above, CVS implicitly assumes the common ancestor of the versions involved as the third point (in this case b). So `cvs up -j e' would merge the changes from b to e into the workspace. Two more examples (same scenario): o To merge the changes from c to f just specify these versions: cvs up -j c -j f o To revert the change committed as q use cvs up -j q -j p which applies the inverse delta to the workspace (note the order). Does this explain it more clearly? If anybody is unsure how to merge, I'm happy if he (or she) sends me two tags or file versions for inclusion into the release branch. Two simple rules: o It is always a good idea to tag any commit with a unique tag (label). o If more than one file is involved, tags are more or less mandatory (as lists of pairs of versions for every file are very tedious to handle). I'm afraid I don't know offhand how to merge in TurtoiseCVS :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 22 15:47:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 13:47:35 +0000 Subject: [M3devel] m3 cvs web site slightly regressed? Message-ID: Browing CVS on the web, http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/#dirlist et. al.: - icons are x's - colors are missing in dir listing -- perhaps an improvement - preferred diff format doesn't have the coloring so can't really see it but unified view works ok. Problems seen on IE/XP and Firefox/Mac10.5. Not a big deal. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Sep 22 16:00:05 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 10:00:05 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: <4AB89F7B.1E75.00D7.1@scires.com> Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 16:02:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 16:02:36 +0200 Subject: [M3devel] the so_linger inconsistency between Posix and Windows In-Reply-To: References: Message-ID: <20090922160236.mnz8m23fusk4cokc@mail.elegosoft.com> Quoting Jay K : > What I wish we had but don't know if we have, is some major Modula-3 > user of sockets on both Posix and Windows, so that the change can be > tested. All stuff based on network objects. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 22 20:52:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 18:52:37 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4AB89F7B.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 20:57:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 18:57:27 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4AB89F7B.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? and new content: I don't like to speculate if there are problems, and if only one person sees them (even if it is me), that is close to speculation. It is good to get independent verification. You shouldn't need to test your specific code. Just run Juno under a debugger a few times and see if it access violates. Assertion failures I think are ok, unless they are asserting e.g. foo != NIL on the line before derefencing foo (as formsedit now does). - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Tue, 22 Sep 2009 18:52:37 +0000 > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Sep 22 23:06:20 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 17:06:20 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: <4AB90405.1E75.00D7.1@scires.com> Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy >>> Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? and new content: I don't like to speculate if there are problems, and if only one person sees them (even if it is me), that is close to speculation. It is good to get independent verification. You shouldn't need to test your specific code. Just run Juno under a debugger a few times and see if it access violates. Assertion failures I think are ok, unless they are asserting e.g. foo != NIL on the line before derefencing foo (as formsedit now does). - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Tue, 22 Sep 2009 18:52:37 +0000 > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 23:39:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 21:39:53 +0000 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB90405.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy >>> Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? and new content: I don't like to speculate if there are problems, and if only one person sees them (even if it is me), that is close to speculation. It is good to get independent verification. You shouldn't need to test your specific code. Just run Juno under a debugger a few times and see if it access violates. Assertion failures I think are ok, unless they are asserting e.g. foo != NIL on the line before derefencing foo (as formsedit now does). - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Tue, 22 Sep 2009 18:52:37 +0000 > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 22 23:46:21 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 17:46:21 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: > > Again, what I see is that many versions before around Feb 20 2007 > consistently fail with that same assertion failure. > > I have tested many versions now, recently. > > But versions after Feb 20 2007 usually access violate on the address > 0x20000 or so, sometimes other addresses, sometimes various > assertion failures. I believe this is much worse than merely always > failing the same assertion. > > > > - Jay > > > > Date: Tue, 22 Sep 2009 17:06:20 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] more info on juno on windows > > > > > Do we know whether or not Juno ever worked on Windows ? > > I don't recall ever testing it on Windows. I still have a vd5.7.0 > cm3 that I used for the project I finished up last year (August > 2008). If I run Juno on this system (Windows XP SP3), Juno crashes > with an ASSERT failure at line 165 in winvbt/WinContext.m3. The > date on the juno.exe is 8/19/2008. > > Regards, > Randy > >>>> Jay K 9/22/2009 2:57 PM >>> > Here is the truncated part from the previous: > > This change, I think, causes Juno to access violate whereas before > it "only" failed assertions. > I believe it is considered fairly ok for a safe system to terminate > with an assertion failure, > that might not be a bug at all, but considered far worse to hit a > SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Sep 22 23:58:52 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 17:58:52 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> Message-ID: <4AB91054.1E75.00D7.1@scires.com> Tony: I just tried these options. Here are results: recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line 1706, while nogc gets assert in WinContext.m3 line 165. I note that the juno window begins drawing before the crash on nogc whereas it does not on paranoidgc. recent cm3 on Vista, same results as above except that it appears to reference an illegal memory location before hitting the assert in the RTCollector when using paranoidgc. old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to abort the repeating error message. Not sure if anything else happens first because it scrolls too far. For nogc, we get same behavoir as the other tests above. Regards, Randy >>> Tony Hosking 9/22/2009 5:46 PM >>> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 00:11:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 22:11:26 +0000 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB91054.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: current: nogc "works" -- always the WinContext/PushPixmap assertion failure paranoidgc is broken the same as default -- variety of assertion failures and access violations Including but NOT limited to: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 1708 *** which is in RefSanityCheck, doesn't look useful. still many access violations at 00200000-4. I think 00200000 just happens to be some pixmap data from the splash screen that clobbered some other data but I don't know. I posted a big hex dump the other week to see if anyone could confirm it looks like pixmaps. - Jay Date: Tue, 22 Sep 2009 17:58:52 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] more info on juno on windows Tony: I just tried these options. Here are results: recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line 1706, while nogc gets assert in WinContext.m3 line 165. I note that the juno window begins drawing before the crash on nogc whereas it does not on paranoidgc. recent cm3 on Vista, same results as above except that it appears to reference an illegal memory location before hitting the assert in the RTCollector when using paranoidgc. old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to abort the repeating error message. Not sure if anything else happens first because it scrolls too far. For nogc, we get same behavoir as the other tests above. Regards, Randy >>> Tony Hosking 9/22/2009 5:46 PM >>> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 03:34:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:34:06 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB91054.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> <4AB91054.1E75.00D7.1@scires.com> Message-ID: PS Running with nogc at least makes sure that you don't get the garbage collector moving things around, so it should be easier to diagnose who is doing the clobbering. Can you debug with h/w watchpoints to see who overwrites the heap. You'd need to watch the location from which the bogus reference (00200000) gets loaded, which means figuring out where the load occurred. On 22 Sep 2009, at 17:58, Randy Coleburn wrote: > Tony: > > I just tried these options. Here are results: > > recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line > 1706, while nogc gets assert in WinContext.m3 line 165. I note that > the juno window begins drawing before the crash on nogc whereas it > does not on paranoidgc. > > recent cm3 on Vista, same results as above except that it appears to > reference an illegal memory location before hitting the assert in > the RTCollector when using paranoidgc. > > old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating > assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to > abort the repeating error message. Not sure if anything else > happens first because it scrolls too far. For nogc, we get same > behavoir as the other tests above. > > Regards, > Randy > > >>> Tony Hosking 9/22/2009 5:46 PM >>> > Have you tried running with @M3nogc? And @M3paranoidgc? > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Sep 2009, at 17:39, Jay K wrote: > >> >> Again, what I see is that many versions before around Feb 20 2007 >> consistently fail with that same assertion failure. >> >> I have tested many versions now, recently. >> >> But versions after Feb 20 2007 usually access violate on the >> address 0x20000 or so, sometimes other addresses, sometimes various >> assertion failures. I believe this is much worse than merely always >> failing the same assertion. >> >> >> >> - Jay >> >> >> >> Date: Tue, 22 Sep 2009 17:06:20 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] more info on juno on windows >> >> >> >> >> Do we know whether or not Juno ever worked on Windows ? >> >> I don't recall ever testing it on Windows. I still have a vd5.7.0 >> cm3 that I used for the project I finished up last year (August >> 2008). If I run Juno on this system (Windows XP SP3), Juno crashes >> with an ASSERT failure at line 165 in winvbt/WinContext.m3. The >> date on the juno.exe is 8/19/2008. >> >> Regards, >> Randy >> >>>>> Jay K 9/22/2009 2:57 PM >>> >> Here is the truncated part from the previous: >> >> This change, I think, causes Juno to access violate whereas before >> it "only" failed assertions. >> I believe it is considered fairly ok for a safe system to terminate >> with an assertion failure, >> that might not be a bug at all, but considered far worse to hit a >> SIGSEGV > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 03:37:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:37:58 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4AB89F7B.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> <4AB89F7B.1E75.00D7.1@scires.com> Message-ID: On 22 Sep 2009, at 10:00, Randy Coleburn wrote: > Jay your message seems truncated again. > > Threads have always worked for me in the past on Windows. Do we > have some sort of tests we can run to prove correctness of > threading? Seems to me that Juno is the only thing that isn't > working right, supposedly wrt threading. Perhaps the problem lies > in Juno and not threads. Maybe Juno is misusing threads in some way > or there is a bug in something Juno uses that exhibits itself as a > thread problem. Granted, the last time I did heavy checks on my > multithreaded code on Windows was before the date you say a problem > was introduced, so maybe it is broken now. In any event, I think > some standard regression type tests would be in order here. If we > don't have them, perhaps Tony could offer some suggestions. I would > be glad to write some of these tests if given some general ideas on > what to check for. I'm not so convinced it is the threading code per se. Could be that we just tripped over it with some random change. The fact that we see problems arising with @M3nogc suggests that the clobber is outside the GC and threading code. Something deeper in the Windows VBT stuff perhaps? > I don't want to get into a big argument with you (or anyone else), > but I do take exception with your statements about Modula-3 being > "tedious, error prone, unsafe, not portable, target-specific." > Perhaps I am misinterpreting you here and you are specifically > referencing a particular set of Modula-3 code that was done poorly. > If so, then perhaps if you could explain what is wrong with the > Modula-3 code in question, one of us can step up to the plate and > make some corrections. If the SPIN folks could write an OS in > Modula-3, surely we can write the compiler and library code in > Modula-3. IMO, writing such code in Modula-3 should give us the > benefits of Modula-3 instead of the deficiencies of C. After all, > this mail list is for Modula-3 enthusiasts. We wouldn't be spending > time if we didn't think this language was great. PS Randy, in this case I think Jay is making the point that all of the Unix interfaces clones from C header files have no guarantees that they match the original C code. Jay's changes should result in a much cleaner, easier to port system, since problems in the bridging code from M3 to C will be caught by the C compiler. > > Regards, > Randy > > >>> Jay K 9/22/2009 8:16 AM >>> > > The problem with the Modula-3 code is the same as usual. > It is tedious, error prone, unsafe, not portable, target-specific. > Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. > The other -- TimePosix.m3, probably ok. > > Not tremendously so in this case, just a little. > > The idea is to drive Usysdep.i3 to empty, but the last bits might > not be worth it. > > > > > The C layer is also tedious and error-prone, and maybe unsafe, > but it is portable and target-independent, which reduces > but tedium and error-proneness. > > > > > Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. > They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) > and > the result is that the safety guaranteeds are broken. > > > > > C code wouldn't have this problem. It would #include and > fail to compile. > > > > > > Yes there is fairly definitely a problem on Windows and it dates, I > think, to this change: > > > > > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > > > > > I'll have to reconfirm that I guess. > I had checked out and built the CVS tree at many dates/times, doing > roughly > binary search, and narrowed it down to this. > > Though Tony has undone this change. > > I admit 1) I haven't really looked at the diffs either way and 2) I > don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code > very well. > > > > ???It might be worthwhile to try to rewrite ThreadWin32.m3 from > scratch, following ThreadPThread.m3 line for line and coming up with > analogs? Along with the unscalable replacement for condition > variables -- taking one global lock around certain things to get > atomiticy? (Search the web for how to implement condition variables > on Win32, you start to get an idea, though Modula-3 doesn't take > anyone else's approach..you see all the literature is very concerned > with the atomicity of certain runs of operations, that you can get > on NT4 and newer at the cost of kernel transitions > (SignalObjectAndWait?) but that Modula-3 gets by using a "giant > lock" in some places, which might be better, might be worse). > > It also might be worthwhile reimplementing for Vista or newer, > verify it at least works, even if the pre-Vista code remains > supported for pre-Vista. (Vista adds condition variables.) > > You know, if that succeeds, it pins the blame on ThreadWin32.m3. > > If it also fails, it leaves it ambiguous as to if both > "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is > elsewhere. > > > > > It /seems/ that Juno's pixmaps are getting copied over other data. > > > > > This change, I think, causes Juno to access violate whereas before > it "only" failed assertions. > > I believe it is considered fairly ok for a safe system to terminate > with an assertion failure, > that might not be a bug at all, but considered far worse to hit a > SIGSEGV From hosking at cs.purdue.edu Wed Sep 23 03:40:27 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:40:27 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: <0BD93883-9F03-442C-940F-8729D3D9D2AE@cs.purdue.edu> On 22 Sep 2009, at 08:16, Jay K wrote: > Yes there is fairly definitely a problem on Windows and it dates, I > think, to this change: > > > 2009-02-16 02:20 hosking > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. I'm not convinced that this change itself broke things, but perhaps instead exposed the brokenness. In any case, debugging this in the head will probably be easiest. If we have an example that deterministically breaks then I think we have a place to start. My suggestion for now, since it appears to trigger the problem, is to use @M3nogc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 03:43:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:43:17 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: <3337B3AE-0503-4C26-8C9E-D34376786FAF@cs.purdue.edu> On 22 Sep 2009, at 07:21, Olaf Wagner wrote: > Hi Randy, Tony, Jay and all others, > > thanks for your updates. Things already look better in Hudson and > Tinderbox; there may still be some script failures which need manual > intervention. > > As this mail is relevant for all M3 committers, I've CC'ed it to > m3devel, too. > > I understand that a major bug (race condition in pthreads) has been > fixed, but there are still some problems in Windows' threads and I've not seen anything to confirm that there are problems in Window's threads. It sounds more like an issue in the Windows VBT code. I am not skilled sufficiently to debug Window's builds (...yet. Though with time I might get there if it becomes necessary). > Solaris' formsedit which are currently investigated. I'll try to add > some information of your summaries to the Trac roadmap soon. I'll look into this. From jay.krell at cornell.edu Wed Sep 23 03:51:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 01:51:05 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <0BD93883-9F03-442C-940F-8729D3D9D2AE@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: Tony there is something a bit gray that you are missing. The behavior with @M3nogc we don't necessarily consider bad/wrong/buggy. It is a consistent assertion failure. Not an access violation. It could just be Trestle not being fully supported on Windows. Olaf says Trestle was never fully ported. I'm not sure anyone knows what is missing, and if Juno really demonstrates that or not. However, versions before Feb 20 consistently act like current versions act with @M3nogc. Before Feb 20 without @M3nogc. Current with @M3nogc. What I'd like to see is current without @M3nogc to act just as bad but no worse than before Feb 20. I think the current behavior without @M3nogc is worse. It's just "fail vs. no fail". Now, that is apples and oranges. For example, I relatively recently changed the default initial allocation size and maybe incremental allocation sizes. In particular..I forget the exact details but I think changed from malloc to VirtualAlloc, and VirtualAlloc allocates in 64K chunks. I guess I should review that..but that was more recent I think, after Feb 20. I have to check. The code was a bit flawed somehow and I improved it somehow. I forget. Almost everything is subject to rerererereview when there is a bug, granted. I agree as well that Feb 20 might have just uncovered a preexisting problem. But much is unclear and figuring this out I don't think will be easy. :( - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 22 Sep 2009 21:40:27 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? On 22 Sep 2009, at 08:16, Jay K wrote: Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'm not convinced that this change itself broke things, but perhaps instead exposed the brokenness. In any case, debugging this in the head will probably be easiest. If we have an example that deterministically breaks then I think we have a place to start. My suggestion for now, since it appears to trigger the problem, is to use @M3nogc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 04:25:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 22:25:55 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: <52E6F992-DD37-415B-AA77-7BF305E8CC11@cs.purdue.edu> On 22 Sep 2009, at 21:51, Jay K wrote: > Tony there is something a bit gray that you are missing. Yes, clearly I am missing something. > The behavior with @M3nogc we don't necessarily consider bad/wrong/ > buggy. Right, it just takes GC out of the equation for what might be wrong. > It is a consistent assertion failure. Not an access violation. Good. We can debug that. > It could just be Trestle not being fully supported on Windows. > Olaf says Trestle was never fully ported. I don't know enough about this to say either way. > I'm not sure anyone knows what is missing, and if Juno really > demonstrates that or not. > > However, versions before Feb 20 consistently act like current > versions act with @M3nogc. > Before Feb 20 without @M3nogc. > Current with @M3nogc. What does this mean? That pre-2009-02 is just the same as post-2009-02? How does that narrow anything down to that specific time-frame? > What I'd like to see is current without @M3nogc to act just as bad > but no worse than before Feb 20. I think the current behavior > without @M3nogc is worse. It's just "fail vs. no fail". I still don't understand what this says about that particular time- frame. > Now, that is apples and oranges. For example, I relatively recently > changed the default initial allocation size and maybe incremental > allocation sizes. In particular..I forget the exact details but I > think changed from malloc to VirtualAlloc, and VirtualAlloc > allocates in 64K chunks. I guess I should review that..but that was > more recent I think, after Feb 20. I have to check. > The code was a bit flawed somehow and I improved it somehow. I > forget. Almost everything is subject to rerererereview when there is > a bug, granted. > > > I agree as well that Feb 20 might have just uncovered a preexisting > problem. > > > But much is unclear and figuring this out I don't think will be > easy. :( If we have a deterministic failure then it should be easy enough to track down. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 22 Sep 2009 21:40:27 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > again -- cm3 status worse? > > > On 22 Sep 2009, at 08:16, Jay K wrote: > > Yes there is fairly definitely a problem on Windows and it dates, I > think, to this change: > > > 2009-02-16 02:20 hosking > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > I'm not convinced that this change itself broke things, but perhaps > instead exposed the brokenness. In any case, debugging this in the > head will probably be easiest. If we have an example that > deterministically breaks then I think we have a place to start. My > suggestion for now, since it appears to trigger the problem, is to > use @M3nogc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 04:46:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 22:46:30 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <52E6F992-DD37-415B-AA77-7BF305E8CC11@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> <52E6F992-DD37-415B-AA77-7BF305E8CC11@cs.purdue.edu> Message-ID: <4B9C8CCF-897C-478D-95D7-A9030AB33B92@cs.purdue.edu> What about these? They appear to be Trestle and icon-related... 2009-02-18 11:14 jkrell * m3-libs/m3core/src/win32/WinUser.i3, m3-libs/m3core/src/win32/WinUserC.c, m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ WinTrestle.m3: workaround gcc backend bug that names <*EXTERNAL WindowFromPoint:WINAPI*> PROCEDURE WindowFromPoint (Point: POINT): HWND; WindowFromPoint at 4 instead of WindowFromPoint at 8 by adding <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) { return WindowFromPoint(*Point); } This lets I386_MINGW (NT386MINGNU) get further. 2009-02-18 10:51 jkrell * m3-sys/windowsResources/src/winRes.tmpl: adapt to MinGW which has windres instead of rc with different command line usage; detect MinGW by checking if backend mode is integrated backend or not, not great..it should really be informed by a variable in the toplevel configuration -- CONFIG_HAS_RC and CONFIG_HAS_WINDRES? On 22 Sep 2009, at 22:25, Tony Hosking wrote: > On 22 Sep 2009, at 21:51, Jay K wrote: > >> Tony there is something a bit gray that you are missing. > > Yes, clearly I am missing something. > >> The behavior with @M3nogc we don't necessarily consider bad/wrong/ >> buggy. > > Right, it just takes GC out of the equation for what might be wrong. > >> It is a consistent assertion failure. Not an access violation. > > Good. We can debug that. > >> It could just be Trestle not being fully supported on Windows. >> Olaf says Trestle was never fully ported. > > I don't know enough about this to say either way. > >> I'm not sure anyone knows what is missing, and if Juno really >> demonstrates that or not. >> >> However, versions before Feb 20 consistently act like current >> versions act with @M3nogc. >> Before Feb 20 without @M3nogc. >> Current with @M3nogc. > > What does this mean? That pre-2009-02 is just the same as > post-2009-02? How does that narrow anything down to that specific > time-frame? > >> What I'd like to see is current without @M3nogc to act just as bad >> but no worse than before Feb 20. I think the current behavior >> without @M3nogc is worse. It's just "fail vs. no fail". > > I still don't understand what this says about that particular time- > frame. > >> Now, that is apples and oranges. For example, I relatively >> recently changed the default initial allocation size and maybe >> incremental allocation sizes. In particular..I forget the exact >> details but I think changed from malloc to VirtualAlloc, and >> VirtualAlloc allocates in 64K chunks. I guess I should review >> that..but that was more recent I think, after Feb 20. I have to >> check. >> The code was a bit flawed somehow and I improved it somehow. I >> forget. Almost everything is subject to rerererereview when there >> is a bug, granted. >> >> >> I agree as well that Feb 20 might have just uncovered a preexisting >> problem. >> >> >> But much is unclear and figuring this out I don't think will be >> easy. :( > > If we have a deterministic failure then it should be easy enough to > track down. > >> >> >> - Jay >> >> >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 22 Sep 2009 21:40:27 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back >> again -- cm3 status worse? >> >> >> On 22 Sep 2009, at 08:16, Jay K wrote: >> >> Yes there is fairly definitely a problem on Windows and it dates, I >> think, to this change: >> >> >> 2009-02-16 02:20 hosking >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ >> dtoa.c, >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ >> ThreadPThreadC.i3, >> thread/WIN32/ThreadWin32.m3: >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better >> match underlying pthread semantics. >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap >> is held. >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or >> not. >> >> I'm not convinced that this change itself broke things, but perhaps >> instead exposed the brokenness. In any case, debugging this in the >> head will probably be easiest. If we have an example that >> deterministically breaks then I think we have a place to start. My >> suggestion for now, since it appears to trigger the problem, is to >> use @M3nogc. >> >> > From jay.krell at cornell.edu Wed Sep 23 05:48:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 03:48:59 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4B9C8CCF-897C-478D-95D7-A9030AB33B92@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: I'm "certain" these are ok but I can try without them. 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. 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). You still aren't understanding me. We have a consistent failure before Feb 20, but it is deemed maybe ok. It was maybe always that way. It is maybe unfinished code. Not heap corruption. Though we don't know 100% and it does merit some investigation. After Feb 20 without @M3nogc we have a "more severe" and actually fairly consistent but not completely consistent failure -- heap corruption. After Feb 20 with @M3nogc acts the same as before Feb 20 without @M3nogc. - Jay > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 22 Sep 2009 22:46:30 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? > > What about these? > They appear to be Trestle and icon-related... > 2009-02-18 11:14 jkrell > > * m3-libs/m3core/src/win32/WinUser.i3, > m3-libs/m3core/src/win32/WinUserC.c, > m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ > WinTrestle.m3: > > workaround gcc backend bug that names > > <*EXTERNAL WindowFromPoint:WINAPI*> > PROCEDURE WindowFromPoint (Point: POINT): HWND; > > WindowFromPoint at 4 instead of WindowFromPoint at 8 > > by adding > > <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> > PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; > > HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) > { > return WindowFromPoint(*Point); > } > > This lets I386_MINGW (NT386MINGNU) get further. > > 2009-02-18 10:51 jkrell > > * m3-sys/windowsResources/src/winRes.tmpl: > > adapt to MinGW which has windres instead of rc with different > command line usage; detect MinGW by checking if backend mode is > integrated backend or not, not great..it should really be informed by > a variable in the toplevel configuration -- CONFIG_HAS_RC and > CONFIG_HAS_WINDRES? > > > On 22 Sep 2009, at 22:25, Tony Hosking wrote: > > > On 22 Sep 2009, at 21:51, Jay K wrote: > > > >> Tony there is something a bit gray that you are missing. > > > > Yes, clearly I am missing something. > > > >> The behavior with @M3nogc we don't necessarily consider bad/wrong/ > >> buggy. > > > > Right, it just takes GC out of the equation for what might be wrong. > > > >> It is a consistent assertion failure. Not an access violation. > > > > Good. We can debug that. > > > >> It could just be Trestle not being fully supported on Windows. > >> Olaf says Trestle was never fully ported. > > > > I don't know enough about this to say either way. > > > >> I'm not sure anyone knows what is missing, and if Juno really > >> demonstrates that or not. > >> > >> However, versions before Feb 20 consistently act like current > >> versions act with @M3nogc. > >> Before Feb 20 without @M3nogc. > >> Current with @M3nogc. > > > > What does this mean? That pre-2009-02 is just the same as > > post-2009-02? How does that narrow anything down to that specific > > time-frame? > > > >> What I'd like to see is current without @M3nogc to act just as bad > >> but no worse than before Feb 20. I think the current behavior > >> without @M3nogc is worse. It's just "fail vs. no fail". > > > > I still don't understand what this says about that particular time- > > frame. > > > >> Now, that is apples and oranges. For example, I relatively > >> recently changed the default initial allocation size and maybe > >> incremental allocation sizes. In particular..I forget the exact > >> details but I think changed from malloc to VirtualAlloc, and > >> VirtualAlloc allocates in 64K chunks. I guess I should review > >> that..but that was more recent I think, after Feb 20. I have to > >> check. > >> The code was a bit flawed somehow and I improved it somehow. I > >> forget. Almost everything is subject to rerererereview when there > >> is a bug, granted. > >> > >> > >> I agree as well that Feb 20 might have just uncovered a preexisting > >> problem. > >> > >> > >> But much is unclear and figuring this out I don't think will be > >> easy. :( > > > > If we have a deterministic failure then it should be easy enough to > > track down. > > > >> > >> > >> - Jay > >> > >> > >> > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Date: Tue, 22 Sep 2009 21:40:27 -0400 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > >> again -- cm3 status worse? > >> > >> > >> On 22 Sep 2009, at 08:16, Jay K wrote: > >> > >> Yes there is fairly definitely a problem on Windows and it dates, I > >> think, to this change: > >> > >> > >> 2009-02-16 02:20 hosking > >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > >> dtoa.c, > >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, > >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ > >> ThreadPThreadC.i3, > >> thread/WIN32/ThreadWin32.m3: > >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > >> match underlying pthread semantics. > >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap > >> is held. > >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > >> not. > >> > >> I'm not convinced that this change itself broke things, but perhaps > >> instead exposed the brokenness. In any case, debugging this in the > >> head will probably be easiest. If we have an example that > >> deterministically breaks then I think we have a place to start. My > >> suggestion for now, since it appears to trigger the problem, is to > >> use @M3nogc. > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 05:51:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 03:51:58 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4B9C8CCF-897C-478D-95D7-A9030AB33B92@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: Plus I think I narrowed the problem down to a 30 minute window, not just a day. I build like 2:00 and 2:30 on the day of the heap/lock change. But granted it might only be revealing some other problem, that was always there or recently introduced or long ago introduced... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Wed, 23 Sep 2009 03:48:59 +0000 I'm "certain" these are ok but I can try without them. 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. 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). You still aren't understanding me. We have a consistent failure before Feb 20, but it is deemed maybe ok. It was maybe always that way. It is maybe unfinished code. Not heap corruption. Though we don't know 100% and it does merit some investigation. After Feb 20 without @M3nogc we have a "more severe" and actually fairly consistent but not completely consistent failure -- heap corruption. After Feb 20 with @M3nogc acts the same as before Feb 20 without @M3nogc. - Jay > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 22 Sep 2009 22:46:30 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? > > What about these? > They appear to be Trestle and icon-related... > 2009-02-18 11:14 jkrell > > * m3-libs/m3core/src/win32/WinUser.i3, > m3-libs/m3core/src/win32/WinUserC.c, > m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ > WinTrestle.m3: > > workaround gcc backend bug that names > > <*EXTERNAL WindowFromPoint:WINAPI*> > PROCEDURE WindowFromPoint (Point: POINT): HWND; > > WindowFromPoint at 4 instead of WindowFromPoint at 8 > > by adding > > <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> > PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; > > HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) > { > return WindowFromPoint(*Point); > } > > This lets I386_MINGW (NT386MINGNU) get further. > > 2009-02-18 10:51 jkrell > > * m3-sys/windowsResources/src/winRes.tmpl: > > adapt to MinGW which has windres instead of rc with different > command line usage; detect MinGW by checking if backend mode is > integrated backend or not, not great..it should really be informed by > a variable in the toplevel configuration -- CONFIG_HAS_RC and > CONFIG_HAS_WINDRES? > > > On 22 Sep 2009, at 22:25, Tony Hosking wrote: > > > On 22 Sep 2009, at 21:51, Jay K wrote: > > > >> Tony there is something a bit gray that you are missing. > > > > Yes, clearly I am missing something. > > > >> The behavior with @M3nogc we don't necessarily consider bad/wrong/ > >> buggy. > > > > Right, it just takes GC out of the equation for what might be wrong. > > > >> It is a consistent assertion failure. Not an access violation. > > > > Good. We can debug that. > > > >> It could just be Trestle not being fully supported on Windows. > >> Olaf says Trestle was never fully ported. > > > > I don't know enough about this to say either way. > > > >> I'm not sure anyone knows what is missing, and if Juno really > >> demonstrates that or not. > >> > >> However, versions before Feb 20 consistently act like current > >> versions act with @M3nogc. > >> Before Feb 20 without @M3nogc. > >> Current with @M3nogc. > > > > What does this mean? That pre-2009-02 is just the same as > > post-2009-02? How does that narrow anything down to that specific > > time-frame? > > > >> What I'd like to see is current without @M3nogc to act just as bad > >> but no worse than before Feb 20. I think the current behavior > >> without @M3nogc is worse. It's just "fail vs. no fail". > > > > I still don't understand what this says about that particular time- > > frame. > > > >> Now, that is apples and oranges. For example, I relatively > >> recently changed the default initial allocation size and maybe > >> incremental allocation sizes. In particular..I forget the exact > >> details but I think changed from malloc to VirtualAlloc, and > >> VirtualAlloc allocates in 64K chunks. I guess I should review > >> that..but that was more recent I think, after Feb 20. I have to > >> check. > >> The code was a bit flawed somehow and I improved it somehow. I > >> forget. Almost everything is subject to rerererereview when there > >> is a bug, granted. > >> > >> > >> I agree as well that Feb 20 might have just uncovered a preexisting > >> problem. > >> > >> > >> But much is unclear and figuring this out I don't think will be > >> easy. :( > > > > If we have a deterministic failure then it should be easy enough to > > track down. > > > >> > >> > >> - Jay > >> > >> > >> > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Date: Tue, 22 Sep 2009 21:40:27 -0400 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > >> again -- cm3 status worse? > >> > >> > >> On 22 Sep 2009, at 08:16, Jay K wrote: > >> > >> Yes there is fairly definitely a problem on Windows and it dates, I > >> think, to this change: > >> > >> > >> 2009-02-16 02:20 hosking > >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > >> dtoa.c, > >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, > >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ > >> ThreadPThreadC.i3, > >> thread/WIN32/ThreadWin32.m3: > >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > >> match underlying pthread semantics. > >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap > >> is held. > >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > >> not. > >> > >> I'm not convinced that this change itself broke things, but perhaps > >> instead exposed the brokenness. In any case, debugging this in the > >> head will probably be easiest. If we have an example that > >> deterministically breaks then I think we have a place to start. My > >> suggestion for now, since it appears to trigger the problem, is to > >> use @M3nogc. > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 06:03:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Sep 2009 00:03:22 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: On 22 Sep 2009, at 23:48, Jay K wrote: > I'm "certain" these are ok but I can try without them. > 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. > > > 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). > > > You still aren't understanding me. > > We have a consistent failure before Feb 20, but it is deemed maybe ok. > It was maybe always that way. It is maybe unfinished code. Not > heap corruption. > Though we don't know 100% and it does merit some investigation. > > After Feb 20 without @M3nogc we have a "more severe" and actually > fairly consistent but not completely consistent failure -- heap > corruption. OK, now I think I begin to understand. What happens with @M3paranoidgc on the post-2009-02 code is what you sent earlier, right? Sounds like something is being collected when it should not, resulting in a dangling reference to memory that gets reused for something else. I don't think I changed anything that would affect that. I'll take another look. The M3paranoidgc flag should catch any dangling reference. Can you try with @M3noincremental and/or @M3nogenerational? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 06:32:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Sep 2009 00:32:30 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: 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? On 22 Sep 2009, at 23:51, Jay K wrote: > Plus I think I narrowed the problem down to a 30 minute window, not > just a day. > I build like 2:00 and 2:30 on the day of the heap/lock change. > But granted it might only be revealing some other problem, that was > always there or recently introduced or long ago introduced... > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back > again -- cm3 status worse? > Date: Wed, 23 Sep 2009 03:48:59 +0000 > > I'm "certain" these are ok but I can try without them. > 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. > > > 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). > > > You still aren't understanding me. > > We have a consistent failure before Feb 20, but it is deemed maybe ok. > It was maybe always that way. It is maybe unfinished code. Not > heap corruption. > Though we don't know 100% and it does merit some investigation. > > After Feb 20 without @M3nogc we have a "more severe" and actually > fairly consistent but not completely consistent failure -- heap > corruption. > > After Feb 20 with @M3nogc acts the same as before Feb 20 without > @M3nogc. > > > - Jay > > > From: hosking at cs.purdue.edu > > To: hosking at cs.purdue.edu > > Date: Tue, 22 Sep 2009 22:46:30 -0400 > > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > again -- cm3 status worse? > > > > What about these? > > They appear to be Trestle and icon-related... > > 2009-02-18 11:14 jkrell > > > > * m3-libs/m3core/src/win32/WinUser.i3, > > m3-libs/m3core/src/win32/WinUserC.c, > > m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ > > WinTrestle.m3: > > > > workaround gcc backend bug that names > > > > <*EXTERNAL WindowFromPoint:WINAPI*> > > PROCEDURE WindowFromPoint (Point: POINT): HWND; > > > > WindowFromPoint at 4 instead of WindowFromPoint at 8 > > > > by adding > > > > <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> > > PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; > > > > HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) > > { > > return WindowFromPoint(*Point); > > } > > > > This lets I386_MINGW (NT386MINGNU) get further. > > > > 2009-02-18 10:51 jkrell > > > > * m3-sys/windowsResources/src/winRes.tmpl: > > > > adapt to MinGW which has windres instead of rc with different > > command line usage; detect MinGW by checking if backend mode is > > integrated backend or not, not great..it should really be informed > by > > a variable in the toplevel configuration -- CONFIG_HAS_RC and > > CONFIG_HAS_WINDRES? > > > > > > On 22 Sep 2009, at 22:25, Tony Hosking wrote: > > > > > On 22 Sep 2009, at 21:51, Jay K wrote: > > > > > >> Tony there is something a bit gray that you are missing. > > > > > > Yes, clearly I am missing something. > > > > > >> The behavior with @M3nogc we don't necessarily consider bad/ > wrong/ > > >> buggy. > > > > > > Right, it just takes GC out of the equation for what might be > wrong. > > > > > >> It is a consistent assertion failure. Not an access violation. > > > > > > Good. We can debug that. > > > > > >> It could just be Trestle not being fully supported on Windows. > > >> Olaf says Trestle was never fully ported. > > > > > > I don't know enough about this to say either way. > > > > > >> I'm not sure anyone knows what is missing, and if Juno really > > >> demonstrates that or not. > > >> > > >> However, versions before Feb 20 consistently act like current > > >> versions act with @M3nogc. > > >> Before Feb 20 without @M3nogc. > > >> Current with @M3nogc. > > > > > > What does this mean? That pre-2009-02 is just the same as > > > post-2009-02? How does that narrow anything down to that specific > > > time-frame? > > > > > >> What I'd like to see is current without @M3nogc to act just as > bad > > >> but no worse than before Feb 20. I think the current behavior > > >> without @M3nogc is worse. It's just "fail vs. no fail". > > > > > > I still don't understand what this says about that particular > time- > > > frame. > > > > > >> Now, that is apples and oranges. For example, I relatively > > >> recently changed the default initial allocation size and maybe > > >> incremental allocation sizes. In particular..I forget the exact > > >> details but I think changed from malloc to VirtualAlloc, and > > >> VirtualAlloc allocates in 64K chunks. I guess I should review > > >> that..but that was more recent I think, after Feb 20. I have to > > >> check. > > >> The code was a bit flawed somehow and I improved it somehow. I > > >> forget. Almost everything is subject to rerererereview when there > > >> is a bug, granted. > > >> > > >> > > >> I agree as well that Feb 20 might have just uncovered a > preexisting > > >> problem. > > >> > > >> > > >> But much is unclear and figuring this out I don't think will be > > >> easy. :( > > > > > > If we have a deterministic failure then it should be easy enough > to > > > track down. > > > > > >> > > >> > > >> - Jay > > >> > > >> > > >> > > >> From: hosking at cs.purdue.edu > > >> To: jay.krell at cornell.edu > > >> Date: Tue, 22 Sep 2009 21:40:27 -0400 > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > > >> again -- cm3 status worse? > > >> > > >> > > >> On 22 Sep 2009, at 08:16, Jay K wrote: > > >> > > >> Yes there is fairly definitely a problem on Windows and it > dates, I > > >> think, to this change: > > >> > > >> > > >> 2009-02-16 02:20 hosking > > >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > > >> dtoa.c, > > >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, > > >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > > >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > > >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > > >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > > >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ > > >> ThreadPThreadC.i3, > > >> thread/WIN32/ThreadWin32.m3: > > >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > > >> match underlying pthread semantics. > > >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap > > >> is held. > > >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > > >> not. > > >> > > >> I'm not convinced that this change itself broke things, but > perhaps > > >> instead exposed the brokenness. In any case, debugging this in > the > > >> head will probably be easiest. If we have an example that > > >> deterministically breaks then I think we have a place to start. > My > > >> suggestion for now, since it appears to trigger the problem, is > to > > >> use @M3nogc. > > >> > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 23 09:30:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 09:30:22 +0200 Subject: [M3devel] package tests regression Message-ID: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> I noticed yesterday that several package build jobs failed because of wrong timestamps (probably some changed dependency). But even after cleaning everything before compilation AMD64_LINUX and FreeBSD (which should run without any errors) show some regression: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests Perhaps some missing overrides again? Or something else? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Sep 23 09:39:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 09:39:18 +0200 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> Quoting Olaf Wagner : > I noticed yesterday that several package build jobs failed because > of wrong timestamps (probably some changed dependency). But even after > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > run without any errors) show some regression: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests Tests seem to be completely messed up for Solaris (no results at all): http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run for 11 and 23 days respectively, probably due to unavailability of the build machines. I've started those now manually. xdarwin is offline currently though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 23 09:42:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 07:42:38 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: I thought I386_OPENBSD had been up pretty well. I check it every so often. There was maybe over a week of no checkins to release actually so maybe no tests then? :) I386_DARWIN I'll leave on, and AMD64_FREEBSD.. I agree about Solaris. And I was trying to fix the date/expr stuff on Solaris. - Jay > Date: Wed, 23 Sep 2009 09:39:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Olaf Wagner : > > > I noticed yesterday that several package build jobs failed because > > of wrong timestamps (probably some changed dependency). But even after > > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > > run without any errors) show some regression: > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests > > Tests seem to be completely messed up for Solaris (no results at all): > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console > > Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run > for 11 and 23 days respectively, probably due to unavailability of the > build machines. I've started those now manually. xdarwin is offline > currently though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 09:44:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 07:44:46 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: I see the problem. My fix for Solaris is quite bad. It doesn't account for the cwd changing during pkgmap. Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; export PATH and then run m3date. Or maybe you can do an awk one liner there?? I figured C was easy enough. Or just remove the date %+s altogether? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] more package tests regression Date: Wed, 23 Sep 2009 07:42:38 +0000 I thought I386_OPENBSD had been up pretty well. I check it every so often. There was maybe over a week of no checkins to release actually so maybe no tests then? :) I386_DARWIN I'll leave on, and AMD64_FREEBSD.. I agree about Solaris. And I was trying to fix the date/expr stuff on Solaris. - Jay > Date: Wed, 23 Sep 2009 09:39:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Olaf Wagner : > > > I noticed yesterday that several package build jobs failed because > > of wrong timestamps (probably some changed dependency). But even after > > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > > run without any errors) show some regression: > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests > > Tests seem to be completely messed up for Solaris (no results at all): > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console > > Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run > for 11 and 23 days respectively, probably due to unavailability of the > build machines. I've started those now manually. xdarwin is offline > currently though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 09:48:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 07:48:17 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: PPC_LINUX should also have good availability..I'll double check in a bit... (All of xlin (Linux/x86), plin (Linux/ppc), slin (Linux/sparc), ssol (Solaris/sparc), xobsd (OpenBSD/x86) should have good availability a while now; "jbook2" (Mac/amd64/x86) and its vms (afbsd (FreeBSD/AMD64)) yeah they've been off and on, I'll leave them on; there are yet other machines...). - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] more package tests regression Date: Wed, 23 Sep 2009 07:44:46 +0000 I see the problem. My fix for Solaris is quite bad. It doesn't account for the cwd changing during pkgmap. Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; export PATH and then run m3date. Or maybe you can do an awk one liner there?? I figured C was easy enough. Or just remove the date %+s altogether? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] more package tests regression Date: Wed, 23 Sep 2009 07:42:38 +0000 I thought I386_OPENBSD had been up pretty well. I check it every so often. There was maybe over a week of no checkins to release actually so maybe no tests then? :) I386_DARWIN I'll leave on, and AMD64_FREEBSD.. I agree about Solaris. And I was trying to fix the date/expr stuff on Solaris. - Jay > Date: Wed, 23 Sep 2009 09:39:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Olaf Wagner : > > > I noticed yesterday that several package build jobs failed because > > of wrong timestamps (probably some changed dependency). But even after > > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > > run without any errors) show some regression: > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests > > Tests seem to be completely messed up for Solaris (no results at all): > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console > > Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run > for 11 and 23 days respectively, probably due to unavailability of the > build machines. I've started those now manually. xdarwin is offline > currently though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 23 11:18:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 11:18:41 +0200 Subject: [M3devel] Reasoning for /usr/local/cm3 ? Message-ID: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Quoting Martin Bishop : > Why does everything install into /usr/local/cm3/* ? I tried editing my > PATH variable to get the cm3 binary in there, but I still have to > 'source /etc/profile' with every shell. And if I symlink it, it causes > problems. The paths are different on different systems. /usr/local/cm3 is just the system-specifics-ignoring default of a generic cm3 installation. System-specific packages are currently being prepared by some people, but not yet finished as far as I know. There should be mails in the archives about download locations. > Is there a reason to not just install to normal positions like /usr/bin > and /usr/lib, etc? Is it possible to tell cminstall where to install > other the default /usr/local/cm3 ? Sure. Just give cminstall the target directory as argument. It will always install a complete tree though (bin, lib, pkg, doc, www, ...). If that doesn't suffice, you may also be able to use symlinks for the main binaries in one of your PATH directories. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 23 13:23:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 11:23:20 +0000 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > problems. > Symlink should work. Symlink /usr/bin/cm3 to /usr/local/cm3/bin? Hardlinks would not likely work. /usr/local/cm3/bin is used instead of /usr/bin, because it makes it clear what goes/came together and uninstall is just a recursive delete. "uninstall is just a recursive delete" is something a lot of people like, and sometimes it is available, sometimes not. What about that PATH=/usr/local/cm3/bin:$PATH tidbits left behind in ~/.bashrc that user put in manually... Some people would use the shorter /opt/cm3. Personally I use /cm3, possibly symlinked to ~jay/cm3. (Note: symlinks not necessarily available!) I like that /opt is shorter, but there is much inertia/momentum behind /usr/local -- the default for autoconf, but granted, not /usr/local/pkg. Some folks use /opt/pkg1 /opt/pkg2 and then blow up $PATH with lots of entries. Others use symlinks into the shared /usr/bin and whatnot. Maybe others just use full paths. There is no perfect answer here. Every approach has (large, glarying) advantages and disadvantages. It is quite unfortunate but I really just try to ignore it. I believe you could spend, uh, infinite time discussing and implementing package management and as I said, you'd still have large glarying disadvantages. Of course there are various package managers that let you put everything "intermixed" in /usr and they keep track of what came from what and allow uninstall that isn't just a recursive delete. Some people use a userid per package. One more thing before I shut up ... we produce package manager indepent packages. So not much of an installer/uninstaller, no package database. I do have code to produce .deb files checked in. I should enable that soon. I'm inclined to just produce one large cm3-linux-x86.deb, cm3-linux-amd64.deb, cm3-linux-sparc.deb, etc. Not all the broken out packages that Olaf did. No dependencies. Not ubuntuv1, debianv4, etc., just claim that are fairly portable and see what happens. They could even be easily installed on non-Debian systems -- a .deb file is a very simple format esp. if you ignore the metadata file. It is as I recall an ar file with a metadata file and a nested .tar.gz or .tar.bz2 or .tar.lzma -- and due to the .tar.lzma option, much smaller than others. (And heck, we could make .debs for Darwin and Solaris; it really just takes like two lines of .sh to install them...) - Jay > Date: Wed, 23 Sep 2009 11:18:41 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ? > > Quoting Martin Bishop : > > > Why does everything install into /usr/local/cm3/* ? I tried editing my > > PATH variable to get the cm3 binary in there, but I still have to > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > problems. > > The paths are different on different systems. /usr/local/cm3 is just > the system-specifics-ignoring default of a generic cm3 installation. > System-specific packages are currently being prepared by some > people, but not yet finished as far as I know. There should be > mails in the archives about download locations. > > > Is there a reason to not just install to normal positions like /usr/bin > > and /usr/lib, etc? Is it possible to tell cminstall where to install > > other the default /usr/local/cm3 ? > > Sure. Just give cminstall the target directory as argument. > It will always install a complete tree though (bin, lib, pkg, doc, www, ...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 23 13:48:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 13:48:36 +0200 Subject: [M3devel] more package tests regression In-Reply-To: References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: <20090923134836.9axwal8pgk4k0gcc@mail.elegosoft.com> Quoting Jay K : > > I see the problem. My fix for Solaris is quite bad. > > It doesn't account for the cwd changing during pkgmap. > > Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; > export PATH and then run m3date. > > Or maybe you can do an awk one liner there?? > > I figured C was easy enough. > > Or just remove the date %+s altogether? Tests on NT386 now show === package m3-sys/libdump === /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: line 388: ./m3date: No such file or directory /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: line 391: ./m3date: No such file or directory expr: non-numeric argument (standard_in) 1: parse error for all packages :-( Perhaps you could just comment-out the date stuff for the time being (if we don't really need it)? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 23 14:11:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 12:11:24 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923134836.9axwal8pgk4k0gcc@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: I just fixed "my part". It is to get "your part" to work -- date +%s on Solaris. If your part isn't needed, definltely delete it and mine. If you want yours though, give mine another change please, thanks. Or if it is optional, maybe just enable it on non-Solaris systems (`uname` = "SunOS")? - Jay > Date: Wed, 23 Sep 2009 13:48:36 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Jay K : > > > > > I see the problem. My fix for Solaris is quite bad. > > > > It doesn't account for the cwd changing during pkgmap. > > > > Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; > > export PATH and then run m3date. > > > > Or maybe you can do an awk one liner there?? > > > > I figured C was easy enough. > > > > Or just remove the date %+s altogether? > > Tests on NT386 now show > > === package m3-sys/libdump === > > /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: > line 388: ./m3date: No such file or directory > > /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: > line 391: ./m3date: No such file or directory > > expr: non-numeric argument > > (standard_in) 1: parse error > > for all packages :-( > > Perhaps you could just comment-out the date stuff for the time being > (if we don't really need it)? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Sep 23 16:16:49 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 23 Sep 2009 10:16:49 -0400 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: <20090923141648.GA26316@topoi.pooq.com> On Wed, Sep 23, 2009 at 11:23:20AM +0000, Jay K wrote: > > > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > > problems. > > > > > > Symlink should work. > > Symlink /usr/bin/cm3 to /usr/local/cm3/bin? There's a program called stow (http://www.gnu.org/software/stow/) to make these soft links and keep track of them. -- hendrik From mbishop at esoteriq.org Wed Sep 23 18:32:21 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 23 Sep 2009 11:32:21 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: <4ABA4D95.3060100@esoteriq.org> Jay K wrote: > > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > > problems. > > > > Symlink should work. > Symlink /usr/bin/cm3 to /usr/local/cm3/bin? > Hardlinks would not likely work. > > > /usr/local/cm3/bin is used instead of /usr/bin, because it makes it > clear what goes/came together and uninstall is just a recursive delete. > "uninstall is just a recursive delete" is something a lot of people > like, and sometimes it is available, sometimes not. What about that > PATH=/usr/local/cm3/bin:$PATH tidbits left behind in ~/.bashrc that > user put in manually... > > > Some people would use the shorter /opt/cm3. > > Personally I use /cm3, possibly symlinked to ~jay/cm3. > (Note: symlinks not necessarily available!) > > I like that /opt is shorter, but there is much inertia/momentum behind > /usr/local -- the default for autoconf, but granted, not /usr/local/pkg. > > Some folks use > /opt/pkg1 > /opt/pkg2 > > and then blow up $PATH with lots of entries. Others use symlinks into > the shared /usr/bin and whatnot. > Maybe others just use full paths. > > There is no perfect answer here. Every approach has (large, glarying) > advantages and disadvantages. > It is quite unfortunate but I really just try to ignore it. I believe > you could spend, uh, infinite time discussing and implementing package > management and as I said, you'd still have large glarying disadvantages. > > Of course there are various package managers that let you put > everything "intermixed" in /usr and they keep track of what came from > what and allow uninstall that isn't just a recursive delete. > > Some people use a userid per package. > > One more thing before I shut up ... we produce package manager > indepent packages. > So not much of an installer/uninstaller, no package database. > Thanks, I guess there really isn't a simple answer... > I do have code to produce .deb files checked in. I should enable that > soon. > I'm inclined to just produce one large cm3-linux-x86.deb, > cm3-linux-amd64.deb, cm3-linux-sparc.deb, etc. Not all the broken out > packages that Olaf did. No dependencies. Not ubuntuv1, debianv4, etc., > just claim that are fairly portable and see what happens. They could > even be easily installed on non-Debian systems -- a .deb file is a > very simple format esp. if you ignore the metadata file. It is as I > recall an ar file with a metadata file and a nested .tar.gz or > .tar.bz2 or .tar.lzma -- and due to the .tar.lzma option, much smaller > than others. (And heck, we could make .debs for Darwin and Solaris; it > really just takes like two lines of .sh to install them...) > You should definitely provide debs for the stable release. Will help get more people to try it out. > > - Jay > > > > > Date: Wed, 23 Sep 2009 11:18:41 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ? > > > > Quoting Martin Bishop : > > > > > Why does everything install into /usr/local/cm3/* ? I tried editing my > > > PATH variable to get the cm3 binary in there, but I still have to > > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > > problems. > > > > The paths are different on different systems. /usr/local/cm3 is just > > the system-specifics-ignoring default of a generic cm3 installation. > > System-specific packages are currently being prepared by some > > people, but not yet finished as far as I know. There should be > > mails in the archives about download locations. > > > > > Is there a reason to not just install to normal positions like > /usr/bin > > > and /usr/lib, etc? Is it possible to tell cminstall where to install > > > other the default /usr/local/cm3 ? > > > > Sure. Just give cminstall the target directory as argument. > > It will always install a complete tree though (bin, lib, pkg, doc, > www, ...) From mbishop at esoteriq.org Wed Sep 23 18:34:18 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 23 Sep 2009 11:34:18 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: <4ABA4E0A.3080202@esoteriq.org> Olaf Wagner wrote: > Quoting Martin Bishop : > >> Why does everything install into /usr/local/cm3/* ? I tried editing my >> PATH variable to get the cm3 binary in there, but I still have to >> 'source /etc/profile' with every shell. And if I symlink it, it causes >> problems. > > The paths are different on different systems. /usr/local/cm3 is just > the system-specifics-ignoring default of a generic cm3 installation. > System-specific packages are currently being prepared by some > people, but not yet finished as far as I know. There should be > mails in the archives about download locations. > >> Is there a reason to not just install to normal positions like /usr/bin >> and /usr/lib, etc? Is it possible to tell cminstall where to install >> other the default /usr/local/cm3 ? > > Sure. Just give cminstall the target directory as argument. > It will always install a complete tree though (bin, lib, pkg, doc, > www, ...) Oh! Didn't know that. Thanks From jay.krell at cornell.edu Wed Sep 23 20:23:08 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 23 Sep 2009 11:23:08 -0700 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <4ABA4D95.3060100@esoteriq.org> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> <4ABA4D95.3060100@esoteriq.org> Message-ID: Upon further thought symlink might not work. We can make it work on some systems e.g. Mac and cygwin. Problem I see is, how does one find the executable's fullpath? If the symlink source is in argv[0] then no posix portable way. I was looking at this for finding cm3.cfg. -jay/phone From rodney.m.bates at cox.net Wed Sep 23 20:53:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 23 Sep 2009 13:53:49 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> <4ABA4D95.3060100@esoteriq.org> Message-ID: <4ABA6EBD.7050301@cox.net> I've had this around for a while. Don't know how portable it is. It's mainly a main executable wrapper for, and delegates the real work to, FS.GetAbsolutePathname, which, if not fully portable, ought to be fixed so it is. It works on LINUXLIBC6 and AMD64_LINUX. It also changes backslashes to forward slashes. Maybe better for general script use if it returned a return code if things go awry. jay.krell at cornell.edu wrote: > Upon further thought symlink might not work. We can make it work on > some systems e.g. Mac and cygwin. Problem I see is, how does one find > the executable's fullpath? If the symlink source is in argv[0] then no > posix portable way. I was looking at this for finding cm3.cfg. > > -jay/phone > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: AbsPath.m3 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m3makefile URL: From jay.krell at cornell.edu Thu Sep 24 01:25:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 23:25:09 +0000 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <4ABA6EBD.7050301@cox.net> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> <4ABA4D95.3060100@esoteriq.org> Message-ID: I don't believe that FS.GetAbsolutePathname(RTArgs.Get(1)) is correct. mkdir /path /cwd PATH=/path cp /usr/bin/ls /path cp /usr/bin/ls /cwd cd /cwd ls You will return /cwd/ instead of the correct /path/lsh. The code I have seen to handle this is roundabout. You have to first check for dots and/or slashes. If they are present, you use GetAbsolutePathname like you do. Else you split up $PATH on the appropriate character, appending argv[0] to each element and see if it exists and/or is executable. On Windows that isn't right probably, due to "extensions", however on Windows there is a very simple way, just GetModuleFileName(NULL). I expect there is a simple way on Mac too. There might be a way to fish out the dynamic linker parameters on other systems. But I don't think Posix provides a correct simple way. - Jay > Date: Wed, 23 Sep 2009 13:53:49 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ? > > I've had this around for a while. Don't know how portable it is. > It's mainly a main executable wrapper for, and > delegates the real work to, FS.GetAbsolutePathname, > which, if not fully portable, ought to be fixed so it is. > > It works on LINUXLIBC6 and AMD64_LINUX. > > It also changes backslashes to forward slashes. > Maybe better for general script use if it returned > a return code if things go awry. > > jay.krell at cornell.edu wrote: > > Upon further thought symlink might not work. We can make it work on > > some systems e.g. Mac and cygwin. Problem I see is, how does one find > > the executable's fullpath? If the symlink source is in argv[0] then no > > posix portable way. I was looking at this for finding cm3.cfg. > > > > -jay/phone > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 24 16:24:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Sep 2009 14:24:21 +0000 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB91054.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: @M3noincremental about the same crashing @M3nogenerational about the same crashing @M3noincremental @M3nogenerational about the same crashing - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] more info on juno on windows Date: Tue, 22 Sep 2009 22:11:26 +0000 current: nogc "works" -- always the WinContext/PushPixmap assertion failure paranoidgc is broken the same as default -- variety of assertion failures and access violations Including but NOT limited to: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 1708 *** which is in RefSanityCheck, doesn't look useful. still many access violations at 00200000-4. I think 00200000 just happens to be some pixmap data from the splash screen that clobbered some other data but I don't know. I posted a big hex dump the other week to see if anyone could confirm it looks like pixmaps. - Jay Date: Tue, 22 Sep 2009 17:58:52 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] more info on juno on windows Tony: I just tried these options. Here are results: recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line 1706, while nogc gets assert in WinContext.m3 line 165. I note that the juno window begins drawing before the crash on nogc whereas it does not on paranoidgc. recent cm3 on Vista, same results as above except that it appears to reference an illegal memory location before hitting the assert in the RTCollector when using paranoidgc. old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to abort the repeating error message. Not sure if anything else happens first because it scrolls too far. For nogc, we get same behavoir as the other tests above. Regards, Randy >>> Tony Hosking 9/22/2009 5:46 PM >>> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Sep 24 16:33:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Sep 2009 10:33:23 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: <354148C0-DBA4-438C-963B-80350725E453@cs.purdue.edu> Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 24 Sep 2009, at 10:24, Jay K wrote: > @M3noincremental about the same crashing > @M3nogenerational about the same crashing > @M3noincremental @M3nogenerational about the same crashing > > - Jay > > > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more info on juno on windows > Date: Tue, 22 Sep 2009 22:11:26 +0000 > > current: > > nogc "works" -- always the WinContext/PushPixmap assertion failure I think this is indicative of a heap clobber that you are seeing. > > paranoidgc is broken the same as default -- variety of assertion > failures and access violations > Including but NOT limited to: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1708 > *** > > > which is in RefSanityCheck, doesn't look useful. > > still many access violations at 00200000-4. > I think 00200000 just happens to be some pixmap data from the splash > screen that clobbered some other data but I don't know. > I posted a big hex dump the other week to see if anyone could > confirm it looks like pixmaps. > > - Jay > > > Date: Tue, 22 Sep 2009 17:58:52 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more info on juno on windows > > Tony: > > I just tried these options. Here are results: > > recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line > 1706, while nogc gets assert in WinContext.m3 line 165. I note that > the juno window begins drawing before the crash on nogc whereas it > does not on paranoidgc. > > recent cm3 on Vista, same results as above except that it appears to > reference an illegal memory location before hitting the assert in > the RTCollector when using paranoidgc. > > old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating > assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to > abort the repeating error message. Not sure if anything else > happens first because it scrolls too far. For nogc, we get same > behavoir as the other tests above. > > Regards, > Randy > > >>> Tony Hosking 9/22/2009 5:46 PM >>> > Have you tried running with @M3nogc? And @M3paranoidgc? > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Sep 2009, at 17:39, Jay K wrote: > > > Again, what I see is that many versions before around Feb 20 2007 > consistently fail with that same assertion failure. > > I have tested many versions now, recently. > > But versions after Feb 20 2007 usually access violate on the address > 0x20000 or so, sometimes other addresses, sometimes various > assertion failures. I believe this is much worse than merely always > failing the same assertion. > > > > - Jay > > > > Date: Tue, 22 Sep 2009 17:06:20 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] more info on juno on windows > > > > > Do we know whether or not Juno ever worked on Windows ? > > I don't recall ever testing it on Windows. I still have a vd5.7.0 > cm3 that I used for the project I finished up last year (August > 2008). If I run Juno on this system (Windows XP SP3), Juno crashes > with an ASSERT failure at line 165 in winvbt/WinContext.m3. The > date on the juno.exe is 8/19/2008. > > Regards, > Randy > > Jay K 9/22/2009 2:57 PM >>> > Here is the truncated part from the previous: > > This change, I think, causes Juno to access violate whereas before > it "only" failed assertions. > I believe it is considered fairly ok for a safe system to terminate > with an assertion failure, > that might not be a bug at all, but considered far worse to hit a > SIGSEGV > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 01:28:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 25 Sep 2009 23:28:05 +0000 Subject: [M3devel] formsedit Message-ID: I can confirm that formsedit fails on PPC_DARWIN too. The same as on Solaris/sparc32. Juno and Cube work fine. Current source. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 26 02:06:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Sep 2009 20:06:07 -0400 Subject: [M3devel] formsedit In-Reply-To: References: Message-ID: OK, thanks. I think we can track this down easily. Perhaps an endianness issue? Both are big-endian whereas Intel are little. I'm not sure what other big-endian platforms M3 has ever run on, so perhaps this is a dark and dusty corner... On 25 Sep 2009, at 19:28, Jay K wrote: > I can confirm that formsedit fails on PPC_DARWIN too. The same as on > Solaris/sparc32. > Juno and Cube work fine. > Current source. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 05:19:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 03:19:54 +0000 Subject: [M3devel] formsedit In-Reply-To: References: Message-ID: I forgot to mention: This was on an actual PPC machine. I /assume/ it can be reproed under emulation on x86 but I didn't try. > big endian I could try out my HP-UX/hppa machine again. :) Seriously it was working. I also had Linux/hppa running, but not Modula-3. I have some bids on eBay for some Mac/68K machines. :) I don't think I have seen on this Linux/sparc or Linux/ppc, but I will definitely try those. I don't remember if I tried. They are up and running well, even in Hudson. I can give you ssh access to all/several of these, send me your ssh public key. Could do OPEN/NETFREE/BSD/sparc/ppc too, with a little more time. (FreeBSD/ppc is a pain to install -- no partitioner -- and I haven't succeeded, but Net/Open are easy.) - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 25 Sep 2009 20:06:07 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] formsedit OK, thanks. I think we can track this down easily. Perhaps an endianness issue? Both are big-endian whereas Intel are little. I'm not sure what other big-endian platforms M3 has ever run on, so perhaps this is a dark and dusty corner... On 25 Sep 2009, at 19:28, Jay K wrote: I can confirm that formsedit fails on PPC_DARWIN too. The same as on Solaris/sparc32. Juno and Cube work fine. Current source. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 11:44:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 09:44:46 +0000 Subject: [M3devel] birch is out of diskspace Message-ID: birch is out of diskspace I'll free up some, but probably not much. I /might/ download some older archives locally. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Sat Sep 26 11:49:15 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Sat, 26 Sep 2009 11:49:15 +0200 Subject: [M3devel] birch is out of diskspace In-Reply-To: References: Message-ID: <20090926114915.0457c6tx1c0ogssc@mail.elego.de> Quoting Jay K : > > birch is out of diskspace > I'm on it. -Mike > I'll free up some, but probably not much. > I /might/ download some older archives locally. > > - Jay > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Sep 26 12:04:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 10:04:06 +0000 Subject: [M3devel] birch is out of diskspace In-Reply-To: <20090926114915.0457c6tx1c0ogssc@mail.elego.de> References: Message-ID: Thanks. It looks like I was maybe using ~7gig and I'm down to ~1gig and still cleaning up. - Jay > Date: Sat, 26 Sep 2009 11:49:15 +0200 > From: michael.anderson at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] birch is out of diskspace > > Quoting Jay K : > > > > > birch is out of diskspace > > > > I'm on it. > > -Mike > > > I'll free up some, but probably not much. > > I /might/ download some older archives locally. > > > > - Jay > > > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 19:01:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 17:01:48 +0000 Subject: [M3devel] formsedit In-Reply-To: References: Message-ID: No problem on Linux/sparc or Linux/powerpc. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] formsedit Date: Sat, 26 Sep 2009 03:19:54 +0000 I forgot to mention: This was on an actual PPC machine. I /assume/ it can be reproed under emulation on x86 but I didn't try. > big endian I could try out my HP-UX/hppa machine again. :) Seriously it was working. I also had Linux/hppa running, but not Modula-3. I have some bids on eBay for some Mac/68K machines. :) I don't think I have seen on this Linux/sparc or Linux/ppc, but I will definitely try those. I don't remember if I tried. They are up and running well, even in Hudson. I can give you ssh access to all/several of these, send me your ssh public key. Could do OPEN/NETFREE/BSD/sparc/ppc too, with a little more time. (FreeBSD/ppc is a pain to install -- no partitioner -- and I haven't succeeded, but Net/Open are easy.) - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 25 Sep 2009 20:06:07 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] formsedit OK, thanks. I think we can track this down easily. Perhaps an endianness issue? Both are big-endian whereas Intel are little. I'm not sure what other big-endian platforms M3 has ever run on, so perhaps this is a dark and dusty corner... On 25 Sep 2009, at 19:28, Jay K wrote: I can confirm that formsedit fails on PPC_DARWIN too. The same as on Solaris/sparc32. Juno and Cube work fine. Current source. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Sep 26 21:11:02 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 26 Sep 2009 21:11:02 +0200 Subject: [M3devel] LONGINT, looks urgent... Message-ID: <1253992263.13608.17.camel@faramir.m3w.org> Spent a piece of day with pdv := osnovica * 17L DIV 100L; varying osnovica from 1, over 1791, 1793... and many more. It looks like LONGINT arithmetic in anything except simplest expressions is broken. When turned to: WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO pdv := step2; END; it works... I have no much time ATM (doing various M3+Gtk+ tasks right now, tight on delivery schedule) to check it more. My version is a bit rusty but not much. If nobody makes more research, I'll - few weeks is most earliest I can expect any free time. -- Dragi?a Duri? From dragisha at m3w.org Sun Sep 27 00:19:54 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 27 Sep 2009 00:19:54 +0200 Subject: [M3devel] Just thinking.... runtime creation of types Message-ID: <1254003594.13608.21.camel@faramir.m3w.org> What steps are needed to create modula-3 type at runtime? Obviously, it can be fully used only from some scripting engine (and I have one, already using type found on start/after plugin load)... But integration with other types will simplify things. Also - new objects can be handled where supertypes can. IMO, very useful. -- Dragi?a Duri? From hosking at cs.purdue.edu Sun Sep 27 02:26:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 26 Sep 2009 20:26:55 -0400 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <1253992263.13608.17.camel@faramir.m3w.org> References: <1253992263.13608.17.camel@faramir.m3w.org> Message-ID: <585FE8AF-3874-41B7-9663-148E923415C7@cs.purdue.edu> What platform? On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > Spent a piece of day with > > pdv := osnovica * 17L DIV 100L; > > varying osnovica from 1, over 1791, 1793... and many more. It looks > like > LONGINT arithmetic in anything except simplest expressions is broken. > When turned to: > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > pdv := step2; > END; > > it works... > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > tight on > delivery schedule) to check it more. My version is a bit rusty but not > much. If nobody makes more research, I'll - few weeks is most > earliest I > can expect any free time. > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Sep 27 07:54:03 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 27 Sep 2009 07:54:03 +0200 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <585FE8AF-3874-41B7-9663-148E923415C7@cs.purdue.edu> References: <1253992263.13608.17.camel@faramir.m3w.org> <585FE8AF-3874-41B7-9663-148E923415C7@cs.purdue.edu> Message-ID: <1254030843.13608.24.camel@faramir.m3w.org> LINUXLIBC6, sorry for missing that. On Sat, 2009-09-26 at 20:26 -0400, Tony Hosking wrote: > What platform? > > On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > > > Spent a piece of day with > > > > pdv := osnovica * 17L DIV 100L; > > > > varying osnovica from 1, over 1791, 1793... and many more. It looks > > like > > LONGINT arithmetic in anything except simplest expressions is > > broken. > > When turned to: > > > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > > pdv := step2; > > END; > > > > it works... > > > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > > tight on > > delivery schedule) to check it more. My version is a bit rusty but > > not > > much. If nobody makes more research, I'll - few weeks is most > > earliest I > > can expect any free time. > > -- > > Dragi?a Duri? > > > -- Dragi?a Duri? From dragisha at m3w.org Sun Sep 27 13:34:23 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 27 Sep 2009 13:34:23 +0200 Subject: [M3devel] Sorry if FAQ, but there's no one...? :) Message-ID: <1254051264.13608.28.camel@faramir.m3w.org> I would like to send a program binary to friend for review, with Modula-3 libraries linked statically so he does not need to install cm3. build_standalone() tries to link staticlaly Gtk+ libs I am using, and they have no .a files and I want them as .so's anyway. LINUXLIBC6 -- Dragi?a Duri? From jay.krell at cornell.edu Sun Sep 27 14:32:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Sep 2009 12:32:24 +0000 Subject: [M3devel] Sorry if FAQ, but there's no one...? :) In-Reply-To: <1254051264.13608.28.camel@faramir.m3w.org> References: <1254051264.13608.28.camel@faramir.m3w.org> Message-ID: build_standalone() should be the answer. Are your Gtk+ libraries in Modula-3 or not? If they are in Modula-3, then that makes sense. As a quick hack, how about delete or move away the .a files that are being used that you don't want used? And, your config file doesn't say -static, right? I've seen that in older ones. Can you add build_standalone() to src/m3makefile rm -rf LINUXLIBC cm3 -commands and look at it and/or show us? This area is a bit wierd and gray imho, but will probably remain exactly asis. (I'm not saying we won't solve your problem. I think the current system already does.) The full flexibility is not exposed.. That is, it isn't likely to let you pick and chose which lib is static and which is dynamic, unless the library itself is build_standalone(), in which case always static. - Jay > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sun, 27 Sep 2009 13:34:23 +0200 > Subject: [M3devel] Sorry if FAQ, but there's no one...? :) > > I would like to send a program binary to friend for review, with > Modula-3 libraries linked statically so he does not need to install cm3. > build_standalone() tries to link staticlaly Gtk+ libs I am using, and > they have no .a files and I want them as .so's anyway. > > LINUXLIBC6 > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Sep 27 14:35:30 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 27 Sep 2009 08:35:30 -0400 Subject: [M3devel] Just thinking.... runtime creation of types In-Reply-To: <1254003594.13608.21.camel@faramir.m3w.org> References: <1254003594.13608.21.camel@faramir.m3w.org> Message-ID: <20090927123529.GB3719@topoi.pooq.com> On Sun, Sep 27, 2009 at 12:19:54AM +0200, Dragi?a Duri? wrote: > What steps are needed to create modula-3 type at runtime? > > Obviously, it can be fully used only from some scripting engine (and I > have one, already using type found on start/after plugin load)... But > integration with other types will simplify things. Also - new objects > can be handled where supertypes can. IMO, very useful. > -- > Dragi?a Duri? > It could also be used for code generated at run-time -- something I've wanted to do for a while now. -- hendrik From hosking at cs.purdue.edu Sun Sep 27 15:19:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 09:19:03 -0400 Subject: [M3devel] Sorry if FAQ, but there's no one...? :) In-Reply-To: <1254051264.13608.28.camel@faramir.m3w.org> References: <1254051264.13608.28.camel@faramir.m3w.org> Message-ID: <6493A410-33FF-4611-BD2B-4ED597C2FAFD@cs.purdue.edu> You could define the gtk+ libs as system libs in the config file, prefixed with dynamic linking directives. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Sep 2009, at 07:34, Dragi?a Duri? wrote: > I would like to send a program binary to friend for review, with > Modula-3 libraries linked statically so he does not need to install > cm3. > build_standalone() tries to link staticlaly Gtk+ libs I am using, and > they have no .a files and I want them as .so's anyway. > > LINUXLIBC6 > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Sep 27 19:49:03 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 27 Sep 2009 13:49:03 -0400 Subject: [M3devel] cvs error Message-ID: <4ABF6D2D.1E75.00D7.1@scires.com> I am getting the following CVS errors when I update my sandbox: In C:\cm3\Sandbox: "C:\Program Files\CVSNT\cvs.exe" -q update -P -d CVSROOT=:ssh:rcoleburn at birch.elegosoft.com:/usr/cvs cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' Not sure why this is happening. I did not edit any of these files. Any ideas on how to resolve? Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 27 20:14:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Sep 2009 18:14:37 +0000 Subject: [M3devel] cvs error In-Reply-To: <4ABF6D2D.1E75.00D7.1@scires.com> References: <4ABF6D2D.1E75.00D7.1@scires.com> Message-ID: I don't know, but out of ignorance I often do heavy handed stuff to fix my local cvs. like cd m3-sys rm -rf m3cc # rd /q/s m3cc on NT cvs -z3 upd -dAP m3cc if I don't have any changes in m3cc. - Jay Date: Sun, 27 Sep 2009 13:49:03 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] cvs error I am getting the following CVS errors when I update my sandbox: In C:\cm3\Sandbox: "C:\Program Files\CVSNT\cvs.exe" -q update -P -d CVSROOT=:ssh:rcoleburn at birch.elegosoft.com:/usr/cvs cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' Not sure why this is happening. I did not edit any of these files. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 27 20:19:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Sep 2009 18:19:26 +0000 Subject: [M3devel] m3tests hanging Message-ID: tests seemed hung on I386_DARWIN and I386_OPENBSD. I killed some processes to let them continue. OpenBSD I think we could blame on p007 that Tony fixed already? I copied from head. I haven't had good experience with having CVS do merges -- what changes to tell it? You just have to know? I often manually diff stuff and copy diffs. In this case I just copied the entire file. I wonder if we should apply for a Perforce open source license. It does branching very well, knowing what changes are where. Darwin I don't have an explanation for. So we'll have to just watch it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 27 20:59:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 14:59:29 -0400 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <1253992263.13608.17.camel@faramir.m3w.org> References: <1253992263.13608.17.camel@faramir.m3w.org> Message-ID: <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> It works OK for me on I386_DARWIN running with the CVS head. This program produces identical output for both the INTEGER and LONGINT values. Main.m3: MODULE Main; IMPORT MainC; VAR a, i: INTEGER; aa: LONGINT; BEGIN i := 0; FOR ii := 1L TO 1793L DO INC(i); a := i * 17 DIV 100; MainC.PutInt(a); aa := ii * 17L DIV 100L; MainC.PutLong(aa); END; END Main. MainC.i3: INTERFACE MainC; <*EXTERNAL*> PROCEDURE PutLong (x: LONGINT); <*EXTERNAL*> PROCEDURE PutInt (x: INTEGER); END MainC. MainC.C: #include void PutLong (long long x) { printf("%d\n", x); } void PutInt (long x) { printf("%d\n", x); } On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > Spent a piece of day with > > pdv := osnovica * 17L DIV 100L; > > varying osnovica from 1, over 1791, 1793... and many more. It looks > like > LONGINT arithmetic in anything except simplest expressions is broken. > When turned to: > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > pdv := step2; > END; > > it works... > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > tight on > delivery schedule) to check it more. My version is a bit rusty but not > much. If nobody makes more research, I'll - few weeks is most > earliest I > can expect any free time. > -- > Dragi?a Duri? From hosking at cs.purdue.edu Sun Sep 27 21:32:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 15:32:35 -0400 Subject: [M3devel] Config file skeletons Message-ID: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> Where did all the config file skeletons go? How do I fix the SOLgnu installation to look for libz.so instead of libz.a. I thought I could simply add a "Z" entry to SYSTEM_LIBS, but I don't know where to do that anymore. That way my tinderbox builds should succeed for the cvsup packages which need libz, but which is not normally installed as a static library. From hosking at cs.purdue.edu Sun Sep 27 21:53:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 15:53:52 -0400 Subject: [M3devel] Broken CVS head Message-ID: <60D3CE30-BF24-4972-ADF1-E49183533E6A@cs.purdue.edu> Jay, CVS head is broken right now because of your changes to m3core/ src/float/m3makefile and m3core/src/Csupport/m3makefile. I'm not sure if this is because I have an old config file or what, but it looks like the quake function "FileExists" is not defined anywhere. Just as a courtesy to others, please try to test commits before pushing them to the CVS head. At minimum, one should be able to build the head without errors. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 28 02:19:01 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 27 Sep 2009 17:19:01 -0700 Subject: [M3devel] Config file skeletons In-Reply-To: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> References: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> Message-ID: <793451C3-475A-446A-8E44-6B4319599704@hotmail.com> Find . | grep SOLgnu$ M3-sys/cminstall/src/config-no-install - Jay (phone) On Sep 27, 2009, at 12:32 PM, Tony Hosking wrote: > Where did all the config file skeletons go? How do I fix the > SOLgnu installation to look for libz.so instead of libz.a. I > thought I could simply add a "Z" entry to SYSTEM_LIBS, but I don't > know where to do that anymore. That way my tinderbox builds should > succeed for the cvsup packages which need libz, but which is not > normally installed as a static library. > > From wagner at elegosoft.com Mon Sep 28 10:32:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 10:32:58 +0200 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> References: <1253992263.13608.17.camel@faramir.m3w.org> <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> Message-ID: <20090928103258.tlrry9cuocg88ss8@mail.elegosoft.com> Quoting Tony Hosking : > It works OK for me on I386_DARWIN running with the CVS head. This > program produces identical output for both the INTEGER and LONGINT > values. > > Main.m3: > > MODULE Main; > IMPORT MainC; > > VAR > a, i: INTEGER; > aa: LONGINT; > BEGIN > i := 0; > FOR ii := 1L TO 1793L DO > INC(i); > a := i * 17 DIV 100; > MainC.PutInt(a); > aa := ii * 17L DIV 100L; > MainC.PutLong(aa); > END; > END Main. > > MainC.i3: > > INTERFACE MainC; > > <*EXTERNAL*> PROCEDURE PutLong (x: LONGINT); > <*EXTERNAL*> PROCEDURE PutInt (x: INTEGER); > > END MainC. > > MainC.C: > > #include > > void PutLong (long long x) { > printf("%d\n", x); > } > > void PutInt (long x) { > printf("%d\n", x); > } > > > On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > >> Spent a piece of day with >> >> pdv := osnovica * 17L DIV 100L; >> >> varying osnovica from 1, over 1791, 1793... and many more. It looks like >> LONGINT arithmetic in anything except simplest expressions is broken. >> When turned to: >> >> WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO >> pdv := step2; >> END; >> >> it works... >> >> I have no much time ATM (doing various M3+Gtk+ tasks right now, tight on >> delivery schedule) to check it more. My version is a bit rusty but not >> much. If nobody makes more research, I'll - few weeks is most earliest I >> can expect any free time. I know that everybody else is busy, too, but we should o open a ticket for this issue in trac o add the test program to m3-sys/m3tests so that it is run on all regression test platforms automatically Any volunteers? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Sep 28 11:13:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 11:13:27 +0200 Subject: [M3devel] cvs error In-Reply-To: <4ABF6D2D.1E75.00D7.1@scires.com> References: <4ABF6D2D.1E75.00D7.1@scires.com> Message-ID: <20090928111327.ivuoyshlsgsc4sg4@mail.elegosoft.com> Quoting Randy Coleburn : > I am getting the following CVS errors when I update my sandbox: > > In C:\cm3\Sandbox: "C:\Program Files\CVSNT\cvs.exe" -q update -P -d > CVSROOT=:ssh:rcoleburn at birch.elegosoft.com:/usr/cvs > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for > `m3-sys/m3cc/gcc/fixincludes' > Not sure why this is happening. I did not edit any of these files. > > Any ideas on how to resolve? This is no error. CVS just thinks that the mentioned files should be under version control but aren't. Indeed they are probably generated by some make target, so I think it should be OK. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Sep 28 11:18:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 11:18:21 +0200 Subject: [M3devel] m3tests hanging In-Reply-To: References: Message-ID: <20090928111821.ii777ufy5cook4ko@mail.elegosoft.com> Quoting Jay K : > > tests seemed hung on I386_DARWIN and I386_OPENBSD. > I killed some processes to let them continue. > > OpenBSD I think we could blame on p007 that Tony fixed already? I > copied from head. > I haven't had good experience with having CVS do merges -- what > changes to tell it? You just have to know? I often manually diff > stuff and copy diffs. I posted a description on cvs merges some days ago, or didn't it show up on the list? > In this case I just copied the entire file. I wonder if we should > apply for a Perforce > open source license. It does branching very well, knowing what > changes are where. Not now. If everybody agrees (which I don't think, as others will prefer subversion or git or mercurial or ...) _and_ we do much branching, Perforce might be a good idea. But until now branching was only used for infrequent release branches, which CVS should be able to handle, too. > Darwin I don't have an explanation for. > So we'll have to just watch it. So p007 should now terminate on any platform with Tony's fixes? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Sep 28 11:31:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 28 Sep 2009 09:31:02 +0000 Subject: [M3devel] m3tests hanging In-Reply-To: <20090928111821.ii777ufy5cook4ko@mail.elegosoft.com> References: Message-ID: > I posted a description on cvs merges some days ago, or didn't it show > up on the list? It seems to require me to know every change in the system and what branch it is in. I do that to some extent, and when I can't, I diff my two trees. With perforce you just tell it the two branches and it knows which changes are in which branch, basically. At least it seems to keep a high water mark. > > In this case I just copied the entire file. I wonder if we should > > apply for a Perforce > > open source license. It does branching very well, knowing what > > changes are where. > > Not now. If everybody agrees (which I don't think, as others will > prefer subversion or git or mercurial or ...) _and_ we do much branching, I've done some research here sort of, at least read stuff, guaged popular opinion. I have a lot of experience with Perforce and highly recommend it. But it isn't free beer for any project and source isn't available. It isn't just merging/branching that it does well. It does basically everything well, except it isn't distributed. It has a good command line interface, a good gui, pretty good platform support. I'm not sure of its perf over slow network. Otherwise git and mercurial seem to the most popular, but git is seen as perhaps too hard to use. I might shortly have to use/learn mercurial for a small project (said project considered git as well, but chose mercurial). Subversion is better than CVS and has atomic multi-file changesets. Historically its branching support is terrible, again you have to know which changes are in which branch. They might have fixed that by now. Monotone sounds good, but git and mercurial seem more popular. Conversion from cvs seems supported well enough. Some of the systems support on-going bidirectional conversion, including accepting CVS commits. Some support read only CVS mirrors. > So p007 should now terminate on any platform with Tony's fixes? That is my hope/expectation. I haven't tested it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Sep 28 12:24:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 12:24:44 +0200 Subject: [M3devel] Config file skeletons In-Reply-To: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> References: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> Message-ID: <20090928122444.73xexhn69wcs8k0w@mail.elegosoft.com> Quoting Tony Hosking : > Where did all the config file skeletons go? How do I fix the SOLgnu > installation to look for libz.so instead of libz.a. I thought I could > simply add a "Z" entry to SYSTEM_LIBS, but I don't know where to do > that anymore. That way my tinderbox builds should succeed for the > cvsup packages which need libz, but which is not normally installed as > a static library. Wasn't the problem that libz is not yet contained in SYSTEM_LIBS, but looked up with some local quake magic? At least there's a ticket in trac related to this failure: https://projects.elego.de/cm3/ticket/1048 I don't know why it isn't fixed yet, doesn't look too difficult. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Sep 28 12:55:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 28 Sep 2009 10:55:19 +0000 Subject: [M3devel] Juno on Windows, some inconclusive investigation.. Message-ID: 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: From dragisha at m3w.org Mon Sep 28 13:17:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 28 Sep 2009 13:17:34 +0200 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> References: <1253992263.13608.17.camel@faramir.m3w.org> <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> Message-ID: <1254136654.13608.558.camel@faramir.m3w.org> Mea culpa... Test code alone works well on LINUXLIBC6, it's obviously something higher up. I've used Fmt.LongInt, but addedd to this code, it also works well. I'll check it more, for now - sorry for false alarm. On Sun, 2009-09-27 at 14:59 -0400, Tony Hosking wrote: > It works OK for me on I386_DARWIN running with the CVS head. This > program produces identical output for both the INTEGER and LONGINT > values. > > Main.m3: > > MODULE Main; > IMPORT MainC; > > VAR > a, i: INTEGER; > aa: LONGINT; > BEGIN > i := 0; > FOR ii := 1L TO 1793L DO > INC(i); > a := i * 17 DIV 100; > MainC.PutInt(a); > aa := ii * 17L DIV 100L; > MainC.PutLong(aa); > END; > END Main. > > MainC.i3: > > INTERFACE MainC; > > <*EXTERNAL*> PROCEDURE PutLong (x: LONGINT); > <*EXTERNAL*> PROCEDURE PutInt (x: INTEGER); > > END MainC. > > MainC.C: > > #include > > void PutLong (long long x) { > printf("%d\n", x); > } > > void PutInt (long x) { > printf("%d\n", x); > } > > > On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > > > Spent a piece of day with > > > > pdv := osnovica * 17L DIV 100L; > > > > varying osnovica from 1, over 1791, 1793... and many more. It looks > > like > > LONGINT arithmetic in anything except simplest expressions is broken. > > When turned to: > > > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > > pdv := step2; > > END; > > > > it works... > > > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > > tight on > > delivery schedule) to check it more. My version is a bit rusty but not > > much. If nobody makes more research, I'll - few weeks is most > > earliest I > > can expect any free time. > > -- > > Dragi?a Duri? > -- Dragi?a Duri? From jay.krell at cornell.edu Mon Sep 28 15:11:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 28 Sep 2009 13:11:28 +0000 Subject: [M3devel] help debugging Juno..sanity check? Message-ID: So, I know that ThreadWin32.T instances are prone to being overwritten. So I did this: T = BRANDED "Thread.T Win32-1.0" OBJECT > pad1: ARRAY [0..16_1000] OF CHAR; > protect: ARRAY [0..16_1] OF CHAR; > pad2: ARRAY [0..16_1000] OF CHAR; And then there are two occurences of NEW(T): next_self := NEW(T); > Protect(next_self); PROCEDURE CreateT (act: Activation): T = (* LL = 0, because allocating a traced reference may cause the allocator to start a collection which will call "SuspendOthers" which will try to acquire "activeMu". *) VAR t := NEW(T, act := act); BEGIN > Protect(t); PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); END Protect; This should catch any writes to these fields. Now, a thread can be garbage collected and reused. And I'd want to unprotect this memory. Or prevent the garbage collector from deciding any thread is garbage. Second option seems easier and suffices. So: VAR threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) threadCount: INTEGER; and more completely: PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); RTIO.PutInt(threadCount); RTIO.PutText(" "); RTIO.PutAddr(ADR(threads)); RTIO.PutText(" "); RTIO.PutAddr(ADR(t.protect)); RTIO.PutText("\n"); threads[threadCount] := t; INC(threadCount); END Protect; And just in case, I emptied out the FreeSlot function. But yet I get: 0 0xe2abe0 0x1141021 1 0xe2abe0 0x114b429 2 0xe2abe0 0x11a2311 3 0xe2abe0 0x11a48b1 4 0xe2abe0 0x11ab499 5 0xe2abe0 0x12e9f11 6 0xe2abe0 0x12d211d 7 0xe2abe0 0x11bd691 8 0xe2abe0 0x11d1011 9 0xe2abe0 0x11d3e2d 10 0xe2abe0 0x11d6759 11 0xe2abe0 0x11d8bd1 12 0xe2abe0 0x12089f1 13 0xe2abe0 0x1211455 14 0xe2abe0 0x12138cd 15 0xe2abe0 0x1215ecd 16 0xe2abe0 0x12184cd 17 0xe2abe0 0x121bcd5 18 0xe2abe0 0x121e35d Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: 23% (b60.9d4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 edi=011bd000 eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 MSVCR90!fastzero_I+0x20: 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds:0023:011bd000=0000000 0000000000000000000000000 0:003> k ChildEBP RetAddr 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db 0:003> r edi edi=011bd000 0:003> What am I confused about? Why does it seem that even if I store some pointers in globals, they are getting garbage collected and reused? I should debug BuildGlobalMap?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 28 16:04:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Sep 2009 10:04:55 -0400 Subject: [M3devel] help debugging Juno..sanity check? In-Reply-To: References: Message-ID: <4297E27D-B5E9-48D2-BA1D-1CAE6332899D@cs.purdue.edu> Huh? I don't understand the point of all of this. Threads can be moved by the GC, even if referenced from globals. The only way to prevent a thread moving is to keep a reference to it on some thread stack. (I still don't know what you are trying to achieve -- why not use a hardware breakpoint in the debugger?). That's how I found the race in ScrollerVBTClass.m3. On 28 Sep 2009, at 09:11, Jay K wrote: > So, I know that ThreadWin32.T instances are prone to being > overwritten. > > So I did this: > > > T = BRANDED "Thread.T Win32-1.0" OBJECT > > pad1: ARRAY [0..16_1000] OF CHAR; > > protect: ARRAY [0..16_1] OF CHAR; > > pad2: ARRAY [0..16_1000] OF CHAR; > > And then there are two occurences of NEW(T): > > > next_self := NEW(T); > > Protect(next_self); > > > PROCEDURE CreateT (act: Activation): T = > (* LL = 0, because allocating a traced reference may cause > the allocator to start a collection which will call > "SuspendOthers" > which will try to acquire "activeMu". *) > VAR t := NEW(T, act := act); > BEGIN > > Protect(t); > > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > END Protect; > > > This should catch any writes to these fields. > > > Now, a thread can be garbage collected and reused. > And I'd want to unprotect this memory. > Or prevent the garbage collector from deciding any thread is garbage. > Second option seems easier and suffices. > > > So: > > > VAR > threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) > threadCount: INTEGER; > > > and more completely: > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > RTIO.PutInt(threadCount); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(threads)); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(t.protect)); > RTIO.PutText("\n"); > threads[threadCount] := t; > INC(threadCount); > END Protect; > > > And just in case, I emptied out the FreeSlot function. > > > But yet I get: > > 0 0xe2abe0 0x1141021 > 1 0xe2abe0 0x114b429 > 2 0xe2abe0 0x11a2311 > 3 0xe2abe0 0x11a48b1 > 4 0xe2abe0 0x11ab499 > 5 0xe2abe0 0x12e9f11 > 6 0xe2abe0 0x12d211d > 7 0xe2abe0 0x11bd691 > 8 0xe2abe0 0x11d1011 > 9 0xe2abe0 0x11d3e2d > 10 0xe2abe0 0x11d6759 > 11 0xe2abe0 0x11d8bd1 > 12 0xe2abe0 0x12089f1 > 13 0xe2abe0 0x1211455 > 14 0xe2abe0 0x12138cd > 15 0xe2abe0 0x1215ecd > 16 0xe2abe0 0x12184cd > 17 0xe2abe0 0x121bcd5 > 18 0xe2abe0 0x121e35d > Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: > 23% > (b60.9d4): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 > edi=011bd000 > eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > MSVCR90!fastzero_I+0x20: > 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds: > 0023:011bd000=0000000 > 0000000000000000000000000 > 0:003> k > ChildEBP RetAddr > 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 > 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 > 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f > 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 > 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec > 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c > 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 > 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e > 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e > 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b > 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 > 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f > 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 > 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 > 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 > 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 > 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf > 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db > 0:003> r edi > edi=011bd000 > 0:003> > > > What am I confused about? > > Why does it seem that even if I store some pointers in globals, they > are getting garbage collected and reused? > > I should debug BuildGlobalMap?? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 07:39:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 05:39:24 +0000 Subject: [M3devel] help debugging Juno..sanity check? In-Reply-To: <4297E27D-B5E9-48D2-BA1D-1CAE6332899D@cs.purdue.edu> References: Message-ID: oops, thanks, I forgot gc is compacting. I don't see how to use a hardware breakpoint, the corruption seems to always move around. This is an attempt to set a hardware breakpoint programmatically based on what the runtime addresses happen to be. I do know these bytes are getting overwritten. If I assert they are zero in Join, inevitably the assert fails. I think I might try to vary the Juno pixmaps, see if the altered data appears in the corruption, try to prove, as it appears, that the corruption is pixmap data. Thanks, - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 28 Sep 2009 10:04:55 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] help debugging Juno..sanity check? Huh? I don't understand the point of all of this. Threads can be moved by the GC, even if referenced from globals. The only way to prevent a thread moving is to keep a reference to it on some thread stack. (I still don't know what you are trying to achieve -- why not use a hardware breakpoint in the debugger?). That's how I found the race in ScrollerVBTClass.m3. On 28 Sep 2009, at 09:11, Jay K wrote: So, I know that ThreadWin32.T instances are prone to being overwritten. So I did this: T = BRANDED "Thread.T Win32-1.0" OBJECT > pad1: ARRAY [0..16_1000] OF CHAR; > protect: ARRAY [0..16_1] OF CHAR; > pad2: ARRAY [0..16_1000] OF CHAR; And then there are two occurences of NEW(T): next_self := NEW(T); > Protect(next_self); PROCEDURE CreateT (act: Activation): T = (* LL = 0, because allocating a traced reference may cause the allocator to start a collection which will call "SuspendOthers" which will try to acquire "activeMu". *) VAR t := NEW(T, act := act); BEGIN > Protect(t); PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); END Protect; This should catch any writes to these fields. Now, a thread can be garbage collected and reused. And I'd want to unprotect this memory. Or prevent the garbage collector from deciding any thread is garbage. Second option seems easier and suffices. So: VAR threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) threadCount: INTEGER; and more completely: PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); RTIO.PutInt(threadCount); RTIO.PutText(" "); RTIO.PutAddr(ADR(threads)); RTIO.PutText(" "); RTIO.PutAddr(ADR(t.protect)); RTIO.PutText("\n"); threads[threadCount] := t; INC(threadCount); END Protect; And just in case, I emptied out the FreeSlot function. But yet I get: 0 0xe2abe0 0x1141021 1 0xe2abe0 0x114b429 2 0xe2abe0 0x11a2311 3 0xe2abe0 0x11a48b1 4 0xe2abe0 0x11ab499 5 0xe2abe0 0x12e9f11 6 0xe2abe0 0x12d211d 7 0xe2abe0 0x11bd691 8 0xe2abe0 0x11d1011 9 0xe2abe0 0x11d3e2d 10 0xe2abe0 0x11d6759 11 0xe2abe0 0x11d8bd1 12 0xe2abe0 0x12089f1 13 0xe2abe0 0x1211455 14 0xe2abe0 0x12138cd 15 0xe2abe0 0x1215ecd 16 0xe2abe0 0x12184cd 17 0xe2abe0 0x121bcd5 18 0xe2abe0 0x121e35d Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: 23% (b60.9d4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 edi=011bd000 eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 MSVCR90!fastzero_I+0x20: 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds:0023:011bd000=0000000 0000000000000000000000000 0:003> k ChildEBP RetAddr 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db 0:003> r edi edi=011bd000 0:003> What am I confused about? Why does it seem that even if I store some pointers in globals, they are getting garbage collected and reused? I should debug BuildGlobalMap?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 09:47:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 07:47:15 +0000 Subject: [M3devel] why Thread.Wait immediately after Thread.Fork? Message-ID: What is the point of Thread.Wait(Thread.Fork(NEW(ClosureType....)); vs. just: NEW(ClosureType....).apply(); ? The only reason I can think of is to ensure more stack the ClosureType().apply() than might be present on the current thread. OR maybe an assertion on the author's part that the work could/should be performed without waiting, but he hasn't made it so yet? OR maybe so user can interrupt long running operation with control-c? But that works the same on the original thread, right? OR maybe to stress test the threading library and ensure that thread creation is cheap?? These do seem like wasted threads. I have found a few examples. Here is one: m3-ui\formsvbt\src\FormsVBT.m3 PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T RAISES {Error} = BEGIN TYPECASE Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000, description := description, fv := t, state := state))) OF | TEXT (msg) => RAISE Error (msg) | VBT.T (ch) => RETURN ch ELSE <* ASSERT FALSE *> END END Parse; why not: PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T RAISES {Error} = BEGIN TYPECASE NEW (ParseClosure, stackSize := 10000, description := description, fv := t, state := state).apply() OF | TEXT (msg) => RAISE Error (msg) | VBT.T (ch) => RETURN ch ELSE <* ASSERT FALSE *> END END Parse; If the point is to ensure enough stack, perhaps a mechanism to report how much stack is left would be reasonable?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 29 10:08:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Sep 2009 10:08:56 +0200 Subject: [M3devel] why Thread.Wait immediately after Thread.Fork? In-Reply-To: References: Message-ID: <20090929100856.j46qpa66m8k4c84w@mail.elegosoft.com> My guess would be it is the stacksize. The parser will probably be a simple LL implementation, and the default size for thread stacks was (is?) notorious small in M3. What are the current defaults? Olaf Quoting Jay K : > What is the point of > > Thread.Wait(Thread.Fork(NEW(ClosureType....)); > > vs. just: > > NEW(ClosureType....).apply(); > > ? > > The only reason I can think of is to ensure more stack the > ClosureType().apply() than might be present on the current thread. > > OR maybe an assertion on the author's part that the work > could/should be performed without waiting, but he hasn't made it so > yet? > > > OR maybe so user can interrupt long running operation with > control-c? But that works the same on the original thread, right? > > > > OR maybe to stress test the threading library and ensure that thread > creation is cheap?? > > These do seem like wasted threads. > > > > I have found a few examples. Here is one: > > > > > m3-ui\formsvbt\src\FormsVBT.m3 > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > RAISES {Error} = > BEGIN > TYPECASE > Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000, > description := description, fv := t, > state := state))) OF > | TEXT (msg) => RAISE Error (msg) > | VBT.T (ch) => RETURN ch > ELSE <* ASSERT FALSE *> > END > END Parse; > > > > > why not: > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > RAISES {Error} = > BEGIN > TYPECASE > NEW (ParseClosure, stackSize := 10000, > description := description, fv := t, > state := state).apply() OF > | TEXT (msg) => RAISE Error (msg) > | VBT.T (ch) => RETURN ch > ELSE <* ASSERT FALSE *> > END > END Parse; > > > > > > If the point is to ensure enough stack, perhaps a mechanism to > report how much stack is left would be reasonable?? > > > > > - Jay > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 29 10:13:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 08:13:51 +0000 Subject: [M3devel] Juno/Win32 possibly somewhat understood Message-ID: So..in order to simplify debugging, I started removing and simplifying code, as long as the failures were similar. Sometimes I'd get an array overflow as a result -- like if I removed code that initialized stuff. I focused on: removing maybe unnecessary threads -- like the FileBrowserVBT.Watcher, the font cleanupt thread I changed uses of Wait(Fork(NEW(T)) to just NEW(T).apply() I did also remove a bunch of Trestle redraw code that was often on the stack. Eventually, while almost nothing got drawn, Juno seemed to crash less often and more consistently. So I undid/redid stuff. It seems the main thing I had altered was using fewer threads. So, a quick look at ThreadWin32.m3. It maintains some idle threads. If I remove that, Juno seems to stop crashing. I'm going to double check stuff. Like undo all my other changes. Maybe even try setting the idle thread count to 0 instead of removing the code. See if my findings repeat themselves. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 10:18:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 08:18:05 +0000 Subject: [M3devel] why Thread.Wait immediately after Thread.Fork? In-Reply-To: <20090929100856.j46qpa66m8k4c84w@mail.elegosoft.com> References: Message-ID: The defaults are still small. C:\dev2\cm3.2\m3-libs\m3core\src\thread\POSIX\ThreadPosix.m3(196): defaultStackSize := 3000; C:\dev2\cm3.2\m3-libs\m3core\src\thread\PTHREAD\ThreadPThread.m3(819):VAR defaultStackSize := 4096; I did some experimentation, and I was HOPING to find something like: Among all supported platforms, the smallest actual creatable stack is 64K, therefore set our minimum to 64K. Or even 16K. However I didn't find that to be true. I think I found I could create stacks as small as 4K, maybe even less. On the other hand, I'm sure a number of platforms cannot create such small stacks. Also I believe the Linux default stack is a whopping 8MB, so you sometimes find code that fails with smaller than that. NT defaults tend to either be 1MB or 256K, maybe doubled for 64bit. - Jay > Date: Tue, 29 Sep 2009 10:08:56 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] why Thread.Wait immediately after Thread.Fork? > > My guess would be it is the stacksize. The parser will probably > be a simple LL implementation, and the default size for thread > stacks was (is?) notorious small in M3. > > What are the current defaults? > > Olaf > > Quoting Jay K : > > > What is the point of > > > > Thread.Wait(Thread.Fork(NEW(ClosureType....)); > > > > vs. just: > > > > NEW(ClosureType....).apply(); > > > > ? > > > > The only reason I can think of is to ensure more stack the > > ClosureType().apply() than might be present on the current thread. > > > > OR maybe an assertion on the author's part that the work > > could/should be performed without waiting, but he hasn't made it so > > yet? > > > > > > OR maybe so user can interrupt long running operation with > > control-c? But that works the same on the original thread, right? > > > > > > > > OR maybe to stress test the threading library and ensure that thread > > creation is cheap?? > > > > These do seem like wasted threads. > > > > > > > > I have found a few examples. Here is one: > > > > > > > > > > m3-ui\formsvbt\src\FormsVBT.m3 > > > > > > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > > RAISES {Error} = > > BEGIN > > TYPECASE > > Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000, > > description := description, fv := t, > > state := state))) OF > > | TEXT (msg) => RAISE Error (msg) > > | VBT.T (ch) => RETURN ch > > ELSE <* ASSERT FALSE *> > > END > > END Parse; > > > > > > > > > > why not: > > > > > > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > > RAISES {Error} = > > BEGIN > > TYPECASE > > NEW (ParseClosure, stackSize := 10000, > > description := description, fv := t, > > state := state).apply() OF > > | TEXT (msg) => RAISE Error (msg) > > | VBT.T (ch) => RETURN ch > > ELSE <* ASSERT FALSE *> > > END > > END Parse; > > > > > > > > > > > > If the point is to ensure enough stack, perhaps a mechanism to > > report how much stack is left would be reasonable?? > > > > > > > > > > - Jay > > > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 11:18:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 09:18:57 +0000 Subject: [M3devel] ThreadF.MyID? Message-ID: The algorithms for thread id assignment vary on the platforms. In posix user threads and Win32 threads, it appears to be a number that increments for every new thread. Not sure what happens after 2 or 4 billion. On pthreads, it appears to be, well, we maintain an array of threads. So it is a number between 0 and n where n is the maximum number of threads that have "ever" been running at the same time. With presumably aggressive reuse of ids. Ok? They should all use the same? It's just that I'm looking at the Win32 code, comparing it to the pthread code: Win32: LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); Pthread doesn't have this code. I don't believe self.closure needs a lock. And per above, pthreads doesn't need protection here for id, since it is handled elsewhere. I know this was just discussed in a sense -- MyId is for debugging/diagnostics only and its value can't be depended on for much. The are obvious advantages/disadvantages to the two schemes. Win32/Posix recycle "never", so debugging probably easier. Pthread doesn't waste time/space on the id. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 11:24:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 09:24:49 +0000 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: Probably on Win32 should just use GetCurrentThreadId(). And pthread could just use pthread_self(). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 09:18:57 +0000 Subject: [M3devel] ThreadF.MyID? The algorithms for thread id assignment vary on the platforms. In posix user threads and Win32 threads, it appears to be a number that increments for every new thread. Not sure what happens after 2 or 4 billion. On pthreads, it appears to be, well, we maintain an array of threads. So it is a number between 0 and n where n is the maximum number of threads that have "ever" been running at the same time. With presumably aggressive reuse of ids. Ok? They should all use the same? It's just that I'm looking at the Win32 code, comparing it to the pthread code: Win32: LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); Pthread doesn't have this code. I don't believe self.closure needs a lock. And per above, pthreads doesn't need protection here for id, since it is handled elsewhere. I know this was just discussed in a sense -- MyId is for debugging/diagnostics only and its value can't be depended on for much. The are obvious advantages/disadvantages to the two schemes. Win32/Posix recycle "never", so debugging probably easier. Pthread doesn't waste time/space on the id. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 13:19:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 11:19:06 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. Message-ID: Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. At least. The Enter/Leave mechanical replacement error. However even with that, the idle thread stuff seemed to cause problems. It was there forever, I realize. Also, I should have done this first, but anyway, later, I tried merging back in your changes from Feb 16. Somewhat they are moot (lock vs. LockMutex). Somewhat they are already there (WaitHeap, heapCond => condition). Somewhat they are trivial (fixing error messages). That leaves, in my analysis, the BroadcastHeap change. With this change however, /sometimes/ Juno hangs. Is this, like, somehow equivalent to the Posix hang? Is the current code the "best"? Oh darn..it hangs either way. Just not often. Could that be "similar" to the pthread problem? Any chance you can look at it? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 15:49:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 09:49:19 -0400 Subject: [M3devel] help debugging Juno..sanity check? In-Reply-To: References: Message-ID: OK, remind me again what happens with @M3nogc. That will prevent movement, and should allow you to protect state as you originally intended, without worrying about it being GC'd or moved.. From what you are saying though, it appears that even with @M3nogc the corruption is not deterministic. Which does make it tricky to nail down where it occurs. On 29 Sep 2009, at 01:39, Jay K wrote: > oops, thanks, I forgot gc is compacting. > > I don't see how to use a hardware breakpoint, > the corruption seems to always move around. > > This is an attempt to set a hardware breakpoint programmatically based > on what the runtime addresses happen to be. > > I do know these bytes are getting overwritten. > If I assert they are zero in Join, inevitably the assert fails. > > I think I might try to vary the Juno pixmaps, see if the altered > data appears in the corruption, try to prove, as it appears, > that the corruption is pixmap data. > > Thanks, > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 28 Sep 2009 10:04:55 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help debugging Juno..sanity check? > > Huh? I don't understand the point of all of this. Threads can be > moved by the GC, even if referenced from globals. The only way to > prevent a thread moving is to keep a reference to it on some thread > stack. (I still don't know what you are trying to achieve -- why > not use a hardware breakpoint in the debugger?). That's how I found > the race in ScrollerVBTClass.m3. > > On 28 Sep 2009, at 09:11, Jay K wrote: > > So, I know that ThreadWin32.T instances are prone to being > overwritten. > > So I did this: > > > T = BRANDED "Thread.T Win32-1.0" OBJECT > > pad1: ARRAY [0..16_1000] OF CHAR; > > protect: ARRAY [0..16_1] OF CHAR; > > pad2: ARRAY [0..16_1000] OF CHAR; > > And then there are two occurences of NEW(T): > > > next_self := NEW(T); > > Protect(next_self); > > > PROCEDURE CreateT (act: Activation): T = > (* LL = 0, because allocating a traced reference may cause > the allocator to start a collection which will call > "SuspendOthers" > which will try to acquire "activeMu". *) > VAR t := NEW(T, act := act); > BEGIN > > Protect(t); > > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > END Protect; > > > This should catch any writes to these fields. > > > Now, a thread can be garbage collected and reused. > And I'd want to unprotect this memory. > Or prevent the garbage collector from deciding any thread is garbage. > Second option seems easier and suffices. > > > So: > > > VAR > threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) > threadCount: INTEGER; > > > and more completely: > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > RTIO.PutInt(threadCount); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(threads)); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(t.protect)); > RTIO.PutText("\n"); > threads[threadCount] := t; > INC(threadCount); > END Protect; > > > And just in case, I emptied out the FreeSlot function. > > > But yet I get: > > 0 0xe2abe0 0x1141021 > 1 0xe2abe0 0x114b429 > 2 0xe2abe0 0x11a2311 > 3 0xe2abe0 0x11a48b1 > 4 0xe2abe0 0x11ab499 > 5 0xe2abe0 0x12e9f11 > 6 0xe2abe0 0x12d211d > 7 0xe2abe0 0x11bd691 > 8 0xe2abe0 0x11d1011 > 9 0xe2abe0 0x11d3e2d > 10 0xe2abe0 0x11d6759 > 11 0xe2abe0 0x11d8bd1 > 12 0xe2abe0 0x12089f1 > 13 0xe2abe0 0x1211455 > 14 0xe2abe0 0x12138cd > 15 0xe2abe0 0x1215ecd > 16 0xe2abe0 0x12184cd > 17 0xe2abe0 0x121bcd5 > 18 0xe2abe0 0x121e35d > Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: > 23% > (b60.9d4): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 > edi=011bd000 > eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > MSVCR90!fastzero_I+0x20: > 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds: > 0023:011bd000=0000000 > 0000000000000000000000000 > 0:003> k > ChildEBP RetAddr > 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 > 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 > 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f > 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 > 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec > 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c > 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 > 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e > 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e > 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b > 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 > 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f > 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 > 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 > 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 > 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 > 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf > 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db > 0:003> r edi > edi=011bd000 > 0:003> > > > What am I confused about? > > Why does it seem that even if I store some pointers in globals, they > are getting garbage collected and reused? > > I should debug BuildGlobalMap?? > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 15:58:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 09:58:45 -0400 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: <317FC510-CCDE-414D-AEC2-1D9FBEE67B6D@cs.purdue.edu> MyId is not a standard interface so it can do what it likes. Also, I was trying to match thread Ids to those of the OS (as reported by gdb) which recycles them. No guarantees though. I don't think they should necessarily all be the same from one thread implementation to another. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 29 Sep 2009, at 05:18, Jay K wrote: > The algorithms for thread id assignment vary on the platforms. > > In posix user threads and Win32 threads, it appears to be a number > that increments for every new thread. > Not sure what happens after 2 or 4 billion. > > On pthreads, it appears to be, well, we maintain an array of threads. > So it is a number between 0 and n where n is the maximum number of > threads that have > "ever" been running at the same time. With presumably aggressive > reuse of ids. > > Ok? > > They should all use the same? > > It's just that I'm looking at the Win32 code, comparing it to the > pthread code: > > Win32: > LockMutex(threadMu); > cl := self.closure; > self.id := nextId; INC (nextId); > UnlockMutex(threadMu); > > Pthread doesn't have this code. > I don't believe self.closure needs a lock. > And per above, pthreads doesn't need protection here for id, since > it is handled elsewhere. > > I know this was just discussed in a sense -- MyId is for debugging/ > diagnostics only and its value can't be depended on for much. > > The are obvious advantages/disadvantages to the two schemes. > Win32/Posix recycle "never", so debugging probably easier. > Pthread doesn't waste time/space on the id. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 15:59:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 09:59:15 -0400 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: On 29 Sep 2009, at 05:24, Jay K wrote: > Probably on Win32 should just use GetCurrentThreadId(). > And pthread could just use pthread_self(). Yeah, but the type of pthread_self is indeterminate. > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 29 Sep 2009 09:18:57 +0000 > Subject: [M3devel] ThreadF.MyID? > > The algorithms for thread id assignment vary on the platforms. > > In posix user threads and Win32 threads, it appears to be a number > that increments for every new thread. > Not sure what happens after 2 or 4 billion. > > On pthreads, it appears to be, well, we maintain an array of threads. > So it is a number between 0 and n where n is the maximum number of > threads that have > "ever" been running at the same time. With presumably aggressive > reuse of ids. > > Ok? > > They should all use the same? > > It's just that I'm looking at the Win32 code, comparing it to the > pthread code: > > Win32: > LockMutex(threadMu); > cl := self.closure; > self.id := nextId; INC (nextId); > UnlockMutex(threadMu); > > Pthread doesn't have this code. > I don't believe self.closure needs a lock. > And per above, pthreads doesn't need protection here for id, since > it is handled elsewhere. > > I know this was just discussed in a sense -- MyId is for debugging/ > diagnostics only and its value can't be depended on for much. > > The are obvious advantages/disadvantages to the two schemes. > Win32/Posix recycle "never", so debugging probably easier. > Pthread doesn't waste time/space on the id. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 16:01:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 10:01:16 -0400 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: None of what you say rings any bells. I don't think any of this is in the BroadcastHeap stuff. It *may* be similar to the POSIX hang that I fixed. I'll need to look more closely at the ThreadWin32 code. But you are getting corruption, not a hang, right? On 29 Sep 2009, at 07:19, Jay K wrote: > Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. > At least. The Enter/Leave mechanical replacement error. > > However even with that, the idle thread stuff seemed to cause > problems. > It was there forever, I realize. > > Also, I should have done this first, but anyway, later, I tried > merging back in your changes from Feb 16. > Somewhat they are moot (lock vs. LockMutex). > Somewhat they are already there (WaitHeap, heapCond => condition). > Somewhat they are trivial (fixing error messages). > > That leaves, in my analysis, the BroadcastHeap change. > > With this change however, /sometimes/ Juno hangs. > Is this, like, somehow equivalent to the Posix hang? > Is the current code the "best"? > > Oh darn..it hangs either way. Just not often. > Could that be "similar" to the pthread problem? > Any chance you can look at it? > > Thanks, > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:06:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:06:28 +0000 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: Fyi, I made us dependent on pthread_self fitting in an INTEGER, though it can be smaller. There are assertions that this is ok. I kind of just trolling..looking at pthreads for inspiration how to fix win32 threads..noticing the differences. We're much better now, but it still definitely hangs sometimes. :( - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ThreadF.MyID? Date: Tue, 29 Sep 2009 09:59:15 -0400 On 29 Sep 2009, at 05:24, Jay K wrote: Probably on Win32 should just use GetCurrentThreadId(). And pthread could just use pthread_self(). Yeah, but the type of pthread_self is indeterminate. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 09:18:57 +0000 Subject: [M3devel] ThreadF.MyID? The algorithms for thread id assignment vary on the platforms. In posix user threads and Win32 threads, it appears to be a number that increments for every new thread. Not sure what happens after 2 or 4 billion. On pthreads, it appears to be, well, we maintain an array of threads. So it is a number between 0 and n where n is the maximum number of threads that have "ever" been running at the same time. With presumably aggressive reuse of ids. Ok? They should all use the same? It's just that I'm looking at the Win32 code, comparing it to the pthread code: Win32: LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); Pthread doesn't have this code. I don't believe self.closure needs a lock. And per above, pthreads doesn't need protection here for id, since it is handled elsewhere. I know this was just discussed in a sense -- MyId is for debugging/diagnostics only and its value can't be depended on for much. The are obvious advantages/disadvantages to the two schemes. Win32/Posix recycle "never", so debugging probably easier. Pthread doesn't waste time/space on the id. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:12:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:12:06 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: The corruption is gone now. The combination of fixing Enter vs. Leave, and disabling/removing the idle threads solved the corruption. Neither alone seemed to work. The Enter/Leave problem was obvious, my fault. The idle threads I didn't dig into. Maybe you didn't realize waitSema was dual purpose???? Or maybe it was just the Enter/Leave? If anyone wants, certainly retest it with each change independently. Whenever I look, the Juno hang is on "untilDone" condition variable in Juno. RTIO shows it usually signals it in Misc: C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\Juno.m3(806): Thread.Signal(w.untilDone) but it doesn't seem to always, either when it hangs or sometimes when it doesn't hang. This /could/ be a bug in Juno or Trestle..except, and this isn't conclusive: I ran Juno @M3no-trestle-await-delete in a loop on Mac and it seemed to go forever. I'll leave it a few hours when I'm not home to see the screen flashing. Of course that switch merits review and/or implementation in a different place. Very useful for testing, very dubious otherwise. We need some sort of stress or fault-injection or variation-injection tests. Run threads deterministically in every combination of order, for example. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: win32 threads...now Juno sometimes hangs.. Date: Tue, 29 Sep 2009 10:01:16 -0400 None of what you say rings any bells. I don't think any of this is in the BroadcastHeap stuff. It *may* be similar to the POSIX hang that I fixed. I'll need to look more closely at the ThreadWin32 code. But you are getting corruption, not a hang, right? On 29 Sep 2009, at 07:19, Jay K wrote: Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. At least. The Enter/Leave mechanical replacement error. However even with that, the idle thread stuff seemed to cause problems. It was there forever, I realize. Also, I should have done this first, but anyway, later, I tried merging back in your changes from Feb 16. Somewhat they are moot (lock vs. LockMutex). Somewhat they are already there (WaitHeap, heapCond => condition). Somewhat they are trivial (fixing error messages). That leaves, in my analysis, the BroadcastHeap change. With this change however, /sometimes/ Juno hangs. Is this, like, somehow equivalent to the Posix hang? Is the current code the "best"? Oh darn..it hangs either way. Just not often. Could that be "similar" to the pthread problem? Any chance you can look at it? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:14:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:14:02 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: I could have easily flubbed it but the one time I tried to debug your Broadcast change, I had a deadlock due to one thread having the cm/giant lock and waiting for cs/heap, and another thread vice versa. It's pretty easy to see in the debugger. Given the presence of cm/giant on Win32 and not on pthreads, that doesn't seem too surprising. ? And/or I could easily have mismerged. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 29 Sep 2009 10:01:16 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. None of what you say rings any bells. I don't think any of this is in the BroadcastHeap stuff. It *may* be similar to the POSIX hang that I fixed. I'll need to look more closely at the ThreadWin32 code. But you are getting corruption, not a hang, right? On 29 Sep 2009, at 07:19, Jay K wrote: Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. At least. The Enter/Leave mechanical replacement error. However even with that, the idle thread stuff seemed to cause problems. It was there forever, I realize. Also, I should have done this first, but anyway, later, I tried merging back in your changes from Feb 16. Somewhat they are moot (lock vs. LockMutex). Somewhat they are already there (WaitHeap, heapCond => condition). Somewhat they are trivial (fixing error messages). That leaves, in my analysis, the BroadcastHeap change. With this change however, /sometimes/ Juno hangs. Is this, like, somehow equivalent to the Posix hang? Is the current code the "best"? Oh darn..it hangs either way. Just not often. Could that be "similar" to the pthread problem? Any chance you can look at it? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:16:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:16:11 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:23:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:23:07 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: ps: while I consider the whole stacksize thing broken anyway, notice that using an idle thread (which you had no choice about) got you an indeterminate stack size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:16:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:48:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:48:24 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: Tony..this semaphore with a maximum value of 1, that is a strange thing, isn't it? It could just be an event, right? I tried that..it took 50 runs to hang Juno.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] win32 threads...now Juno sometimes hangs.. Date: Tue, 29 Sep 2009 14:23:07 +0000 ps: while I consider the whole stacksize thing broken anyway, notice that using an idle thread (which you had no choice about) got you an indeterminate stack size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:16:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 17:09:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 15:09:10 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: ah, well now I've got 68 runs with an event amd /slight/ expansion of the giant lock -- in InnerWait I .release before Leave(giant). Given that release almost immediates enter giant anyway, that doesn't seem a bad move. It didn't hang at 68, it did: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x207fef8 0xfb62a5 Redisplay + 0x3ae in ..\src\vbt\VBTRep.m3 0x207ff24 0xfb5e34 UncoverRedisplay + 0xdd in ..\src\vbt\VBTRep.m3 0x207ff4c 0xfb5ec5 RdApply + 0x8c in ..\src\vbt\VBTRep.m3 0x207ff8c 0x5eacb9 RunThread + 0x184 in ..\src\thread\WIN32\ThreadWin32.m3 0x207ffb4 0x5eaaea ThreadBase + 0x33 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... C:\dev2\cm3.2\m3-libs\m3core>echo 69 && \cm3\bin\Juno.exe @M3no-trestle-await- delete 69 C:\dev2\cm3.2\m3-libs\m3core>echo 70 && \cm3\bin\Juno.exe @M3no-trestle-await- delete 70 I'll try again having put back the semaphore.. I rather suspect I have it fixed though and have uncovered some other problem. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:48:24 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. Tony..this semaphore with a maximum value of 1, that is a strange thing, isn't it? It could just be an event, right? I tried that..it took 50 runs to hang Juno.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] win32 threads...now Juno sometimes hangs.. Date: Tue, 29 Sep 2009 14:23:07 +0000 ps: while I consider the whole stacksize thing broken anyway, notice that using an idle thread (which you had no choice about) got you an indeterminate stack size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:16:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 17:25:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 11:25:06 -0400 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: <0951DB0C-7A75-403E-AB56-90AAE1A22C83@cs.purdue.edu> Ah, yes, interesting. On 29 Sep 2009, at 10:23, Jay K wrote: > ps: while I consider the whole stacksize thing broken anyway, notice > that using an idle thread (which you had no choice about) got you an > indeterminate stack size. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 29 Sep 2009 14:16:11 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. > > small email truncation: > > >> We need some sort of stress or fault-injection or variation- > injection tests. > >> Run threads deterministically in every combination of order, for > example. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 17:25:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 11:25:58 -0400 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: Hmm. Possibly. I'll look more closely. On 29 Sep 2009, at 10:14, Jay K wrote: > I could have easily flubbed it but the one time I tried to debug > your Broadcast change, I had a deadlock due to one thread having the > cm/giant lock and waiting for cs/heap, and another thread vice > versa. It's pretty easy to see in the debugger. > Given the presence of cm/giant on Win32 and not on pthreads, that > doesn't seem too surprising. > ? > And/or I could easily have mismerged. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 29 Sep 2009 10:01:16 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. > > None of what you say rings any bells. I don't think any of this is > in the BroadcastHeap stuff. It *may* be similar to the POSIX hang > that I fixed. I'll need to look more closely at the ThreadWin32 > code. But you are getting corruption, not a hang, right? > > On 29 Sep 2009, at 07:19, Jay K wrote: > > Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. > At least. The Enter/Leave mechanical replacement error. > > However even with that, the idle thread stuff seemed to cause > problems. > It was there forever, I realize. > > Also, I should have done this first, but anyway, later, I tried > merging back in your changes from Feb 16. > Somewhat they are moot (lock vs. LockMutex). > Somewhat they are already there (WaitHeap, heapCond => condition). > Somewhat they are trivial (fixing error messages). > > That leaves, in my analysis, the BroadcastHeap change. > > With this change however, /sometimes/ Juno hangs. > Is this, like, somehow equivalent to the Posix hang? > Is the current code the "best"? > > Oh darn..it hangs either way. Just not often. > Could that be "similar" to the pthread problem? > Any chance you can look at it? > > Thanks, > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 17:43:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 15:43:26 +0000 Subject: [M3devel] array out of bounds in VBTRep.Redisplay? Message-ID: Anyone ever seen: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1fffef8 0xfb62a5 Redisplay + 0x3ae in ..\src\vbt\VBTRep.m3 0x1ffff24 0xfb5e34 UncoverRedisplay + 0xdd in ..\src\vbt\VBTRep.m3 0x1ffff4c 0xfb5ec5 RdApply + 0x8c in ..\src\vbt\VBTRep.m3 0x1ffff8c 0x5eacd7 RunThread + 0x184 in ..\src\thread\WIN32\ThreadWin32.m3 0x1ffffb4 0x5eab08 ThreadBase + 0x33 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... line is apparently: v[dcount[list[i].depth - 1].n] := list[i].v; This is admittedly Juno on Win32. Maybe someone can study the function for bugs? I'll leave Juno looping for hours on a non-Win32 today or so. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 18:27:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 12:27:09 -0400 Subject: [M3devel] array out of bounds in VBTRep.Redisplay? In-Reply-To: References: Message-ID: <2CF5EA91-AD04-43C0-8632-CB27E4CB429F@cs.purdue.edu> Never seen it. Probably a race. I think Windows threads must still be broken somehow. On 29 Sep 2009, at 11:43, Jay K wrote: > Anyone ever seen: > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\src\vbt\VBTRep.m3", line 644 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1fffef8 0xfb62a5 Redisplay + 0x3ae in ..\src\vbt\VBTRep.m3 > 0x1ffff24 0xfb5e34 UncoverRedisplay + 0xdd in ..\src\vbt\VBTRep.m3 > 0x1ffff4c 0xfb5ec5 RdApply + 0x8c in ..\src\vbt\VBTRep.m3 > 0x1ffff8c 0x5eacd7 RunThread + 0x184 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x1ffffb4 0x5eab08 ThreadBase + 0x33 in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > > line is apparently: > v[dcount[list[i].depth - 1].n] := list[i].v; > > > This is admittedly Juno on Win32. > Maybe someone can study the function for bugs? > I'll leave Juno looping for hours on a non-Win32 today or so. > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 19:54:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 13:54:48 -0400 Subject: [M3devel] Win32 threads Message-ID: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> I believe that the hangs we are seeing are because of the race present in AlertWait, which permit a thread to miss seeing an alert before waiting on the condition. We want the thread only to wait if there has been no alert. Unfortunately, the alert is only protected by the global mutex, which must be release before waiting. Currently, we release the mutex, then wait, with the resulting race. This requires a more complicated handshake than currently implemented. Perhaps using SignalObjectAndWait instead as well as a Win32 mutex on each thread. Similarly to ThreadPThread.m3. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Tue Sep 29 20:13:04 2009 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 29 Sep 2009 20:13:04 +0200 Subject: [M3devel] Mailing list archive Message-ID: <4AC24E30.5030304@gmx.de> Hi, I would like to fix a bug I found in 2005, but the bug's details are not in trac, but only in a mailing list archive, which isn't available anymore. https://projects.elego.de/cm3/ticket/640 Can anyone provide me with the details? Roland From jay.krell at cornell.edu Tue Sep 29 22:12:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 20:12:00 +0000 Subject: [M3devel] Win32 threads In-Reply-To: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> References: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> Message-ID: SignalObjectAndWait is widely mentioned as important to implementing condition variables on Win32, however it is documented as not being atomic. Search the web: http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx "Note that the "signal" and "wait" are not guaranteed to be performed as an atomic operation. Threads executing on other processors can observe the signaled state of the first object before the thread calling SignalObjectAndWait begins its wait on the second object." So it isn't useful, right? Thanks, - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 13:54:48 -0400 Subject: [M3devel] Win32 threads I believe that the hangs we are seeing are because of the race present in AlertWait, which permit a thread to miss seeing an alert before waiting on the condition. We want the thread only to wait if there has been no alert. Unfortunately, the alert is only protected by the global mutex, which must be release before waiting. Currently, we release the mutex, then wait, with the resulting race. This requires a more complicated handshake than currently implemented. Perhaps using SignalObjectAndWait instead as well as a Win32 mutex on each thread. Similarly to ThreadPThread.m3. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 22:26:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 20:26:07 +0000 Subject: [M3devel] Win32 threads In-Reply-To: References: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> Message-ID: 1) Would it be useful to use native alertability? 2) Or to make alerted an event, and use WaitForMultipleObjects? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Tue, 29 Sep 2009 20:12:00 +0000 Subject: Re: [M3devel] Win32 threads SignalObjectAndWait is widely mentioned as important to implementing condition variables on Win32, however it is documented as not being atomic. Search the web: http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx "Note that the "signal" and "wait" are not guaranteed to be performed as an atomic operation. Threads executing on other processors can observe the signaled state of the first object before the thread calling SignalObjectAndWait begins its wait on the second object." So it isn't useful, right? Thanks, - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 13:54:48 -0400 Subject: [M3devel] Win32 threads I believe that the hangs we are seeing are because of the race present in AlertWait, which permit a thread to miss seeing an alert before waiting on the condition. We want the thread only to wait if there has been no alert. Unfortunately, the alert is only protected by the global mutex, which must be release before waiting. Currently, we release the mutex, then wait, with the resulting race. This requires a more complicated handshake than currently implemented. Perhaps using SignalObjectAndWait instead as well as a Win32 mutex on each thread. Similarly to ThreadPThread.m3. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 29 23:26:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Sep 2009 23:26:59 +0200 Subject: [M3devel] Mailing list archive In-Reply-To: <4AC24E30.5030304@gmx.de> References: <4AC24E30.5030304@gmx.de> Message-ID: <20090929232659.xvsqww0leccswck0@mail.elegosoft.com> Quoting Roland Illig : > Hi, > > I would like to fix a bug I found in 2005, but the bug's details are > not in trac, but only in a mailing list archive, which isn't available > anymore. > > https://projects.elego.de/cm3/ticket/640 > > Can anyone provide me with the details? Here is a copy of your old mail: X-Authenticated: #530625 Date: Tue, 11 Oct 2005 10:57:29 +0200 From: Roland Illig To: m3devel at elegosoft.com Subject: quake bug: local variable disappears X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavis (elego Software Solutions GmbH) X-List-Check-m3devel-pint-elegosoft-com: approved X-Virus-Scanned: by amavis (elego Software Solutions GmbH) X-Copy: forwarded from wagner at elego.de X-Virus-Scanned: by amavis (elego Software Solutions GmbH) X-Keywords: X-UID: 12885 proc first_of(arr) is foreach e in arr if not empty(e) return e end end return "cc" end proc compile_c(source, object, includes, o_flag, d_flag) is local cmd = [] local cc = first_of([$CC, "cc"]) cmd += [cc] return try_exec(cmd) end c_source("main") c_program("test") Critical Mass Modula-3 version d5.2.7 last updated: 2004-10-31 --- building in NetBSD2_i386 --- new source -> compiling main.c "/home/roland/proj/m3/c-test/src/m3makefile", line 14: quake runtime error: undefined variable: cmd The bug only shows because of: - the order of the two "local" statements in compile_c - a procedure is called - a "foreach" loop appears in the procedure - the "return" from inside the "foreach" loop is executed Roland -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Sep 29 23:31:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 17:31:36 -0400 Subject: [M3devel] Win32 threads In-Reply-To: References: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> Message-ID: If the documentation is true then it is essentially useless in general. Typical MS. On the other hand, several MS sources on the Web claim that it *is* atomic. Perhaps they should figure out what they really mean. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 29 Sep 2009, at 16:12, Jay K wrote: > SignalObjectAndWait is widely mentioned as important to implementing > condition variables on Win32, however it is documented as not being > atomic. > Search the web: > http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx > > "Note that the "signal" and "wait" are not guaranteed to be > performed as an atomic operation. Threads executing on other > processors can observe the signaled state of the first object before > the thread calling SignalObjectAndWait begins its wait on the second > object." > > So it isn't useful, right? > > Thanks, > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Tue, 29 Sep 2009 13:54:48 -0400 > Subject: [M3devel] Win32 threads > > I believe that the hangs we are seeing are because of the race > present in AlertWait, which permit a thread to miss seeing an alert > before waiting on the condition. We want the thread only to wait if > there has been no alert. Unfortunately, the alert is only protected > by the global mutex, which must be release before waiting. > Currently, we release the mutex, then wait, with the resulting > race. This requires a more complicated handshake than currently > implemented. Perhaps using SignalObjectAndWait instead as well as a > Win32 mutex on each thread. Similarly to ThreadPThread.m3. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 1 01:23:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 01:23:26 +0200 Subject: [M3devel] Pickling problem from 64 to 32 bit platforms In-Reply-To: <4A9C429B.9070308@cox.net> References: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> <4A9C429B.9070308@cox.net> Message-ID: <20090901012326.ey14b7i9bc484008@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Some initial observations: > > I don't understand the circumstances where this is happening. > "pickles from 64 to 32 bit" sounds to me like the pickle was written > on a 64-bit machine and read on a 32-bit machine. But the backtrace > seems to be of a run on a 64-bit machine, in part because of the > filename in the outermost frame: > > #38 0x0000000000408409 in _start () at ../sysdeps/x86_64/elf/start.S:113 > ^^^^^^ > > and in part, because all the hexadecimal addresses are 64-bit values. > > This example seems to be using version 1 of pickles: #5 > 0x000000000045ac12 in ReadRef (reader=16_00000000025b2018) at > ../src/pickle/ver1/Pickle.m3:529 > > ^^^^ > > Without some vetting, I can't say for sure, but I'm not sure this > version ever did all the > cross-target stuff completely. Did this case work earlier under the > same circumstances? > > The len parameter to String8.Hash has surely gone bad. Could there > something wrong > with operations on CARDINAL on 64-bit machines? What is the symptom > of the failure? What needs to be run to reproduce it? The tickets says: "Testing the network objects from 64 bit client to 32 bit target using Linux Debian Lenny. The perf test fails on any of the oc oq r rc object call tests." So I assume the test to be run is cm3/m3-comm/netobj/tests/perf; the client is a 64 bit machine, the server is a 32 bit machine, and we see a backtrace from the client. peter.mckinna at gmail.com who wrote the ticket may be able to provide more details. I cannot easily test this myself as I don't have the required machines close together anywhere. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Sep 1 11:45:33 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 11:45:33 +0200 Subject: [M3devel] last RC3 tasks Message-ID: <20090901114533.f2wgu748hwkg4gok@mail.elegosoft.com> Jay, I have moved the current version on the release branch from RC3 to pre-RC4. If you build any more packages for RC3, you have to explicitly set the version via the DS variable (originally datestamp for snapshots). I'd like to close the RC3 tasks in trac and retarget everything to the final release or RC4. However, there are some open issues: o I think we should offer packages for I386_DARWIN. Could you provide them? o There are some packages named pre-RC3 in the download area from you. These should probably be removed? o What's the status of the MSI installer for Windows? Automation can wait until RC4, but can we have a package on birch? o AMD64_FREEBSD looks rather incomplete and old. Have you run any tests on it? Should it be removed? When the packages are OK, I'd like to post a public announcement on comp.lang.modula3 and www.modula3.org. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Sep 1 13:02:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 13:02:03 +0200 Subject: [M3devel] last RC3 tasks In-Reply-To: <20090901114533.f2wgu748hwkg4gok@mail.elegosoft.com> References: <20090901114533.f2wgu748hwkg4gok@mail.elegosoft.com> Message-ID: <20090901130203.fhpolgatc4ks488g@mail.elegosoft.com> Quoting Olaf Wagner : > Jay, > > I have moved the current version on the release branch from RC3 to pre-RC4. > If you build any more packages for RC3, you have to explicitly set the > version via the DS variable (originally datestamp for snapshots). I made a mistake in the script: DS cannot be overwritten from the environment. Will fix tonight if nobody is faster. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Sep 1 14:56:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 14:56:28 +0200 Subject: [M3devel] p007 not terminating on NT386 Message-ID: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> It looks as if m3test p007 does not terminate any more on NT386. This used to work. I just found this --- p007 --- a whole bunch of threads - does the memory grow ? cd ..\src\p0\p007 && cm3 -silent -DM3TESTS >NT386\stdout.build.raw 2>NT386\stderr.build.raw running for more than 5 hours. The last successful run was http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Sep 1 15:51:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 09:51:23 -0400 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> Message-ID: <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> These thread problems are relatively new (similar to Jay's problems with AutoFlushWr...). Something quite bad must have happened recently to cause them. I took a quick look at ThreadPThread.m3 but didn't notice anything obviously wrong. Something else perhaps? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 1 Sep 2009, at 08:56, Olaf Wagner wrote: > It looks as if m3test p007 does not terminate any more on NT386. > This used to work. I just found this > > --- p007 --- a whole bunch of threads - does the memory grow ? > > cd ..\src\p0\p007 && cm3 -silent -DM3TESTS >NT386\stdout.build.raw > 2>NT386\stderr.build.raw > > running for more than 5 hours. > > The last successful run was > http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/ > . > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 1 16:13:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Sep 2009 14:13:06 +0000 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> Message-ID: AutoFlushWr: on non-I386_OPENBSD, it passed in the test runs, but generally hit assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe others. on I386_OPENBSD: it hangs The code was a bit hard for me to verify the correctness of. I replaced it with an easy to understand version and the non-I386_OPENBSD problems went away. The I386_OPENBSD hang remains. In particular, AutoFlushWr layers a Wr over a Wr, but if the underlying Wr is buffered, it strives to not add an additional buffering layer. If the underlying Wr is not buffered, it does add buffering. All Wrs have a few public fields to implement buffering. AutoFlushWr copies these fields back and forth. I think it was a) optimizing which fields to copy based on knowing which fields the toplevel Wr modified when b) I think it was doing some computation them that it should not have, instead of just copying them. I just have it basically copy all the fields all the time. There are just a few. Agreed, the I386_OPENBSD hang might be related. I think I might have to try out very old versions, like I'm doing (slowly!) for the formsedit crash. Maybe not, since the I386_OPENBSD hang is easy to reproduce and only involves two threads -- not too complicated. I think p007 also hangs on Cygwin, but it always has. I tried debugging it but Cygwin seemed like a mess. Granted, it hung with Cygwin whether or not I used pthreads or NT threads. Recentness isn't particularly clear I think, since I don't think these platforms have ever had good test coverage. But I did think regular NT386 was ok here. Later, - Jay ________________________________ > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 1 Sep 2009 09:51:23 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] p007 not terminating on NT386 > > These thread problems are relatively new (similar to Jay's problems with AutoFlushWr...). Something quite bad must have happened recently to cause them. I took a quick look at ThreadPThread.m3 but didn't notice anything obviously wrong. Something else perhaps? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 1 Sep 2009, at 08:56, Olaf Wagner wrote: > > It looks as if m3test p007 does not terminate any more on NT386. > This used to work. I just found this > > --- p007 --- a whole bunch of threads - does the memory grow ? > > cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw 2>NT386\stderr.build.raw > > running for more than 5 hours. > > The last successful run was > http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From hosking at cs.purdue.edu Tue Sep 1 16:54:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 10:54:26 -0400 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> Message-ID: <3B500B6D-168E-4BA7-819D-43E6C9D6BB03@cs.purdue.edu> On 1 Sep 2009, at 10:13, Jay K wrote: > > AutoFlushWr: > on non-I386_OPENBSD, it passed in the test runs, but generally hit > assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe > others. > on I386_OPENBSD: it hangs > > > The code was a bit hard for me to verify the correctness of. I > replaced it with an easy to understand version and the non- > I386_OPENBSD problems went away. The I386_OPENBSD hang remains. > > > In particular, AutoFlushWr layers a Wr over a Wr, but if the > underlying Wr is buffered, it strives to not add an additional > buffering layer. If the underlying Wr is not buffered, it does add > buffering. All Wrs have a few public fields to implement buffering. > AutoFlushWr copies these fields back and forth. I think it was a) > optimizing which fields to copy based on knowing which fields the > toplevel Wr modified when b) I think it was doing some computation > them that it should not have, instead of just copying them. I just > have it basically copy all the fields all the time. There are just a > few. OK, sounds like we all need to take a closer look at this code and satisfy ourselves that it is now correct. > Agreed, the I386_OPENBSD hang might be related. > I think I might have to try out very old versions, like I'm doing > (slowly!) for the formsedit crash. > Maybe not, since the I386_OPENBSD hang is easy to reproduce and only > involves two threads -- not too complicated. This is particularly weird, since it is clear that the main thread is trying to stop the other thread, but the other thread is not responding. I wonder if signal delivery to waiting threads is broken on OpenBSD? > I think p007 also hangs on Cygwin, but it always has. I tried > debugging it but Cygwin seemed like a mess. Granted, it hung with > Cygwin whether or not I used pthreads or NT threads. I have a feeling p007 is just buggy in itself -- it looks like there is a serious race in there. So, in this case I think the test is broken, not the platform. I'll try to clean it up. > Recentness isn't particularly clear I think, since I don't think > these platforms have ever had good test coverage. But I did think > regular NT386 was ok here. > > > Later, > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 1 Sep 2009 09:51:23 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] p007 not terminating on NT386 >> >> These thread problems are relatively new (similar to Jay's problems >> with AutoFlushWr...). Something quite bad must have happened >> recently to cause them. I took a quick look at ThreadPThread.m3 but >> didn't notice anything obviously wrong. Something else perhaps? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 1 Sep 2009, at 08:56, Olaf Wagner wrote: >> >> It looks as if m3test p007 does not terminate any more on NT386. >> This used to work. I just found this >> >> --- p007 --- a whole bunch of threads - does the memory grow ? >> >> cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw >> 2>NT386\stderr.build.raw >> >> running for more than 5 hours. >> >> The last successful run was >> http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/ >> . >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> From jay.krell at cornell.edu Tue Sep 1 19:47:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Sep 2009 17:47:13 +0000 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: <3B500B6D-168E-4BA7-819D-43E6C9D6BB03@cs.purdue.edu> References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> <3B500B6D-168E-4BA7-819D-43E6C9D6BB03@cs.purdue.edu> Message-ID: > take a closer look Sure. I'm suspicious of the entire approach actually. I understand that layering/pipelining Rd/Wr can be very nice, but I think there are better approaches here. 1) Don't layer a Wr over a Wr. Just have a worker thread and a table of weakrefs to Wr. Understandable downside to this approach is without an interception point, it doesn't know if a Wr has any data worth flushing, it would needlessly flush idle Wrs. or 2) Mark the upper Wr as not buffered -- not clear to me if adding buffering to unbuffered Wr is a goal. I'm not sure unbuffered Wr even makes sense, I have to reread it.. Underlying point is that, let's say I have a "counting Wr"..you know a Wr of very little but non-zero semantic. It seems too difficult imho to layer in a Wr that does very little. But again, I should reeread. Thank you for fixing the test case. I'll have to try Cygwin again here. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 1 Sep 2009 10:54:26 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] p007 not terminating on NT386 > > On 1 Sep 2009, at 10:13, Jay K wrote: > >> >> AutoFlushWr: >> on non-I386_OPENBSD, it passed in the test runs, but generally hit >> assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe >> others. >> on I386_OPENBSD: it hangs >> >> >> The code was a bit hard for me to verify the correctness of. I >> replaced it with an easy to understand version and the non- >> I386_OPENBSD problems went away. The I386_OPENBSD hang remains. >> >> >> In particular, AutoFlushWr layers a Wr over a Wr, but if the >> underlying Wr is buffered, it strives to not add an additional >> buffering layer. If the underlying Wr is not buffered, it does add >> buffering. All Wrs have a few public fields to implement buffering. >> AutoFlushWr copies these fields back and forth. I think it was a) >> optimizing which fields to copy based on knowing which fields the >> toplevel Wr modified when b) I think it was doing some computation >> them that it should not have, instead of just copying them. I just >> have it basically copy all the fields all the time. There are just a >> few. > > OK, sounds like we all need to take a closer look at this code and > satisfy ourselves that it is now correct. > >> Agreed, the I386_OPENBSD hang might be related. >> I think I might have to try out very old versions, like I'm doing >> (slowly!) for the formsedit crash. >> Maybe not, since the I386_OPENBSD hang is easy to reproduce and only >> involves two threads -- not too complicated. > > This is particularly weird, since it is clear that the main thread is > trying to stop the other thread, but the other thread is not > responding. I wonder if signal delivery to waiting threads is broken > on OpenBSD? > >> I think p007 also hangs on Cygwin, but it always has. I tried >> debugging it but Cygwin seemed like a mess. Granted, it hung with >> Cygwin whether or not I used pthreads or NT threads. > > I have a feeling p007 is just buggy in itself -- it looks like there > is a serious race in there. So, in this case I think the test is > broken, not the platform. I'll try to clean it up. > > >> Recentness isn't particularly clear I think, since I don't think >> these platforms have ever had good test coverage. But I did think >> regular NT386 was ok here. >> >> >> Later, >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 1 Sep 2009 09:51:23 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] p007 not terminating on NT386 >>> >>> These thread problems are relatively new (similar to Jay's problems >>> with AutoFlushWr...). Something quite bad must have happened >>> recently to cause them. I took a quick look at ThreadPThread.m3 but >>> didn't notice anything obviously wrong. Something else perhaps? >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 1 Sep 2009, at 08:56, Olaf Wagner wrote: >>> >>> It looks as if m3test p007 does not terminate any more on NT386. >>> This used to work. I just found this >>> >>> --- p007 --- a whole bunch of threads - does the memory grow ? >>> >>> cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw >>> 2>NT386\stderr.build.raw >>> >>> running for more than 5 hours. >>> >>> The last successful run was >>> http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/ >>> . >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> > From rcoleburn at scires.com Wed Sep 2 02:09:25 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Sep 2009 20:09:25 -0400 Subject: [M3devel] report on Windows XP builds/tests Message-ID: <4A9D7F7B.1E75.00D7.1@scires.com> Hi, I am back from vacation. I've updated my sandbox on WindowsXP to be current with the CVS head. I tried first to run Jay's "upgrade.py", but got the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py using c:\cm3\bin\cm3.exe PATH=c:\cm3\bin;%PATH% set CM3_TARGET=NT386 set CM3_INSTALL=c:\cm3 set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 set CM3_ROOT=C:/cm3/Sandbox/cm3 ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) C:\cm3\Sandbox\cm3\scripts\python> Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: C:\cm3\bin>mentor *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 ......... ......... ... more frames ... C:\cm3\bin>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 2284 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... C:\cm3\bin> Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. I will try to run some tests on Vista platform tomorrow. Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. Let me know how I can best assist with the release effort. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 2 02:29:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 20:29:59 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: <4A9D7F7B.1E75.00D7.1@scires.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> Message-ID: <0FA9C0AE-2B85-4574-A90F-1C1A81DE98BB@cs.purdue.edu> Possibly something very broken in mutexes? On 1 Sep 2009, at 20:09, Randy Coleburn wrote: > Hi, I am back from vacation. > > I've updated my sandbox on WindowsXP to be current with the CVS head. > > I tried first to run Jay's "upgrade.py", but got the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > using c:\cm3\bin\cm3.exe > PATH=c:\cm3\bin;%PATH% > set CM3_TARGET=NT386 > set CM3_INSTALL=c:\cm3 > set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- > install\NT386 > set CM3_ROOT=C:/cm3/Sandbox/cm3 > ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: > \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files > \Microsoft Platform SDK for Windows Server 2003 R2\Include) > C:\cm3\Sandbox\cm3\scripts\python> > > Next I tried my upgrade script and was successful. Then I used my > "do-cm3.cmd" script to rebuild all packages and was successful, > except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib > \test". > > In catching up on my email, I noticed Olaf had asked about mentor > and juno on Windows, so I tried running these. Juno starts up and > puts up a window, but quickly crashes. mentor crashes before any > window comes up and I also get a firewall request from Windows > asking whether to block the program--I suspect it is trying to > access the network, hence the firewall request. Here are the > runtime error reports: > > C:\cm3\bin>mentor > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime > \NT386\RTSignal.m3 > 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 > 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 > 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 > 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > > C:\cm3\bin>juno > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 2284 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime > \common\RTCollector.m3 > 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 > 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 > 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 > 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 > 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 > 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 > 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 > 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 > 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > C:\cm3\bin> > > Juno crashes on an ASSERT in the collector, while mentor seems to be > trying to lock a mutex that isn't properly initialized. I have not > looked at the source code to try and debug. Let me know if you want > me to pursue further. > > I've rebuilt some of my own programs and run some very basic tests. > So far, no problems detected. > > I will try to run some tests on Vista platform tomorrow. > > Maybe it would be prudent for me to compile and run some of the > tests ya'll have been implementing. I think the scripts for these > aren't native Windows, but if you can point me to some of these, > I'll try to translate for use on Windows. > > Let me know how I can best assist with the release effort. > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 2 03:33:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 01:33:41 +0000 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: <4A9D7F7B.1E75.00D7.1@scires.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> Message-ID: Is the message about errno.h correct? caltech-parser..hm.. you are up to date? I thought I had either fixed it, or filtered it out. Mutex/mentor I'll have to look at. - Jay Date: Tue, 1 Sep 2009 20:09:25 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] report on Windows XP builds/tests Hi, I am back from vacation. I've updated my sandbox on WindowsXP to be current with the CVS head. I tried first to run Jay's "upgrade.py", but got the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py using c:\cm3\bin\cm3.exe PATH=c:\cm3\bin;%PATH% set CM3_TARGET=NT386 set CM3_INSTALL=c:\cm3 set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 set CM3_ROOT=C:/cm3/Sandbox/cm3 ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) C:\cm3\Sandbox\cm3\scripts\python> Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: C:\cm3\bin>mentor *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 ......... ......... ... more frames ... C:\cm3\bin>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 2284 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... C:\cm3\bin> Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. I will try to run some tests on Vista platform tomorrow. Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. Let me know how I can best assist with the release effort. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Wed Sep 2 03:56:02 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Tue, 01 Sep 2009 20:56:02 -0500 Subject: [M3devel] Mentor error on LINUXLIBC6 Message-ID: <4A9DD0B2.4010505@esoteriq.org> I installed the RC3 core fine, worked well, but I was adding addition packages and tried running mentor. I get: mentor: error while loading shared library libobliqlibanim.so.5: cannot open shared object file: No such file or directory. I'm guessing this is because I didn't install the Obliq package...but why should I have to? From mbishop at esoteriq.org Wed Sep 2 03:58:06 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Tue, 01 Sep 2009 20:58:06 -0500 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <4A9DD0B2.4010505@esoteriq.org> References: <4A9DD0B2.4010505@esoteriq.org> Message-ID: <4A9DD12E.2080903@esoteriq.org> Martin Bishop wrote: > I installed the RC3 core fine, worked well, but I was adding addition > packages and tried running mentor. I get: > > mentor: error while loading shared library libobliqlibanim.so.5: > cannot open shared object file: No such file or directory. > > I'm guessing this is because I didn't install the Obliq package...but > why should I have to? > Oh, and another issue (might just be me?) when I use the install scripts in each package, they complain that "cm3" is not found. If it change it to /usr/local/cm3/bin/cm3, it works just fine. From hosking at cs.purdue.edu Wed Sep 2 04:06:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 22:06:07 -0400 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <4A9DD0B2.4010505@esoteriq.org> References: <4A9DD0B2.4010505@esoteriq.org> Message-ID: <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> Because mentor depends on obliq? If you didn't install the obliq package then it can't dynamically load the shard library. On 1 Sep 2009, at 21:56, Martin Bishop wrote: > I installed the RC3 core fine, worked well, but I was adding > addition packages and tried running mentor. I get: > > mentor: error while loading shared library libobliqlibanim.so.5: > cannot open shared object file: No such file or directory. > > I'm guessing this is because I didn't install the Obliq > package...but why should I have to? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Sep 2 04:53:10 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Sep 2009 22:53:10 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> Message-ID: <4A9DA5DB.1E75.00D7.1@scires.com> I tried upgrade.py again, and it seemed to work this time. I think I may have forgotten to run vcvars to setup the Visual C++ command line on my prior attempt. Sorry. Here is the compiler output for the "caltech-parser\parserlib\parserlib\test" build: --- processing package "caltech-parser\parserlib\parserlib\test" --- --- building in NT386 --- LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed I tried running juno and mentor again. I get different results each run. Interestingly, sometimes mentor didn't crash, instead giving me an error message about not having my HOME environment var set. I tried later to set this, but mentor still crashes. Once when I ran juno it complained that it tried to join a thread twice. Sounds like something is broken in the threading or GC, or the program is coded wrongly somehow. See below for some sample runs of mentor and juno: C:\cm3\Sandbox\cm3\scripts\win>mentor *** *** runtime error: *** Exception "FormsVBT.Error" not in RAISES list *** file "..\src\FormsVBT.m3", line 73 *** *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "..\src\runtime\common\RTType.m3", line 71 *** C:\cm3\Sandbox\cm3\scripts\win>mentor Error: the HOME environment variable is undefined. Please set it to the path of your home directory and try again. C:\cm3\Sandbox\cm3\scripts\win>mentor Error: the HOME environment variable is undefined. Please set it to the path of your home directory and try again. C:\cm3\Sandbox\cm3\scripts\win>mentor *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread\WIN32\ThreadWin32.m3 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 0x12fe88 0x4e32da RegisterView + 0x30 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 Here is another run of Juno. This one dies on a different line number in same module. C:\cm3\Sandbox\cm3\scripts\win>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 1087 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common\RTCollector.m3 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime\common\RTCollector.m3 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src\JunoCompile.m3 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src\JunoCompile.m3 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src\JunoCompile.m3 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src\JunoCompile.m3 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src\JunoCompile.m3 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src\JunoCompile.m3 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src\JunoCompile.m3 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... Regards, Randy Coleburn >>> Jay K 9/1/2009 9:33 PM >>> Is the message about errno.h correct? caltech-parser..hm.. you are up to date? I thought I had either fixed it, or filtered it out. Mutex/mentor I'll have to look at. - Jay Date: Tue, 1 Sep 2009 20:09:25 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] report on Windows XP builds/tests Hi, I am back from vacation. I've updated my sandbox on WindowsXP to be current with the CVS head. I tried first to run Jay's "upgrade.py", but got the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py using c:\cm3\bin\cm3.exe PATH=c:\cm3\bin;%PATH% set CM3_TARGET=NT386 set CM3_INSTALL=c:\cm3 set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 set CM3_ROOT=C:/cm3/Sandbox/cm3 ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) C:\cm3\Sandbox\cm3\scripts\python> Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: C:\cm3\bin>mentor *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 ......... ......... ... more frames ... C:\cm3\bin>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 2284 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... C:\cm3\bin> Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. I will try to run some tests on Vista platform tomorrow. Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. Let me know how I can best assist with the release effort. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 2 05:52:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 23:52:39 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: <4A9DA5DB.1E75.00D7.1@scires.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: mentor (and probably other GUI apps) lock up in ways I have not seen before (it has been a long time since I tried running it, but it always used to work for me without problems about the time that I was bedding down the native threads code so logs there might give the timeframe). I suspect something is quite broken, but don't know when the brokenness got introduced. Here is a backtrace for all threads: Thread 20 (process 84568 thread 0x4f07): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:669 #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:686 #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../ src/xvbt/XClientF.m3:105 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 19 (process 84568 thread 0x4e0b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../ src/Zeus.m3:328 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 18 (process 84568 thread 0x5c0b): #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:189 #1 0x0101ee7a in ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:324 #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') at ../ src/thread/PTHREAD/ThreadPThread.m3:670 #3 0x0101f77a in Thread__AlertPause (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ ThreadPThread.m3:700 #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../ src/Animate.m3:71 #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313 #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 #7 0x00020798 in ViewIncrementalReal__ShowPixel (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ ViewIncrementalReal.m3:567 #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../ src/Zeus.m3:331 #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #11 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #12 0x96373155 in _pthread_start () #13 0x96373012 in thread_start () Thread 17 (process 84568 thread 0x6f0f): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../ src/Zeus.m3:328 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 16 (process 84568 thread 0x425b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) at ../src/ZeusPanel.m3:1425 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 15 (process 84568 thread 0x310b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) at ../src/View.m3:74 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 14 (process 84568 thread 0x3003): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) at ../src/View.m3:74 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 13 (process 84568 thread 0x2f03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) at ../src/View.m3:74 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 12 (process 84568 thread 0x2e03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) at ../src/xvbt/XMessenger.m3:69 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 11 (process 84568 thread 0x2d03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) at ../src/xvbt/XInput.m3:102 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 10 (process 84568 thread 0x2a2b): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/unix/ Common/UnixC.c:301 #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ PTHREAD/ThreadPThread.m3:788 #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ PTHREAD/ThreadPThread.m3:827 #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ thread/PTHREAD/ThreadPThread.m3:730 #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) at ../src/xvbt/XInput.m3:63 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 9 (process 84568 thread 0x29f3): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 #7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/BresenhamIE.m3:227 #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../ src/bresenham/AlgBresenham.m3:55 #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../ src/bresenham/AlgBresenham.m3:86 #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) at ../ src/ZeusPanel.m3:1534 #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 8 (process 84568 thread 0x2803): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) at ../ src/formatter/Formatter.m3:615 #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 7 (process 84568 thread 0x2703): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) at ../ src/formatter/Formatter.m3:615 #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 6 (process 84568 thread 0x2603): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) at ../src/WorkerPool.m3:152 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 5 (process 84568 thread 0x2313): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../src/ unix/Common/UnixC.c:301 #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/ thread/PTHREAD/ThreadPThread.m3:788 #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=1 '\001') at ../src/thread/ PTHREAD/ThreadPThread.m3:827 #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ src/thread/PTHREAD/ThreadPThread.m3:743 #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/POSIX/ TCP.m3:234 #7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #9 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #10 0x96373155 in _pthread_start () #11 0x96373012 in thread_start () Thread 4 (process 84568 thread 0x2003): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:669 #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:686 #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) at ../src/lego/FileBrowserVBT.m3:259 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 3 (process 84568 thread 0x1f03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 2 (process 84568 thread 0x313): #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../ src/thread/PTHREAD/ThreadPThread.m3:669 #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:686 #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../ src/vbt/VBTRep.m3:460 #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #4 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #5 0x96373155 in _pthread_start () #6 0x96373012 in thread_start () Thread 1 (process 84568 local thread 0x2e03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../ src/trestle/Trestle.m3:884 #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ src/runtime/common/RTLinker.m3:400 #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at _m3main.mc:6 On 1 Sep 2009, at 22:53, Randy Coleburn wrote: > I tried upgrade.py again, and it seemed to work this time. I think > I may have forgotten to run vcvars to setup the Visual C++ command > line on my prior attempt. Sorry. > > Here is the compiler output for the "caltech-parser\parserlib > \parserlib\test" build: > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > > LIB_INSTALL is C:\cm3\lib > ignoring ..\src\m3overrides > > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o > CalcTok.i3 > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o > CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime > error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src > \Calc.t -o CalcTok.i3 > > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\NT386\m3make.args > > Fatal Error: package build failed > > I tried running juno and mentor again. I get different results each > run. Interestingly, sometimes mentor didn't crash, instead giving > me an error message about not having my HOME environment var set. I > tried later to set this, but mentor still crashes. Once when I ran > juno it complained that it tried to join a thread twice. Sounds > like something is broken in the threading or GC, or the program is > coded wrongly somehow. See below for some sample runs of mentor and > juno: > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** Exception "FormsVBT.Error" not in RAISES list > *** file "..\src\FormsVBT.m3", line 73 > *** > > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "..\src\runtime\common\RTType.m3", line 71 > *** > > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 > 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 > 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 > 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 > 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 > 0x12fe88 0x4e32da RegisterView + 0x30 in .. > \NT386\MinimaxViewGameTreeBObliqView.m3 > 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in .. > \NT386\MinimaxViewGameTreeBObliqView.m3 > > Here is another run of Juno. This one dies on a different line > number in same module. > > > C:\cm3\Sandbox\cm3\scripts\win>juno > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1087 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common > \RTCollector.m3 > 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime > \common\RTCollector.m3 > 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src > \JunoCompile.m3 > 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src > \JunoCompile.m3 > 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src > \JunoCompile.m3 > 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src > \JunoCompile.m3 > 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src > \JunoCompile.m3 > 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src > \JunoCompile.m3 > 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src > \JunoCompile.m3 > 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src > \JunoCompile.m3 > ......... ......... ... more frames ... > > Regards, > Randy Coleburn > > >>> Jay K 9/1/2009 9:33 PM >>> > Is the message about errno.h correct? > caltech-parser..hm.. you are up to date? I thought I had either > fixed it, or filtered it out. > Mutex/mentor I'll have to look at. > > - Jay > > Date: Tue, 1 Sep 2009 20:09:25 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] report on Windows XP builds/tests > > Hi, I am back from vacation. > > I've updated my sandbox on WindowsXP to be current with the CVS head. > > I tried first to run Jay's "upgrade.py", but got the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > using c:\cm3\bin\cm3.exe > PATH=c:\cm3\bin;%PATH% > set CM3_TARGET=NT386 > set CM3_INSTALL=c:\cm3 > set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- > install\NT386 > set CM3_ROOT=C:/cm3/Sandbox/cm3 > ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: > \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files > \Microsoft Platform SDK for Windows Server 2003 R2\Include) > C:\cm3\Sandbox\cm3\scripts\python> > > Next I tried my upgrade script and was successful. Then I used my > "do-cm3.cmd" script to rebuild all packages and was successful, > except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib > \test". > > In catching up on my email, I noticed Olaf had asked about mentor > and juno on Windows, so I tried running these. Juno starts up and > puts up a window, but quickly crashes. mentor crashes before any > window comes up and I also get a firewall request from Windows > asking whether to block the program--I suspect it is trying to > access the network, hence the firewall request. Here are the > runtime error reports: > > C:\cm3\bin>mentor > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime > \NT386\RTSignal.m3 > 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 > 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 > 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 > 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > > C:\cm3\bin>juno > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 2284 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime > \common\RTCollector.m3 > 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 > 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 > 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 > 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 > 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 > 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 > 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 > 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 > 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > C:\cm3\bin> > > Juno crashes on an ASSERT in the collector, while mentor seems to be > trying to lock a mutex that isn't properly initialized. I have not > looked at the source code to try and debug. Let me know if you want > me to pursue further. > > I've rebuilt some of my own programs and run some very basic tests. > So far, no problems detected. > > I will try to run some tests on Vista platform tomorrow. > > Maybe it would be prudent for me to compile and run some of the > tests ya'll have been implementing. I think the scripts for these > aren't native Windows, but if you can point me to some of these, > I'll try to translate for use on Windows. > > Let me know how I can best assist with the release effort. > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 2 06:00:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 04:00:12 +0000 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <4A9DD12E.2080903@esoteriq.org> References: <4A9DD0B2.4010505@esoteriq.org> <4A9DD12E.2080903@esoteriq.org> Message-ID: I had the same experience with cm3 not found. cm3 is expected to be on the path. Seems kind of reasonable? As to the need to have dependencies -- well, this is our simple cross platform package format. Ahem, if we just bundled everything together in one package, the dependency problem would go away. Granted, maybe that is yucky. - Jay > Date: Tue, 1 Sep 2009 20:58:06 -0500 > From: mbishop at esoteriq.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Mentor error on LINUXLIBC6 > > Martin Bishop wrote: > > I installed the RC3 core fine, worked well, but I was adding addition > > packages and tried running mentor. I get: > > > > mentor: error while loading shared library libobliqlibanim.so.5: > > cannot open shared object file: No such file or directory. > > > > I'm guessing this is because I didn't install the Obliq package...but > > why should I have to? > > > Oh, and another issue (might just be me?) when I use the install scripts > in each package, they complain that "cm3" is not found. If it change it > to /usr/local/cm3/bin/cm3, it works just fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 2 06:20:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 04:20:41 +0000 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: My fear is that I messed up when I factored sizeof(pthread_cond_t), sizeof(pthread_mutex_t), etc. out of the Modula-3 code. The code looks right, but it is easy to miss a level of indirection, or something. We also might as well wrap the last few that aren't wrapped, but no reason to believe that will fix anything. My dashed hope is/was that the compiler being written in Modula-3, including using multiple threads, for garbage collection, would be a good test of the overall system working. The caltech-parser problem looks familiar. I'll have to look again. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Tue, 1 Sep 2009 23:52:39 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] report on Windows XP builds/tests > > mentor (and probably other GUI apps) lock up in ways I have not seen before (it has been a long time since I tried running it, but it always used to work for me without problems about the time that I was bedding down the native threads code so logs there might give the timeframe). I suspect something is quite broken, but don't know when the brokenness got introduced. Here is a backtrace for all threads: > > Thread 20 (process 84568 thread 0x4f07): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:686 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../src/xvbt/XClientF.m3:105 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 19 (process 84568 thread 0x4e0b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../src/Zeus.m3:328 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 84568 thread 0x5c0b): > #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:189 > #1 0x0101ee7a in ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:324 > #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:670 > #3 0x0101f77a in Thread__AlertPause (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ThreadPThread.m3:700 > #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71 > #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #7 0x00020798 in ViewIncrementalReal__ShowPixel (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ViewIncrementalReal.m3:567 > #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 > #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../src/Zeus.m3:331 > #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #11 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #12 0x96373155 in _pthread_start () > #13 0x96373012 in thread_start () > > Thread 17 (process 84568 thread 0x6f0f): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../src/Zeus.m3:328 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 16 (process 84568 thread 0x425b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) at ../src/ZeusPanel.m3:1425 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 84568 thread 0x310b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) at ../src/View.m3:74 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 84568 thread 0x3003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) at ../src/View.m3:74 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 84568 thread 0x2f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) at ../src/View.m3:74 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 84568 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) at ../src/xvbt/XMessenger.m3:69 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 84568 thread 0x2d03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) at ../src/xvbt/XInput.m3:102 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 84568 thread 0x2a2b): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/unix/Common/UnixC.c:301 > #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:788 > #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:827 > #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:730 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) at ../src/xvbt/XInput.m3:63 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 84568 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) at ../src/ZeusPanel.m3:1534 > #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 84568 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) at ../src/formatter/Formatter.m3:615 > #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 84568 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) at ../src/formatter/Formatter.m3:615 > #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 84568 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) at ../src/WorkerPool.m3:152 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 84568 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../src/unix/Common/UnixC.c:301 > #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/thread/PTHREAD/ThreadPThread.m3:788 > #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:827 > #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:743 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 > #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #9 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 84568 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:686 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) at ../src/lego/FileBrowserVBT.m3:259 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 84568 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 84568 thread 0x313): > #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:686 > #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../src/vbt/VBTRep.m3:460 > #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #4 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #5 0x96373155 in _pthread_start () > #6 0x96373012 in thread_start () > > Thread 1 (process 84568 local thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:400 > #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at _m3main.mc:6 > > > On 1 Sep 2009, at 22:53, Randy Coleburn wrote: > > I tried upgrade.py again, and it seemed to work this time. I think I may have forgotten to run vcvars to setup the Visual C++ command line on my prior attempt. Sorry. > > Here is the compiler output for the "caltech-parser\parserlib\parserlib\test" build: > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > > LIB_INSTALL is C:\cm3\lib > ignoring ..\src\m3overrides > > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args > > Fatal Error: package build failed > > I tried running juno and mentor again. I get different results each run. Interestingly, sometimes mentor didn't crash, instead giving me an error message about not having my HOME environment var set. I tried later to set this, but mentor still crashes. Once when I ran juno it complained that it tried to join a thread twice. Sounds like something is broken in the threading or GC, or the program is coded wrongly somehow. See below for some sample runs of mentor and juno: > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** Exception "FormsVBT.Error" not in RAISES list > *** file "..\src\FormsVBT.m3", line 73 > *** > > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "..\src\runtime\common\RTType.m3", line 71 > *** > > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** failed. > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 > 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 > 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 > 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 > 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 > 0x12fe88 0x4e32da RegisterView + 0x30 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 > 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 > > Here is another run of Juno. This one dies on a different line number in same module. > > > C:\cm3\Sandbox\cm3\scripts\win>juno > > *** > *** runtime error: > *** failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1087 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common\RTCollector.m3 > 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime\common\RTCollector.m3 > 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src\JunoCompile.m3 > 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src\JunoCompile.m3 > 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src\JunoCompile.m3 > 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src\JunoCompile.m3 > 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src\JunoCompile.m3 > 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src\JunoCompile.m3 > 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src\JunoCompile.m3 > 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > Regards, > Randy Coleburn > >>>> Jay K> 9/1/2009 9:33 PM>>> > Is the message about errno.h correct? > caltech-parser..hm.. you are up to date? I thought I had either fixed it, or filtered it out. > Mutex/mentor I'll have to look at. > > - Jay > > ________________________________ > Date: Tue, 1 Sep 2009 20:09:25 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] report on Windows XP builds/tests > > Hi, I am back from vacation. > > I've updated my sandbox on WindowsXP to be current with the CVS head. > > I tried first to run Jay's "upgrade.py", but got the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > using c:\cm3\bin\cm3.exe > PATH=c:\cm3\bin;%PATH% > set CM3_TARGET=NT386 > set CM3_INSTALL=c:\cm3 > set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 > set CM3_ROOT=C:/cm3/Sandbox/cm3 > ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) > C:\cm3\Sandbox\cm3\scripts\python> > > Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". > > In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: > > C:\cm3\bin>mentor > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 > 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 > 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 > 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 > 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 > 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > > C:\cm3\bin>juno > > *** > *** runtime error: > *** failed. > *** file "..\src\runtime\common\RTCollector.m3", line 2284 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 > 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 > 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 > 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 > 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 > 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 > 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 > 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 > 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 > 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > C:\cm3\bin> > > Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. > > I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. > > I will try to run some tests on Vista platform tomorrow. > > Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. > > Let me know how I can best assist with the release effort. > > Regards, > Randy Coleburn > From hosking at cs.purdue.edu Wed Sep 2 06:52:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Sep 2009 00:52:15 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: On 2 Sep 2009, at 00:20, Jay K wrote: > My fear is that I messed up when I factored sizeof(pthread_cond_t), > sizeof(pthread_mutex_t), etc. out of the Modula-3 code. > The code looks right, but it is easy to miss a level of indirection, > or something. > We also might as well wrap the last few that aren't wrapped, but no > reason to believe that will fix anything. We'll need to look into this. The weird thing is that it *mostly* works. I'd have thought getting those wrong would break everywhere. Still, probably worth rechecking. > My dashed hope is/was that the compiler being written in Modula-3, > including using multiple threads, for garbage collection, would be a > good test of the overall system working. I don't think the compiler is a multi-threaded mutator. The GC piggybacks work on the mutator by default, rather than running in separate threads. > The caltech-parser problem looks familiar. I'll have to look again. > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: rcoleburn at scires.com >> Date: Tue, 1 Sep 2009 23:52:39 -0400 >> CC: m3devel at elegosoft.com; jay.krell at cornell.edu >> Subject: Re: [M3devel] report on Windows XP builds/tests >> >> mentor (and probably other GUI apps) lock up in ways I have not >> seen before (it has been a long time since I tried running it, but >> it always used to work for me without problems about the time that >> I was bedding down the native threads code so logs there might give >> the timeframe). I suspect something is quite broken, but don't know >> when the brokenness got introduced. Here is a backtrace for all >> threads: >> >> Thread 20 (process 84568 thread 0x4f07): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, >> rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:669 >> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:686 >> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../ >> src/xvbt/XClientF.m3:105 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 19 (process 84568 thread 0x4e0b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, >> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >> M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >> M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../ >> src/Zeus.m3:328 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 18 (process 84568 thread 0x5c0b): >> #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) >> at ../src/thread/PTHREAD/ThreadPThread.m3:189 >> #1 0x0101ee7a in ThreadPThread__XTestAlert >> (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:324 >> #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, >> M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') >> at ../src/thread/PTHREAD/ThreadPThread.m3:670 >> #3 0x0101f77a in Thread__AlertPause >> (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:700 >> #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, >> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) >> at ../src/Animate.m3:71 >> #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, >> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >> #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, >> M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 >> #7 0x00020798 in ViewIncrementalReal__ShowPixel >> (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ >> ViewIncrementalReal.m3:567 >> #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, >> M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 >> #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../ >> src/Zeus.m3:331 >> #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #11 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #12 0x96373155 in _pthread_start () >> #13 0x96373012 in thread_start () >> >> Thread 17 (process 84568 thread 0x6f0f): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, >> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >> M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >> M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../ >> src/Zeus.m3:328 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 16 (process 84568 thread 0x425b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, >> M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, >> M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) >> at ../src/ZeusPanel.m3:1425 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 15 (process 84568 thread 0x310b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) >> at ../src/View.m3:74 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 14 (process 84568 thread 0x3003): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) >> at ../src/View.m3:74 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 13 (process 84568 thread 0x2f03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) >> at ../src/View.m3:74 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 12 (process 84568 thread 0x2e03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, >> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >> M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) >> at ../src/xvbt/XMessenger.m3:69 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 11 (process 84568 thread 0x2d03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, >> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >> M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) >> at ../src/xvbt/XInput.m3:102 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 10 (process 84568 thread 0x2a2b): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, >> writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/ >> unix/Common/UnixC.c:301 >> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:788 >> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:827 >> #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, >> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:730 >> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) >> at ../src/xvbt/XInput.m3:63 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 9 (process 84568 thread 0x29f3): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, >> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, >> M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, >> M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 >> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, >> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 >> #7 0x000149a7 in BresenhamIE__ShowPixel >> (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/ >> BresenhamIE.m3:227 >> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, >> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >> at ../src/bresenham/AlgBresenham.m3:55 >> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../ >> src/bresenham/AlgBresenham.m3:86 >> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) >> at ../src/ZeusPanel.m3:1534 >> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #12 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 8 (process 84568 thread 0x2803): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, >> M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, >> M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >> Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, >> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) >> at ../src/formatter/Formatter.m3:615 >> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #12 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 7 (process 84568 thread 0x2703): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, >> M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, >> M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >> Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, >> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) >> at ../src/formatter/Formatter.m3:615 >> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #12 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 6 (process 84568 thread 0x2603): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, >> M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, >> M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) >> at ../src/WorkerPool.m3:152 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 5 (process 84568 thread 0x2313): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, >> writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../ >> src/unix/Common/UnixC.c:301 >> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:788 >> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:827 >> #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, >> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:743 >> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, >> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/ >> POSIX/TCP.m3:234 >> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >> (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 >> #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #9 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #10 0x96373155 in _pthread_start () >> #11 0x96373012 in thread_start () >> >> Thread 4 (process 84568 thread 0x2003): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, >> rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:669 >> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:686 >> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) >> at ../src/lego/FileBrowserVBT.m3:259 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 3 (process 84568 thread 0x1f03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, >> M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, >> M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00a839e2 in VTView__VFontCleanUpThread >> (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 2 (process 84568 thread 0x313): >> #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, >> M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../ >> src/thread/PTHREAD/ThreadPThread.m3:669 >> #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) >> at ../src/thread/PTHREAD/ThreadPThread.m3:686 >> #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../ >> src/vbt/VBTRep.m3:460 >> #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #4 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #5 0x96373155 in _pthread_start () >> #6 0x96373012 in thread_start () >> >> Thread 1 (process 84568 local thread 0x2e03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >> M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 >> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >> #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ >> src/runtime/common/RTLinker.m3:400 >> #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at >> _m3main.mc:6 >> >> >> On 1 Sep 2009, at 22:53, Randy Coleburn wrote: >> >> I tried upgrade.py again, and it seemed to work this time. I think >> I may have forgotten to run vcvars to setup the Visual C++ command >> line on my prior attempt. Sorry. >> >> Here is the compiler output for the "caltech-parser\parserlib >> \parserlib\test" build: >> >> --- processing package "caltech-parser\parserlib\parserlib\test" --- >> --- building in NT386 --- >> >> LIB_INSTALL is C:\cm3\lib >> ignoring ..\src\m3overrides >> >> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >> CalcTok.i3 >> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >> CalcTok.i3 >> The system cannot find the path specified. >> "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime >> error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok .. >> \src\Calc.t -o CalcTok.i3 >> >> --procedure-- -line- -file--- >> exec -- >> _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl >> _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl >> _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl >> _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl >> token 73 C:\cm3\pkg\parserlib\src\parser.tmpl >> include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib >> \test\src\m3makefile >> 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test >> \NT386\m3make.args >> >> Fatal Error: package build failed >> >> I tried running juno and mentor again. I get different results each >> run. Interestingly, sometimes mentor didn't crash, instead giving >> me an error message about not having my HOME environment var set. I >> tried later to set this, but mentor still crashes. Once when I ran >> juno it complained that it tried to join a thread twice. Sounds >> like something is broken in the threading or GC, or the program is >> coded wrongly somehow. See below for some sample runs of mentor and >> juno: >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> >> *** >> *** runtime error: >> *** Exception "FormsVBT.Error" not in RAISES list >> *** file "..\src\FormsVBT.m3", line 73 >> *** >> >> >> >> *** >> *** runtime error: >> *** An enumeration or subrange value was out of range. >> *** file "..\src\runtime\common\RTType.m3", line 71 >> *** >> >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> Error: the HOME environment variable is undefined. >> Please set it to the path of your home directory and try again. >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> Error: the HOME environment variable is undefined. >> Please set it to the path of your home directory and try again. >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread >> \WIN32\ThreadWin32.m3 >> 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 >> 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 >> 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 >> 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 >> 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 >> 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 >> 0x12fe88 0x4e32da RegisterView + 0x30 in .. >> \NT386\MinimaxViewGameTreeBObliqView.m3 >> 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in .. >> \NT386\MinimaxViewGameTreeBObliqView.m3 >> >> Here is another run of Juno. This one dies on a different line >> number in same module. >> >> >> C:\cm3\Sandbox\cm3\scripts\win>juno >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 1087 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common >> \RTCollector.m3 >> 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime >> \common\RTCollector.m3 >> 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src >> \JunoCompile.m3 >> 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src >> \JunoCompile.m3 >> 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src >> \JunoCompile.m3 >> 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src >> \JunoCompile.m3 >> 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src >> \JunoCompile.m3 >> 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src >> \JunoCompile.m3 >> 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src >> \JunoCompile.m3 >> 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src >> \JunoCompile.m3 >> ......... ......... ... more frames ... >> >> Regards, >> Randy Coleburn >> >>>>> Jay K> 9/1/2009 9:33 PM>>> >> Is the message about errno.h correct? >> caltech-parser..hm.. you are up to date? I thought I had either >> fixed it, or filtered it out. >> Mutex/mentor I'll have to look at. >> >> - Jay >> >> ________________________________ >> Date: Tue, 1 Sep 2009 20:09:25 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] report on Windows XP builds/tests >> >> Hi, I am back from vacation. >> >> I've updated my sandbox on WindowsXP to be current with the CVS head. >> >> I tried first to run Jay's "upgrade.py", but got the following error: >> >> C:\cm3\Sandbox\cm3\scripts\python>upgrade.py >> using c:\cm3\bin\cm3.exe >> PATH=c:\cm3\bin;%PATH% >> set CM3_TARGET=NT386 >> set CM3_INSTALL=c:\cm3 >> set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- >> install\NT386 >> set CM3_ROOT=C:/cm3/Sandbox/cm3 >> ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: >> \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files >> \Microsoft Platform SDK for Windows Server 2003 R2\Include) >> C:\cm3\Sandbox\cm3\scripts\python> >> >> Next I tried my upgrade script and was successful. Then I used my >> "do-cm3.cmd" script to rebuild all packages and was successful, >> except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib >> \test". >> >> In catching up on my email, I noticed Olaf had asked about mentor >> and juno on Windows, so I tried running these. Juno starts up and >> puts up a window, but quickly crashes. mentor crashes before any >> window comes up and I also get a firewall request from Windows >> asking whether to block the program--I suspect it is trying to >> access the network, hence the firewall request. Here are the >> runtime error reports: >> >> C:\cm3\bin>mentor >> >> *** >> *** runtime error: >> *** Attempt to reference an illegal memory location. >> *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread >> \WIN32\ThreadWin32.m3 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime >> \NT386\RTSignal.m3 >> 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread >> \WIN32\ThreadWin32.m3 >> 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 >> 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 >> 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >> 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >> 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 >> 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >> 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >> 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 >> ......... ......... ... more frames ... >> >> >> C:\cm3\bin>juno >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 2284 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common >> \RTCollector.m3 >> 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 >> 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 >> 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 >> 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 >> 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 >> 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 >> 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 >> 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 >> 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 >> ......... ......... ... more frames ... >> >> C:\cm3\bin> >> >> Juno crashes on an ASSERT in the collector, while mentor seems to >> be trying to lock a mutex that isn't properly initialized. I have >> not looked at the source code to try and debug. Let me know if you >> want me to pursue further. >> >> I've rebuilt some of my own programs and run some very basic tests. >> So far, no problems detected. >> >> I will try to run some tests on Vista platform tomorrow. >> >> Maybe it would be prudent for me to compile and run some of the >> tests ya'll have been implementing. I think the scripts for these >> aren't native Windows, but if you can point me to some of these, >> I'll try to translate for use on Windows. >> >> Let me know how I can best assist with the release effort. >> >> Regards, >> Randy Coleburn >> From jay.krell at cornell.edu Wed Sep 2 07:15:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 05:15:46 +0000 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: Yep, no matter what the problem is, that's my other dashed hope -- that'd it'd either work very little or very much, and not somewhere in between as it does. It seems a little surprising to see things only 4-aligned below, but I'd have to check the related sizes, if they are 4 then ok. I also checked the parameter order for calloc. calloc(n,1) could reasonably provide something unaligned, but calloc(1,n) that I use should be n or "max" aligned, whichever is smaller. I can't claim that I thought of this at the time, maybe I just got lucky. I'll /try/ to look at this shortly. Nice that it occurs on NT too. :) It could be something else entirely, but this an obvious area to double double double check, and if not too difficult, test with it reverted and sort of prove by showing the opposite behavior with the opposite state (which isn't conclusive, but you understand..) Hm noticably on NT I didn't make this change for dynamically allocated structures, only static ones. That part is also a little bit to be focused on, but /seemingly/ easier to get correct. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 2 Sep 2009 00:52:15 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] report on Windows XP builds/tests > > On 2 Sep 2009, at 00:20, Jay K wrote: > >> My fear is that I messed up when I factored sizeof(pthread_cond_t), >> sizeof(pthread_mutex_t), etc. out of the Modula-3 code. >> The code looks right, but it is easy to miss a level of indirection, >> or something. >> We also might as well wrap the last few that aren't wrapped, but no >> reason to believe that will fix anything. > > We'll need to look into this. The weird thing is that it *mostly* > works. I'd have thought getting those wrong would break everywhere. > Still, probably worth rechecking. > >> My dashed hope is/was that the compiler being written in Modula-3, >> including using multiple threads, for garbage collection, would be a >> good test of the overall system working. > > I don't think the compiler is a multi-threaded mutator. > > The GC piggybacks work on the mutator by default, rather than running > in separate threads. > >> The caltech-parser problem looks familiar. I'll have to look again. >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: rcoleburn at scires.com >>> Date: Tue, 1 Sep 2009 23:52:39 -0400 >>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu >>> Subject: Re: [M3devel] report on Windows XP builds/tests >>> >>> mentor (and probably other GUI apps) lock up in ways I have not >>> seen before (it has been a long time since I tried running it, but >>> it always used to work for me without problems about the time that >>> I was bedding down the native threads code so logs there might give >>> the timeframe). I suspect something is quite broken, but don't know >>> when the brokenness got introduced. Here is a backtrace for all >>> threads: >>> >>> Thread 20 (process 84568 thread 0x4f07): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, >>> rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:669 >>> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:686 >>> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../ >>> src/xvbt/XClientF.m3:105 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 19 (process 84568 thread 0x4e0b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, >>> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >>> M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >>> M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../ >>> src/Zeus.m3:328 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 18 (process 84568 thread 0x5c0b): >>> #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:189 >>> #1 0x0101ee7a in ThreadPThread__XTestAlert >>> (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:324 >>> #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, >>> M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') >>> at ../src/thread/PTHREAD/ThreadPThread.m3:670 >>> #3 0x0101f77a in Thread__AlertPause >>> (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:700 >>> #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, >>> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) >>> at ../src/Animate.m3:71 >>> #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, >>> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >>> #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, >>> M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 >>> #7 0x00020798 in ViewIncrementalReal__ShowPixel >>> (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >>> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ >>> ViewIncrementalReal.m3:567 >>> #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, >>> M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 >>> #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../ >>> src/Zeus.m3:331 >>> #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #11 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #12 0x96373155 in _pthread_start () >>> #13 0x96373012 in thread_start () >>> >>> Thread 17 (process 84568 thread 0x6f0f): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, >>> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >>> M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >>> M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../ >>> src/Zeus.m3:328 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 16 (process 84568 thread 0x425b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, >>> M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, >>> M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) >>> at ../src/ZeusPanel.m3:1425 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 15 (process 84568 thread 0x310b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) >>> at ../src/View.m3:74 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 14 (process 84568 thread 0x3003): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) >>> at ../src/View.m3:74 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 13 (process 84568 thread 0x2f03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) >>> at ../src/View.m3:74 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 12 (process 84568 thread 0x2e03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, >>> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >>> M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) >>> at ../src/xvbt/XMessenger.m3:69 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 11 (process 84568 thread 0x2d03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, >>> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >>> M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) >>> at ../src/xvbt/XInput.m3:102 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 10 (process 84568 thread 0x2a2b): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, >>> writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/ >>> unix/Common/UnixC.c:301 >>> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:788 >>> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, >>> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:827 >>> #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:730 >>> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) >>> at ../src/xvbt/XInput.m3:63 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 9 (process 84568 thread 0x29f3): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, >>> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, >>> M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, >>> M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 >>> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, >>> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >>> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 >>> #7 0x000149a7 in BresenhamIE__ShowPixel >>> (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >>> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/ >>> BresenhamIE.m3:227 >>> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, >>> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >>> at ../src/bresenham/AlgBresenham.m3:55 >>> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../ >>> src/bresenham/AlgBresenham.m3:86 >>> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) >>> at ../src/ZeusPanel.m3:1534 >>> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #12 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 8 (process 84568 thread 0x2803): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, >>> M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, >>> M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >>> Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, >>> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #12 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 7 (process 84568 thread 0x2703): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, >>> M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, >>> M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >>> Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, >>> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #12 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 6 (process 84568 thread 0x2603): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, >>> M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, >>> M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) >>> at ../src/WorkerPool.m3:152 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 5 (process 84568 thread 0x2313): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, >>> writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../ >>> src/unix/Common/UnixC.c:301 >>> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:788 >>> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, >>> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:827 >>> #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:743 >>> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, >>> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >>> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/ >>> POSIX/TCP.m3:234 >>> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >>> (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 >>> #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #9 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #10 0x96373155 in _pthread_start () >>> #11 0x96373012 in thread_start () >>> >>> Thread 4 (process 84568 thread 0x2003): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, >>> rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:669 >>> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:686 >>> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) >>> at ../src/lego/FileBrowserVBT.m3:259 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 3 (process 84568 thread 0x1f03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, >>> M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, >>> M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00a839e2 in VTView__VFontCleanUpThread >>> (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 2 (process 84568 thread 0x313): >>> #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, >>> M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../ >>> src/thread/PTHREAD/ThreadPThread.m3:669 >>> #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:686 >>> #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../ >>> src/vbt/VBTRep.m3:460 >>> #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #4 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #5 0x96373155 in _pthread_start () >>> #6 0x96373012 in thread_start () >>> >>> Thread 1 (process 84568 local thread 0x2e03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >>> M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 >>> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >>> #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ >>> src/runtime/common/RTLinker.m3:400 >>> #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at >>> _m3main.mc:6 >>> >>> >>> On 1 Sep 2009, at 22:53, Randy Coleburn wrote: >>> >>> I tried upgrade.py again, and it seemed to work this time. I think >>> I may have forgotten to run vcvars to setup the Visual C++ command >>> line on my prior attempt. Sorry. >>> >>> Here is the compiler output for the "caltech-parser\parserlib >>> \parserlib\test" build: >>> >>> --- processing package "caltech-parser\parserlib\parserlib\test" --- >>> --- building in NT386 --- >>> >>> LIB_INSTALL is C:\cm3\lib >>> ignoring ..\src\m3overrides >>> >>> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >>> CalcTok.i3 >>> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >>> CalcTok.i3 >>> The system cannot find the path specified. >>> "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime >>> error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok .. >>> \src\Calc.t -o CalcTok.i3 >>> >>> --procedure-- -line- -file--- >>> exec -- >>> _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl >>> _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl >>> _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl >>> _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl >>> token 73 C:\cm3\pkg\parserlib\src\parser.tmpl >>> include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib >>> \test\src\m3makefile >>> 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test >>> \NT386\m3make.args >>> >>> Fatal Error: package build failed >>> >>> I tried running juno and mentor again. I get different results each >>> run. Interestingly, sometimes mentor didn't crash, instead giving >>> me an error message about not having my HOME environment var set. I >>> tried later to set this, but mentor still crashes. Once when I ran >>> juno it complained that it tried to join a thread twice. Sounds >>> like something is broken in the threading or GC, or the program is >>> coded wrongly somehow. See below for some sample runs of mentor and >>> juno: >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> >>> *** >>> *** runtime error: >>> *** Exception "FormsVBT.Error" not in RAISES list >>> *** file "..\src\FormsVBT.m3", line 73 >>> *** >>> >>> >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "..\src\runtime\common\RTType.m3", line 71 >>> *** >>> >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> Error: the HOME environment variable is undefined. >>> Please set it to the path of your home directory and try again. >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> Error: the HOME environment variable is undefined. >>> Please set it to the path of your home directory and try again. >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 >>> 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 >>> 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 >>> 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 >>> 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 >>> 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 >>> 0x12fe88 0x4e32da RegisterView + 0x30 in .. >>> \NT386\MinimaxViewGameTreeBObliqView.m3 >>> 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in .. >>> \NT386\MinimaxViewGameTreeBObliqView.m3 >>> >>> Here is another run of Juno. This one dies on a different line >>> number in same module. >>> >>> >>> C:\cm3\Sandbox\cm3\scripts\win>juno >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\runtime\common\RTCollector.m3", line 1087 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common >>> \RTCollector.m3 >>> 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime >>> \common\RTCollector.m3 >>> 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src >>> \JunoCompile.m3 >>> 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src >>> \JunoCompile.m3 >>> 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src >>> \JunoCompile.m3 >>> 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src >>> \JunoCompile.m3 >>> 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src >>> \JunoCompile.m3 >>> 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src >>> \JunoCompile.m3 >>> 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src >>> \JunoCompile.m3 >>> 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src >>> \JunoCompile.m3 >>> ......... ......... ... more frames ... >>> >>> Regards, >>> Randy Coleburn >>> >>>>>> Jay K> 9/1/2009 9:33 PM>>> >>> Is the message about errno.h correct? >>> caltech-parser..hm.. you are up to date? I thought I had either >>> fixed it, or filtered it out. >>> Mutex/mentor I'll have to look at. >>> >>> - Jay >>> >>> ________________________________ >>> Date: Tue, 1 Sep 2009 20:09:25 -0400 >>> From: rcoleburn at scires.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] report on Windows XP builds/tests >>> >>> Hi, I am back from vacation. >>> >>> I've updated my sandbox on WindowsXP to be current with the CVS head. >>> >>> I tried first to run Jay's "upgrade.py", but got the following error: >>> >>> C:\cm3\Sandbox\cm3\scripts\python>upgrade.py >>> using c:\cm3\bin\cm3.exe >>> PATH=c:\cm3\bin;%PATH% >>> set CM3_TARGET=NT386 >>> set CM3_INSTALL=c:\cm3 >>> set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- >>> install\NT386 >>> set CM3_ROOT=C:/cm3/Sandbox/cm3 >>> ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: >>> \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files >>> \Microsoft Platform SDK for Windows Server 2003 R2\Include) >>> C:\cm3\Sandbox\cm3\scripts\python> >>> >>> Next I tried my upgrade script and was successful. Then I used my >>> "do-cm3.cmd" script to rebuild all packages and was successful, >>> except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib >>> \test". >>> >>> In catching up on my email, I noticed Olaf had asked about mentor >>> and juno on Windows, so I tried running these. Juno starts up and >>> puts up a window, but quickly crashes. mentor crashes before any >>> window comes up and I also get a firewall request from Windows >>> asking whether to block the program--I suspect it is trying to >>> access the network, hence the firewall request. Here are the >>> runtime error reports: >>> >>> C:\cm3\bin>mentor >>> >>> *** >>> *** runtime error: >>> *** Attempt to reference an illegal memory location. >>> *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime >>> \NT386\RTSignal.m3 >>> 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 >>> 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 >>> 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 >>> 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 >>> ......... ......... ... more frames ... >>> >>> >>> C:\cm3\bin>juno >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\runtime\common\RTCollector.m3", line 2284 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common >>> \RTCollector.m3 >>> 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 >>> 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 >>> 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 >>> 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 >>> 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 >>> 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 >>> 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 >>> 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 >>> 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 >>> ......... ......... ... more frames ... >>> >>> C:\cm3\bin> >>> >>> Juno crashes on an ASSERT in the collector, while mentor seems to >>> be trying to lock a mutex that isn't properly initialized. I have >>> not looked at the source code to try and debug. Let me know if you >>> want me to pursue further. >>> >>> I've rebuilt some of my own programs and run some very basic tests. >>> So far, no problems detected. >>> >>> I will try to run some tests on Vista platform tomorrow. >>> >>> Maybe it would be prudent for me to compile and run some of the >>> tests ya'll have been implementing. I think the scripts for these >>> aren't native Windows, but if you can point me to some of these, >>> I'll try to translate for use on Windows. >>> >>> Let me know how I can best assist with the release effort. >>> >>> Regards, >>> Randy Coleburn >>> > From wagner at elegosoft.com Wed Sep 2 08:39:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 08:39:23 +0200 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> References: <4A9DD0B2.4010505@esoteriq.org> <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> Message-ID: <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> Quoting Tony Hosking : > Because mentor depends on obliq? If you didn't install the obliq > package then it can't dynamically load the shard library. This is strange. mentor should be built standalone. Is build_standalone() broken on LINUXLIBC6? And I don't see a direct obliq dependency. Ah, that's in src/minimax/m3makefile; I've probably missed it when extracting the dependencies. > On 1 Sep 2009, at 21:56, Martin Bishop wrote: > >> I installed the RC3 core fine, worked well, but I was adding >> addition packages and tried running mentor. I get: >> >> mentor: error while loading shared library libobliqlibanim.so.5: >> cannot open shared object file: No such file or directory. >> >> I'm guessing this is because I didn't install the Obliq >> package...but why should I have to? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 2 08:45:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 06:45:36 +0000 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> References: <4A9DD0B2.4010505@esoteriq.org> <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> Message-ID: Why should mentor be standalone? - Jay ---------------------------------------- > Date: Wed, 2 Sep 2009 08:39:23 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Mentor error on LINUXLIBC6 > > Quoting Tony Hosking : > >> Because mentor depends on obliq? If you didn't install the obliq >> package then it can't dynamically load the shard library. > > This is strange. mentor should be built standalone. > Is build_standalone() broken on LINUXLIBC6? > > And I don't see a direct obliq dependency. Ah, that's in > src/minimax/m3makefile; I've probably missed it when extracting the > dependencies. > >> On 1 Sep 2009, at 21:56, Martin Bishop wrote: >> >>> I installed the RC3 core fine, worked well, but I was adding >>> addition packages and tried running mentor. I get: >>> >>> mentor: error while loading shared library libobliqlibanim.so.5: >>> cannot open shared object file: No such file or directory. >>> >>> I'm guessing this is because I didn't install the Obliq >>> package...but why should I have to? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Sep 2 08:49:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 08:49:47 +0200 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> Quoting Tony Hosking : > On 2 Sep 2009, at 00:20, Jay K wrote: > >> My fear is that I messed up when I factored sizeof(pthread_cond_t), >> sizeof(pthread_mutex_t), etc. out of the Modula-3 code. >> The code looks right, but it is easy to miss a level of >> indirection, or something. >> We also might as well wrap the last few that aren't wrapped, but no >> reason to believe that will fix anything. > > We'll need to look into this. The weird thing is that it *mostly* > works. I'd have thought getting those wrong would break everywhere. > Still, probably worth rechecking. If something this fundamental is broken in the runtime, we can probably forget all the RC3 packages built so far and just hope for RC4? Why has nobody noticed this before? We really need some more tests that are able to detect such breakage. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Sep 2 08:56:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 08:56:25 +0200 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: References: <4A9DD0B2.4010505@esoteriq.org> <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> Message-ID: <20090902085625.crri91x21ws800os@mail.elegosoft.com> Quoting Jay K : > Why should mentor be standalone? You are correct. build_standalone() is a local modification in one of my workspaces for debugging. Sorry for the confusion. Still the dependency seems to be missing in the documentation (anim --> obliq). Probably the sub-makefiles weren't processed :-( Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 2 09:11:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 07:11:28 +0000 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> Message-ID: we can't answer the question until we determine the problem! :) - Jay ---------------------------------------- > Date: Wed, 2 Sep 2009 08:49:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests > > Quoting Tony Hosking : > >> On 2 Sep 2009, at 00:20, Jay K wrote: >> >>> My fear is that I messed up when I factored sizeof(pthread_cond_t), >>> sizeof(pthread_mutex_t), etc. out of the Modula-3 code. >>> The code looks right, but it is easy to miss a level of >>> indirection, or something. >>> We also might as well wrap the last few that aren't wrapped, but no >>> reason to believe that will fix anything. >> >> We'll need to look into this. The weird thing is that it *mostly* >> works. I'd have thought getting those wrong would break everywhere. >> Still, probably worth rechecking. > > If something this fundamental is broken in the runtime, we can > probably forget all the RC3 packages built so far and just hope > for RC4? > > Why has nobody noticed this before? We really need some more tests > that are able to detect such breakage. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Sep 2 10:41:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 08:41:59 +0000 Subject: [M3devel] duplicate FileBrowserVBT.m3 Message-ID: C:\dev2\cm3.2\m3-lectern\lectern\src\FileBrowserVBT.m3 C:\dev2\cm3.2\m3-ui\vbtkit\src\lego\FileBrowserVBT.m3 These are nearly identical. I don't entirely believe the comment about directories on Windows. - directories to have timestamps - it is up to the file system, not the operating system, You can see ext3 file systems over the network from Windows via SMB, etc. (and you can see FAT and NTFS on Linux, Solaris, Mac, etc. via SMB, NFS, etc.) They should be merged. Probably m3-ui/vbtkit is where the merge should go. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 2 11:26:02 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 11:26:02 +0200 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> Message-ID: <20090902112602.eecq6rptkwk4k480@mail.elegosoft.com> Quoting Jay K : > we can't answer the question until we determine the problem! :) Of course. I have opened ticket #1070 in trac for this issue. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 2 11:30:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 09:30:08 +0000 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: <20090902112602.eecq6rptkwk4k480@mail.elegosoft.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> <20090902112602.eecq6rptkwk4k480@mail.elegosoft.com> Message-ID: er, now that I experience it, of course, it is worse. I see the intermittent hangs of Juno on I386_DARWIN. I see Juno and/or mentor always/usually crashing on NT. The Juno crash is particularly nice because it is always accessing the same invalid address, or a fixed offset from it (the invalid address is in a register and the instruction contains an offset). @M3nogc seems to perturb it. NT has fewer changes here. I'm going to try 5.7.0 and 5.7.1 snapshots. Getting daily or weekly snapshots automatically from Hudson would be nice. - Jay > Date: Wed, 2 Sep 2009 11:26:02 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests > > Quoting Jay K : > > > we can't answer the question until we determine the problem! :) > > Of course. > > I have opened ticket #1070 in trac for this issue. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Sep 3 00:46:42 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Sep 2009 18:46:42 -0400 Subject: [M3devel] cm3.cfg for Windows Message-ID: <4A9EBD88.1E75.00D7.1@scires.com> Jay: After running your "upgrade.py" I notice that the "cm3\bin\cm3.cfg" file has been replaced and now contains 134 lines instead of the 2 lines you had described earlier. Let me know if I should switch back to the 2-line variant you described earlier, or if the new 134-line file is the new way forward. Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 3 03:15:12 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 2 Sep 2009 18:15:12 -0700 Subject: [M3devel] cm3.cfg for Windows In-Reply-To: <4A9EBD88.1E75.00D7.1@scires.com> References: <4A9EBD88.1E75.00D7.1@scires.com> Message-ID: <3D5C4155-A36D-4E87-AAB5-6AAC2E18A7BE@hotmail.com> They are both valid. The larger one makes some guesses and delegates back to the cvs tree. It is nice for when you are actively editing the files and don't want to also copy them. It also will delegate to the installed ones and there its value is honoring the CM3_TARGET environment variable. Upgrade.py should probably have a command line option. Really upgrade is just a LITTLE more than do-pkg and might need some rethinking. It also copies cm3 for example which is really a workaround for cm3 not shipping itself. For you probably the two liner. - Jay (phone) On Sep 2, 2009, at 3:46 PM, "Randy Coleburn" wrote: > Jay: > > After running your "upgrade.py" I notice that the "cm3\bin\cm3.cfg" > file has been replaced and now contains 134 lines instead of the 2 > lines you had described earlier. > > Let me know if I should switch back to the 2-line variant you > described earlier, or if the new 134-line file is the new way forward. > > Regards, > Randy From michael.anderson at elego.de Wed Sep 2 13:07:43 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 02 Sep 2009 13:07:43 +0200 Subject: [M3devel] elego Server Maintenance 04.09.09 Message-ID: <20090902130743.pp6nlfuumo8k4008@mail.elego.de> Liebe Kollegen, Liebe Elego-Kunden, In der Nacht von Freitag, dem 04.09 auf Samstag, den 05.09 werden wir um 22.00 CET Uhr planmaessige Wartungsarbeiten an unseren Servern durchfuehren. Es kann zur kurzeitigen Unterbrechung mancher Dienste kommen. Voraussichtliche Dauer der Wartung: 120 Min. Wir bitten um Verst?ndnis. - die elego Admins On Friday, September 4 at 10 PM CET, we will perform scheduled maintenance on our servers. Brief interruptions of service may occur. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Sep 3 15:15:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Sep 2009 13:15:09 +0000 Subject: [M3devel] some data on Juno crash on Win32 Message-ID: summary: 5.7.0 and 5.7.1 of unknown date: both always fail 5.7.0 always fails an assert (various?) 5.7.1 sometimes fails an assert (various) 5.7.1 sometimes access violates, always on address 00200000, plus or minus 4. Current source always access violates, same address. Since 5.7.1 and current source always access violate (aka SIGSEGV) on the same location, every run, I'm more inclined to look at this. And then hope everything else is "the same" problem. But of course there might be multiple problems. It might be good to check for the hang in various from http://www.opencm3.net/uploaded-archives/index.html. Also see what all we can get from http://www.opencm3.net/snaps/snapshot-index.html. I'm going to see if I can get the index update with the many files I noticed in the file system. longer story: 5.7.0 visual glitch and usually: visual glitch might have been the problem with import the bit set data. *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x59cf830 0xf01c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x59cf8f8 0xf0fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x59cfd54 0xf0dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x59cfdbc 0xf085be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x59cfe04 0xf06ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x59cfe30 0x7e418734 0x59cfe98 0x7e418816 0x59cfef8 0x7e4189cd 0x59cff08 0x7e4196c7 0x59cff50 0xf0bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 5.7.1 no visual glitch and usually either same as above, or access violating accessing address 001ffffc or (6c4.13b8): Access violation - code c0000005 (first chance) m3core!RTCollector__Move+0x3d: 005beeb4 8b5e00 mov ebx,dword ptr [esi] ds:0023:001ffffc=???????? 0:007> r esi esi=001ffffc 0:007> k ChildEBP RetAddr WARNING: Stack unwind information not available. Following frames may be wrong. 0213e5c0 005badd1 m3core!RTCollector__Move+0x3d 0213e604 005ba6aa m3core!RTHeapMap__Walk+0x467 0213e628 005ba640 m3core!RTHeapMap__DoWalkRef+0x62 0213e654 005c0ab8 m3core!RTHeapMap__WalkRef+0x100 0213e67c 005c092c m3core!RTCollector__CleanBetween+0xdd 0213e6a8 005c0222 m3core!RTCollector__CleanPage+0x5b 0213e6fc 005bfc34 m3core!RTCollector__CollectSomeInStateZero+0x5b2 0213e710 005bf933 m3core!RTCollector__CollectSome+0x6e 0213e740 005c17cb m3core!RTCollector__CollectEnough+0x90 0213e7a0 005b7c23 m3core!RTHeapRep__AllocTraced+0xef 0213e7e4 005b74f8 m3core!RTAllocator__GetOpenArray+0x61 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3ui.dll - 0213e808 00f94c01 m3core!RTHooks__AllocateOpenArray+0x19 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3vbtkit.dll - 0213e85c 00ea330c m3ui!ScrnPixmap__NewRaw+0x16d 0213e898 00ea518b m3vbtkit!Image__InitGray+0x7f 0213e96c 00ea4b8a m3vbtkit!Image__pgm2+0x78 0213ea04 00ec2f4a m3vbtkit!Image__FromRd+0x179 0213ea48 00e93855 m3vbtkit!VBTKitResources__GetPixmap+0x9a 0213ea88 00e91058 m3vbtkit!ScrollerVBTClass__InitGraphics+0x18e *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3formsvbt.dll - 0213eac4 00e43fa2 m3vbtkit!ScrollerVBTClass__Init+0x58 0213ebf4 00e33106 m3formsvbt!FormsVBT__pTextEdit+0x9f5 don't believe that stack much, at least where the offsets are large. There are no symbols, just exports. *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 490 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x25efc5c 0x5d9eae CheckSlot + 0x28 in ..\src\thread\WIN32\ThreadWin32.m3 0x25efca0 0x5da9c8 Fork + 0x298 in ..\src\thread\WIN32\ThreadWin32.m3 0x25efcf0 0xf9240d Mark + 0x383 in ..\src\vbt\VBTRep.m3 0x25efd14 0xf88076 Mark + 0x4b in ..\src\vbt\VBT.m3 0x25efd34 0xfaccfd NewShape + 0xaa in ..\src\split\HVSplit.m3 0x25efd70 0xf87dca NewShape + 0x1d3 in ..\src\vbt\VBT.m3 0x25efd88 0xf8dc63 NewShapeDefault + 0x16 in ..\src\vbt\VBTClass.m3 0x25efdc4 0xf87dca NewShape + 0x1d3 in ..\src\vbt\VBT.m3 0x25efe20 0xfbee4d SetAndAlign + 0x1d1 in ..\src\split\TextVBT.m3 0x25efe38 0xfbf836 Redisplay + 0x15 in ..\src\split\TextVBT.m3 ......... ......... ... more frames ... more commonly accessing 00200000, er, well, notice the offset: (1350.f08): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000005 edx=0060b148 esi=011b8a3c edi=0120dfcc eip=005dabcf esp=0012f964 ebp=0012f98c iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3core.dll - m3core!Thread__Join+0x133: 005dabcf 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> k *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\juno-compiler.dll - ChildEBP RetAddr WARNING: Stack unwind information not available. Following frames may be wrong. 0012f98c 1000e2b1 m3core!Thread__Join+0x133 *** ERROR: Module load completed but symbols could not be loaded for Juno.exe 0012f9d0 0041c7e5 juno_compiler!JunoCompile__ProcDecl+0x1f5 0012fa08 0041d1cf Juno+0x1c7e5 0012fab4 0041d088 Juno+0x1d1cf 0012fae8 0043d425 Juno+0x1d088 0012fb28 0043d61e Juno+0x3d425 0012fbc8 0043df47 Juno+0x3d61e 0012fd70 0044b61e Juno+0x3df47 0012fee0 005c8d14 Juno+0x4b61e 0012ff24 005c82ec m3core!RTLinker__RunMainBody+0x25a 0012ff3c 005c8395 m3core!RTLinker__AddUnitI+0xf7 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 0012ff7c 004b0d74 Juno+0x1038 0012ffc0 7c817077 Juno+0xb0d74 0012fff0 00000000 kernel32!BaseProcessStart+0x23 *** *** runtime error: *** Thread client error: attempt to join with thread twice *** file "..\src\thread\WIN32\ThreadWin32.m3", line 708 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f954 0x5db678 Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 0x12f98c 0x5dab36 Join + 0x9a in ..\src\thread\WIN32\ThreadWin32.m3 0x12f9d0 0x1000e2b1 ProcDecl + 0x1f5 in ..\src\JunoCompile.m3 0x12fa08 0x41c7e5 Pass2 + 0x1a5 in ..\src\Editor.m3 0x12fab4 0x41d1cf Compile2 + 0x137 in ..\src\Editor.m3 0x12fae8 0x41d088 Compile + 0x53 in ..\src\Editor.m3 0x12fb28 0x43d425 CompileEditor + 0x2c in ..\src\Juno.m3 0x12fbc8 0x43d61e CompileModule + 0x12c in ..\src\Juno.m3 0x12fd70 0x43df47 CompileModules + 0x2d3 in ..\src\Juno.m3 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Sep 3 15:44:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 03 Sep 2009 15:44:36 +0200 Subject: [M3devel] some data on Juno crash on Win32 In-Reply-To: References: Message-ID: <20090903154436.w1aooqqaskg4scg4@mail.elegosoft.com> Quoting Jay K : > summary: 5.7.0 and 5.7.1 of unknown date: > > both always fail > > 5.7.0 always fails an assert (various?) > > 5.7.1 sometimes fails an assert (various) > > 5.7.1 sometimes access violates, always on address 00200000, plus or minus 4. > > Current source always access violates, same address. > > Since 5.7.1 and current source always access violate (aka SIGSEGV) > on the same > location, every run, I'm more inclined to look at this. This is all on Windows/NT386, isn't it? Or on POSIX platforms, too? I seem to remember that Juno always crashed on a PaintBrush operation on Windows, while the various mentor applications crashed at different points, but all relating to insufficient Trestle/Win support. On POSIX platforms both applications always ran OK AFAIR. Olaf > And then hope everything else is "the same" problem. > > But of course there might be multiple problems. > > It might be good to check for the hang in various from > http://www.opencm3.net/uploaded-archives/index.html. > > Also see what all we can get from > http://www.opencm3.net/snaps/snapshot-index.html. > > I'm going to see if I can get the index update with the many files I > noticed in the file system. The same file name pattern for all files would help here. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Sep 3 17:44:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Sep 2009 15:44:17 +0000 Subject: [M3devel] This is a pixmap? Message-ID: Does this look like a pixmap to anyone? This is the parameter to Win32 Join. PROCEDURE Join(t: T): REFANY = VAR res: REFANY; BEGIN LOCK threadMu DO IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; WHILE NOT t.completed DO Wait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; t.cond := NIL; IF perfOn THEN PerfChanged(t.id, State.dead) END; END; RETURN res; END Join; Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. t is at @ebp + here. The pointer then is 00200000 at the start of the second line of the second dump. If we can confirm this is pixmap, we can hunt more around in the gui code. 0:000> dd @ebp+8 0012f964 012ac6a8 02827bf4 02827974 02824c3c 0012f974 02829c40 02829c40 0012f98c 00000006 0012f984 011b9838 012ac6a8 0012f9fc 00000004 0012f994 10017170 000001c7 02829c40 0012f9d8 0012f9a4 0041ffea 02824c3c 02827bf4 02827974 0012f9b4 028250b8 02827974 02827904 02824dd8 0012f9c4 02824c3c 02827bf4 02824d9c 02824d9c 0012f9d4 02824dd8 0012fa8c 00420b98 028250b8 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> .lastevent Last event: ee0.13a4: Access violation - code c0000005 (first chance) debugger time: Thu Sep 3 07:43:12.390 2009 (GMT-7) 0:000> u . l1 m3core!Thread__Join+0x173: 005ebb01 8b5ffc mov ebx,dword ptr [edi-4] 0:000> r edi edi=00200000 0:000> Here is the entire bitmappy looking thing. 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> dd 012ac728 00200000 00200000 00200000 00200000 012ac738 00200000 00200000 00200000 00200000 012ac748 00200000 00200000 00200000 00200000 012ac758 00200000 00200000 00200000 00200000 012ac768 00200000 00200000 00200000 00200000 012ac778 00200000 00200000 00200000 00200000 012ac788 00200000 00200000 00200000 00200000 012ac798 00200000 00200000 00200000 00200000 0:000> 012ac7a8 00200000 00200000 00200000 00200000 012ac7b8 00200000 00200000 00200000 00200000 012ac7c8 00200000 00200000 00200000 00200000 012ac7d8 00200000 00200000 00200000 00200000 012ac7e8 00200000 00200000 00200000 00200000 012ac7f8 00200000 00200000 00200000 00200000 012ac808 00200000 00200000 00200000 00200000 012ac818 00200000 00200000 00200000 00200000 0:000> 012ac828 00200000 00200000 00200000 00200000 012ac838 00200000 00200000 00200000 00200000 012ac848 00200000 00200000 00200000 00200000 012ac858 00200000 00200000 00200000 00200000 012ac868 00200000 00200000 00200000 00200000 012ac878 00200000 00200000 00200000 00200000 012ac888 00200000 00200000 00200000 00200000 012ac898 00200000 00200000 00200000 00200000 0:000> 012ac8a8 00200000 00200000 00200000 00200000 012ac8b8 00200000 00200000 00200000 00200000 012ac8c8 00200000 00200000 00200000 00200000 012ac8d8 00200000 00200000 00200000 00200000 012ac8e8 00200000 00200000 00200000 00200000 012ac8f8 00200000 00200000 00200000 00200000 012ac908 00200000 00200000 00200000 00200000 012ac918 00200000 00200000 00200000 00200000 0:000> 012ac928 00200000 00200000 00200000 00200000 012ac938 00200000 00200000 00200000 00200000 012ac948 00200000 00200000 00200000 00200000 012ac958 00200000 00200000 00200000 00200000 012ac968 00200000 00200000 00200000 00200000 012ac978 00200000 00200000 00200000 00200000 012ac988 00200000 00200000 00200000 00200000 012ac998 00200000 00200000 00200000 00200000 0:000> 012ac9a8 00200000 00200000 00200000 00200000 012ac9b8 00200000 00200000 00200000 00200000 012ac9c8 00200000 00200000 00200000 00200000 012ac9d8 00200000 00200000 00200000 00200000 012ac9e8 00200000 00200000 00200000 00200000 012ac9f8 00200000 00200000 00200000 00200000 012aca08 00200000 00200000 00200000 00200000 012aca18 00200000 00200000 00200000 00200000 0:000> 012aca28 00200000 00200000 00200000 00200000 012aca38 00200000 00200000 00200000 00200000 012aca48 00200000 00200000 00200000 00200000 012aca58 00200000 00200000 00200000 00200000 012aca68 00200000 00200000 00200000 00200000 012aca78 00200000 00200000 00200000 00200000 012aca88 00200000 00200000 00200000 00200000 012aca98 00200000 00200000 00200000 00200000 0:000> 012acaa8 00200000 00200000 00200000 00200000 012acab8 00200000 00200000 00200000 00200000 012acac8 00200000 00200000 00200000 00200000 012acad8 00200000 00200000 00200000 00200000 012acae8 00200000 00200000 00200000 00200000 012acaf8 00200000 00200000 00200000 00200000 012acb08 00200000 00200000 00200000 00200000 012acb18 00200000 00200000 00200000 00200000 0:000> 012acb28 00200000 00200000 00200000 00200000 012acb38 00200000 00200000 00200000 00200000 012acb48 00200000 00200000 00200000 00200000 012acb58 00200000 00200000 00200000 00200000 012acb68 00200000 00200000 00200000 00200000 012acb78 00200000 00200000 00200000 00200000 012acb88 00200000 00200000 00200000 00200000 012acb98 00200000 00200000 00200000 00200000 0:000> 012acba8 00200000 00200000 00200000 00200000 012acbb8 00200000 00200000 00200000 00200000 012acbc8 00200000 00200000 00200000 00200000 012acbd8 00200000 00200000 00200000 00200000 012acbe8 00200000 00200000 00200000 00200000 012acbf8 00200000 00200000 00200000 00200000 012acc08 00200000 00200000 00200000 00200000 012acc18 00200000 00200000 00200000 00200000 0:000> 012acc28 00200000 00200000 00200000 00200000 012acc38 00200000 00200000 00200000 00200000 012acc48 00200000 00200000 00200000 00200000 012acc58 00200000 00200000 00200000 00200000 012acc68 00200000 00200000 00200000 00200000 012acc78 00200000 00200000 00200000 00200000 012acc88 00200000 00200000 00200000 00200000 012acc98 00200000 00200000 00200000 00200000 0:000> 012acca8 00200000 00200000 00200000 00200000 012accb8 00200000 00200000 00200000 00200000 012accc8 00200000 00200000 00200000 00200000 012accd8 00200000 00200000 00200000 00200000 012acce8 00200000 00200000 00200000 00200000 012accf8 00200000 00200000 00200000 00200000 012acd08 00200000 00200000 00200000 00200000 012acd18 00200000 00200000 00200000 00200000 0:000> 012acd28 00200000 00200000 00200000 00200000 012acd38 00200000 00200000 00200000 00200000 012acd48 00200000 00200000 00200000 00200000 012acd58 00200000 00200000 00200000 00200000 012acd68 00200000 00200000 00200000 00200000 012acd78 00200000 00200000 00200000 00200000 012acd88 00200000 00200000 00200000 00200000 012acd98 00200000 00200000 00200000 00200000 0:000> 012acda8 00200000 00200000 00200000 00200000 012acdb8 00200000 00200000 00200000 00200000 012acdc8 00200000 00200000 00200000 00200000 012acdd8 00200000 00200000 00200000 00200000 012acde8 00200000 00200000 00200000 00200000 012acdf8 00200000 00200000 00200000 00200000 012ace08 00200000 00200000 00200000 00200000 012ace18 00200000 00200000 00200000 00200000 0:000> 012ace28 00200000 00200000 00200000 00200000 012ace38 00200000 00200000 00200000 00200000 012ace48 00200000 00200000 00200000 00200000 012ace58 00200000 00200000 00200000 00200000 012ace68 00200000 00200000 00200000 00200000 012ace78 00200000 00200000 00200000 00200000 012ace88 00200000 00200000 00200000 00200000 012ace98 00200000 00200000 00200000 00200000 0:000> 012acea8 00200000 00200000 00200000 00200000 012aceb8 00200000 00200000 00200000 00200000 012acec8 00200000 00200000 00200000 00200000 012aced8 00200000 00200000 00200000 00200000 012acee8 00200000 00200000 00200000 00200000 012acef8 00200000 00200000 00200000 00200000 012acf08 00200000 00200000 00200000 00200000 012acf18 00200000 00200000 00200000 00200000 0:000> 012acf28 00200000 00200000 00200000 00200000 012acf38 00200000 00200000 00200000 00200000 012acf48 00200000 00200000 00200000 00200000 012acf58 00200000 00200000 00200000 00200000 012acf68 00200000 00200000 00200000 00200000 012acf78 00200000 00200000 00200000 00200000 012acf88 00200000 00200000 00200000 00200000 012acf98 00200000 00200000 00200000 00200000 0:000> 012acfa8 00200000 00200000 00200000 00200000 012acfb8 00200000 00200000 00200000 00200000 012acfc8 00200000 00200000 00200000 00200000 012acfd8 00200000 00200000 00200000 00200000 012acfe8 00200000 00200000 00200000 00200000 012acff8 00200000 00200000 00200000 00200000 012ad008 00200000 00200000 00200000 00200000 012ad018 00200000 00200000 00200000 00200000 0:000> 012ad028 00200000 00200000 00200000 00200000 012ad038 00200000 00200000 00200000 00200000 012ad048 00200000 00200000 00200000 00200000 012ad058 00200000 00200000 00200000 00200000 012ad068 00200000 00200000 00200000 00200000 012ad078 00200000 00200000 00200000 00200000 012ad088 00200000 00200000 00200000 00200000 012ad098 00200000 00200000 00200000 00200000 0:000> 012ad0a8 00200000 00200000 00200000 00200000 012ad0b8 00200000 00200000 00200000 00200000 012ad0c8 00200000 00200000 00200000 00200000 012ad0d8 00200000 00200000 00200000 00200000 012ad0e8 00200000 00200000 00200000 00200000 012ad0f8 00200000 00200000 00200000 00200000 012ad108 00200000 00200000 00200000 00200000 012ad118 00200000 00200000 00200000 00200000 0:000> 012ad128 00200000 00200000 00200000 00200000 012ad138 00200000 00200000 00200000 00200000 012ad148 00200000 00200000 00200000 00200000 012ad158 00200000 00200000 00200000 00200000 012ad168 00200000 00200000 00200000 00200000 012ad178 00200000 00200000 00200000 00200000 012ad188 00200000 00200000 00200000 00200000 012ad198 00200000 00200000 00200000 00200000 0:000> 012ad1a8 00200000 00200000 00200000 00200000 012ad1b8 00200000 00200000 00200000 00200000 012ad1c8 00200000 00200000 00200000 00200000 012ad1d8 00200000 00200000 00200000 00200000 012ad1e8 00200000 00200000 00200000 00200000 012ad1f8 00200000 00200000 00200000 00200000 012ad208 00200000 00200000 00200000 00200000 012ad218 00200000 00200000 00200000 00200000 0:000> 012ad228 00200000 00200000 00200000 00200000 012ad238 00200000 00200000 00200000 00200000 012ad248 00200000 00200000 00200000 00200000 012ad258 00200000 00200000 00200000 00200000 012ad268 00200000 00200000 00200000 00200000 012ad278 00200000 00200000 00200000 00200000 012ad288 00200000 00200000 00200000 00200000 012ad298 00200000 00200000 00200000 00200000 0:000> 012ad2a8 00200000 00200000 00200000 00200000 012ad2b8 00200000 00200000 00200000 00200000 012ad2c8 00200000 00200000 00200000 00200000 012ad2d8 00200000 00200000 00200000 00200000 012ad2e8 00200000 00200000 00200000 00200000 012ad2f8 00200000 00200000 00200000 00200000 012ad308 00200000 00200000 00200000 00200000 012ad318 00200000 00200000 00200000 00200000 0:000> 012ad328 00200000 00200000 00200000 00200000 012ad338 00200000 00200000 00200000 00200000 012ad348 00200000 00200000 00200000 00200000 012ad358 00200000 00200000 00200000 00200000 012ad368 00200000 00200000 00200000 00200000 012ad378 00200000 00200000 00200000 00200000 012ad388 00200000 00200000 00200000 00200000 012ad398 00200000 00200000 00200000 00200000 0:000> 012ad3a8 00200000 00200000 00200000 00200000 012ad3b8 00200000 00200000 00200000 00200000 012ad3c8 00200000 00200000 00200000 00200000 012ad3d8 00200000 00200000 00200000 00200000 012ad3e8 00200000 00200000 00200000 00200000 012ad3f8 00200000 00200000 00200000 00200000 012ad408 00200000 00200000 00200000 00200000 012ad418 00200000 00200000 00200000 00200000 0:000> 012ad428 00200000 00200000 00200000 00200000 012ad438 00200000 00200000 00200000 00200000 012ad448 00200000 00200000 00200000 00200000 012ad458 00200000 00200000 00200000 00200000 012ad468 00200000 00200000 00200000 00200000 012ad478 00200000 00200000 00200000 00200000 012ad488 00200000 00200000 00200000 00200000 012ad498 00200000 00200000 00200000 00200000 0:000> 012ad4a8 00200000 00200000 00200000 00200000 012ad4b8 00200000 00200000 00200000 00200000 012ad4c8 00200000 00200000 00200000 00200000 012ad4d8 00200000 00200000 00200000 00200000 012ad4e8 00200000 00200000 00200000 00200000 012ad4f8 00200000 00200000 00200000 00200000 012ad508 00200000 00200000 00200000 00200000 012ad518 00200000 00200000 00200000 00200000 0:000> 012ad528 00200000 00200000 00200000 00200000 012ad538 00200000 00200000 00200000 00200000 012ad548 00200000 00200000 00200000 00200000 012ad558 00200000 00200000 00200000 00200000 012ad568 00200000 00200000 00200000 00200000 012ad578 00200000 00200000 00200000 00200000 012ad588 00200000 00200000 00200000 00200000 012ad598 00200000 00200000 00200000 00200000 0:000> 012ad5a8 00200000 00200000 00200000 00200000 012ad5b8 00200000 00200000 00200000 00200000 012ad5c8 00200000 00200000 00200000 00200000 012ad5d8 00200000 00200000 00200000 00200000 012ad5e8 00200000 00200000 00200000 00200000 012ad5f8 00200000 00200000 00200000 00200000 012ad608 00200000 00200000 00200000 00200000 012ad618 00200000 00200000 00200000 00200000 0:000> 012ad628 00200000 00200000 00200000 00200000 012ad638 00200000 00200000 00200000 00200000 012ad648 00200000 00200000 00200000 00200000 012ad658 00200000 00200000 00200000 00200000 012ad668 00200000 00200000 00200000 00200000 012ad678 00200000 00200000 00200000 00200000 012ad688 00200000 00200000 00200000 00200000 012ad698 00200000 00200000 00200000 00200000 0:000> 012ad6a8 00200000 00200000 00200000 00200000 012ad6b8 00200000 00200000 00200000 00200000 012ad6c8 00200000 00200000 00200000 00200000 012ad6d8 00200000 00200000 00200000 00200000 012ad6e8 00200000 00200000 00200000 00200000 012ad6f8 00200000 00200000 00200000 00200000 012ad708 00200000 00200000 00200000 00200000 012ad718 00200000 00200000 00200000 00200000 0:000> 012ad728 00200000 00200000 00200000 00200000 012ad738 00200000 00200000 00200000 00200000 012ad748 00200000 00200000 00200000 00200000 012ad758 00200000 00200000 00200000 00200000 012ad768 00200000 00200000 00200000 00200000 012ad778 00200000 00200000 00200000 00200000 012ad788 00200000 00200000 00200000 00200000 012ad798 00200000 00200000 00200000 00200000 0:000> 012ad7a8 00200000 00200000 00200000 00200000 012ad7b8 00200000 00200000 00200000 00200000 012ad7c8 00200000 00200000 00200000 00200000 012ad7d8 00200000 00200000 00200000 00200000 012ad7e8 00200000 00200000 00200000 00200000 012ad7f8 00200000 00200000 00200000 00200000 012ad808 00200000 00200000 00200000 00200000 012ad818 00200000 00200000 00200000 00200000 0:000> 012ad828 00200000 00200000 00200000 00200000 012ad838 00200000 00200000 00200000 00200000 012ad848 00200000 00200000 00200000 00200000 012ad858 00200000 00200000 00200000 00200000 012ad868 00200000 00200000 00200000 00200000 012ad878 00200000 00200000 00200000 00200000 012ad888 00200000 00200000 00200000 00200000 012ad898 00200000 00200000 00200000 00200000 0:000> 012ad8a8 00200000 00200000 00200000 00200000 012ad8b8 00200000 00200000 00200000 00200000 012ad8c8 00200000 00200000 00200000 00200000 012ad8d8 00200000 00200000 00200000 00200000 012ad8e8 00200000 00200000 00200000 00200000 012ad8f8 00200000 00200000 00200000 00200000 012ad908 00200000 00200000 00200000 00200000 012ad918 00200000 00200000 00200000 00200000 0:000> 012ad928 00200000 00200000 00200000 00200000 012ad938 00200000 00200000 00200000 00200000 012ad948 00200000 00200000 00200000 00200000 012ad958 00200000 00200000 00200000 00200000 012ad968 00200000 00200000 00200000 00200000 012ad978 00200000 00200000 00200000 00200000 012ad988 00200000 00200000 00200000 00200000 012ad998 00200000 00200000 00200000 00200000 0:000> 012ad9a8 00200000 00200000 00200000 00200000 012ad9b8 00200000 00200000 00200000 00200000 012ad9c8 00200000 00200000 00200000 00200000 012ad9d8 00200000 00200000 00200000 00200000 012ad9e8 00200000 00200000 00200000 00200000 012ad9f8 00200000 00200000 00200000 00200000 012ada08 00200000 00200000 00200000 00200000 012ada18 00200000 00200000 00200000 00200000 0:000> 012ada28 00200000 00200000 00200000 00200000 012ada38 00200000 00200000 00200000 00200000 012ada48 00200000 00200000 00200000 00200000 012ada58 00200000 00200000 00200000 00200000 012ada68 00200000 00200000 00200000 00200000 012ada78 00200000 00200000 00200000 00200000 012ada88 00200000 00200000 00200000 00200000 012ada98 00200000 00200000 00200000 00200000 0:000> 012adaa8 00200000 00200000 00200000 00200000 012adab8 00200000 00200000 00200000 00200000 012adac8 00200000 00200000 00200000 00200000 012adad8 00200000 00200000 00200000 00200000 012adae8 00200000 00200000 00200000 00200000 012adaf8 00200000 00200000 00200000 00200000 012adb08 00200000 00200000 00200000 00200000 012adb18 00200000 00200000 00200000 00200000 0:000> 012adb28 00200000 00200000 00200000 00200000 012adb38 00200000 00200000 00200000 00200000 012adb48 00200000 00200000 00200000 00200000 012adb58 00200000 00200000 00200000 00200000 012adb68 00200000 00200000 00200000 00200000 012adb78 00200000 00200000 00200000 00200000 012adb88 00200000 00200000 00200000 00200000 012adb98 00200000 00200000 00200000 00200000 0:000> 012adba8 00200000 00200000 00200000 00200000 012adbb8 00200000 00200000 00200000 00200000 012adbc8 00200000 00200000 00200000 00200000 012adbd8 00200000 00200000 00200000 00200000 012adbe8 00200000 00200000 00200000 00200000 012adbf8 00200000 00200000 00200000 00200000 012adc08 00200000 00200000 00200000 00200000 012adc18 00200000 00200000 00200000 00200000 0:000> 012adc28 00200000 00200000 00200000 00200000 012adc38 00200000 00200000 00200000 00200000 012adc48 00200000 00200000 00200000 00200000 012adc58 00200000 00200000 00200000 00200000 012adc68 00200000 00200000 00200000 00200000 012adc78 00200000 00200000 00200000 00200000 012adc88 00200000 00200000 00200000 00200000 012adc98 00200000 00200000 00200000 00200000 0:000> 012adca8 00200000 00200000 00200000 00200000 012adcb8 00200000 00200000 00200000 00200000 012adcc8 00200000 00200000 00200000 00200000 012adcd8 00200000 00200000 00200000 00200000 012adce8 00200000 00200000 00200000 00200000 012adcf8 00200000 00200000 00200000 00200000 012add08 00200000 00200000 00200000 00200000 012add18 00200000 00200000 00200000 00200000 0:000> 012add28 00200000 00200000 00200000 00200000 012add38 00200000 00200000 00200000 00200000 012add48 00200000 00200000 00200000 00200000 012add58 00200000 00200000 00200000 00200000 012add68 00200000 00200000 00200000 00200000 012add78 00200000 00200000 00200000 00200000 012add88 00200000 00200000 00200000 00200000 012add98 00200000 00200000 00200000 00200000 0:000> 012adda8 00200000 00200000 00200000 00200000 012addb8 00200000 00200000 00200000 00200000 012addc8 00200000 00200000 00200000 00200000 012addd8 00200000 00200000 00200000 00200000 012adde8 00200000 00200000 00200000 00200000 012addf8 00200000 00200000 00200000 00200000 012ade08 00200000 00200000 00200000 00200000 012ade18 00200000 00200000 00200000 00200000 0:000> 012ade28 00200000 00200000 00200000 00200000 012ade38 00200000 00200000 00200000 00200000 012ade48 00200000 00200000 00200000 00200000 012ade58 00200000 00200000 00200000 00200000 012ade68 00200000 00200000 00200000 00200000 012ade78 00200000 00200000 00200000 00200000 012ade88 00200000 00200000 00200000 00200000 012ade98 00200000 00200000 00200000 00200000 0:000> 012adea8 00200000 00200000 00200000 00200000 012adeb8 00200000 00200000 00200000 00200000 012adec8 00200000 00200000 00200000 00200000 012aded8 00200000 00200000 00200000 00200000 012adee8 00200000 00200000 00200000 00200000 012adef8 00200000 00200000 00200000 00200000 012adf08 00200000 00200000 00200000 00200000 012adf18 00200000 00200000 00200000 00200000 0:000> 012adf28 00200000 00200000 00200000 00200000 012adf38 00200000 00200000 00200000 00200000 012adf48 00200000 00200000 00200000 00200000 012adf58 00200000 00200000 00200000 00200000 012adf68 00200000 00200000 00200000 00200000 012adf78 00200000 00200000 00200000 00200000 012adf88 00200000 00200000 00200000 00200000 012adf98 00200000 00200000 00200000 00200000 0:000> 012adfa8 00200000 00200000 00200000 00200000 012adfb8 00200000 00200000 00200000 00200000 012adfc8 00200000 00200000 00200000 00200000 012adfd8 00200000 00200000 00200000 00200000 012adfe8 00200000 00200000 00200000 00200000 012adff8 00200000 00200000 00200000 00200000 012ae008 00200000 00200000 00200000 00200000 012ae018 00200000 00200000 00200000 00200000 0:000> 012ae028 00200000 00200000 00200000 00200000 012ae038 00200000 00200000 00200000 00200000 012ae048 00200000 00200000 00200000 00200000 012ae058 00200000 00200000 00200000 00200000 012ae068 00200000 00200000 00200000 00200000 012ae078 00200000 00200000 00200000 00200000 012ae088 00200000 00200000 00200000 00200000 012ae098 00200000 00200000 00200000 00200000 0:000> 012ae0a8 00200000 00200000 00200000 00200000 012ae0b8 00200000 00200000 00200000 00200000 012ae0c8 00200000 00200000 00200000 00200000 012ae0d8 00200000 00200000 00200000 00200000 012ae0e8 00200000 00200000 00200000 00200000 012ae0f8 00200000 00200000 00200000 00200000 012ae108 00200000 00200000 00200000 00200000 012ae118 00200000 00200000 00200000 00200000 0:000> 012ae128 00200000 00200000 00200000 00200000 012ae138 00200000 00200000 00200000 00200000 012ae148 00200000 00200000 00200000 00200000 012ae158 00200000 00200000 00200000 00200000 012ae168 00200000 00200000 00200000 00200000 012ae178 00200000 00200000 00200000 00200000 012ae188 00200000 00200000 00200000 00200000 012ae198 00200000 00200000 00200000 00200000 0:000> 012ae1a8 00200000 00200000 00200000 00200000 012ae1b8 00200000 00200000 00200000 00200000 012ae1c8 00200000 00200000 00200000 00200000 012ae1d8 00200000 00200000 00200000 00200000 012ae1e8 00200000 00200000 00200000 00200000 012ae1f8 00200000 00200000 00200000 00200000 012ae208 00200000 00200000 00200000 00200000 012ae218 00200000 00200000 00200000 00200000 0:000> 012ae228 00200000 00200000 00200000 00200000 012ae238 00200000 00200000 00200000 00200000 012ae248 00200000 00200000 00200000 00200000 012ae258 00200000 00200000 00200000 00200000 012ae268 00200000 00200000 00200000 00200000 012ae278 00200000 00200000 00200000 00200000 012ae288 00200000 00200000 00200000 00200000 012ae298 00200000 00200000 00200000 00200000 0:000> 012ae2a8 00200000 00200000 00200000 00200000 012ae2b8 00200000 00200000 00200000 00200000 012ae2c8 00200000 00200000 00200000 00200000 012ae2d8 00200000 00200000 00200000 00200000 012ae2e8 00200000 00200000 00200000 00200000 012ae2f8 00200000 00200000 00200000 00200000 012ae308 00200000 00200000 00200000 00200000 012ae318 00200000 00200000 00200000 00200000 0:000> 012ae328 00200000 00200000 00200000 00200000 012ae338 00200000 00200000 00200000 00200000 012ae348 00200000 00200000 00200000 00200000 012ae358 00200000 00200000 00200000 00200000 012ae368 00200000 00200000 00200000 00200000 012ae378 00200000 00200000 00200000 00200000 012ae388 00200000 00200000 00200000 00200000 012ae398 00200000 00200000 00200000 00200000 0:000> 012ae3a8 00200000 00200000 00200000 00200000 012ae3b8 00200000 00200000 00200000 00200000 012ae3c8 00200000 00200000 00200000 00200000 012ae3d8 00200000 00200000 00200000 00200000 012ae3e8 00200000 00200000 00200000 00200000 012ae3f8 00200000 00200000 00200000 00200000 012ae408 00200000 00200000 00200000 00200000 012ae418 00200000 00200000 00200000 00200000 0:000> 012ae428 00200000 00200000 00200000 00200000 012ae438 00200000 00200000 00200000 00200000 012ae448 00200000 00200000 00200000 00200000 012ae458 00200000 00200000 00200000 00200000 012ae468 00200000 00200000 00200000 00200000 012ae478 00200000 00200000 00200000 00200000 012ae488 00200000 00200000 00200000 00200000 012ae498 00200000 00200000 00200000 00200000 0:000> 012ae4a8 00200000 00200000 00200000 00200000 012ae4b8 00200000 00200000 00200000 00200000 012ae4c8 00200000 00200000 00200000 00200000 012ae4d8 00200000 00200000 00200000 00200000 012ae4e8 00200000 00200000 00200000 00200000 012ae4f8 00200000 00200000 00200000 00200000 012ae508 00200000 00200000 00200000 00200000 012ae518 00200000 00200000 00200000 00200000 0:000> 012ae528 00200000 00200000 00200000 00200000 012ae538 00200000 00200000 00200000 00200000 012ae548 00200000 00200000 00200000 00200000 012ae558 00200000 00200000 00200000 00200000 012ae568 00200000 00200000 00200000 00200000 012ae578 00200000 00200000 00200000 00200000 012ae588 00200000 00200000 00200000 00200000 012ae598 00200000 00200000 00200000 00200000 0:000> 012ae5a8 00200000 00200000 00200000 00200000 012ae5b8 00200000 00200000 00200000 00200000 012ae5c8 00200000 00200000 00200000 00200000 012ae5d8 00200000 00200000 00200000 00200000 012ae5e8 00200000 00200000 00200000 00200000 012ae5f8 00200000 00200000 00200000 00200000 012ae608 00200000 00200000 00200000 00200000 012ae618 00200000 00200000 00200000 00200000 0:000> 012ae628 00200000 00200000 00200000 00200000 012ae638 00200000 00200000 00200000 00200000 012ae648 00200000 00200000 00200000 00200000 012ae658 00200000 00200000 00200000 00200000 012ae668 00200000 00200000 00200000 00200000 012ae678 00200000 00200000 00200000 00200000 012ae688 00200000 00200000 00200000 00200000 012ae698 00200000 00200000 00200000 00200000 0:000> 012ae6a8 00200000 00200000 00200000 00200000 012ae6b8 00200000 00200000 00200000 00200000 012ae6c8 00200000 00200000 00200000 00200000 012ae6d8 00200000 00200000 00200000 00200000 012ae6e8 00200000 00200000 00200000 00200000 012ae6f8 00200000 00200000 00200000 00200000 012ae708 00200000 00200000 00200000 00200000 012ae718 00200000 00200000 00200000 00200000 0:000> 012ae728 00200000 00200000 00200000 00200000 012ae738 00200000 00200000 00200000 00200000 012ae748 00200000 00200000 00200000 00200000 012ae758 00200000 00200000 00200000 00200000 012ae768 00200000 00200000 00200000 00200000 012ae778 00200000 00200000 00200000 00200000 012ae788 00200000 00200000 00200000 00200000 012ae798 00200000 00200000 00200000 00200000 0:000> 012ae7a8 00200000 00200000 00200000 00200000 012ae7b8 00200000 00200000 00200000 00200000 012ae7c8 00200000 00200000 00200000 00200000 012ae7d8 00200000 00200000 00200000 00200000 012ae7e8 00200000 00200000 00200000 00200000 012ae7f8 00200000 00200000 00200000 00200000 012ae808 00200000 00200000 00200000 00200000 012ae818 00200000 00200000 00200000 00200000 0:000> 012ae828 00200000 00200000 00200000 00200000 012ae838 00200000 00200000 00200000 00200000 012ae848 00200000 00200000 00200000 00200000 012ae858 00200000 00200000 00200000 00200000 012ae868 00200000 00200000 00200000 00200000 012ae878 00200000 00200000 00200000 00200000 012ae888 00200000 00200000 00200000 00200000 012ae898 00200000 00200000 00200000 00200000 0:000> 012ae8a8 00200000 00200000 00200000 00200000 012ae8b8 00200000 00200000 00200000 00200000 012ae8c8 00200000 00200000 00200000 00200000 012ae8d8 00200000 00200000 00200000 00200000 012ae8e8 00200000 00200000 00200000 00200000 012ae8f8 00200000 00200000 00200000 00200000 012ae908 00200000 00200000 00200000 00200000 012ae918 00200000 00200000 00200000 00200000 0:000> 012ae928 00200000 00200000 00200000 00200000 012ae938 00200000 00200000 00200000 00200000 012ae948 00200000 00200000 00200000 00200000 012ae958 00200000 00200000 00200000 00200000 012ae968 00200000 00200000 00200000 00200000 012ae978 00200000 00200000 00200000 00200000 012ae988 00200000 00200000 00200000 00200000 012ae998 00200000 00200000 00200000 00200000 0:000> 012ae9a8 00200000 00200000 00200000 00200000 012ae9b8 00200000 00200000 00200000 00200000 012ae9c8 00200000 00200000 00200000 00200000 012ae9d8 00200000 00200000 00200000 00200000 012ae9e8 00200000 00200000 00200000 00200000 012ae9f8 00200000 00200000 00200000 00200000 012aea08 00200000 00200000 00200000 00200000 012aea18 00200000 00200000 00200000 00200000 0:000> 012aea28 00200000 00200000 00200000 00200000 012aea38 00200000 00200000 00200000 00200000 012aea48 00200000 00200000 00200000 00200000 012aea58 00200000 00200000 00200000 00200000 012aea68 00200000 00200000 00200000 00200000 012aea78 00200000 00200000 00200000 00200000 012aea88 00200000 00200000 00200000 00200000 012aea98 00200000 00200000 00200000 00200000 0:000> 012aeaa8 00200000 00200000 00200000 00200000 012aeab8 00200000 00200000 00200000 00200000 012aeac8 00200000 00200000 00200000 00200000 012aead8 00200000 00200000 00200000 00200000 012aeae8 00200000 00200000 00200000 00200000 012aeaf8 00200000 00200000 00200000 00200000 012aeb08 00200000 00200000 00200000 00200000 012aeb18 00200000 00200000 00200000 00200000 0:000> 012aeb28 00200000 00200000 00200000 00200000 012aeb38 00200000 00200000 00200000 00200000 012aeb48 00200000 00200000 00200000 00200000 012aeb58 00200000 00200000 00200000 00200000 012aeb68 00200000 00200000 00200000 00200000 012aeb78 00200000 00200000 00200000 00200000 012aeb88 00200000 00200000 00200000 00200000 012aeb98 00200000 00200000 00200000 00200000 0:000> 012aeba8 00200000 00200000 00200000 00200000 012aebb8 00200000 00200000 00200000 00200000 012aebc8 00200000 00200000 00200000 00200000 012aebd8 00200000 00200000 00200000 00200000 012aebe8 00200000 00200000 00200000 00200000 012aebf8 00200000 00200000 00200000 00200000 012aec08 00200000 00200000 00200000 00200000 012aec18 00200000 00200000 00200000 00200000 0:000> 012aec28 00200000 00200000 00200000 00200000 012aec38 00200000 00200000 00200000 00200000 012aec48 00200000 00200000 00200000 00200000 012aec58 00200000 00200000 00200000 00200000 012aec68 00200000 00200000 00200000 00200000 012aec78 00200000 00200000 00200000 00200000 012aec88 00200000 00200000 00200000 00200000 012aec98 00200000 00200000 00200000 00200000 0:000> 012aeca8 00200000 00200000 00200000 00200000 012aecb8 00200000 00200000 00200000 00200000 012aecc8 00200000 00200000 00200000 00200000 012aecd8 00200000 00200000 00200000 00200000 012aece8 00200000 00200000 00200000 00200000 012aecf8 00200000 00200000 00200000 00200000 012aed08 00200000 00200000 00200000 00200000 012aed18 00200000 00200000 00200000 00200000 0:000> 012aed28 00200000 00200000 00200000 00200000 012aed38 00200000 00200000 00200000 00200000 012aed48 00200000 00200000 00200000 00200000 012aed58 00200000 00200000 00200000 00200000 012aed68 00200000 00200000 00200000 00200000 012aed78 00200000 00200000 00200000 00200000 012aed88 00200000 00200000 00200000 00200000 012aed98 00200000 00200000 00200000 00200000 0:000> 012aeda8 00200000 00200000 00200000 00200000 012aedb8 00200000 00200000 00200000 00200000 012aedc8 00200000 00200000 00200000 00200000 012aedd8 00200000 00200000 00200000 00200000 012aede8 00200000 00200000 00200000 00200000 012aedf8 00200000 00200000 00200000 00200000 012aee08 00200000 00200000 00200000 00200000 012aee18 00200000 00200000 00200000 00200000 0:000> 012aee28 00200000 00200000 00200000 00200000 012aee38 00200000 00200000 00200000 00200000 012aee48 00200000 00200000 00200000 00200000 012aee58 00200000 00200000 00200000 00200000 012aee68 00200000 00200000 00200000 00200000 012aee78 00200000 00200000 00200000 00200000 012aee88 00200000 00200000 00200000 00200000 012aee98 00200000 00200000 00200000 00200000 0:000> 012aeea8 00200000 00200000 00200000 00200000 012aeeb8 00200000 00200000 00200000 00200000 012aeec8 00200000 00200000 00200000 00200000 012aeed8 00200000 00200000 00200000 00200000 012aeee8 00200000 00200000 00200000 00200000 012aeef8 00200000 00200000 00200000 00200000 012aef08 00200000 00200000 00200000 00200000 012aef18 00200000 00200000 00200000 00200000 0:000> 012aef28 00200000 00200000 00200000 00200000 012aef38 00200000 00200000 00200000 00200000 012aef48 00200000 00200000 00200000 00200000 012aef58 00200000 00200000 00200000 00200000 012aef68 00200000 00200000 00200000 00200000 012aef78 00200000 00200000 00200000 00200000 012aef88 00200000 00200000 00200000 00200000 012aef98 00200000 00200000 00200000 00200000 0:000> 012aefa8 00200000 00200000 00200000 00200000 012aefb8 00200000 00200000 00200000 00200000 012aefc8 00200000 00200000 00200000 00200000 012aefd8 00200000 00200000 00200000 00200000 012aefe8 00200000 00200000 00200000 00200000 012aeff8 00200000 00200000 00200000 00200000 012af008 00200000 00200000 00200000 00200000 012af018 00200000 00200000 00200000 00200000 0:000> 012af028 00200000 00200000 00200000 00200000 012af038 00200000 00200000 00200000 00200000 012af048 00200000 00200000 00200000 00200000 012af058 00200000 00200000 00200000 00200000 012af068 00200000 00200000 00200000 00200000 012af078 00200000 00200000 00200000 00200000 012af088 00200000 00200000 00200000 00200000 012af098 00200000 00200000 00200000 00200000 0:000> 012af0a8 00200000 00200000 00200000 00200000 012af0b8 00200000 00200000 00200000 00200000 012af0c8 00200000 00200000 00200000 00200000 012af0d8 00200000 00200000 00200000 00200000 012af0e8 00200000 00200000 00200000 00200000 012af0f8 00200000 00200000 00200000 00200000 012af108 00200000 00200000 00200000 00200000 012af118 00200000 00200000 00200000 00200000 0:000> 012af128 00200000 00200000 00200000 00200000 012af138 00200000 00200000 00200000 00200000 012af148 00200000 00200000 00200000 00200000 012af158 00200000 00200000 00200000 00200000 012af168 00200000 00200000 00200000 00200000 012af178 00200000 00200000 00200000 00200000 012af188 00200000 00200000 00200000 00200000 012af198 00200000 00200000 00200000 00200000 0:000> 012af1a8 00200000 00200000 00200000 00200000 012af1b8 00200000 00200000 00200000 00200000 012af1c8 00200000 00200000 00200000 00200000 012af1d8 00200000 00200000 00200000 00200000 012af1e8 00200000 00200000 00200000 00200000 012af1f8 00200000 00200000 00200000 00200000 012af208 00200000 00200000 00200000 00200000 012af218 00200000 00200000 00200000 00200000 0:000> 012af228 00200000 00200000 00200000 00200000 012af238 00200000 00200000 00200000 00200000 012af248 00200000 00200000 00200000 00200000 012af258 00200000 00200000 00200000 00200000 012af268 00200000 00200000 00200000 00200000 012af278 00200000 00200000 00200000 00200000 012af288 00200000 00200000 00200000 00200000 012af298 00200000 00200000 00200000 00200000 0:000> 012af2a8 00200000 00200000 00200000 00200000 012af2b8 00200000 00200000 00200000 00200000 012af2c8 00200000 00200000 00200000 00200000 012af2d8 00200000 00200000 00200000 00200000 012af2e8 00200000 00200000 00200000 00200000 012af2f8 00200000 00200000 00200000 00200000 012af308 00200000 00200000 00200000 00200000 012af318 00200000 00200000 00200000 00200000 0:000> 012af328 00200000 00200000 00200000 00200000 012af338 00200000 00200000 00200000 00200000 012af348 00200000 00200000 00200000 00200000 012af358 00200000 00200000 00200000 00200000 012af368 00200000 00200000 00200000 00200000 012af378 00200000 00200000 00200000 00200000 012af388 00200000 00200000 00200000 00200000 012af398 00200000 00200000 00200000 00200000 0:000> 012af3a8 00200000 00200000 00200000 00200000 012af3b8 00200000 00200000 00200000 00200000 012af3c8 00200000 00200000 00200000 00200000 012af3d8 00200000 00200000 00200000 00200000 012af3e8 00200000 00200000 00200000 00200000 012af3f8 00200000 00200000 00200000 00200000 012af408 00200000 00200000 00200000 00200000 012af418 00200000 00200000 00200000 00200000 0:000> 012af428 00200000 00200000 00200000 00200000 012af438 00200000 00200000 00200000 00200000 012af448 00200000 00200000 00200000 00200000 012af458 00200000 00200000 00200000 00200000 012af468 00200000 00200000 00200000 00200000 012af478 00200000 00200000 00200000 00200000 012af488 00200000 00200000 00200000 00200000 012af498 00200000 00200000 00200000 00200000 0:000> 012af4a8 00200000 00200000 00200000 00200000 012af4b8 00200000 00200000 00200000 00200000 012af4c8 00200000 00200000 00200000 00200000 012af4d8 00200000 00200000 00200000 00200000 012af4e8 00200000 00200000 00200000 00200000 012af4f8 00200000 00200000 00200000 00200000 012af508 00200000 00200000 00200000 00200000 012af518 00200000 00200000 00200000 00200000 0:000> 012af528 00200000 00200000 00200000 00200000 012af538 00200000 00200000 00200000 00200000 012af548 00200000 00200000 00200000 00200000 012af558 00200000 00200000 00200000 00200000 012af568 00200000 00200000 00200000 00200000 012af578 00200000 00200000 00200000 00200000 012af588 00200000 00200000 00200000 00200000 012af598 00200000 00200000 00200000 00200000 0:000> 012af5a8 00200000 00200000 00200000 00200000 012af5b8 00200000 00200000 00200000 00200000 012af5c8 00200000 00200000 00200000 00200000 012af5d8 00200000 00200000 00200000 00200000 012af5e8 00200000 00200000 00200000 00200000 012af5f8 00200000 00200000 00200000 00200000 012af608 00200000 00200000 00200000 00200000 012af618 00200000 00200000 00200000 00200000 0:000> 012af628 00200000 00200000 00200000 00200000 012af638 00200000 00200000 00200000 00200000 012af648 00200000 00200000 00200000 00200000 012af658 00200000 00200000 00200000 00200000 012af668 00200000 00200000 00200000 00200000 012af678 00200000 00200000 00200000 00200000 012af688 00200000 00200000 00200000 00200000 012af698 00200000 00200000 00200000 00200000 0:000> 012af6a8 00200000 00200000 00200000 00200000 012af6b8 00200000 00200000 00200000 00200000 012af6c8 00200000 00200000 00200000 00200000 012af6d8 00200000 00200000 00200000 00200000 012af6e8 00200000 00200000 00200000 00200000 012af6f8 00200000 00200000 00200000 00200000 012af708 00200000 00200000 00200000 00200000 012af718 00200000 00200000 00200000 00200000 0:000> 012af728 00200000 00200000 00200000 00200000 012af738 00200000 00200000 00200000 00200000 012af748 00200000 00200000 00200000 00200000 012af758 00200000 00200000 00200000 00200000 012af768 00200000 00200000 00200000 00200000 012af778 00200000 00200000 00200000 00200000 012af788 00200000 00200000 00200000 00200000 012af798 00200000 00200000 00200000 00200000 0:000> 012af7a8 00200000 00200000 00200000 00200000 012af7b8 00200000 00200000 00200000 00200000 012af7c8 00200000 00200000 00200000 00200000 012af7d8 00200000 00200000 00200000 00200000 012af7e8 00200000 00200000 00200000 00200000 012af7f8 00200000 00200000 00200000 00200000 012af808 00200000 00200000 00200000 00200000 012af818 00200000 00200000 00200000 00200000 0:000> 012af828 00200000 00200000 00200000 00200000 012af838 00200000 00200000 00200000 00200000 012af848 00200000 00200000 00200000 00200000 012af858 00200000 00200000 00200000 00200000 012af868 00200000 00200000 00200000 00200000 012af878 00200000 00200000 00200000 00200000 012af888 00200000 00200000 00200000 00200000 012af898 00200000 00200000 00200000 00200000 0:000> 012af8a8 00200000 00200000 00200000 00200000 012af8b8 00200000 00200000 00200000 00200000 012af8c8 00200000 00200000 00200000 00200000 012af8d8 00200000 00200000 00200000 00200000 012af8e8 00200000 00200000 00200000 00200000 012af8f8 00200000 00200000 00200000 00200000 012af908 00200000 00200000 00200000 00200000 012af918 00200000 00200000 00200000 00200000 0:000> 012af928 00200000 00200000 00200000 00200000 012af938 00200000 00200000 00200000 00200000 012af948 00200000 00200000 00200000 00200000 012af958 00200000 00200000 00200000 00200000 012af968 00200000 00200000 00200000 00200000 012af978 00200000 00200000 00200000 00200000 012af988 00200000 00200000 00200000 00200000 012af998 00200000 00200000 00200000 00200000 0:000> 012af9a8 00200000 00200000 00200000 00200000 012af9b8 00200000 00200000 00200000 00200000 012af9c8 00200000 00200000 00200000 00200000 012af9d8 00200000 00200000 00200000 00200000 012af9e8 00200000 00200000 00200000 00200000 012af9f8 00200000 00200000 00200000 00200000 012afa08 00200000 00200000 00200000 00200000 012afa18 00200000 00200000 00200000 00200000 0:000> 012afa28 00200000 00200000 00200000 00200000 012afa38 00200000 00200000 00200000 00200000 012afa48 00200000 00200000 00200000 00200000 012afa58 00200000 00200000 00200000 00200000 012afa68 00200000 00200000 00200000 00200000 012afa78 00200000 00200000 00200000 00200000 012afa88 00200000 00200000 00200000 00200000 012afa98 00200000 00200000 00200000 00200000 0:000> 012afaa8 00200000 00200000 00200000 00200000 012afab8 00200000 00200000 00200000 00200000 012afac8 00200000 00200000 00200000 00200000 012afad8 00200000 00200000 00200000 00200000 012afae8 00200000 00200000 00200000 00200000 012afaf8 00200000 00200000 00200000 00200000 012afb08 00200000 00200000 00200000 00200000 012afb18 00200000 00200000 00200000 00200000 0:000> 012afb28 00200000 00200000 00200000 00200000 012afb38 00200000 00200000 00200000 00200000 012afb48 00200000 00200000 00200000 00200000 012afb58 00200000 00200000 00200000 00200000 012afb68 00200000 00200000 00200000 00200000 012afb78 00200000 00200000 00200000 00200000 012afb88 00200000 00200000 00200000 00200000 012afb98 00200000 00200000 00200000 00200000 0:000> 012afba8 00200000 00200000 00200000 00200000 012afbb8 00200000 00200000 00200000 00200000 012afbc8 00200000 00200000 00200000 00200000 012afbd8 00200000 00200000 00200000 00200000 012afbe8 00200000 00200000 00200000 00200000 012afbf8 00200000 00200000 00200000 00200000 012afc08 00200000 00200000 00200000 00200000 012afc18 00200000 00200000 00200000 00200000 0:000> 012afc28 00200000 00200000 00200000 00200000 012afc38 00200000 00200000 00200000 00200000 012afc48 00200000 00200000 00200000 00200000 012afc58 00200000 00200000 00200000 00200000 012afc68 00200000 00200000 00200000 00200000 012afc78 00200000 00200000 00200000 00200000 012afc88 00200000 00200000 00200000 00200000 012afc98 00200000 00200000 00200000 00200000 0:000> 012afca8 00200000 00200000 00200000 00200000 012afcb8 00200000 00200000 00200000 00200000 012afcc8 00200000 00200000 00200000 00200000 012afcd8 00200000 00200000 00200000 00200000 012afce8 00200000 00200000 00200000 00200000 012afcf8 00200000 00200000 00200000 00200000 012afd08 00200000 00200000 00200000 00200000 012afd18 00200000 00200000 00200000 00200000 0:000> 012afd28 00200000 00200000 00200000 00200000 012afd38 00200000 00200000 00200000 00200000 012afd48 00200000 00200000 00200000 00200000 012afd58 00200000 00200000 00200000 00200000 012afd68 00200000 00200000 00200000 00200000 012afd78 00200000 00200000 00200000 00200000 012afd88 00200000 00200000 00200000 00200000 012afd98 00200000 00200000 00200000 00200000 0:000> 012afda8 00200000 00200000 00200000 00200000 012afdb8 00200000 00200000 00200000 00200000 012afdc8 00200000 00200000 00200000 00200000 012afdd8 00200000 00200000 00200000 00200000 012afde8 00200000 00200000 00200000 00200000 012afdf8 00200000 00200000 00200000 00200000 012afe08 00200000 00200000 00200000 00200000 012afe18 00200000 00200000 00200000 00200000 0:000> 012afe28 00200000 00200000 00200000 00200000 012afe38 00200000 00200000 00200000 00200000 012afe48 00200000 00200000 00200000 00200000 012afe58 00200000 00200000 00200000 00200000 012afe68 00200000 00200000 00200000 00200000 012afe78 00200000 00200000 00200000 00200000 012afe88 00200000 00200000 00200000 00200000 012afe98 00200000 00200000 00200000 00200000 0:000> 012afea8 00200000 00200000 00200000 00200000 012afeb8 00200000 00200000 00200000 00200000 012afec8 00200000 00200000 00200000 00200000 012afed8 00200000 00200000 00200000 00200000 012afee8 00200000 00200000 00200000 00200000 012afef8 00200000 00200000 00200000 00200000 012aff08 00200000 00200000 00200000 00200000 012aff18 00200000 00200000 00200000 00200000 0:000> 012aff28 00200000 00200000 00200000 00200000 012aff38 00200000 00200000 00200000 00200000 012aff48 00200000 00200000 00200000 00200000 012aff58 00200000 00200000 00200000 00200000 012aff68 00200000 00200000 00200000 00200000 012aff78 00200000 00200000 00200000 00200000 012aff88 00200000 00200000 00200000 00200000 012aff98 00200000 00200000 00200000 00200000 0:000> 012affa8 00200000 00200000 00200000 00200000 012affb8 00200000 00200000 00200000 00200000 012affc8 00200000 00200000 00200000 00200000 012affd8 00200000 00200000 00200000 00200000 012affe8 00200000 00200000 00200000 00200000 012afff8 00200000 00200000 00000013 00000001 012b0008 00200026 012b0014 0000172e 00000000 012b0018 00000000 00000000 00000000 00000000 0:000> 012b0028 00000000 00000000 00000000 00000000 012b0038 00000000 00000000 00000000 00000000 012b0048 00000000 00000000 00000000 00000000 012b0058 00000000 00000000 00000000 00000000 012b0068 00000000 00000000 00000000 00000000 012b0078 00000000 00000000 00000000 00000000 012b0088 00000000 00000000 00000000 00000000 012b0098 00000000 00000000 00000000 00000000 0:000> 012b00a8 00000000 00000000 00000000 00000000 012b00b8 00000000 00000000 00000000 00000000 012b00c8 00000000 00000000 00000000 00000000 012b00d8 00000000 00000000 00000000 00000000 012b00e8 00000000 00000000 00000000 00000000 012b00f8 00000000 00000000 00000000 00000000 012b0108 00000000 00000000 00000000 00000000 012b0118 00000000 00000000 00000000 00000000 0:000> 012b0128 00000000 00000000 00000000 00000000 012b0138 00000000 00000000 00000000 00000000 012b0148 00000000 00000000 00000000 00000000 012b0158 00000000 00000000 00000000 00000000 012b0168 00000000 00000000 00000000 00000000 012b0178 00000000 00000000 00000000 00000000 012b0188 00000000 00000000 00000000 00000000 012b0198 00000000 00000000 00000000 00000000 0:000> 012b01a8 00000000 00000000 00000000 00000000 012b01b8 00000000 00000000 00000000 00000000 012b01c8 00000000 00000000 00000000 00000000 012b01d8 00000000 00000000 00000000 00000000 012b01e8 00000000 00000000 00000000 00000000 012b01f8 00000000 00000000 00000000 00000000 012b0208 00000000 00000000 00000000 00000000 012b0218 00000000 00000000 00000000 00000000 0:000> 012b0228 00000000 00000000 00000000 00000000 012b0238 00000000 00000000 00000000 00000000 012b0248 00000000 00000000 00000000 00000000 012b0258 00000000 00000000 00000000 00000000 012b0268 00000000 00000000 00000000 00000000 012b0278 00000000 00000000 00000000 00000000 012b0288 00000000 00000000 00000000 00000000 012b0298 00000000 00000000 00000000 00000000 0:000> 012b02a8 00000000 00000000 00000000 00000000 012b02b8 00000000 00000000 00000000 00000000 012b02c8 00000000 00000000 00000000 00000000 012b02d8 00000000 00000000 00000000 00000000 012b02e8 00000000 00000000 00000000 00000000 012b02f8 00000000 00000000 00000000 00000000 012b0308 00000000 00000000 00000000 00000000 012b0318 00000000 00000000 00000000 00000000 0:000> 012b0328 00000000 00000000 00000000 00000000 012b0338 00000000 00000000 00000000 00000000 012b0348 00000000 00000000 55000000 55005500 012b0358 55005500 55005500 55005500 55005500 012b0368 55005500 55005500 55005500 55005500 012b0378 55005500 55005500 55005500 55005500 012b0388 55005500 55005500 55005500 55005500 012b0398 55005500 55005500 55005500 55005500 0:000> 012b03a8 55005500 55005500 55005500 55005500 012b03b8 55005500 55005500 55005500 55005500 012b03c8 55005500 55005500 55005500 55005500 012b03d8 55005500 55005500 55005500 55005500 012b03e8 55005500 55005500 55005500 55005500 012b03f8 55005500 55005500 55005500 55005500 012b0408 55005500 55005500 55005500 55005500 012b0418 55005500 55005500 55005500 55005500 0:000> 012b0428 55005500 55005500 55005500 55005500 012b0438 55005500 55005500 55005500 55005500 012b0448 55005500 55005500 55005500 55005500 012b0458 55005500 55005500 00000000 55000000 012b0468 55000055 55000055 55000055 55000055 012b0478 55000055 55000055 55000055 55000055 012b0488 55000055 55000055 55000055 55000055 012b0498 55000055 55000055 55000055 55000055 0:000> 012b04a8 55000055 55000055 55000055 55000055 012b04b8 55000055 55000055 55000055 55000055 012b04c8 55000055 55000055 55000055 55000055 012b04d8 55000055 55000055 55000055 55000055 012b04e8 55000055 55000055 55000055 55000055 012b04f8 55000055 55000055 55000055 55000055 012b0508 55000055 55000055 55000055 55000055 012b0518 55000055 55000055 55000055 55000055 0:000> 012b0528 55000055 55000055 55000055 55000055 012b0538 55000055 55000055 55000055 55000055 012b0548 55000055 55000055 55000055 55000055 012b0558 55000055 55000055 55000055 55000055 012b0568 55000055 55000055 55000055 00000000 012b0578 00000000 00555555 00555555 00555555 012b0588 00555555 00555555 00555555 00555555 012b0598 00555555 00555555 00555555 00555555 0:000> 012b05a8 00555555 00555555 00555555 00555555 012b05b8 00555555 00555555 00555555 00555555 012b05c8 00555555 00555555 00555555 00555555 012b05d8 00555555 00555555 00555555 00555555 012b05e8 00555555 00555555 00555555 00555555 012b05f8 00555555 00555555 00555555 00555555 012b0608 00555555 00555555 00555555 00555555 012b0618 00555555 00555555 00555555 00555555 0:000> 012b0628 00555555 00555555 00555555 00555555 012b0638 00555555 00555555 00555555 00555555 012b0648 00555555 00555555 00555555 00555555 012b0658 00555555 00555555 00555555 00555555 012b0668 00555555 00555555 00555555 00555555 012b0678 00555555 00555555 00555555 00555555 012b0688 00000000 55000000 55005500 55005500 012b0698 55005500 55005500 55005500 55005500 0:000> 012b06a8 55005500 55005500 55005500 55005500 012b06b8 55005500 55005500 55005500 55005500 012b06c8 55005500 55005500 55005500 55005500 012b06d8 55005500 55005500 55005500 55005500 012b06e8 55005500 55005500 55005500 55005500 012b06f8 55005500 55005500 55005500 55005500 012b0708 55005500 55005500 55005500 55005500 012b0718 55005500 55005500 55005500 55005500 0:000> 012b0728 55005500 55005500 55005500 55005500 012b0738 55005500 55005500 55005500 55005500 012b0748 55005500 55005500 55005500 55005500 012b0758 55005500 55005500 55005500 55005500 012b0768 55005500 55005500 55005500 55005500 012b0778 55005500 55005500 55005500 55005500 012b0788 55005500 55005500 55005500 55005500 012b0798 55005500 00000000 00000000 00555500 0:000> 012b07a8 00555500 00555500 00555500 00555500 012b07b8 00555500 00555500 00555500 00555500 012b07c8 00555500 00555500 00555500 00555500 012b07d8 00555500 00555500 00555500 00555500 012b07e8 00555500 00555500 00555500 00555500 012b07f8 00555500 00555500 00555500 00555500 012b0808 00555500 00555500 00555500 00555500 012b0818 00555500 00555500 00555500 00555500 0:000> 012b0828 00555500 00555500 00555500 00555500 012b0838 00555500 00555500 00555500 00555500 012b0848 00555500 00555500 00555500 00555500 012b0858 00555500 00555500 00555500 00555500 012b0868 00555500 00555500 00555500 00555500 012b0878 00555500 00555500 00555500 00555500 012b0888 00555500 00555500 00555500 00555500 012b0898 00555500 00555500 00555500 00555500 0:000> 012b08a8 00555500 00555500 00000000 55000000 012b08b8 55550055 55550055 55550055 55550055 012b08c8 55550055 55550055 55550055 55550055 012b08d8 55550055 55550055 55550055 55550055 012b08e8 55550055 55550055 55550055 55550055 012b08f8 55550055 55550055 55550055 55550055 012b0908 55550055 55550055 55550055 55550055 012b0918 55550055 55550055 55550055 55550055 0:000> 012b0928 55550055 55550055 55550055 55550055 012b0938 55550055 55550055 55550055 55550055 012b0948 55550055 55550055 55550055 55550055 012b0958 55550055 55550055 55550055 55550055 012b0968 55550055 55550055 55550055 55550055 012b0978 55550055 55550055 55550055 55550055 012b0988 55550055 55550055 55550055 55550055 012b0998 55550055 55550055 55550055 55550055 0:000> 012b09a8 55550055 55550055 55550055 55550055 012b09b8 55550055 55550055 55550055 00000000 012b09c8 55000000 55005500 55005500 55005500 012b09d8 55005500 55005500 55005500 55005500 012b09e8 55005500 55005500 55005500 55005500 012b09f8 55005500 55005500 55005500 55005500 012b0a08 55005500 55005500 55005500 55005500 012b0a18 55005500 55005500 55005500 55005500 0:000> 012b0a28 55005500 55005500 55005500 55005500 012b0a38 55005500 55005500 55005500 55005500 012b0a48 55005500 55005500 55005500 55005500 012b0a58 55005500 55005500 55005500 55005500 012b0a68 55005500 55005500 55005500 55005500 012b0a78 55005500 55005500 55005500 55005500 012b0a88 55005500 55005500 55005500 55005500 012b0a98 55005500 55005500 55005500 55005500 0:000> 012b0aa8 55005500 55005500 55005500 55005500 012b0ab8 55005500 55005500 55005500 55005500 012b0ac8 55005500 55005500 55005500 55005500 012b0ad8 00000000 55000000 55000055 55000055 012b0ae8 55000055 55000055 55000055 55000055 012b0af8 55000055 55000055 55000055 55000055 012b0b08 55000055 55000055 55000055 55000055 012b0b18 55000055 55000055 55000055 55000055 0:000> 012b0b28 55000055 55000055 55000055 55000055 012b0b38 55000055 55000055 55000055 55000055 012b0b48 55000055 55000055 55000055 55000055 012b0b58 55000055 55000055 55000055 55000055 012b0b68 55000055 55000055 55000055 55000055 012b0b78 55000055 55000055 55000055 55000055 012b0b88 55000055 55000055 55000055 55000055 012b0b98 55000055 55000055 55000055 55000055 0:000> 012b0ba8 55000055 55000055 55000055 55000055 012b0bb8 55000055 55000055 55000055 55000055 012b0bc8 55000055 55000055 55000055 55000055 012b0bd8 55000055 55000055 55000055 55000055 012b0be8 55000055 00000000 00000000 00555555 012b0bf8 00555555 00555555 00555555 00555555 012b0c08 00555555 00555555 00555555 00555555 012b0c18 00555555 00555555 00555555 00555555 0:000> 012b0c28 00555555 00555555 00555555 00555555 012b0c38 00555555 00555555 00555555 00555555 012b0c48 00555555 00555555 00555555 00555555 012b0c58 00555555 00555555 00555555 00555555 012b0c68 00555555 00555555 00555555 00555555 012b0c78 00555555 00555555 00555555 00555555 012b0c88 00555555 00555555 00555555 00555555 012b0c98 00555555 00555555 00555555 00555555 0:000> 012b0ca8 00555555 00555555 00555555 00555555 012b0cb8 00555555 00555555 00555555 00555555 012b0cc8 00555555 00555555 00555555 00555555 012b0cd8 00555555 00555555 00555555 00555555 012b0ce8 00555555 00555555 00555555 00555555 012b0cf8 00555555 00555555 00000000 55000000 012b0d08 55005500 55005500 55005500 55005500 012b0d18 55005500 55005500 55005500 55005500 0:000> 012b0d28 55005500 55005500 55005500 55005500 012b0d38 55005500 55005500 55005500 55005500 012b0d48 55005500 55005500 55005500 55005500 012b0d58 55005500 55005500 55005500 55005500 012b0d68 55005500 55005500 55005500 55005500 012b0d78 55005500 55005500 55005500 55005500 012b0d88 55005500 55005500 55005500 55005500 012b0d98 55005500 55005500 55005500 55005500 0:000> 012b0da8 55005500 55005500 55005500 55005500 012b0db8 55005500 55005500 55005500 55005500 012b0dc8 55005500 55005500 55005500 55005500 012b0dd8 55005500 55005500 55005500 55005500 012b0de8 55005500 55005500 55005500 55005500 012b0df8 55005500 55005500 55005500 55005500 012b0e08 55005500 55005500 55005500 00000000 012b0e18 00000000 00555500 00555500 00555500 0:000> 012b0e28 00555500 00555500 00555500 00555500 012b0e38 00555500 00555500 00555500 00555500 012b0e48 00555500 00555500 00555500 00555500 012b0e58 00555500 00555500 00555500 00555500 012b0e68 00555500 00555500 00555500 00555500 012b0e78 00555500 00555500 00555500 00555500 012b0e88 00555500 00555500 00555500 00555500 012b0e98 00555500 00555500 00555500 00555500 0:000> 012b0ea8 00555500 00555500 00555500 00555500 012b0eb8 00555500 00555500 00555500 00555500 012b0ec8 00555500 00555500 00555500 00555500 012b0ed8 00555500 00555500 00555500 00555500 012b0ee8 00555500 00555500 00555500 00555500 012b0ef8 00555500 00555500 00555500 00555500 012b0f08 00555500 00555500 00555500 00555500 012b0f18 00555500 00555500 00555500 00555500 0:000> 012b0f28 00000000 55000000 55550055 55550055 012b0f38 55550055 55550055 55550055 55550055 012b0f48 55550055 55550055 55550055 55550055 012b0f58 55550055 55550055 55550055 55550055 012b0f68 55550055 55550055 55550055 55550055 012b0f78 55550055 55550055 55550055 55550055 012b0f88 55550055 55550055 55550055 55550055 012b0f98 55550055 55550055 55550055 55550055 0:000> 012b0fa8 55550055 55550055 55550055 55550055 012b0fb8 55550055 55550055 55550055 55550055 012b0fc8 55550055 55550055 55550055 55550055 012b0fd8 55550055 55550055 55550055 55550055 012b0fe8 55550055 55550055 55550055 55550055 012b0ff8 55550055 55550055 55550055 55550055 012b1008 55550055 55550055 55550055 55550055 012b1018 55550055 55550055 55550055 55550055 0:000> 012b1028 55550055 55550055 55550055 55550055 012b1038 55550055 00000000 55000000 55005500 012b1048 55005500 55005500 55005500 55005500 012b1058 55005500 55005500 55005500 55005500 012b1068 55005500 55005500 55005500 55005500 012b1078 55005500 55005500 55005500 55005500 012b1088 55005500 55005500 55005500 55005500 012b1098 55005500 55005500 55005500 55005500 0:000> 012b10a8 55005500 55005500 55005500 55005500 012b10b8 55005500 55005500 55005500 55005500 012b10c8 55005500 55005500 55005500 55005500 012b10d8 55005500 55005500 55005500 55005500 012b10e8 55005500 55005500 55005500 55005500 012b10f8 55005500 55005500 55005500 55005500 012b1108 55005500 55005500 55005500 55005500 012b1118 55005500 55005500 55005500 55005500 0:000> 012b1128 55005500 55005500 55005500 55005500 012b1138 55005500 55005500 55005500 55005500 012b1148 55005500 55005500 00000000 55000000 012b1158 55000055 55000055 55000055 55000055 012b1168 55000055 55000055 55000055 55000055 012b1178 55000055 55000055 55000055 55000055 012b1188 55000055 55000055 55000055 55000055 012b1198 55000055 55000055 55000055 55000055 0:000> 012b11a8 55000055 55000055 55000055 55000055 012b11b8 55000055 55000055 55000055 55000055 012b11c8 55000055 55000055 55000055 55000055 012b11d8 55000055 55000055 55000055 55000055 012b11e8 55000055 55000055 55000055 55000055 012b11f8 55000055 55000055 55000055 55000055 012b1208 55000055 55000055 55000055 55000055 012b1218 55000055 55000055 55000055 55000055 0:000> 012b1228 55000055 55000055 55000055 55000055 012b1238 55000055 55000055 55000055 55000055 012b1248 55000055 55000055 55000055 55000055 012b1258 55000055 55000055 55000055 00000000 012b1268 00000000 00555555 00555555 00555555 012b1278 00555555 00555555 00555555 00555555 012b1288 00555555 00555555 00555555 00555555 012b1298 00555555 00555555 00555555 00555555 0:000> 012b12a8 00555555 00555555 00555555 00555555 012b12b8 00555555 00555555 00555555 00555555 012b12c8 00555555 00555555 00555555 00555555 012b12d8 00555555 00555555 00555555 00555555 012b12e8 00555555 00555555 00555555 00555555 012b12f8 00555555 00555555 00555555 00555555 012b1308 00555555 00555555 00555555 00555555 012b1318 00555555 00555555 00555555 00555555 0:000> 012b1328 00555555 00555555 00555555 00555555 012b1338 00555555 00555555 00555555 00555555 012b1348 00555555 00555555 00555555 00555555 012b1358 00555555 00555555 00555555 00555555 012b1368 00555555 00555555 00555555 00555555 012b1378 00000000 55000000 55005500 55005500 012b1388 55005500 55005500 55005500 55005500 012b1398 55005500 55005500 55005500 55005500 0:000> 012b13a8 55005500 55005500 55005500 55005500 012b13b8 55005500 55005500 55005500 55005500 012b13c8 55005500 55005500 55005500 55005500 012b13d8 55005500 55005500 55005500 55005500 012b13e8 55005500 55005500 55005500 55005500 012b13f8 55005500 55005500 55005500 55005500 012b1408 55005500 55005500 55005500 55005500 012b1418 55005500 55005500 55005500 55005500 0:000> 012b1428 55005500 55005500 55005500 55005500 012b1438 55005500 55005500 55005500 55005500 012b1448 55005500 55005500 55005500 55005500 012b1458 55005500 55005500 55005500 55005500 012b1468 55005500 55005500 55005500 55005500 012b1478 55005500 55005500 55005500 55005500 012b1488 55005500 00000000 00000000 00555500 012b1498 00555500 00555500 00555500 00555500 0:000> 012b14a8 00555500 00555500 00555500 00555500 012b14b8 00555500 00555500 00555500 00555500 012b14c8 00555500 00555500 00555500 00555500 012b14d8 00555500 00555500 00555500 00555500 012b14e8 00555500 00555500 00555500 00555500 012b14f8 00555500 00555500 00555500 00555500 012b1508 00555500 00555500 00555500 00555500 012b1518 00555500 00555500 00555500 00555500 0:000> 012b1528 00555500 00555500 00555500 00555500 012b1538 00555500 00555500 00555500 00555500 012b1548 00555500 00555500 00555500 00555500 012b1558 00555500 00555500 00555500 00555500 012b1568 00555500 00555500 00555500 00555500 012b1578 00555500 00555500 00555500 00555500 012b1588 00555500 00555500 00555500 00555500 012b1598 00555500 00555500 00000000 55000000 0:000> 012b15a8 55550055 55550055 55550055 55550055 012b15b8 55550055 55550055 55550055 55550055 012b15c8 55550055 55550055 55550055 55550055 012b15d8 55550055 55550055 55550055 55550055 012b15e8 55550055 ff550055 ffffffff ffffffff 012b15f8 ffffffff 55550055 ffffffff ffffffff 012b1608 555500ff 55550055 55550055 55550055 012b1618 55550055 55550055 ffff0055 ffffffff 0:000> 012b1628 5555ffff 55550055 ff550055 ffffffff 012b1638 55ffffff 55550055 55550055 55550055 012b1648 55550055 55550055 55550055 55550055 012b1658 55550055 55550055 55550055 55550055 012b1668 55550055 55550055 55550055 55550055 012b1678 55550055 55550055 55550055 55550055 012b1688 55550055 55550055 55550055 55550055 012b1698 55550055 55550055 55550055 55550055 0:000> 012b16a8 55550055 55550055 55550055 00000000 012b16b8 55000000 55005500 55005500 55005500 012b16c8 55005500 55005500 55005500 55005500 012b16d8 55005500 55005500 55005500 55005500 012b16e8 55005500 55005500 55005500 55005500 012b16f8 55005500 55005500 55005500 ffffff00 012b1708 ffffffff 550055ff 55005500 ff005500 012b1718 55ffffff 55005500 55005500 55005500 0:000> 012b1728 55005500 55005500 55005500 ff005500 012b1738 ffffffff 55ffffff 55005500 55005500 012b1748 ffffff00 550055ff 55005500 55005500 012b1758 55005500 55005500 55005500 55005500 012b1768 55005500 ff005500 ffffffff 55ffffff 012b1778 55005500 55005500 55005500 55005500 012b1788 55005500 55005500 55005500 55005500 012b1798 55005500 55005500 55005500 55005500 0:000> 012b17a8 55005500 55005500 55005500 55005500 012b17b8 55005500 55005500 55005500 55005500 012b17c8 00000000 55000000 55000055 55000055 012b17d8 55000055 55000055 55000055 55000055 012b17e8 ffffff55 ffffffff ffffffff ffffffff 012b17f8 ffffffff ffffffff 55000055 55000055 012b1808 55000055 55000055 55000055 55000055 012b1818 ffff0055 ffffffff 55000055 55000055 0:000> 012b1828 55000055 5500ffff 55000055 55000055 012b1838 55000055 55000055 55000055 55000055 012b1848 55000055 ffffffff ffffffff 55000055 012b1858 55000055 ffff0055 55000055 55000055 012b1868 55000055 55000055 55000055 55000055 012b1878 55000055 55000055 ffffffff 550000ff 012b1888 ffffff55 5500ffff 55000055 55000055 012b1898 55000055 55000055 55000055 55000055 0:000> 012b18a8 55000055 55000055 55000055 55000055 012b18b8 ffffff55 55ffffff 55000055 55000055 012b18c8 55000055 55000055 55000055 55000055 012b18d8 55000055 00000000 00000000 00555555 012b18e8 00555555 00555555 00555555 00555555 012b18f8 00555555 ffffff55 ffffffff ffffffff 012b1908 ffffffff ffffffff ffffffff 00555555 012b1918 00555555 00555555 00555555 00555555 0:000> 012b1928 00555555 ffff5555 ffffffff 00555555 012b1938 00555555 00555555 0055ffff 00555555 012b1948 00555555 00555555 00555555 00555555 012b1958 00555555 00555555 ffffff55 ffffffff 012b1968 005555ff 00555555 ffff5555 00555555 012b1978 00555555 00555555 00555555 00555555 012b1988 00555555 00555555 ff555555 00ffffff 012b1998 00555555 ff555555 00ffffff 00555555 0:000> 012b19a8 00555555 00555555 00555555 00555555 012b19b8 00555555 00555555 00555555 00555555 012b19c8 ffff5555 ffffffff ffffffff 0055ffff 012b19d8 00555555 00555555 00555555 00555555 012b19e8 00555555 00555555 00000000 55000000 012b19f8 55005500 55005500 55005500 55005500 012b1a08 55005500 55005500 55005500 ffff5500 012b1a18 ffffffff ffffffff ffffffff 55005500 0:000> 012b1a28 55005500 55005500 00005500 55005500 012b1a38 55005500 55005500 ffff5500 ffffffff 012b1a48 55005500 55005500 55005500 5500ffff 012b1a58 55005500 00005500 00550055 00550000 012b1a68 55000055 55005500 55005500 ffffff00 012b1a78 ffffffff 550055ff 55005500 ffff5500 012b1a88 55005500 55005500 00550000 00000055 012b1a98 00550055 55005500 55005500 ffff5500 0:000> 012b1aa8 5500ffff 55005500 55005500 ffffffff 012b1ab8 55005500 55005500 00005500 00550055 012b1ac8 00550000 55000055 55005500 55005500 012b1ad8 55005500 ffffff00 ffffffff ffffffff 012b1ae8 ffffffff 55005500 55005500 55005500 012b1af8 55005500 55005500 55005500 00000000 012b1b08 00000000 00555500 00555500 00555500 012b1b18 00555500 00555500 00555500 00555500 0:000> 012b1b28 ff555500 ffffffff ffffffff 00ffffff 012b1b38 00555500 00555500 00555500 00005500 012b1b48 00555500 00555500 00555500 ffff5500 012b1b58 ffffffff 00555500 00555500 00555500 012b1b68 0055ffff 00555500 55555500 00550000 012b1b78 55550000 00550000 00555500 00555500 012b1b88 ffffff00 ffffffff 0055ffff 00555500 012b1b98 ffff5500 00555500 00555500 00005500 0:000> 012b1ba8 00000055 00005555 00555500 00555500 012b1bb8 ffffff00 0055ffff 00555500 00555500 012b1bc8 ffffffff 005555ff 00555500 55555500 012b1bd8 00550000 55550000 00550000 00555500 012b1be8 00555500 ff555500 ffffffff ffffffff 012b1bf8 ffffffff ffffffff 005555ff 00555500 012b1c08 00555500 00555500 00555500 00555500 012b1c18 00000000 55000000 55550055 55550055 0:000> 012b1c28 55550055 55550055 55550055 55550055 012b1c38 55550055 55550055 ffffffff ffffffff 012b1c48 5555ffff 55550055 55550055 55550055 012b1c58 00000055 55550000 55550055 55550055 012b1c68 ffff0055 ffffffff 55550055 55550055 012b1c78 55550055 5555ffff 55550055 55550055 012b1c88 00005555 55000000 55555555 55550055 012b1c98 55550055 55ffff55 ffffffff 55ffffff 0:000> 012b1ca8 55550055 ffff0055 55550055 55550055 012b1cb8 55555555 00000000 55555500 55550055 012b1cc8 55550055 ffffffff 555500ff 55550055 012b1cd8 55550055 ffffff55 5555ffff 55550055 012b1ce8 55550055 00005555 55000000 55555555 012b1cf8 55550055 55550055 ffff0055 ffffffff 012b1d08 ffffffff ffffffff ffffffff 5555ffff 012b1d18 55550055 55550055 55550055 55550055 0:000> 012b1d28 55550055 00000000 55000000 55005500 012b1d38 55005500 55005500 55005500 55005500 012b1d48 55005500 55005500 55005500 ffffffff 012b1d58 ffffffff 5500ffff 55005500 55005500 012b1d68 55005500 00000000 55000000 55005500 012b1d78 55005500 ffff5500 ffffffff 55005500 012b1d88 55005500 55005500 5500ffff 55005500 012b1d98 00005500 00000055 00000000 55000055 0:000> 012b1da8 55005500 55005500 55ffff00 ffffffff 012b1db8 ffffffff 55005500 ffff5500 55005500 012b1dc8 55005500 00550000 00000000 00550000 012b1dd8 55005500 ff005500 ffffffff 550055ff 012b1de8 55005500 55005500 ffffff00 55ffffff 012b1df8 55005500 00005500 00000055 00000000 012b1e08 55000055 55005500 55005500 ffff5500 012b1e18 ffffffff ffffffff ffffffff ffffffff 0:000> 012b1e28 5500ffff 55005500 55005500 55005500 012b1e38 55005500 55005500 00000000 55000000 012b1e48 55000055 55000055 55000055 55000055 012b1e58 55000055 55000055 55000055 55000055 012b1e68 ffffffff ffffffff 5500ffff 55000055 012b1e78 55000055 55000055 00000055 55000000 012b1e88 55000055 55000055 ffff0055 ffffffff 012b1e98 55000055 55000055 55000055 5500ffff 0:000> 012b1ea8 55000055 00000055 00005555 00000000 012b1eb8 55005555 55000055 55000055 55ffff55 012b1ec8 ffffff55 ffffffff 550000ff ffff0055 012b1ed8 55000055 55000055 55550055 00000000 012b1ee8 55550000 55000055 ff000055 ffffffff 012b1ef8 55000055 55000055 55000055 ffff0055 012b1f08 55ffffff 55000055 00000055 00005555 012b1f18 00000000 55005555 55000055 55000055 0:000> 012b1f28 ffffff55 ffffffff ffffffff ffffffff 012b1f38 ffffffff 55ffffff 55000055 55000055 012b1f48 55000055 55000055 55000055 00000000 012b1f58 00000000 00555555 00555555 00555555 012b1f68 00555555 00555555 00555555 00555555 012b1f78 00555555 ffffffff ffffffff 0055ffff 012b1f88 00555555 00555555 00555555 00000000 012b1f98 00000000 00555555 00555555 ffff5555 0:000> 012b1fa8 ffffffff 00555555 00555555 00555555 012b1fb8 0055ffff 00555555 55555555 00000000 012b1fc8 00000000 00555500 00555555 00555555 012b1fd8 00ffff55 ffff5555 ffffffff 005555ff 012b1fe8 ffff5555 00555555 00555555 00005555 012b1ff8 00000000 55000000 00555555 ff555555 012b2008 ffffffff 00555555 00555555 00555555 012b2018 ffff5555 00ffffff 00555555 55555555 0:000> 012b2028 00000000 00000000 00555500 00555555 012b2038 00555555 ffffffff 005555ff ffff5555 012b2048 ffffffff ffffffff 00ffffff 00555555 012b2058 00555555 00555555 00555555 00555555 012b2068 00000000 55000000 55005500 55005500 012b2078 55005500 55005500 55005500 55005500 012b2088 55005500 55005500 ffffffff ffffffff 012b2098 5500ffff 55005500 55005500 55005500 0:000> 012b20a8 00000000 55000000 55005500 55005500 012b20b8 ffff5500 ffffffff 55005500 55005500 012b20c8 55005500 5500ffff 55005500 00005500 012b20d8 00000055 00000000 55000055 55005500 012b20e8 55005500 55ffff00 ff005500 ffffffff 012b20f8 5500ffff ffff5500 55005500 55005500 012b2108 00550000 00000000 00550000 55005500 012b2118 ffff5500 ffffffff 55005500 55005500 0:000> 012b2128 55005500 ffff5500 ffffffff 55005500 012b2138 00005500 00000055 00000000 55000055 012b2148 55005500 55005500 55ffffff 55005500 012b2158 55005500 ffffffff ffffffff ffffffff 012b2168 55005500 55005500 55005500 55005500 012b2178 55005500 00000000 00000000 00555500 012b2188 00555500 00555500 00555500 00555500 012b2198 00555500 00555500 00555500 ffffffff 0:000> 012b21a8 ffffffff 0055ffff 00555500 00555500 012b21b8 00555500 00000000 00000000 00555500 012b21c8 00555500 ffff5500 ffffffff 00555500 012b21d8 00555500 00555500 0055ffff 00555500 012b21e8 55555500 00000000 00000000 00550000 012b21f8 00555500 00555500 00ffff00 00555500 012b2208 ffffffff 00ffffff ffff5500 00555500 012b2218 00555500 00005500 00000000 00000000 0:000> 012b2228 00555500 ffff5500 ffffffff 00555500 012b2238 00555500 00555500 ffff5500 ffffffff 012b2248 00555500 55555500 00000000 00000000 012b2258 00550000 00555500 ff555500 0055ffff 012b2268 00555500 00555500 ffffff00 ffffffff 012b2278 ffffffff 00555500 00555500 00555500 012b2288 00555500 00555500 00000000 55000000 012b2298 55550055 55550055 55550055 55550055 0:000> 012b22a8 55550055 55550055 55550055 55550055 012b22b8 ffffffff ffffffff 5555ffff 55550055 012b22c8 55550055 00000055 00000000 00000000 012b22d8 55550000 55550055 ffff0055 ffffffff 012b22e8 55550055 55550055 55550055 5555ffff 012b22f8 55550055 00550055 00000000 00000000 012b2308 55550000 55550055 55550055 55ffff55 012b2318 55550055 ffffff55 ffffffff ffff0055 0:000> 012b2328 55550055 55550055 00000055 00000000 012b2338 00000000 55550055 ffff0055 ffffffff 012b2348 55550055 55550055 55550055 ffff0055 012b2358 ffffffff 55550055 00550055 00000000 012b2368 00000000 55550000 55550055 ff550055 012b2378 555500ff 55550055 55550055 ffff0055 012b2388 ffffffff ffffffff 55550055 55550055 012b2398 55550055 55550055 55550055 00000000 0:000> 012b23a8 55000000 55005500 55005500 55005500 012b23b8 55005500 55005500 55005500 55005500 012b23c8 55005500 ffffffff ffffffff 5500ffff 012b23d8 55005500 55005500 00005500 00000000 012b23e8 00000000 55005500 55005500 ffff5500 012b23f8 ffffffff 55005500 55005500 55005500 012b2408 5500ffff 55005500 00005500 00000000 012b2418 00000000 55000000 55005500 55005500 0:000> 012b2428 55ffff00 55005500 ffffff00 ffffffff 012b2438 ffff55ff 55005500 55005500 00000000 012b2448 00000000 00000000 55005500 ffff5500 012b2458 ffffffff 55005500 55005500 55005500 012b2468 ffff5500 ffffffff 55005500 00005500 012b2478 00000000 00000000 55000000 55005500 012b2488 ffff5500 55005500 55005500 55005500 012b2498 ffff5500 ffffffff ffffffff 55005500 0:000> 012b24a8 55005500 55005500 55005500 55005500 012b24b8 00000000 55000000 55000055 55000055 012b24c8 55000055 55000055 55000055 55000055 012b24d8 55000055 55000055 ffffffff ffffffff 012b24e8 5500ffff 55000055 55000055 00000055 012b24f8 00000000 00000000 55000000 55000055 012b2508 ffff0055 ffffffff 55000055 55000055 012b2518 55000055 5500ffff 55000055 00000055 0:000> 012b2528 00000000 00000000 55000000 55000055 012b2538 55000055 55ffff55 55000055 ffff0055 012b2548 ffffffff ffff00ff 55000055 55000055 012b2558 00000055 00000000 00000000 55000055 012b2568 ffff0055 ffffffff 55000055 55000055 012b2578 55000055 ffff0055 ffffffff 55000055 012b2588 00000055 00000000 00000000 55000000 012b2598 55000055 55000055 55000055 55000055 0:000> 012b25a8 55000055 ff000055 ffffffff ffffffff 012b25b8 55000055 55000055 55000055 55000055 012b25c8 55000055 00000000 00000000 00555555 012b25d8 00555555 00555555 00555555 00555555 012b25e8 00555555 00555555 00555555 ffffffff 012b25f8 ffffffff 0055ffff 00555555 00555555 012b2608 00555555 00000000 00000000 00555555 012b2618 00555555 ffff5555 ffffffff 00555555 0:000> 012b2628 00555555 00555555 0055ffff 00555555 012b2638 55555555 00000000 00000000 00555500 012b2648 00555555 00555555 00ffff55 00555555 012b2658 ff555555 ffffffff ffffffff 00555555 012b2668 00555555 00005555 00000000 55000000 012b2678 00555555 ffff5555 ffffffff 00555555 012b2688 00555555 00555555 ffff5555 ffffffff 012b2698 00555555 55555555 00000000 00000000 0:000> 012b26a8 00555500 00555555 00555555 00555555 012b26b8 00555555 00555555 ff555555 ffffffff 012b26c8 ffffffff 00555555 00555555 00555555 012b26d8 00555555 00555555 00000000 55000000 012b26e8 55005500 55005500 55005500 55005500 012b26f8 55005500 55005500 55005500 55005500 012b2708 ffffffff ffffffff 5500ffff 55005500 012b2718 55005500 55005500 00000000 55000000 0:000> 012b2728 55005500 55005500 ffff5500 ffffffff 012b2738 55005500 55005500 55005500 5500ffff 012b2748 55005500 00005500 00000055 00000000 012b2758 55000055 55005500 55005500 55ffff00 012b2768 55005500 55005500 ffffffff ffffffff 012b2778 55005500 55005500 00550000 00000000 012b2788 00550000 55005500 ffff5500 ffffffff 012b2798 55005500 55005500 55005500 ffff5500 0:000> 012b27a8 ffffffff 55005500 00005500 00000055 012b27b8 00000000 55000055 55005500 55005500 012b27c8 55005500 55005500 55005500 ff005500 012b27d8 ffffffff 55ffffff 55005500 55005500 012b27e8 55005500 55005500 55005500 00000000 012b27f8 00000000 00555500 00555500 00555500 012b2808 00555500 00555500 00555500 00555500 012b2818 00555500 ffffffff ffffffff 0055ffff 0:000> 012b2828 00555500 00555500 00555500 00000000 012b2838 00000000 00555500 00555500 ffff5500 012b2848 ffffffff 00555500 00555500 00555500 012b2858 0055ffff 00555500 55555500 00000000 012b2868 00000000 00550000 00555500 00555500 012b2878 00ffff00 00555500 00555500 ffffff00 012b2888 ffffffff 00555500 00555500 00005500 012b2898 00000000 00000000 00555500 ff555500 0:000> 012b28a8 ffffffff 00555500 00555500 00555500 012b28b8 ffff5500 00ffffff 00555500 55555500 012b28c8 00000000 00000000 00550000 00555500 012b28d8 00555500 00555500 00555500 00555500 012b28e8 ff555500 ffffffff 00ffffff 00555500 012b28f8 00555500 00555500 00555500 00555500 012b2908 00000000 55000000 55550055 55550055 012b2918 55550055 55550055 55550055 55550055 0:000> 012b2928 55550055 55550055 ffffffff ffffffff 012b2938 5555ffff 55550055 55550055 55550055 012b2948 00000055 55550000 55550055 55550055 012b2958 ffff0055 ffffffff 55550055 55550055 012b2968 55550055 555500ff 55550055 55550055 012b2978 00005555 55000000 55555555 55550055 012b2988 55550055 55ffff55 55550055 55550055 012b2998 ffffff55 ffffffff 55550055 55550055 0:000> 012b29a8 55555555 00000000 55555500 55550055 012b29b8 ff550055 ffffffff 55550055 55550055 012b29c8 55550055 ffff0055 55ffffff 55550055 012b29d8 55550055 00005555 55000000 55555555 012b29e8 55550055 55550055 55550055 55550055 012b29f8 55550055 ff550055 ffffffff 55ffffff 012b2a08 55550055 55550055 55550055 55550055 012b2a18 55550055 00000000 55000000 55005500 0:000> 012b2a28 55005500 55005500 55005500 55005500 012b2a38 55005500 55005500 55005500 ffffffff 012b2a48 ffffffff 5500ffff 55005500 55005500 012b2a58 55005500 00000000 55000000 55005500 012b2a68 55005500 ff005500 ffffffff 55005500 012b2a78 55005500 ff005500 550055ff 55005500 012b2a88 00005500 00000055 00000000 55000055 012b2a98 55005500 55005500 55ffff00 55005500 0:000> 012b2aa8 55005500 ffff5500 ffffffff 55005500 012b2ab8 55005500 00550000 00000000 00550000 012b2ac8 55005500 ff005500 ffffffff 550055ff 012b2ad8 55005500 55005500 ffffff00 55ffffff 012b2ae8 55005500 00005500 00000055 00000000 012b2af8 55000055 55005500 55005500 55005500 012b2b08 55005500 55005500 ff005500 ffffffff 012b2b18 5500ffff 55005500 55005500 55005500 0:000> 012b2b28 55005500 55005500 00000000 55000000 012b2b38 55000055 55000055 55000055 55000055 012b2b48 55000055 55000055 55000055 55000055 012b2b58 ffffffff ffffffff 5500ffff 55000055 012b2b68 55000055 55000055 00000055 55000000 012b2b78 55000055 55000055 ff000055 ffffffff 012b2b88 550000ff 55000055 ff000055 550000ff 012b2b98 55000055 00000055 00005555 00000000 0:000> 012b2ba8 55005555 55000055 55000055 55ffff55 012b2bb8 55000055 55000055 ff000055 ffffffff 012b2bc8 55000055 55000055 55550055 00000000 012b2bd8 55550000 55000055 55000055 ffffffff 012b2be8 550000ff 55000055 55000055 ffffff55 012b2bf8 5500ffff 55000055 00000055 00005555 012b2c08 00000000 55005555 55000055 55000055 012b2c18 55000055 55000055 55000055 ffff0055 0:000> 012b2c28 ffffffff 5500ffff 55000055 55000055 012b2c38 55000055 55000055 55000055 00000000 012b2c48 00000000 00555555 00555555 00555555 012b2c58 00555555 00555555 00555555 00555555 012b2c68 00555555 ffffffff ffffffff 0055ffff 012b2c78 00555555 00555555 00555555 00005555 012b2c88 00555500 00555555 00555555 00555555 012b2c98 ffffffff 005555ff 00555555 ffff5555 0:000> 012b2ca8 00555555 00555555 55555555 00555500 012b2cb8 55550000 00555500 00555555 00555555 012b2cc8 00ffff55 00555555 00555555 00555555 012b2cd8 ffffffff 00555555 00555555 55005555 012b2ce8 00000055 55005555 00555555 00555555 012b2cf8 ffffff55 005555ff 00555555 00555555 012b2d08 ffffff55 005555ff 00555555 55555555 012b2d18 00555500 55550000 00555500 00555555 0:000> 012b2d28 00555555 00555555 00555555 00555555 012b2d38 ffff5555 ffffffff 005555ff 00555555 012b2d48 00555555 00555555 00555555 00555555 012b2d58 00000000 55000000 55005500 55005500 012b2d68 55005500 55005500 55005500 55005500 012b2d78 55005500 55005500 ffffffff ffffffff 012b2d88 5500ffff 55005500 55005500 55005500 012b2d98 00005500 55005500 55005500 55005500 0:000> 012b2da8 55005500 ffffff00 55ffffff 55005500 012b2db8 55ffff00 55005500 55005500 00005500 012b2dc8 00550055 00550000 55000055 55005500 012b2dd8 55005500 55ffff00 55005500 55005500 012b2de8 55005500 ffffff00 55005500 55005500 012b2df8 00550000 00000055 00550055 55005500 012b2e08 55005500 ffffff00 5500ffff 55005500 012b2e18 55005500 ffffffff 55005500 55005500 0:000> 012b2e28 00005500 00550055 00550000 55000055 012b2e38 55005500 55005500 55005500 55005500 012b2e48 55005500 ffff5500 ffffffff 55005500 012b2e58 55005500 55005500 55005500 55005500 012b2e68 55005500 00000000 00000000 00555500 012b2e78 00555500 00555500 00555500 00555500 012b2e88 00555500 00555500 00555500 ffffffff 012b2e98 ffffffff 0055ffff 00555500 00555500 0:000> 012b2ea8 00555500 00555500 00555500 00555500 012b2eb8 00555500 00555500 ffff5500 ffffffff 012b2ec8 ffffffff 0055ffff 00555500 00555500 012b2ed8 00555500 00555500 00555500 00555500 012b2ee8 00555500 00555500 ffffffff 00555500 012b2ef8 00555500 00555500 ffff5500 00555500 012b2f08 00555500 00555500 00555500 00555500 012b2f18 00555500 00555500 ff555500 00ffffff 0:000> 012b2f28 00555500 ff555500 00ffffff 00555500 012b2f38 00555500 00555500 00555500 00555500 012b2f48 00555500 00555500 00555500 00555500 012b2f58 00555500 00555500 ffffff00 ffffffff 012b2f68 00555500 00555500 00555500 00555500 012b2f78 00555500 00555500 00000000 55000000 012b2f88 55550055 55550055 55550055 55550055 012b2f98 55550055 55550055 55550055 55550055 0:000> 012b2fa8 ffffffff ffffffff 5555ffff 55550055 012b2fb8 55550055 55550055 55550055 55550055 012b2fc8 55550055 55550055 55550055 55550055 012b2fd8 ffffff55 55ffffff 55550055 55550055 012b2fe8 55550055 55550055 55550055 55550055 012b2ff8 55550055 55550055 ffff0055 ffffffff 012b3008 5555ffff 55550055 55550055 ffff0055 012b3018 55550055 55550055 55550055 55550055 0:000> 012b3028 55550055 55550055 55550055 55550055 012b3038 ffffffff 55550055 ffff0055 5555ffff 012b3048 55550055 55550055 55550055 55550055 012b3058 55550055 55550055 55550055 55550055 012b3068 55550055 55550055 55550055 ffffff55 012b3078 55ffffff 55550055 55550055 55550055 012b3088 55550055 55550055 55550055 00000000 012b3098 55000000 55005500 55005500 55005500 0:000> 012b30a8 55005500 55005500 55005500 55005500 012b30b8 55005500 ffffffff ffffffff 5500ffff 012b30c8 55005500 55005500 55005500 55005500 012b30d8 55005500 55005500 55005500 55005500 012b30e8 55005500 55005500 55005500 55005500 012b30f8 55005500 55005500 55005500 55005500 012b3108 55005500 55005500 55005500 55005500 012b3118 55005500 55005500 55005500 55005500 0:000> 012b3128 55005500 55005500 55005500 55005500 012b3138 55005500 55005500 55005500 55005500 012b3148 55005500 ff005500 ffffffff 55ffffff 012b3158 55005500 55005500 55005500 55005500 012b3168 55005500 55005500 55005500 55005500 012b3178 55005500 55005500 55005500 55005500 012b3188 ffffffff 5500ffff 55005500 55005500 012b3198 55005500 55005500 55005500 55005500 0:000> 012b31a8 00000000 55000000 55000055 55000055 012b31b8 55000055 55000055 55000055 55000055 012b31c8 55000055 55000055 ffffffff ffffffff 012b31d8 5500ffff 55000055 55000055 55000055 012b31e8 55000055 55000055 55000055 55000055 012b31f8 55000055 55000055 55000055 55000055 012b3208 55000055 55000055 55000055 55000055 012b3218 55000055 55000055 55000055 55000055 0:000> 012b3228 55000055 55000055 55000055 55000055 012b3238 55000055 55000055 55000055 55000055 012b3248 55000055 55000055 55000055 55000055 012b3258 55000055 55000055 55000055 55000055 012b3268 55000055 55000055 55000055 55000055 012b3278 55000055 55000055 55000055 55000055 012b3288 55000055 55000055 55000055 55000055 012b3298 ff000055 ffffffff 550000ff 55000055 0:000> 012b32a8 55000055 55000055 55000055 55000055 012b32b8 55000055 00000000 00000000 00555555 012b32c8 00555555 00555555 00555555 00555555 012b32d8 00555555 00555555 00555555 ffffffff 012b32e8 ffffffff 0055ffff 00555555 00555555 012b32f8 00555555 00555555 00555555 00555555 012b3308 00555555 00555555 00555555 00555555 012b3318 00555555 00555555 00555555 00555555 0:000> 012b3328 00555555 00555555 00555555 00555555 012b3338 00555555 00555555 00555555 00555555 012b3348 00555555 00555555 00555555 00555555 012b3358 00555555 00555555 00555555 00555555 012b3368 00555555 00555555 00555555 00555555 012b3378 00555555 00555555 00555555 00555555 012b3388 00555555 00555555 00555555 00555555 012b3398 00555555 00555555 00555555 00555555 0:000> 012b33a8 00555555 ff555555 ffffffff 00555555 012b33b8 00555555 00555555 00555555 00555555 012b33c8 00555555 00555555 00000000 55000000 012b33d8 55005500 55005500 55005500 55005500 012b33e8 55005500 55005500 55005500 55005500 012b33f8 ffffffff ffffffff 5500ffff 55005500 012b3408 55005500 55005500 55005500 55005500 012b3418 55005500 55005500 55005500 55005500 0:000> 012b3428 55005500 55005500 55005500 55005500 012b3438 55005500 55005500 55005500 55005500 012b3448 55005500 55005500 55005500 55005500 012b3458 55005500 55005500 55005500 55005500 012b3468 55005500 55005500 55005500 55005500 012b3478 55005500 55005500 55005500 55005500 012b3488 55005500 55005500 55005500 55005500 012b3498 55005500 55005500 55005500 55005500 0:000> 012b34a8 55005500 55005500 55005500 55005500 012b34b8 55005500 55005500 ffff5500 55ffffff 012b34c8 55005500 55005500 55005500 55005500 012b34d8 55005500 55005500 55005500 00000000 012b34e8 00000000 00555500 00555500 00555500 012b34f8 00555500 00555500 00555500 00555500 012b3508 00555500 ffffffff ffffffff 0055ffff 012b3518 00555500 00555500 00555500 00555500 0:000> 012b3528 00555500 00555500 00555500 00555500 012b3538 00555500 00555500 00555500 00555500 012b3548 00555500 00555500 00555500 00555500 012b3558 00555500 00555500 00555500 00555500 012b3568 00555500 00555500 00555500 00555500 012b3578 00555500 00555500 00555500 00555500 012b3588 00555500 00555500 00555500 00555500 012b3598 00555500 00555500 00555500 00555500 0:000> 012b35a8 00555500 00555500 00555500 00555500 012b35b8 00555500 00555500 00555500 00555500 012b35c8 00555500 00555500 00555500 ffffff00 012b35d8 005555ff 00555500 00555500 00555500 012b35e8 00555500 00555500 00555500 00555500 012b35f8 00000000 55000000 55550055 55550055 012b3608 55550055 55550055 55550055 55550055 012b3618 55550055 55550055 ffffffff ffffffff 0:000> 012b3628 5555ffff 55550055 55550055 55550055 012b3638 55550055 55550055 55550055 55550055 012b3648 55550055 55550055 55550055 55550055 012b3658 55550055 55550055 55550055 55550055 012b3668 55550055 55550055 55550055 55550055 012b3678 55550055 55550055 55550055 55550055 012b3688 55550055 55550055 55550055 55550055 012b3698 55550055 55550055 55550055 55550055 0:000> 012b36a8 55550055 55550055 55550055 55550055 012b36b8 55550055 55550055 55550055 55550055 012b36c8 55550055 55550055 55550055 55550055 012b36d8 55550055 55550055 55550055 55550055 012b36e8 ffffffff 55550055 55550055 55550055 012b36f8 55550055 55550055 55550055 55550055 012b3708 55550055 00000000 55000000 55005500 012b3718 55005500 55005500 55005500 55005500 0:000> 012b3728 55005500 55005500 55005500 ffffffff 012b3738 ffffffff 5500ffff 55005500 55005500 012b3748 55005500 55005500 55005500 55005500 012b3758 55005500 55005500 55005500 55005500 012b3768 55005500 55005500 55005500 55005500 012b3778 55005500 55005500 55005500 55005500 012b3788 55005500 55005500 55005500 55005500 012b3798 55005500 55005500 55005500 55005500 0:000> 012b37a8 55005500 55005500 55005500 55005500 012b37b8 55005500 55005500 55005500 55005500 012b37c8 55005500 55005500 55005500 55005500 012b37d8 55005500 55005500 55005500 55005500 012b37e8 55005500 55005500 55005500 55005500 012b37f8 55005500 55ffffff 55005500 55005500 012b3808 55005500 55ffff00 55005500 55005500 012b3818 55005500 55005500 00000000 55000000 0:000> 012b3828 55000055 55000055 55000055 55000055 012b3838 55000055 55000055 55000055 55000055 012b3848 ffffffff ffffffff 5500ffff 55000055 012b3858 55000055 55000055 55000055 55000055 012b3868 55000055 55000055 00000055 55000055 012b3878 55000055 55000055 55000055 55000055 012b3888 55000055 00000055 55000000 55000055 012b3898 55000055 55000055 55000055 55000055 0:000> 012b38a8 55000055 00000000 55000055 55000055 012b38b8 55000055 55000055 55000055 55000055 012b38c8 00000055 55000000 55000055 55000055 012b38d8 55000055 55000055 55000055 55000055 012b38e8 55000000 55000055 55000055 55000055 012b38f8 55000055 55000055 55000055 55000055 012b3908 55000055 ff000055 5500ffff 55000055 012b3918 55000055 55000055 5500ffff 55000055 0:000> 012b3928 55000055 55000055 55000055 00000000 012b3938 00000000 00555555 00555555 00555555 012b3948 00555555 00555555 00555555 00555555 012b3958 00555555 ffffffff ffffffff 0055ffff 012b3968 00555555 00555555 00555555 00555555 012b3978 00555555 00555555 00555555 00000000 012b3988 00550000 00555555 00555555 00555555 012b3998 00555555 00555555 00000055 00000000 0:000> 012b39a8 00555555 00555555 00555555 00555555 012b39b8 00555555 00555555 00000000 00555500 012b39c8 00555555 00555555 00555555 00555555 012b39d8 00555555 00000055 00000000 00555555 012b39e8 00555555 00555555 00555555 00555555 012b39f8 00555555 00000000 00555500 00555555 012b3a08 00555555 00555555 00555555 00555555 012b3a18 00555555 00555555 ffff5555 005555ff 0:000> 012b3a28 00555555 00555555 00555555 0055ffff 012b3a38 00555555 00555555 00555555 00555555 012b3a48 00000000 55000000 55005500 55005500 012b3a58 55005500 55005500 55005500 55005500 012b3a68 55005500 55005500 ffffffff ffffffff 012b3a78 5500ffff 55005500 55005500 55005500 012b3a88 55005500 55005500 55005500 00005500 012b3a98 00000000 55000000 55005500 55005500 0:000> 012b3aa8 55005500 55005500 55005500 00000000 012b3ab8 00000000 55005500 55005500 55005500 012b3ac8 55005500 55005500 00005500 00000000 012b3ad8 55000000 55005500 55005500 55005500 012b3ae8 55005500 00005500 00000000 00000000 012b3af8 55005500 55005500 55005500 55005500 012b3b08 55005500 00000000 00000000 55000000 012b3b18 55005500 55005500 55005500 55005500 0:000> 012b3b28 55005500 55005500 55005500 ffffff00 012b3b38 55005500 55005500 55005500 ff005500 012b3b48 5500ffff 55005500 55005500 55005500 012b3b58 55005500 00000000 00000000 00555500 012b3b68 00555500 00555500 00555500 00555500 012b3b78 00555500 00555500 00555500 ffffffff 012b3b88 ffffffff 0055ffff 00555500 00555500 012b3b98 00555500 00555500 00555500 00555500 0:000> 012b3ba8 00000000 00000000 00000000 00555500 012b3bb8 00555500 00555500 00555500 00005500 012b3bc8 00000000 00000000 00550000 00555500 012b3bd8 00555500 00555500 00555500 00000000 012b3be8 00000000 00000000 00555500 00555500 012b3bf8 00555500 00555500 00005500 00000000 012b3c08 00000000 00550000 00555500 00555500 012b3c18 00555500 00555500 00000000 00000000 0:000> 012b3c28 00000000 00555500 00555500 00555500 012b3c38 00555500 00555500 00555500 00555500 012b3c48 00ffffff 00555500 00555500 00555500 012b3c58 ffff5500 0055ffff 00555500 00555500 012b3c68 00555500 00555500 00000000 55000000 012b3c78 55550055 55550055 55550055 55550055 012b3c88 55550055 55550055 55550055 55550055 012b3c98 ffffffff ffffffff 5555ffff 55550055 0:000> 012b3ca8 55550055 55550055 55550055 55550055 012b3cb8 00550055 00000000 00000000 00000000 012b3cc8 55550000 55550055 55550055 55550055 012b3cd8 00000055 00000000 00000000 00000000 012b3ce8 55550055 55550055 55550055 00550055 012b3cf8 00000000 00000000 00000000 55550000 012b3d08 55550055 55550055 55550055 00000055 012b3d18 00000000 00000000 55000000 55550055 0:000> 012b3d28 55550055 55550055 00000055 00000000 012b3d38 00000000 00000000 55550000 55550055 012b3d48 55550055 55550055 55550055 55550055 012b3d58 ff550055 ffffffff ffffffff ffffffff 012b3d68 ffffffff ffffffff 555500ff 55550055 012b3d78 55550055 55550055 55550055 00000000 012b3d88 55000000 55005500 55005500 55005500 012b3d98 55005500 55005500 5500ff00 55005500 0:000> 012b3da8 55005500 ffffffff ffffffff 5500ffff 012b3db8 55005500 55005500 55005500 55005500 012b3dc8 55005500 00005500 00000000 00000000 012b3dd8 00000000 55000000 55005500 55005500 012b3de8 55005500 00000000 00000000 00000000 012b3df8 00000000 55005500 55005500 55005500 012b3e08 00000000 00000000 00000000 00000000 012b3e18 55000000 55005500 55005500 00005500 0:000> 012b3e28 00000000 55000000 00000000 00000000 012b3e38 55005500 55005500 55005500 00000000 012b3e48 00000000 00005500 00000000 55000000 012b3e58 55005500 55005500 55005500 55005500 012b3e68 55005500 ffff5500 ffffffff ffffffff 012b3e78 ffffffff ffffffff ffffffff 550055ff 012b3e88 55005500 55005500 55005500 55005500 012b3e98 00000000 55000000 55000055 55000055 0:000> 012b3ea8 55000055 55000055 ff000055 ffffffff 012b3eb8 55000055 55000055 ffffffff ffffffff 012b3ec8 5500ffff 55000055 55000055 55000055 012b3ed8 55000055 55000055 00000000 00000000 012b3ee8 55000000 00000000 00000000 55000000 012b3ef8 55000055 00000055 00000000 55000000 012b3f08 00000055 00000000 55000000 55000055 012b3f18 55000055 00000000 00000000 55000055 0:000> 012b3f28 00000000 00000000 55000055 55000055 012b3f38 00000055 00000000 55000000 00000055 012b3f48 00000000 55000000 55000055 55000055 012b3f58 00000000 00000000 00000055 00000000 012b3f68 00000000 55000055 55000055 55000055 012b3f78 55000055 55000055 ffffff55 ffffffff 012b3f88 ffffffff ffffffff ffffffff ffffffff 012b3f98 550000ff 55000055 55000055 55000055 0:000> 012b3fa8 55000055 00000000 00000000 00555555 012b3fb8 00555555 00555555 00555555 ffff5555 012b3fc8 ffffffff 005555ff 00555555 ffffffff 012b3fd8 ffffffff 0055ffff 00555555 00555555 012b3fe8 00555555 00555555 00555555 00000000 012b3ff8 00000000 00555555 00005555 00000000 012b4008 00550000 00555555 00000055 00000000 012b4018 00555500 00555555 00000000 00000000 0:000> 012b4028 00555555 00555555 00000000 00000000 012b4038 00555555 00000055 00000000 00550000 012b4048 00555555 00000000 00000000 00555500 012b4058 00555555 00000000 00000000 00555555 012b4068 00005555 00000000 00000000 00555555 012b4078 00000055 00000000 00555500 00555555 012b4088 00555555 00555555 00555555 ffffff55 012b4098 ffffffff ffffffff ffffffff ffffffff 0:000> 012b40a8 ffffffff 005555ff 00555555 00555555 012b40b8 00555555 00555555 00000000 55000000 012b40c8 55005500 55005500 55005500 55005500 012b40d8 ffffff00 ffffffff 5500ffff 55005500 012b40e8 ffffffff ffffffff 5500ffff 55005500 012b40f8 55005500 55005500 55005500 00005500 012b4108 00000000 55000000 55005500 00005500 012b4118 00000000 55000000 00005500 00000000 0:000> 012b4128 00000000 55005500 55005500 00000000 012b4138 00000000 55005500 00000000 00000000 012b4148 55000000 55005500 00005500 00000000 012b4158 55000000 00005500 00000000 55000000 012b4168 55005500 55005500 00000000 00000000 012b4178 55005500 00000000 00000000 55005500 012b4188 55005500 00005500 00000000 55000000 012b4198 55005500 55005500 55005500 55005500 0:000> 012b41a8 ffffffff ffffffff ffffffff ffffffff 012b41b8 ffffffff ffffffff 550055ff 55005500 012b41c8 55005500 55005500 55005500 00000000 012b41d8 00000000 00555500 00555500 00555500 012b41e8 00555500 ffffff00 ffffffff 0055ffff 012b41f8 00555500 ffffffff ffffffff 005555ff 012b4208 00555500 00555500 00555500 00555500 012b4218 00000000 00000000 00555500 00555500 0:000> 012b4228 00555500 00000000 00000000 00005500 012b4238 00000000 00550000 00555500 00555500 012b4248 00005500 00000000 00000000 00000000 012b4258 00000000 00555500 00555500 00555500 012b4268 00000000 00000000 00005500 00000000 012b4278 00550000 00555500 00555500 00005500 012b4288 00000000 00550000 00000000 00000000 012b4298 00555500 00555500 00555500 00000000 0:000> 012b42a8 00000000 00555500 00555500 00555500 012b42b8 ff555500 ffffffff ffffffff ffffffff 012b42c8 ffffffff ffffffff ffffffff 00555500 012b42d8 00555500 00555500 00555500 00555500 012b42e8 00000000 55000000 55550055 55550055 012b42f8 55550055 55550055 ffffff55 ffffffff 012b4308 5555ffff 55550055 ffffffff ffffffff 012b4318 555500ff 55550055 55550055 55550055 0:000> 012b4328 00550055 00000000 55000000 55550055 012b4338 55550055 55550055 00000055 00000000 012b4348 00000000 00000000 55550000 55550055 012b4358 55550055 55550055 00000000 00000000 012b4368 00000000 55000000 55550055 55550055 012b4378 55550055 00000055 00000000 00000000 012b4388 00000000 55550000 55550055 55550055 012b4398 00550055 00000000 00000000 00000000 0:000> 012b43a8 55550000 55550055 55550055 55550055 012b43b8 00000055 00000000 55550000 55550055 012b43c8 55550055 ffff0055 ffffffff ffffffff 012b43d8 ffffffff ffffffff ffffffff ffffffff 012b43e8 55550055 55550055 55550055 55550055 012b43f8 55550055 00000000 55000000 55005500 012b4408 55005500 55005500 55005500 ffffff00 012b4418 ffffffff 5500ffff 55005500 ffffffff 0:000> 012b4428 ffffffff 550055ff 55005500 55005500 012b4438 55005500 00000000 00000000 55000000 012b4448 55005500 55005500 55005500 00005500 012b4458 00000000 00000000 00000000 55005500 012b4468 55005500 55005500 55005500 00000000 012b4478 00000000 00000000 55005500 55005500 012b4488 55005500 55005500 00005500 00000000 012b4498 00000000 55000000 55005500 55005500 0:000> 012b44a8 55005500 55005500 00000000 00000000 012b44b8 00000000 55005500 55005500 55005500 012b44c8 55005500 00005500 00000000 55000000 012b44d8 55005500 55005500 ffffff00 ffffffff 012b44e8 ffffffff ffffffff ffffffff ffffffff 012b44f8 ffffffff 55005500 55005500 55005500 012b4508 55005500 55005500 00000000 55000000 012b4518 55000055 55000055 55000055 55000055 0:000> 012b4528 ffff0055 ffffffff 550000ff 55000055 012b4538 ffffffff ffffffff 55000055 55000055 012b4548 55000055 55000055 00000055 00000000 012b4558 55000055 55000055 55000055 55000055 012b4568 55000055 00000055 00000000 55000000 012b4578 55000055 55000055 55000055 55000055 012b4588 00000055 00000000 00000000 55000055 012b4598 55000055 55000055 55000055 55000055 0:000> 012b45a8 00000000 00000000 55000000 55000055 012b45b8 55000055 55000055 55000055 00000055 012b45c8 00000000 00000000 55000055 55000055 012b45d8 55000055 55000055 55000055 00000000 012b45e8 55000000 55000055 55000055 ffffff55 012b45f8 ffffffff ffffffff ffffffff ffffffff 012b4608 ffffffff ffffffff 55000055 55000055 012b4618 55000055 55000055 55000055 00000000 0:000> 012b4628 00000000 00555555 00555555 00555555 012b4638 00555555 ffff5555 ffffffff 00555555 012b4648 00555555 ffffffff 00ffffff 00555555 012b4658 00555555 00555555 00555555 00000055 012b4668 00000000 00555555 00555555 00555555 012b4678 00555555 00555555 00005555 00000000 012b4688 00555500 00555555 00555555 00555555 012b4698 00555555 00555555 00000000 00000000 0:000> 012b46a8 00555555 00555555 00555555 00555555 012b46b8 00555555 00005555 00000000 00555555 012b46c8 00555555 00555555 00555555 00555555 012b46d8 00555555 00000000 00550000 00555555 012b46e8 00555555 00555555 00555555 00555555 012b46f8 00000055 00000000 00555555 00555555 012b4708 00555555 00555555 00555555 00555555 012b4718 00555555 00555555 00555555 00555555 0:000> 012b4728 00555555 00555555 00555555 00555555 012b4738 00000000 55000000 55005500 55005500 012b4748 55005500 55005500 ff005500 ffffffff 012b4758 55005500 ff005500 ffffffff 55ffffff 012b4768 55005500 55005500 55005500 55005500 012b4778 00005500 55000000 55005500 55005500 012b4788 55005500 55005500 55005500 00005500 012b4798 55000000 55005500 55005500 55005500 0:000> 012b47a8 55005500 55005500 55005500 00000000 012b47b8 55005500 55005500 55005500 55005500 012b47c8 55005500 55005500 00005500 55000000 012b47d8 55005500 55005500 55005500 55005500 012b47e8 55005500 55005500 00000000 55005500 012b47f8 55005500 55005500 55005500 55005500 012b4808 55005500 00005500 55000000 55005500 012b4818 55005500 55005500 55005500 55005500 0:000> 012b4828 55005500 55005500 55005500 55005500 012b4838 55005500 55005500 55005500 55005500 012b4848 55005500 00000000 00000000 00555500 012b4858 00555500 00555500 00555500 00555500 012b4868 ffffffff 005555ff ffff5500 ffffffff 012b4878 005555ff 00555500 00555500 00555500 012b4888 00555500 00005500 00555500 00555500 012b4898 00555500 00555500 00555500 00555500 0:000> 012b48a8 00555500 00550000 00555500 00555500 012b48b8 00555500 00555500 00555500 00555500 012b48c8 00555500 00555500 00555500 00555500 012b48d8 00555500 00555500 00555500 00555500 012b48e8 00550000 00555500 00555500 00555500 012b48f8 00555500 00555500 00555500 00005500 012b4908 00555500 00555500 00555500 00555500 012b4918 00555500 00555500 00555500 00550000 0:000> 012b4928 00555500 00555500 00555500 00555500 012b4938 00555500 00555500 00555500 00555500 012b4948 00555500 00555500 00555500 00555500 012b4958 00555500 00555500 00000000 55000000 012b4968 55550055 55550055 55550055 55550055 012b4978 55550055 ffffff55 ffffffff ffffffff 012b4988 ffffffff 55550055 55550055 55550055 012b4998 55550055 55550055 55550055 55550055 0:000> 012b49a8 55550055 55550055 55550055 55550055 012b49b8 55550055 55550055 55550055 55550055 012b49c8 55550055 55550055 55550055 55550055 012b49d8 55550055 55550055 55550055 55550055 012b49e8 55550055 55550055 55550055 55550055 012b49f8 55550055 55550055 55550055 55550055 012b4a08 55550055 55550055 55550055 55550055 012b4a18 55550055 55550055 55550055 55550055 0:000> 012b4a28 55550055 55550055 55550055 55550055 012b4a38 55550055 55550055 55550055 55550055 012b4a48 55550055 55550055 55550055 55550055 012b4a58 55550055 55550055 55550055 55550055 012b4a68 55550055 55550055 55550055 00000000 012b4a78 55000000 55005500 55005500 55005500 012b4a88 55005500 55005500 55005500 ffffffff 012b4a98 ffffffff 550055ff 55005500 55005500 0:000> 012b4aa8 55005500 55005500 55005500 55005500 012b4ab8 55005500 55005500 55005500 55005500 012b4ac8 55005500 55005500 55005500 55005500 012b4ad8 55005500 55005500 55005500 55005500 012b4ae8 55005500 55005500 55005500 55005500 012b4af8 55005500 55005500 55005500 55005500 012b4b08 55005500 55005500 55005500 55005500 012b4b18 55005500 55005500 55005500 55005500 0:000> 012b4b28 55005500 55005500 55005500 55005500 012b4b38 55005500 55005500 55005500 55005500 012b4b48 55005500 55005500 55005500 55005500 012b4b58 55005500 55005500 55005500 55005500 012b4b68 55005500 55005500 55005500 55005500 012b4b78 55005500 55005500 55005500 55005500 012b4b88 00000000 55000000 55000055 55000055 012b4b98 55000055 55000055 55000055 55000055 0:000> 012b4ba8 55000055 55000055 55000055 55000055 012b4bb8 55000055 55000055 55000055 55000055 012b4bc8 55000055 55000055 55000055 55000055 012b4bd8 55000055 55000055 55000055 55000055 012b4be8 55000055 55000055 55000055 55000055 012b4bf8 55000055 55000055 55000055 55000055 012b4c08 55000055 55000055 55000055 55000055 012b4c18 55000055 55000055 55000055 55000055 0:000> 012b4c28 55000055 55000055 55000055 55000055 012b4c38 55000055 55000055 55000055 55000055 012b4c48 55000055 55000055 55000055 55000055 012b4c58 55000055 55000055 55000055 55000055 012b4c68 55000055 55000055 55000055 55000055 012b4c78 55000055 55000055 55000055 55000055 012b4c88 55000055 55000055 55000055 55000055 012b4c98 55000055 00000000 00000000 00555555 0:000> 012b4ca8 00555555 00555555 00555555 00555555 012b4cb8 00555555 00555555 00555555 00555555 012b4cc8 00555555 00555555 00555555 00555555 012b4cd8 00555555 00555555 00555555 00555555 012b4ce8 00555555 00555555 00555555 00555555 012b4cf8 00555555 00555555 00555555 00555555 012b4d08 00555555 00555555 00555555 00555555 012b4d18 00555555 00555555 00555555 00555555 0:000> 012b4d28 00555555 00555555 00555555 00555555 012b4d38 00555555 00555555 00555555 00555555 012b4d48 00555555 00555555 00555555 00555555 012b4d58 00555555 00555555 00555555 00555555 012b4d68 00555555 00555555 00555555 00555555 012b4d78 00555555 00555555 00555555 00555555 012b4d88 00555555 00555555 00555555 00555555 012b4d98 00555555 00555555 00555555 00555555 0:000> 012b4da8 00555555 00555555 00000000 55000000 012b4db8 55005500 55005500 55005500 55005500 012b4dc8 55005500 55005500 55005500 55005500 012b4dd8 55005500 55005500 55005500 55005500 012b4de8 55005500 55005500 55005500 55005500 012b4df8 55005500 55005500 55005500 55005500 012b4e08 55005500 55005500 55005500 55005500 012b4e18 55005500 55005500 55005500 55005500 0:000> 012b4e28 55005500 55005500 55005500 55005500 012b4e38 55005500 55005500 55005500 55005500 012b4e48 55005500 55005500 55005500 55005500 012b4e58 55005500 55005500 55005500 55005500 012b4e68 55005500 55005500 55005500 55005500 012b4e78 55005500 55005500 55005500 55005500 012b4e88 55005500 55005500 55005500 55005500 012b4e98 55005500 55005500 55005500 55005500 0:000> 012b4ea8 55005500 55005500 55005500 55005500 012b4eb8 55005500 55005500 55005500 00000000 012b4ec8 00000000 00555500 00555500 00555500 012b4ed8 00555500 00555500 00555500 00555500 012b4ee8 00555500 00555500 00555500 00555500 012b4ef8 00555500 00555500 00555500 00555500 012b4f08 00555500 00555500 00555500 00555500 012b4f18 00555500 00555500 00555500 00555500 0:000> 012b4f28 00555500 00555500 00555500 00555500 012b4f38 00555500 00555500 00555500 00555500 012b4f48 00555500 00555500 00555500 00555500 012b4f58 00555500 00555500 00555500 00555500 012b4f68 00555500 00555500 00555500 00555500 012b4f78 00555500 00555500 00555500 00555500 012b4f88 00555500 00555500 00555500 00555500 012b4f98 00555500 00555500 00555500 00555500 0:000> 012b4fa8 00555500 00555500 00555500 00555500 012b4fb8 00555500 00555500 00555500 00555500 012b4fc8 00555500 00555500 00555500 00555500 012b4fd8 00000000 55000000 55550055 55550055 012b4fe8 55550055 55550055 55550055 55550055 012b4ff8 55550055 55550055 55550055 55550055 012b5008 55550055 55550055 55550055 55550055 012b5018 55550055 55550055 55550055 55550055 0:000> 012b5028 55550055 55550055 55550055 55550055 012b5038 55550055 55550055 55550055 55550055 012b5048 55550055 55550055 55550055 55550055 012b5058 55550055 55550055 55550055 55550055 012b5068 55550055 55550055 55550055 55550055 012b5078 55550055 55550055 55550055 55550055 012b5088 55550055 55550055 55550055 55550055 012b5098 55550055 55550055 55550055 55550055 0:000> 012b50a8 55550055 55550055 55550055 55550055 012b50b8 55550055 55550055 55550055 55550055 012b50c8 55550055 55550055 55550055 55550055 012b50d8 55550055 55550055 55550055 55550055 012b50e8 55550055 00000000 55000000 55005500 012b50f8 55005500 55005500 55005500 55005500 012b5108 55005500 55005500 55005500 55005500 012b5118 55005500 55005500 55005500 55005500 0:000> 012b5128 55005500 55005500 55005500 55005500 012b5138 55005500 55005500 55005500 55005500 012b5148 55005500 55005500 55005500 55005500 012b5158 55005500 55005500 55005500 55005500 012b5168 55005500 55005500 55005500 55005500 012b5178 55005500 55005500 55005500 55005500 012b5188 55005500 55005500 55005500 55005500 012b5198 55005500 55005500 55005500 55005500 0:000> 012b51a8 55005500 55005500 55005500 55005500 012b51b8 55005500 55005500 55005500 55005500 012b51c8 55005500 55005500 55005500 55005500 012b51d8 55005500 55005500 55005500 55005500 012b51e8 55005500 55005500 55005500 55005500 012b51f8 55005500 55005500 00000000 55000000 012b5208 55000055 55000055 55000055 55000055 012b5218 55000055 55000055 55000055 55000055 0:000> 012b5228 55000055 55000055 55000055 55000055 012b5238 55000055 55000055 55000055 55000055 012b5248 55000055 55000055 55000055 55000055 012b5258 55000055 55000055 55000055 55000055 012b5268 55000055 55000055 55000055 55000055 012b5278 55000055 55000055 55000055 55000055 012b5288 55000055 55000055 55000055 55000055 012b5298 55000055 55000055 55000055 55000055 0:000> 012b52a8 55000055 55000055 55000055 55000055 012b52b8 55000055 55000055 55000055 55000055 012b52c8 55000055 55000055 55000055 55000055 012b52d8 55000055 55000055 55000055 55000055 012b52e8 55000055 55000055 55000055 55000055 012b52f8 55000055 55000055 55000055 55000055 012b5308 55000055 55000055 55000055 00000000 012b5318 00000000 00555555 00555555 00555555 0:000> 012b5328 00555555 00555555 00555555 00555555 012b5338 00555555 00555555 00555555 00555555 012b5348 00555555 00555555 00555555 00555555 012b5358 00555555 00555555 00555555 00555555 012b5368 00555555 00555555 00555555 00555555 012b5378 00555555 00555555 00555555 00555555 012b5388 00555555 00555555 00555555 00555555 012b5398 00555555 00555555 00555555 00555555 0:000> 012b53a8 00555555 00555555 00555555 00555555 012b53b8 00555555 00555555 00555555 00555555 012b53c8 00555555 00555555 00555555 00555555 012b53d8 00555555 00555555 00555555 00555555 012b53e8 00555555 00555555 00555555 00555555 012b53f8 00555555 00555555 00555555 00555555 012b5408 00555555 00555555 00555555 00555555 012b5418 00555555 00555555 00555555 00555555 0:000> 012b5428 00000000 55000000 55005500 55005500 012b5438 55005500 55005500 55005500 55005500 012b5448 55005500 55005500 55005500 55005500 012b5458 55005500 55005500 55005500 55005500 012b5468 55005500 55005500 55005500 55005500 012b5478 55005500 55005500 55005500 55005500 012b5488 55005500 55005500 55005500 55005500 012b5498 55005500 55005500 55005500 55005500 0:000> 012b54a8 55005500 55005500 55005500 55005500 012b54b8 55005500 55005500 55005500 55005500 012b54c8 55005500 55005500 55005500 55005500 012b54d8 55005500 55005500 55005500 55005500 012b54e8 55005500 55005500 55005500 55005500 012b54f8 55005500 55005500 55005500 55005500 012b5508 55005500 55005500 55005500 55005500 012b5518 55005500 55005500 55005500 55005500 0:000> 012b5528 55005500 55005500 55005500 55005500 012b5538 55005500 00000000 00000000 00555500 012b5548 00555500 00555500 00555500 00555500 012b5558 00555500 00555500 00555500 00555500 012b5568 00555500 00555500 00555500 00555500 012b5578 00555500 00555500 00555500 00555500 012b5588 00555500 00555500 00555500 00555500 012b5598 00555500 00555500 00555500 00555500 0:000> 012b55a8 00555500 00555500 00555500 00555500 012b55b8 00555500 00555500 00555500 00555500 012b55c8 00555500 00555500 00555500 00555500 012b55d8 00555500 00555500 00555500 00555500 012b55e8 00555500 00555500 00555500 00555500 012b55f8 00555500 00555500 00555500 00555500 012b5608 00555500 00555500 00555500 00555500 012b5618 00555500 00555500 00555500 00555500 0:000> 012b5628 00555500 00555500 00555500 00555500 012b5638 00555500 00555500 00555500 00555500 012b5648 00555500 00555500 00000000 55000000 012b5658 55550055 55550055 55550055 55550055 012b5668 55550055 55550055 55550055 55550055 012b5678 55550055 55550055 55550055 55550055 012b5688 55550055 55550055 55550055 55550055 012b5698 55550055 55550055 55550055 55550055 0:000> 012b56a8 55550055 55550055 55550055 55550055 012b56b8 55550055 55550055 55550055 55550055 012b56c8 55550055 55550055 55550055 55550055 012b56d8 55550055 55550055 55550055 55550055 012b56e8 55550055 55550055 55550055 55550055 012b56f8 55550055 55550055 55550055 55550055 012b5708 55550055 55550055 55550055 55550055 012b5718 55550055 55550055 55550055 55550055 0:000> 012b5728 55550055 55550055 55550055 55550055 012b5738 55550055 55550055 55550055 55550055 012b5748 55550055 55550055 55550055 55550055 012b5758 55550055 55550055 55550055 00000000 012b5768 55000000 55005500 55005500 55005500 012b5778 55005500 55005500 55005500 55005500 012b5788 55005500 55005500 55005500 55005500 012b5798 55005500 55005500 55005500 55005500 0:000> 012b57a8 55005500 55005500 55005500 55005500 012b57b8 55005500 55005500 55005500 55005500 012b57c8 55005500 55005500 55005500 55005500 012b57d8 55005500 55005500 55005500 55005500 012b57e8 55005500 55005500 55005500 55005500 012b57f8 55005500 55005500 55005500 55005500 012b5808 55005500 55005500 55005500 55005500 012b5818 55005500 55005500 55005500 55005500 0:000> 012b5828 55005500 55005500 55005500 55005500 012b5838 55005500 55005500 55005500 55005500 012b5848 55005500 55005500 55005500 55005500 012b5858 55005500 55005500 55005500 55005500 012b5868 55005500 55005500 55005500 55005500 012b5878 00000000 55000000 55000055 55000055 012b5888 55000055 55000055 55000055 55000055 012b5898 55000055 55000055 55000055 55000055 0:000> 012b58a8 55000055 55000055 55000055 55000055 012b58b8 55000055 55000055 55000055 55000055 012b58c8 55000055 55000055 55000055 55000055 012b58d8 55000055 55000055 55000055 55000055 012b58e8 55000055 55000055 55000055 55000055 012b58f8 55000055 55000055 55000055 55000055 012b5908 55000055 55000055 55000055 55000055 012b5918 55000055 55000055 55000055 55000055 0:000> 012b5928 55000055 55000055 55000055 55000055 012b5938 55000055 55000055 55000055 55000055 012b5948 55000055 55000055 55000055 55000055 012b5958 55000055 55000055 55000055 55000055 012b5968 55000055 55000055 55000055 55000055 012b5978 55000055 55000055 55000055 55000055 012b5988 55000055 00000000 00000000 00000000 012b5998 00000000 00000000 00000000 00000000 0:000> 012b59a8 00000000 00000000 00000000 00000000 012b59b8 00000000 00000000 00000000 00000000 012b59c8 00000000 00000000 00000000 00000000 012b59d8 00000000 00000000 00000000 00000000 012b59e8 00000000 00000000 00000000 00000000 012b59f8 00000000 00000000 00000000 00000000 012b5a08 00000000 00000000 00000000 00000000 012b5a18 00000000 00000000 00000000 00000000 0:000> 012b5a28 00000000 00000000 00000000 00000000 012b5a38 00000000 00000000 00000000 00000000 012b5a48 00000000 00000000 00000000 00000000 012b5a58 00000000 00000000 00000000 00000000 012b5a68 00000000 00000000 00000000 00000000 012b5a78 00000000 00000000 00000000 00000000 012b5a88 00000000 00000000 00000000 00000000 012b5a98 00000000 00000000 00000000 00000000 0:000> 012b5aa8 00000000 00000000 00000000 00000000 012b5ab8 00000000 00000000 00000000 00000000 012b5ac8 00000000 00000000 00000000 00000000 012b5ad8 00000000 00000000 00000000 00000000 012b5ae8 00000000 00000000 00000000 00000000 012b5af8 00000000 00000000 00000000 00000000 012b5b08 00000000 00000000 00000000 00000000 012b5b18 00000000 00000000 00000000 00000000 0:000> 012b5b28 00000000 00000000 00000000 00000000 012b5b38 00000000 00000000 00000000 00000000 012b5b48 00000000 00000000 00000000 00000000 012b5b58 00000000 00000000 00000000 00000000 012b5b68 00000000 00000000 00000000 00000000 012b5b78 00000000 00000000 00000000 00000000 012b5b88 00000000 00000000 00000000 00000000 012b5b98 00000000 00000000 00000000 00000000 0:000> 012b5ba8 00000000 00000000 00000000 00000000 012b5bb8 00000000 00000000 00000000 00000000 012b5bc8 00000000 00000000 00000000 00000000 012b5bd8 00000000 00000000 00000000 00000000 012b5be8 00000000 00000000 00000000 00000000 012b5bf8 00000000 00000000 00000000 00000000 012b5c08 00000000 00000000 00000000 00000000 012b5c18 00000000 00000000 00000000 00000000 0:000> 012b5c28 00000000 00000000 00000000 00000000 012b5c38 00000000 00000000 00000000 00000000 012b5c48 00000000 00000000 00000000 00000000 012b5c58 00000000 00000000 00000000 00000000 012b5c68 00000000 00000000 00000000 00000000 012b5c78 00000000 00000000 00000000 00000000 012b5c88 00000000 00000000 00000000 00000000 012b5c98 00000000 00000000 00000000 00000000 0:000> 012b5ca8 00000000 00000000 00000000 00000000 012b5cb8 00000000 00000000 00000000 00000000 012b5cc8 00000000 00200b16 00eb7e38 02216808 012b5cd8 00200898 01354828 00000000 00000000 012b5ce8 02214018 012b5d48 00000000 000002c2 012b5cf8 000000d5 0000012b 0118cd08 00000000 012b5d08 00000000 00000040 00000000 00000000 012b5d18 00000000 00000000 00000000 00000000 0:000> 012b5d28 02216830 c7c34f80 c7c34f80 c7c34f80 012b5d38 c7c34f80 00000000 00000000 002004ba 012b5d48 00000000 02216894 012b5e64 012b5cdc 012b5d58 00000056 00200470 00000000 022168ac 012b5d68 022168bc 0020052e 00e66248 00e63b70 012b5d78 00000000 011a0648 00e63b60 00200546 012b5d88 00e6609c 00e64e10 00000001 4061c71c 012b5d98 c7c34f80 c7c34f80 00200882 01353ec0 0:000> 012b5da8 00000000 00000000 02214018 012b5e64 012b5db8 00000000 000002c2 0000012b 00000137 012b5dc8 0118cd08 00000000 00000000 00000040 012b5dd8 00000000 00000000 00000000 00000000 012b5de8 00000000 00000000 012b5e10 c7c34f80 012b5df8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b5e08 c7c34f80 00200a3c 01340ff0 00000000 012b5e18 00000000 012b5da4 00000000 00000000 0:000> 012b5e28 000002c2 0000012b 00000137 0118cd08 012b5e38 00000000 00000000 00000040 00000000 012b5e48 00000000 00000000 00000000 00000052 012b5e58 00000000 00000000 002004ba 00000000 012b5e68 012b5d48 012b6118 012b5da4 0000000c 012b5e78 00200470 00000000 022168cc 022168bc 012b5e88 00200332 012b5e94 00000001 022168dc 012b5e98 00200470 00000000 0119e8cc 012b5eac 0:000> 012b5ea8 00200470 00000000 022168e8 012b5ebc 012b5eb8 00200470 00000000 022168dc 00000000 012b5ec8 00200470 00000000 012b5e9c 012b5e7c 012b5ed8 0020052e 00e66248 00e63b70 00000000 012b5ee8 011a0648 00e63b60 00200546 00e6609c 012b5ef8 00e63c80 00000001 c7c34f80 00000000 012b5f08 00000000 00200546 00e6609c 00e63900 012b5f18 00000000 c7c34f80 c7c34f80 c7c34f80 0:000> 012b5f28 00200470 00000000 022168dc 012b5ecc 012b5f38 00200470 00000000 022168dc 00000000 012b5f48 0020052e 00e66248 00e63b70 00000000 012b5f58 011a0648 00e63b60 00200548 00e6607c 012b5f68 00e64e10 00000001 022168dc 00200544 012b5f78 00e660bc 00e64564 00000000 40000000 012b5f88 00200544 00e660bc 00e64578 00000000 012b5f98 00000000 00200532 00e661e4 00e6458c 0:000> 012b5fa8 00000000 00000000 00200532 00e661e4 012b5fb8 00e645a4 00000000 00000001 00200532 012b5fc8 00e661e4 00e645b8 00000000 00000000 012b5fd8 00200534 01341518 00e64e10 00000000 012b5fe8 012b5ff8 00000001 00000001 00200540 012b5ff8 012b6000 00000003 012b5fa0 012b5fb4 012b6008 012b5fc8 00200548 00e6607c 00e6418c 012b6018 00000000 00000000 002008a0 01354e98 0:000> 012b6028 00000000 00000000 012b60ac 00000000 012b6038 00000000 000002c2 00000137 00000151 012b6048 0118cd08 00000000 00000000 00000040 012b6058 00000000 00000000 00000000 00000000 012b6068 022168dc 00000007 0119ff40 3f349f4a 012b6078 00000000 00000002 00000000 3f000000 012b6088 3f000000 000000b8 0000020a 00000137 012b6098 00000151 000000b8 0000014c 00000000 0:000> 012b60a8 00200898 01354828 00000000 00000000 012b60b8 02214018 012b6118 00000000 000002c2 012b60c8 00000137 00000151 0118cd08 00000000 012b60d8 00000000 00000040 00000000 00000000 012b60e8 00000000 00000000 00000000 00000000 012b60f8 012b6024 c7c34f80 c7c34f80 c7c34f80 012b6108 c7c34f80 00000000 00000000 002004ba 012b6118 00000000 012b5e64 012b6234 012b60ac 012b6128 0000001a 00200470 00000000 022168f8 012b6138 022168bc 0020052e 00e66248 00e63b70 012b6148 00000000 011a0648 00e63b60 00200546 012b6158 00e6609c 00e64e10 00000001 4061c71c 012b6168 c7c34f80 c7c34f80 00200882 01353ec0 012b6178 00000000 00000000 02214018 012b6234 012b6188 00000000 000002c2 00000151 0000015d 012b6198 0118cd08 00000000 00000000 00000040 012b61a8 00000000 00000000 00000000 00000000 012b61b8 00000000 00000000 012b61e0 c7c34f80 012b61c8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b61d8 c7c34f80 00200a3c 01340ff0 00000000 012b61e8 00000000 012b6174 00000000 00000000 012b61f8 000002c2 00000151 0000015d 0118cd08 012b6208 00000000 00000000 00000040 00000000 012b6218 00000000 00000000 00000000 00000052 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 3 17:45:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Sep 2009 15:45:39 +0000 Subject: [M3devel] some data on Juno crash on Win32 In-Reply-To: <20090903154436.w1aooqqaskg4scg4@mail.elegosoft.com> References: <20090903154436.w1aooqqaskg4scg4@mail.elegosoft.com> Message-ID: This is on NT. Posix often hangs. If I blow up the initial heap size by a factor of 100, to avoid any garbage collection occuring, the crashes and hangs go away. NT then just fails assertions. I think @M3nogc causes the same thing. So, duh, I think something is trashing the heap. Maybe the gui code. - Jay > Date: Thu, 3 Sep 2009 15:44:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] some data on Juno crash on Win32 > > Quoting Jay K : > > > summary: 5.7.0 and 5.7.1 of unknown date: > > > > both always fail > > > > 5.7.0 always fails an assert (various?) > > > > 5.7.1 sometimes fails an assert (various) > > > > 5.7.1 sometimes access violates, always on address 00200000, plus or minus 4. > > > > Current source always access violates, same address. > > > > Since 5.7.1 and current source always access violate (aka SIGSEGV) > > on the same > > location, every run, I'm more inclined to look at this. > > This is all on Windows/NT386, isn't it? Or on POSIX platforms, too? > I seem to remember that Juno always crashed on a PaintBrush operation > on Windows, while the various mentor applications crashed at > different points, but all relating to insufficient Trestle/Win > support. > > On POSIX platforms both applications always ran OK AFAIR. > > Olaf > > > And then hope everything else is "the same" problem. > > > > But of course there might be multiple problems. > > > > It might be good to check for the hang in various from > > http://www.opencm3.net/uploaded-archives/index.html. > > > > Also see what all we can get from > > http://www.opencm3.net/snaps/snapshot-index.html. > > > > I'm going to see if I can get the index update with the many files I > > noticed in the file system. > > The same file name pattern for all files would help here. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Sep 3 20:32:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 03 Sep 2009 20:32:27 +0200 Subject: [M3devel] RC3, RC4? Message-ID: <20090903203227.smcanrumcgo84w4o@mail.elegosoft.com> Hi again, I'm about to leave for my holidays and will be back again on September 22. I probably won't be able to check my email for about two weeks, nor will I further the CM3 release engineering in this time. For 5.8 RC3, packages for most target platforms have been built and are available on www.opencm3.net. But there is a possibly critical problem described in ticket #1070, which may make it necessary to rebuild all packages (which should then be named RC4). I trust that Jay and Tony and anybody else who is interested track down the problem and fix it, and update tickets and roadmap at https://projects.elego.de/cm3/roadmap appropriately. I hope to see a usable set of packages at my return :-) I'll have a look at my mail again later tonight and tomorrow morning, but won't do much more concerning CM3 now. If anybody wants to go on and build RC4, here is what should be done: 1. Apply the tag release_CM3_5_8_RC4 to an appropriate and consistent configuration in CVS containing all needed fixes. 2. Update cm3/scripts/version to 5.8.4 etc. 3. Insert the tag as default into scripts/make-dist.sh (optional). 4. Build installation packages on all target platforms, most easily done via the makedist-jobs in http://hudson.modula3.com:8080/view/makedist/. 5. When the packages are available, they should be tested with http://hudson.modula3.com:8080/view/test-install/. Of course, all regression test results available at http://hudson.modula3.com:8080/ should be examined before the build. 6. Update the release documentation in cm3/www/releng and cm3/www and install this on birch.elegosoft.com. If anybody needs access to Hudson or Trac, please refer to admins at elego.de; Kay, Mike or Michael will help you. That's it for now, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Sep 4 04:02:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 02:02:47 +0000 Subject: [M3devel] This is a pixmap? Message-ID: Trying again due to truncation. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: This is a pixmap? Date: Thu, 3 Sep 2009 15:44:17 +0000 Does this look like a pixmap to anyone? This is the parameter to Win32 Join. PROCEDURE Join(t: T): REFANY = VAR res: REFANY; BEGIN LOCK threadMu DO IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; WHILE NOT t.completed DO Wait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; t.cond := NIL; IF perfOn THEN PerfChanged(t.id, State.dead) END; END; RETURN res; END Join; Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. t is at @ebp + here. The pointer then is 00200000 at the start of the second line of the second dump. If we can confirm this is pixmap, we can hunt more around in the gui code. 0:000> dd @ebp+8 0012f964 012ac6a8 02827bf4 02827974 02824c3c 0012f974 02829c40 02829c40 0012f98c 00000006 0012f984 011b9838 012ac6a8 0012f9fc 00000004 0012f994 10017170 000001c7 02829c40 0012f9d8 0012f9a4 0041ffea 02824c3c 02827bf4 02827974 0012f9b4 028250b8 02827974 02827904 02824dd8 0012f9c4 02824c3c 02827bf4 02824d9c 02824d9c 0012f9d4 02824dd8 0012fa8c 00420b98 028250b8 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> .lastevent Last event: ee0.13a4: Access violation - code c0000005 (first chance) debugger time: Thu Sep 3 07:43:12.390 2009 (GMT-7) 0:000> u . l1 m3core!Thread__Join+0x173: 005ebb01 8b5ffc mov ebx,dword ptr [edi-4] 0:000> r edi edi=00200000 0:000> Here is the entire bitmappy looking thing. 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> dd 012ac728 00200000 00200000 00200000 00200000 012ac738 00200000 00200000 00200000 00200000 012ac748 00200000 00200000 00200000 00200000 012ac758 00200000 00200000 00200000 00200000 012ac768 00200000 00200000 00200000 00200000 012ac778 00200000 00200000 00200000 00200000 012ac788 00200000 00200000 00200000 00200000 012ac798 00200000 00200000 00200000 00200000 0:000> 012ac7a8 00200000 00200000 00200000 00200000 012ac7b8 00200000 00200000 00200000 00200000 012ac7c8 00200000 00200000 00200000 00200000 012ac7d8 00200000 00200000 00200000 00200000 012ac7e8 00200000 00200000 00200000 00200000 012ac7f8 00200000 00200000 00200000 00200000 012ac808 00200000 00200000 00200000 00200000 012ac818 00200000 00200000 00200000 00200000 0:000> 012ac828 00200000 00200000 00200000 00200000 012ac838 00200000 00200000 00200000 00200000 012ac848 00200000 00200000 00200000 00200000 012ac858 00200000 00200000 00200000 00200000 012ac868 00200000 00200000 00200000 00200000 012ac878 00200000 00200000 00200000 00200000 012ac888 00200000 00200000 00200000 00200000 012ac898 00200000 00200000 00200000 00200000 0:000> 012ac8a8 00200000 00200000 00200000 00200000 012ac8b8 00200000 00200000 00200000 00200000 012ac8c8 00200000 00200000 00200000 00200000 012ac8d8 00200000 00200000 00200000 00200000 012ac8e8 00200000 00200000 00200000 00200000 012ac8f8 00200000 00200000 00200000 00200000 012ac908 00200000 00200000 00200000 00200000 012ac918 00200000 00200000 00200000 00200000 0:000> 012ac928 00200000 00200000 00200000 00200000 012ac938 00200000 00200000 00200000 00200000 012ac948 00200000 00200000 00200000 00200000 012ac958 00200000 00200000 00200000 00200000 012ac968 00200000 00200000 00200000 00200000 012ac978 00200000 00200000 00200000 00200000 012ac988 00200000 00200000 00200000 00200000 012ac998 00200000 00200000 00200000 00200000 0:000> 012ac9a8 00200000 00200000 00200000 00200000 012ac9b8 00200000 00200000 00200000 00200000 012ac9c8 00200000 00200000 00200000 00200000 012ac9d8 00200000 00200000 00200000 00200000 012ac9e8 00200000 00200000 00200000 00200000 012ac9f8 00200000 00200000 00200000 00200000 012aca08 00200000 00200000 00200000 00200000 012aca18 00200000 00200000 00200000 00200000 0:000> 012aca28 00200000 00200000 00200000 00200000 012aca38 00200000 00200000 00200000 00200000 012aca48 00200000 00200000 00200000 00200000 012aca58 00200000 00200000 00200000 00200000 012aca68 00200000 00200000 00200000 00200000 012aca78 00200000 00200000 00200000 00200000 012aca88 00200000 00200000 00200000 00200000 012aca98 00200000 00200000 00200000 00200000 0:000> 012acaa8 00200000 00200000 00200000 00200000 012acab8 00200000 00200000 00200000 00200000 012acac8 00200000 00200000 00200000 00200000 012acad8 00200000 00200000 00200000 00200000 012acae8 00200000 00200000 00200000 00200000 012acaf8 00200000 00200000 00200000 00200000 012acb08 00200000 00200000 00200000 00200000 012acb18 00200000 00200000 00200000 00200000 0:000> 012acb28 00200000 00200000 00200000 00200000 012acb38 00200000 00200000 00200000 00200000 012acb48 00200000 00200000 00200000 00200000 012acb58 00200000 00200000 00200000 00200000 012acb68 00200000 00200000 00200000 00200000 012acb78 00200000 00200000 00200000 00200000 012acb88 00200000 00200000 00200000 00200000 012acb98 00200000 00200000 00200000 00200000 0:000> 012acba8 00200000 00200000 00200000 00200000 012acbb8 00200000 00200000 00200000 00200000 012acbc8 00200000 00200000 00200000 00200000 012acbd8 00200000 00200000 00200000 00200000 012acbe8 00200000 00200000 00200000 00200000 012acbf8 00200000 00200000 00200000 00200000 012acc08 00200000 00200000 00200000 00200000 012acc18 00200000 00200000 00200000 00200000 0:000> 012acc28 00200000 00200000 00200000 00200000 012acc38 00200000 00200000 00200000 00200000 012acc48 00200000 00200000 00200000 00200000 012acc58 00200000 00200000 00200000 00200000 012acc68 00200000 00200000 00200000 00200000 012acc78 00200000 00200000 00200000 00200000 012acc88 00200000 00200000 00200000 00200000 012acc98 00200000 00200000 00200000 00200000 0:000> 012acca8 00200000 00200000 00200000 00200000 012accb8 00200000 00200000 00200000 00200000 012accc8 00200000 00200000 00200000 00200000 012accd8 00200000 00200000 00200000 00200000 012acce8 00200000 00200000 00200000 00200000 012accf8 00200000 00200000 00200000 00200000 012acd08 00200000 00200000 00200000 00200000 012acd18 00200000 00200000 00200000 00200000 0:000> 012acd28 00200000 00200000 00200000 00200000 012acd38 00200000 00200000 00200000 00200000 012acd48 00200000 00200000 00200000 00200000 012acd58 00200000 00200000 00200000 00200000 012acd68 00200000 00200000 00200000 00200000 012acd78 00200000 00200000 00200000 00200000 012acd88 00200000 00200000 00200000 00200000 012acd98 00200000 00200000 00200000 00200000 0:000> 012acda8 00200000 00200000 00200000 00200000 012acdb8 00200000 00200000 00200000 00200000 012acdc8 00200000 00200000 00200000 00200000 012acdd8 00200000 00200000 00200000 00200000 012acde8 00200000 00200000 00200000 00200000 012acdf8 00200000 00200000 00200000 00200000 012ace08 00200000 00200000 00200000 00200000 012ace18 00200000 00200000 00200000 00200000 0:000> 012ace28 00200000 00200000 00200000 00200000 012ace38 00200000 00200000 00200000 00200000 012ace48 00200000 00200000 00200000 00200000 012ace58 00200000 00200000 00200000 00200000 012ace68 00200000 00200000 00200000 00200000 012ace78 00200000 00200000 00200000 00200000 012ace88 00200000 00200000 00200000 00200000 012ace98 00200000 00200000 00200000 00200000 0:000> 012acea8 00200000 00200000 00200000 00200000 012aceb8 00200000 00200000 00200000 00200000 012acec8 00200000 00200000 00200000 00200000 012aced8 00200000 00200000 00200000 00200000 012acee8 00200000 00200000 00200000 00200000 012acef8 00200000 00200000 00200000 00200000 012acf08 00200000 00200000 00200000 00200000 012acf18 00200000 00200000 00200000 00200000 0:000> 012acf28 00200000 00200000 00200000 00200000 012acf38 00200000 00200000 00200000 00200000 012acf48 00200000 00200000 00200000 00200000 012acf58 00200000 00200000 00200000 00200000 012acf68 00200000 00200000 00200000 00200000 012acf78 00200000 00200000 00200000 00200000 012acf88 00200000 00200000 00200000 00200000 012acf98 00200000 00200000 00200000 00200000 0:000> 012acfa8 00200000 00200000 00200000 00200000 012acfb8 00200000 00200000 00200000 00200000 012acfc8 00200000 00200000 00200000 00200000 012acfd8 00200000 00200000 00200000 00200000 012acfe8 00200000 00200000 00200000 00200000 012acff8 00200000 00200000 00200000 00200000 012ad008 00200000 00200000 00200000 00200000 012ad018 00200000 00200000 00200000 00200000 0:000> 012ad028 00200000 00200000 00200000 00200000 012ad038 00200000 00200000 00200000 00200000 012ad048 00200000 00200000 00200000 00200000 012ad058 00200000 00200000 00200000 00200000 012ad068 00200000 00200000 00200000 00200000 012ad078 00200000 00200000 00200000 00200000 012ad088 00200000 00200000 00200000 00200000 012ad098 00200000 00200000 00200000 00200000 0:000> 012ad0a8 00200000 00200000 00200000 00200000 012ad0b8 00200000 00200000 00200000 00200000 012ad0c8 00200000 00200000 00200000 00200000 012ad0d8 00200000 00200000 00200000 00200000 012ad0e8 00200000 00200000 00200000 00200000 012ad0f8 00200000 00200000 00200000 00200000 012ad108 00200000 00200000 00200000 00200000 012ad118 00200000 00200000 00200000 00200000 0:000> 012ad128 00200000 00200000 00200000 00200000 012ad138 00200000 00200000 00200000 00200000 012ad148 00200000 00200000 00200000 00200000 012ad158 00200000 00200000 00200000 00200000 012ad168 00200000 00200000 00200000 00200000 012ad178 00200000 00200000 00200000 00200000 012ad188 00200000 00200000 00200000 00200000 012ad198 00200000 00200000 00200000 00200000 0:000> 012ad1a8 00200000 00200000 00200000 00200000 012ad1b8 00200000 00200000 00200000 00200000 012ad1c8 00200000 00200000 00200000 00200000 012ad1d8 00200000 00200000 00200000 00200000 012ad1e8 00200000 00200000 00200000 00200000 012ad1f8 00200000 00200000 00200000 00200000 012ad208 00200000 00200000 00200000 00200000 012ad218 00200000 00200000 00200000 00200000 0:000> 012ad228 00200000 00200000 00200000 00200000 012ad238 00200000 00200000 00200000 00200000 012ad248 00200000 00200000 00200000 00200000 012ad258 00200000 00200000 00200000 00200000 012ad268 00200000 00200000 00200000 00200000 012ad278 00200000 00200000 00200000 00200000 012ad288 00200000 00200000 00200000 00200000 012ad298 00200000 00200000 00200000 00200000 0:000> 012ad2a8 00200000 00200000 00200000 00200000 012ad2b8 00200000 00200000 00200000 00200000 012ad2c8 00200000 00200000 00200000 00200000 012ad2d8 00200000 00200000 00200000 00200000 012ad2e8 00200000 00200000 00200000 00200000 012ad2f8 00200000 00200000 00200000 00200000 012ad308 00200000 00200000 00200000 00200000 012ad318 00200000 00200000 00200000 00200000 0:000> 012ad328 00200000 00200000 00200000 00200000 012ad338 00200000 00200000 00200000 00200000 012ad348 00200000 00200000 00200000 00200000 012ad358 00200000 00200000 00200000 00200000 012ad368 00200000 00200000 00200000 00200000 012ad378 00200000 00200000 00200000 00200000 012ad388 00200000 00200000 00200000 00200000 012ad398 00200000 00200000 00200000 00200000 0:000> 012ad3a8 00200000 00200000 00200000 00200000 012ad3b8 00200000 00200000 00200000 00200000 012ad3c8 00200000 00200000 00200000 00200000 012ad3d8 00200000 00200000 00200000 00200000 012ad3e8 00200000 00200000 00200000 00200000 012ad3f8 00200000 00200000 00200000 00200000 012ad408 00200000 00200000 00200000 00200000 012ad418 00200000 00200000 00200000 00200000 0:000> 012ad428 00200000 00200000 00200000 00200000 012ad438 00200000 00200000 00200000 00200000 012ad448 00200000 00200000 00200000 00200000 012ad458 00200000 00200000 00200000 00200000 012ad468 00200000 00200000 00200000 00200000 012ad478 00200000 00200000 00200000 00200000 012ad488 00200000 00200000 00200000 00200000 012ad498 00200000 00200000 00200000 00200000 0:000> 012ad4a8 00200000 00200000 00200000 00200000 012ad4b8 00200000 00200000 00200000 00200000 012ad4c8 00200000 00200000 00200000 00200000 012ad4d8 00200000 00200000 00200000 00200000 012ad4e8 00200000 00200000 00200000 00200000 012ad4f8 00200000 00200000 00200000 00200000 012ad508 00200000 00200000 00200000 00200000 012ad518 00200000 00200000 00200000 00200000 0:000> 012ad528 00200000 00200000 00200000 00200000 012ad538 00200000 00200000 00200000 00200000 012ad548 00200000 00200000 00200000 00200000 012ad558 00200000 00200000 00200000 00200000 012ad568 00200000 00200000 00200000 00200000 012ad578 00200000 00200000 00200000 00200000 012ad588 00200000 00200000 00200000 00200000 012ad598 00200000 00200000 00200000 00200000 0:000> 012ad5a8 00200000 00200000 00200000 00200000 012ad5b8 00200000 00200000 00200000 00200000 012ad5c8 00200000 00200000 00200000 00200000 012ad5d8 00200000 00200000 00200000 00200000 012ad5e8 00200000 00200000 00200000 00200000 012ad5f8 00200000 00200000 00200000 00200000 012ad608 00200000 00200000 00200000 00200000 012ad618 00200000 00200000 00200000 00200000 0:000> 012ad628 00200000 00200000 00200000 00200000 012ad638 00200000 00200000 00200000 00200000 012ad648 00200000 00200000 00200000 00200000 012ad658 00200000 00200000 00200000 00200000 012ad668 00200000 00200000 00200000 00200000 012ad678 00200000 00200000 00200000 00200000 012ad688 00200000 00200000 00200000 00200000 012ad698 00200000 00200000 00200000 00200000 0:000> 012ad6a8 00200000 00200000 00200000 00200000 012ad6b8 00200000 00200000 00200000 00200000 012ad6c8 00200000 00200000 00200000 00200000 012ad6d8 00200000 00200000 00200000 00200000 012ad6e8 00200000 00200000 00200000 00200000 012ad6f8 00200000 00200000 00200000 00200000 012ad708 00200000 00200000 00200000 00200000 012ad718 00200000 00200000 00200000 00200000 0:000> 012ad728 00200000 00200000 00200000 00200000 012ad738 00200000 00200000 00200000 00200000 012ad748 00200000 00200000 00200000 00200000 012ad758 00200000 00200000 00200000 00200000 012ad768 00200000 00200000 00200000 00200000 012ad778 00200000 00200000 00200000 00200000 012ad788 00200000 00200000 00200000 00200000 012ad798 00200000 00200000 00200000 00200000 0:000> 012ad7a8 00200000 00200000 00200000 00200000 012ad7b8 00200000 00200000 00200000 00200000 012ad7c8 00200000 00200000 00200000 00200000 012ad7d8 00200000 00200000 00200000 00200000 012ad7e8 00200000 00200000 00200000 00200000 012ad7f8 00200000 00200000 00200000 00200000 012ad808 00200000 00200000 00200000 00200000 012ad818 00200000 00200000 00200000 00200000 0:000> 012ad828 00200000 00200000 00200000 00200000 012ad838 00200000 00200000 00200000 00200000 012ad848 00200000 00200000 00200000 00200000 012ad858 00200000 00200000 00200000 00200000 012ad868 00200000 00200000 00200000 00200000 012ad878 00200000 00200000 00200000 00200000 012ad888 00200000 00200000 00200000 00200000 012ad898 00200000 00200000 00200000 00200000 0:000> 012ad8a8 00200000 00200000 00200000 00200000 012ad8b8 00200000 00200000 00200000 00200000 012ad8c8 00200000 00200000 00200000 00200000 012ad8d8 00200000 00200000 00200000 00200000 012ad8e8 00200000 00200000 00200000 00200000 012ad8f8 00200000 00200000 00200000 00200000 012ad908 00200000 00200000 00200000 00200000 012ad918 00200000 00200000 00200000 00200000 0:000> 012ad928 00200000 00200000 00200000 00200000 012ad938 00200000 00200000 00200000 00200000 012ad948 00200000 00200000 00200000 00200000 012ad958 00200000 00200000 00200000 00200000 012ad968 00200000 00200000 00200000 00200000 012ad978 00200000 00200000 00200000 00200000 012ad988 00200000 00200000 00200000 00200000 012ad998 00200000 00200000 00200000 00200000 0:000> 012ad9a8 00200000 00200000 00200000 00200000 012ad9b8 00200000 00200000 00200000 00200000 012ad9c8 00200000 00200000 00200000 00200000 012ad9d8 00200000 00200000 00200000 00200000 012ad9e8 00200000 00200000 00200000 00200000 012ad9f8 00200000 00200000 00200000 00200000 012ada08 00200000 00200000 00200000 00200000 012ada18 00200000 00200000 00200000 00200000 0:000> 012ada28 00200000 00200000 00200000 00200000 012ada38 00200000 00200000 00200000 00200000 012ada48 00200000 00200000 00200000 00200000 012ada58 00200000 00200000 00200000 00200000 012ada68 00200000 00200000 00200000 00200000 012ada78 00200000 00200000 00200000 00200000 012ada88 00200000 00200000 00200000 00200000 012ada98 00200000 00200000 00200000 00200000 0:000> 012adaa8 00200000 00200000 00200000 00200000 012adab8 00200000 00200000 00200000 00200000 012adac8 00200000 00200000 00200000 00200000 012adad8 00200000 00200000 00200000 00200000 012adae8 00200000 00200000 00200000 00200000 012adaf8 00200000 00200000 00200000 00200000 012adb08 00200000 00200000 00200000 00200000 012adb18 00200000 00200000 00200000 00200000 0:000> 012adb28 00200000 00200000 00200000 00200000 012adb38 00200000 00200000 00200000 00200000 012adb48 00200000 00200000 00200000 00200000 012adb58 00200000 00200000 00200000 00200000 012adb68 00200000 00200000 00200000 00200000 012adb78 00200000 00200000 00200000 00200000 012adb88 00200000 00200000 00200000 00200000 012adb98 00200000 00200000 00200000 00200000 0:000> 012adba8 00200000 00200000 00200000 00200000 012adbb8 00200000 00200000 00200000 00200000 012adbc8 00200000 00200000 00200000 00200000 012adbd8 00200000 00200000 00200000 00200000 012adbe8 00200000 00200000 00200000 00200000 012adbf8 00200000 00200000 00200000 00200000 012adc08 00200000 00200000 00200000 00200000 012adc18 00200000 00200000 00200000 00200000 0:000> 012adc28 00200000 00200000 00200000 00200000 012adc38 00200000 00200000 00200000 00200000 012adc48 00200000 00200000 00200000 00200000 012adc58 00200000 00200000 00200000 00200000 012adc68 00200000 00200000 00200000 00200000 012adc78 00200000 00200000 00200000 00200000 012adc88 00200000 00200000 00200000 00200000 012adc98 00200000 00200000 00200000 00200000 0:000> 012adca8 00200000 00200000 00200000 00200000 012adcb8 00200000 00200000 00200000 00200000 012adcc8 00200000 00200000 00200000 00200000 012adcd8 00200000 00200000 00200000 00200000 012adce8 00200000 00200000 00200000 00200000 012adcf8 00200000 00200000 00200000 00200000 012add08 00200000 00200000 00200000 00200000 012add18 00200000 00200000 00200000 00200000 0:000> 012add28 00200000 00200000 00200000 00200000 012add38 00200000 00200000 00200000 00200000 012add48 00200000 00200000 00200000 00200000 012add58 00200000 00200000 00200000 00200000 012add68 00200000 00200000 00200000 00200000 012add78 00200000 00200000 00200000 00200000 012add88 00200000 00200000 00200000 00200000 012add98 00200000 00200000 00200000 00200000 0:000> 012adda8 00200000 00200000 00200000 00200000 012addb8 00200000 00200000 00200000 00200000 012addc8 00200000 00200000 00200000 00200000 012addd8 00200000 00200000 00200000 00200000 012adde8 00200000 00200000 00200000 00200000 012addf8 00200000 00200000 00200000 00200000 012ade08 00200000 00200000 00200000 00200000 012ade18 00200000 00200000 00200000 00200000 0:000> 012ade28 00200000 00200000 00200000 00200000 012ade38 00200000 00200000 00200000 00200000 012ade48 00200000 00200000 00200000 00200000 012ade58 00200000 00200000 00200000 00200000 012ade68 00200000 00200000 00200000 00200000 012ade78 00200000 00200000 00200000 00200000 012ade88 00200000 00200000 00200000 00200000 012ade98 00200000 00200000 00200000 00200000 0:000> 012adea8 00200000 00200000 00200000 00200000 012adeb8 00200000 00200000 00200000 00200000 012adec8 00200000 00200000 00200000 00200000 012aded8 00200000 00200000 00200000 00200000 012adee8 00200000 00200000 00200000 00200000 012adef8 00200000 00200000 00200000 00200000 012adf08 00200000 00200000 00200000 00200000 012adf18 00200000 00200000 00200000 00200000 0:000> 012adf28 00200000 00200000 00200000 00200000 012adf38 00200000 00200000 00200000 00200000 012adf48 00200000 00200000 00200000 00200000 012adf58 00200000 00200000 00200000 00200000 012adf68 00200000 00200000 00200000 00200000 012adf78 00200000 00200000 00200000 00200000 012adf88 00200000 00200000 00200000 00200000 012adf98 00200000 00200000 00200000 00200000 0:000> 012adfa8 00200000 00200000 00200000 00200000 012adfb8 00200000 00200000 00200000 00200000 012adfc8 00200000 00200000 00200000 00200000 012adfd8 00200000 00200000 00200000 00200000 012adfe8 00200000 00200000 00200000 00200000 012adff8 00200000 00200000 00200000 00200000 012ae008 00200000 00200000 00200000 00200000 012ae018 00200000 00200000 00200000 00200000 0:000> 012ae028 00200000 00200000 00200000 00200000 012ae038 00200000 00200000 00200000 00200000 012ae048 00200000 00200000 00200000 00200000 012ae058 00200000 00200000 00200000 00200000 012ae068 00200000 00200000 00200000 00200000 012ae078 00200000 00200000 00200000 00200000 012ae088 00200000 00200000 00200000 00200000 012ae098 00200000 00200000 00200000 00200000 0:000> 012ae0a8 00200000 00200000 00200000 00200000 012ae0b8 00200000 00200000 00200000 00200000 012ae0c8 00200000 00200000 00200000 00200000 012ae0d8 00200000 00200000 00200000 00200000 012ae0e8 00200000 00200000 00200000 00200000 012ae0f8 00200000 00200000 00200000 00200000 012ae108 00200000 00200000 00200000 00200000 012ae118 00200000 00200000 00200000 00200000 0:000> 012ae128 00200000 00200000 00200000 00200000 012ae138 00200000 00200000 00200000 00200000 012ae148 00200000 00200000 00200000 00200000 012ae158 00200000 00200000 00200000 00200000 012ae168 00200000 00200000 00200000 00200000 012ae178 00200000 00200000 00200000 00200000 012ae188 00200000 00200000 00200000 00200000 012ae198 00200000 00200000 00200000 00200000 0:000> 012ae1a8 00200000 00200000 00200000 00200000 012ae1b8 00200000 00200000 00200000 00200000 012ae1c8 00200000 00200000 00200000 00200000 012ae1d8 00200000 00200000 00200000 00200000 012ae1e8 00200000 00200000 00200000 00200000 012ae1f8 00200000 00200000 00200000 00200000 012ae208 00200000 00200000 00200000 00200000 012ae218 00200000 00200000 00200000 00200000 0:000> 012ae228 00200000 00200000 00200000 00200000 012ae238 00200000 00200000 00200000 00200000 012ae248 00200000 00200000 00200000 00200000 012ae258 00200000 00200000 00200000 00200000 012ae268 00200000 00200000 00200000 00200000 012ae278 00200000 00200000 00200000 00200000 012ae288 00200000 00200000 00200000 00200000 012ae298 00200000 00200000 00200000 00200000 0:000> 012ae2a8 00200000 00200000 00200000 00200000 012ae2b8 00200000 00200000 00200000 00200000 012ae2c8 00200000 00200000 00200000 00200000 012ae2d8 00200000 00200000 00200000 00200000 012ae2e8 00200000 00200000 00200000 00200000 012ae2f8 00200000 00200000 00200000 00200000 012ae308 00200000 00200000 00200000 00200000 012ae318 00200000 00200000 00200000 00200000 0:000> 012ae328 00200000 00200000 00200000 00200000 012ae338 00200000 00200000 00200000 00200000 012ae348 00200000 00200000 00200000 00200000 012ae358 00200000 00200000 00200000 00200000 012ae368 00200000 00200000 00200000 00200000 012ae378 00200000 00200000 00200000 00200000 012ae388 00200000 00200000 00200000 00200000 012ae398 00200000 00200000 00200000 00200000 0:000> 012ae3a8 00200000 00200000 00200000 00200000 012ae3b8 00200000 00200000 00200000 00200000 012ae3c8 00200000 00200000 00200000 00200000 012ae3d8 00200000 00200000 00200000 00200000 012ae3e8 00200000 00200000 00200000 00200000 012ae3f8 00200000 00200000 00200000 00200000 012ae408 00200000 00200000 00200000 00200000 012ae418 00200000 00200000 00200000 00200000 0:000> 012ae428 00200000 00200000 00200000 00200000 012ae438 00200000 00200000 00200000 00200000 012ae448 00200000 00200000 00200000 00200000 012ae458 00200000 00200000 00200000 00200000 012ae468 00200000 00200000 00200000 00200000 012ae478 00200000 00200000 00200000 00200000 012ae488 00200000 00200000 00200000 00200000 012ae498 00200000 00200000 00200000 00200000 0:000> 012ae4a8 00200000 00200000 00200000 00200000 012ae4b8 00200000 00200000 00200000 00200000 012ae4c8 00200000 00200000 00200000 00200000 012ae4d8 00200000 00200000 00200000 00200000 012ae4e8 00200000 00200000 00200000 00200000 012ae4f8 00200000 00200000 00200000 00200000 012ae508 00200000 00200000 00200000 00200000 012ae518 00200000 00200000 00200000 00200000 0:000> 012ae528 00200000 00200000 00200000 00200000 012ae538 00200000 00200000 00200000 00200000 012ae548 00200000 00200000 00200000 00200000 012ae558 00200000 00200000 00200000 00200000 012ae568 00200000 00200000 00200000 00200000 012ae578 00200000 00200000 00200000 00200000 012ae588 00200000 00200000 00200000 00200000 012ae598 00200000 00200000 00200000 00200000 0:000> 012ae5a8 00200000 00200000 00200000 00200000 012ae5b8 00200000 00200000 00200000 00200000 012ae5c8 00200000 00200000 00200000 00200000 012ae5d8 00200000 00200000 00200000 00200000 012ae5e8 00200000 00200000 00200000 00200000 012ae5f8 00200000 00200000 00200000 00200000 012ae608 00200000 00200000 00200000 00200000 012ae618 00200000 00200000 00200000 00200000 0:000> 012ae628 00200000 00200000 00200000 00200000 012ae638 00200000 00200000 00200000 00200000 012ae648 00200000 00200000 00200000 00200000 012ae658 00200000 00200000 00200000 00200000 012ae668 00200000 00200000 00200000 00200000 012ae678 00200000 00200000 00200000 00200000 012ae688 00200000 00200000 00200000 00200000 012ae698 00200000 00200000 00200000 00200000 0:000> 012ae6a8 00200000 00200000 00200000 00200000 012ae6b8 00200000 00200000 00200000 00200000 012ae6c8 00200000 00200000 00200000 00200000 012ae6d8 00200000 00200000 00200000 00200000 012ae6e8 00200000 00200000 00200000 00200000 012ae6f8 00200000 00200000 00200000 00200000 012ae708 00200000 00200000 00200000 00200000 012ae718 00200000 00200000 00200000 00200000 0:000> 012ae728 00200000 00200000 00200000 00200000 012ae738 00200000 00200000 00200000 00200000 012ae748 00200000 00200000 00200000 00200000 012ae758 00200000 00200000 00200000 00200000 012ae768 00200000 00200000 00200000 00200000 012ae778 00200000 00200000 00200000 00200000 012ae788 00200000 00200000 00200000 00200000 012ae798 00200000 00200000 00200000 00200000 0:000> 012ae7a8 00200000 00200000 00200000 00200000 012ae7b8 00200000 00200000 00200000 00200000 012ae7c8 00200000 00200000 00200000 00200000 012ae7d8 00200000 00200000 00200000 00200000 012ae7e8 00200000 00200000 00200000 00200000 012ae7f8 00200000 00200000 00200000 00200000 012ae808 00200000 00200000 00200000 00200000 012ae818 00200000 00200000 00200000 00200000 0:000> 012ae828 00200000 00200000 00200000 00200000 012ae838 00200000 00200000 00200000 00200000 012ae848 00200000 00200000 00200000 00200000 012ae858 00200000 00200000 00200000 00200000 012ae868 00200000 00200000 00200000 00200000 012ae878 00200000 00200000 00200000 00200000 012ae888 00200000 00200000 00200000 00200000 012ae898 00200000 00200000 00200000 00200000 0:000> 012ae8a8 00200000 00200000 00200000 00200000 012ae8b8 00200000 00200000 00200000 00200000 012ae8c8 00200000 00200000 00200000 00200000 012ae8d8 00200000 00200000 00200000 00200000 012ae8e8 00200000 00200000 00200000 00200000 012ae8f8 00200000 00200000 00200000 00200000 012ae908 00200000 00200000 00200000 00200000 012ae918 00200000 00200000 00200000 00200000 0:000> 012ae928 00200000 00200000 00200000 00200000 012ae938 00200000 00200000 00200000 00200000 012ae948 00200000 00200000 00200000 00200000 012ae958 00200000 00200000 00200000 00200000 012ae968 00200000 00200000 00200000 00200000 012ae978 00200000 00200000 00200000 00200000 012ae988 00200000 00200000 00200000 00200000 012ae998 00200000 00200000 00200000 00200000 0:000> 012ae9a8 00200000 00200000 00200000 00200000 012ae9b8 00200000 00200000 00200000 00200000 012ae9c8 00200000 00200000 00200000 00200000 012ae9d8 00200000 00200000 00200000 00200000 012ae9e8 00200000 00200000 00200000 00200000 012ae9f8 00200000 00200000 00200000 00200000 012aea08 00200000 00200000 00200000 00200000 012aea18 00200000 00200000 00200000 00200000 0:000> 012aea28 00200000 00200000 00200000 00200000 012aea38 00200000 00200000 00200000 00200000 012aea48 00200000 00200000 00200000 00200000 012aea58 00200000 00200000 00200000 00200000 012aea68 00200000 00200000 00200000 00200000 012aea78 00200000 00200000 00200000 00200000 012aea88 00200000 00200000 00200000 00200000 012aea98 00200000 00200000 00200000 00200000 0:000> 012aeaa8 00200000 00200000 00200000 00200000 012aeab8 00200000 00200000 00200000 00200000 012aeac8 00200000 00200000 00200000 00200000 012aead8 00200000 00200000 00200000 00200000 012aeae8 00200000 00200000 00200000 00200000 012aeaf8 00200000 00200000 00200000 00200000 012aeb08 00200000 00200000 00200000 00200000 012aeb18 00200000 00200000 00200000 00200000 0:000> 012aeb28 00200000 00200000 00200000 00200000 012aeb38 00200000 00200000 00200000 00200000 012aeb48 00200000 00200000 00200000 00200000 012aeb58 00200000 00200000 00200000 00200000 012aeb68 00200000 00200000 00200000 00200000 012aeb78 00200000 00200000 00200000 00200000 012aeb88 00200000 00200000 00200000 00200000 012aeb98 00200000 00200000 00200000 00200000 0:000> 012aeba8 00200000 00200000 00200000 00200000 012aebb8 00200000 00200000 00200000 00200000 012aebc8 00200000 00200000 00200000 00200000 012aebd8 00200000 00200000 00200000 00200000 012aebe8 00200000 00200000 00200000 00200000 012aebf8 00200000 00200000 00200000 00200000 012aec08 00200000 00200000 00200000 00200000 012aec18 00200000 00200000 00200000 00200000 0:000> 012aec28 00200000 00200000 00200000 00200000 012aec38 00200000 00200000 00200000 00200000 012aec48 00200000 00200000 00200000 00200000 012aec58 00200000 00200000 00200000 00200000 012aec68 00200000 00200000 00200000 00200000 012aec78 00200000 00200000 00200000 00200000 012aec88 00200000 00200000 00200000 00200000 012aec98 00200000 00200000 00200000 00200000 0:000> 012aeca8 00200000 00200000 00200000 00200000 012aecb8 00200000 00200000 00200000 00200000 012aecc8 00200000 00200000 00200000 00200000 012aecd8 00200000 00200000 00200000 00200000 012aece8 00200000 00200000 00200000 00200000 012aecf8 00200000 00200000 00200000 00200000 012aed08 00200000 00200000 00200000 00200000 012aed18 00200000 00200000 00200000 00200000 0:000> 012aed28 00200000 00200000 00200000 00200000 012aed38 00200000 00200000 00200000 00200000 012aed48 00200000 00200000 00200000 00200000 012aed58 00200000 00200000 00200000 00200000 012aed68 00200000 00200000 00200000 00200000 012aed78 00200000 00200000 00200000 00200000 012aed88 00200000 00200000 00200000 00200000 012aed98 00200000 00200000 00200000 00200000 0:000> 012aeda8 00200000 00200000 00200000 00200000 012aedb8 00200000 00200000 00200000 00200000 012aedc8 00200000 00200000 00200000 00200000 012aedd8 00200000 00200000 00200000 00200000 012aede8 00200000 00200000 00200000 00200000 012aedf8 00200000 00200000 00200000 00200000 012aee08 00200000 00200000 00200000 00200000 012aee18 00200000 00200000 00200000 00200000 0:000> 012aee28 00200000 00200000 00200000 00200000 012aee38 00200000 00200000 00200000 00200000 012aee48 00200000 00200000 00200000 00200000 012aee58 00200000 00200000 00200000 00200000 012aee68 00200000 00200000 00200000 00200000 012aee78 00200000 00200000 00200000 00200000 012aee88 00200000 00200000 00200000 00200000 012aee98 00200000 00200000 00200000 00200000 0:000> 012aeea8 00200000 00200000 00200000 00200000 012aeeb8 00200000 00200000 00200000 00200000 012aeec8 00200000 00200000 00200000 00200000 012aeed8 00200000 00200000 00200000 00200000 012aeee8 00200000 00200000 00200000 00200000 012aeef8 00200000 00200000 00200000 00200000 012aef08 00200000 00200000 00200000 00200000 012aef18 00200000 00200000 00200000 00200000 0:000> 012aef28 00200000 00200000 00200000 00200000 012aef38 00200000 00200000 00200000 00200000 012aef48 00200000 00200000 00200000 00200000 012aef58 00200000 00200000 00200000 00200000 012aef68 00200000 00200000 00200000 00200000 012aef78 00200000 00200000 00200000 00200000 012aef88 00200000 00200000 00200000 00200000 012aef98 00200000 00200000 00200000 00200000 0:000> 012aefa8 00200000 00200000 00200000 00200000 012aefb8 00200000 00200000 00200000 00200000 012aefc8 00200000 00200000 00200000 00200000 012aefd8 00200000 00200000 00200000 00200000 012aefe8 00200000 00200000 00200000 00200000 012aeff8 00200000 00200000 00200000 00200000 012af008 00200000 00200000 00200000 00200000 012af018 00200000 00200000 00200000 00200000 0:000> 012af028 00200000 00200000 00200000 00200000 012af038 00200000 00200000 00200000 00200000 012af048 00200000 00200000 00200000 00200000 012af058 00200000 00200000 00200000 00200000 012af068 00200000 00200000 00200000 00200000 012af078 00200000 00200000 00200000 00200000 012af088 00200000 00200000 00200000 00200000 012af098 00200000 00200000 00200000 00200000 0:000> 012af0a8 00200000 00200000 00200000 00200000 012af0b8 00200000 00200000 00200000 00200000 012af0c8 00200000 00200000 00200000 00200000 012af0d8 00200000 00200000 00200000 00200000 012af0e8 00200000 00200000 00200000 00200000 012af0f8 00200000 00200000 00200000 00200000 012af108 00200000 00200000 00200000 00200000 012af118 00200000 00200000 00200000 00200000 0:000> 012af128 00200000 00200000 00200000 00200000 012af138 00200000 00200000 00200000 00200000 012af148 00200000 00200000 00200000 00200000 012af158 00200000 00200000 00200000 00200000 012af168 00200000 00200000 00200000 00200000 012af178 00200000 00200000 00200000 00200000 012af188 00200000 00200000 00200000 00200000 012af198 00200000 00200000 00200000 00200000 0:000> 012af1a8 00200000 00200000 00200000 00200000 012af1b8 00200000 00200000 00200000 00200000 012af1c8 00200000 00200000 00200000 00200000 012af1d8 00200000 00200000 00200000 00200000 012af1e8 00200000 00200000 00200000 00200000 012af1f8 00200000 00200000 00200000 00200000 012af208 00200000 00200000 00200000 00200000 012af218 00200000 00200000 00200000 00200000 0:000> 012af228 00200000 00200000 00200000 00200000 012af238 00200000 00200000 00200000 00200000 012af248 00200000 00200000 00200000 00200000 012af258 00200000 00200000 00200000 00200000 012af268 00200000 00200000 00200000 00200000 012af278 00200000 00200000 00200000 00200000 012af288 00200000 00200000 00200000 00200000 012af298 00200000 00200000 00200000 00200000 0:000> 012af2a8 00200000 00200000 00200000 00200000 012af2b8 00200000 00200000 00200000 00200000 012af2c8 00200000 00200000 00200000 00200000 012af2d8 00200000 00200000 00200000 00200000 012af2e8 00200000 00200000 00200000 00200000 012af2f8 00200000 00200000 00200000 00200000 012af308 00200000 00200000 00200000 00200000 012af318 00200000 00200000 00200000 00200000 0:000> 012af328 00200000 00200000 00200000 00200000 012af338 00200000 00200000 00200000 00200000 012af348 00200000 00200000 00200000 00200000 012af358 00200000 00200000 00200000 00200000 012af368 00200000 00200000 00200000 00200000 012af378 00200000 00200000 00200000 00200000 012af388 00200000 00200000 00200000 00200000 012af398 00200000 00200000 00200000 00200000 0:000> 012af3a8 00200000 00200000 00200000 00200000 012af3b8 00200000 00200000 00200000 00200000 012af3c8 00200000 00200000 00200000 00200000 012af3d8 00200000 00200000 00200000 00200000 012af3e8 00200000 00200000 00200000 00200000 012af3f8 00200000 00200000 00200000 00200000 012af408 00200000 00200000 00200000 00200000 012af418 00200000 00200000 00200000 00200000 0:000> 012af428 00200000 00200000 00200000 00200000 012af438 00200000 00200000 00200000 00200000 012af448 00200000 00200000 00200000 00200000 012af458 00200000 00200000 00200000 00200000 012af468 00200000 00200000 00200000 00200000 012af478 00200000 00200000 00200000 00200000 012af488 00200000 00200000 00200000 00200000 012af498 00200000 00200000 00200000 00200000 0:000> 012af4a8 00200000 00200000 00200000 00200000 012af4b8 00200000 00200000 00200000 00200000 012af4c8 00200000 00200000 00200000 00200000 012af4d8 00200000 00200000 00200000 00200000 012af4e8 00200000 00200000 00200000 00200000 012af4f8 00200000 00200000 00200000 00200000 012af508 00200000 00200000 00200000 00200000 012af518 00200000 00200000 00200000 00200000 0:000> 012af528 00200000 00200000 00200000 00200000 012af538 00200000 00200000 00200000 00200000 012af548 00200000 00200000 00200000 00200000 012af558 00200000 00200000 00200000 00200000 012af568 00200000 00200000 00200000 00200000 012af578 00200000 00200000 00200000 00200000 012af588 00200000 00200000 00200000 00200000 012af598 00200000 00200000 00200000 00200000 0:000> 012af5a8 00200000 00200000 00200000 00200000 012af5b8 00200000 00200000 00200000 00200000 012af5c8 00200000 00200000 00200000 00200000 012af5d8 00200000 00200000 00200000 00200000 012af5e8 00200000 00200000 00200000 00200000 012af5f8 00200000 00200000 00200000 00200000 012af608 00200000 00200000 00200000 00200000 012af618 00200000 00200000 00200000 00200000 0:000> 012af628 00200000 00200000 00200000 00200000 012af638 00200000 00200000 00200000 00200000 012af648 00200000 00200000 00200000 00200000 012af658 00200000 00200000 00200000 00200000 012af668 00200000 00200000 00200000 00200000 012af678 00200000 00200000 00200000 00200000 012af688 00200000 00200000 00200000 00200000 012af698 00200000 00200000 00200000 00200000 0:000> 012af6a8 00200000 00200000 00200000 00200000 012af6b8 00200000 00200000 00200000 00200000 012af6c8 00200000 00200000 00200000 00200000 012af6d8 00200000 00200000 00200000 00200000 012af6e8 00200000 00200000 00200000 00200000 012af6f8 00200000 00200000 00200000 00200000 012af708 00200000 00200000 00200000 00200000 012af718 00200000 00200000 00200000 00200000 0:000> 012af728 00200000 00200000 00200000 00200000 012af738 00200000 00200000 00200000 00200000 012af748 00200000 00200000 00200000 00200000 012af758 00200000 00200000 00200000 00200000 012af768 00200000 00200000 00200000 00200000 012af778 00200000 00200000 00200000 00200000 012af788 00200000 00200000 00200000 00200000 012af798 00200000 00200000 00200000 00200000 0:000> 012af7a8 00200000 00200000 00200000 00200000 012af7b8 00200000 00200000 00200000 00200000 012af7c8 00200000 00200000 00200000 00200000 012af7d8 00200000 00200000 00200000 00200000 012af7e8 00200000 00200000 00200000 00200000 012af7f8 00200000 00200000 00200000 00200000 012af808 00200000 00200000 00200000 00200000 012af818 00200000 00200000 00200000 00200000 0:000> 012af828 00200000 00200000 00200000 00200000 012af838 00200000 00200000 00200000 00200000 012af848 00200000 00200000 00200000 00200000 012af858 00200000 00200000 00200000 00200000 012af868 00200000 00200000 00200000 00200000 012af878 00200000 00200000 00200000 00200000 012af888 00200000 00200000 00200000 00200000 012af898 00200000 00200000 00200000 00200000 0:000> 012af8a8 00200000 00200000 00200000 00200000 012af8b8 00200000 00200000 00200000 00200000 012af8c8 00200000 00200000 00200000 00200000 012af8d8 00200000 00200000 00200000 00200000 012af8e8 00200000 00200000 00200000 00200000 012af8f8 00200000 00200000 00200000 00200000 012af908 00200000 00200000 00200000 00200000 012af918 00200000 00200000 00200000 00200000 0:000> 012af928 00200000 00200000 00200000 00200000 012af938 00200000 00200000 00200000 00200000 012af948 00200000 00200000 00200000 00200000 012af958 00200000 00200000 00200000 00200000 012af968 00200000 00200000 00200000 00200000 012af978 00200000 00200000 00200000 00200000 012af988 00200000 00200000 00200000 00200000 012af998 00200000 00200000 00200000 00200000 0:000> 012af9a8 00200000 00200000 00200000 00200000 012af9b8 00200000 00200000 00200000 00200000 012af9c8 00200000 00200000 00200000 00200000 012af9d8 00200000 00200000 00200000 00200000 012af9e8 00200000 00200000 00200000 00200000 012af9f8 00200000 00200000 00200000 00200000 012afa08 00200000 00200000 00200000 00200000 012afa18 00200000 00200000 00200000 00200000 0:000> 012afa28 00200000 00200000 00200000 00200000 012afa38 00200000 00200000 00200000 00200000 012afa48 00200000 00200000 00200000 00200000 012afa58 00200000 00200000 00200000 00200000 012afa68 00200000 00200000 00200000 00200000 012afa78 00200000 00200000 00200000 00200000 012afa88 00200000 00200000 00200000 00200000 012afa98 00200000 00200000 00200000 00200000 0:000> 012afaa8 00200000 00200000 00200000 00200000 012afab8 00200000 00200000 00200000 00200000 012afac8 00200000 00200000 00200000 00200000 012afad8 00200000 00200000 00200000 00200000 012afae8 00200000 00200000 00200000 00200000 012afaf8 00200000 00200000 00200000 00200000 012afb08 00200000 00200000 00200000 00200000 012afb18 00200000 00200000 00200000 00200000 0:000> 012afb28 00200000 00200000 00200000 00200000 012afb38 00200000 00200000 00200000 00200000 012afb48 00200000 00200000 00200000 00200000 012afb58 00200000 00200000 00200000 00200000 012afb68 00200000 00200000 00200000 00200000 012afb78 00200000 00200000 00200000 00200000 012afb88 00200000 00200000 00200000 00200000 012afb98 00200000 00200000 00200000 00200000 0:000> 012afba8 00200000 00200000 00200000 00200000 012afbb8 00200000 00200000 00200000 00200000 012afbc8 00200000 00200000 00200000 00200000 012afbd8 00200000 00200000 00200000 00200000 012afbe8 00200000 00200000 00200000 00200000 012afbf8 00200000 00200000 00200000 00200000 012afc08 00200000 00200000 00200000 00200000 012afc18 00200000 00200000 00200000 00200000 0:000> 012afc28 00200000 00200000 00200000 00200000 012afc38 00200000 00200000 00200000 00200000 012afc48 00200000 00200000 00200000 00200000 012afc58 00200000 00200000 00200000 00200000 012afc68 00200000 00200000 00200000 00200000 012afc78 00200000 00200000 00200000 00200000 012afc88 00200000 00200000 00200000 00200000 012afc98 00200000 00200000 00200000 00200000 0:000> 012afca8 00200000 00200000 00200000 00200000 012afcb8 00200000 00200000 00200000 00200000 012afcc8 00200000 00200000 00200000 00200000 012afcd8 00200000 00200000 00200000 00200000 012afce8 00200000 00200000 00200000 00200000 012afcf8 00200000 00200000 00200000 00200000 012afd08 00200000 00200000 00200000 00200000 012afd18 00200000 00200000 00200000 00200000 0:000> 012afd28 00200000 00200000 00200000 00200000 012afd38 00200000 00200000 00200000 00200000 012afd48 00200000 00200000 00200000 00200000 012afd58 00200000 00200000 00200000 00200000 012afd68 00200000 00200000 00200000 00200000 012afd78 00200000 00200000 00200000 00200000 012afd88 00200000 00200000 00200000 00200000 012afd98 00200000 00200000 00200000 00200000 0:000> 012afda8 00200000 00200000 00200000 00200000 012afdb8 00200000 00200000 00200000 00200000 012afdc8 00200000 00200000 00200000 00200000 012afdd8 00200000 00200000 00200000 00200000 012afde8 00200000 00200000 00200000 00200000 012afdf8 00200000 00200000 00200000 00200000 012afe08 00200000 00200000 00200000 00200000 012afe18 00200000 00200000 00200000 00200000 0:000> 012afe28 00200000 00200000 00200000 00200000 012afe38 00200000 00200000 00200000 00200000 012afe48 00200000 00200000 00200000 00200000 012afe58 00200000 00200000 00200000 00200000 012afe68 00200000 00200000 00200000 00200000 012afe78 00200000 00200000 00200000 00200000 012afe88 00200000 00200000 00200000 00200000 012afe98 00200000 00200000 00200000 00200000 0:000> 012afea8 00200000 00200000 00200000 00200000 012afeb8 00200000 00200000 00200000 00200000 012afec8 00200000 00200000 00200000 00200000 012afed8 00200000 00200000 00200000 00200000 012afee8 00200000 00200000 00200000 00200000 012afef8 00200000 00200000 00200000 00200000 012aff08 00200000 00200000 00200000 00200000 012aff18 00200000 00200000 00200000 00200000 0:000> 012aff28 00200000 00200000 00200000 00200000 012aff38 00200000 00200000 00200000 00200000 012aff48 00200000 00200000 00200000 00200000 012aff58 00200000 00200000 00200000 00200000 012aff68 00200000 00200000 00200000 00200000 012aff78 00200000 00200000 00200000 00200000 012aff88 00200000 00200000 00200000 00200000 012aff98 00200000 00200000 00200000 00200000 0:000> 012affa8 00200000 00200000 00200000 00200000 012affb8 00200000 00200000 00200000 00200000 012affc8 00200000 00200000 00200000 00200000 012affd8 00200000 00200000 00200000 00200000 012affe8 00200000 00200000 00200000 00200000 012afff8 00200000 00200000 00000013 00000001 012b0008 00200026 012b0014 0000172e 00000000 012b0018 00000000 00000000 00000000 00000000 0:000> 012b0028 00000000 00000000 00000000 00000000 012b0038 00000000 00000000 00000000 00000000 012b0048 00000000 00000000 00000000 00000000 012b0058 00000000 00000000 00000000 00000000 012b0068 00000000 00000000 00000000 00000000 012b0078 00000000 00000000 00000000 00000000 012b0088 00000000 00000000 00000000 00000000 012b0098 00000000 00000000 00000000 00000000 0:000> 012b00a8 00000000 00000000 00000000 00000000 012b00b8 00000000 00000000 00000000 00000000 012b00c8 00000000 00000000 00000000 00000000 012b00d8 00000000 00000000 00000000 00000000 012b00e8 00000000 00000000 00000000 00000000 012b00f8 00000000 00000000 00000000 00000000 012b0108 00000000 00000000 00000000 00000000 012b0118 00000000 00000000 00000000 00000000 0:000> 012b0128 00000000 00000000 00000000 00000000 012b0138 00000000 00000000 00000000 00000000 012b0148 00000000 00000000 00000000 00000000 012b0158 00000000 00000000 00000000 00000000 012b0168 00000000 00000000 00000000 00000000 012b0178 00000000 00000000 00000000 00000000 012b0188 00000000 00000000 00000000 00000000 012b0198 00000000 00000000 00000000 00000000 0:000> 012b01a8 00000000 00000000 00000000 00000000 012b01b8 00000000 00000000 00000000 00000000 012b01c8 00000000 00000000 00000000 00000000 012b01d8 00000000 00000000 00000000 00000000 012b01e8 00000000 00000000 00000000 00000000 012b01f8 00000000 00000000 00000000 00000000 012b0208 00000000 00000000 00000000 00000000 012b0218 00000000 00000000 00000000 00000000 0:000> 012b0228 00000000 00000000 00000000 00000000 012b0238 00000000 00000000 00000000 00000000 012b0248 00000000 00000000 00000000 00000000 012b0258 00000000 00000000 00000000 00000000 012b0268 00000000 00000000 00000000 00000000 012b0278 00000000 00000000 00000000 00000000 012b0288 00000000 00000000 00000000 00000000 012b0298 00000000 00000000 00000000 00000000 0:000> 012b02a8 00000000 00000000 00000000 00000000 012b02b8 00000000 00000000 00000000 00000000 012b02c8 00000000 00000000 00000000 00000000 012b02d8 00000000 00000000 00000000 00000000 012b02e8 00000000 00000000 00000000 00000000 012b02f8 00000000 00000000 00000000 00000000 012b0308 00000000 00000000 00000000 00000000 012b0318 00000000 00000000 00000000 00000000 0:000> 012b0328 00000000 00000000 00000000 00000000 012b0338 00000000 00000000 00000000 00000000 012b0348 00000000 00000000 55000000 55005500 012b0358 55005500 55005500 55005500 55005500 012b0368 55005500 55005500 55005500 55005500 012b0378 55005500 55005500 55005500 55005500 012b0388 55005500 55005500 55005500 55005500 012b0398 55005500 55005500 55005500 55005500 0:000> 012b03a8 55005500 55005500 55005500 55005500 012b03b8 55005500 55005500 55005500 55005500 012b03c8 55005500 55005500 55005500 55005500 012b03d8 55005500 55005500 55005500 55005500 012b03e8 55005500 55005500 55005500 55005500 012b03f8 55005500 55005500 55005500 55005500 012b0408 55005500 55005500 55005500 55005500 012b0418 55005500 55005500 55005500 55005500 0:000> 012b0428 55005500 55005500 55005500 55005500 012b0438 55005500 55005500 55005500 55005500 012b0448 55005500 55005500 55005500 55005500 012b0458 55005500 55005500 00000000 55000000 012b0468 55000055 55000055 55000055 55000055 012b0478 55000055 55000055 55000055 55000055 012b0488 55000055 55000055 55000055 55000055 012b0498 55000055 55000055 55000055 55000055 0:000> 012b04a8 55000055 55000055 55000055 55000055 012b04b8 55000055 55000055 55000055 55000055 012b04c8 55000055 55000055 55000055 55000055 012b04d8 55000055 55000055 55000055 55000055 012b04e8 55000055 55000055 55000055 55000055 012b04f8 55000055 55000055 55000055 55000055 012b0508 55000055 55000055 55000055 55000055 012b0518 55000055 55000055 55000055 55000055 0:000> 012b0528 55000055 55000055 55000055 55000055 012b0538 55000055 55000055 55000055 55000055 012b0548 55000055 55000055 55000055 55000055 012b0558 55000055 55000055 55000055 55000055 012b0568 55000055 55000055 55000055 00000000 012b0578 00000000 00555555 00555555 00555555 012b0588 00555555 00555555 00555555 00555555 012b0598 00555555 00555555 00555555 00555555 0:000> 012b05a8 00555555 00555555 00555555 00555555 012b05b8 00555555 00555555 00555555 00555555 012b05c8 00555555 00555555 00555555 00555555 012b05d8 00555555 00555555 00555555 00555555 012b05e8 00555555 00555555 00555555 00555555 012b05f8 00555555 00555555 00555555 00555555 012b0608 00555555 00555555 00555555 00555555 012b0618 00555555 00555555 00555555 00555555 0:000> 012b0628 00555555 00555555 00555555 00555555 012b0638 00555555 00555555 00555555 00555555 012b0648 00555555 00555555 00555555 00555555 012b0658 00555555 00555555 00555555 00555555 012b0668 00555555 00555555 00555555 00555555 012b0678 00555555 00555555 00555555 00555555 012b0688 00000000 55000000 55005500 55005500 012b0698 55005500 55005500 55005500 55005500 0:000> 012b06a8 55005500 55005500 55005500 55005500 012b06b8 55005500 55005500 55005500 55005500 012b06c8 55005500 55005500 55005500 55005500 012b06d8 55005500 55005500 55005500 55005500 012b06e8 55005500 55005500 55005500 55005500 012b06f8 55005500 55005500 55005500 55005500 012b0708 55005500 55005500 55005500 55005500 012b0718 55005500 55005500 55005500 55005500 0:000> 012b0728 55005500 55005500 55005500 55005500 012b0738 55005500 55005500 55005500 55005500 012b0748 55005500 55005500 55005500 55005500 012b0758 55005500 55005500 55005500 55005500 012b0768 55005500 55005500 55005500 55005500 012b0778 55005500 55005500 55005500 55005500 012b0788 55005500 55005500 55005500 55005500 012b0798 55005500 00000000 00000000 00555500 0:000> 012b07a8 00555500 00555500 00555500 00555500 012b07b8 00555500 00555500 00555500 00555500 012b07c8 00555500 00555500 00555500 00555500 012b07d8 00555500 00555500 00555500 00555500 012b07e8 00555500 00555500 00555500 00555500 012b07f8 00555500 00555500 00555500 00555500 012b0808 00555500 00555500 00555500 00555500 012b0818 00555500 00555500 00555500 00555500 0:000> 012b0828 00555500 00555500 00555500 00555500 012b0838 00555500 00555500 00555500 00555500 012b0848 00555500 00555500 00555500 00555500 012b0858 00555500 00555500 00555500 00555500 012b0868 00555500 00555500 00555500 00555500 012b0878 00555500 00555500 00555500 00555500 012b0888 00555500 00555500 00555500 00555500 012b0898 00555500 00555500 00555500 00555500 0:000> 012b08a8 00555500 00555500 00000000 55000000 012b08b8 55550055 55550055 55550055 55550055 012b08c8 55550055 55550055 55550055 55550055 012b08d8 55550055 55550055 55550055 55550055 012b08e8 55550055 55550055 55550055 55550055 012b08f8 55550055 55550055 55550055 55550055 012b0908 55550055 55550055 55550055 55550055 012b0918 55550055 55550055 55550055 55550055 0:000> 012b0928 55550055 55550055 55550055 55550055 012b0938 55550055 55550055 55550055 55550055 012b0948 55550055 55550055 55550055 55550055 012b0958 55550055 55550055 55550055 55550055 012b0968 55550055 55550055 55550055 55550055 012b0978 55550055 55550055 55550055 55550055 012b0988 55550055 55550055 55550055 55550055 012b0998 55550055 55550055 55550055 55550055 0:000> 012b09a8 55550055 55550055 55550055 55550055 012b09b8 55550055 55550055 55550055 00000000 012b09c8 55000000 55005500 55005500 55005500 012b09d8 55005500 55005500 55005500 55005500 012b09e8 55005500 55005500 55005500 55005500 012b09f8 55005500 55005500 55005500 55005500 012b0a08 55005500 55005500 55005500 55005500 012b0a18 55005500 55005500 55005500 55005500 0:000> 012b0a28 55005500 55005500 55005500 55005500 012b0a38 55005500 55005500 55005500 55005500 012b0a48 55005500 55005500 55005500 55005500 012b0a58 55005500 55005500 55005500 55005500 012b0a68 55005500 55005500 55005500 55005500 012b0a78 55005500 55005500 55005500 55005500 012b0a88 55005500 55005500 55005500 55005500 012b0a98 55005500 55005500 55005500 55005500 0:000> 012b0aa8 55005500 55005500 55005500 55005500 012b0ab8 55005500 55005500 55005500 55005500 012b0ac8 55005500 55005500 55005500 55005500 012b0ad8 00000000 55000000 55000055 55000055 012b0ae8 55000055 55000055 55000055 55000055 012b0af8 55000055 55000055 55000055 55000055 012b0b08 55000055 55000055 55000055 55000055 012b0b18 55000055 55000055 55000055 55000055 0:000> 012b0b28 55000055 55000055 55000055 55000055 012b0b38 55000055 55000055 55000055 55000055 012b0b48 55000055 55000055 55000055 55000055 012b0b58 55000055 55000055 55000055 55000055 012b0b68 55000055 55000055 55000055 55000055 012b0b78 55000055 55000055 55000055 55000055 012b0b88 55000055 55000055 55000055 55000055 012b0b98 55000055 55000055 55000055 55000055 0:000> 012b0ba8 55000055 55000055 55000055 55000055 012b0bb8 55000055 55000055 55000055 55000055 012b0bc8 55000055 55000055 55000055 55000055 012b0bd8 55000055 55000055 55000055 55000055 012b0be8 55000055 00000000 00000000 00555555 012b0bf8 00555555 00555555 00555555 00555555 012b0c08 00555555 00555555 00555555 00555555 012b0c18 00555555 00555555 00555555 00555555 0:000> 012b0c28 00555555 00555555 00555555 00555555 012b0c38 00555555 00555555 00555555 00555555 012b0c48 00555555 00555555 00555555 00555555 012b0c58 00555555 00555555 00555555 00555555 012b0c68 00555555 00555555 00555555 00555555 012b0c78 00555555 00555555 00555555 00555555 012b0c88 00555555 00555555 00555555 00555555 012b0c98 00555555 00555555 00555555 00555555 0:000> 012b0ca8 00555555 00555555 00555555 00555555 012b0cb8 00555555 00555555 00555555 00555555 012b0cc8 00555555 00555555 00555555 00555555 012b0cd8 00555555 00555555 00555555 00555555 012b0ce8 00555555 00555555 00555555 00555555 012b0cf8 00555555 00555555 00000000 55000000 012b0d08 55005500 55005500 55005500 55005500 012b0d18 55005500 55005500 55005500 55005500 0:000> 012b0d28 55005500 55005500 55005500 55005500 012b0d38 55005500 55005500 55005500 55005500 012b0d48 55005500 55005500 55005500 55005500 012b0d58 55005500 55005500 55005500 55005500 012b0d68 55005500 55005500 55005500 55005500 012b0d78 55005500 55005500 55005500 55005500 012b0d88 55005500 55005500 55005500 55005500 012b0d98 55005500 55005500 55005500 55005500 0:000> 012b0da8 55005500 55005500 55005500 55005500 012b0db8 55005500 55005500 55005500 55005500 012b0dc8 55005500 55005500 55005500 55005500 012b0dd8 55005500 55005500 55005500 55005500 012b0de8 55005500 55005500 55005500 55005500 012b0df8 55005500 55005500 55005500 55005500 012b0e08 55005500 55005500 55005500 00000000 012b0e18 00000000 00555500 00555500 00555500 0:000> 012b0e28 00555500 00555500 00555500 00555500 012b0e38 00555500 00555500 00555500 00555500 012b0e48 00555500 00555500 00555500 00555500 012b0e58 00555500 00555500 00555500 00555500 012b0e68 00555500 00555500 00555500 00555500 012b0e78 00555500 00555500 00555500 00555500 012b0e88 00555500 00555500 00555500 00555500 012b0e98 00555500 00555500 00555500 00555500 0:000> 012b0ea8 00555500 00555500 00555500 00555500 012b0eb8 00555500 00555500 00555500 00555500 012b0ec8 00555500 00555500 00555500 00555500 012b0ed8 00555500 00555500 00555500 00555500 012b0ee8 00555500 00555500 00555500 00555500 012b0ef8 00555500 00555500 00555500 00555500 012b0f08 00555500 00555500 00555500 00555500 012b0f18 00555500 00555500 00555500 00555500 0:000> 012b0f28 00000000 55000000 55550055 55550055 012b0f38 55550055 55550055 55550055 55550055 012b0f48 55550055 55550055 55550055 55550055 012b0f58 55550055 55550055 55550055 55550055 012b0f68 55550055 55550055 55550055 55550055 012b0f78 55550055 55550055 55550055 55550055 012b0f88 55550055 55550055 55550055 55550055 012b0f98 55550055 55550055 55550055 55550055 0:000> 012b0fa8 55550055 55550055 55550055 55550055 012b0fb8 55550055 55550055 55550055 55550055 012b0fc8 55550055 55550055 55550055 55550055 012b0fd8 55550055 55550055 55550055 55550055 012b0fe8 55550055 55550055 55550055 55550055 012b0ff8 55550055 55550055 55550055 55550055 012b1008 55550055 55550055 55550055 55550055 012b1018 55550055 55550055 55550055 55550055 0:000> 012b1028 55550055 55550055 55550055 55550055 012b1038 55550055 00000000 55000000 55005500 012b1048 55005500 55005500 55005500 55005500 012b1058 55005500 55005500 55005500 55005500 012b1068 55005500 55005500 55005500 55005500 012b1078 55005500 55005500 55005500 55005500 012b1088 55005500 55005500 55005500 55005500 012b1098 55005500 55005500 55005500 55005500 0:000> 012b10a8 55005500 55005500 55005500 55005500 012b10b8 55005500 55005500 55005500 55005500 012b10c8 55005500 55005500 55005500 55005500 012b10d8 55005500 55005500 55005500 55005500 012b10e8 55005500 55005500 55005500 55005500 012b10f8 55005500 55005500 55005500 55005500 012b1108 55005500 55005500 55005500 55005500 012b1118 55005500 55005500 55005500 55005500 0:000> 012b1128 55005500 55005500 55005500 55005500 012b1138 55005500 55005500 55005500 55005500 012b1148 55005500 55005500 00000000 55000000 012b1158 55000055 55000055 55000055 55000055 012b1168 55000055 55000055 55000055 55000055 012b1178 55000055 55000055 55000055 55000055 012b1188 55000055 55000055 55000055 55000055 012b1198 55000055 55000055 55000055 55000055 0:000> 012b11a8 55000055 55000055 55000055 55000055 012b11b8 55000055 55000055 55000055 55000055 012b11c8 55000055 55000055 55000055 55000055 012b11d8 55000055 55000055 55000055 55000055 012b11e8 55000055 55000055 55000055 55000055 012b11f8 55000055 55000055 55000055 55000055 012b1208 55000055 55000055 55000055 55000055 012b1218 55000055 55000055 55000055 55000055 0:000> 012b1228 55000055 55000055 55000055 55000055 012b1238 55000055 55000055 55000055 55000055 012b1248 55000055 55000055 55000055 55000055 012b1258 55000055 55000055 55000055 00000000 012b1268 00000000 00555555 00555555 00555555 012b1278 00555555 00555555 00555555 00555555 012b1288 00555555 00555555 00555555 00555555 012b1298 00555555 00555555 00555555 00555555 0:000> 012b12a8 00555555 00555555 00555555 00555555 012b12b8 00555555 00555555 00555555 00555555 012b12c8 00555555 00555555 00555555 00555555 012b12d8 00555555 00555555 00555555 00555555 012b12e8 00555555 00555555 00555555 00555555 012b12f8 00555555 00555555 00555555 00555555 012b1308 00555555 00555555 00555555 00555555 012b1318 00555555 00555555 00555555 00555555 0:000> 012b1328 00555555 00555555 00555555 00555555 012b1338 00555555 00555555 00555555 00555555 012b1348 00555555 00555555 00555555 00555555 012b1358 00555555 00555555 00555555 00555555 012b1368 00555555 00555555 00555555 00555555 012b1378 00000000 55000000 55005500 55005500 012b1388 55005500 55005500 55005500 55005500 012b1398 55005500 55005500 55005500 55005500 0:000> 012b13a8 55005500 55005500 55005500 55005500 012b13b8 55005500 55005500 55005500 55005500 012b13c8 55005500 55005500 55005500 55005500 012b13d8 55005500 55005500 55005500 55005500 012b13e8 55005500 55005500 55005500 55005500 012b13f8 55005500 55005500 55005500 55005500 012b1408 55005500 55005500 55005500 55005500 012b1418 55005500 55005500 55005500 55005500 0:000> 012b1428 55005500 55005500 55005500 55005500 012b1438 55005500 55005500 55005500 55005500 012b1448 55005500 55005500 55005500 55005500 012b1458 55005500 55005500 55005500 55005500 012b1468 55005500 55005500 55005500 55005500 012b1478 55005500 55005500 55005500 55005500 012b1488 55005500 00000000 00000000 00555500 012b1498 00555500 00555500 00555500 00555500 0:000> 012b14a8 00555500 00555500 00555500 00555500 012b14b8 00555500 00555500 00555500 00555500 012b14c8 00555500 00555500 00555500 00555500 012b14d8 00555500 00555500 00555500 00555500 012b14e8 00555500 00555500 00555500 00555500 012b14f8 00555500 00555500 00555500 00555500 012b1508 00555500 00555500 00555500 00555500 012b1518 00555500 00555500 00555500 00555500 0:000> 012b1528 00555500 00555500 00555500 00555500 012b1538 00555500 00555500 00555500 00555500 012b1548 00555500 00555500 00555500 00555500 012b1558 00555500 00555500 00555500 00555500 012b1568 00555500 00555500 00555500 00555500 012b1578 00555500 00555500 00555500 00555500 012b1588 00555500 00555500 00555500 00555500 012b1598 00555500 00555500 00000000 55000000 0:000> 012b15a8 55550055 55550055 55550055 55550055 012b15b8 55550055 55550055 55550055 55550055 012b15c8 55550055 55550055 55550055 55550055 012b15d8 55550055 55550055 55550055 55550055 012b15e8 55550055 ff550055 ffffffff ffffffff 012b15f8 ffffffff 55550055 ffffffff ffffffff 012b1608 555500ff 55550055 55550055 55550055 012b1618 55550055 55550055 ffff0055 ffffffff 0:000> 012b1628 5555ffff 55550055 ff550055 ffffffff 012b1638 55ffffff 55550055 55550055 55550055 012b1648 55550055 55550055 55550055 55550055 012b1658 55550055 55550055 55550055 55550055 012b1668 55550055 55550055 55550055 55550055 012b1678 55550055 55550055 55550055 55550055 012b1688 55550055 55550055 55550055 55550055 012b1698 55550055 55550055 55550055 55550055 0:000> 012b16a8 55550055 55550055 55550055 00000000 012b16b8 55000000 55005500 55005500 55005500 012b16c8 55005500 55005500 55005500 55005500 012b16d8 55005500 55005500 55005500 55005500 012b16e8 55005500 55005500 55005500 55005500 012b16f8 55005500 55005500 55005500 ffffff00 012b1708 ffffffff 550055ff 55005500 ff005500 012b1718 55ffffff 55005500 55005500 55005500 0:000> 012b1728 55005500 55005500 55005500 ff005500 012b1738 ffffffff 55ffffff 55005500 55005500 012b1748 ffffff00 550055ff 55005500 55005500 012b1758 55005500 55005500 55005500 55005500 012b1768 55005500 ff005500 ffffffff 55ffffff 012b1778 55005500 55005500 55005500 55005500 012b1788 55005500 55005500 55005500 55005500 012b1798 55005500 55005500 55005500 55005500 0:000> 012b17a8 55005500 55005500 55005500 55005500 012b17b8 55005500 55005500 55005500 55005500 012b17c8 00000000 55000000 55000055 55000055 012b17d8 55000055 55000055 55000055 55000055 012b17e8 ffffff55 ffffffff ffffffff ffffffff 012b17f8 ffffffff ffffffff 55000055 55000055 012b1808 55000055 55000055 55000055 55000055 012b1818 ffff0055 ffffffff 55000055 55000055 0:000> 012b1828 55000055 5500ffff 55000055 55000055 012b1838 55000055 55000055 55000055 55000055 012b1848 55000055 ffffffff ffffffff 55000055 012b1858 55000055 ffff0055 55000055 55000055 012b1868 55000055 55000055 55000055 55000055 012b1878 55000055 55000055 ffffffff 550000ff 012b1888 ffffff55 5500ffff 55000055 55000055 012b1898 55000055 55000055 55000055 55000055 0:000> 012b18a8 55000055 55000055 55000055 55000055 012b18b8 ffffff55 55ffffff 55000055 55000055 012b18c8 55000055 55000055 55000055 55000055 012b18d8 55000055 00000000 00000000 00555555 012b18e8 00555555 00555555 00555555 00555555 012b18f8 00555555 ffffff55 ffffffff ffffffff 012b1908 ffffffff ffffffff ffffffff 00555555 012b1918 00555555 00555555 00555555 00555555 0:000> 012b1928 00555555 ffff5555 ffffffff 00555555 012b1938 00555555 00555555 0055ffff 00555555 012b1948 00555555 00555555 00555555 00555555 012b1958 00555555 00555555 ffffff55 ffffffff 012b1968 005555ff 00555555 ffff5555 00555555 012b1978 00555555 00555555 00555555 00555555 012b1988 00555555 00555555 ff555555 00ffffff 012b1998 00555555 ff555555 00ffffff 00555555 0:000> 012b19a8 00555555 00555555 00555555 00555555 012b19b8 00555555 00555555 00555555 00555555 012b19c8 ffff5555 ffffffff ffffffff 0055ffff 012b19d8 00555555 00555555 00555555 00555555 012b19e8 00555555 00555555 00000000 55000000 012b19f8 55005500 55005500 55005500 55005500 012b1a08 55005500 55005500 55005500 ffff5500 012b1a18 ffffffff ffffffff ffffffff 55005500 0:000> 012b1a28 55005500 55005500 00005500 55005500 012b1a38 55005500 55005500 ffff5500 ffffffff 012b1a48 55005500 55005500 55005500 5500ffff 012b1a58 55005500 00005500 00550055 00550000 012b1a68 55000055 55005500 55005500 ffffff00 012b1a78 ffffffff 550055ff 55005500 ffff5500 012b1a88 55005500 55005500 00550000 00000055 012b1a98 00550055 55005500 55005500 ffff5500 0:000> 012b1aa8 5500ffff 55005500 55005500 ffffffff 012b1ab8 55005500 55005500 00005500 00550055 012b1ac8 00550000 55000055 55005500 55005500 012b1ad8 55005500 ffffff00 ffffffff ffffffff 012b1ae8 ffffffff 55005500 55005500 55005500 012b1af8 55005500 55005500 55005500 00000000 012b1b08 00000000 00555500 00555500 00555500 012b1b18 00555500 00555500 00555500 00555500 0:000> 012b1b28 ff555500 ffffffff ffffffff 00ffffff 012b1b38 00555500 00555500 00555500 00005500 012b1b48 00555500 00555500 00555500 ffff5500 012b1b58 ffffffff 00555500 00555500 00555500 012b1b68 0055ffff 00555500 55555500 00550000 012b1b78 55550000 00550000 00555500 00555500 012b1b88 ffffff00 ffffffff 0055ffff 00555500 012b1b98 ffff5500 00555500 00555500 00005500 0:000> 012b1ba8 00000055 00005555 00555500 00555500 012b1bb8 ffffff00 0055ffff 00555500 00555500 012b1bc8 ffffffff 005555ff 00555500 55555500 012b1bd8 00550000 55550000 00550000 00555500 012b1be8 00555500 ff555500 ffffffff ffffffff 012b1bf8 ffffffff ffffffff 005555ff 00555500 012b1c08 00555500 00555500 00555500 00555500 012b1c18 00000000 55000000 55550055 55550055 0:000> 012b1c28 55550055 55550055 55550055 55550055 012b1c38 55550055 55550055 ffffffff ffffffff 012b1c48 5555ffff 55550055 55550055 55550055 012b1c58 00000055 55550000 55550055 55550055 012b1c68 ffff0055 ffffffff 55550055 55550055 012b1c78 55550055 5555ffff 55550055 55550055 012b1c88 00005555 55000000 55555555 55550055 012b1c98 55550055 55ffff55 ffffffff 55ffffff 0:000> 012b1ca8 55550055 ffff0055 55550055 55550055 012b1cb8 55555555 00000000 55555500 55550055 012b1cc8 55550055 ffffffff 555500ff 55550055 012b1cd8 55550055 ffffff55 5555ffff 55550055 012b1ce8 55550055 00005555 55000000 55555555 012b1cf8 55550055 55550055 ffff0055 ffffffff 012b1d08 ffffffff ffffffff ffffffff 5555ffff 012b1d18 55550055 55550055 55550055 55550055 0:000> 012b1d28 55550055 00000000 55000000 55005500 012b1d38 55005500 55005500 55005500 55005500 012b1d48 55005500 55005500 55005500 ffffffff 012b1d58 ffffffff 5500ffff 55005500 55005500 012b1d68 55005500 00000000 55000000 55005500 012b1d78 55005500 ffff5500 ffffffff 55005500 012b1d88 55005500 55005500 5500ffff 55005500 012b1d98 00005500 00000055 00000000 55000055 0:000> 012b1da8 55005500 55005500 55ffff00 ffffffff 012b1db8 ffffffff 55005500 ffff5500 55005500 012b1dc8 55005500 00550000 00000000 00550000 012b1dd8 55005500 ff005500 ffffffff 550055ff 012b1de8 55005500 55005500 ffffff00 55ffffff 012b1df8 55005500 00005500 00000055 00000000 012b1e08 55000055 55005500 55005500 ffff5500 012b1e18 ffffffff ffffffff ffffffff ffffffff 0:000> 012b1e28 5500ffff 55005500 55005500 55005500 012b1e38 55005500 55005500 00000000 55000000 012b1e48 55000055 55000055 55000055 55000055 012b1e58 55000055 55000055 55000055 55000055 012b1e68 ffffffff ffffffff 5500ffff 55000055 012b1e78 55000055 55000055 00000055 55000000 012b1e88 55000055 55000055 ffff0055 ffffffff 012b1e98 55000055 55000055 55000055 5500ffff 0:000> 012b1ea8 55000055 00000055 00005555 00000000 012b1eb8 55005555 55000055 55000055 55ffff55 012b1ec8 ffffff55 ffffffff 550000ff ffff0055 012b1ed8 55000055 55000055 55550055 00000000 012b1ee8 55550000 55000055 ff000055 ffffffff 012b1ef8 55000055 55000055 55000055 ffff0055 012b1f08 55ffffff 55000055 00000055 00005555 012b1f18 00000000 55005555 55000055 55000055 0:000> 012b1f28 ffffff55 ffffffff ffffffff ffffffff 012b1f38 ffffffff 55ffffff 55000055 55000055 012b1f48 55000055 55000055 55000055 00000000 012b1f58 00000000 00555555 00555555 00555555 012b1f68 00555555 00555555 00555555 00555555 012b1f78 00555555 ffffffff ffffffff 0055ffff 012b1f88 00555555 00555555 00555555 00000000 012b1f98 00000000 00555555 00555555 ffff5555 0:000> 012b1fa8 ffffffff 00555555 00555555 00555555 012b1fb8 0055ffff 00555555 55555555 00000000 012b1fc8 00000000 00555500 00555555 00555555 012b1fd8 00ffff55 ffff5555 ffffffff 005555ff 012b1fe8 ffff5555 00555555 00555555 00005555 012b1ff8 00000000 55000000 00555555 ff555555 012b2008 ffffffff 00555555 00555555 00555555 012b2018 ffff5555 00ffffff 00555555 55555555 0:000> 012b2028 00000000 00000000 00555500 00555555 012b2038 00555555 ffffffff 005555ff ffff5555 012b2048 ffffffff ffffffff 00ffffff 00555555 012b2058 00555555 00555555 00555555 00555555 012b2068 00000000 55000000 55005500 55005500 012b2078 55005500 55005500 55005500 55005500 012b2088 55005500 55005500 ffffffff ffffffff 012b2098 5500ffff 55005500 55005500 55005500 0:000> 012b20a8 00000000 55000000 55005500 55005500 012b20b8 ffff5500 ffffffff 55005500 55005500 012b20c8 55005500 5500ffff 55005500 00005500 012b20d8 00000055 00000000 55000055 55005500 012b20e8 55005500 55ffff00 ff005500 ffffffff 012b20f8 5500ffff ffff5500 55005500 55005500 012b2108 00550000 00000000 00550000 55005500 012b2118 ffff5500 ffffffff 55005500 55005500 0:000> 012b2128 55005500 ffff5500 ffffffff 55005500 012b2138 00005500 00000055 00000000 55000055 012b2148 55005500 55005500 55ffffff 55005500 012b2158 55005500 ffffffff ffffffff ffffffff 012b2168 55005500 55005500 55005500 55005500 012b2178 55005500 00000000 00000000 00555500 012b2188 00555500 00555500 00555500 00555500 012b2198 00555500 00555500 00555500 ffffffff 0:000> 012b21a8 ffffffff 0055ffff 00555500 00555500 012b21b8 00555500 00000000 00000000 00555500 012b21c8 00555500 ffff5500 ffffffff 00555500 012b21d8 00555500 00555500 0055ffff 00555500 012b21e8 55555500 00000000 00000000 00550000 012b21f8 00555500 00555500 00ffff00 00555500 012b2208 ffffffff 00ffffff ffff5500 00555500 012b2218 00555500 00005500 00000000 00000000 0:000> 012b2228 00555500 ffff5500 ffffffff 00555500 012b2238 00555500 00555500 ffff5500 ffffffff 012b2248 00555500 55555500 00000000 00000000 012b2258 00550000 00555500 ff555500 0055ffff 012b2268 00555500 00555500 ffffff00 ffffffff 012b2278 ffffffff 00555500 00555500 00555500 012b2288 00555500 00555500 00000000 55000000 012b2298 55550055 55550055 55550055 55550055 0:000> 012b22a8 55550055 55550055 55550055 55550055 012b22b8 ffffffff ffffffff 5555ffff 55550055 012b22c8 55550055 00000055 00000000 00000000 012b22d8 55550000 55550055 ffff0055 ffffffff 012b22e8 55550055 55550055 55550055 5555ffff 012b22f8 55550055 00550055 00000000 00000000 012b2308 55550000 55550055 55550055 55ffff55 012b2318 55550055 ffffff55 ffffffff ffff0055 0:000> 012b2328 55550055 55550055 00000055 00000000 012b2338 00000000 55550055 ffff0055 ffffffff 012b2348 55550055 55550055 55550055 ffff0055 012b2358 ffffffff 55550055 00550055 00000000 012b2368 00000000 55550000 55550055 ff550055 012b2378 555500ff 55550055 55550055 ffff0055 012b2388 ffffffff ffffffff 55550055 55550055 012b2398 55550055 55550055 55550055 00000000 0:000> 012b23a8 55000000 55005500 55005500 55005500 012b23b8 55005500 55005500 55005500 55005500 012b23c8 55005500 ffffffff ffffffff 5500ffff 012b23d8 55005500 55005500 00005500 00000000 012b23e8 00000000 55005500 55005500 ffff5500 012b23f8 ffffffff 55005500 55005500 55005500 012b2408 5500ffff 55005500 00005500 00000000 012b2418 00000000 55000000 55005500 55005500 0:000> 012b2428 55ffff00 55005500 ffffff00 ffffffff 012b2438 ffff55ff 55005500 55005500 00000000 012b2448 00000000 00000000 55005500 ffff5500 012b2458 ffffffff 55005500 55005500 55005500 012b2468 ffff5500 ffffffff 55005500 00005500 012b2478 00000000 00000000 55000000 55005500 012b2488 ffff5500 55005500 55005500 55005500 012b2498 ffff5500 ffffffff ffffffff 55005500 0:000> 012b24a8 55005500 55005500 55005500 55005500 012b24b8 00000000 55000000 55000055 55000055 012b24c8 55000055 55000055 55000055 55000055 012b24d8 55000055 55000055 ffffffff ffffffff 012b24e8 5500ffff 55000055 55000055 00000055 012b24f8 00000000 00000000 55000000 55000055 012b2508 ffff0055 ffffffff 55000055 55000055 012b2518 55000055 5500ffff 55000055 00000055 0:000> 012b2528 00000000 00000000 55000000 55000055 012b2538 55000055 55ffff55 55000055 ffff0055 012b2548 ffffffff ffff00ff 55000055 55000055 012b2558 00000055 00000000 00000000 55000055 012b2568 ffff0055 ffffffff 55000055 55000055 012b2578 55000055 ffff0055 ffffffff 55000055 012b2588 00000055 00000000 00000000 55000000 012b2598 55000055 55000055 55000055 55000055 0:000> 012b25a8 55000055 ff000055 ffffffff ffffffff 012b25b8 55000055 55000055 55000055 55000055 012b25c8 55000055 00000000 00000000 00555555 012b25d8 00555555 00555555 00555555 00555555 012b25e8 00555555 00555555 00555555 ffffffff 012b25f8 ffffffff 0055ffff 00555555 00555555 012b2608 00555555 00000000 00000000 00555555 012b2618 00555555 ffff5555 ffffffff 00555555 0:000> 012b2628 00555555 00555555 0055ffff 00555555 012b2638 55555555 00000000 00000000 00555500 012b2648 00555555 00555555 00ffff55 00555555 012b2658 ff555555 ffffffff ffffffff 00555555 012b2668 00555555 00005555 00000000 55000000 012b2678 00555555 ffff5555 ffffffff 00555555 012b2688 00555555 00555555 ffff5555 ffffffff 012b2698 00555555 55555555 00000000 00000000 0:000> 012b26a8 00555500 00555555 00555555 00555555 012b26b8 00555555 00555555 ff555555 ffffffff 012b26c8 ffffffff 00555555 00555555 00555555 012b26d8 00555555 00555555 00000000 55000000 012b26e8 55005500 55005500 55005500 55005500 012b26f8 55005500 55005500 55005500 55005500 012b2708 ffffffff ffffffff 5500ffff 55005500 012b2718 55005500 55005500 00000000 55000000 0:000> 012b2728 55005500 55005500 ffff5500 ffffffff 012b2738 55005500 55005500 55005500 5500ffff 012b2748 55005500 00005500 00000055 00000000 012b2758 55000055 55005500 55005500 55ffff00 012b2768 55005500 55005500 ffffffff ffffffff 012b2778 55005500 55005500 00550000 00000000 012b2788 00550000 55005500 ffff5500 ffffffff 012b2798 55005500 55005500 55005500 ffff5500 0:000> 012b27a8 ffffffff 55005500 00005500 00000055 012b27b8 00000000 55000055 55005500 55005500 012b27c8 55005500 55005500 55005500 ff005500 012b27d8 ffffffff 55ffffff 55005500 55005500 012b27e8 55005500 55005500 55005500 00000000 012b27f8 00000000 00555500 00555500 00555500 012b2808 00555500 00555500 00555500 00555500 012b2818 00555500 ffffffff ffffffff 0055ffff 0:000> 012b2828 00555500 00555500 00555500 00000000 012b2838 00000000 00555500 00555500 ffff5500 012b2848 ffffffff 00555500 00555500 00555500 012b2858 0055ffff 00555500 55555500 00000000 012b2868 00000000 00550000 00555500 00555500 012b2878 00ffff00 00555500 00555500 ffffff00 012b2888 ffffffff 00555500 00555500 00005500 012b2898 00000000 00000000 00555500 ff555500 0:000> 012b28a8 ffffffff 00555500 00555500 00555500 012b28b8 ffff5500 00ffffff 00555500 55555500 012b28c8 00000000 00000000 00550000 00555500 012b28d8 00555500 00555500 00555500 00555500 012b28e8 ff555500 ffffffff 00ffffff 00555500 012b28f8 00555500 00555500 00555500 00555500 012b2908 00000000 55000000 55550055 55550055 012b2918 55550055 55550055 55550055 55550055 0:000> 012b2928 55550055 55550055 ffffffff ffffffff 012b2938 5555ffff 55550055 55550055 55550055 012b2948 00000055 55550000 55550055 55550055 012b2958 ffff0055 ffffffff 55550055 55550055 012b2968 55550055 555500ff 55550055 55550055 012b2978 00005555 55000000 55555555 55550055 012b2988 55550055 55ffff55 55550055 55550055 012b2998 ffffff55 ffffffff 55550055 55550055 0:000> 012b29a8 55555555 00000000 55555500 55550055 012b29b8 ff550055 ffffffff 55550055 55550055 012b29c8 55550055 ffff0055 55ffffff 55550055 012b29d8 55550055 00005555 55000000 55555555 012b29e8 55550055 55550055 55550055 55550055 012b29f8 55550055 ff550055 ffffffff 55ffffff 012b2a08 55550055 55550055 55550055 55550055 012b2a18 55550055 00000000 55000000 55005500 0:000> 012b2a28 55005500 55005500 55005500 55005500 012b2a38 55005500 55005500 55005500 ffffffff 012b2a48 ffffffff 5500ffff 55005500 55005500 012b2a58 55005500 00000000 55000000 55005500 012b2a68 55005500 ff005500 ffffffff 55005500 012b2a78 55005500 ff005500 550055ff 55005500 012b2a88 00005500 00000055 00000000 55000055 012b2a98 55005500 55005500 55ffff00 55005500 0:000> 012b2aa8 55005500 ffff5500 ffffffff 55005500 012b2ab8 55005500 00550000 00000000 00550000 012b2ac8 55005500 ff005500 ffffffff 550055ff 012b2ad8 55005500 55005500 ffffff00 55ffffff 012b2ae8 55005500 00005500 00000055 00000000 012b2af8 55000055 55005500 55005500 55005500 012b2b08 55005500 55005500 ff005500 ffffffff 012b2b18 5500ffff 55005500 55005500 55005500 0:000> 012b2b28 55005500 55005500 00000000 55000000 012b2b38 55000055 55000055 55000055 55000055 012b2b48 55000055 55000055 55000055 55000055 012b2b58 ffffffff ffffffff 5500ffff 55000055 012b2b68 55000055 55000055 00000055 55000000 012b2b78 55000055 55000055 ff000055 ffffffff 012b2b88 550000ff 55000055 ff000055 550000ff 012b2b98 55000055 00000055 00005555 00000000 0:000> 012b2ba8 55005555 55000055 55000055 55ffff55 012b2bb8 55000055 55000055 ff000055 ffffffff 012b2bc8 55000055 55000055 55550055 00000000 012b2bd8 55550000 55000055 55000055 ffffffff 012b2be8 550000ff 55000055 55000055 ffffff55 012b2bf8 5500ffff 55000055 00000055 00005555 012b2c08 00000000 55005555 55000055 55000055 012b2c18 55000055 55000055 55000055 ffff0055 0:000> 012b2c28 ffffffff 5500ffff 55000055 55000055 012b2c38 55000055 55000055 55000055 00000000 012b2c48 00000000 00555555 00555555 00555555 012b2c58 00555555 00555555 00555555 00555555 012b2c68 00555555 ffffffff ffffffff 0055ffff 012b2c78 00555555 00555555 00555555 00005555 012b2c88 00555500 00555555 00555555 00555555 012b2c98 ffffffff 005555ff 00555555 ffff5555 0:000> 012b2ca8 00555555 00555555 55555555 00555500 012b2cb8 55550000 00555500 00555555 00555555 012b2cc8 00ffff55 00555555 00555555 00555555 012b2cd8 ffffffff 00555555 00555555 55005555 012b2ce8 00000055 55005555 00555555 00555555 012b2cf8 ffffff55 005555ff 00555555 00555555 012b2d08 ffffff55 005555ff 00555555 55555555 012b2d18 00555500 55550000 00555500 00555555 0:000> 012b2d28 00555555 00555555 00555555 00555555 012b2d38 ffff5555 ffffffff 005555ff 00555555 012b2d48 00555555 00555555 00555555 00555555 012b2d58 00000000 55000000 55005500 55005500 012b2d68 55005500 55005500 55005500 55005500 012b2d78 55005500 55005500 ffffffff ffffffff 012b2d88 5500ffff 55005500 55005500 55005500 012b2d98 00005500 55005500 55005500 55005500 0:000> 012b2da8 55005500 ffffff00 55ffffff 55005500 012b2db8 55ffff00 55005500 55005500 00005500 012b2dc8 00550055 00550000 55000055 55005500 012b2dd8 55005500 55ffff00 55005500 55005500 012b2de8 55005500 ffffff00 55005500 55005500 012b2df8 00550000 00000055 00550055 55005500 012b2e08 55005500 ffffff00 5500ffff 55005500 012b2e18 55005500 ffffffff 55005500 55005500 0:000> 012b2e28 00005500 00550055 00550000 55000055 012b2e38 55005500 55005500 55005500 55005500 012b2e48 55005500 ffff5500 ffffffff 55005500 012b2e58 55005500 55005500 55005500 55005500 012b2e68 55005500 00000000 00000000 00555500 012b2e78 00555500 00555500 00555500 00555500 012b2e88 00555500 00555500 00555500 ffffffff 012b2e98 ffffffff 0055ffff 00555500 00555500 0:000> 012b2ea8 00555500 00555500 00555500 00555500 012b2eb8 00555500 00555500 ffff5500 ffffffff 012b2ec8 ffffffff 0055ffff 00555500 00555500 012b2ed8 00555500 00555500 00555500 00555500 012b2ee8 00555500 00555500 ffffffff 00555500 012b2ef8 00555500 00555500 ffff5500 00555500 012b2f08 00555500 00555500 00555500 00555500 012b2f18 00555500 00555500 ff555500 00ffffff 0:000> 012b2f28 00555500 ff555500 00ffffff 00555500 012b2f38 00555500 00555500 00555500 00555500 012b2f48 00555500 00555500 00555500 00555500 012b2f58 00555500 00555500 ffffff00 ffffffff 012b2f68 00555500 00555500 00555500 00555500 012b2f78 00555500 00555500 00000000 55000000 012b2f88 55550055 55550055 55550055 55550055 012b2f98 55550055 55550055 55550055 55550055 0:000> 012b2fa8 ffffffff ffffffff 5555ffff 55550055 012b2fb8 55550055 55550055 55550055 55550055 012b2fc8 55550055 55550055 55550055 55550055 012b2fd8 ffffff55 55ffffff 55550055 55550055 012b2fe8 55550055 55550055 55550055 55550055 012b2ff8 55550055 55550055 ffff0055 ffffffff 012b3008 5555ffff 55550055 55550055 ffff0055 012b3018 55550055 55550055 55550055 55550055 0:000> 012b3028 55550055 55550055 55550055 55550055 012b3038 ffffffff 55550055 ffff0055 5555ffff 012b3048 55550055 55550055 55550055 55550055 012b3058 55550055 55550055 55550055 55550055 012b3068 55550055 55550055 55550055 ffffff55 012b3078 55ffffff 55550055 55550055 55550055 012b3088 55550055 55550055 55550055 00000000 012b3098 55000000 55005500 55005500 55005500 0:000> 012b30a8 55005500 55005500 55005500 55005500 012b30b8 55005500 ffffffff ffffffff 5500ffff 012b30c8 55005500 55005500 55005500 55005500 012b30d8 55005500 55005500 55005500 55005500 012b30e8 55005500 55005500 55005500 55005500 012b30f8 55005500 55005500 55005500 55005500 012b3108 55005500 55005500 55005500 55005500 012b3118 55005500 55005500 55005500 55005500 0:000> 012b3128 55005500 55005500 55005500 55005500 012b3138 55005500 55005500 55005500 55005500 012b3148 55005500 ff005500 ffffffff 55ffffff 012b3158 55005500 55005500 55005500 55005500 012b3168 55005500 55005500 55005500 55005500 012b3178 55005500 55005500 55005500 55005500 012b3188 ffffffff 5500ffff 55005500 55005500 012b3198 55005500 55005500 55005500 55005500 0:000> 012b31a8 00000000 55000000 55000055 55000055 012b31b8 55000055 55000055 55000055 55000055 012b31c8 55000055 55000055 ffffffff ffffffff 012b31d8 5500ffff 55000055 55000055 55000055 012b31e8 55000055 55000055 55000055 55000055 012b31f8 55000055 55000055 55000055 55000055 012b3208 55000055 55000055 55000055 55000055 012b3218 55000055 55000055 55000055 55000055 0:000> 012b3228 55000055 55000055 55000055 55000055 012b3238 55000055 55000055 55000055 55000055 012b3248 55000055 55000055 55000055 55000055 012b3258 55000055 55000055 55000055 55000055 012b3268 55000055 55000055 55000055 55000055 012b3278 55000055 55000055 55000055 55000055 012b3288 55000055 55000055 55000055 55000055 012b3298 ff000055 ffffffff 550000ff 55000055 0:000> 012b32a8 55000055 55000055 55000055 55000055 012b32b8 55000055 00000000 00000000 00555555 012b32c8 00555555 00555555 00555555 00555555 012b32d8 00555555 00555555 00555555 ffffffff 012b32e8 ffffffff 0055ffff 00555555 00555555 012b32f8 00555555 00555555 00555555 00555555 012b3308 00555555 00555555 00555555 00555555 012b3318 00555555 00555555 00555555 00555555 0:000> 012b3328 00555555 00555555 00555555 00555555 012b3338 00555555 00555555 00555555 00555555 012b3348 00555555 00555555 00555555 00555555 012b3358 00555555 00555555 00555555 00555555 012b3368 00555555 00555555 00555555 00555555 012b3378 00555555 00555555 00555555 00555555 012b3388 00555555 00555555 00555555 00555555 012b3398 00555555 00555555 00555555 00555555 0:000> 012b33a8 00555555 ff555555 ffffffff 00555555 012b33b8 00555555 00555555 00555555 00555555 012b33c8 00555555 00555555 00000000 55000000 012b33d8 55005500 55005500 55005500 55005500 012b33e8 55005500 55005500 55005500 55005500 012b33f8 ffffffff ffffffff 5500ffff 55005500 012b3408 55005500 55005500 55005500 55005500 012b3418 55005500 55005500 55005500 55005500 0:000> 012b3428 55005500 55005500 55005500 55005500 012b3438 55005500 55005500 55005500 55005500 012b3448 55005500 55005500 55005500 55005500 012b3458 55005500 55005500 55005500 55005500 012b3468 55005500 55005500 55005500 55005500 012b3478 55005500 55005500 55005500 55005500 012b3488 55005500 55005500 55005500 55005500 012b3498 55005500 55005500 55005500 55005500 0:000> 012b34a8 55005500 55005500 55005500 55005500 012b34b8 55005500 55005500 ffff5500 55ffffff 012b34c8 55005500 55005500 55005500 55005500 012b34d8 55005500 55005500 55005500 00000000 012b34e8 00000000 00555500 00555500 00555500 012b34f8 00555500 00555500 00555500 00555500 012b3508 00555500 ffffffff ffffffff 0055ffff 012b3518 00555500 00555500 00555500 00555500 0:000> 012b3528 00555500 00555500 00555500 00555500 012b3538 00555500 00555500 00555500 00555500 012b3548 00555500 00555500 00555500 00555500 012b3558 00555500 00555500 00555500 00555500 012b3568 00555500 00555500 00555500 00555500 012b3578 00555500 00555500 00555500 00555500 012b3588 00555500 00555500 00555500 00555500 012b3598 00555500 00555500 00555500 00555500 0:000> 012b35a8 00555500 00555500 00555500 00555500 012b35b8 00555500 00555500 00555500 00555500 012b35c8 00555500 00555500 00555500 ffffff00 012b35d8 005555ff 00555500 00555500 00555500 012b35e8 00555500 00555500 00555500 00555500 012b35f8 00000000 55000000 55550055 55550055 012b3608 55550055 55550055 55550055 55550055 012b3618 55550055 55550055 ffffffff ffffffff 0:000> 012b3628 5555ffff 55550055 55550055 55550055 012b3638 55550055 55550055 55550055 55550055 012b3648 55550055 55550055 55550055 55550055 012b3658 55550055 55550055 55550055 55550055 012b3668 55550055 55550055 55550055 55550055 012b3678 55550055 55550055 55550055 55550055 012b3688 55550055 55550055 55550055 55550055 012b3698 55550055 55550055 55550055 55550055 0:000> 012b36a8 55550055 55550055 55550055 55550055 012b36b8 55550055 55550055 55550055 55550055 012b36c8 55550055 55550055 55550055 55550055 012b36d8 55550055 55550055 55550055 55550055 012b36e8 ffffffff 55550055 55550055 55550055 012b36f8 55550055 55550055 55550055 55550055 012b3708 55550055 00000000 55000000 55005500 012b3718 55005500 55005500 55005500 55005500 0:000> 012b3728 55005500 55005500 55005500 ffffffff 012b3738 ffffffff 5500ffff 55005500 55005500 012b3748 55005500 55005500 55005500 55005500 012b3758 55005500 55005500 55005500 55005500 012b3768 55005500 55005500 55005500 55005500 012b3778 55005500 55005500 55005500 55005500 012b3788 55005500 55005500 55005500 55005500 012b3798 55005500 55005500 55005500 55005500 0:000> 012b37a8 55005500 55005500 55005500 55005500 012b37b8 55005500 55005500 55005500 55005500 012b37c8 55005500 55005500 55005500 55005500 012b37d8 55005500 55005500 55005500 55005500 012b37e8 55005500 55005500 55005500 55005500 012b37f8 55005500 55ffffff 55005500 55005500 012b3808 55005500 55ffff00 55005500 55005500 012b3818 55005500 55005500 00000000 55000000 0:000> 012b3828 55000055 55000055 55000055 55000055 012b3838 55000055 55000055 55000055 55000055 012b3848 ffffffff ffffffff 5500ffff 55000055 012b3858 55000055 55000055 55000055 55000055 012b3868 55000055 55000055 00000055 55000055 012b3878 55000055 55000055 55000055 55000055 012b3888 55000055 00000055 55000000 55000055 012b3898 55000055 55000055 55000055 55000055 0:000> 012b38a8 55000055 00000000 55000055 55000055 012b38b8 55000055 55000055 55000055 55000055 012b38c8 00000055 55000000 55000055 55000055 012b38d8 55000055 55000055 55000055 55000055 012b38e8 55000000 55000055 55000055 55000055 012b38f8 55000055 55000055 55000055 55000055 012b3908 55000055 ff000055 5500ffff 55000055 012b3918 55000055 55000055 5500ffff 55000055 0:000> 012b3928 55000055 55000055 55000055 00000000 012b3938 00000000 00555555 00555555 00555555 012b3948 00555555 00555555 00555555 00555555 012b3958 00555555 ffffffff ffffffff 0055ffff 012b3968 00555555 00555555 00555555 00555555 012b3978 00555555 00555555 00555555 00000000 012b3988 00550000 00555555 00555555 00555555 012b3998 00555555 00555555 00000055 00000000 0:000> 012b39a8 00555555 00555555 00555555 00555555 012b39b8 00555555 00555555 00000000 00555500 012b39c8 00555555 00555555 00555555 00555555 012b39d8 00555555 00000055 00000000 00555555 012b39e8 00555555 00555555 00555555 00555555 012b39f8 00555555 00000000 00555500 00555555 012b3a08 00555555 00555555 00555555 00555555 012b3a18 00555555 00555555 ffff5555 005555ff 0:000> 012b3a28 00555555 00555555 00555555 0055ffff 012b3a38 00555555 00555555 00555555 00555555 012b3a48 00000000 55000000 55005500 55005500 012b3a58 55005500 55005500 55005500 55005500 012b3a68 55005500 55005500 ffffffff ffffffff 012b3a78 5500ffff 55005500 55005500 55005500 012b3a88 55005500 55005500 55005500 00005500 012b3a98 00000000 55000000 55005500 55005500 0:000> 012b3aa8 55005500 55005500 55005500 00000000 012b3ab8 00000000 55005500 55005500 55005500 012b3ac8 55005500 55005500 00005500 00000000 012b3ad8 55000000 55005500 55005500 55005500 012b3ae8 55005500 00005500 00000000 00000000 012b3af8 55005500 55005500 55005500 55005500 012b3b08 55005500 00000000 00000000 55000000 012b3b18 55005500 55005500 55005500 55005500 0:000> 012b3b28 55005500 55005500 55005500 ffffff00 012b3b38 55005500 55005500 55005500 ff005500 012b3b48 5500ffff 55005500 55005500 55005500 012b3b58 55005500 00000000 00000000 00555500 012b3b68 00555500 00555500 00555500 00555500 012b3b78 00555500 00555500 00555500 ffffffff 012b3b88 ffffffff 0055ffff 00555500 00555500 012b3b98 00555500 00555500 00555500 00555500 0:000> 012b3ba8 00000000 00000000 00000000 00555500 012b3bb8 00555500 00555500 00555500 00005500 012b3bc8 00000000 00000000 00550000 00555500 012b3bd8 00555500 00555500 00555500 00000000 012b3be8 00000000 00000000 00555500 00555500 012b3bf8 00555500 00555500 00005500 00000000 012b3c08 00000000 00550000 00555500 00555500 012b3c18 00555500 00555500 00000000 00000000 0:000> 012b3c28 00000000 00555500 00555500 00555500 012b3c38 00555500 00555500 00555500 00555500 012b3c48 00ffffff 00555500 00555500 00555500 012b3c58 ffff5500 0055ffff 00555500 00555500 012b3c68 00555500 00555500 00000000 55000000 012b3c78 55550055 55550055 55550055 55550055 012b3c88 55550055 55550055 55550055 55550055 012b3c98 ffffffff ffffffff 5555ffff 55550055 0:000> 012b3ca8 55550055 55550055 55550055 55550055 012b3cb8 00550055 00000000 00000000 00000000 012b3cc8 55550000 55550055 55550055 55550055 012b3cd8 00000055 00000000 00000000 00000000 012b3ce8 55550055 55550055 55550055 00550055 012b3cf8 00000000 00000000 00000000 55550000 012b3d08 55550055 55550055 55550055 00000055 012b3d18 00000000 00000000 55000000 55550055 0:000> 012b3d28 55550055 55550055 00000055 00000000 012b3d38 00000000 00000000 55550000 55550055 012b3d48 55550055 55550055 55550055 55550055 012b3d58 ff550055 ffffffff ffffffff ffffffff 012b3d68 ffffffff ffffffff 555500ff 55550055 012b3d78 55550055 55550055 55550055 00000000 012b3d88 55000000 55005500 55005500 55005500 012b3d98 55005500 55005500 5500ff00 55005500 0:000> 012b3da8 55005500 ffffffff ffffffff 5500ffff 012b3db8 55005500 55005500 55005500 55005500 012b3dc8 55005500 00005500 00000000 00000000 012b3dd8 00000000 55000000 55005500 55005500 012b3de8 55005500 00000000 00000000 00000000 012b3df8 00000000 55005500 55005500 55005500 012b3e08 00000000 00000000 00000000 00000000 012b3e18 55000000 55005500 55005500 00005500 0:000> 012b3e28 00000000 55000000 00000000 00000000 012b3e38 55005500 55005500 55005500 00000000 012b3e48 00000000 00005500 00000000 55000000 012b3e58 55005500 55005500 55005500 55005500 012b3e68 55005500 ffff5500 ffffffff ffffffff 012b3e78 ffffffff ffffffff ffffffff 550055ff 012b3e88 55005500 55005500 55005500 55005500 012b3e98 00000000 55000000 55000055 55000055 0:000> 012b3ea8 55000055 55000055 ff000055 ffffffff 012b3eb8 55000055 55000055 ffffffff ffffffff 012b3ec8 5500ffff 55000055 55000055 55000055 012b3ed8 55000055 55000055 00000000 00000000 012b3ee8 55000000 00000000 00000000 55000000 012b3ef8 55000055 00000055 00000000 55000000 012b3f08 00000055 00000000 55000000 55000055 012b3f18 55000055 00000000 00000000 55000055 0:000> 012b3f28 00000000 00000000 55000055 55000055 012b3f38 00000055 00000000 55000000 00000055 012b3f48 00000000 55000000 55000055 55000055 012b3f58 00000000 00000000 00000055 00000000 012b3f68 00000000 55000055 55000055 55000055 012b3f78 55000055 55000055 ffffff55 ffffffff 012b3f88 ffffffff ffffffff ffffffff ffffffff 012b3f98 550000ff 55000055 55000055 55000055 0:000> 012b3fa8 55000055 00000000 00000000 00555555 012b3fb8 00555555 00555555 00555555 ffff5555 012b3fc8 ffffffff 005555ff 00555555 ffffffff 012b3fd8 ffffffff 0055ffff 00555555 00555555 012b3fe8 00555555 00555555 00555555 00000000 012b3ff8 00000000 00555555 00005555 00000000 012b4008 00550000 00555555 00000055 00000000 012b4018 00555500 00555555 00000000 00000000 0:000> 012b4028 00555555 00555555 00000000 00000000 012b4038 00555555 00000055 00000000 00550000 012b4048 00555555 00000000 00000000 00555500 012b4058 00555555 00000000 00000000 00555555 012b4068 00005555 00000000 00000000 00555555 012b4078 00000055 00000000 00555500 00555555 012b4088 00555555 00555555 00555555 ffffff55 012b4098 ffffffff ffffffff ffffffff ffffffff 0:000> 012b40a8 ffffffff 005555ff 00555555 00555555 012b40b8 00555555 00555555 00000000 55000000 012b40c8 55005500 55005500 55005500 55005500 012b40d8 ffffff00 ffffffff 5500ffff 55005500 012b40e8 ffffffff ffffffff 5500ffff 55005500 012b40f8 55005500 55005500 55005500 00005500 012b4108 00000000 55000000 55005500 00005500 012b4118 00000000 55000000 00005500 00000000 0:000> 012b4128 00000000 55005500 55005500 00000000 012b4138 00000000 55005500 00000000 00000000 012b4148 55000000 55005500 00005500 00000000 012b4158 55000000 00005500 00000000 55000000 012b4168 55005500 55005500 00000000 00000000 012b4178 55005500 00000000 00000000 55005500 012b4188 55005500 00005500 00000000 55000000 012b4198 55005500 55005500 55005500 55005500 0:000> 012b41a8 ffffffff ffffffff ffffffff ffffffff 012b41b8 ffffffff ffffffff 550055ff 55005500 012b41c8 55005500 55005500 55005500 00000000 012b41d8 00000000 00555500 00555500 00555500 012b41e8 00555500 ffffff00 ffffffff 0055ffff 012b41f8 00555500 ffffffff ffffffff 005555ff 012b4208 00555500 00555500 00555500 00555500 012b4218 00000000 00000000 00555500 00555500 0:000> 012b4228 00555500 00000000 00000000 00005500 012b4238 00000000 00550000 00555500 00555500 012b4248 00005500 00000000 00000000 00000000 012b4258 00000000 00555500 00555500 00555500 012b4268 00000000 00000000 00005500 00000000 012b4278 00550000 00555500 00555500 00005500 012b4288 00000000 00550000 00000000 00000000 012b4298 00555500 00555500 00555500 00000000 0:000> 012b42a8 00000000 00555500 00555500 00555500 012b42b8 ff555500 ffffffff ffffffff ffffffff 012b42c8 ffffffff ffffffff ffffffff 00555500 012b42d8 00555500 00555500 00555500 00555500 012b42e8 00000000 55000000 55550055 55550055 012b42f8 55550055 55550055 ffffff55 ffffffff 012b4308 5555ffff 55550055 ffffffff ffffffff 012b4318 555500ff 55550055 55550055 55550055 0:000> 012b4328 00550055 00000000 55000000 55550055 012b4338 55550055 55550055 00000055 00000000 012b4348 00000000 00000000 55550000 55550055 012b4358 55550055 55550055 00000000 00000000 012b4368 00000000 55000000 55550055 55550055 012b4378 55550055 00000055 00000000 00000000 012b4388 00000000 55550000 55550055 55550055 012b4398 00550055 00000000 00000000 00000000 0:000> 012b43a8 55550000 55550055 55550055 55550055 012b43b8 00000055 00000000 55550000 55550055 012b43c8 55550055 ffff0055 ffffffff ffffffff 012b43d8 ffffffff ffffffff ffffffff ffffffff 012b43e8 55550055 55550055 55550055 55550055 012b43f8 55550055 00000000 55000000 55005500 012b4408 55005500 55005500 55005500 ffffff00 012b4418 ffffffff 5500ffff 55005500 ffffffff 0:000> 012b4428 ffffffff 550055ff 55005500 55005500 012b4438 55005500 00000000 00000000 55000000 012b4448 55005500 55005500 55005500 00005500 012b4458 00000000 00000000 00000000 55005500 012b4468 55005500 55005500 55005500 00000000 012b4478 00000000 00000000 55005500 55005500 012b4488 55005500 55005500 00005500 00000000 012b4498 00000000 55000000 55005500 55005500 0:000> 012b44a8 55005500 55005500 00000000 00000000 012b44b8 00000000 55005500 55005500 55005500 012b44c8 55005500 00005500 00000000 55000000 012b44d8 55005500 55005500 ffffff00 ffffffff 012b44e8 ffffffff ffffffff ffffffff ffffffff 012b44f8 ffffffff 55005500 55005500 55005500 012b4508 55005500 55005500 00000000 55000000 012b4518 55000055 55000055 55000055 55000055 0:000> 012b4528 ffff0055 ffffffff 550000ff 55000055 012b4538 ffffffff ffffffff 55000055 55000055 012b4548 55000055 55000055 00000055 00000000 012b4558 55000055 55000055 55000055 55000055 012b4568 55000055 00000055 00000000 55000000 012b4578 55000055 55000055 55000055 55000055 012b4588 00000055 00000000 00000000 55000055 012b4598 55000055 55000055 55000055 55000055 0:000> 012b45a8 00000000 00000000 55000000 55000055 012b45b8 55000055 55000055 55000055 00000055 012b45c8 00000000 00000000 55000055 55000055 012b45d8 55000055 55000055 55000055 00000000 012b45e8 55000000 55000055 55000055 ffffff55 012b45f8 ffffffff ffffffff ffffffff ffffffff 012b4608 ffffffff ffffffff 55000055 55000055 012b4618 55000055 55000055 55000055 00000000 0:000> 012b4628 00000000 00555555 00555555 00555555 012b4638 00555555 ffff5555 ffffffff 00555555 012b4648 00555555 ffffffff 00ffffff 00555555 012b4658 00555555 00555555 00555555 00000055 012b4668 00000000 00555555 00555555 00555555 012b4678 00555555 00555555 00005555 00000000 012b4688 00555500 00555555 00555555 00555555 012b4698 00555555 00555555 00000000 00000000 0:000> 012b46a8 00555555 00555555 00555555 00555555 012b46b8 00555555 00005555 00000000 00555555 012b46c8 00555555 00555555 00555555 00555555 012b46d8 00555555 00000000 00550000 00555555 012b46e8 00555555 00555555 00555555 00555555 012b46f8 00000055 00000000 00555555 00555555 012b4708 00555555 00555555 00555555 00555555 012b4718 00555555 00555555 00555555 00555555 0:000> 012b4728 00555555 00555555 00555555 00555555 012b4738 00000000 55000000 55005500 55005500 012b4748 55005500 55005500 ff005500 ffffffff 012b4758 55005500 ff005500 ffffffff 55ffffff 012b4768 55005500 55005500 55005500 55005500 012b4778 00005500 55000000 55005500 55005500 012b4788 55005500 55005500 55005500 00005500 012b4798 55000000 55005500 55005500 55005500 0:000> 012b47a8 55005500 55005500 55005500 00000000 012b47b8 55005500 55005500 55005500 55005500 012b47c8 55005500 55005500 00005500 55000000 012b47d8 55005500 55005500 55005500 55005500 012b47e8 55005500 55005500 00000000 55005500 012b47f8 55005500 55005500 55005500 55005500 012b4808 55005500 00005500 55000000 55005500 012b4818 55005500 55005500 55005500 55005500 0:000> 012b4828 55005500 55005500 55005500 55005500 012b4838 55005500 55005500 55005500 55005500 012b4848 55005500 00000000 00000000 00555500 012b4858 00555500 00555500 00555500 00555500 012b4868 ffffffff 005555ff ffff5500 ffffffff 012b4878 005555ff 00555500 00555500 00555500 012b4888 00555500 00005500 00555500 00555500 012b4898 00555500 00555500 00555500 00555500 0:000> 012b48a8 00555500 00550000 00555500 00555500 012b48b8 00555500 00555500 00555500 00555500 012b48c8 00555500 00555500 00555500 00555500 012b48d8 00555500 00555500 00555500 00555500 012b48e8 00550000 00555500 00555500 00555500 012b48f8 00555500 00555500 00555500 00005500 012b4908 00555500 00555500 00555500 00555500 012b4918 00555500 00555500 00555500 00550000 0:000> 012b4928 00555500 00555500 00555500 00555500 012b4938 00555500 00555500 00555500 00555500 012b4948 00555500 00555500 00555500 00555500 012b4958 00555500 00555500 00000000 55000000 012b4968 55550055 55550055 55550055 55550055 012b4978 55550055 ffffff55 ffffffff ffffffff 012b4988 ffffffff 55550055 55550055 55550055 012b4998 55550055 55550055 55550055 55550055 0:000> 012b49a8 55550055 55550055 55550055 55550055 012b49b8 55550055 55550055 55550055 55550055 012b49c8 55550055 55550055 55550055 55550055 012b49d8 55550055 55550055 55550055 55550055 012b49e8 55550055 55550055 55550055 55550055 012b49f8 55550055 55550055 55550055 55550055 012b4a08 55550055 55550055 55550055 55550055 012b4a18 55550055 55550055 55550055 55550055 0:000> 012b4a28 55550055 55550055 55550055 55550055 012b4a38 55550055 55550055 55550055 55550055 012b4a48 55550055 55550055 55550055 55550055 012b4a58 55550055 55550055 55550055 55550055 012b4a68 55550055 55550055 55550055 00000000 012b4a78 55000000 55005500 55005500 55005500 012b4a88 55005500 55005500 55005500 ffffffff 012b4a98 ffffffff 550055ff 55005500 55005500 0:000> 012b4aa8 55005500 55005500 55005500 55005500 012b4ab8 55005500 55005500 55005500 55005500 012b4ac8 55005500 55005500 55005500 55005500 012b4ad8 55005500 55005500 55005500 55005500 012b4ae8 55005500 55005500 55005500 55005500 012b4af8 55005500 55005500 55005500 55005500 012b4b08 55005500 55005500 55005500 55005500 012b4b18 55005500 55005500 55005500 55005500 0:000> 012b4b28 55005500 55005500 55005500 55005500 012b4b38 55005500 55005500 55005500 55005500 012b4b48 55005500 55005500 55005500 55005500 012b4b58 55005500 55005500 55005500 55005500 012b4b68 55005500 55005500 55005500 55005500 012b4b78 55005500 55005500 55005500 55005500 012b4b88 00000000 55000000 55000055 55000055 012b4b98 55000055 55000055 55000055 55000055 0:000> 012b4ba8 55000055 55000055 55000055 55000055 012b4bb8 55000055 55000055 55000055 55000055 012b4bc8 55000055 55000055 55000055 55000055 012b4bd8 55000055 55000055 55000055 55000055 012b4be8 55000055 55000055 55000055 55000055 012b4bf8 55000055 55000055 55000055 55000055 012b4c08 55000055 55000055 55000055 55000055 012b4c18 55000055 55000055 55000055 55000055 0:000> 012b4c28 55000055 55000055 55000055 55000055 012b4c38 55000055 55000055 55000055 55000055 012b4c48 55000055 55000055 55000055 55000055 012b4c58 55000055 55000055 55000055 55000055 012b4c68 55000055 55000055 55000055 55000055 012b4c78 55000055 55000055 55000055 55000055 012b4c88 55000055 55000055 55000055 55000055 012b4c98 55000055 00000000 00000000 00555555 0:000> 012b4ca8 00555555 00555555 00555555 00555555 012b4cb8 00555555 00555555 00555555 00555555 012b4cc8 00555555 00555555 00555555 00555555 012b4cd8 00555555 00555555 00555555 00555555 012b4ce8 00555555 00555555 00555555 00555555 012b4cf8 00555555 00555555 00555555 00555555 012b4d08 00555555 00555555 00555555 00555555 012b4d18 00555555 00555555 00555555 00555555 0:000> 012b4d28 00555555 00555555 00555555 00555555 012b4d38 00555555 00555555 00555555 00555555 012b4d48 00555555 00555555 00555555 00555555 012b4d58 00555555 00555555 00555555 00555555 012b4d68 00555555 00555555 00555555 00555555 012b4d78 00555555 00555555 00555555 00555555 012b4d88 00555555 00555555 00555555 00555555 012b4d98 00555555 00555555 00555555 00555555 0:000> 012b4da8 00555555 00555555 00000000 55000000 012b4db8 55005500 55005500 55005500 55005500 012b4dc8 55005500 55005500 55005500 55005500 012b4dd8 55005500 55005500 55005500 55005500 012b4de8 55005500 55005500 55005500 55005500 012b4df8 55005500 55005500 55005500 55005500 012b4e08 55005500 55005500 55005500 55005500 012b4e18 55005500 55005500 55005500 55005500 0:000> 012b4e28 55005500 55005500 55005500 55005500 012b4e38 55005500 55005500 55005500 55005500 012b4e48 55005500 55005500 55005500 55005500 012b4e58 55005500 55005500 55005500 55005500 012b4e68 55005500 55005500 55005500 55005500 012b4e78 55005500 55005500 55005500 55005500 012b4e88 55005500 55005500 55005500 55005500 012b4e98 55005500 55005500 55005500 55005500 0:000> 012b4ea8 55005500 55005500 55005500 55005500 012b4eb8 55005500 55005500 55005500 00000000 012b4ec8 00000000 00555500 00555500 00555500 012b4ed8 00555500 00555500 00555500 00555500 012b4ee8 00555500 00555500 00555500 00555500 012b4ef8 00555500 00555500 00555500 00555500 012b4f08 00555500 00555500 00555500 00555500 012b4f18 00555500 00555500 00555500 00555500 0:000> 012b4f28 00555500 00555500 00555500 00555500 012b4f38 00555500 00555500 00555500 00555500 012b4f48 00555500 00555500 00555500 00555500 012b4f58 00555500 00555500 00555500 00555500 012b4f68 00555500 00555500 00555500 00555500 012b4f78 00555500 00555500 00555500 00555500 012b4f88 00555500 00555500 00555500 00555500 012b4f98 00555500 00555500 00555500 00555500 0:000> 012b4fa8 00555500 00555500 00555500 00555500 012b4fb8 00555500 00555500 00555500 00555500 012b4fc8 00555500 00555500 00555500 00555500 012b4fd8 00000000 55000000 55550055 55550055 012b4fe8 55550055 55550055 55550055 55550055 012b4ff8 55550055 55550055 55550055 55550055 012b5008 55550055 55550055 55550055 55550055 012b5018 55550055 55550055 55550055 55550055 0:000> 012b5028 55550055 55550055 55550055 55550055 012b5038 55550055 55550055 55550055 55550055 012b5048 55550055 55550055 55550055 55550055 012b5058 55550055 55550055 55550055 55550055 012b5068 55550055 55550055 55550055 55550055 012b5078 55550055 55550055 55550055 55550055 012b5088 55550055 55550055 55550055 55550055 012b5098 55550055 55550055 55550055 55550055 0:000> 012b50a8 55550055 55550055 55550055 55550055 012b50b8 55550055 55550055 55550055 55550055 012b50c8 55550055 55550055 55550055 55550055 012b50d8 55550055 55550055 55550055 55550055 012b50e8 55550055 00000000 55000000 55005500 012b50f8 55005500 55005500 55005500 55005500 012b5108 55005500 55005500 55005500 55005500 012b5118 55005500 55005500 55005500 55005500 0:000> 012b5128 55005500 55005500 55005500 55005500 012b5138 55005500 55005500 55005500 55005500 012b5148 55005500 55005500 55005500 55005500 012b5158 55005500 55005500 55005500 55005500 012b5168 55005500 55005500 55005500 55005500 012b5178 55005500 55005500 55005500 55005500 012b5188 55005500 55005500 55005500 55005500 012b5198 55005500 55005500 55005500 55005500 0:000> 012b51a8 55005500 55005500 55005500 55005500 012b51b8 55005500 55005500 55005500 55005500 012b51c8 55005500 55005500 55005500 55005500 012b51d8 55005500 55005500 55005500 55005500 012b51e8 55005500 55005500 55005500 55005500 012b51f8 55005500 55005500 00000000 55000000 012b5208 55000055 55000055 55000055 55000055 012b5218 55000055 55000055 55000055 55000055 0:000> 012b5228 55000055 55000055 55000055 55000055 012b5238 55000055 55000055 55000055 55000055 012b5248 55000055 55000055 55000055 55000055 012b5258 55000055 55000055 55000055 55000055 012b5268 55000055 55000055 55000055 55000055 012b5278 55000055 55000055 55000055 55000055 012b5288 55000055 55000055 55000055 55000055 012b5298 55000055 55000055 55000055 55000055 0:000> 012b52a8 55000055 55000055 55000055 55000055 012b52b8 55000055 55000055 55000055 55000055 012b52c8 55000055 55000055 55000055 55000055 012b52d8 55000055 55000055 55000055 55000055 012b52e8 55000055 55000055 55000055 55000055 012b52f8 55000055 55000055 55000055 55000055 012b5308 55000055 55000055 55000055 00000000 012b5318 00000000 00555555 00555555 00555555 0:000> 012b5328 00555555 00555555 00555555 00555555 012b5338 00555555 00555555 00555555 00555555 012b5348 00555555 00555555 00555555 00555555 012b5358 00555555 00555555 00555555 00555555 012b5368 00555555 00555555 00555555 00555555 012b5378 00555555 00555555 00555555 00555555 012b5388 00555555 00555555 00555555 00555555 012b5398 00555555 00555555 00555555 00555555 0:000> 012b53a8 00555555 00555555 00555555 00555555 012b53b8 00555555 00555555 00555555 00555555 012b53c8 00555555 00555555 00555555 00555555 012b53d8 00555555 00555555 00555555 00555555 012b53e8 00555555 00555555 00555555 00555555 012b53f8 00555555 00555555 00555555 00555555 012b5408 00555555 00555555 00555555 00555555 012b5418 00555555 00555555 00555555 00555555 0:000> 012b5428 00000000 55000000 55005500 55005500 012b5438 55005500 55005500 55005500 55005500 012b5448 55005500 55005500 55005500 55005500 012b5458 55005500 55005500 55005500 55005500 012b5468 55005500 55005500 55005500 55005500 012b5478 55005500 55005500 55005500 55005500 012b5488 55005500 55005500 55005500 55005500 012b5498 55005500 55005500 55005500 55005500 0:000> 012b54a8 55005500 55005500 55005500 55005500 012b54b8 55005500 55005500 55005500 55005500 012b54c8 55005500 55005500 55005500 55005500 012b54d8 55005500 55005500 55005500 55005500 012b54e8 55005500 55005500 55005500 55005500 012b54f8 55005500 55005500 55005500 55005500 012b5508 55005500 55005500 55005500 55005500 012b5518 55005500 55005500 55005500 55005500 0:000> 012b5528 55005500 55005500 55005500 55005500 012b5538 55005500 00000000 00000000 00555500 012b5548 00555500 00555500 00555500 00555500 012b5558 00555500 00555500 00555500 00555500 012b5568 00555500 00555500 00555500 00555500 012b5578 00555500 00555500 00555500 00555500 012b5588 00555500 00555500 00555500 00555500 012b5598 00555500 00555500 00555500 00555500 0:000> 012b55a8 00555500 00555500 00555500 00555500 012b55b8 00555500 00555500 00555500 00555500 012b55c8 00555500 00555500 00555500 00555500 012b55d8 00555500 00555500 00555500 00555500 012b55e8 00555500 00555500 00555500 00555500 012b55f8 00555500 00555500 00555500 00555500 012b5608 00555500 00555500 00555500 00555500 012b5618 00555500 00555500 00555500 00555500 0:000> 012b5628 00555500 00555500 00555500 00555500 012b5638 00555500 00555500 00555500 00555500 012b5648 00555500 00555500 00000000 55000000 012b5658 55550055 55550055 55550055 55550055 012b5668 55550055 55550055 55550055 55550055 012b5678 55550055 55550055 55550055 55550055 012b5688 55550055 55550055 55550055 55550055 012b5698 55550055 55550055 55550055 55550055 0:000> 012b56a8 55550055 55550055 55550055 55550055 012b56b8 55550055 55550055 55550055 55550055 012b56c8 55550055 55550055 55550055 55550055 012b56d8 55550055 55550055 55550055 55550055 012b56e8 55550055 55550055 55550055 55550055 012b56f8 55550055 55550055 55550055 55550055 012b5708 55550055 55550055 55550055 55550055 012b5718 55550055 55550055 55550055 55550055 0:000> 012b5728 55550055 55550055 55550055 55550055 012b5738 55550055 55550055 55550055 55550055 012b5748 55550055 55550055 55550055 55550055 012b5758 55550055 55550055 55550055 00000000 012b5768 55000000 55005500 55005500 55005500 012b5778 55005500 55005500 55005500 55005500 012b5788 55005500 55005500 55005500 55005500 012b5798 55005500 55005500 55005500 55005500 0:000> 012b57a8 55005500 55005500 55005500 55005500 012b57b8 55005500 55005500 55005500 55005500 012b57c8 55005500 55005500 55005500 55005500 012b57d8 55005500 55005500 55005500 55005500 012b57e8 55005500 55005500 55005500 55005500 012b57f8 55005500 55005500 55005500 55005500 012b5808 55005500 55005500 55005500 55005500 012b5818 55005500 55005500 55005500 55005500 0:000> 012b5828 55005500 55005500 55005500 55005500 012b5838 55005500 55005500 55005500 55005500 012b5848 55005500 55005500 55005500 55005500 012b5858 55005500 55005500 55005500 55005500 012b5868 55005500 55005500 55005500 55005500 012b5878 00000000 55000000 55000055 55000055 012b5888 55000055 55000055 55000055 55000055 012b5898 55000055 55000055 55000055 55000055 0:000> 012b58a8 55000055 55000055 55000055 55000055 012b58b8 55000055 55000055 55000055 55000055 012b58c8 55000055 55000055 55000055 55000055 012b58d8 55000055 55000055 55000055 55000055 012b58e8 55000055 55000055 55000055 55000055 012b58f8 55000055 55000055 55000055 55000055 012b5908 55000055 55000055 55000055 55000055 012b5918 55000055 55000055 55000055 55000055 0:000> 012b5928 55000055 55000055 55000055 55000055 012b5938 55000055 55000055 55000055 55000055 012b5948 55000055 55000055 55000055 55000055 012b5958 55000055 55000055 55000055 55000055 012b5968 55000055 55000055 55000055 55000055 012b5978 55000055 55000055 55000055 55000055 012b5988 55000055 00000000 00000000 00000000 012b5998 00000000 00000000 00000000 00000000 0:000> 012b59a8 00000000 00000000 00000000 00000000 012b59b8 00000000 00000000 00000000 00000000 012b59c8 00000000 00000000 00000000 00000000 012b59d8 00000000 00000000 00000000 00000000 012b59e8 00000000 00000000 00000000 00000000 012b59f8 00000000 00000000 00000000 00000000 012b5a08 00000000 00000000 00000000 00000000 012b5a18 00000000 00000000 00000000 00000000 0:000> 012b5a28 00000000 00000000 00000000 00000000 012b5a38 00000000 00000000 00000000 00000000 012b5a48 00000000 00000000 00000000 00000000 012b5a58 00000000 00000000 00000000 00000000 012b5a68 00000000 00000000 00000000 00000000 012b5a78 00000000 00000000 00000000 00000000 012b5a88 00000000 00000000 00000000 00000000 012b5a98 00000000 00000000 00000000 00000000 0:000> 012b5aa8 00000000 00000000 00000000 00000000 012b5ab8 00000000 00000000 00000000 00000000 012b5ac8 00000000 00000000 00000000 00000000 012b5ad8 00000000 00000000 00000000 00000000 012b5ae8 00000000 00000000 00000000 00000000 012b5af8 00000000 00000000 00000000 00000000 012b5b08 00000000 00000000 00000000 00000000 012b5b18 00000000 00000000 00000000 00000000 0:000> 012b5b28 00000000 00000000 00000000 00000000 012b5b38 00000000 00000000 00000000 00000000 012b5b48 00000000 00000000 00000000 00000000 012b5b58 00000000 00000000 00000000 00000000 012b5b68 00000000 00000000 00000000 00000000 012b5b78 00000000 00000000 00000000 00000000 012b5b88 00000000 00000000 00000000 00000000 012b5b98 00000000 00000000 00000000 00000000 0:000> 012b5ba8 00000000 00000000 00000000 00000000 012b5bb8 00000000 00000000 00000000 00000000 012b5bc8 00000000 00000000 00000000 00000000 012b5bd8 00000000 00000000 00000000 00000000 012b5be8 00000000 00000000 00000000 00000000 012b5bf8 00000000 00000000 00000000 00000000 012b5c08 00000000 00000000 00000000 00000000 012b5c18 00000000 00000000 00000000 00000000 0:000> 012b5c28 00000000 00000000 00000000 00000000 012b5c38 00000000 00000000 00000000 00000000 012b5c48 00000000 00000000 00000000 00000000 012b5c58 00000000 00000000 00000000 00000000 012b5c68 00000000 00000000 00000000 00000000 012b5c78 00000000 00000000 00000000 00000000 012b5c88 00000000 00000000 00000000 00000000 012b5c98 00000000 00000000 00000000 00000000 0:000> 012b5ca8 00000000 00000000 00000000 00000000 012b5cb8 00000000 00000000 00000000 00000000 012b5cc8 00000000 00200b16 00eb7e38 02216808 012b5cd8 00200898 01354828 00000000 00000000 012b5ce8 02214018 012b5d48 00000000 000002c2 012b5cf8 000000d5 0000012b 0118cd08 00000000 012b5d08 00000000 00000040 00000000 00000000 012b5d18 00000000 00000000 00000000 00000000 0:000> 012b5d28 02216830 c7c34f80 c7c34f80 c7c34f80 012b5d38 c7c34f80 00000000 00000000 002004ba 012b5d48 00000000 02216894 012b5e64 012b5cdc 012b5d58 00000056 00200470 00000000 022168ac 012b5d68 022168bc 0020052e 00e66248 00e63b70 012b5d78 00000000 011a0648 00e63b60 00200546 012b5d88 00e6609c 00e64e10 00000001 4061c71c 012b5d98 c7c34f80 c7c34f80 00200882 01353ec0 0:000> 012b5da8 00000000 00000000 02214018 012b5e64 012b5db8 00000000 000002c2 0000012b 00000137 012b5dc8 0118cd08 00000000 00000000 00000040 012b5dd8 00000000 00000000 00000000 00000000 012b5de8 00000000 00000000 012b5e10 c7c34f80 012b5df8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b5e08 c7c34f80 00200a3c 01340ff0 00000000 012b5e18 00000000 012b5da4 00000000 00000000 0:000> 012b5e28 000002c2 0000012b 00000137 0118cd08 012b5e38 00000000 00000000 00000040 00000000 012b5e48 00000000 00000000 00000000 00000052 012b5e58 00000000 00000000 002004ba 00000000 012b5e68 012b5d48 012b6118 012b5da4 0000000c 012b5e78 00200470 00000000 022168cc 022168bc 012b5e88 00200332 012b5e94 00000001 022168dc 012b5e98 00200470 00000000 0119e8cc 012b5eac 0:000> 012b5ea8 00200470 00000000 022168e8 012b5ebc 012b5eb8 00200470 00000000 022168dc 00000000 012b5ec8 00200470 00000000 012b5e9c 012b5e7c 012b5ed8 0020052e 00e66248 00e63b70 00000000 012b5ee8 011a0648 00e63b60 00200546 00e6609c 012b5ef8 00e63c80 00000001 c7c34f80 00000000 012b5f08 00000000 00200546 00e6609c 00e63900 012b5f18 00000000 c7c34f80 c7c34f80 c7c34f80 0:000> 012b5f28 00200470 00000000 022168dc 012b5ecc 012b5f38 00200470 00000000 022168dc 00000000 012b5f48 0020052e 00e66248 00e63b70 00000000 012b5f58 011a0648 00e63b60 00200548 00e6607c 012b5f68 00e64e10 00000001 022168dc 00200544 012b5f78 00e660bc 00e64564 00000000 40000000 012b5f88 00200544 00e660bc 00e64578 00000000 012b5f98 00000000 00200532 00e661e4 00e6458c 0:000> 012b5fa8 00000000 00000000 00200532 00e661e4 012b5fb8 00e645a4 00000000 00000001 00200532 012b5fc8 00e661e4 00e645b8 00000000 00000000 012b5fd8 00200534 01341518 00e64e10 00000000 012b5fe8 012b5ff8 00000001 00000001 00200540 012b5ff8 012b6000 00000003 012b5fa0 012b5fb4 012b6008 012b5fc8 00200548 00e6607c 00e6418c 012b6018 00000000 00000000 002008a0 01354e98 0:000> 012b6028 00000000 00000000 012b60ac 00000000 012b6038 00000000 000002c2 00000137 00000151 012b6048 0118cd08 00000000 00000000 00000040 012b6058 00000000 00000000 00000000 00000000 012b6068 022168dc 00000007 0119ff40 3f349f4a 012b6078 00000000 00000002 00000000 3f000000 012b6088 3f000000 000000b8 0000020a 00000137 012b6098 00000151 000000b8 0000014c 00000000 0:000> 012b60a8 00200898 01354828 00000000 00000000 012b60b8 02214018 012b6118 00000000 000002c2 012b60c8 00000137 00000151 0118cd08 00000000 012b60d8 00000000 00000040 00000000 00000000 012b60e8 00000000 00000000 00000000 00000000 012b60f8 012b6024 c7c34f80 c7c34f80 c7c34f80 012b6108 c7c34f80 00000000 00000000 002004ba 012b6118 00000000 012b5e64 012b6234 012b60ac 012b6128 0000001a 00200470 00000000 022168f8 012b6138 022168bc 0020052e 00e66248 00e63b70 012b6148 00000000 011a0648 00e63b60 00200546 012b6158 00e6609c 00e64e10 00000001 4061c71c 012b6168 c7c34f80 c7c34f80 00200882 01353ec0 012b6178 00000000 00000000 02214018 012b6234 012b6188 00000000 000002c2 00000151 0000015d 012b6198 0118cd08 00000000 00000000 00000040 012b61a8 00000000 00000000 00000000 00000000 012b61b8 00000000 00000000 012b61e0 c7c34f80 012b61c8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b61d8 c7c34f80 00200a3c 01340ff0 00000000 012b61e8 00000000 012b6174 00000000 00000000 012b61f8 000002c2 00000151 0000015d 0118cd08 012b6208 00000000 00000000 00000040 00000000 012b6218 00000000 00000000 00000000 00000052 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 04:27:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 02:27:09 +0000 Subject: [M3devel] FW: This is a pixmap? Message-ID: resorting to an attachment since this is important and keeps getting truncated -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jay.krell at cornell.edu Fri Sep 4 10:33:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 08:33:36 +0000 Subject: [M3devel] updating web site? Message-ID: http://modula3.elegosoft.com/cm3/index.html (http://modula3.elegosoft.com/cm3/start.html) looks really bad, with the nested frame I believe I fixed this days ago: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/www/start.html.diff?r1=1.3.2.2;r2=1.3.2.3 How does one get the web site to update? Maybe use head instead of the release branch? Maybe I didn't move the tag forward? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 10:54:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) Message-ID: short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 11:12:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 09:12:23 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 13:52:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 11:52:28 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 16:06:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 14:06:08 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 16:07:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 14:07:46 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 16:40:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 14:40:49 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Sep 4 17:10:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 04 Sep 2009 11:10:53 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: <4AA0F5A7.1E75.00D7.1@scires.com> Jay said: >This we shall blame on Trestle not fully being ported to Win32, I guess. >At the very least, it seems to the behavior going back a while. >You can occasionally see this in head, but usually you see #3. I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 4 18:44:21 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Sep 2009 12:44:21 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non- Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote: > no..still unsolved..not sure if I misobserved or what..will have to > backtrack.. > > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:07:46 +0000 > > (Well, duh, it wasn't ProcessPools(SuspendPool), that just has > assertions) > > - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:06:08 +0000 > > Restoring the: > ThreadF.ProcessPools(ClosePool); > > 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. > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 11:52:28 +0000 > > I have narrowed it way down to between "2009-02-16 02:00Z" and -D > "2009-02-16 02:30Z". > So please review this change. > I have reviewed it and tried to partly undo it, without luck yet. > There is a semantic change in BroadcastHeap where the broadcast used > to happen upon the next unlock > and now I think happens right away. I tried restoring that, but > again, no luck for me. > > Thanks, > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 09:12:23 +0000 > > I have narrowed it down further to between 2/15/2009 and 2/18/2009. > Next I will try old text code in head to see if it is that. > > Tony, can you double check this stuff: > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > > 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..). > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 08:54:54 +0000 > Subject: [M3devel] Juno on NT (presumably canary for other problems) > > short story: > > > I narrowed it down to between 2/15/2009 and 2/20/2009. > I will keep digging. > > There are actually a lot of changes in that brief period. > I will narrow it further. > > > long story: > > Juno on NT, as canary for other problems. > Juno on NT has three behaviors. > > > Behavior #1 > > > The most common historical behavior, an assertion failure: > C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\winvbt\WinContext.m3", line 165 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt > \WinContext.m3 > 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 > 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 > 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe30 0x7e418734 > 0x1b3fe98 0x7e418816 > 0x1b3fef8 0x7e4189cd > 0x1b3ff08 0x7e4196c7 > 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt > \WinTrestle.m3 > ......... ......... ... more frames ... > (1860.1d80): Break instruction exception - code 80000003 (first > chance) > eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 > edi=005d526b > eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz > na po nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00000202 > ntdll!DbgBreakPoint: > 7c90120e cc int 3 > 0:003> .lines > Line number information will be loaded > 0:003> k999 > ChildEBP RetAddr > 01b3f5bc 005d52b7 ntdll!DbgBreakPoint > 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime > \WIN32\RTOS.m3 @ 29] > 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common > \RTProcess. > m3 @ 66] > 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime > \common\RTError.m > 3 @ 118] > 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common > \RTError.m3 @ > 40] > 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime > \common\RTExcep > tion.m3 @ 79] > 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src > \runtime\commo > n\RTException.m3 @ 39] > 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src > \runtime\commo > n\RTException.m3 @ 47] > 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime > \common\RTHook > s.m3 @ 110] > 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt > \WinContext.m3 @ 1 > 7] > 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt > \WinContext.m3 > @ 167] > 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt > \WinPaint.m3 @ 71 > 2] > 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt > \WinPaint.m3 @ 5 > 1] > 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt > \WinTrestle > .m3 @ 1574] > 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt > \WinTrestle.m3 > @ 1163] > 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 > 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 > 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 > 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf > 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src > \winvbt\WinTrestl > e.m3 @ 2450] > 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread > \WIN32\Threa > dWin32.m3 @ 579] > 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread > \WIN32\Threa > dWin32.m3 @ 548] > 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 > 0:003> > > > This we shall blame on Trestle not fully being ported to Win32, I > guess. > At the very least, it seems to the behavior going back a while. > You can occasionally see this in head, but usually you see #3. > > > Behavior #2 > > Sometimes, rarely, Juno hangs in startup on NT. > I believe I have seen this both with fairly old and current versions. > This occurs very rarely. I might look into it more after #3 is solved. > > > Behavior #3 > > > An access violation (SIGSEGV to Unix folks) during startup. > This is the most common behavior with current source, going back a > few months. > It is almost always accessing address 00200000 and the instruction > pointer is very > often in Thread__Join, but neither are always true. > Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. > > > C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe > (1ac4.1e9c): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 > edi=02812974 > eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > m3core!Thread__Join+0x13f: > 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds: > 0023:001ffffc=???????? > 0:000> r ebx > ebx=00200000 > 0:000> .lines > Line number information will be loaded > 0:000> k > ChildEBP RetAddr > 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread > \WIN32\ThreadWin32.m3 > @ 710] > 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src > \JunoCompile. > m3 @ 256] > 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] > 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] > 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] > 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] > 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ > 174] > 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ > 263] > 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] > 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime > \common\RTLi > nker.m3 @ 399] > 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime > \common\RTLinker > .m3 @ 113] > 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime > \common\RTLinker. > m3 @ 122] > 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] > 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld > \self_x86\c > rt\src\crtexe.c @ 582] > 0012fff0 00000000 kernel32!BaseProcessStart+0x23 > 0:000> > > #4 sometimes other, for example: > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 411 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common > \RTCollector.m3 > 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common > \RTCollector.m > 3 > 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common > \RTCollector.m3 > 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src > \runtime\common\RT > Collector.m3 > 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common > \RTCollector.m3 > 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common > \RTCollector. > m3 > 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common > \RTCollector.m3 > ......... ......... ... more frames ... > (14b0.121c): Break instruction exception - code 80000003 (first > chance) > > for example: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\src\vbt\VBTRep.m3", line 644 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 > 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 > 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 > 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > (1c3c.e3c): Break instruction exception - code 80000003 (first chance) > > I figure these are just a variation of #3. > > Now, I finally learned how to give CVS a date to checkout or update. > And NT builds very fast due to the integrated backend. > So I have been building various dates. > > The change between #3 and #1 happened around mid February 2009. > Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, > #4 above is from 2009/02/20. > And 2009/02/20 also access violates on 00200000 often. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 21:44:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 19:44:51 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: <4AA0F5A7.1E75.00D7.1@scires.com> References: <4AA0F5A7.1E75.00D7.1@scires.com> Message-ID: Randy, thanks, understood. Actually Juno does draw a bunch of fancy stuff before the assertion failure. And formsedit at least historically works, and I thought mentor but I'll have to retest after Tony fixes, and with old versions. Yes please test anything you can. I can get you an HP-UX toolset if you need..assumiing I can resolve why last I powered the machine on I couldn't see it on the network. At some point we might even get HP-UX in Hudson. :) - Jay Date: Fri, 4 Sep 2009 11:10:53 -0400 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay said: >This we shall blame on Trestle not fully being ported to Win32, I guess. >At the very least, it seems to the behavior going back a while. >You can occasionally see this in head, but usually you see #3. I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 21:42:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 19:42:58 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: > no..still unsolved..not sure if I misobserved or what..will have to backtrack.. To clarify, the problem is between "2009-02-16 02:00Z" and "2009-02-16 02:30Z", just that I don't know either of - a small change to "2009-02-16 02:30Z" to fix it - and applying such to head - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Date: Fri, 4 Sep 2009 14:40:49 +0000 Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Sep 4 22:21:47 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 04 Sep 2009 16:21:47 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: <4AA0F5A7.1E75.00D7.1@scires.com> Message-ID: <4AA13E82.1E75.00D7.1@scires.com> Jay: Yeah I see the Juno window start up on most runs, but then it crashes so quickly that you can't see much before the window disappears. I use formsedit quite a bit. I recall that back when we purchased Reactor/cm3 v4.1, that Farshad and company had to make some patches to formsedit because it crashed on certain platforms. Critical Mass provided us with the patched executables, but I never got the sources. Not sure if the patches got put into what we have now. There are some problems now with formsedit that I've documented in the past. One of the big ones has to deal with keeping the cursor placement in sync between what is shown on the display and what the program actually thinks, particularly when switching between mouse and keyboard movement. Similarly, I know that Reactor was a work in progress. Although I worked with Farshad to obtain the sources for the open source release as CM3IDE, I'm not confident that all the latest greatest sources actually made it to me in the version Farshad supplied. He had to dig back through some archives to obtain them. I've noticed some operational differences between my old "Reactor" and the new "CM3IDE". Monday is a holiday for me, so I'll try to devote some time this long weekend on running more tests. If you want me to run stuff on HP-UX, I'll have to pull the machine "out-of-moth-balls" so to speak because its been a long time since I've used it. I think I still have three HP-UX machines. One of them had a hard drive problem with one of its SCSI drives so that may take some to repair. I'll also try to look at some of the scripts ya'll are using for the automated tests and see if there is a way I can run some of these tests on XP and Vista (unless ya'll already have that covered on a VM for Hudson--let me know if I don't need to do this). Regards, Randy >>> Jay K 9/4/2009 3:44 PM >>> Randy, thanks, understood. Actually Juno does draw a bunch of fancy stuff before the assertion failure. And formsedit at least historically works, and I thought mentor but I'll have to retest after Tony fixes, and with old versions. Yes please test anything you can. I can get you an HP-UX toolset if you need..assumiing I can resolve why last I powered the machine on I couldn't see it on the network. At some point we might even get HP-UX in Hudson. :) - Jay Date: Fri, 4 Sep 2009 11:10:53 -0400 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay said: >This we shall blame on Trestle not fully being ported to Win32, I guess. >At the very least, it seems to the behavior going back a while. >You can occasionally see this in head, but usually you see #3. I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 23:20:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 21:20:13 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: <4AA13E82.1E75.00D7.1@scires.com> References: <4AA0F5A7.1E75.00D7.1@scires.com> <4AA13E82.1E75.00D7.1@scires.com> Message-ID: > unless ya'll already have that covered on a VM for Hudson We do. Another wouldn't hurt much though, except time/energy. Maybe document the setup. We had a bunch of problems, though some were due to wierdo missteps that I would have called out had I been paying close attention. That is, setup is more like "leave the defaults, don't do extra wierd stuff". CVSNT by default changes line endings, breaking all .sh files. Maybe there is a setting to fix it? I'm not sure. The documentation is very confusing on this point. It talks about a keyword setting on a per file basis. Or maybe a checkout/update option? So Cygwin text mode mounts were used, which partly fixes the problem, but leaves caltech-parser broken (it should be fixed to allow for \n, \r, or \r\n.). Had I noticed I would have avoided the text mode mount in the first place. Fixed by: Use Cygwin cvs as I've been using all along. Don't use textmode mounts, use the default. Also cygwin mount cygexec was being used. I don't know what that really does. No longer used. It's not the default. Cygwin sshd has a bug that breaks Visual C++ link.exe. Seriously. We switched to another sshd, and paid a small licensing fee. Sometimes reboot needed to get sshd/ssh/scp working. The initial setup up cm3 itself has some kinks as well that Olaf pledges to improve after the current release -- where to find a baseline cm3 to start with and possibly m3core/libm3. It's probably easier, though still a small pain, to run the Tinderbox stuff. I checked in a document detailing my experience. Tinderbox doesn't require Java or sshd. I would still avoid CVSNT unless that behavior can be remedied. - Jay ________________________________ > Date: Fri, 4 Sep 2009 16:21:47 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) > > > > > > > > > > Jay: > > > > Yeah I see the Juno window start up on most runs, but then it crashes so quickly that you can't see much before the window disappears. > > > > I use formsedit quite a bit. I recall that back when we purchased Reactor/cm3 v4.1, that Farshad and company had to make some patches to formsedit because it crashed on certain platforms. Critical Mass provided us with the patched executables, but I never got the sources. Not sure if the patches got put into what we have now. > > > > There are some problems now with formsedit that I've documented in the past. One of the big ones has to deal with keeping the cursor placement in sync between what is shown on the display and what the program actually thinks, particularly when switching between mouse and keyboard movement. > > > > Similarly, I know that Reactor was a work in progress. Although I worked with Farshad to obtain the sources for the open source release as CM3IDE, I'm not confident that all the latest greatest sources actually made it to me in the version Farshad supplied. He had to dig back through some archives to obtain them. I've noticed some operational differences between my old "Reactor" and the new "CM3IDE". > > > > Monday is a holiday for me, so I'll try to devote some time this long weekend on running more tests. If you want me to run stuff on HP-UX, I'll have to pull the machine "out-of-moth-balls" so to speak because its been a long time since I've used it. I think I still have three HP-UX machines. One of them had a hard drive problem with one of its SCSI drives so that may take some to repair. I'll also try to look at some of the scripts ya'll are using for the automated tests and see if there is a way I can run some of these tests on XP and Vista (unless ya'll already have that covered on a VM for Hudson--let me know if I don't need to do this). > > > > Regards, > > Randy > >>>> Jay K 9/4/2009 3:44 PM>>> > Randy, thanks, understood. Actually Juno does draw a bunch of fancy stuff before the assertion failure. And formsedit at least historically works, and I thought mentor but I'll have to retest after Tony fixes, and with old versions. Yes please test anything you can. I can get you an HP-UX toolset if you need..assumiing I can resolve why last I powered the machine on I couldn't see it on the network. At some point we might even get HP-UX in Hudson. :) > > - Jay > > > > > ________________________________ > > > Date: Fri, 4 Sep 2009 11:10:53 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) > > > > > Jay said: > >>This we shall blame on Trestle not fully being ported to Win32, I guess. >>At the very least, it seems to the behavior going back a while. >>You can occasionally see this in head, but usually you see #3. > > I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. > > > > Regards, > > Randy From jay.krell at cornell.edu Sun Sep 6 14:30:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Sep 2009 12:30:27 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Tony both of these timestamps are somewhat prone to hanging during Juno I386_DARWIN startup. But they don't crash, er..well they do both fail assertions in text, but I just put current source in to address that. I'm going to search backward for a time that doesn't hang. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 4 Sep 2009 12:44:21 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non-Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote:no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 6 16:04:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Sep 2009 14:04:55 +0000 Subject: [M3devel] XSharedMem.m3 Message-ID: The file m3-ui/ui/src/xvbt/XSharedMem.m3 has a bug. The function IsSameHost is wrong. What does it matter either way? Can the code that uses it just depend on the shared memory stuff working? Or is it important to know if really on the same machine? That is, can it just be hardcoded as TRUE and back progatate that assumption to its callers? Apple's X11 does like this: bash-3.2$ echo $DISPLAY /tmp/launch-gTYtJF/:0 which causes this IsSameHost code to fail. You can see I put in a band-aid a while ago, but it isn't really fixed. Why have I never heard of this problem in other X code? Because X seems to stink so I don't pay much attention to it.. Because X is little used on Macs? Little used in general? .. (note that Interix seems to lack some of this XSharedMem stuff, therefore so far no Modula-3 gui apps on it. Now that I see this optionality though, maybe it is easy to workaround?) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 6 18:11:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Sep 2009 16:11:28 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Tony, I386_DARWIN Juno is very prone to hang during startup going back at least until 2007/12/01. But they certainly don't always hang. I haven't found a version yet that doesn't hang. I'll look some more. I guess soon I should try other platforms? Sometimes there is a pause and it continues. Perhaps the hangs I'm just being too impatient on?? But, then, it's a bit inconsistent. Has it ever worked? Race condition in Juno maybe? It isn't always easy to build these old dates. Caveats: I'm using just current cm3cg. I started seeing as complain about older cm3cg output. Current config files. Build standalone (as current config files do with older compilers automatically, for "old" == missing the symlink functions). Patched XSharedMem/IsSameHost to always be FALSE, though TRUE would be correct, FALSE seems safe, I have to read that code.. Here is 2007/12/01 hung. It got as far as displaying "Curve" in the startup text that goes by. (gdb) thread apply all bt Thread 9 (process 32852 thread 0x294f): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1e8c in Thread__AlertWait () #5 0x00290988 in Formatter__Allocate () #6 0x00291137 in Formatter__Probe () #7 0x0029178e in Formatter__Peek () #8 0x00291677 in Formatter__PeekOp () #9 0x00291d18 in Formatter__PrintUntil () #10 0x002918d2 in Formatter__PrintTop () #11 0x002e3651 in ThreadPThread__RunThread () #12 0x002e33a3 in ThreadPThread__ThreadBase () #13 0x96f74155 in _pthread_start () #14 0x96f74012 in thread_start () Thread 8 (process 32852 thread 0x2603): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001aad83 in XMessenger__Messenger () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 7 (process 32852 thread 0x2503): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001b68da in XInput__FilterXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 6 (process 32852 thread 0x240f): #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () #1 0x96fc8261 in select () #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () #3 0x002e4b05 in ThreadPThread__XIOWait () #4 0x002e4614 in SchedulerPosix__IOWait () #5 0x001b65f5 in XInput__WaitForXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 5 (process 32852 thread 0x2303): #0 0x96f433a6 in mach_wait_until () #1 0x96fba3ad in nanosleep () #2 0x002e423c in ThreadPThread__XPause () #3 0x002e4393 in Thread__Pause () #4 0x0011113a in FileBrowserVBT__Watcher () #5 0x002e3651 in ThreadPThread__RunThread () #6 0x002e33a3 in ThreadPThread__ThreadBase () #7 0x96f74155 in _pthread_start () #8 0x96f74012 in thread_start () Thread 4 (process 32852 thread 0x2203): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001883f9 in VTView__VFontCleanUpThread () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 3 (process 32852 thread 0x2103): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001eb9c2 in VBTRep__MeterMaid () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 2 (process 32852 thread 0x313): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e65ec in RTOS__WaitHeap () #6 0x002d2d54 in RTCollector__WeakCleaner () #7 0x002e3651 in ThreadPThread__RunThread () #8 0x002e33a3 in ThreadPThread__ThreadBase () #9 0x96f74155 in _pthread_start () #10 0x96f74012 in thread_start () Thread 1 (process 32852 local thread 0x2d03): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e3ddb in Thread__Join () #6 0x0028f53d in Formatter__Close () #7 0x00079485 in JunoUnparse__Expr () #8 0x00021721 in Editor__Pass4 () #9 0x00022048 in EditorUI__CompileUI () #10 0x0003e7f8 in Juno__CompileEditor () #11 0x0003e98d in Juno__CompileModule () #12 0x0003f3be in Juno__CompileModules () #13 0x0004d43d in Juno_M3 () #14 0x002d71fa in RTLinker__RunMainBody () #15 0x002d67b0 in RTLinker__AddUnitI () #16 0x002d682e in RTLinker__AddUnit () #17 0x00003c88 in main () - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Sun, 6 Sep 2009 12:30:27 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Tony both of these timestamps are somewhat prone to hanging during Juno I386_DARWIN startup. But they don't crash, er..well they do both fail assertions in text, but I just put current source in to address that. I'm going to search backward for a time that doesn't hang. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 4 Sep 2009 12:44:21 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non-Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote:no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 03:49:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 01:49:28 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack. Current LINUXLIBC6 Juno doesn't seem to ever hang. So I conclude, with obvious non scientific firmness, that the Darwin-specific threading has never really worked and that the problem lies with it, not within the common code (or perhaps in the common code but only in how it mixes with the Darwin code). - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Sun, 6 Sep 2009 16:11:28 +0000 Tony, I386_DARWIN Juno is very prone to hang during startup going back at least until 2007/12/01. But they certainly don't always hang. I haven't found a version yet that doesn't hang. I'll look some more. I guess soon I should try other platforms? Sometimes there is a pause and it continues. Perhaps the hangs I'm just being too impatient on?? But, then, it's a bit inconsistent. Has it ever worked? Race condition in Juno maybe? It isn't always easy to build these old dates. Caveats: I'm using just current cm3cg. I started seeing as complain about older cm3cg output. Current config files. Build standalone (as current config files do with older compilers automatically, for "old" == missing the symlink functions). Patched XSharedMem/IsSameHost to always be FALSE, though TRUE would be correct, FALSE seems safe, I have to read that code.. Here is 2007/12/01 hung. It got as far as displaying "Curve" in the startup text that goes by. (gdb) thread apply all bt Thread 9 (process 32852 thread 0x294f): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1e8c in Thread__AlertWait () #5 0x00290988 in Formatter__Allocate () #6 0x00291137 in Formatter__Probe () #7 0x0029178e in Formatter__Peek () #8 0x00291677 in Formatter__PeekOp () #9 0x00291d18 in Formatter__PrintUntil () #10 0x002918d2 in Formatter__PrintTop () #11 0x002e3651 in ThreadPThread__RunThread () #12 0x002e33a3 in ThreadPThread__ThreadBase () #13 0x96f74155 in _pthread_start () #14 0x96f74012 in thread_start () Thread 8 (process 32852 thread 0x2603): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001aad83 in XMessenger__Messenger () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 7 (process 32852 thread 0x2503): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001b68da in XInput__FilterXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 6 (process 32852 thread 0x240f): #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () #1 0x96fc8261 in select () #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () #3 0x002e4b05 in ThreadPThread__XIOWait () #4 0x002e4614 in SchedulerPosix__IOWait () #5 0x001b65f5 in XInput__WaitForXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 5 (process 32852 thread 0x2303): #0 0x96f433a6 in mach_wait_until () #1 0x96fba3ad in nanosleep () #2 0x002e423c in ThreadPThread__XPause () #3 0x002e4393 in Thread__Pause () #4 0x0011113a in FileBrowserVBT__Watcher () #5 0x002e3651 in ThreadPThread__RunThread () #6 0x002e33a3 in ThreadPThread__ThreadBase () #7 0x96f74155 in _pthread_start () #8 0x96f74012 in thread_start () Thread 4 (process 32852 thread 0x2203): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001883f9 in VTView__VFontCleanUpThread () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 3 (process 32852 thread 0x2103): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001eb9c2 in VBTRep__MeterMaid () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 2 (process 32852 thread 0x313): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e65ec in RTOS__WaitHeap () #6 0x002d2d54 in RTCollector__WeakCleaner () #7 0x002e3651 in ThreadPThread__RunThread () #8 0x002e33a3 in ThreadPThread__ThreadBase () #9 0x96f74155 in _pthread_start () #10 0x96f74012 in thread_start () Thread 1 (process 32852 local thread 0x2d03): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e3ddb in Thread__Join () #6 0x0028f53d in Formatter__Close () #7 0x00079485 in JunoUnparse__Expr () #8 0x00021721 in Editor__Pass4 () #9 0x00022048 in EditorUI__CompileUI () #10 0x0003e7f8 in Juno__CompileEditor () #11 0x0003e98d in Juno__CompileModule () #12 0x0003f3be in Juno__CompileModules () #13 0x0004d43d in Juno_M3 () #14 0x002d71fa in RTLinker__RunMainBody () #15 0x002d67b0 in RTLinker__AddUnitI () #16 0x002d682e in RTLinker__AddUnit () #17 0x00003c88 in main () - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Sun, 6 Sep 2009 12:30:27 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Tony both of these timestamps are somewhat prone to hanging during Juno I386_DARWIN startup. But they don't crash, er..well they do both fail assertions in text, but I just put current source in to address that. I'm going to search backward for a time that doesn't hang. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 4 Sep 2009 12:44:21 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non-Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote:no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 04:34:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 02:34:29 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: [was truncated] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack. Current LINUXLIBC6 Juno doesn't seem to ever hang. So I conclude, with obvious non scientific firmness, that the Darwin-specific threading has never really worked and that the problem lies with it, not within the common code (or perhaps in the common code but only in how it mixes with the Darwin code). - Jay From: jay.krell at cornell.edu [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 05:18:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 03:18:40 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack. Current LINUXLIBC6 Juno doesn't seem to ever hang. So I conclude, with obvious non scientific firmness, that the Darwin-specific threading has never really worked and that the problem lies with it, not within the common code (or perhaps in the common code but only in how it mixes with the Darwin code). - Jay From: jay.krell at cornell.edu [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 11:33:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 09:33:39 +0000 Subject: [M3devel] (no subject) Message-ID: Tony, can you..um, trick question sort of, briefly explain the differences between pthreads and Modula-3 threads? The "trick" part is that, to an audience (me) who is not all that familiar with the nuances of either? I'll see if I can find my green book and other reference material (online). I understand the basics of threading very well, if that helps. Eh, not much to it really. I'm not super familiar with condition variables, as Win32 didn't historically have them. But I think I understand them. Specific questions: Can Modula-3 threads be implemented more directly upon pthreads? Why do we need to maintain a waiting list? Is "alert" the same as "cancel" in pthread vocabulary? Or almost the same? I understand..there might be a difficult problem..does Modula-3 allow catching an alert? I think so. Does Posix allow canceling a cancel? I think not. Posix allows, what I think of as try/finally, for alert. Modula-3 probably does too. Even though you can't stop the cancel, you can run "cleanup" code that runs before the cancel completes. However mapping Modula-3 to Posix here would be tricky. As I see things..any function with a try/finally would have to be contorted into a form that passes a pointer to itself, along with parameters, to C code that does pthread_cleanup_push/pop around calling the function pointer. At least given the Darwin implementation. Other implementations might simply be able to call push at the start and pop at the end. But on Darwin these functions are macros where push introduces a local variable that pop references. I guess maybe one could to the "reverse engineering" approach (just by reading the header). But it'd still be ugly. I have to do more research here. I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is thinner than the current ThreadPThread.m3 and see how it fairs, specifically if the Juno hangs go away. "writing" being an exaggeration because it should be very small. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 7 17:06:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Sep 2009 11:06:41 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: It used to work... :-) On 6 Sep 2009, at 21:49, Jay K wrote: > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack. > Current LINUXLIBC6 Juno doesn't seem to ever hang. > So I conclude, with obvious non scientific firmness, that the Darwin- > specific threading has never really worked and that the problem lies > with it, not within the common code (or perhaps in the common code > but only in how it mixes with the Darwin code). > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Sun, 6 Sep 2009 16:11:28 +0000 > > Tony, I386_DARWIN Juno is very prone to hang during startup going > back at least until 2007/12/01. > But they certainly don't always hang. > I haven't found a version yet that doesn't hang. I'll look some > more. I guess soon I should try other platforms? > Sometimes there is a pause and it continues. Perhaps the hangs I'm > just being too impatient on?? > But, then, it's a bit inconsistent. > Has it ever worked? > Race condition in Juno maybe? > It isn't always easy to build these old dates. > Caveats: > I'm using just current cm3cg. I started seeing as complain about > older cm3cg output. > Current config files. > Build standalone (as current config files do with older compilers > automatically, for "old" == missing the symlink functions). > Patched XSharedMem/IsSameHost to always be FALSE, though TRUE > would be correct, FALSE seems safe, I have to read that code.. > > Here is 2007/12/01 hung. > It got as far as displaying "Curve" in the startup text that goes by. > > (gdb) thread apply all bt > > Thread 9 (process 32852 thread 0x294f): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1e8c in Thread__AlertWait () > #5 0x00290988 in Formatter__Allocate () > #6 0x00291137 in Formatter__Probe () > #7 0x0029178e in Formatter__Peek () > #8 0x00291677 in Formatter__PeekOp () > #9 0x00291d18 in Formatter__PrintUntil () > #10 0x002918d2 in Formatter__PrintTop () > #11 0x002e3651 in ThreadPThread__RunThread () > #12 0x002e33a3 in ThreadPThread__ThreadBase () > #13 0x96f74155 in _pthread_start () > #14 0x96f74012 in thread_start () > > Thread 8 (process 32852 thread 0x2603): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001aad83 in XMessenger__Messenger () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 7 (process 32852 thread 0x2503): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001b68da in XInput__FilterXInput () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 6 (process 32852 thread 0x240f): > #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () > #1 0x96fc8261 in select () > #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () > #3 0x002e4b05 in ThreadPThread__XIOWait () > #4 0x002e4614 in SchedulerPosix__IOWait () > #5 0x001b65f5 in XInput__WaitForXInput () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 5 (process 32852 thread 0x2303): > #0 0x96f433a6 in mach_wait_until () > #1 0x96fba3ad in nanosleep () > #2 0x002e423c in ThreadPThread__XPause () > #3 0x002e4393 in Thread__Pause () > #4 0x0011113a in FileBrowserVBT__Watcher () > #5 0x002e3651 in ThreadPThread__RunThread () > #6 0x002e33a3 in ThreadPThread__ThreadBase () > #7 0x96f74155 in _pthread_start () > #8 0x96f74012 in thread_start () > > Thread 4 (process 32852 thread 0x2203): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001883f9 in VTView__VFontCleanUpThread () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 3 (process 32852 thread 0x2103): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001eb9c2 in VBTRep__MeterMaid () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > > Thread 2 (process 32852 thread 0x313): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x002e65ec in RTOS__WaitHeap () > #6 0x002d2d54 in RTCollector__WeakCleaner () > #7 0x002e3651 in ThreadPThread__RunThread () > #8 0x002e33a3 in ThreadPThread__ThreadBase () > #9 0x96f74155 in _pthread_start () > #10 0x96f74012 in thread_start () > > Thread 1 (process 32852 local thread 0x2d03): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x002e3ddb in Thread__Join () > #6 0x0028f53d in Formatter__Close () > #7 0x00079485 in JunoUnparse__Expr () > #8 0x00021721 in Editor__Pass4 () > #9 0x00022048 in EditorUI__CompileUI () > #10 0x0003e7f8 in Juno__CompileEditor () > #11 0x0003e98d in Juno__CompileModule () > #12 0x0003f3be in Juno__CompileModules () > #13 0x0004d43d in Juno_M3 () > #14 0x002d71fa in RTLinker__RunMainBody () > #15 0x002d67b0 in RTLinker__AddUnitI () > #16 0x002d682e in RTLinker__AddUnit () > #17 0x00003c88 in main () > > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 6 Sep 2009 12:30:27 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other > problems) > > Tony both of these timestamps are somewhat prone to hanging during > Juno I386_DARWIN startup. But they don't crash, er..well they do > both fail assertions in text, but I just put current source in to > address that. I'm going to search backward for a time that doesn't > hang. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 4 Sep 2009 12:44:21 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other > problems) > > Jay, > > I can rapidly diagnose any problems in the code you have been > messing with. Let me get a version on the head that "works" (at > least for non-Windows) and then we can move on to see what other > problems there may be in the WIndows part of the workd. > > -- Tony > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 4 Sep 2009, at 10:40, Jay K wrote: > > no..still unsolved..not sure if I misobserved or what..will have to > backtrack.. > > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:07:46 +0000 > > (Well, duh, it wasn't ProcessPools(SuspendPool), that just has > assertions) > > - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:06:08 +0000 > > Restoring the: > ThreadF.ProcessPools(ClosePool); > > 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. > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 11:52:28 +0000 > > I have narrowed it way down to between "2009-02-16 02:00Z" and -D > "2009-02-16 02:30Z". > So please review this change. > I have reviewed it and tried to partly undo it, without luck yet. > There is a semantic change in BroadcastHeap where the broadcast used > to happen upon the next unlock > and now I think happens right away. I tried restoring that, but > again, no luck for me. > > Thanks, > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 09:12:23 +0000 > > I have narrowed it down further to between 2/15/2009 and 2/18/2009. > Next I will try old text code in head to see if it is that. > > Tony, can you double check this stuff: > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > > 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..). > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 08:54:54 +0000 > Subject: [M3devel] Juno on NT (presumably canary for other problems) > > short story: > > > I narrowed it down to between 2/15/2009 and 2/20/2009. > I will keep digging. > > There are actually a lot of changes in that brief period. > I will narrow it further. > > > long story: > > Juno on NT, as canary for other problems. > Juno on NT has three behaviors. > > > Behavior #1 > > > The most common historical behavior, an assertion failure: > C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\winvbt\WinContext.m3", line 165 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt > \WinContext.m3 > 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 > 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 > 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe30 0x7e418734 > 0x1b3fe98 0x7e418816 > 0x1b3fef8 0x7e4189cd > 0x1b3ff08 0x7e4196c7 > 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt > \WinTrestle.m3 > ......... ......... ... more frames ... > (1860.1d80): Break instruction exception - code 80000003 (first > chance) > eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 > edi=005d526b > eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz > na po nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00000202 > ntdll!DbgBreakPoint: > 7c90120e cc int 3 > 0:003> .lines > Line number information will be loaded > 0:003> k999 > ChildEBP RetAddr > 01b3f5bc 005d52b7 ntdll!DbgBreakPoint > 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime > \WIN32\RTOS.m3 @ 29] > 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common > \RTProcess. > m3 @ 66] > 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime > \common\RTError.m > 3 @ 118] > 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common > \RTError.m3 @ > 40] > 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime > \common\RTExcep > tion.m3 @ 79] > 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src > \runtime\commo > n\RTException.m3 @ 39] > 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src > \runtime\commo > n\RTException.m3 @ 47] > 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime > \common\RTHook > s.m3 @ 110] > 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt > \WinContext.m3 @ 1 > 7] > 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt > \WinContext.m3 > @ 167] > 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt > \WinPaint.m3 @ 71 > 2] > 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt > \WinPaint.m3 @ 5 > 1] > 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt > \WinTrestle > .m3 @ 1574] > 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt > \WinTrestle.m3 > @ 1163] > 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 > 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 > 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 > 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf > 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src > \winvbt\WinTrestl > e.m3 @ 2450] > 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread > \WIN32\Threa > dWin32.m3 @ 579] > 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread > \WIN32\Threa > dWin32.m3 @ 548] > 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 > 0:003> > > > This we shall blame on Trestle not fully being ported to Win32, I > guess. > At the very least, it seems to the behavior going back a while. > You can occasionally see this in head, but usually you see #3. > > > Behavior #2 > > Sometimes, rarely, Juno hangs in startup on NT. > I believe I have seen this both with fairly old and current versions. > This occurs very rarely. I might look into it more after #3 is solved. > > > Behavior #3 > > > An access violation (SIGSEGV to Unix folks) during startup. > This is the most common behavior with current source, going back a > few months. > It is almost always accessing address 00200000 and the instruction > pointer is very > often in Thread__Join, but neither are always true. > Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. > > > C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe > (1ac4.1e9c): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 > edi=02812974 > eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > m3core!Thread__Join+0x13f: > 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds: > 0023:001ffffc=???????? > 0:000> r ebx > ebx=00200000 > 0:000> .lines > Line number information will be loaded > 0:000> k > ChildEBP RetAddr > 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread > \WIN32\ThreadWin32.m3 > @ 710] > 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src > \JunoCompile. > m3 @ 256] > 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] > 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] > 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] > 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] > 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ > 174] > 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ > 263] > 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] > 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime > \common\RTLi > nker.m3 @ 399] > 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime > \common\RTLinker > .m3 @ 113] > 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime > \common\RTLinker. > m3 @ 122] > 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] > 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld > \self_x86\c > rt\src\crtexe.c @ 582] > 0012fff0 00000000 kernel32!BaseProcessStart+0x23 > 0:000> > > #4 sometimes other, for example: > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 411 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common > \RTCollector.m3 > 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common > \RTCollector.m > 3 > 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common > \RTCollector.m3 > 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src > \runtime\common\RT > Collector.m3 > 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common > \RTCollector.m3 > 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common > \RTCollector. > m3 > 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common > \RTCollector.m3 > ......... ......... ... more frames ... > (14b0.121c): Break instruction exception - code 80000003 (first > chance) > > for example: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\src\vbt\VBTRep.m3", line 644 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 > 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 > 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 > 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > (1c3c.e3c): Break instruction exception - code 80000003 (first chance) > > I figure these are just a variation of #3. > > Now, I finally learned how to give CVS a date to checkout or update. > And NT builds very fast due to the integrated backend. > So I have been building various dates. > > The change between #3 and #1 happened around mid February 2009. > Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, > #4 above is from 2009/02/20. > And 2009/02/20 also access violates on 00200000 often. > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 7 17:17:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Sep 2009 11:17:50 -0400 Subject: [M3devel] (no subject) In-Reply-To: References: Message-ID: Jay, Before you go off half cocked and brew up some new threads system might I suggest that it would be better to find and fix the current problem. I am sceptical that there is a much thinner M3 thread implementation on top of pthreads than we currently have. I am in the process of tracking down the problem on I386_DARWIN (I see at least one thing broken right now, and will have a fix soon). In answer to your question, the wait list is to deal with M3 alerts, which are not the same as pthread cancellation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Sep 2009, at 05:33, Jay K wrote: > Tony, can you..um, trick question sort of, briefly explain the > differences between pthreads and Modula-3 threads? > The "trick" part is that, to an audience (me) who is not all that > familiar with the nuances of either? > I'll see if I can find my green book and other reference material > (online). > > > I understand the basics of threading very well, if that helps. > Eh, not much to it really. > > > I'm not super familiar with condition variables, as Win32 didn't > historically have them. > But I think I understand them. > > > Specific questions: > Can Modula-3 threads be implemented more directly upon pthreads? > > > Why do we need to maintain a waiting list? > > > Is "alert" the same as "cancel" in pthread vocabulary? Or almost > the same? > > > I understand..there might be a difficult problem..does Modula-3 > allow catching an alert? I think so. > Does Posix allow canceling a cancel? I think not. > > > Posix allows, what I think of as try/finally, for alert. Modula-3 > probably does too. Even though you can't stop the cancel, you can > run "cleanup" code that runs before the cancel completes. > > > However mapping Modula-3 to Posix here would be tricky. As I see > things..any function with a try/finally would have to be contorted > into a form that passes a pointer to itself, along with parameters, > to C code that does pthread_cleanup_push/pop around calling the > function pointer. At least given the Darwin implementation. Other > implementations might simply be able to call push at the start and > pop at the end. But on Darwin these functions are macros where push > introduces a local variable that pop references. I guess maybe one > could to the "reverse engineering" approach (just by reading the > header). But it'd still be ugly. > > > I have to do more research here. > > > I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is > thinner than the current ThreadPThread.m3 and see how it fairs, > specifically if the Juno hangs go away. > "writing" being an exaggeration because it should be very small. > > > Thanks, > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Sep 7 17:30:52 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 7 Sep 2009 15:30:52 +0000 (GMT) Subject: [M3devel] (no subject) Threads Primitives In-Reply-To: Message-ID: <258903.40993.qm@web23604.mail.ird.yahoo.com> Hi all: Please consider this reading:? "Synchronization Primitives for Threads" which has a formal definition and proof for threads primitives: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.1092 and? "Pthreads and Applications of Mutex-Abstraction" http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5367 Also the formal definition of the thread Interface from DEC SRC research Report 20 (revised in the Green book, Systems programming with Modula-3 as? Chapter 5): ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/abstracts/src-rr-020.html and? an introduction to programming with Threads DEC SRC research Report 35 (revised in the Green book, Systems programming with Modula-3 as? Chapter 4) ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/SRC-035.pdf Hope it helps --- El lun, 7/9/09, Jay K escribi?: De: Jay K Asunto: [M3devel] (no subject) Para: "Tony" , "m3devel" Fecha: lunes, 7 septiembre, 2009 4:33 #yiv792797967 .hmmessage P { margin:0px;padding:0px;} #yiv792797967 { font-size:10pt;font-family:Verdana;} Tony, can you..um, trick question sort of, briefly explain the differences between pthreads and Modula-3 threads? The "trick" part is that, to an audience (me) who is not all that familiar with the nuances of either? I'll see if I can find my green book and other reference material (online). I understand the basics of threading very well, if that helps. Eh, not much to it really. I'm not super familiar with condition variables, as Win32 didn't historically have them. But I think I understand them. Specific questions: ? Can Modula-3 threads be implemented more directly upon pthreads? ? Why do we need to maintain a waiting list? ? Is "alert" the same as "cancel" in pthread vocabulary? Or almost the same? ? I understand..there might be a difficult problem..does Modula-3 allow catching an alert? I think so. ? Does Posix allow canceling a cancel? I think not. ? Posix allows, what I think of as try/finally, for alert. Modula-3 probably does too. Even though you can't stop the cancel, you can run "cleanup" code that runs before the cancel completes. However mapping Modula-3 to Posix here would be tricky. As I see things..any function with a try/finally would have to be contorted into a form that passes a pointer to itself, along with parameters, to C code that does pthread_cleanup_push/pop around calling the function pointer. At least given the Darwin implementation. Other implementations might simply be able to call push at the start and pop at the end. But on Darwin these functions are macros where push introduces a local variable that pop references. I guess maybe one could to the "reverse engineering" approach (just by reading the header). But it'd still be ugly. I have to do more research here. I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is thinner than the current ThreadPThread.m3 and see how it fairs, specifically if the Juno hangs go away. "writing" being an exaggeration because it should be very small. Thanks, ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 18:03:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 16:03:21 +0000 Subject: [M3devel] Modula-3 threads vs. pthreads? In-Reply-To: References: Message-ID: To answer part of my question the same as you did, this (buggy -- race conditions) program demonstrates that Alert is catchable, whereas apparently pthread_cancel is not. MODULE Main; IMPORT IO, Thread; PROCEDURE ThreadMain (<* UNUSED *> closure: Thread.Closure): REFANY = VAR i := 0; BEGIN TRY LOOP TRY Thread.AlertPause(0.01D0); IO.PutInt(i); IO.Put("\n"); EXCEPT Thread.Alerted => IO.Put("Thread.Alerted 1\n"); INC(i, 1); IF i = 10 THEN (*RAISE Thread.Alerted;*) RETURN NIL; END; ELSE IO.Put("Thread.Alerted 3?\n"); END END; FINALLY IO.Put("Thread.Alerted 2\n"); END; RETURN NIL; END ThreadMain; VAR a := Thread.Fork(NEW(Thread.Closure, apply := ThreadMain)); BEGIN FOR i := 1 TO 10 DO Thread.Pause(1.0D0); Thread.Alert(a); END; EVAL Thread.Join(a); END Main. Thanks, - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: Date: Mon, 7 Sep 2009 11:17:50 -0400 Jay, Before you go off half cocked and brew up some new threads system might I suggest that it would be better to find and fix the current problem. I am sceptical that there is a much thinner M3 thread implementation on top of pthreads than we currently have. I am in the process of tracking down the problem on I386_DARWIN (I see at least one thing broken right now, and will have a fix soon). In answer to your question, the wait list is to deal with M3 alerts, which are not the same as pthread cancellation. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Sep 2009, at 05:33, Jay K wrote:Tony, can you..um, trick question sort of, briefly explain the differences between pthreads and Modula-3 threads? The "trick" part is that, to an audience (me) who is not all that familiar with the nuances of either? I'll see if I can find my green book and other reference material (online). I understand the basics of threading very well, if that helps. Eh, not much to it really. I'm not super familiar with condition variables, as Win32 didn't historically have them. But I think I understand them. Specific questions: Can Modula-3 threads be implemented more directly upon pthreads? Why do we need to maintain a waiting list? Is "alert" the same as "cancel" in pthread vocabulary? Or almost the same? I understand..there might be a difficult problem..does Modula-3 allow catching an alert? I think so. Does Posix allow canceling a cancel? I think not. Posix allows, what I think of as try/finally, for alert. Modula-3 probably does too. Even though you can't stop the cancel, you can run "cleanup" code that runs before the cancel completes. However mapping Modula-3 to Posix here would be tricky. As I see things..any function with a try/finally would have to be contorted into a form that passes a pointer to itself, along with parameters, to C code that does pthread_cleanup_push/pop around calling the function pointer. At least given the Darwin implementation. Other implementations might simply be able to call push at the start and pop at the end. But on Darwin these functions are macros where push introduces a local variable that pop references. I guess maybe one could to the "reverse engineering" approach (just by reading the header). But it'd still be ugly. I have to do more research here. I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is thinner than the current ThreadPThread.m3 and see how it fairs, specifically if the Juno hangs go away. "writing" being an exaggeration because it should be very small. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Mon Sep 7 14:22:03 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Mon, 07 Sep 2009 14:22:03 +0200 Subject: [M3devel] Server Maint. birch.elego.de tonight 22:00 CEST Message-ID: <20090907142203.thu0879lw4oosc8w@mail.elego.de> Hallo, Heute Abend um 22:00 Uhr CEST wird der Server birch.elego.de kurz herunterfahren um eine fehlerhafte Festplatte zu ersetzen. Betroffen werden www/ftp.elegosoft.com, die modula3 Websites, sowie die modula3 cvs Repositories and continuous-integration Dienste. Wir bitten um Verst?ndnis. - die elego Admins The server birch.elego.de will be taken offline for a short time this evening at 22:00 CEST in order to replace a failing disk drive. The internet sites www/ftp.elegosoft.de, www/ftp.elego.de, the modula3 sites, as well as the modula3 cvs repositories and continuous integration servers will be affected. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 8 03:22:29 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 7 Sep 2009 18:22:29 -0700 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: When did it work? I have looked quite a bit and have not found anything that works. - Jay (phone) On Sep 7, 2009, at 8:06 AM, Tony Hosking wrote: > It used to work... > > :-) > > On 6 Sep 2009, at 21:49, Jay K wrote: > >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of >> stack. >> Current LINUXLIBC6 Juno doesn't seem to ever hang. >> So I conclude, with obvious non scientific firmness, that the >> Darwin-specific threading has never really worked and that the >> problem lies with it, not within the common code (or perhaps in the >> common code but only in how it mixes with the Darwin code). >> >> - Jay >> >> >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Sun, 6 Sep 2009 16:11:28 +0000 >> >> Tony, I386_DARWIN Juno is very prone to hang during startup going >> back at least until 2007/12/01. >> But they certainly don't always hang. >> I haven't found a version yet that doesn't hang. I'll look some >> more. I guess soon I should try other platforms? >> Sometimes there is a pause and it continues. Perhaps the hangs >> I'm just being too impatient on?? >> But, then, it's a bit inconsistent. >> Has it ever worked? >> Race condition in Juno maybe? >> It isn't always easy to build these old dates. >> Caveats: >> I'm using just current cm3cg. I started seeing as complain about >> older cm3cg output. >> Current config files. >> Build standalone (as current config files do with older compilers >> automatically, for "old" == missing the symlink functions). >> Patched XSharedMem/IsSameHost to always be FALSE, though TRUE >> would be correct, FALSE seems safe, I have to read that code.. >> >> Here is 2007/12/01 hung. >> It got as far as displaying "Curve" in the startup text that goes by. >> >> (gdb) thread apply all bt >> >> Thread 9 (process 32852 thread 0x294f): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1e8c in Thread__AlertWait () >> #5 0x00290988 in Formatter__Allocate () >> #6 0x00291137 in Formatter__Probe () >> #7 0x0029178e in Formatter__Peek () >> #8 0x00291677 in Formatter__PeekOp () >> #9 0x00291d18 in Formatter__PrintUntil () >> #10 0x002918d2 in Formatter__PrintTop () >> #11 0x002e3651 in ThreadPThread__RunThread () >> #12 0x002e33a3 in ThreadPThread__ThreadBase () >> #13 0x96f74155 in _pthread_start () >> #14 0x96f74012 in thread_start () >> >> Thread 8 (process 32852 thread 0x2603): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001aad83 in XMessenger__Messenger () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 7 (process 32852 thread 0x2503): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001b68da in XInput__FilterXInput () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 6 (process 32852 thread 0x240f): >> #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () >> #1 0x96fc8261 in select () >> #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () >> #3 0x002e4b05 in ThreadPThread__XIOWait () >> #4 0x002e4614 in SchedulerPosix__IOWait () >> #5 0x001b65f5 in XInput__WaitForXInput () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 5 (process 32852 thread 0x2303): >> #0 0x96f433a6 in mach_wait_until () >> #1 0x96fba3ad in nanosleep () >> #2 0x002e423c in ThreadPThread__XPause () >> #3 0x002e4393 in Thread__Pause () >> #4 0x0011113a in FileBrowserVBT__Watcher () >> #5 0x002e3651 in ThreadPThread__RunThread () >> #6 0x002e33a3 in ThreadPThread__ThreadBase () >> #7 0x96f74155 in _pthread_start () >> #8 0x96f74012 in thread_start () >> >> Thread 4 (process 32852 thread 0x2203): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001883f9 in VTView__VFontCleanUpThread () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 3 (process 32852 thread 0x2103): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001eb9c2 in VBTRep__MeterMaid () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> >> Thread 2 (process 32852 thread 0x313): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x002e65ec in RTOS__WaitHeap () >> #6 0x002d2d54 in RTCollector__WeakCleaner () >> #7 0x002e3651 in ThreadPThread__RunThread () >> #8 0x002e33a3 in ThreadPThread__ThreadBase () >> #9 0x96f74155 in _pthread_start () >> #10 0x96f74012 in thread_start () >> >> Thread 1 (process 32852 local thread 0x2d03): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x002e3ddb in Thread__Join () >> #6 0x0028f53d in Formatter__Close () >> #7 0x00079485 in JunoUnparse__Expr () >> #8 0x00021721 in Editor__Pass4 () >> #9 0x00022048 in EditorUI__CompileUI () >> #10 0x0003e7f8 in Juno__CompileEditor () >> #11 0x0003e98d in Juno__CompileModule () >> #12 0x0003f3be in Juno__CompileModules () >> #13 0x0004d43d in Juno_M3 () >> #14 0x002d71fa in RTLinker__RunMainBody () >> #15 0x002d67b0 in RTLinker__AddUnitI () >> #16 0x002d682e in RTLinker__AddUnit () >> #17 0x00003c88 in main () >> >> >> - Jay >> >> >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 6 Sep 2009 12:30:27 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Juno on NT (presumably canary for other >> problems) >> >> Tony both of these timestamps are somewhat prone to hanging during >> Juno I386_DARWIN startup. But they don't crash, er..well they do >> both fail assertions in text, but I just put current source in to >> address that. I'm going to search backward for a time that doesn't >> hang. >> >> - Jay >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Fri, 4 Sep 2009 12:44:21 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Juno on NT (presumably canary for other >> problems) >> >> Jay, >> >> I can rapidly diagnose any problems in the code you have been >> messing with. Let me get a version on the head that "works" (at >> least for non-Windows) and then we can move on to see what other >> problems there may be in the WIndows part of the workd. >> >> -- Tony >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 4 Sep 2009, at 10:40, Jay K wrote: >> >> no..still unsolved..not sure if I misobserved or what..will have to >> backtrack.. >> >> >> - Jay >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 14:07:46 +0000 >> >> (Well, duh, it wasn't ProcessPools(SuspendPool), that just has >> assertions) >> >> - Jay >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 14:06:08 +0000 >> >> Restoring the: >> ThreadF.ProcessPools(ClosePool); >> >> 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. >> >> - Jay >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 11:52:28 +0000 >> >> I have narrowed it way down to between "2009-02-16 02:00Z" and -D >> "2009-02-16 02:30Z". >> So please review this change. >> I have reviewed it and tried to partly undo it, without luck yet. >> There is a semantic change in BroadcastHeap where the broadcast >> used to happen upon the next unlock >> and now I think happens right away. I tried restoring that, but >> again, no luck for me. >> >> Thanks, >> - Jay >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 09:12:23 +0000 >> >> I have narrowed it down further to between 2/15/2009 and 2/18/2009. >> Next I will try old text code in head to see if it is that. >> >> Tony, can you double check this stuff: >> >> 2009-02-16 02:20 hosking >> >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ >> dtoa.c, >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ >> ThreadPThreadC.i3, >> thread/WIN32/ThreadWin32.m3: >> >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better >> match underlying pthread semantics. >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap >> is held. >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or >> not. >> >> >> 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..). >> >> >> - Jay >> >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Fri, 4 Sep 2009 08:54:54 +0000 >> Subject: [M3devel] Juno on NT (presumably canary for other problems) >> >> short story: >> >> >> I narrowed it down to between 2/15/2009 and 2/20/2009. >> I will keep digging. >> >> There are actually a lot of changes in that brief period. >> I will narrow it further. >> >> >> long story: >> >> Juno on NT, as canary for other problems. >> Juno on NT has three behaviors. >> >> >> Behavior #1 >> >> >> The most common historical behavior, an assertion failure: >> C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "..\src\winvbt\WinContext.m3", line 165 >> *** >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt >> \WinContext.m3 >> 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 >> 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 >> 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt >> \WinTrestle.m3 >> 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt >> \WinTrestle.m3 >> 0x1b3fe30 0x7e418734 >> 0x1b3fe98 0x7e418816 >> 0x1b3fef8 0x7e4189cd >> 0x1b3ff08 0x7e4196c7 >> 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt >> \WinTrestle.m3 >> ......... ......... ... more frames ... >> (1860.1d80): Break instruction exception - code 80000003 (first >> chance) >> eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 >> edi=005d526b >> eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl >> nz na po nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00000202 >> ntdll!DbgBreakPoint: >> 7c90120e cc int 3 >> 0:003> .lines >> Line number information will be loaded >> 0:003> k999 >> ChildEBP RetAddr >> 01b3f5bc 005d52b7 ntdll!DbgBreakPoint >> 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime >> \WIN32\RTOS.m3 @ 29] >> 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime >> \common\RTProcess. >> m3 @ 66] >> 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime >> \common\RTError.m >> 3 @ 118] >> 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common >> \RTError.m3 @ >> 40] >> 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime >> \common\RTExcep >> tion.m3 @ 79] >> 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src >> \runtime\commo >> n\RTException.m3 @ 39] >> 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src >> \runtime\common >> \RTException.m3 @ 25] >> 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime >> \ex_frame\RTExFr >> ame.m3 @ 29] >> 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src >> \runtime\commo >> n\RTException.m3 @ 47] >> 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src >> \runtime\common >> \RTException.m3 @ 25] >> 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime >> \ex_frame\RTExFr >> ame.m3 @ 29] >> 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime >> \common\RTHook >> s.m3 @ 110] >> 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt >> \WinContext.m3 @ 1 >> 7] >> 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt >> \WinContext.m3 >> @ 167] >> 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt >> \WinPaint.m3 @ 71 >> 2] >> 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt >> \WinPaint.m3 @ 5 >> 1] >> 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src >> \winvbt\WinTrestle >> .m3 @ 1574] >> 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt >> \WinTrestle.m3 >> @ 1163] >> 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 >> 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 >> 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 >> 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf >> 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src >> \winvbt\WinTrestl >> e.m3 @ 2450] >> 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread >> \WIN32\Threa >> dWin32.m3 @ 579] >> 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread >> \WIN32\Threa >> dWin32.m3 @ 548] >> 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 >> 0:003> >> >> >> This we shall blame on Trestle not fully being ported to Win32, I >> guess. >> At the very least, it seems to the behavior going back a while. >> You can occasionally see this in head, but usually you see #3. >> >> >> Behavior #2 >> >> Sometimes, rarely, Juno hangs in startup on NT. >> I believe I have seen this both with fairly old and current versions. >> This occurs very rarely. I might look into it more after #3 is >> solved. >> >> >> Behavior #3 >> >> >> An access violation (SIGSEGV to Unix folks) during startup. >> This is the most common behavior with current source, going back a >> few months. >> It is almost always accessing address 00200000 and the instruction >> pointer is very >> often in Thread__Join, but neither are always true. >> Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. >> >> >> C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe >> (1ac4.1e9c): Access violation - code c0000005 (first chance) >> First chance exceptions are reported before any exception handling. >> This exception may be expected and handled. >> eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 >> edi=02812974 >> eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl >> nz na pe nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00010206 >> m3core!Thread__Join+0x13f: >> 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds: >> 0023:001ffffc=???????? >> 0:000> r ebx >> ebx=00200000 >> 0:000> .lines >> Line number information will be loaded >> 0:000> k >> ChildEBP RetAddr >> 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread >> \WIN32\ThreadWin32.m3 >> @ 710] >> 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src >> \JunoCompile. >> m3 @ 256] >> 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] >> 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ >> 813] >> 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] >> 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ >> 140] >> 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ >> 174] >> 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ >> 263] >> 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] >> 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime >> \common\RTLi >> nker.m3 @ 399] >> 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime >> \common\RTLinker >> .m3 @ 113] >> 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime >> \common\RTLinker. >> m3 @ 122] >> 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] >> 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools >> \crt_bld\self_x86\c >> rt\src\crtexe.c @ 582] >> 0012fff0 00000000 kernel32!BaseProcessStart+0x23 >> 0:000> >> >> #4 sometimes other, for example: >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 411 >> *** >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common >> \RTCollector.m3 >> 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common >> \RTHeapMap.m3 >> 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common >> \RTHeapMap.m3 >> 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common >> \RTHeapMap.m3 >> 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common >> \RTCollector.m >> 3 >> 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common >> \RTCollector.m3 >> 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src >> \runtime\common\RT >> Collector.m3 >> 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common >> \RTCollector.m3 >> 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common >> \RTCollector. >> m3 >> 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common >> \RTCollector.m3 >> ......... ......... ... more frames ... >> (14b0.121c): Break instruction exception - code 80000003 (first >> chance) >> >> for example: >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "..\src\vbt\VBTRep.m3", line 644 >> *** >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 >> 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 >> 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 >> 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread >> \WIN32\ThreadWin32.m3 >> 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread >> \WIN32\ThreadWin32.m3 >> ......... ......... ... more frames ... >> (1c3c.e3c): Break instruction exception - code 80000003 (first >> chance) >> >> I figure these are just a variation of #3. >> >> Now, I finally learned how to give CVS a date to checkout or update. >> And NT builds very fast due to the integrated backend. >> So I have been building various dates. >> >> The change between #3 and #1 happened around mid February 2009. >> Specifically, ignoring the rare #2, 2009/02/15 always fails an >> assert, >> #4 above is from 2009/02/20. >> And 2009/02/20 also access violates on 00200000 often. >> >> >> - Jay >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 07:58:53 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 01:58:53 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Here's the hang I see for juno running on I386_DARWIN. If the stack is overflowing this could cause a hang. Otherwise, I see nothing innately suspicious in these thread backtraces. Any ideas? Thread 8 (process 94794 thread 0x2a9f): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x17a6844, M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e7a6 in Thread__AlertWait (M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x0075cdf2 in Formatter__Allocate (M3_ACp9GL_t=0x16e99fc, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x0075cf0a in Formatter__Probe (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x0075d2b8 in Formatter__Peek (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x0075d2ff in Formatter__PeekOp (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x0075db25 in Formatter__PrintUntil (M3_ACp9GL_t=0x16e99fc, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x2162430) at ../src/ formatter/Formatter.m3:708 #10 0x0075dfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x17a6834) at ../ src/formatter/Formatter.m3:615 #11 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1527e00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1527e00) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 7 (process 94794 thread 0x2503): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x1705d88, M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044a0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044a0) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x004c1962 in XMessenger__Messenger (M3_EVlqQO_self=0x1705d78) at ../src/xvbt/XMessenger.m3:69 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1511f60) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1511f60) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 6 (process 94794 thread 0x2407): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x1705d38, M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044c0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044c0) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x004c7bc2 in XInput__FilterXInput (M3_DSd60P_self=0x1705d28) at ../src/xvbt/XInput.m3:102 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1511de0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1511de0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 5 (process 94794 thread 0x230f): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x00944503 in Unix__select (nfds=4, readfds=0x17a90c4, writefds=0x17a90d4, exceptfds=0x17a90e4, timeout=0x0) at ../src/unix/ Common/UnixC.c:301 #2 0x00941970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ PTHREAD/ThreadPThread.m3:788 #3 0x009416cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1705ce8, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ PTHREAD/ThreadPThread.m3:827 #4 0x009411b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ thread/PTHREAD/ThreadPThread.m3:730 #5 0x004c920b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1705cd8) at ../src/xvbt/XInput.m3:63 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1511d10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1511d10) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 4 (process 94794 thread 0x2203): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x00943cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x00940d7c in ThreadPThread__XPause (M3_BXP32l_self=0x1640ed8, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:669 #4 0x00940ef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:686 #5 0x0031bd53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1640ed0) at ../src/lego/FileBrowserVBT.m3:259 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1510200) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1510200) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 3 (process 94794 thread 0x2103): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x160c410, M3_AYIbX3_m=0x160c3ec, M3_Bl0jv4_c=0x160c3f8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x160c3ec, M3_Bl0jv4_c=0x160c3f8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0038d9e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x160c408) at ../src/vtext/VTView.m3:111 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x15103a0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x15103a0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 2 (process 94794 thread 0x1003): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x16079d8, M3_AYIbX3_m=0x1607998, M3_Bl0jv4_c=0x16079a4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x1607998, M3_Bl0jv4_c=0x16079a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x004fd3d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x16079cc) at ../ src/vbt/VBTRep.m3:439 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x150fdd0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x150fdd0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 1 (process 94794 thread 0x10b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x160000c, M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0075c592 in Formatter__WaitUntilEmpty (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_index=) at ../src/formatter/Formatter.m3:491 #6 0x0076092a in Formatter__Flush (M3_ACp9GL_t=0x16e99fc) at ../src/ formatter/Formatter.m3:219 #7 0x0014d2f3 in JunoUnparse__Unparse (M3_ACp9GL_fmt=0x16e99fc, M3_Dpy7Ic_ast=0x16e9520, M3_AcxOUs_tokens=2147483647, M3_AcxOUs_indent=0, M3_AcxOUs_prec=3, M3_AicXUJ_debug=0 '\0', M3_AicXUJ_private=1 '\001', M3_Dpy7Ic_errast=0x0) at ../src/ JunoUnparse.m3:1016 #8 0x0014d5f9 in JunoUnparse__Expr (M3_BxxOH1_wr=0x16e9548, M3_ATZ4pH_ast=0x16e9520, M3_Cwb5VA_tokens=, M3_Cwb5VA_indent=, M3_Cwb5VA_width=, M3_Cwb5VA_prec=, M3_AicXUJ_debug=0 '\0') at ../src/ JunoUnparse.m3:52 #9 0x0001da6e in Editor__Pass4 (M3_EchL3i_rt=0x16df008, M3_ALfX9C_ed=0x240ddbc, M3_ClYh8q_scp=0x161b7dc) at ../src/Editor.m3:904 #10 0x0002204d in EditorUI__CompileUI (M3_EchL3i_rt=0x16df008, M3_ALfX9C_te=0x240ddbc, M3_AcxOUs_time=0, M3_ClYh8q_scp=0x161b7dc) at ../src/Editor.m3:1007 #11 0x00046b70 in Juno__CompileEditor (M3_EchL3i_rt=0x16df008, M3_ALfX9C_ed=0x240ddbc, M3_AcxOUs_time=0, M3_ClYh8q_scp=0x16dedd8, M3_A0YqHX_modName=0xbfffe870, M3_EmmWP2_entity=0xbfffe86c, M3_AicXUJ_uniqueModName=1 '\001') at ../src/Juno.m3:140 #12 0x00046eeb in Juno__CompileModule (M3_BtMpDB_w=0x1764f78, M3_Bd56fi_mod=0x2408b00, M3_EkTcCb_rd=0x240d7d0, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:174 #13 0x00047b59 in Juno__CompileModules (M3_BtMpDB_w=0x1764f78, M3_EkTcCb_rd=0x17a35a4, M3_Al6NTd_modList=0xbfffec94, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #14 0x0004a9d9 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #15 0x0092fb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x5aee0) at ../ src/runtime/common/RTLinker.m3:399 #16 0x00002518 in main (argc=1, argv=0xbfffedec, envp=0xbfffedf4) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 08:09:28 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 02:09:28 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:668 #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:685 #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ src/xvbt/XClientF.m3:105 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103): #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ thread/PTHREAD/ThreadPThread.m3:319 #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../ src/thread/PTHREAD/ThreadPThread.m3:669 #2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ ThreadPThread.m3:699 #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ src/Animate.m3:71 #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313 #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ src/bresenham/ViewError.m3:548 #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ src/Zeus.m3:331 #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #11 0x96373155 in _pthread_start () #12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ src/Zeus.m3:328 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ src/Zeus.m3:328 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03): #0 0x963493dc in _pthread_testcancel () #1 0x96349275 in nanosleep$UNIX2003 () #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:668 #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ PTHREAD/ThreadPThread.m3:685 #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/ vtext/VTCaret.m3:149 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ Common/UnixC.c:301 #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ PTHREAD/ThreadPThread.m3:787 #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ PTHREAD/ThreadPThread.m3:826 #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ thread/PTHREAD/ThreadPThread.m3:729 #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 #7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../ src/bresenham/AlgBresenham.m3:55 #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ src/bresenham/AlgBresenham.m3:86 #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../ src/ZeusPanel.m3:1534 #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../ src/formatter/Formatter.m3:615 #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../ src/formatter/Formatter.m3:615 #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/ unix/Common/UnixC.c:301 #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/ thread/PTHREAD/ThreadPThread.m3:787 #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ src/thread/PTHREAD/ThreadPThread.m3:742 #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/ TCP.m3:234 #7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #10 0x96373155 in _pthread_start () #11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:668 #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:685 #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ src/vbt/VBTRep.m3:439 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ src/trestle/Trestle.m3:884 #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ src/runtime/common/RTLinker.m3:399 #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:09:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:09:31 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <20090908074840.EB4811A2079@async.async.caltech.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <20090908074840.EB4811A2079@async.async.caltech.edu> Message-ID: Nice thing about pthreads is everyone uses them. Whatever tools they have, we can use. ..Jay > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) > Date: Tue, 8 Sep 2009 00:48:40 -0700 > From: mika at async.async.caltech.edu > > > A nice thing about the user threads system is that it has a beautiful > deadlock detector... do you have anything like this in the pthreads > environment? > > Mika > > Tony Hosking writes: > > > >--Apple-Mail-13--794937978 > >Content-Type: text/plain; > > charset=US-ASCII; > > format=flowed; > > delsp=yes > >Content-Transfer-Encoding: 7bit > > > >Here's the hang backtrace for mentor. Again, all appears normal, > >except that all the threads are paused or waiting, which is > >suspicious. I'm stumped for now. > > > >Thread 21 (process 96727 thread 0x7403): > >#0 0x9634946e in __semwait_signal () > >#1 0x963492ef in nanosleep$UNIX2003 () > >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > >rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > >M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > >ThreadPThread.m3:668 > >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:685 > >#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > >src/xvbt/XClientF.m3:105 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 20 (process 96727 thread 0x7103): > >#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > >thread/PTHREAD/ThreadPThread.m3:319 > >#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > >M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../ > >src/thread/PTHREAD/ThreadPThread.m3:669 > >#2 0x01020024 in Thread__AlertPause > >(M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:699 > >#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > >M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > >src/Animate.m3:71 > >#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > >M3_BUucNs_duration=1) at ../src/MGV.m3:313 > >#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > >M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > >#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > >M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > >src/bresenham/ViewError.m3:548 > >#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > >M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > >#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > >src/Zeus.m3:331 > >#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#10 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#11 0x96373155 in _pthread_start () > >#12 0x96373012 in thread_start () > > > >Thread 19 (process 96727 thread 0x5d07): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > >M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > >M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > >M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > >src/Zeus.m3:328 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 18 (process 96727 thread 0x700b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > >M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > >M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > >M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > >src/Zeus.m3:328 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 17 (process 96727 thread 0x6e03): > >#0 0x963493dc in _pthread_testcancel () > >#1 0x96349275 in nanosleep$UNIX2003 () > >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > >rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > >M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > >ThreadPThread.m3:668 > >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:685 > >#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/ > >vtext/VTCaret.m3:149 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 16 (process 96727 thread 0x435b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > >M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > >M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > >at ../src/ZeusPanel.m3:1425 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 15 (process 96727 thread 0x420b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > >at ../src/View.m3:74 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 14 (process 96727 thread 0x4103): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > >at ../src/View.m3:74 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 13 (process 96727 thread 0x4003): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > >at ../src/View.m3:74 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 12 (process 96727 thread 0x2e03): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > >M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > >M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > >at ../src/xvbt/XMessenger.m3:69 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 11 (process 96727 thread 0x2b07): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > >M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > >M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > >at ../src/xvbt/XInput.m3:102 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 10 (process 96727 thread 0x2a23): > >#0 0x963916fa in select$DARWIN_EXTSN () > >#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > >writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > >Common/UnixC.c:301 > >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > >(M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:787 > >#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > >M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > >M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > >PTHREAD/ThreadPThread.m3:826 > >#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, > >M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ > >thread/PTHREAD/ThreadPThread.m3:729 > >#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > >at ../src/xvbt/XInput.m3:63 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 9 (process 96727 thread 0x29f3): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > >M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > >M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > >M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > >M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > >#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > >M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > >M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > >M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > >#7 0x000149a7 in BresenhamIE__ShowPixel > >(M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > >M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > >#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > >M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../ > >src/bresenham/AlgBresenham.m3:55 > >#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > >src/bresenham/AlgBresenham.m3:86 > >#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../ > >src/ZeusPanel.m3:1534 > >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#12 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#13 0x96373155 in _pthread_start () > >#14 0x96373012 in thread_start () > > > >Thread 8 (process 96727 thread 0x2803): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > >M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > >M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > >M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > >formatter/Formatter.m3:440 > >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > >M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > >M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > >formatter/Formatter.m3:708 > >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../ > >src/formatter/Formatter.m3:615 > >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#12 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#13 0x96373155 in _pthread_start () > >#14 0x96373012 in thread_start () > > > >Thread 7 (process 96727 thread 0x2703): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > >M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > >M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > >M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > >formatter/Formatter.m3:440 > >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > >M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > >M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > >formatter/Formatter.m3:708 > >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../ > >src/formatter/Formatter.m3:615 > >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#12 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#13 0x96373155 in _pthread_start () > >#14 0x96373012 in thread_start () > > > >Thread 6 (process 96727 thread 0x2603): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > >M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > >M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > >at ../src/WorkerPool.m3:152 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 5 (process 96727 thread 0x2313): > >#0 0x963916fa in select$DARWIN_EXTSN () > >#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > >writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/ > >unix/Common/UnixC.c:301 > >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > >(M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/ > >thread/PTHREAD/ThreadPThread.m3:787 > >#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > >M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > >M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > >#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= >type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > >src/thread/PTHREAD/ThreadPThread.m3:742 > >#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > >M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > >#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/ > >TCP.m3:234 > >#7 0x006dbc6b in LocalObjectSpace__SpaceAccept > >(M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > >#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#9 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#10 0x96373155 in _pthread_start () > >#11 0x96373012 in thread_start () > > > >Thread 4 (process 96727 thread 0x2003): > >#0 0x9634946e in __semwait_signal () > >#1 0x963492ef in nanosleep$UNIX2003 () > >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > >rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > >M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > >ThreadPThread.m3:668 > >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:685 > >#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > >at ../src/lego/FileBrowserVBT.m3:259 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 3 (process 96727 thread 0x1f03): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > >M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > >M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) > >at ../src/vtext/VTView.m3:111 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 2 (process 96727 thread 0xd07): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > >M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > >M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > >src/vbt/VBTRep.m3:439 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 1 (process 96727 thread 0x10b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > >M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > >#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > >#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > >src/runtime/common/RTLinker.m3:399 > >#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > >_m3main.mc:6 > > > > > >Antony Hosking | Associate Professor | Computer Science | Purdue > >University > >305 N. University Street | West Lafayette | IN 47907 | USA > >Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > >On 6 Sep 2009, at 23:18, Jay K wrote: > > > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> [was truncated again!] > >> > >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > >> stack > > > > > >--Apple-Mail-13--794937978 > >Content-Type: text/html; > > charset=US-ASCII > >Content-Transfer-Encoding: quoted-printable > > > > >-webkit-line-break: after-white-space; ">Here's the hang backtrace for = > >mentor.  Again, all appears normal, except that all the threads are = > >paused or waiting, which is suspicious.  I'm stumped for = > >now.

Thread 21 (process 96727 thread = > >0x7403):
#0  0x9634946e in __semwait_signal = > >()
#1  0x963492ef in nanosleep$UNIX2003 ()
#2 = > > 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb15d4db0, = > >rem=3D0xb15d4db8) at = > >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  0x0101fd7c = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1f3f880, M3_CtKayy_n=3D1, = > >M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  0x0101fef3 = > >in Thread__Pause (M3_CtKayy_n=3D1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  0x00bc9cf4 = > >in XClientF__MeterMaid (M3_AS2y1X_cl=3D0x1f3f870) at = > >../src/xvbt/XClientF.m3:105
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c441d0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c441d0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 20 (process 96727 thread = > >0x7103):
#0  ThreadPThread__XTestAlert = > >(M3_BXP32l_self=3D0x1e5c134) at = > >../src/thread/PTHREAD/ThreadPThread.m3:319
#1  0x0101fd9b = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e5c134, = > >M3_CtKayy_n=3D0.0056863520294427872, M3_AicXUJ_alertable=3D1 '\001') at = > >../src/thread/PTHREAD/ThreadPThread.m3:669
#2  0x01020024 = > >in Thread__AlertPause (M3_CtKayy_n=3D0.0056863520294427872) at = > >../src/thread/PTHREAD/ThreadPThread.m3:699
#3  0x008f9ea1 = > >in Animate__Do (M3_CCfZY3_t=3D0x1e7e3fc, M3_DsL7Zz_mg=3D0x0, = > >M3_AdEaVQ_v=3D0x1e5e0f8, M3_BUucNs_duration=3D1) at = > >../src/Animate.m3:71
#4  0x00909610 in MGV__Animation = > >(M3_AdEaVQ_v=3D0x1e5e0f8, M3_BUucNs_duration=3D1) at = > >../src/MGV.m3:313
#5  0x008921f9 in = > >GraphVBT__AnimateGraph (M3_Cj00zi_graph=3D0x1e5e00c, M3_BUucNs_t0=3D0, = > >M3_BUucNs_t1=3D1) at ../src/GraphVBT.m3:656
#6 = > > 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=3D0x1ed3060, = > >M3_AcxOUs_x=3D3, M3_AcxOUs_y=3D2, M3_AcxOUs_p1=3D6, M3_AcxOUs_p2=3D-2) = > >at ../src/bresenham/ViewError.m3:548
#7  0x0001529a in = > >BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D0x1ed3060, = > >M3_Af40ku_evt=3D0x1e08014) at = > >../I386_DARWIN/BresenhamIE.m3:101
#8  0x007abb9b in = > >Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c128) at = > >../src/Zeus.m3:331
#9  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fd80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#10 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3fd80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#11 0x96373155 in = > >_pthread_start ()
#12 0x96373012 in thread_start = > >()

Thread 19 (process 96727 thread = > >0x5d07):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c0bc, = > >M3_AYIbX3_m=3D0x1e3f9bc, M3_Bl0jv4_c=3D0x1edf34c, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc, = > >M3_Bl0jv4_c=3D0x1edf34c) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x007ab7f2 = > >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc, = > >M3_B74vJ1_view=3D0x1edf25c) at ../src/Zeus.m3:361
#6 = > > 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c0b0) at = > >../src/Zeus.m3:328
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fc80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3fc80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 18 (process 96727 thread = > >0x700b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c044, = > >M3_AYIbX3_m=3D0x1e3f9bc, M3_Bl0jv4_c=3D0x1ee3bac, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc, = > >M3_Bl0jv4_c=3D0x1ee3bac) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x007ab7f2 = > >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc, = > >M3_B74vJ1_view=3D0x1ee3b00) at ../src/Zeus.m3:361
#6 = > > 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c038) at = > >../src/Zeus.m3:328
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fa90) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3fa90) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 17 (process 96727 thread = > >0x6e03):
#0  0x963493dc in _pthread_testcancel = > >()
#1  0x96349275 in nanosleep$UNIX2003 ()
#2 = > > 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb134add0, = > >rem=3D0xb134add8) at = > >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  0x0101fd7c = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e54388, M3_CtKayy_n=3D0.5, = > >M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  0x0101fef3 = > >in Thread__Pause (M3_CtKayy_n=3D0.5) at = > >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  0x00a6f0c0 = > >in VTCaret__Blinker (M3_Axogco_arg=3D0x1e5437c) at = > >../src/vtext/VTCaret.m3:149
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3f9c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3f9c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 16 (process 96727 thread = > >0x435b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1df30c8, = > >M3_AYIbX3_m=3D0x1e3bb94, M3_Bl0jv4_c=3D0x1e3bbb0, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3bb94, = > >M3_Bl0jv4_c=3D0x1e3bbb0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x007baaa1 = > >in ZeusPanel__PanelThread (M3_CvdnuP_pc=3D0x1df30b8) at = > >../src/ZeusPanel.m3:1425
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c39830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c39830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 15 (process 96727 thread = > >0x420b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d67e68, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1d22688, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1d22688) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ee3b00) at = > >../src/trestle/Trestle.m3:884
#6  0x007a98b1 in = > >View__WaiterThread (M3_C7vPGX_waiter=3D0x1d67e5c) at = > >../src/View.m3:74
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c305c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c305c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 14 (process 96727 thread = > >0x4103):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ee32e4, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1edf3c4, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1edf3c4) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1edf25c) at = > >../src/trestle/Trestle.m3:884
#6  0x007a98b1 in = > >View__WaiterThread (M3_C7vPGX_waiter=3D0x1ee32d8) at = > >../src/View.m3:74
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38bf0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38bf0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 13 (process 96727 thread = > >0x4003):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1edb2e4, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1ed532c, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1ed532c) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ed3060) at = > >../src/trestle/Trestle.m3:884
#6  0x007a98b1 in = > >View__WaiterThread (M3_C7vPGX_waiter=3D0x1edb2d8) at = > >../src/View.m3:74
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38780) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38780) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 12 (process 96727 thread = > >0x2e03):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed52a4, = > >M3_AYIbX3_m=3D0x1ed327c, M3_Bl0jv4_c=3D0x1ed35f4, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c, = > >M3_Bl0jv4_c=3D0x1ed35f4) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00bb7962 = > >in XMessenger__Messenger (M3_EVlqQO_self=3D0x1ed5294) at = > >../src/xvbt/XMessenger.m3:69
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38420) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38420) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 11 (process 96727 thread = > >0x2b07):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed5254, = > >M3_AYIbX3_m=3D0x1ed327c, M3_Bl0jv4_c=3D0x1ed3614, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c, = > >M3_Bl0jv4_c=3D0x1ed3614) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00bbdbc2 = > >in XInput__FilterXInput (M3_DSd60P_self=3D0x1ed5244) at = > >../src/xvbt/XInput.m3:102
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38320) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38320) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 10 (process 96727 thread = > >0x2a23):
#0  0x963916fa in select$DARWIN_EXTSN = > >()
#1  0x01023503 in Unix__select (nfds=3D7, = > >readfds=3D0x2813d54, writefds=3D0x2813d64, exceptfds=3D0x2813d74, = > >timeout=3D0x0) at ../src/unix/Common/UnixC.c:301
#2 = > > 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 = > >(M3_Cwb5VA_nfd=3D<unknown type>, M3_A4bqCj_timeout=3D0x0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:787
#3  0x010206cc = > >in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1ed5204, = > >M3_Cwb5VA_fd=3D<unknown type>, M3_AicXUJ_read=3D1 '\001', = > >M3_CtKayy_interval=3D-1, M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:826
#4  0x010201b4 = > >in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3D<unknown type>, = > >M3_AicXUJ_read=3D1 '\001', M3_CtKayy_timeoutInterval=3D-1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:729
#5  0x00bbf20b = > >in XInput__WaitForXInput (M3_Bkyxhg_self=3D0x1ed51f4) at = > >../src/xvbt/XInput.m3:63
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38250) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38250) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 9 (process 96727 thread = > >0x29f3):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e3fafc, = > >M3_AYIbX3_m=3D0x1e3f9bc, M3_Bl0jv4_c=3D0x1e3f9c8, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3f9bc, = > >M3_Bl0jv4_c=3D0x1e3f9c8) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x007ab312 = > >in Zeus__AlgToViews (M3_CQpoHd_zeus=3D0x1e3ccfc, = > >M3_Ao6Rbg_initiator=3D0x1ecd9cc, M3_BMhQCx_dispatchProc=3D0x150e0, = > >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:306
#6 = > > 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D0x1ecd9cc, = > >M3_DsvzJ6_style=3D0 '\0', M3_AcxOUs_priority=3D1, = > >M3_Bd56fi_eventName=3D0x1d9d60, M3_BMhQCx_dispatchProc=3D0x150e0, = > >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:246
#7 = > > 0x000149a7 in BresenhamIE__ShowPixel = > >(M3_CfiRBL_initiator=3D0x1ecd9cc, M3_AcxOUs_x=3D3, M3_AcxOUs_y=3D2, = > >M3_AcxOUs_p1=3D6, M3_AcxOUs_p2=3D-2) at = > >../I386_DARWIN/BresenhamIE.m3:227
#8  0x000175b7 in = > >AlgBresenham__DrawLine (M3_ECecEc_alg=3D0x1ecd9cc, M3_AcxOUs_x1=3D0, = > >M3_AcxOUs_y1=3D0, M3_AcxOUs_x2=3D10, M3_AcxOUs_y2=3D6) at = > >../src/bresenham/AlgBresenham.m3:55
#9  0x0001788f in = > >AlgBresenham__Run (M3_ECecEc_alg=3D0x1ecd9cc) at = > >../src/bresenham/AlgBresenham.m3:86
#10 0x007bb729 in = > >ZeusPanel__AlgThread (M3_Dijbki_ac=3D0x1e3fae8) at = > >../src/ZeusPanel.m3:1534
#11 0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29fd0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c29fd0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >_pthread_start ()
#14 0x96373012 in thread_start = > >()

Thread 8 (process 96727 thread = > >0x2803):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d8e01c, = > >M3_AYIbX3_m=3D0x1d71fdc, M3_Bl0jv4_c=3D0x1d71fe8, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d71fdc, = > >M3_Bl0jv4_c=3D0x1d71fe8) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x00e3bdf2 = > >in Formatter__Allocate (M3_ACp9GL_t=3D0x1d71680, M3_DBiloZ_this=3D1 = > >'\001', M3_Cwb5VA_minSize=3D<unknown type>) at = > >../src/formatter/Formatter.m3:440
#6  0x00e3bf0a in = > >Formatter__Probe (M3_ACp9GL_t=3D0x1d71680, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:542
#7 = > > 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d71680, = > >M3_Cwb5VA_i=3D<unknown type>) at = > >../src/formatter/Formatter.m3:592
#8  0x00e3c2ff in = > >Formatter__PeekOp (M3_ACp9GL_t=3D0x1d71680, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:577
#9 = > > 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d71680, = > >M3_DOUxXw_mode=3D1 '\001', M3_ElBLGV_pos=3D0xb038ce90, = > >M3_Cwb5VA_maxL=3D<unknown type>, M3_CCuODf_op=3D0x1d72c08) at = > >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in = > >Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d8e00c) at = > >../src/formatter/Formatter.m3:615
#11 0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29140) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c29140) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >_pthread_start ()
#14 0x96373012 in thread_start = > >()

Thread 7 (process 96727 thread = > >0x2703):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d71618, = > >M3_AYIbX3_m=3D0x1d715ec, M3_Bl0jv4_c=3D0x1d715f8, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d715ec, = > >M3_Bl0jv4_c=3D0x1d715f8) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x00e3bdf2 = > >in Formatter__Allocate (M3_ACp9GL_t=3D0x1d70c90, M3_DBiloZ_this=3D1 = > >'\001', M3_Cwb5VA_minSize=3D<unknown type>) at = > >../src/formatter/Formatter.m3:440
#6  0x00e3bf0a in = > >Formatter__Probe (M3_ACp9GL_t=3D0x1d70c90, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:542
#7 = > > 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d70c90, = > >M3_Cwb5VA_i=3D<unknown type>) at = > >../src/formatter/Formatter.m3:592
#8  0x00e3c2ff in = > >Formatter__PeekOp (M3_ACp9GL_t=3D0x1d70c90, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:577
#9 = > > 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d70c90, = > >M3_DOUxXw_mode=3D1 '\001', M3_ElBLGV_pos=3D0xb030ae90, = > >M3_Cwb5VA_maxL=3D<unknown type>, M3_CCuODf_op=3D0x1d72c08) at = > >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in = > >Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d71608) at = > >../src/formatter/Formatter.m3:615
#11 0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c221e0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c221e0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >_pthread_start ()
#14 0x96373012 in thread_start = > >()

Thread 6 (process 96727 thread = > >0x2603):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d729bc, = > >M3_AYIbX3_m=3D0x1d728b4, M3_Bl0jv4_c=3D0x1d729a0, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d728b4, = > >M3_Bl0jv4_c=3D0x1d729a0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x0073de32 = > >in WorkerPool__ClericApply (M3_BSwVRC_self=3D0x1d729b0) at = > >../src/WorkerPool.m3:152
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28e10) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c28e10) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 5 (process 96727 thread = > >0x2313):
#0  0x963916fa in select$DARWIN_EXTSN = > >()
#1  0x01023503 in Unix__select (nfds=3D4, = > >readfds=3D0x1d74014, writefds=3D0x1d74024, exceptfds=3D0x1d74034, = > >timeout=3D0xb0206b20) at ../src/unix/Common/UnixC.c:301
#2 = > > 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 = > >(M3_Cwb5VA_nfd=3D<unknown type>, M3_A4bqCj_timeout=3D0xb0206b20) = > >at ../src/thread/PTHREAD/ThreadPThread.m3:787
#3 = > > 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1d585bc, = > >M3_Cwb5VA_fd=3D<unknown type>, M3_AicXUJ_read=3D1 '\001', = > >M3_CtKayy_interval=3D1.7976931348623157e+308, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823
#4 = > > 0x010202e7 in SchedulerPosix__IOAlertWait = > >(M3_Cwb5VA_fd=3D<unknown type>, M3_AicXUJ_read=3D1 '\001', = > >M3_CtKayy_timeoutInterval=3D-1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:742
#5  0x00dd3cc2 = > >in TCPMisc__Accept=46rom (M3_AahksS_c=3D0x1d58594, = > >M3_DoBjMZ_peer=3D0xb0206cb4) at ../src/POSIX/TCP.m3:458
#6 = > > 0x00dd3da8 in TCP__Accept (M3_AahksS_c=3D0x1d58594) at = > >../src/POSIX/TCP.m3:234
#7  0x006dbc6b in = > >LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=3D0x1d585b0) at = > >../src/LocalObjectSpace.m3:307
#8  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28d60) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#9  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c28d60) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#10 0x96373155 in = > >_pthread_start ()
#11 0x96373012 in thread_start = > >()

Thread 4 (process 96727 thread = > >0x2003):
#0  0x9634946e in __semwait_signal = > >()
#1  0x963492ef in nanosleep$UNIX2003 ()
#2 = > > 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb0184dd0, = > >rem=3D0xb0184dd8) at = > >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  0x0101fd7c = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1d0ba08, M3_CtKayy_n=3D1, = > >M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  0x0101fef3 = > >in Thread__Pause (M3_CtKayy_n=3D1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  0x00a11d53 = > >in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D0x1d0ba00) at = > >../src/lego/FileBrowserVBT.m3:259
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c21830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 3 (process 96727 thread = > >0x1f03):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d090d4, = > >M3_AYIbX3_m=3D0x1d090b0, M3_Bl0jv4_c=3D0x1d090bc, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d090b0, = > >M3_Bl0jv4_c=3D0x1d090bc) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00a839e2 = > >in VTView__VFontCleanUpThread (M3_EMTrVz_cl=3D0x1d090cc) at = > >../src/vtext/VTView.m3:111
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21310) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c21310) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 2 (process 96727 thread = > >0xd07):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d006c8, = > >M3_AYIbX3_m=3D0x1d00688, M3_Bl0jv4_c=3D0x1d00694, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00688, = > >M3_Bl0jv4_c=3D0x1d00694) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00bf33d2 = > >in VBTRep__MeterMaid (M3_EMTrVz_self=3D0x1d006bc) at = > >../src/vbt/VBTRep.m3:439
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21390) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c21390) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 1 (process 96727 thread = > >0x10b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d0000c, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1df3114, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1df3114) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1e3a204) at = > >../src/trestle/Trestle.m3:884
#6  0x007c09eb in = > >ZeusPanel__Interact (M3_Bd56fi_title=3D0x290db0, = > >M3_DYb95R_path=3D0x1d498c0) at ../src/ZeusPanel.m3:477
#7 = > > 0x001b0ede in Main_M3 (M3_AcxOUs_mode=3D1) at = > >../src/Main.m3:165
#8  0x0100eb1f in = > >RTLinker__RunMainBody (M3_DjPxE3_m=3D0x1d6060) at = > >../src/runtime/common/RTLinker.m3:399
#9  0x00002578 in = > >main (argc=3D1, argv=3D0xbfffedb8, envp=3D0xbfffedc0) at = > >_m3main.mc:6


>class=3D"Apple-style-span" style=3D"font-size: 12px; ">
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = > >-webkit-line-break: after-white-space; "> >style=3D"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; ">
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = > >-webkit-line-break: after-white-space; "> >style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; ">
>class=3D"Apple-style-span" color=3D"#0000FF"> >class=3D"Apple-style-span" face=3D"Gill Sans"> >class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = > >'Gill Sans'; "> >0, 255); font-family: 'Gill Sans'; ">Antony = > >Hosking >face=3D"Gill Sans"> >'Gill Sans'; "> >'Gill Sans'; "> | >class=3D"Apple-converted-space">  >class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; "> >class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; = > >">Associate Professor >style=3D"font-family: 'Gill Sans'; "> >style=3D"font-family: 'Gill Sans'; "> | Computer Science | Purdue = > >University
> face=3D"GillSans-Light"> >style=3D"font-family: GillSans-Light; ">305 N. University Street | West = > >Lafayette | IN 47907 | USA
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"> >class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = > >'Gill Sans'; "> >0, 255); font-family: 'Gill Sans'; ">Office >class=3D"Apple-style-span" face=3D"GillSans-Light"> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; = > >"> +1 765 494 6001 | >class=3D"Apple-converted-space">  >class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"> >class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = > >'Gill Sans'; "> >0, 255); font-family: 'Gill Sans'; ">Mobile >class=3D"Apple-style-span" face=3D"GillSans-Light"> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "> >class=3D"Apple-converted-space"> +1 765 427 = > >5484
>face=3D"GillSans-Light">
>class=3D"khtml-block-placeholder">
>>

>class=3D"Apple-interchange-newline">

>class=3D"Apple-interchange-newline">

On 6 Sep 2009, = > >at 23:18, Jay K wrote:

>class=3D"Apple-interchange-newline">
>type=3D"cite">









[was truncated = > >again!]

PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes = > >runs out of stack

= > > > >--Apple-Mail-13--794937978-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:16:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:16:41 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:50:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:50:08 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:53:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:53:34 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Wow. I've seen it hang for up to 30 seconds, but if I am patient, I can run it many times in a row with no infinite hang. This is with the stack size code removed. Now to try without it, and if it always proceeds after a possibly long wait, well..that's still pretty bad, but... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:50:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 11:00:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 09:00:07 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Hm..setting the stack 1meg never seems to hang now. I'll dig a bit more and try mentor too. Another thing different about Darwin, I should have pointed out, I think, it doesn't optimize by default like the others, meaning it will use more stack than the others. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:53:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Wow. I've seen it hang for up to 30 seconds, but if I am patient, I can run it many times in a row with no infinite hang. This is with the stack size code removed. Now to try without it, and if it always proceeds after a possibly long wait, well..that's still pretty bad, but... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:50:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 11:15:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 09:15:20 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Hm. I take that back. 1meg I might have been running Linux Juno in a nearby terminal. Without the stack code Juno does still often hang. I have seen it also pause a few seconds with one word in the status, then quite a while later advance to another, and then sit there. Usually after a minute I declare failure. But I have seen it progress after counting to 30. Arg this stinks.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 09:00:07 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm..setting the stack 1meg never seems to hang now. I'll dig a bit more and try mentor too. Another thing different about Darwin, I should have pointed out, I think, it doesn't optimize by default like the others, meaning it will use more stack than the others. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:53:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Wow. I've seen it hang for up to 30 seconds, but if I am patient, I can run it many times in a row with no infinite hang. This is with the stack size code removed. Now to try without it, and if it always proceeds after a possibly long wait, well..that's still pretty bad, but... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:50:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 12:07:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 10:07:16 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: > What is different about Darwin? > Well obviously the same world suspend works. Can we use the portable way instead?? sem_init returns ENOSYS on Darwin, so no. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 13:18:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 11:18:59 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <20090908082345.B34371A2079@async.async.caltech.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <20090908074840.EB4811A2079@async.async.caltech.edu> <20090908082345.B34371A2079@async.async.caltech.edu> Message-ID: Thanks. Well, userthreads on I386_DARWIN don't seem to work presently. == package /Users/jay/dev2/cm3/m3-sys/cm3ide == +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in I386_DARWIN --- ignoring ../src/m3overrides /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-/qk *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x464b7 = PushEFrame + 0x63 in ../src/thread/POSIX/ThreadPosix.m3 *** Maybe I'll look into that.. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) > Date: Tue, 8 Sep 2009 01:23:45 -0700 > From: mika at async.async.caltech.edu > > I really meant it as a debugging hint: > > if you deadlock the user threads you get an instant core dump, also lots > of diagnostics to stderr, which will tell you which LOCK or Thread.Acquire > is creating the dependency cycle. > > If you're debugging deadlocks, that's one way to look for them. > That being said I've never seen mentor or Juno hang on FreeBSD4... > > I haven't used the pthreads much (a bit, when porting to Linux and OS > X as well as when testing the new stuff on FreeBSD). Is it possible to > get deadlock detection with them? As I recall, it's not automatic the > way it is with the user threads. > > Mika > > Jay K writes: > >--_d2a2b05c-dd99-4149-b3de-8867976ffb79_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Nice thing about pthreads is everyone uses them. > >Whatever tools they have=2C we can use. > > > > ..Jay > > > >> To: hosking at cs.purdue.edu=3B jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other proble= > >ms)=20 > >> Date: Tue=2C 8 Sep 2009 00:48:40 -0700 > >> From: mika at async.async.caltech.edu > >>=20 > >>=20 > >> A nice thing about the user threads system is that it has a beautiful > >> deadlock detector... do you have anything like this in the pthreads > >> environment? > >>=20 > >> Mika > >>=20 > >> Tony Hosking writes: > >> > > >> >--Apple-Mail-13--794937978 > >> >Content-Type: text/plain=3B > >> > charset=3DUS-ASCII=3B > >> > format=3Dflowed=3B > >> > delsp=3Dyes > >> >Content-Transfer-Encoding: 7bit > >> > > >> >Here's the hang backtrace for mentor. Again=2C all appears normal=2C =20 > >> >except that all the threads are paused or waiting=2C which is =20 > >> >suspicious. I'm stumped for now. > >> > > >> >Thread 21 (process 96727 thread 0x7403): > >> >#0 0x9634946e in __semwait_signal () > >> >#1 0x963492ef in nanosleep$UNIX2003 () > >> >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb15d4db0=2C =20 > >> >rem=3D0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >> >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=3D0x1f3f880=2C = > >=20 > >> >M3_CtKayy_n=3D1=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHREA= > >D/=20 > >> >ThreadPThread.m3:668 > >> >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ../src/thread/=20 > >> >PTHREAD/ThreadPThread.m3:685 > >> >#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=3D0x1f3f870) at ../= > >=20 > >> >src/xvbt/XClientF.m3:105 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c441d0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c441d0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 20 (process 96727 thread 0x7103): > >> >#0 ThreadPThread__XTestAlert (M3_BXP32l_self=3D0x1e5c134) at ../src/=20 > >> >thread/PTHREAD/ThreadPThread.m3:319 > >> >#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e5c134=2C = > >=20 > >> >M3_CtKayy_n=3D0.0056863520294427872=2C M3_AicXUJ_alertable=3D1 '\001') a= > >t ../=20 > >> >src/thread/PTHREAD/ThreadPThread.m3:669 > >> >#2 0x01020024 in Thread__AlertPause =20 > >> >(M3_CtKayy_n=3D0.0056863520294427872) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:699 > >> >#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=3D0x1e7e3fc=2C =20 > >> >M3_DsL7Zz_mg=3D0x0=2C M3_AdEaVQ_v=3D0x1e5e0f8=2C M3_BUucNs_duration=3D1)= > > at ../=20 > >> >src/Animate.m3:71 > >> >#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=3D0x1e5e0f8=2C =20 > >> >M3_BUucNs_duration=3D1) at ../src/MGV.m3:313 > >> >#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=3D0x1e5e00c=2C= > > =20 > >> >M3_BUucNs_t0=3D0=2C M3_BUucNs_t1=3D1) at ../src/GraphVBT.m3:656 > >> >#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=3D0x1ed3060=2C =20 > >> >M3_AcxOUs_x=3D3=2C M3_AcxOUs_y=3D2=2C M3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2= > >=3D-2) at ../=20 > >> >src/bresenham/ViewError.m3:548 > >> >#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D0x1ed3060=2C = > >=20 > >> >M3_Af40ku_evt=3D0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > >> >#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c128) at ../=20 > >> >src/Zeus.m3:331 > >> >#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fd80) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#10 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3fd80) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#11 0x96373155 in _pthread_start () > >> >#12 0x96373012 in thread_start () > >> > > >> >Thread 19 (process 96727 thread 0x5d07): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c0bc=2C =20 > >> >M3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1edf34c=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc=2C =20 > >> >M3_Bl0jv4_c=3D0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc=2C = > >=20 > >> >M3_B74vJ1_view=3D0x1edf25c) at ../src/Zeus.m3:361 > >> >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c0b0) at ../=20 > >> >src/Zeus.m3:328 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fc80) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3fc80) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 18 (process 96727 thread 0x700b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c044=2C =20 > >> >M3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1ee3bac=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc=2C =20 > >> >M3_Bl0jv4_c=3D0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc=2C = > >=20 > >> >M3_B74vJ1_view=3D0x1ee3b00) at ../src/Zeus.m3:361 > >> >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c038) at ../=20 > >> >src/Zeus.m3:328 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fa90) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3fa90) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 17 (process 96727 thread 0x6e03): > >> >#0 0x963493dc in _pthread_testcancel () > >> >#1 0x96349275 in nanosleep$UNIX2003 () > >> >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb134add0=2C =20 > >> >rem=3D0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >> >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e54388=2C = > >=20 > >> >M3_CtKayy_n=3D0.5=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHR= > >EAD/=20 > >> >ThreadPThread.m3:668 > >> >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D0.5) at ../src/thread/=20 > >> >PTHREAD/ThreadPThread.m3:685 > >> >#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=3D0x1e5437c) at ../src= > >/=20 > >> >vtext/VTCaret.m3:149 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3f9c0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3f9c0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 16 (process 96727 thread 0x435b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1df30c8=2C =20 > >> >M3_AYIbX3_m=3D0x1e3bb94=2C M3_Bl0jv4_c=3D0x1e3bbb0=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3bb94=2C =20 > >> >M3_Bl0jv4_c=3D0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=3D0x1df30b8) =20 > >> >at ../src/ZeusPanel.m3:1425 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c39830) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c39830) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 15 (process 96727 thread 0x420b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d67e68=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1d22688=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ee3b00) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=3D0x1d67e5c) =20 > >> >at ../src/View.m3:74 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c305c0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c305c0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 14 (process 96727 thread 0x4103): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ee32e4=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1edf3c4=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1edf25c) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=3D0x1ee32d8) =20 > >> >at ../src/View.m3:74 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38bf0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38bf0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 13 (process 96727 thread 0x4003): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1edb2e4=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1ed532c=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ed3060) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=3D0x1edb2d8) =20 > >> >at ../src/View.m3:74 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38780) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38780) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 12 (process 96727 thread 0x2e03): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed52a4=2C =20 > >> >M3_AYIbX3_m=3D0x1ed327c=2C M3_Bl0jv4_c=3D0x1ed35f4=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c=2C =20 > >> >M3_Bl0jv4_c=3D0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=3D0x1ed5294) =20 > >> >at ../src/xvbt/XMessenger.m3:69 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38420) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38420) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 11 (process 96727 thread 0x2b07): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed5254=2C =20 > >> >M3_AYIbX3_m=3D0x1ed327c=2C M3_Bl0jv4_c=3D0x1ed3614=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c=2C =20 > >> >M3_Bl0jv4_c=3D0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=3D0x1ed5244) =20 > >> >at ../src/xvbt/XInput.m3:102 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38320) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38320) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 10 (process 96727 thread 0x2a23): > >> >#0 0x963916fa in select$DARWIN_EXTSN () > >> >#1 0x01023503 in Unix__select (nfds=3D7=2C readfds=3D0x2813d54=2C =20 > >> >writefds=3D0x2813d64=2C exceptfds=3D0x2813d74=2C timeout=3D0x0) at ../sr= > >c/unix/=20 > >> >Common/UnixC.c:301 > >> >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =20 > >> >(M3_Cwb5VA_nfd=3D=2C M3_A4bqCj_timeout=3D0x0) at ../src/th= > >read/=20 > >> >PTHREAD/ThreadPThread.m3:787 > >> >#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1ed5204=2C = > >=20 > >> >M3_Cwb5VA_fd=3D=2C M3_AicXUJ_read=3D1 '\001'=2C =20 > >> >M3_CtKayy_interval=3D-1=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/threa= > >d/=20 > >> >PTHREAD/ThreadPThread.m3:826 > >> >#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3D= > >=2C =20 > >> >M3_AicXUJ_read=3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D-1) at ../src/= > >=20 > >> >thread/PTHREAD/ThreadPThread.m3:729 > >> >#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=3D0x1ed51f4) =20 > >> >at ../src/xvbt/XInput.m3:63 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38250) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38250) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 9 (process 96727 thread 0x29f3): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e3fafc=2C =20 > >> >M3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1e3f9c8=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3f9bc=2C =20 > >> >M3_Bl0jv4_c=3D0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=3D0x1e3ccfc=2C =20 > >> >M3_Ao6Rbg_initiator=3D0x1ecd9cc=2C M3_BMhQCx_dispatchProc=3D0x150e0=2C = > >=20 > >> >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:306 > >> >#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D0x1ecd9cc=2C =20 > >> >M3_DsvzJ6_style=3D0 '\0'=2C M3_AcxOUs_priority=3D1=2C =20 > >> >M3_Bd56fi_eventName=3D0x1d9d60=2C M3_BMhQCx_dispatchProc=3D0x150e0=2C =20 > >> >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:246 > >> >#7 0x000149a7 in BresenhamIE__ShowPixel =20 > >> >(M3_CfiRBL_initiator=3D0x1ecd9cc=2C M3_AcxOUs_x=3D3=2C M3_AcxOUs_y=3D2= > >=2C =20 > >> >M3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2=3D-2) at ../I386_DARWIN/BresenhamIE.m3:= > >227 > >> >#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=3D0x1ecd9cc=2C = > >=20 > >> >M3_AcxOUs_x1=3D0=2C M3_AcxOUs_y1=3D0=2C M3_AcxOUs_x2=3D10=2C M3_AcxOUs_y= > >2=3D6) at ../=20 > >> >src/bresenham/AlgBresenham.m3:55 > >> >#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=3D0x1ecd9cc) at ../=20 > >> >src/bresenham/AlgBresenham.m3:86 > >> >#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=3D0x1e3fae8) at ../= > >=20 > >> >src/ZeusPanel.m3:1534 > >> >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29fd0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#12 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c29fd0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#13 0x96373155 in _pthread_start () > >> >#14 0x96373012 in thread_start () > >> > > >> >Thread 8 (process 96727 thread 0x2803): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d8e01c=2C =20 > >> >M3_AYIbX3_m=3D0x1d71fdc=2C M3_Bl0jv4_c=3D0x1d71fe8=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d71fdc=2C =20 > >> >M3_Bl0jv4_c=3D0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_DBiloZ_this=3D1 '\001'=2C M3_Cwb5VA_minSize=3D) at ../s= > >rc/=20 > >> >formatter/Formatter.m3:440 > >> >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:542 > >> >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:592 > >> >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:577 > >> >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_DOUxXw_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb038ce90=2C =20 > >> >M3_Cwb5VA_maxL=3D=2C M3_CCuODf_op=3D0x1d72c08) at ../src/= > >=20 > >> >formatter/Formatter.m3:708 > >> >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d8e00c) at ..= > >/=20 > >> >src/formatter/Formatter.m3:615 > >> >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29140) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#12 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c29140) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#13 0x96373155 in _pthread_start () > >> >#14 0x96373012 in thread_start () > >> > > >> >Thread 7 (process 96727 thread 0x2703): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d71618=2C =20 > >> >M3_AYIbX3_m=3D0x1d715ec=2C M3_Bl0jv4_c=3D0x1d715f8=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d715ec=2C =20 > >> >M3_Bl0jv4_c=3D0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_DBiloZ_this=3D1 '\001'=2C M3_Cwb5VA_minSize=3D) at ../s= > >rc/=20 > >> >formatter/Formatter.m3:440 > >> >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:542 > >> >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:592 > >> >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:577 > >> >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_DOUxXw_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb030ae90=2C =20 > >> >M3_Cwb5VA_maxL=3D=2C M3_CCuODf_op=3D0x1d72c08) at ../src/= > >=20 > >> >formatter/Formatter.m3:708 > >> >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d71608) at ..= > >/=20 > >> >src/formatter/Formatter.m3:615 > >> >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c221e0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#12 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c221e0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#13 0x96373155 in _pthread_start () > >> >#14 0x96373012 in thread_start () > >> > > >> >Thread 6 (process 96727 thread 0x2603): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d729bc=2C =20 > >> >M3_AYIbX3_m=3D0x1d728b4=2C M3_Bl0jv4_c=3D0x1d729a0=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d728b4=2C =20 > >> >M3_Bl0jv4_c=3D0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=3D0x1d729b0) = > >=20 > >> >at ../src/WorkerPool.m3:152 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28e10) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c28e10) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 5 (process 96727 thread 0x2313): > >> >#0 0x963916fa in select$DARWIN_EXTSN () > >> >#1 0x01023503 in Unix__select (nfds=3D4=2C readfds=3D0x1d74014=2C =20 > >> >writefds=3D0x1d74024=2C exceptfds=3D0x1d74034=2C timeout=3D0xb0206b20) a= > >t ../src/=20 > >> >unix/Common/UnixC.c:301 > >> >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =20 > >> >(M3_Cwb5VA_nfd=3D=2C M3_A4bqCj_timeout=3D0xb0206b20) at ..= > >/src/=20 > >> >thread/PTHREAD/ThreadPThread.m3:787 > >> >#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1d585bc=2C = > >=20 > >> >M3_Cwb5VA_fd=3D=2C M3_AicXUJ_read=3D1 '\001'=2C =20 > >> >M3_CtKayy_interval=3D1.7976931348623157e+308=2C M3_AicXUJ_alertable=3D1 = > >=20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > >> >#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3D >=20 > >> >type>=2C M3_AicXUJ_read=3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D-1) at= > > ../=20 > >> >src/thread/PTHREAD/ThreadPThread.m3:742 > >> >#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=3D0x1d58594=2C =20 > >> >M3_DoBjMZ_peer=3D0xb0206cb4) at ../src/POSIX/TCP.m3:458 > >> >#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=3D0x1d58594) at ../src/POSIX/= > >=20 > >> >TCP.m3:234 > >> >#7 0x006dbc6b in LocalObjectSpace__SpaceAccept =20 > >> >(M3_Dbz8GV_self=3D0x1d585b0) at ../src/LocalObjectSpace.m3:307 > >> >#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28d60) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#9 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c28d60) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#10 0x96373155 in _pthread_start () > >> >#11 0x96373012 in thread_start () > >> > > >> >Thread 4 (process 96727 thread 0x2003): > >> >#0 0x9634946e in __semwait_signal () > >> >#1 0x963492ef in nanosleep$UNIX2003 () > >> >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb0184dd0=2C =20 > >> >rem=3D0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >> >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=3D0x1d0ba08=2C = > >=20 > >> >M3_CtKayy_n=3D1=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHREA= > >D/=20 > >> >ThreadPThread.m3:668 > >> >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ../src/thread/=20 > >> >PTHREAD/ThreadPThread.m3:685 > >> >#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D0x1d0ba00) =20 > >> >at ../src/lego/FileBrowserVBT.m3:259 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21830) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c21830) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 3 (process 96727 thread 0x1f03): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d090d4=2C =20 > >> >M3_AYIbX3_m=3D0x1d090b0=2C M3_Bl0jv4_c=3D0x1d090bc=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d090b0=2C =20 > >> >M3_Bl0jv4_c=3D0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=3D0x1d090cc) = > >=20 > >> >at ../src/vtext/VTView.m3:111 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21310) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c21310) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 2 (process 96727 thread 0xd07): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d006c8=2C =20 > >> >M3_AYIbX3_m=3D0x1d00688=2C M3_Bl0jv4_c=3D0x1d00694=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00688=2C =20 > >> >M3_Bl0jv4_c=3D0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=3D0x1d006bc) at ../= > >=20 > >> >src/vbt/VBTRep.m3:439 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21390) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c21390) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 1 (process 96727 thread 0x10b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d0000c=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1df3114=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1e3a204) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=3D0x290db0=2C =20 > >> >M3_DYb95R_path=3D0x1d498c0) at ../src/ZeusPanel.m3:477 > >> >#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=3D1) at ../src/Main.m3:165 > >> >#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=3D0x1d6060) at ../= > >=20 > >> >src/runtime/common/RTLinker.m3:399 > >> >#9 0x00002578 in main (argc=3D1=2C argv=3D0xbfffedb8=2C envp=3D0xbfffed= > >c0) at =20 > >> >_m3main.mc:6 > >> > > >> > > >> >Antony Hosking | Associate Professor | Computer Science | Purdue =20 > >> >University > >> >305 N. University Street | West Lafayette | IN 47907 | USA > >> >Office +1 765 494 6001 | Mobile +1 765 427 5484 > >> > > >> > > >> > > >> > > >> >On 6 Sep 2009=2C at 23:18=2C Jay K wrote: > >> > > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> [was truncated again!] > >> >> > >> >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes runs out of = > >=20 > >> >> stack > >> > > >> > > >> >--Apple-Mail-13--794937978 > >> >Content-Type: text/html=3B > >> > charset=3DUS-ASCII > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > >=3B =3D > >> >-webkit-line-break: after-white-space=3B ">Here's the hang backtrace for= > > =3D > >> >mentor.  =3BAgain=2C all appears normal=2C except that all the threa= > >ds are =3D > >> >paused or waiting=2C which is suspicious.  =3BI'm stumped for =3D > >> >now.

Thread 21 (process 96727 thread =3D > >> >0x7403):
#0  =3B0x9634946e in __semwait_signal =3D > >> >()
#1  =3B0x963492ef in nanosleep$UNIX2003 ()
#2= > > =3D > >> > =3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb15d4db0=2C = > >=3D > >> >rem=3D3D0xb15d4db8) at =3D > >> >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  =3B0x0101fd= > >7c =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1f3f880=2C M3_CtKayy_n=3D= > >3D1=2C =3D > >> >M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  =3B0x0101fe= > >f3 =3D > >> >in Thread__Pause (M3_CtKayy_n=3D3D1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  =3B0x00bc9c= > >f4 =3D > >> >in XClientF__MeterMaid (M3_AS2y1X_cl=3D3D0x1f3f870) at =3D > >> >../src/xvbt/XClientF.m3:105
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c441d0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c441d0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 20 (process 96727 thread =3D > >> >0x7103):
#0  =3BThreadPThread__XTestAlert =3D > >> >(M3_BXP32l_self=3D3D0x1e5c134) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:319
#1  =3B0x0101fd= > >9b =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1e5c134=2C =3D > >> >M3_CtKayy_n=3D3D0.0056863520294427872=2C M3_AicXUJ_alertable=3D3D1 '\001= > >') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:669
#2  =3B0x010200= > >24 =3D > >> >in Thread__AlertPause (M3_CtKayy_n=3D3D0.0056863520294427872) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:699
#3  =3B0x008f9e= > >a1 =3D > >> >in Animate__Do (M3_CCfZY3_t=3D3D0x1e7e3fc=2C M3_DsL7Zz_mg=3D3D0x0=2C =3D > >> >M3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_duration=3D3D1) at =3D > >> >../src/Animate.m3:71
#4  =3B0x00909610 in MGV__Animation = > >=3D > >> >(M3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_duration=3D3D1) at =3D > >> >../src/MGV.m3:313
#5  =3B0x008921f9 in =3D > >> >GraphVBT__AnimateGraph (M3_Cj00zi_graph=3D3D0x1e5e00c=2C M3_BUucNs_t0=3D= > >3D0=2C =3D > >> >M3_BUucNs_t1=3D3D1) at ../src/GraphVBT.m3:656
#6 =3D > >> > =3B0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=3D3D0x1ed3060= > >=2C =3D > >> >M3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y=3D3D2=2C M3_AcxOUs_p1=3D3D6=2C M3_AcxOU= > >s_p2=3D3D-2) =3D > >> >at ../src/bresenham/ViewError.m3:548
#7  =3B0x0001529a in = > >=3D > >> >BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D3D0x1ed3060=2C =3D > >> >M3_Af40ku_evt=3D3D0x1e08014) at =3D > >> >../I386_DARWIN/BresenhamIE.m3:101
#8  =3B0x007abb9b in =3D > >> >Zeus__ViewThread (M3_BH3Tll_self=3D3D0x1e5c128) at =3D > >> >../src/Zeus.m3:331
#9  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fd80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#10 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3fd80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#11 0x96373155 in = > >=3D > >> >_pthread_start ()
#12 0x96373012 in thread_start =3D > >> >()

Thread 19 (process 96727 thread =3D > >> >0x5d07):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e5c0bc=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1edf34c=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1edf34c) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x007ab7= > >f2 =3D > >> >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D > >> >M3_B74vJ1_view=3D3D0x1edf25c) at ../src/Zeus.m3:361
#6 =3D > >> > =3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D3D0x1e5c0b0) at= > > =3D > >> >../src/Zeus.m3:328
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fc80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3fc80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 18 (process 96727 thread =3D > >> >0x700b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e5c044=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1ee3bac=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1ee3bac) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x007ab7= > >f2 =3D > >> >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D > >> >M3_B74vJ1_view=3D3D0x1ee3b00) at ../src/Zeus.m3:361
#6 =3D > >> > =3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D3D0x1e5c038) at= > > =3D > >> >../src/Zeus.m3:328
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fa90) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3fa90) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 17 (process 96727 thread =3D > >> >0x6e03):
#0  =3B0x963493dc in _pthread_testcancel =3D > >> >()
#1  =3B0x96349275 in nanosleep$UNIX2003 ()
#2= > > =3D > >> > =3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb134add0=2C = > >=3D > >> >rem=3D3D0xb134add8) at =3D > >> >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  =3B0x0101fd= > >7c =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1e54388=2C M3_CtKayy_n=3D= > >3D0.5=2C =3D > >> >M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  =3B0x0101fe= > >f3 =3D > >> >in Thread__Pause (M3_CtKayy_n=3D3D0.5) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  =3B0x00a6f0= > >c0 =3D > >> >in VTCaret__Blinker (M3_Axogco_arg=3D3D0x1e5437c) at =3D > >> >../src/vtext/VTCaret.m3:149
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3f9c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3f9c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 16 (process 96727 thread =3D > >> >0x435b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1df30c8=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3bb94=2C M3_Bl0jv4_c=3D3D0x1e3bbb0=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1e3bb94=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1e3bbb0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x007baa= > >a1 =3D > >> >in ZeusPanel__PanelThread (M3_CvdnuP_pc=3D3D0x1df30b8) at =3D > >> >../src/ZeusPanel.m3:1425
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c39830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c39830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 15 (process 96727 thread =3D > >> >0x420b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d67e68=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1d22688=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1d22688) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1ee3b00) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007a98b1 in =3D > >> >View__WaiterThread (M3_C7vPGX_waiter=3D3D0x1d67e5c) at =3D > >> >../src/View.m3:74
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c305c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c305c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 14 (process 96727 thread =3D > >> >0x4103):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ee32e4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1edf3c4=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1edf3c4) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1edf25c) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007a98b1 in =3D > >> >View__WaiterThread (M3_C7vPGX_waiter=3D3D0x1ee32d8) at =3D > >> >../src/View.m3:74
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38bf0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38bf0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 13 (process 96727 thread =3D > >> >0x4003):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1edb2e4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1ed532c=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1ed532c) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1ed3060) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007a98b1 in =3D > >> >View__WaiterThread (M3_C7vPGX_waiter=3D3D0x1edb2d8) at =3D > >> >../src/View.m3:74
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38780) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38780) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 12 (process 96727 thread =3D > >> >0x2e03):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed52a4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed35f4=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed327c=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1ed35f4) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00bb79= > >62 =3D > >> >in XMessenger__Messenger (M3_EVlqQO_self=3D3D0x1ed5294) at =3D > >> >../src/xvbt/XMessenger.m3:69
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38420) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38420) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 11 (process 96727 thread =3D > >> >0x2b07):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed5254=2C =3D > >> >M3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed3614=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed327c=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1ed3614) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00bbdb= > >c2 =3D > >> >in XInput__FilterXInput (M3_DSd60P_self=3D3D0x1ed5244) at =3D > >> >../src/xvbt/XInput.m3:102
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38320) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38320) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 10 (process 96727 thread =3D > >> >0x2a23):
#0  =3B0x963916fa in select$DARWIN_EXTSN =3D > >> >()
#1  =3B0x01023503 in Unix__select (nfds=3D3D7=2C =3D > >> >readfds=3D3D0x2813d54=2C writefds=3D3D0x2813d64=2C exceptfds=3D3D0x2813d= > >74=2C =3D > >> >timeout=3D3D0x0) at ../src/unix/Common/UnixC.c:301
#2 =3D > >> > =3B0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =3D > >> >(M3_Cwb5VA_nfd=3D3D<=3Bunknown type>=3B=2C M3_A4bqCj_timeout=3D3D0x0= > >) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:787
#3  =3B0x010206= > >cc =3D > >> >in ThreadPThread__XIOWait (M3_BXP32l_self=3D3D0x1ed5204=2C =3D > >> >M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C M3_AicXUJ_read=3D3D1 '\001'= > >=2C =3D > >> >M3_CtKayy_interval=3D3D-1=2C M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:826
#4  =3B0x010201= > >b4 =3D > >> >in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C = > >=3D > >> >M3_AicXUJ_read=3D3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D3D-1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:729
#5  =3B0x00bbf2= > >0b =3D > >> >in XInput__WaitForXInput (M3_Bkyxhg_self=3D3D0x1ed51f4) at =3D > >> >../src/xvbt/XInput.m3:63
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38250) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38250) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 9 (process 96727 thread =3D > >> >0x29f3):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e3fafc=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1e3f9c8=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1e3f9c8) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x007ab3= > >12 =3D > >> >in Zeus__AlgToViews (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D > >> >M3_Ao6Rbg_initiator=3D3D0x1ecd9cc=2C M3_BMhQCx_dispatchProc=3D3D0x150e0= > >=2C =3D > >> >M3_Af40ku_evtArgs=3D3D0x1e08014) at ../src/Zeus.m3:306
#6 =3D > >> > =3B0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D3D0x1ecd9cc= > >=2C =3D > >> >M3_DsvzJ6_style=3D3D0 '\0'=2C M3_AcxOUs_priority=3D3D1=2C =3D > >> >M3_Bd56fi_eventName=3D3D0x1d9d60=2C M3_BMhQCx_dispatchProc=3D3D0x150e0= > >=2C =3D > >> >M3_Af40ku_evtArgs=3D3D0x1e08014) at ../src/Zeus.m3:246
#7 =3D > >> > =3B0x000149a7 in BresenhamIE__ShowPixel =3D > >> >(M3_CfiRBL_initiator=3D3D0x1ecd9cc=2C M3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y= > >=3D3D2=2C =3D > >> >M3_AcxOUs_p1=3D3D6=2C M3_AcxOUs_p2=3D3D-2) at =3D > >> >../I386_DARWIN/BresenhamIE.m3:227
#8  =3B0x000175b7 in =3D > >> >AlgBresenham__DrawLine (M3_ECecEc_alg=3D3D0x1ecd9cc=2C M3_AcxOUs_x1=3D3D= > >0=2C =3D > >> >M3_AcxOUs_y1=3D3D0=2C M3_AcxOUs_x2=3D3D10=2C M3_AcxOUs_y2=3D3D6) at =3D > >> >../src/bresenham/AlgBresenham.m3:55
#9  =3B0x0001788f in = > >=3D > >> >AlgBresenham__Run (M3_ECecEc_alg=3D3D0x1ecd9cc) at =3D > >> >../src/bresenham/AlgBresenham.m3:86
#10 0x007bb729 in =3D > >> >ZeusPanel__AlgThread (M3_Dijbki_ac=3D3D0x1e3fae8) at =3D > >> >../src/ZeusPanel.m3:1534
#11 0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c29fd0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c29fd0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >=3D > >> >_pthread_start ()
#14 0x96373012 in thread_start =3D > >> >()

Thread 8 (process 96727 thread =3D > >> >0x2803):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d8e01c=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d71fdc=2C M3_Bl0jv4_c=3D3D0x1d71fe8=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1d71fdc=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1d71fe8) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x00e3bd= > >f2 =3D > >> >in Formatter__Allocate (M3_ACp9GL_t=3D3D0x1d71680=2C M3_DBiloZ_this=3D3D= > >1 =3D > >> >'\001'=2C M3_Cwb5VA_minSize=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:440
#6  =3B0x00e3bf0a in =3D > >> >Formatter__Probe (M3_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D<=3Bunk= > >nown =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:542
#7 =3D > >> > =3B0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d71680=2C =3D > >> >M3_Cwb5VA_i=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:592
#8  =3B0x00e3c2ff in =3D > >> >Formatter__PeekOp (M3_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D<=3Bun= > >known =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:577
#9 =3D > >> > =3B0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D3D0x1d71680= > >=2C =3D > >> >M3_DOUxXw_mode=3D3D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb038ce90=2C =3D > >> >M3_Cwb5VA_maxL=3D3D<=3Bunknown type>=3B=2C M3_CCuODf_op=3D3D0x1d72c0= > >8) at =3D > >> >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in =3D > >> >Formatter__PrintTop (M3_B5Nhtj_self=3D3D0x1d8e00c) at =3D > >> >../src/formatter/Formatter.m3:615
#11 0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c29140) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c29140) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >=3D > >> >_pthread_start ()
#14 0x96373012 in thread_start =3D > >> >()

Thread 7 (process 96727 thread =3D > >> >0x2703):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d71618=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d715ec=2C M3_Bl0jv4_c=3D3D0x1d715f8=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1d715ec=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1d715f8) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x00e3bd= > >f2 =3D > >> >in Formatter__Allocate (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_DBiloZ_this=3D3D= > >1 =3D > >> >'\001'=2C M3_Cwb5VA_minSize=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:440
#6  =3B0x00e3bf0a in =3D > >> >Formatter__Probe (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D<=3Bunk= > >nown =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:542
#7 =3D > >> > =3B0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d70c90=2C =3D > >> >M3_Cwb5VA_i=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:592
#8  =3B0x00e3c2ff in =3D > >> >Formatter__PeekOp (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D<=3Bun= > >known =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:577
#9 =3D > >> > =3B0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D3D0x1d70c90= > >=2C =3D > >> >M3_DOUxXw_mode=3D3D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb030ae90=2C =3D > >> >M3_Cwb5VA_maxL=3D3D<=3Bunknown type>=3B=2C M3_CCuODf_op=3D3D0x1d72c0= > >8) at =3D > >> >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in =3D > >> >Formatter__PrintTop (M3_B5Nhtj_self=3D3D0x1d71608) at =3D > >> >../src/formatter/Formatter.m3:615
#11 0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c221e0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c221e0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >=3D > >> >_pthread_start ()
#14 0x96373012 in thread_start =3D > >> >()

Thread 6 (process 96727 thread =3D > >> >0x2603):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d729bc=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d728b4=2C M3_Bl0jv4_c=3D3D0x1d729a0=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1d728b4=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1d729a0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x0073de= > >32 =3D > >> >in WorkerPool__ClericApply (M3_BSwVRC_self=3D3D0x1d729b0) at =3D > >> >../src/WorkerPool.m3:152
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c28e10) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c28e10) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 5 (process 96727 thread =3D > >> >0x2313):
#0  =3B0x963916fa in select$DARWIN_EXTSN =3D > >> >()
#1  =3B0x01023503 in Unix__select (nfds=3D3D4=2C =3D > >> >readfds=3D3D0x1d74014=2C writefds=3D3D0x1d74024=2C exceptfds=3D3D0x1d740= > >34=2C =3D > >> >timeout=3D3D0xb0206b20) at ../src/unix/Common/UnixC.c:301
#2 = > >=3D > >> > =3B0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =3D > >> >(M3_Cwb5VA_nfd=3D3D<=3Bunknown type>=3B=2C M3_A4bqCj_timeout=3D3D0xb= > >0206b20) =3D > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:787
#3 =3D > >> > =3B0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=3D3D0x1d585= > >bc=2C =3D > >> >M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C M3_AicXUJ_read=3D3D1 '\001'= > >=2C =3D > >> >M3_CtKayy_interval=3D3D1.7976931348623157e+308=2C M3_AicXUJ_alertable=3D= > >3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823
#4 =3D > >> > =3B0x010202e7 in SchedulerPosix__IOAlertWait =3D > >> >(M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C M3_AicXUJ_read=3D3D1 '\001= > >'=2C =3D > >> >M3_CtKayy_timeoutInterval=3D3D-1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:742
#5  =3B0x00dd3c= > >c2 =3D > >> >in TCPMisc__Accept=3D46rom (M3_AahksS_c=3D3D0x1d58594=2C =3D > >> >M3_DoBjMZ_peer=3D3D0xb0206cb4) at ../src/POSIX/TCP.m3:458
#6 = > >=3D > >> > =3B0x00dd3da8 in TCP__Accept (M3_AahksS_c=3D3D0x1d58594) at =3D > >> >../src/POSIX/TCP.m3:234
#7  =3B0x006dbc6b in =3D > >> >LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=3D3D0x1d585b0) at =3D > >> >../src/LocalObjectSpace.m3:307
#8  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c28d60) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#9  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c28d60) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#10 0x96373155 in = > >=3D > >> >_pthread_start ()
#11 0x96373012 in thread_start =3D > >> >()

Thread 4 (process 96727 thread =3D > >> >0x2003):
#0  =3B0x9634946e in __semwait_signal =3D > >> >()
#1  =3B0x963492ef in nanosleep$UNIX2003 ()
#2= > > =3D > >> > =3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb0184dd0=2C = > >=3D > >> >rem=3D3D0xb0184dd8) at =3D > >> >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  =3B0x0101fd= > >7c =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1d0ba08=2C M3_CtKayy_n=3D= > >3D1=2C =3D > >> >M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  =3B0x0101fe= > >f3 =3D > >> >in Thread__Pause (M3_CtKayy_n=3D3D1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  =3B0x00a11d= > >53 =3D > >> >in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D3D0x1d0ba00) at =3D > >> >../src/lego/FileBrowserVBT.m3:259
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 3 (process 96727 thread =3D > >> >0x1f03):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d090d4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d090b0=2C M3_Bl0jv4_c=3D3D0x1d090bc=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d090b0=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1d090bc) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00a839= > >e2 =3D > >> >in VTView__VFontCleanUpThread (M3_EMTrVz_cl=3D3D0x1d090cc) at =3D > >> >../src/vtext/VTView.m3:111
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21310) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21310) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 2 (process 96727 thread =3D > >> >0xd07):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d006c8=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00688=2C M3_Bl0jv4_c=3D3D0x1d00694=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00688=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1d00694) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00bf33= > >d2 =3D > >> >in VBTRep__MeterMaid (M3_EMTrVz_self=3D3D0x1d006bc) at =3D > >> >../src/vbt/VBTRep.m3:439
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21390) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21390) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 1 (process 96727 thread =3D > >> >0x10b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d0000c=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1df3114=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1df3114) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1e3a204) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007c09eb in =3D > >> >ZeusPanel__Interact (M3_Bd56fi_title=3D3D0x290db0=2C =3D > >> >M3_DYb95R_path=3D3D0x1d498c0) at ../src/ZeusPanel.m3:477
#7 = > >=3D > >> > =3B0x001b0ede in Main_M3 (M3_AcxOUs_mode=3D3D1) at =3D > >> >../src/Main.m3:165
#8  =3B0x0100eb1f in =3D > >> >RTLinker__RunMainBody (M3_DjPxE3_m=3D3D0x1d6060) at =3D > >> >../src/runtime/common/RTLinker.m3:399
#9  =3B0x00002578 in= > > =3D > >> >main (argc=3D3D1=2C argv=3D3D0xbfffedb8=2C envp=3D3D0xbfffedc0) at =3D > >> >_m3main.mc:6


>> >class=3D3D"Apple-style-span" style=3D3D"font-size: 12px=3B ">
>> >style=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode: space=3B =3D > >> >-webkit-line-break: after-white-space=3B "> >span" =3D > >> >style=3D3D"border-collapse: separate=3B -webkit-border-horizontal-spacin= > >g: =3D > >> >0px=3B -webkit-border-vertical-spacing: 0px=3B color: rgb(0=2C 0=2C 0)= > >=3B =3D > >> >font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B =3D > >> >font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B= > > =3D > >> >line-height: normal=3B -webkit-text-decorations-in-effect: none=3B =3D > >> >text-indent: 0px=3B -webkit-text-size-adjust: auto=3B text-transform: no= > >ne=3B =3D > >> >orphans: 2=3B white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "= > >>
>> >style=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode: space=3B =3D > >> >-webkit-line-break: after-white-space=3B "> >span" =3D > >> >style=3D3D"border-collapse: separate=3B -webkit-border-horizontal-spacin= > >g: =3D > >> >0px=3B -webkit-border-vertical-spacing: 0px=3B color: rgb(0=2C 0=2C 0)= > >=3B =3D > >> >font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B =3D > >> >font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B= > > =3D > >> >line-height: normal=3B -webkit-text-decorations-in-effect: none=3B =3D > >> >text-indent: 0px=3B -webkit-text-size-adjust: auto=3B text-transform: no= > >ne=3B =3D > >> >orphans: 2=3B white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "= > >> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B ">
>=3D > >> >class=3D3D"Apple-style-span" color=3D3D"#0000FF"> >> >class=3D3D"Apple-style-span" face=3D3D"Gill Sans"> >> >class=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B fon= > >t-family: =3D > >> >'Gill Sans'=3B "> >b(0=2C =3D > > >0=2C 255)=3B font-family: 'Gill Sans'=3B ">Antony =3D > >> >Hosking >=3D > >> >face=3D3D"Gill Sans"> >family: =3D > >> >'Gill Sans'=3B "> >ly: =3D > >> >'Gill Sans'=3B "> =3B= > >| >> >class=3D3D"Apple-converted-space"> =3B >> >class=3D3D"Apple-style-span" style=3D3D"font-family: 'Gill Sans'=3B "> >pan =3D > >> >class=3D3D"Apple-style-span" style=3D3D"font-family: 'Gill Sans'=3B =3D > >> >">Associate Professor >=3D > >> >style=3D3D"font-family: 'Gill Sans'=3B "> >an" =3D > >> >style=3D3D"font-family: 'Gill Sans'=3B "> =3B| Computer Science | Pu= > >rdue =3D > >> >University
>pan"=3D > >> > face=3D3D"GillSans-Light"> >> >style=3D3D"font-family: GillSans-Light=3B ">305 N. University Street | W= > >est =3D > >> >Lafayette | IN 47907 | USA
>> >class=3D3D"Apple-style-span" color=3D3D"#0000FF" face=3D3D"Gill Sans"> >pan =3D > >> >class=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B fon= > >t-family: =3D > >> >'Gill Sans'=3B "> >b(0=2C =3D > >> >0=2C 255)=3B font-family: 'Gill Sans'=3B ">Office >ont =3D > >> >class=3D3D"Apple-style-span" face=3D3D"GillSans-Light"> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B "= > >> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B = > >=3D > >> >"> =3B+1 765 494 6001 | >> >class=3D3D"Apple-converted-space"> =3B >ont =3D > >> >class=3D3D"Apple-style-span" color=3D3D"#0000FF" face=3D3D"Gill Sans"> >pan =3D > >> >class=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B fon= > >t-family: =3D > >> >'Gill Sans'=3B "> >b(0=2C =3D > >> >0=2C 255)=3B font-family: 'Gill Sans'=3B ">Mobile >ont =3D > >> >class=3D3D"Apple-style-span" face=3D3D"GillSans-Light"> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B "= > >> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B "= > >> >> >class=3D3D"Apple-converted-space"> =3B+1 765 427 =3D > >> >5484
>=3D > >> >face=3D3D"GillSans-Light">
>> >class=3D3D"khtml-block-placeholder">
>span=3D > >> >>
>> >class=3D3D"Apple-interchange-newline">
<= > >br =3D > >> >class=3D3D"Apple-interchange-newline">

On 6 Sep 2009= > >=2C =3D > >> >at 23:18=2C Jay K wrote:

>> >class=3D3D"Apple-interchange-newline">
>> >type=3D3D"cite">









[was truncated = > >=3D > >> >again!]

PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes= > > =3D > >> >runs out of stack

=3D > >> > > >> >--Apple-Mail-13--794937978-- > > > >--_d2a2b05c-dd99-4149-b3de-8867976ffb79_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Nice thing about pthreads is everyone uses them.
Whatever tools they hav= > >e=2C we can use.

 =3B ..Jay

>=3B To: hosking at cs.purdue.= > >edu=3B jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com
>=3B = > >Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems= > >)
>=3B Date: Tue=2C 8 Sep 2009 00:48:40 -0700
>=3B From: mika at as= > >ync.async.caltech.edu
>=3B
>=3B
>=3B A nice thing about th= > >e user threads system is that it has a beautiful
>=3B deadlock detecto= > >r... do you have anything like this in the pthreads
>=3B environment?<= > >br>>=3B
>=3B Mika
>=3B
>=3B Tony Hosking writes:
= > >>=3B >=3B
>=3B >=3B--Apple-Mail-13--794937978
>=3B >=3BCo= > >ntent-Type: text/plain=3B
>=3B >=3B charset=3DUS-ASCII=3B
>=3B > > = > >>=3B format=3Dflowed=3B
>=3B >=3B delsp=3Dyes
>=3B >=3BCon > >t= > >ent-Transfer-Encoding: 7bit
>=3B >=3B
>=3B >=3BHere's the han= > >g backtrace for mentor. Again=2C all appears normal=2C
>=3B >=3Be= > >xcept that all the threads are paused or waiting=2C which is
>=3B &g= > >t=3Bsuspicious. I'm stumped for now.
>=3B >=3B
>=3B >=3BThre= > >ad 21 (process 96727 thread 0x7403):
>=3B >=3B#0 0x9634946e in __se= > >mwait_signal ()
>=3B >=3B#1 0x963492ef in nanosleep$UNIX2003 ()
= > >>=3B >=3B#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb15d4db0= > >=2C
>=3B >=3Brem=3D0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThr= > >eadC.c:318
>=3B >=3B#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP3= > >2l_self=3D0x1f3f880=2C
>=3B >=3BM3_CtKayy_n=3D1=2C M3_AicXUJ_alert= > >able=3D0 '\0') at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:= > >668
>=3B >=3B#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ..= > >/src/thread/
>=3B >=3BPTHREAD/ThreadPThread.m3:685
>=3B >=3B= > >#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=3D0x1f3f870) at ../ >>>=3B >=3Bsrc/xvbt/XClientF.m3:105
>=3B >=3B#6 0x0101f243 in Th= > >readPThread__RunThread (M3_BeUkBA_me=3D0x1c441d0)
>=3B >=3Bat ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x0101ef74 in Th= > >readPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c441d0) at = > >../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >= > >=3B#8 0x96373155 in _pthread_start ()
>=3B >=3B#9 0x96373012 in th= > >read_start ()
>=3B >=3B
>=3B >=3BThread 20 (process 96727 thr= > >ead 0x7103):
>=3B >=3B#0 ThreadPThread__XTestAlert (M3_BXP32l_self= > >=3D0x1e5c134) at ../src/
>=3B >=3Bthread/PTHREAD/ThreadPThread.m3:3= > >19
>=3B >=3B#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self= > >=3D0x1e5c134=2C
>=3B >=3BM3_CtKayy_n=3D0.0056863520294427872=2C M3= > >_AicXUJ_alertable=3D1 '\001') at ../
>=3B >=3Bsrc/thread/PTHREAD/Th= > >readPThread.m3:669
>=3B >=3B#2 0x01020024 in Thread__AlertPause >r>>=3B >=3B(M3_CtKayy_n=3D0.0056863520294427872) at ../src/thread/PTHRE= > >AD/
>=3B >=3BThreadPThread.m3:699
>=3B >=3B#3 0x008f9ea1 in= > > Animate__Do (M3_CCfZY3_t=3D0x1e7e3fc=2C
>=3B >=3BM3_DsL7Zz_mg=3D0= > >x0=2C M3_AdEaVQ_v=3D0x1e5e0f8=2C M3_BUucNs_duration=3D1) at ../
>=3B = > >>=3Bsrc/Animate.m3:71
>=3B >=3B#4 0x00909610 in MGV__Animation (M= > >3_AdEaVQ_v=3D0x1e5e0f8=2C
>=3B >=3BM3_BUucNs_duration=3D1) at ../s= > >rc/MGV.m3:313
>=3B >=3B#5 0x008921f9 in GraphVBT__AnimateGraph (M3_= > >Cj00zi_graph=3D0x1e5e00c=2C
>=3B >=3BM3_BUucNs_t0=3D0=2C M3_BUucNs= > >_t1=3D1) at ../src/GraphVBT.m3:656
>=3B >=3B#6 0x00019be8 in ViewEr= > >ror__ShowPixel (M3_AoJTjZ_view=3D0x1ed3060=2C
>=3B >=3BM3_AcxOUs_x= > >=3D3=2C M3_AcxOUs_y=3D2=2C M3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2=3D-2) at ../ >r>>=3B >=3Bsrc/bresenham/ViewError.m3:548
>=3B >=3B#7 0x0001529= > >a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D0x1ed3060=2C
>=3B >= > >=3BM3_Af40ku_evt=3D0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101
>= > >=3B >=3B#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c128) a= > >t ../
>=3B >=3Bsrc/Zeus.m3:331
>=3B >=3B#9 0x0101f243 in Th= > >readPThread__RunThread (M3_BeUkBA_me=3D0x1c3fd80)
>=3B >=3Bat ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#10 0x0101ef74 in Th= > >readPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c3fd80) at = > >../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >= > >=3B#11 0x96373155 in _pthread_start ()
>=3B >=3B#12 0x96373012 in th= > >read_start ()
>=3B >=3B
>=3B >=3BThread 19 (process 96727 thr= > >ead 0x5d07):
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap (= > >)
>=3B >=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B#= > >2 0x963b9539 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in Thr= > >eadPThread__XWait (M3_BXP32l_self=3D0x1e5c0bc=2C
>=3B >=3BM3_AYIbX= > >3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1edf34c=2C M3_AicXUJ_alertable=3D1
= > >>=3B >=3B'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>= > >=3B >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc=2C = > >
>=3B >=3BM3_Bl0jv4_c=3D0x1edf34c) at ../src/thread/PTHREAD/ThreadPT= > >hread.m3:266
>=3B >=3B#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_C= > >QpoHd_zeus=3D0x1e3ccfc=2C
>=3B >=3BM3_B74vJ1_view=3D0x1edf25c) at = > >../src/Zeus.m3:361
>=3B >=3B#6 0x007abaa2 in Zeus__ViewThread (M3_B= > >H3Tll_self=3D0x1e5c0b0) at ../
>=3B >=3Bsrc/Zeus.m3:328
>=3B &= > >gt=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fc80) = > >
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B &= > >gt=3B#8 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWx= > >b1_param=3D0x1c3fc80) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThr= > >ead.m3:522
>=3B >=3B#9 0x96373155 in _pthread_start ()
>=3B &g= > >t=3B#10 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThre= > >ad 18 (process 96727 thread 0x700b):
>=3B >=3B#0 0x963422ce in sema= > >phore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread_cond_w= > >ait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>=3B >= > >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c044=2C <= > >br>>=3B >=3BM3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1ee3bac=2C M3_Ai= > >cXUJ_alertable=3D1
>=3B >=3B'\001') at ../src/thread/PTHREAD/Threa= > >dPThread.m3:226
>=3B >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYI= > >bX3_m=3D0x1e3f9bc=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1ee3bac) at ../src/t= > >hread/PTHREAD/ThreadPThread.m3:266
>=3B >=3B#5 0x007ab7f2 in Zeus__= > >WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc=2C
>=3B >=3BM3_B74vJ1= > >_view=3D0x1ee3b00) at ../src/Zeus.m3:361
>=3B >=3B#6 0x007abaa2 in = > >Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c038) at ../
>=3B >=3Bsrc/Z= > >eus.m3:328
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_B= > >eUkBA_me=3D0x1c3fa90)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThr= > >ead.m3:546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase >>>=3B >=3B(M3_AJWxb1_param=3D0x1c3fa90) at ../src/thread/PTHREAD/
&= > >gt=3B >=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread= > >_start ()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >= > >=3B
>=3B >=3BThread 17 (process 96727 thread 0x6e03):
>=3B >= > >=3B#0 0x963493dc in _pthread_testcancel ()
>=3B >=3B#1 0x96349275 = > >in nanosleep$UNIX2003 ()
>=3B >=3B#2 0x01022cc4 in ThreadPThread__N= > >anosleep (req=3D0xb134add0=2C
>=3B >=3Brem=3D0xb134add8) at ../src= > >/thread/PTHREAD/ThreadPThreadC.c:318
>=3B >=3B#3 0x0101fd7c in Thre= > >adPThread__XPause (M3_BXP32l_self=3D0x1e54388=2C
>=3B >=3BM3_CtKay= > >y_n=3D0.5=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHREAD/
&g= > >t=3B >=3BThreadPThread.m3:668
>=3B >=3B#4 0x0101fef3 in Thread__P= > >ause (M3_CtKayy_n=3D0.5) at ../src/thread/
>=3B >=3BPTHREAD/ThreadP= > >Thread.m3:685
>=3B >=3B#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco= > >_arg=3D0x1e5437c) at ../src/
>=3B >=3Bvtext/VTCaret.m3:149
>= > >=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3f= > >9c0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>= > >=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3= > >_AJWxb1_param=3D0x1c3f9c0) at ../src/thread/PTHREAD/
>=3B >=3BThrea= > >dPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthread_start ()
>= > >=3B >=3B#9 0x96373012 in thread_start ()
>=3B >=3B
>=3B >= > >=3BThread 16 (process 96727 thread 0x435b):
>=3B >=3B#0 0x963422ce = > >in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread= > >_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>= > >=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1df30c= > >8=2C
>=3B >=3BM3_AYIbX3_m=3D0x1e3bb94=2C M3_Bl0jv4_c=3D0x1e3bbb0= > >=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/thread/PTHREA= > >D/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread__Wait (M3_A= > >YIbX3_m=3D0x1e3bb94=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1e3bbb0) at ../src= > >/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x007baaa1 in Zeus= > >Panel__PanelThread (M3_CvdnuP_pc=3D0x1df30b8)
>=3B >=3Bat ../src/Z= > >eusPanel.m3:1425
>=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread= > > (M3_BeUkBA_me=3D0x1c39830)
>=3B >=3Bat ../src/thread/PTHREAD/Thre= > >adPThread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBas= > >e
>=3B >=3B(M3_AJWxb1_param=3D0x1c39830) at ../src/thread/PTHREAD/= > >
>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x96373155 in _p= > >thread_start ()
>=3B >=3B#9 0x96373012 in thread_start ()
>=3B= > > >=3B
>=3B >=3BThread 15 (process 96727 thread 0x420b):
>=3B = > >>=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0= > >x963742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthrea= > >d_cond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_B= > >XP32l_self=3D0x1d67e68=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_B= > >l0jv4_c=3D0x1d22688=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at .= > >./src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in= > > Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0= > >x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 = > > 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ee3b00) at ../
&g= > >t=3B >=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007a98b1 in Vie= > >w__WaiterThread (M3_C7vPGX_waiter=3D0x1d67e5c)
>=3B >=3Bat ../src/= > >View.m3:74
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_B= > >eUkBA_me=3D0x1c305c0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThr= > >ead.m3:546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase >>>=3B >=3B(M3_AJWxb1_param=3D0x1c305c0) at ../src/thread/PTHREAD/
&= > >gt=3B >=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread= > >_start ()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >= > >=3B
>=3B >=3BThread 14 (process 96727 thread 0x4103):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1ee32e4=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_Bl0j= > >v4_c=3D0x1edf3c4=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Th= > >read__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1e= > >df3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x= > >00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1edf25c) at ../
>= > >=3B >=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007a98b1 in View= > >__WaiterThread (M3_C7vPGX_waiter=3D0x1ee32d8)
>=3B >=3Bat ../src/V= > >iew.m3:74
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_Be= > >UkBA_me=3D0x1c38bf0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThre= > >ad.m3:546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase
= > >>=3B >=3B(M3_AJWxb1_param=3D0x1c38bf0) at ../src/thread/PTHREAD/
&g= > >t=3B >=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread_= > >start ()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >=3B= > >
>=3B >=3BThread 13 (process 96727 thread 0x4003):
>=3B >=3B#= > >0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742= > >c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_= > >wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_s= > >elf=3D0x1edb2e4=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c= > >=3D0x1ed532c=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/t= > >hread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread= > >__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1ed532= > >c) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x00c4= > >0602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ed3060) at ../
>=3B &g= > >t=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007a98b1 in View__Wait= > >erThread (M3_C7vPGX_waiter=3D0x1edb2d8)
>=3B >=3Bat ../src/View.m3= > >:74
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_m= > >e=3D0x1c38780)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:= > >546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase
>=3B= > > >=3B(M3_AJWxb1_param=3D0x1c38780) at ../src/thread/PTHREAD/
>=3B &= > >gt=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread_start = > >()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >=3B
&g= > >t=3B >=3BThread 12 (process 96727 thread 0x2e03):
>=3B >=3B#0 0x9= > >63422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in = > >_pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait (= > >)
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D= > >0x1ed52a4=2C
>=3B >=3BM3_AYIbX3_m=3D0x1ed327c=2C M3_Bl0jv4_c=3D0x1= > >ed35f4=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/thread/= > >PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread__Wait= > > (M3_AYIbX3_m=3D0x1ed327c=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1ed35f4) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x00bb7962 i= > >n XMessenger__Messenger (M3_EVlqQO_self=3D0x1ed5294)
>=3B >=3Bat .= > >./src/xvbt/XMessenger.m3:69
>=3B >=3B#6 0x0101f243 in ThreadPThread= > >__RunThread (M3_BeUkBA_me=3D0x1c38420)
>=3B >=3Bat ../src/thread/P= > >THREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread= > >__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c38420) at ../src/thre= > >ad/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x963= > >73155 in _pthread_start ()
>=3B >=3B#9 0x96373012 in thread_start (= > >)
>=3B >=3B
>=3B >=3BThread 11 (process 96727 thread 0x2b07):= > >
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B = > >>=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b953= > >9 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__= > >XWait (M3_BXP32l_self=3D0x1ed5254=2C
>=3B >=3BM3_AYIbX3_m=3D0x1ed3= > >27c=2C M3_Bl0jv4_c=3D0x1ed3614=2C M3_AicXUJ_alertable=3D0
>=3B >= > >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 = > >0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c=2C
>=3B >=3BM3= > >_Bl0jv4_c=3D0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>= > >=3B >=3B#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=3D0x1ed524= > >4)
>=3B >=3Bat ../src/xvbt/XInput.m3:102
>=3B >=3B#6 0x010= > >1f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38320)
>=3B &g= > >t=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x010= > >1ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1= > >c38320) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
= > >>=3B >=3B#8 0x96373155 in _pthread_start ()
>=3B >=3B#9 0x9637= > >3012 in thread_start ()
>=3B >=3B
>=3B >=3BThread 10 (process= > > 96727 thread 0x2a23):
>=3B >=3B#0 0x963916fa in select$DARWIN_EXTS= > >N ()
>=3B >=3B#1 0x01023503 in Unix__select (nfds=3D7=2C readfds=3D= > >0x2813d54=2C
>=3B >=3Bwritefds=3D0x2813d64=2C exceptfds=3D0x2813d7= > >4=2C timeout=3D0x0) at ../src/unix/
>=3B >=3BCommon/UnixC.c:301
= > >>=3B >=3B#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762
= > >>=3B >=3B(M3_Cwb5VA_nfd=3D<=3Bunknown type>=3B=2C M3_A4bqCj_timeout= > >=3D0x0) at ../src/thread/
>=3B >=3BPTHREAD/ThreadPThread.m3:787
= > >>=3B >=3B#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1= > >ed5204=2C
>=3B >=3BM3_Cwb5VA_fd=3D<=3Bunknown type>=3B=2C M3_A= > >icXUJ_read=3D1 '\001'=2C
>=3B >=3BM3_CtKayy_interval=3D-1=2C M3_Ai= > >cXUJ_alertable=3D0 '\0') at ../src/thread/
>=3B >=3BPTHREAD/ThreadP= > >Thread.m3:826
>=3B >=3B#4 0x010201b4 in SchedulerPosix__IOWait (M3_= > >Cwb5VA_fd=3D<=3Bunknown type>=3B=2C
>=3B >=3BM3_AicXUJ_read=3D= > >1 '\001'=2C M3_CtKayy_timeoutInterval=3D-1) at ../src/
>=3B >=3Bthr= > >ead/PTHREAD/ThreadPThread.m3:729
>=3B >=3B#5 0x00bbf20b in XInput__= > >WaitForXInput (M3_Bkyxhg_self=3D0x1ed51f4)
>=3B >=3Bat ../src/xvbt= > >/XInput.m3:63
>=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M= > >3_BeUkBA_me=3D0x1c38250)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadP= > >Thread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase = > >
>=3B >=3B(M3_AJWxb1_param=3D0x1c38250) at ../src/thread/PTHREAD/ >r>>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthr= > >ead_start ()
>=3B >=3B#9 0x96373012 in thread_start ()
>=3B &g= > >t=3B
>=3B >=3BThread 9 (process 96727 thread 0x29f3):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1e3fafc=2C
>=3B >=3BM3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0j= > >v4_c=3D0x1e3f9c8=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Th= > >read__Wait (M3_AYIbX3_m=3D0x1e3f9bc=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1e= > >3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x= > >007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=3D0x1e3ccfc=2C
>=3B >= > >=3BM3_Ao6Rbg_initiator=3D0x1ecd9cc=2C M3_BMhQCx_dispatchProc=3D0x150e0=2C = > >
>=3B >=3BM3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:306
&g= > >t=3B >=3B#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D0x1ecd9c= > >c=2C
>=3B >=3BM3_DsvzJ6_style=3D0 '\0'=2C M3_AcxOUs_priority=3D1= > >=2C
>=3B >=3BM3_Bd56fi_eventName=3D0x1d9d60=2C M3_BMhQCx_dispatchP= > >roc=3D0x150e0=2C
>=3B >=3BM3_Af40ku_evtArgs=3D0x1e08014) at ../src= > >/Zeus.m3:246
>=3B >=3B#7 0x000149a7 in BresenhamIE__ShowPixel
= > >>=3B >=3B(M3_CfiRBL_initiator=3D0x1ecd9cc=2C M3_AcxOUs_x=3D3=2C M3_AcxO= > >Us_y=3D2=2C
>=3B >=3BM3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2=3D-2) at ../= > >I386_DARWIN/BresenhamIE.m3:227
>=3B >=3B#8 0x000175b7 in AlgBresenh= > >am__DrawLine (M3_ECecEc_alg=3D0x1ecd9cc=2C
>=3B >=3BM3_AcxOUs_x1= > >=3D0=2C M3_AcxOUs_y1=3D0=2C M3_AcxOUs_x2=3D10=2C M3_AcxOUs_y2=3D6) at ../ <= > >br>>=3B >=3Bsrc/bresenham/AlgBresenham.m3:55
>=3B >=3B#9 0x0001= > >788f in AlgBresenham__Run (M3_ECecEc_alg=3D0x1ecd9cc) at ../
>=3B >= > >=3Bsrc/bresenham/AlgBresenham.m3:86
>=3B >=3B#10 0x007bb729 in ZeusP= > >anel__AlgThread (M3_Dijbki_ac=3D0x1e3fae8) at ../
>=3B >=3Bsrc/Zeus= > >Panel.m3:1534
>=3B >=3B#11 0x0101f243 in ThreadPThread__RunThread (M= > >3_BeUkBA_me=3D0x1c29fd0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadP= > >Thread.m3:546
>=3B >=3B#12 0x0101ef74 in ThreadPThread__ThreadBase = > >
>=3B >=3B(M3_AJWxb1_param=3D0x1c29fd0) at ../src/thread/PTHREAD/ >r>>=3B >=3BThreadPThread.m3:522
>=3B >=3B#13 0x96373155 in _pthr= > >ead_start ()
>=3B >=3B#14 0x96373012 in thread_start ()
>=3B &g= > >t=3B
>=3B >=3BThread 8 (process 96727 thread 0x2803):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1d8e01c=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d71fdc=2C M3_Bl0j= > >v4_c=3D0x1d71fe8=2C M3_AicXUJ_alertable=3D1
>=3B >=3B'\001') at ..= > >/src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d7a6 in = > >Thread__AlertWait (M3_AYIbX3_m=3D0x1d71fdc=2C
>=3B >=3BM3_Bl0jv4_c= > >=3D0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266
>=3B >= > >=3B#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=3D0x1d71680=2C
&= > >gt=3B >=3BM3_DBiloZ_this=3D1 '\001'=2C M3_Cwb5VA_minSize=3D<=3Bunknown = > >type>=3B) at ../src/
>=3B >=3Bformatter/Formatter.m3:440
>= > >=3B >=3B#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=3D0x1d71680=2C <= > >br>>=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>=3B) at ../src/formatter= > >/Formatter.m3:542
>=3B >=3B#7 0x00e3c2b8 in Formatter__Peek (M3_ACp= > >9GL_t=3D0x1d71680=2C
>=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>= > >=3B) at ../src/formatter/Formatter.m3:592
>=3B >=3B#8 0x00e3c2ff in= > > Formatter__PeekOp (M3_ACp9GL_t=3D0x1d71680=2C
>=3B >=3BM3_Cwb5VA_= > >i=3D<=3Bunknown type>=3B) at ../src/formatter/Formatter.m3:577
>= > >=3B >=3B#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d71680= > >=2C
>=3B >=3BM3_DOUxXw_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb038ce= > >90=2C
>=3B >=3BM3_Cwb5VA_maxL=3D<=3Bunknown type>=3B=2C M3_CCu= > >ODf_op=3D0x1d72c08) at ../src/
>=3B >=3Bformatter/Formatter.m3:708<= > >br>>=3B >=3B#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1= > >d8e00c) at ../
>=3B >=3Bsrc/formatter/Formatter.m3:615
>=3B &g= > >t=3B#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29140) = > >
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B &g= > >t=3B#12 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb= > >1_param=3D0x1c29140) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThre= > >ad.m3:522
>=3B >=3B#13 0x96373155 in _pthread_start ()
>=3B >= > >=3B#14 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThrea= > >d 7 (process 96727 thread 0x2703):
>=3B >=3B#0 0x963422ce in semaph= > >ore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread_cond_wai= > >t ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>=3B >= > >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d71618=2C <= > >br>>=3B >=3BM3_AYIbX3_m=3D0x1d715ec=2C M3_Bl0jv4_c=3D0x1d715f8=2C M3_Ai= > >cXUJ_alertable=3D1
>=3B >=3B'\001') at ../src/thread/PTHREAD/Threa= > >dPThread.m3:226
>=3B >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYI= > >bX3_m=3D0x1d715ec=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1d715f8) at ../src/t= > >hread/PTHREAD/ThreadPThread.m3:266
>=3B >=3B#5 0x00e3bdf2 in Format= > >ter__Allocate (M3_ACp9GL_t=3D0x1d70c90=2C
>=3B >=3BM3_DBiloZ_this= > >=3D1 '\001'=2C M3_Cwb5VA_minSize=3D<=3Bunknown type>=3B) at ../src/ >>>=3B >=3Bformatter/Formatter.m3:440
>=3B >=3B#6 0x00e3bf0a in = > >Formatter__Probe (M3_ACp9GL_t=3D0x1d70c90=2C
>=3B >=3BM3_Cwb5VA_i= > >=3D<=3Bunknown type>=3B) at ../src/formatter/Formatter.m3:542
>=3B= > > >=3B#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d70c90=2C
&= > >gt=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>=3B) at ../src/formatter/For= > >matter.m3:592
>=3B >=3B#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9G= > >L_t=3D0x1d70c90=2C
>=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>=3B= > >) at ../src/formatter/Formatter.m3:577
>=3B >=3B#9 0x00e3cb25 in Fo= > >rmatter__PrintUntil (M3_ACp9GL_t=3D0x1d70c90=2C
>=3B >=3BM3_DOUxXw= > >_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb030ae90=2C
>=3B >=3BM3_Cwb5= > >VA_maxL=3D<=3Bunknown type>=3B=2C M3_CCuODf_op=3D0x1d72c08) at ../src/ = > >
>=3B >=3Bformatter/Formatter.m3:708
>=3B >=3B#10 0x00e3cfc9 = > >in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d71608) at ../
>=3B >= > >=3Bsrc/formatter/Formatter.m3:615
>=3B >=3B#11 0x0101f243 in ThreadP= > >Thread__RunThread (M3_BeUkBA_me=3D0x1c221e0)
>=3B >=3Bat ../src/th= > >read/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#12 0x0101ef74 in ThreadP= > >Thread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c221e0) at ../sr= > >c/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >=3B#13= > > 0x96373155 in _pthread_start ()
>=3B >=3B#14 0x96373012 in thread_s= > >tart ()
>=3B >=3B
>=3B >=3BThread 6 (process 96727 thread 0x2= > >603):
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
&g= > >t=3B >=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x96= > >3b9539 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThr= > >ead__XWait (M3_BXP32l_self=3D0x1d729bc=2C
>=3B >=3BM3_AYIbX3_m=3D0= > >x1d728b4=2C M3_Bl0jv4_c=3D0x1d729a0=2C M3_AicXUJ_alertable=3D1
>=3B = > >>=3B'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >= > >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d728b4=2C
>= > >=3B >=3BM3_Bl0jv4_c=3D0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m= > >3:266
>=3B >=3B#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_= > >self=3D0x1d729b0)
>=3B >=3Bat ../src/WorkerPool.m3:152
>=3B &= > >gt=3B#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28e10) = > >
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B &= > >gt=3B#7 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWx= > >b1_param=3D0x1c28e10) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThr= > >ead.m3:522
>=3B >=3B#8 0x96373155 in _pthread_start ()
>=3B &g= > >t=3B#9 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThre= > >ad 5 (process 96727 thread 0x2313):
>=3B >=3B#0 0x963916fa in selec= > >t$DARWIN_EXTSN ()
>=3B >=3B#1 0x01023503 in Unix__select (nfds=3D4= > >=2C readfds=3D0x1d74014=2C
>=3B >=3Bwritefds=3D0x1d74024=2C except= > >fds=3D0x1d74034=2C timeout=3D0xb0206b20) at ../src/
>=3B >=3Bunix/C= > >ommon/UnixC.c:301
>=3B >=3B#2 0x01020970 in ThreadPThread__XIOWait_= > >_CallSelect.762
>=3B >=3B(M3_Cwb5VA_nfd=3D<=3Bunknown type>=3B= > >=2C M3_A4bqCj_timeout=3D0xb0206b20) at ../src/
>=3B >=3Bthread/PTHR= > >EAD/ThreadPThread.m3:787
>=3B >=3B#3 0x010206a8 in ThreadPThread__X= > >IOWait (M3_BXP32l_self=3D0x1d585bc=2C
>=3B >=3BM3_Cwb5VA_fd=3D<= > >=3Bunknown type>=3B=2C M3_AicXUJ_read=3D1 '\001'=2C
>=3B >=3BM3_= > >CtKayy_interval=3D1.7976931348623157e+308=2C M3_AicXUJ_alertable=3D1
&= > >gt=3B >=3B'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823
>=3B= > > >=3B#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3D<=3B= > >unknown
>=3B >=3Btype>=3B=2C M3_AicXUJ_read=3D1 '\001'=2C M3_CtK= > >ayy_timeoutInterval=3D-1) at ../
>=3B >=3Bsrc/thread/PTHREAD/Thread= > >PThread.m3:742
>=3B >=3B#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_Aa= > >hksS_c=3D0x1d58594=2C
>=3B >=3BM3_DoBjMZ_peer=3D0xb0206cb4) at ../= > >src/POSIX/TCP.m3:458
>=3B >=3B#6 0x00dd3da8 in TCP__Accept (M3_Aahk= > >sS_c=3D0x1d58594) at ../src/POSIX/
>=3B >=3BTCP.m3:234
>=3B &g= > >t=3B#7 0x006dbc6b in LocalObjectSpace__SpaceAccept
>=3B >=3B(M3_D= > >bz8GV_self=3D0x1d585b0) at ../src/LocalObjectSpace.m3:307
>=3B >=3B#= > >8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28d60)
&= > >gt=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#= > >9 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_par= > >am=3D0x1c28d60) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3= > >:522
>=3B >=3B#10 0x96373155 in _pthread_start ()
>=3B >=3B#1= > >1 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThread 4 (= > >process 96727 thread 0x2003):
>=3B >=3B#0 0x9634946e in __semwait_s= > >ignal ()
>=3B >=3B#1 0x963492ef in nanosleep$UNIX2003 ()
>=3B = > >>=3B#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb0184dd0=2C
= > >>=3B >=3Brem=3D0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:31= > >8
>=3B >=3B#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self= > >=3D0x1d0ba08=2C
>=3B >=3BM3_CtKayy_n=3D1=2C M3_AicXUJ_alertable=3D= > >0 '\0') at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:668
= > >>=3B >=3B#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ../src/th= > >read/
>=3B >=3BPTHREAD/ThreadPThread.m3:685
>=3B >=3B#5 0x0= > >0a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D0x1d0ba00)
>=3B &= > >gt=3Bat ../src/lego/FileBrowserVBT.m3:259
>=3B >=3B#6 0x0101f243 in= > > ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21830)
>=3B >=3Bat .= > >./src/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x0101ef74 in= > > ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c21830) = > >at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B &= > >gt=3B#8 0x96373155 in _pthread_start ()
>=3B >=3B#9 0x96373012 in = > >thread_start ()
>=3B >=3B
>=3B >=3BThread 3 (process 96727 th= > >read 0x1f03):
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap = > >()
>=3B >=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B= > >#2 0x963b9539 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in Th= > >readPThread__XWait (M3_BXP32l_self=3D0x1d090d4=2C
>=3B >=3BM3_AYIb= > >X3_m=3D0x1d090b0=2C M3_Bl0jv4_c=3D0x1d090bc=2C M3_AicXUJ_alertable=3D0 >>>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>=3B= > > >=3B#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d090b0=2C
>= > >=3B >=3BM3_Bl0jv4_c=3D0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m= > >3:277
>=3B >=3B#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTr= > >Vz_cl=3D0x1d090cc)
>=3B >=3Bat ../src/vtext/VTView.m3:111
>= > >=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21= > >310)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>= > >=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3= > >_AJWxb1_param=3D0x1c21310) at ../src/thread/PTHREAD/
>=3B >=3BThrea= > >dPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthread_start ()
>= > >=3B >=3B#9 0x96373012 in thread_start ()
>=3B >=3B
>=3B >= > >=3BThread 2 (process 96727 thread 0xd07):
>=3B >=3B#0 0x963422ce in= > > semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread_c= > >ond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>= > >=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d006c= > >8=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00688=2C M3_Bl0jv4_c=3D0x1d00694= > >=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/thread/PTHREA= > >D/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread__Wait (M3_A= > >YIbX3_m=3D0x1d00688=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1d00694) at ../src= > >/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x00bf33d2 in VBTR= > >ep__MeterMaid (M3_EMTrVz_self=3D0x1d006bc) at ../
>=3B >=3Bsrc/vbt/= > >VBTRep.m3:439
>=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M= > >3_BeUkBA_me=3D0x1c21390)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadP= > >Thread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase = > >
>=3B >=3B(M3_AJWxb1_param=3D0x1c21390) at ../src/thread/PTHREAD/ >r>>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthr= > >ead_start ()
>=3B >=3B#9 0x96373012 in thread_start ()
>=3B &g= > >t=3B
>=3B >=3BThread 1 (process 96727 thread 0x10b):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1d0000c=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_Bl0j= > >v4_c=3D0x1df3114=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Th= > >read__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1d= > >f3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x= > >00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1e3a204) at ../
>= > >=3B >=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007c09eb in Zeus= > >Panel__Interact (M3_Bd56fi_title=3D0x290db0=2C
>=3B >=3BM3_DYb95R_= > >path=3D0x1d498c0) at ../src/ZeusPanel.m3:477
>=3B >=3B#7 0x001b0ede= > > in Main_M3 (M3_AcxOUs_mode=3D1) at ../src/Main.m3:165
>=3B >=3B#8 = > >0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=3D0x1d6060) at ../
>= > >=3B >=3Bsrc/runtime/common/RTLinker.m3:399
>=3B >=3B#9 0x00002578= > > in main (argc=3D1=2C argv=3D0xbfffedb8=2C envp=3D0xbfffedc0) at
>= > >=3B >=3B_m3main.mc:6
>=3B >=3B
>=3B >=3B
>=3B >=3BAn= > >tony Hosking | Associate Professor | Computer Science | Purdue
>=3B = > >>=3BUniversity
>=3B >=3B305 N. University Street | West Lafayette = > >| IN 47907 | USA
>=3B >=3BOffice +1 765 494 6001 | Mobile +1 765 427= > > 5484
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B >r>>=3B >=3BOn 6 Sep 2009=2C at 23:18=2C Jay K wrote:
>=3B >=3B >r>>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>= > >=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B &g= > >t=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B&g= > >t=3B [was truncated again!]
>=3B >=3B>=3B
>=3B >=3B>=3B P= > >PC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes runs out of
&= > >gt=3B >=3B>=3B stack
>=3B >=3B
>=3B >=3B
>=3B >=3B= > >--Apple-Mail-13--794937978
>=3B >=3BContent-Type: text/html=3B
&g= > >t=3B >=3B charset=3DUS-ASCII
>=3B >=3BContent-Transfer-Encoding: q > >= > >uoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>=3B<=3Bbody= > > style=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode: space=3B =3D
>= > >=3B >=3B-webkit-line-break: after-white-space=3B ">=3BHere's the hang b= > >acktrace for =3D
>=3B >=3Bmentor. &=3Bnbsp=3BAgain=2C all appears= > > normal=2C except that all the threads are =3D
>=3B >=3Bpaused or wa= > >iting=2C which is suspicious. &=3Bnbsp=3BI'm stumped for =3D
>=3B &= > >gt=3Bnow.<=3Bdiv>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3B= > >div>=3BThread 21 (process 96727 thread =3D
>=3B >=3B0x7403):<=3B= > >/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x9634946e in __semwait_signal = > >=3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963= > >492ef in nanosleep$UNIX2003 ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb= > >15d4db0=2C =3D
>=3B >=3Brem=3D3D0xb15d4db8) at =3D
>=3B >=3B.= > >./src/thread/PTHREAD/ThreadPThreadC.c:318<=3B/div>=3B<=3Bdiv>=3B#3 = > >&=3Bnbsp=3B0x0101fd7c =3D
>=3B >=3Bin ThreadPThread__XPause (M3_B= > >XP32l_self=3D3D0x1f3f880=2C M3_CtKayy_n=3D3D1=2C =3D
>=3B >=3BM3_Aic= > >XUJ_alertable=3D3D0 '\0') at =3D
>=3B >=3B../src/thread/PTHREAD/Thre= > >adPThread.m3:668<=3B/div>=3B<=3Bdiv>=3B#4 &=3Bnbsp=3B0x0101fef3 = > >=3D
>=3B >=3Bin Thread__Pause (M3_CtKayy_n=3D3D1) at =3D
>=3B &= > >gt=3B../src/thread/PTHREAD/ThreadPThread.m3:685<=3B/div>=3B<=3Bdiv>= > >=3B#5 &=3Bnbsp=3B0x00bc9cf4 =3D
>=3B >=3Bin XClientF__MeterMaid (= > >M3_AS2y1X_cl=3D3D0x1f3f870) at =3D
>=3B >=3B../src/xvbt/XClientF.m3:= > >105<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>= > >=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c441d0) at =3D
&= > >gt=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<= > >=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThrea= > >d__ThreadBase (M3_AJWxb1_param=3D3D0x1c441d0) at =3D
>=3B >=3B../src= > >/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &= > >=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>= > >=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>=3B= > > >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<= > >=3Bdiv>=3BThread 20 (process 96727 thread =3D
>=3B >=3B0x7103):<= > >=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3BThreadPThread__XTestAlert =3D<= > >br>>=3B >=3B(M3_BXP32l_self=3D3D0x1e5c134) at =3D
>=3B >=3B../sr= > >c/thread/PTHREAD/ThreadPThread.m3:319<=3B/div>=3B<=3Bdiv>=3B#1 &= > >=3Bnbsp=3B0x0101fd9b =3D
>=3B >=3Bin ThreadPThread__XPause (M3_BXP32= > >l_self=3D3D0x1e5c134=2C =3D
>=3B >=3BM3_CtKayy_n=3D3D0.0056863520294= > >427872=2C M3_AicXUJ_alertable=3D3D1 '\001') at =3D
>=3B >=3B../src/t= > >hread/PTHREAD/ThreadPThread.m3:669<=3B/div>=3B<=3Bdiv>=3B#2 &=3B= > >nbsp=3B0x01020024 =3D
>=3B >=3Bin Thread__AlertPause (M3_CtKayy_n=3D= > >3D0.0056863520294427872) at =3D
>=3B >=3B../src/thread/PTHREAD/Threa= > >dPThread.m3:699<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x008f9ea1 = > >=3D
>=3B >=3Bin Animate__Do (M3_CCfZY3_t=3D3D0x1e7e3fc=2C M3_DsL7Zz_= > >mg=3D3D0x0=2C =3D
>=3B >=3BM3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_du= > >ration=3D3D1) at =3D
>=3B >=3B../src/Animate.m3:71<=3B/div>=3B&l= > >t=3Bdiv>=3B#4 &=3Bnbsp=3B0x00909610 in MGV__Animation =3D
>=3B &g= > >t=3B(M3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_duration=3D3D1) at =3D
>= > >=3B >=3B../src/MGV.m3:313<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B= > >0x008921f9 in =3D
>=3B >=3BGraphVBT__AnimateGraph (M3_Cj00zi_graph= > >=3D3D0x1e5e00c=2C M3_BUucNs_t0=3D3D0=2C =3D
>=3B >=3BM3_BUucNs_t1=3D= > >3D1) at ../src/GraphVBT.m3:656<=3B/div>=3B<=3Bdiv>=3B#6 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view= > >=3D3D0x1ed3060=2C =3D
>=3B >=3BM3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y=3D3D= > >2=2C M3_AcxOUs_p1=3D3D6=2C M3_AcxOUs_p2=3D3D-2) =3D
>=3B >=3Bat ../s= > >rc/bresenham/ViewError.m3:548<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp= > >=3B0x0001529a in =3D
>=3B >=3BBresenhamIE__OEDispatcher (M3_Ao6Rbg_v= > >=3D3D0x1ed3060=2C =3D
>=3B >=3BM3_Af40ku_evt=3D3D0x1e08014) at =3D >r>>=3B >=3B../I386_DARWIN/BresenhamIE.m3:101<=3B/div>=3B<=3Bdiv&g= > >t=3B#8 &=3Bnbsp=3B0x007abb9b in =3D
>=3B >=3BZeus__ViewThread (M3= > >_BH3Tll_self=3D3D0x1e5c128) at =3D
>=3B >=3B../src/Zeus.m3:331<=3B= > >/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >= > >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fd80) at =3D
>=3B &= > >gt=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>= > >=3B#10 0x0101ef74 in =3D
>=3B >=3BThreadPThread__ThreadBase (M3_AJWx= > >b1_param=3D3D0x1c3fd80) at =3D
>=3B >=3B../src/thread/PTHREAD/Thread= > >PThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#11 0x96373155 in =3D
>= > >=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#12 0x96373012 in= > > thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr= > >>=3B<=3B/div>=3B<=3Bdiv>=3BThread 19 (process 96727 thread =3D >>>=3B >=3B0x5d07):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963= > >422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B&= > >lt=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/di= > >v>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pt= > >hread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d18= > >9 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e5c0bc= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1edf= > >34c=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../src/thre= > >ad/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x= > >1e3f9bc=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1edf34c) at =3D
>=3B = > >>=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div>=3B<=3Bdiv&g= > >t=3B#5 &=3Bnbsp=3B0x007ab7f2 =3D
>=3B >=3Bin Zeus__WakeZeusAndSle= > >ep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D
>=3B >=3BM3_B74vJ1_view=3D3D= > >0x1edf25c) at ../src/Zeus.m3:361<=3B/div>=3B<=3Bdiv>=3B#6 =3D
&g= > >t=3B >=3B&=3Bnbsp=3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D3= > >D0x1e5c0b0) at =3D
>=3B >=3B../src/Zeus.m3:328<=3B/div>=3B<=3B= > >div>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__= > >RunThread (M3_BeUkBA_me=3D3D0x1c3fc80) at =3D
>=3B >=3B../src/thread= > >/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp= > >=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_p= > >aram=3D3D0x1c3fc80) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThr= > >ead.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373155 =3D >>>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#10 0x9637= > >3012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B&= > >lt=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 18 (process 96727 thread= > > =3D
>=3B >=3B0x700b):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp= > >=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/di= > >v>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()&= > >lt=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b95= > >39 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0= > >x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0= > >x1e5c044=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D= > >3D0x1ee3bac=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../= > >src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 = > >=3D
>=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX= > >3_m=3D3D0x1e3f9bc=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1ee3bac) at =3D<= > >br>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div>=3B&= > >lt=3Bdiv>=3B#5 &=3Bnbsp=3B0x007ab7f2 =3D
>=3B >=3Bin Zeus__Wake= > >ZeusAndSleep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D
>=3B >=3BM3_B74vJ1= > >_view=3D3D0x1ee3b00) at ../src/Zeus.m3:361<=3B/div>=3B<=3Bdiv>=3B#6= > > =3D
>=3B >=3B&=3Bnbsp=3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tl= > >l_self=3D3D0x1e5c038) at =3D
>=3B >=3B../src/Zeus.m3:328<=3B/div&g= > >t=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThrea= > >dPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fa90) at =3D
>=3B >=3B../= > >src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8 &a= > >mp=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3= > >_AJWxb1_param=3D3D0x1c3fa90) at =3D
>=3B >=3B../src/thread/PTHREAD/T= > >hreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x963731= > >55 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#= > >10 0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 17 (process 967= > >27 thread =3D
>=3B >=3B0x6e03):<=3B/div>=3B<=3Bdiv>=3B#0 &am= > >p=3Bnbsp=3B0x963493dc in _pthread_testcancel =3D
>=3B >=3B()<=3B/d= > >iv>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x96349275 in nanosleep$UNIX2003 ()= > ><=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x01022= > >cc4 in ThreadPThread__Nanosleep (req=3D3D0xb134add0=2C =3D
>=3B >=3B= > >rem=3D3D0xb134add8) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThr= > >eadC.c:318<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101fd7c =3D >>>=3B >=3Bin ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1e54388=2C M3_= > >CtKayy_n=3D3D0.5=2C =3D
>=3B >=3BM3_AicXUJ_alertable=3D3D0 '\0') at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:668<=3B/div>= > >=3B<=3Bdiv>=3B#4 &=3Bnbsp=3B0x0101fef3 =3D
>=3B >=3Bin Thread= > >__Pause (M3_CtKayy_n=3D3D0.5) at =3D
>=3B >=3B../src/thread/PTHREAD/= > >ThreadPThread.m3:685<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00a6f= > >0c0 =3D
>=3B >=3Bin VTCaret__Blinker (M3_Axogco_arg=3D3D0x1e5437c) a= > >t =3D
>=3B >=3B../src/vtext/VTCaret.m3:149<=3B/div>=3B<=3Bdiv&= > >gt=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunT= > >hread (M3_BeUkBA_me=3D3D0x1c3f9c0) at =3D
>=3B >=3B../src/thread/PTH= > >READ/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x= > >0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param= > >=3D3D0x1c3f9c0) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.= > >m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>= > >=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp= > >=3B0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 16 (process 967= > >27 thread =3D
>=3B >=3B0x435b):<=3B/div>=3B<=3Bdiv>=3B#0 &am= > >p=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()&= > >lt=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_= > >wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B= > >0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3B= > >nbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_se= > >lf=3D3D0x1df30c8=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1e3bb94=2C M3_Bl0= > >jv4_c=3D3D0x1e3bbb0=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') = > >at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>= > >=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIb= > >X3_m=3D3D0x1e3bb94=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1e3bbb0) at =3D= > >
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B= > ><=3Bdiv>=3B#5 &=3Bnbsp=3B0x007baaa1 =3D
>=3B >=3Bin ZeusPanel= > >__PanelThread (M3_CvdnuP_pc=3D3D0x1df30b8) at =3D
>=3B >=3B../src/Ze= > >usPanel.m3:1425<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 i= > >n =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c39830)= > > at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/di= > >v>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin Th= > >readPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c39830) at =3D
>=3B &g= > >t=3B../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>= > >=3B#8 &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<= > >=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D= > >
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div&= > >gt=3B<=3Bdiv>=3BThread 15 (process 96727 thread =3D
>=3B >=3B0x4= > >20b):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphor= > >e_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 = > >&=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv&= > >gt=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait (= > >)<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B &= > >gt=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d67e68=2C =3D
>=3B= > > >=3BM3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1d22688=2C M3_AicXUJ_= > >alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPT= > >hread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnb= > >sp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D
>=3B= > > >=3BM3_Bl0jv4_c=3D3D0x1d22688) at =3D
>=3B >=3B../src/thread/PTHR= > >EAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x0= > >0c40602 =3D
>=3B >=3Bin Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1ee3= > >b00) at =3D
>=3B >=3B../src/trestle/Trestle.m3:884<=3B/div>=3B&l= > >t=3Bdiv>=3B#6 &=3Bnbsp=3B0x007a98b1 in =3D
>=3B >=3BView__Waite= > >rThread (M3_C7vPGX_waiter=3D3D0x1d67e5c) at =3D
>=3B >=3B../src/View= > >.m3:74<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
= > >>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c305c0) at =3D >r>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B&l= > >t=3Bdiv>=3B#8 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThre= > >ad__ThreadBase (M3_AJWxb1_param=3D3D0x1c305c0) at =3D
>=3B >=3B../sr= > >c/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &= > >=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>= > >=3B<=3Bdiv>=3B#10 0x96373012 in thread_start =3D
>=3B >=3B()<= > >=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BTh= > >read 14 (process 96727 thread =3D
>=3B >=3B0x4103):<=3B/div>=3B&= > >lt=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D= > >
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742= > >c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B = > >>=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<= > >=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThrea= > >d__XWait (M3_BXP32l_self=3D3D0x1ee32e4=2C =3D
>=3B >=3BM3_AYIbX3_m= > >=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1edf3c4=2C M3_AicXUJ_alertable=3D3D0 = > >=3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226<= > >=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823= > > in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D
>=3B >=3BM3_Bl0jv= > >4_c=3D3D0x1edf3c4) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThre= > >ad.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00c40602 =3D
= > >>=3B >=3Bin Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1edf25c) at =3D
= > >>=3B >=3B../src/trestle/Trestle.m3:884<=3B/div>=3B<=3Bdiv>=3B#6= > > &=3Bnbsp=3B0x007a98b1 in =3D
>=3B >=3BView__WaiterThread (M3_C7v= > >PGX_waiter=3D3D0x1ee32d8) at =3D
>=3B >=3B../src/View.m3:74<=3B/di= > >v>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BTh= > >readPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38bf0) at =3D
>=3B >=3B= > >../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8= > > &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase = > >(M3_AJWxb1_param=3D3D0x1c38bf0) at =3D
>=3B >=3B../src/thread/PTHREA= > >D/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x963= > >73155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>= > >=3B#10 0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<= > >=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 13 (process= > > 96727 thread =3D
>=3B >=3B0x4003):<=3B/div>=3B<=3Bdiv>=3B#0= > > &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >= > >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread= > >_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bn= > >bsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &= > >amp=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP= > >32l_self=3D3D0x1edb2e4=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d00500=2C = > >M3_Bl0jv4_c=3D3D0x1ed532c=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B= > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdi= > >v>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_= > >AYIbX3_m=3D3D0x1d00500=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1ed532c) at= > > =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div&g= > >t=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00c40602 =3D
>=3B >=3Bin Trest= > >le__AwaitDelete (M3_BFdKo9_v=3D3D0x1ed3060) at =3D
>=3B >=3B../src/t= > >restle/Trestle.m3:884<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x007a= > >98b1 in =3D
>=3B >=3BView__WaiterThread (M3_C7vPGX_waiter=3D3D0x1edb= > >2d8) at =3D
>=3B >=3B../src/View.m3:74<=3B/div>=3B<=3Bdiv>= > >=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunThr= > >ead (M3_BeUkBA_me=3D3D0x1c38780) at =3D
>=3B >=3B../src/thread/PTHRE= > >AD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x01= > >01ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D= > >3D0x1c38780) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:= > >522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373155 =3D
>=3B= > > >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#10 0x96373012 in= > > thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr= > >>=3B<=3B/div>=3B<=3Bdiv>=3BThread 12 (process 96727 thread =3D >>>=3B >=3B0x2e03):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963= > >422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B&= > >lt=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/di= > >v>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pt= > >hread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d18= > >9 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed52a4= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed3= > >5f4=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread= > >/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed32= > >7c=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1ed35f4) at =3D
>=3B >= > >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>= > >=3B#5 &=3Bnbsp=3B0x00bb7962 =3D
>=3B >=3Bin XMessenger__Messenger= > > (M3_EVlqQO_self=3D3D0x1ed5294) at =3D
>=3B >=3B../src/xvbt/XMesseng= > >er.m3:69<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D >r>>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38420) at =3D= > >
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B= > ><=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPTh= > >read__ThreadBase (M3_AJWxb1_param=3D3D0x1c38420) at =3D
>=3B >=3B../= > >src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &a= > >mp=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div&g= > >t=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>= > >=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B&l= > >t=3Bdiv>=3BThread 11 (process 96727 thread =3D
>=3B >=3B0x2b07):&l= > >t=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_= > >signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3B= > >nbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2= > > =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B= > >/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin= > > ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed5254=2C =3D
>=3B >=3B= > >M3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed3614=2C M3_AicXUJ_alertab= > >le=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m= > >3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x= > >0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed327c=2C =3D
>=3B >=3B= > >M3_Bl0jv4_c=3D3D0x1ed3614) at =3D
>=3B >=3B../src/thread/PTHREAD/Thr= > >eadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00bbdbc2= > > =3D
>=3B >=3Bin XInput__FilterXInput (M3_DSd60P_self=3D3D0x1ed5244)= > > at =3D
>=3B >=3B../src/xvbt/XInput.m3:102<=3B/div>=3B<=3Bdiv&= > >gt=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunT= > >hread (M3_BeUkBA_me=3D3D0x1c38320) at =3D
>=3B >=3B../src/thread/PTH= > >READ/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x= > >0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param= > >=3D3D0x1c38320) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.= > >m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>= > >=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp= > >=3B0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 10 (process 967= > >27 thread =3D
>=3B >=3B0x2a23):<=3B/div>=3B<=3Bdiv>=3B#0 &am= > >p=3Bnbsp=3B0x963916fa in select$DARWIN_EXTSN =3D
>=3B >=3B()<=3B/d= > >iv>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x01023503 in Unix__select (nfds=3D= > >3D7=2C =3D
>=3B >=3Breadfds=3D3D0x2813d54=2C writefds=3D3D0x2813d64= > >=2C exceptfds=3D3D0x2813d74=2C =3D
>=3B >=3Btimeout=3D3D0x0) at ../s= > >rc/unix/Common/UnixC.c:301<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B &= > >gt=3B&=3Bnbsp=3B0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =3D= > >
>=3B >=3B(M3_Cwb5VA_nfd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C= > > M3_A4bqCj_timeout=3D3D0x0) at =3D
>=3B >=3B../src/thread/PTHREAD/Th= > >readPThread.m3:787<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x010206c= > >c =3D
>=3B >=3Bin ThreadPThread__XIOWait (M3_BXP32l_self=3D3D0x1ed52= > >04=2C =3D
>=3B >=3BM3_Cwb5VA_fd=3D3D&=3Blt=3Bunknown type&=3Bg= > >t=3B=2C M3_AicXUJ_read=3D3D1 '\001'=2C =3D
>=3B >=3BM3_CtKayy_interv= > >al=3D3D-1=2C M3_AicXUJ_alertable=3D3D0 '\0') at =3D
>=3B >=3B../src/= > >thread/PTHREAD/ThreadPThread.m3:826<=3B/div>=3B<=3Bdiv>=3B#4 &= > >=3Bnbsp=3B0x010201b4 =3D
>=3B >=3Bin SchedulerPosix__IOWait (M3_Cwb5= > >VA_fd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C =3D
>=3B >=3BM3_Ai= > >cXUJ_read=3D3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D3D-1) at =3D
>= > >=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:729<=3B/div>=3B<=3Bd= > >iv>=3B#5 &=3Bnbsp=3B0x00bbf20b =3D
>=3B >=3Bin XInput__WaitForX= > >Input (M3_Bkyxhg_self=3D3D0x1ed51f4) at =3D
>=3B >=3B../src/xvbt/XIn= > >put.m3:63<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D<= > >br>>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38250) at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>= > >=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin Thread= > >PThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38250) at =3D
>=3B >=3B= > >../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8= > > &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/di= > >v>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
&g= > >t=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B&= > >lt=3Bdiv>=3BThread 9 (process 96727 thread =3D
>=3B >=3B0x29f3):&l= > >t=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_= > >signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3B= > >nbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2= > > =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B= > >/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin= > > ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e3fafc=2C =3D
>=3B >=3B= > >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1e3f9c8=2C M3_AicXUJ_alertab= > >le=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m= > >3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x= > >0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C =3D
>=3B >=3B= > >M3_Bl0jv4_c=3D3D0x1e3f9c8) at =3D
>=3B >=3B../src/thread/PTHREAD/Thr= > >eadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x007ab312= > > =3D
>=3B >=3Bin Zeus__AlgToViews (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C = > >=3D
>=3B >=3BM3_Ao6Rbg_initiator=3D3D0x1ecd9cc=2C M3_BMhQCx_dispatch= > >Proc=3D3D0x150e0=2C =3D
>=3B >=3BM3_Af40ku_evtArgs=3D3D0x1e08014) at= > > ../src/Zeus.m3:306<=3B/div>=3B<=3Bdiv>=3B#6 =3D
>=3B >=3B&a= > >mp=3Bnbsp=3B0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D3D0x1ecd9cc= > >=2C =3D
>=3B >=3BM3_DsvzJ6_style=3D3D0 '\0'=2C M3_AcxOUs_priority=3D= > >3D1=2C =3D
>=3B >=3BM3_Bd56fi_eventName=3D3D0x1d9d60=2C M3_BMhQCx_di= > >spatchProc=3D3D0x150e0=2C =3D
>=3B >=3BM3_Af40ku_evtArgs=3D3D0x1e080= > >14) at ../src/Zeus.m3:246<=3B/div>=3B<=3Bdiv>=3B#7 =3D
>=3B &g= > >t=3B&=3Bnbsp=3B0x000149a7 in BresenhamIE__ShowPixel =3D
>=3B >=3B= > >(M3_CfiRBL_initiator=3D3D0x1ecd9cc=2C M3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y=3D3D= > >2=2C =3D
>=3B >=3BM3_AcxOUs_p1=3D3D6=2C M3_AcxOUs_p2=3D3D-2) at =3D<= > >br>>=3B >=3B../I386_DARWIN/BresenhamIE.m3:227<=3B/div>=3B<=3Bdiv&= > >gt=3B#8 &=3Bnbsp=3B0x000175b7 in =3D
>=3B >=3BAlgBresenham__DrawL= > >ine (M3_ECecEc_alg=3D3D0x1ecd9cc=2C M3_AcxOUs_x1=3D3D0=2C =3D
>=3B >= > >=3BM3_AcxOUs_y1=3D3D0=2C M3_AcxOUs_x2=3D3D10=2C M3_AcxOUs_y2=3D3D6) at =3D<= > >br>>=3B >=3B../src/bresenham/AlgBresenham.m3:55<=3B/div>=3B<=3Bdi= > >v>=3B#9 &=3Bnbsp=3B0x0001788f in =3D
>=3B >=3BAlgBresenham__Run= > > (M3_ECecEc_alg=3D3D0x1ecd9cc) at =3D
>=3B >=3B../src/bresenham/AlgB= > >resenham.m3:86<=3B/div>=3B<=3Bdiv>=3B#10 0x007bb729 in =3D
>= > >=3B >=3BZeusPanel__AlgThread (M3_Dijbki_ac=3D3D0x1e3fae8) at =3D
>= > >=3B >=3B../src/ZeusPanel.m3:1534<=3B/div>=3B<=3Bdiv>=3B#11 0x0101= > >f243 in =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c= > >29fd0) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<= > >=3B/div>=3B<=3Bdiv>=3B#12 0x0101ef74 in =3D
>=3B >=3BThreadPTh= > >read__ThreadBase (M3_AJWxb1_param=3D3D0x1c29fd0) at =3D
>=3B >=3B../= > >src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#13 0= > >x96373155 in =3D
>=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv= > >>=3B#14 0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B= > ><=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 8 (proce= > >ss 96727 thread =3D
>=3B >=3B0x2803):<=3B/div>=3B<=3Bdiv>=3B= > >#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >= > >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread= > >_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bn= > >bsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &= > >amp=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP= > >32l_self=3D3D0x1d8e01c=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d71fdc=2C = > >M3_Bl0jv4_c=3D3D0x1d71fe8=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B= > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3B= > >div>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWa= > >it (M3_AYIbX3_m=3D3D0x1d71fdc=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1d71= > >fe8) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:266<= > >=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00e3bdf2 =3D
>=3B >= > >=3Bin Formatter__Allocate (M3_ACp9GL_t=3D3D0x1d71680=2C M3_DBiloZ_this=3D3D= > >1 =3D
>=3B >=3B'\001'=2C M3_Cwb5VA_minSize=3D3D&=3Blt=3Bunknown t= > >ype&=3Bgt=3B) at =3D
>=3B >=3B../src/formatter/Formatter.m3:440&l= > >t=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x00e3bf0a in =3D
>=3B &= > >gt=3BFormatter__Probe (M3_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D&=3B= > >lt=3Bunknown =3D
>=3B >=3Btype&=3Bgt=3B) at ../src/formatter/Form= > >atter.m3:542<=3B/div>=3B<=3Bdiv>=3B#7 =3D
>=3B >=3B&=3Bnb= > >sp=3B0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d71680=2C =3D
>= > >=3B >=3BM3_Cwb5VA_i=3D3D&=3Blt=3Bunknown type&=3Bgt=3B) at =3D
&= > >gt=3B >=3B../src/formatter/Formatter.m3:592<=3B/div>=3B<=3Bdiv>= > >=3B#8 &=3Bnbsp=3B0x00e3c2ff in =3D
>=3B >=3BFormatter__PeekOp (M3= > >_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D&=3Blt=3Bunknown =3D
>= > >=3B >=3Btype&=3Bgt=3B) at ../src/formatter/Formatter.m3:577<=3B/div&= > >gt=3B<=3Bdiv>=3B#9 =3D
>=3B >=3B&=3Bnbsp=3B0x00e3cb25 in Form= > >atter__PrintUntil (M3_ACp9GL_t=3D3D0x1d71680=2C =3D
>=3B >=3BM3_DOUx= > >Xw_mode=3D3D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb038ce90=2C =3D
>=3B >= > >=3BM3_Cwb5VA_maxL=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_CCuODf_op= > >=3D3D0x1d72c08) at =3D
>=3B >=3B../src/formatter/Formatter.m3:708<= > >=3B/div>=3B<=3Bdiv>=3B#10 0x00e3cfc9 in =3D
>=3B >=3BFormatter= > >__PrintTop (M3_B5Nhtj_self=3D3D0x1d8e00c) at =3D
>=3B >=3B../src/for= > >matter/Formatter.m3:615<=3B/div>=3B<=3Bdiv>=3B#11 0x0101f243 in =3D= > >
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c29140) at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>= > >=3B<=3Bdiv>=3B#12 0x0101ef74 in =3D
>=3B >=3BThreadPThread__Thre= > >adBase (M3_AJWxb1_param=3D3D0x1c29140) at =3D
>=3B >=3B../src/thread= > >/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#13 0x96373155 = > >in =3D
>=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#14 = > >0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv&= > >gt=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 7 (process 96727 t= > >hread =3D
>=3B >=3B0x2703):<=3B/div>=3B<=3Bdiv>=3B#0 &=3B= > >nbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<= > >=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wa= > >it ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x= > >963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnb= > >sp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self= > >=3D3D0x1d71618=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d715ec=2C M3_Bl0jv= > >4_c=3D3D0x1d715f8=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') = > >at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>= > >=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3= > >_AYIbX3_m=3D3D0x1d715ec=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1d715f8) a= > >t =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div&= > >gt=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00e3bdf2 =3D
>=3B >=3Bin Form= > >atter__Allocate (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_DBiloZ_this=3D3D1 =3D
&= > >gt=3B >=3B'\001'=2C M3_Cwb5VA_minSize=3D3D&=3Blt=3Bunknown type&=3B= > >gt=3B) at =3D
>=3B >=3B../src/formatter/Formatter.m3:440<=3B/div&g= > >t=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x00e3bf0a in =3D
>=3B >=3BForma= > >tter__Probe (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D&=3Blt=3Bunkno= > >wn =3D
>=3B >=3Btype&=3Bgt=3B) at ../src/formatter/Formatter.m3:5= > >42<=3B/div>=3B<=3Bdiv>=3B#7 =3D
>=3B >=3B&=3Bnbsp=3B0x00e= > >3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d70c90=2C =3D
>=3B >=3B= > >M3_Cwb5VA_i=3D3D&=3Blt=3Bunknown type&=3Bgt=3B) at =3D
>=3B >= > >=3B../src/formatter/Formatter.m3:592<=3B/div>=3B<=3Bdiv>=3B#8 &= > >=3Bnbsp=3B0x00e3c2ff in =3D
>=3B >=3BFormatter__PeekOp (M3_ACp9GL_t= > >=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D&=3Blt=3Bunknown =3D
>=3B >=3Bt= > >ype&=3Bgt=3B) at ../src/formatter/Formatter.m3:577<=3B/div>=3B<=3B= > >div>=3B#9 =3D
>=3B >=3B&=3Bnbsp=3B0x00e3cb25 in Formatter__Prin= > >tUntil (M3_ACp9GL_t=3D3D0x1d70c90=2C =3D
>=3B >=3BM3_DOUxXw_mode=3D3= > >D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb030ae90=2C =3D
>=3B >=3BM3_Cwb5VA_= > >maxL=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_CCuODf_op=3D3D0x1d72c08= > >) at =3D
>=3B >=3B../src/formatter/Formatter.m3:708<=3B/div>=3B&= > >lt=3Bdiv>=3B#10 0x00e3cfc9 in =3D
>=3B >=3BFormatter__PrintTop (M3= > >_B5Nhtj_self=3D3D0x1d71608) at =3D
>=3B >=3B../src/formatter/Formatt= > >er.m3:615<=3B/div>=3B<=3Bdiv>=3B#11 0x0101f243 in =3D
>=3B >= > >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c221e0) at =3D
>=3B &= > >gt=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>= > >=3B#12 0x0101ef74 in =3D
>=3B >=3BThreadPThread__ThreadBase (M3_AJWx= > >b1_param=3D3D0x1c221e0) at =3D
>=3B >=3B../src/thread/PTHREAD/Thread= > >PThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#13 0x96373155 in =3D
>= > >=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#14 0x96373012 in= > > thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr= > >>=3B<=3B/div>=3B<=3Bdiv>=3BThread 6 (process 96727 thread =3D
= > >>=3B >=3B0x2603):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x9634= > >22ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B&l= > >t=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div= > >>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pth= > >read_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189= > > =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d729bc= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d728b4=2C M3_Bl0jv4_c=3D3D0x1d72= > >9a0=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../src/thre= > >ad/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x= > >1d728b4=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1d729a0) at =3D
>=3B = > >>=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div>=3B<=3Bdiv&g= > >t=3B#5 &=3Bnbsp=3B0x0073de32 =3D
>=3B >=3Bin WorkerPool__ClericAp= > >ply (M3_BSwVRC_self=3D3D0x1d729b0) at =3D
>=3B >=3B../src/WorkerPool= > >.m3:152<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D >>>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c28e10) at =3D<= > >br>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B&= > >lt=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThr= > >ead__ThreadBase (M3_AJWxb1_param=3D3D0x1c28e10) at =3D
>=3B >=3B../s= > >rc/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &am= > >p=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>= > >=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>=3B= > > >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<= > >=3Bdiv>=3BThread 5 (process 96727 thread =3D
>=3B >=3B0x2313):<= > >=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963916fa in select$DARWIN_EX= > >TSN =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0= > >x01023503 in Unix__select (nfds=3D3D4=2C =3D
>=3B >=3Breadfds=3D3D0x= > >1d74014=2C writefds=3D3D0x1d74024=2C exceptfds=3D3D0x1d74034=2C =3D
>= > >=3B >=3Btimeout=3D3D0xb0206b20) at ../src/unix/Common/UnixC.c:301<=3B/d= > >iv>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x01020970 in T= > >hreadPThread__XIOWait__CallSelect.762 =3D
>=3B >=3B(M3_Cwb5VA_nfd=3D= > >3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_A4bqCj_timeout=3D3D0xb0206b20)= > > =3D
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:787<=3B/di= > >v>=3B<=3Bdiv>=3B#3 =3D
>=3B >=3B&=3Bnbsp=3B0x010206a8 in Th= > >readPThread__XIOWait (M3_BXP32l_self=3D3D0x1d585bc=2C =3D
>=3B >=3BM= > >3_Cwb5VA_fd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_AicXUJ_read=3D3D= > >1 '\001'=2C =3D
>=3B >=3BM3_CtKayy_interval=3D3D1.7976931348623157e+= > >308=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../src/thre= > >ad/PTHREAD/ThreadPThread.m3:823<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x010202e7 in SchedulerPosix__IOAlertWait =3D
&g= > >t=3B >=3B(M3_Cwb5VA_fd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_Aic= > >XUJ_read=3D3D1 '\001'=2C =3D
>=3B >=3BM3_CtKayy_timeoutInterval=3D3D= > >-1) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:742<=3B= > >/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00dd3cc2 =3D
>=3B >=3Bin= > > TCPMisc__Accept=3D46rom (M3_AahksS_c=3D3D0x1d58594=2C =3D
>=3B >=3B= > >M3_DoBjMZ_peer=3D3D0xb0206cb4) at ../src/POSIX/TCP.m3:458<=3B/div>=3B&l= > >t=3Bdiv>=3B#6 =3D
>=3B >=3B&=3Bnbsp=3B0x00dd3da8 in TCP__Accept= > > (M3_AahksS_c=3D3D0x1d58594) at =3D
>=3B >=3B../src/POSIX/TCP.m3:234= > ><=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x006dbc6b in =3D
>=3B= > > >=3BLocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=3D3D0x1d585b0) at =3D<= > >br>>=3B >=3B../src/LocalObjectSpace.m3:307<=3B/div>=3B<=3Bdiv>= > >=3B#8 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunThr= > >ead (M3_BeUkBA_me=3D3D0x1c28d60) at =3D
>=3B >=3B../src/thread/PTHRE= > >AD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x01= > >01ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D= > >3D0x1c28d60) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:= > >522<=3B/div>=3B<=3Bdiv>=3B#10 0x96373155 in =3D
>=3B >=3B_pt= > >hread_start ()<=3B/div>=3B<=3Bdiv>=3B#11 0x96373012 in thread_start= > > =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/= > >div>=3B<=3Bdiv>=3BThread 4 (process 96727 thread =3D
>=3B >=3B= > >0x2003):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x9634946e in __sem= > >wait_signal =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3B= > >nbsp=3B0x963492ef in nanosleep$UNIX2003 ()<=3B/div>=3B<=3Bdiv>=3B#2= > > =3D
>=3B >=3B&=3Bnbsp=3B0x01022cc4 in ThreadPThread__Nanosleep (= > >req=3D3D0xb0184dd0=2C =3D
>=3B >=3Brem=3D3D0xb0184dd8) at =3D
>= > >=3B >=3B../src/thread/PTHREAD/ThreadPThreadC.c:318<=3B/div>=3B<=3Bd= > >iv>=3B#3 &=3Bnbsp=3B0x0101fd7c =3D
>=3B >=3Bin ThreadPThread__X= > >Pause (M3_BXP32l_self=3D3D0x1d0ba08=2C M3_CtKayy_n=3D3D1=2C =3D
>=3B &= > >gt=3BM3_AicXUJ_alertable=3D3D0 '\0') at =3D
>=3B >=3B../src/thread/P= > >THREAD/ThreadPThread.m3:668<=3B/div>=3B<=3Bdiv>=3B#4 &=3Bnbsp=3B= > >0x0101fef3 =3D
>=3B >=3Bin Thread__Pause (M3_CtKayy_n=3D3D1) at =3D<= > >br>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:685<=3B/div>=3B&= > >lt=3Bdiv>=3B#5 &=3Bnbsp=3B0x00a11d53 =3D
>=3B >=3Bin FileBrowse= > >rVBT__Watcher (M3_EMTrVz_cl=3D3D0x1d0ba00) at =3D
>=3B >=3B../src/le= > >go/FileBrowserVBT.m3:259<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0= > >101f243 in =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0= > >x1c21830) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546= > ><=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B &g= > >t=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21830) at =3D
= > >>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<= > >=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_sta= > >rt ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_s= > >tart =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<= > >=3B/div>=3B<=3Bdiv>=3BThread 3 (process 96727 thread =3D
>=3B &g= > >t=3B0x1f03):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in s= > >emaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv&g= > >t=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<= > >=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond= > >_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
&= > >gt=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d090d4=2C =3D >>>=3B >=3BM3_AYIbX3_m=3D3D0x1d090b0=2C M3_Bl0jv4_c=3D3D0x1d090bc=2C M3_= > >AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/T= > >hreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&a= > >mp=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d090b0=2C =3D >>>=3B >=3BM3_Bl0jv4_c=3D3D0x1d090bc) at =3D
>=3B >=3B../src/thre= > >ad/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbs= > >p=3B0x00a839e2 =3D
>=3B >=3Bin VTView__VFontCleanUpThread (M3_EMTrVz= > >_cl=3D3D0x1d090cc) at =3D
>=3B >=3B../src/vtext/VTView.m3:111<=3B/= > >div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3B= > >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21310) at =3D
>=3B >= > >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>= > >=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__Thread= > >Base (M3_AJWxb1_param=3D3D0x1c21310) at =3D
>=3B >=3B../src/thread/P= > >THREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B= > >0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdi= > >v>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>=3B >=3B()&l= > >t=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BT= > >hread 2 (process 96727 thread =3D
>=3B >=3B0xd07):<=3B/div>=3B&l= > >t=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D<= > >br>>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c= > >6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B &= > >gt=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3B= > >div>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__= > >XWait (M3_BXP32l_self=3D3D0x1d006c8=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D= > >0x1d00688=2C M3_Bl0jv4_c=3D3D0x1d00694=2C M3_AicXUJ_alertable=3D3D0 =3D
= > >>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div&= > >gt=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823 in Thre= > >ad__Wait (M3_AYIbX3_m=3D3D0x1d00688=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D= > >0x1d00694) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:27= > >7<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00bf33d2 =3D
>=3B &= > >gt=3Bin VBTRep__MeterMaid (M3_EMTrVz_self=3D3D0x1d006bc) at =3D
>=3B &= > >gt=3B../src/vbt/VBTRep.m3:439<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp= > >=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me= > >=3D3D0x1c21390) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.= > >m3:546<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>= > >=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21390) at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>= > >=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthre= > >ad_start ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in th= > >read_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>= > >=3B<=3B/div>=3B<=3Bdiv>=3BThread 1 (process 96727 thread =3D
>= > >=3B >=3B0x10b):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce= > > in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3B= > >div>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>= > >=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthrea= > >d_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 = > >=3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d0000c= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1df3= > >114=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread= > >/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d005= > >00=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1df3114) at =3D
>=3B >= > >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>= > >=3B#5 &=3Bnbsp=3B0x00c40602 =3D
>=3B >=3Bin Trestle__AwaitDelete = > >(M3_BFdKo9_v=3D3D0x1e3a204) at =3D
>=3B >=3B../src/trestle/Trestle.m= > >3:884<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x007c09eb in =3D
&= > >gt=3B >=3BZeusPanel__Interact (M3_Bd56fi_title=3D3D0x290db0=2C =3D
>= > >=3B >=3BM3_DYb95R_path=3D3D0x1d498c0) at ../src/ZeusPanel.m3:477<=3B/di= > >v>=3B<=3Bdiv>=3B#7 =3D
>=3B >=3B&=3Bnbsp=3B0x001b0ede in Ma= > >in_M3 (M3_AcxOUs_mode=3D3D1) at =3D
>=3B >=3B../src/Main.m3:165<= > >=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x0100eb1f in =3D
>=3B &g= > >t=3BRTLinker__RunMainBody (M3_DjPxE3_m=3D3D0x1d6060) at =3D
>=3B >= > >=3B../src/runtime/common/RTLinker.m3:399<=3B/div>=3B<=3Bdiv>=3B#9 &= > >amp=3Bnbsp=3B0x00002578 in =3D
>=3B >=3Bmain (argc=3D3D1=2C argv=3D3= > >D0xbfffedb8=2C envp=3D3D0xbfffedc0) at =3D
>=3B >=3B_m3main.mc:6<= > >=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3B/div>=3B&= > >lt=3Bdiv>=3B<=3Bbr>=3B<=3Bdiv>=3B <=3Bspan =3D
>=3B >=3B= > >class=3D3D"Apple-style-span" style=3D3D"font-size: 12px=3B ">=3B<=3Bdiv= > > =3D
>=3B >=3Bstyle=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode:= > > space=3B =3D
>=3B >=3B-webkit-line-break: after-white-space=3B ">= > >=3B<=3Bspan class=3D3D"Apple-style-span" =3D
>=3B >=3Bstyle=3D3D"b= > >order-collapse: separate=3B -webkit-border-horizontal-spacing: =3D
>= > >=3B >=3B0px=3B -webkit-border-vertical-spacing: 0px=3B color: rgb(0=2C 0= > >=2C 0)=3B =3D
>=3B >=3Bfont-family: Helvetica=3B font-size: 12px=3B = > >font-style: normal=3B =3D
>=3B >=3Bfont-variant: normal=3B font-weig= > >ht: normal=3B letter-spacing: normal=3B =3D
>=3B >=3Bline-height: no= > >rmal=3B -webkit-text-decorations-in-effect: none=3B =3D
>=3B >=3Btex= > >t-indent: 0px=3B -webkit-text-size-adjust: auto=3B text-transform: none=3B = > >=3D
>=3B >=3Borphans: 2=3B white-space: normal=3B widows: 2=3B word-= > >spacing: 0px=3B ">=3B<=3Bdiv =3D
>=3B >=3Bstyle=3D3D"word-wrap: = > >break-word=3B -webkit-nbsp-mode: space=3B =3D
>=3B >=3B-webkit-line-= > >break: after-white-space=3B ">=3B<=3Bspan class=3D3D"Apple-style-span" = > >=3D
>=3B >=3Bstyle=3D3D"border-collapse: separate=3B -webkit-border-= > >horizontal-spacing: =3D
>=3B >=3B0px=3B -webkit-border-vertical-spac= > >ing: 0px=3B color: rgb(0=2C 0=2C 0)=3B =3D
>=3B >=3Bfont-family: Hel= > >vetica=3B font-size: 12px=3B font-style: normal=3B =3D
>=3B >=3Bfont= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B =3D >>>=3B >=3Bline-height: normal=3B -webkit-text-decorations-in-effect: no= > >ne=3B =3D
>=3B >=3Btext-indent: 0px=3B -webkit-text-size-adjust: aut= > >o=3B text-transform: none=3B =3D
>=3B >=3Borphans: 2=3B white-space:= > > normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
>= > >=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separate= > >=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webkit-b= > >order-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-sp= > >an" style=3D3D"border-collapse: separate=3B =3D
>=3B >=3B-webkit-bor= > >der-horizontal-spacing: 0px=3B -webkit-border-vertical-spacing: =3D
>= > >=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-= > >size: 12px=3B =3D
>=3B >=3Bfont-style: normal=3B font-variant: norma= > >l=3B font-weight: normal=3B =3D
>=3B >=3Bletter-spacing: normal=3B l= > >ine-height: normal=3B =3D
>=3B >=3B-webkit-text-decorations-in-effec= > >t: none=3B text-indent: 0px=3B =3D
>=3B >=3B-webkit-text-size-adjust= > >: auto=3B text-transform: none=3B orphans: 2=3B =3D
>=3B >=3Bwhite-s= > >pace: normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
= > >>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separ= > >ate=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webki= > >t-border-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont= > >-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-sp= > >an" style=3D3D"border-collapse: separate=3B =3D
>=3B >=3B-webkit-bor= > >der-horizontal-spacing: 0px=3B -webkit-border-vertical-spacing: =3D
>= > >=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-= > >size: 12px=3B =3D
>=3B >=3Bfont-style: normal=3B font-variant: norma= > >l=3B font-weight: normal=3B =3D
>=3B >=3Bletter-spacing: normal=3B l= > >ine-height: normal=3B =3D
>=3B >=3B-webkit-text-decorations-in-effec= > >t: none=3B text-indent: 0px=3B =3D
>=3B >=3B-webkit-text-size-adjust= > >: auto=3B text-transform: none=3B orphans: 2=3B =3D
>=3B >=3Bwhite-s= > >pace: normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
= > >>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separ= > >ate=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webki= > >t-border-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont= > >-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-sp= > >an" style=3D3D"border-collapse: separate=3B =3D
>=3B >=3B-webkit-bor= > >der-horizontal-spacing: 0px=3B -webkit-border-vertical-spacing: =3D
>= > >=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-= > >size: 12px=3B =3D
>=3B >=3Bfont-style: normal=3B font-variant: norma= > >l=3B font-weight: normal=3B =3D
>=3B >=3Bletter-spacing: normal=3B l= > >ine-height: normal=3B =3D
>=3B >=3B-webkit-text-decorations-in-effec= > >t: none=3B text-indent: 0px=3B =3D
>=3B >=3B-webkit-text-size-adjust= > >: auto=3B text-transform: none=3B orphans: 2=3B =3D
>=3B >=3Bwhite-s= > >pace: normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
= > >>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separ= > >ate=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webki= > >t-border-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont= > >-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bdiv>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D= > >"Apple-style-span" color=3D3D"#0000FF">=3B<=3Bfont =3D
>=3B >=3B= > >class=3D3D"Apple-style-span" face=3D3D"Gill Sans">=3B<=3Bspan =3D
&g= > >t=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255= > >)=3B font-family: =3D
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan clas= > >s=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C =3D
>=3B >=3B0= > >=2C 255)=3B font-family: 'Gill Sans'=3B ">=3BAntony =3D
>=3B >=3BH= > >osking<=3B/span>=3B<=3B/span>=3B<=3B/font>=3B<=3B/font>=3B&= > >lt=3Bfont class=3D3D"Apple-style-span" =3D
>=3B >=3Bface=3D3D"Gill S= > >ans">=3B<=3Bspan class=3D3D"Apple-style-span" style=3D3D"font-family: = > >=3D
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan class=3D3D"Apple-style= > >-span" style=3D3D"font-family: =3D
>=3B >=3B'Gill Sans'=3B ">=3B&l= > >t=3Bspan class=3D3D"Apple-converted-space">=3B&=3Bnbsp=3B<=3B/span&g= > >t=3B|<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-converted-space">=3B= > >&=3Bnbsp=3B<=3B/span>=3B<=3B/span>=3B<=3B/span>=3B<=3Bspan= > > =3D
>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"font-family: '= > >Gill Sans'=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-= > >span" style=3D3D"font-family: 'Gill Sans'=3B =3D
>=3B >=3B">=3BAss= > >ociate Professor<=3B/span>=3B<=3B/span>=3B<=3Bspan class=3D3D"App= > >le-style-span" =3D
>=3B >=3Bstyle=3D3D"font-family: 'Gill Sans'=3B "= > >>=3B<=3Bspan class=3D3D"Apple-style-span" =3D
>=3B >=3Bstyle=3D3= > >D"font-family: 'Gill Sans'=3B ">=3B&=3Bnbsp=3B| Computer Science | Pur= > >due =3D
>=3B >=3BUniversity<=3B/span>=3B<=3B/span>=3B<=3B/= > >font>=3B<=3B/div>=3B<=3Bdiv>=3B<=3Bfont class=3D3D"Apple-style-= > >span"=3D
>=3B >=3B face=3D3D"GillSans-Light">=3B<=3Bspan class= > >=3D3D"Apple-style-span" =3D
>=3B >=3Bstyle=3D3D"font-family: GillSan= > >s-Light=3B ">=3B305 N. University Street | West =3D
>=3B >=3BLafay= > >ette | IN 47907 | USA<=3B/span>=3B<=3B/font>=3B<=3B/div>=3B<= > >=3Bdiv>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" col= > >or=3D3D"#0000FF" face=3D3D"Gill Sans">=3B<=3Bspan =3D
>=3B >=3Bc= > >lass=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B font-fa= > >mily: =3D
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan class=3D3D"Apple= > >-style-span" style=3D3D"color: rgb(0=2C =3D
>=3B >=3B0=2C 255)=3B fo= > >nt-family: 'Gill Sans'=3B ">=3BOffice<=3B/span>=3B<=3B/span>=3B&l= > >t=3B/font>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" = > >face=3D3D"GillSans-Light">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Ap= > >ple-style-span" style=3D3D"font-family: GillSans-Light=3B ">=3B<=3Bspan= > > =3D
>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"font-family: G= > >illSans-Light=3B =3D
>=3B >=3B">=3B&=3Bnbsp=3B+1 765 494 6001 |= > ><=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-converted-space">=3B&= > >=3Bnbsp=3B<=3B/span>=3B<=3B/span>=3B<=3B/span>=3B<=3B/font>= > >=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" color=3D3D"#= > >0000FF" face=3D3D"Gill Sans">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D= > >"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B font-family: =3D= > >
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan class=3D3D"Apple-style-sp= > >an" style=3D3D"color: rgb(0=2C =3D
>=3B >=3B0=2C 255)=3B font-family= > >: 'Gill Sans'=3B ">=3BMobile<=3B/span>=3B<=3B/span>=3B<=3B/font= > >>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" face=3D3D= > >"GillSans-Light">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style= > >-span" style=3D3D"font-family: GillSans-Light=3B ">=3B<=3Bspan =3D
&= > >gt=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-L= > >ight=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-converted-sp= > >ace">=3B&=3Bnbsp=3B<=3B/span>=3B+1 765 427 =3D
>=3B >=3B548= > >4<=3B/span>=3B<=3B/span>=3B<=3B/font>=3B<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bfont class=3D3D"Apple-style-span" =3D
>=3B >=3Bface=3D= > >3D"GillSans-Light">=3B<=3Bbr =3D
>=3B >=3Bclass=3D3D"khtml-block= > >-placeholder">=3B<=3B/font>=3B<=3B/div>=3B<=3B/span>=3B<=3B= > >/span>=3B<=3B/span>=3B<=3B/span=3D
>=3B >=3B>=3B<=3B/spa= > >n>=3B<=3B/span>=3B<=3B/span>=3B<=3Bbr =3D
>=3B >=3Bclass= > >=3D3D"Apple-interchange-newline">=3B<=3B/span>=3B<=3B/div>=3B<= > >=3B/span>=3B<=3B/div>=3B<=3B/span>=3B<=3Bbr =3D
>=3B >= > >=3Bclass=3D3D"Apple-interchange-newline">=3B <=3B/div>=3B<=3Bbr>= > >=3B<=3Bdiv>=3B<=3Bdiv>=3BOn 6 Sep 2009=2C =3D
>=3B >=3Bat 23= > >:18=2C Jay K wrote:<=3B/div>=3B<=3Bbr =3D
>=3B >=3Bclass=3D3D"= > >Apple-interchange-newline">=3B<=3Bblockquote =3D
>=3B >=3Btype= > >=3D3D"cite">=3B<=3Bdiv>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B&= > >lt=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3B= > >br>=3B[was truncated =3D
>=3B >=3Bagain!]<=3Bbr>=3B<=3Bbr>= > >=3BPPC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes =3D
>=3B = > >>=3Bruns out of stack<=3B/div>=3B<=3B/blockquote>=3B<=3B/div>= > >=3B<=3Bbr>=3B<=3B/div>=3B<=3B/body>=3B<=3B/html>=3B=3D
&= > >gt=3B >=3B
>=3B >=3B--Apple-Mail-13--794937978--
> >= > > > >--_d2a2b05c-dd99-4149-b3de-8867976ffb79_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 13:17:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 11:17:48 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Can a semaphore be reasonably synthesized from working pthreads constructs? At least to try eliminating this variable? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 10:07:16 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) > What is different about Darwin? > Well obviously the same world suspend works. Can we use the portable way instead?? sem_init returns ENOSYS on Darwin, so no. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 16:09:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 10:09:25 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote: > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 16:44:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 10:44:23 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: <07AC4F22-8D60-4A08-AF4B-5B058B1FE72B@cs.purdue.edu> On 8 Sep 2009, at 04:50, Jay K wrote: > Hm. > - Making SameHost FALSE on Linux didn't induce hang. > - I'm seeing Juno often "hang" for a few seconds without displaying > anything, but I wait, and then it comes up fine. And then the next > run works ok. I see both behaviors often. This is with the stack > size code removed from ThreadPThreadC.c. I'll try restoring it too. > > What is different about Darwin? > Well obviously the same world suspend works. Can we use the portable > way instead?? > I realize the portable way probably isn't as good? This is not a problem with the stop-the-world mechanisms. They work fine. I've stress-tested them heavily and not seen a problem in a long time. My recent changes just made it clearer what was going on (and fixed the bug I introduced last week that you ended up backing out). If you look at the stack traces, no thread is in stop-the-world code. I have a sneaking recollection of needing to configure some property of my X server on Darwin, way back when. I've tried searching the old mail logs to see if I can dig up a reference but the Zope archives are no longer on Elegosoft.com. What to do? > > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other > problems) > Date: Tue, 8 Sep 2009 08:16:41 +0000 > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 16:47:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 10:47:18 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: It is not a problem with the thread stop-the-world suspension code. No thread is in that path at the time of the hang. They are all quietly waiting for something to happen. Clearly they've missed something. I have one thread that looks suspicious sitting inside a call to Formatter__Flush. Clearly the consumer hasn't responded so it is quietly waiting. More investigation needed. On 8 Sep 2009, at 07:17, Jay K wrote: > Can a semaphore be reasonably synthesized from working pthreads > constructs? > At least to try eliminating this variable? > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 8 Sep 2009 10:07:16 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > > What is different about Darwin? > > Well obviously the same world suspend works. Can we use the > portable way instead?? > > sem_init returns ENOSYS on Darwin, so no. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other > problems) > Date: Tue, 8 Sep 2009 08:16:41 +0000 > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 17:51:36 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 8 Sep 2009 08:51:36 -0700 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/ XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: > What did you change? I wonder... > > To get things to work on Darwin I used to have to do "xhosts +" and > set "DISPLAY=:0.0". Is this no longer the case? > > On 8 Sep 2009, at 04:16, Jay K wrote: > >> Here is a wild wild guess: >> One thing unusual to Trestle on Darwin, I think, is that it always >> appears that X client and X server are different machines. >> Well, er, um, that is how I changed it to be when it was otherwise >> always going to fail. >> How did it work previously? However it did work, if those >> conditions are still present, it still has a chance of working. >> >> Coincidentally or not, the formsedit crashes I have reported are >> all/mostly with a separate X client and server. >> >> I'll see if I can induce a hang in the otherwise working LINUXLIBC6 >> by twiddling with this. >> >> The specific change I made in Darwin was in the IsSameHost code. >> Where it would previously hit an unhandled exception, I have it >> return FALSE. >> I'm pretty sure that using XSharedMemory is "just" an optimization, >> albeit a very good one. >> >> I looked at little at what the Juno threads are doing..and it >> doesn't really have to do with gui code. >> libm3/"formatter" is a usual producer/consumer thingy, signal when >> queue is empty or nonempty. >> We /might/ be able to demonstrate this hang without any of Trestle >> in the picture. Might. >> >> I haven't looked at Mentor but it looks more complicated below. >> I'll also see if the Juno NT crashes are gone. >> And I'll raise the stack but stack overflow is just another wild >> guess, right? >> >> On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack >> overflow. >> I raised the stack piecemeal up to 32meg, still overflow. At 64meg >> it ran out of memory. >> >> - Jay >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 8 Sep 2009 02:09:28 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other >> problems) >> >> Here's the hang backtrace for mentor. Again, all appears normal, >> except that all the threads are paused or waiting, which is >> suspicious. I'm stumped for now. >> >> Thread 21 (process 96727 thread 0x7403): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, >> rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:668 >> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:685 >> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) >> at ../src/xvbt/XClientF.m3:105 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 20 (process 96727 thread 0x7103): >> #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:319 >> #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, >> M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') >> at ../src/thread/PTHREAD/ThreadPThread.m3:669 >> #2 0x01020024 in Thread__AlertPause >> (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:699 >> #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, >> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) >> at ../src/Animate.m3:71 >> #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, >> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >> #5 0x008921f9 in GraphVBT__AnimateGraph >> (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../ >> src/GraphVBT.m3:656 >> #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, >> M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) >> at ../src/bresenham/ViewError.m3:548 >> #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, >> M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 >> #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ >> src/Zeus.m3:331 >> #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #10 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #11 0x96373155 in _pthread_start () >> #12 0x96373012 in thread_start () >> >> Thread 19 (process 96727 thread 0x5d07): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, >> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >> M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, >> M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ >> src/Zeus.m3:328 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 18 (process 96727 thread 0x700b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, >> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >> M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, >> M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ >> src/Zeus.m3:328 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 17 (process 96727 thread 0x6e03): >> #0 0x963493dc in _pthread_testcancel () >> #1 0x96349275 in nanosleep$UNIX2003 () >> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, >> rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, >> M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >> PTHREAD/ThreadPThread.m3:668 >> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:685 >> #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ >> src/vtext/VTCaret.m3:149 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 16 (process 96727 thread 0x435b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, >> M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, >> M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) >> at ../src/ZeusPanel.m3:1425 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 15 (process 96727 thread 0x420b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) >> at ../src/View.m3:74 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 14 (process 96727 thread 0x4103): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) >> at ../src/View.m3:74 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 13 (process 96727 thread 0x4003): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) >> at ../src/View.m3:74 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 12 (process 96727 thread 0x2e03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, >> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >> M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) >> at ../src/xvbt/XMessenger.m3:69 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 11 (process 96727 thread 0x2b07): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, >> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >> M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) >> at ../src/xvbt/XInput.m3:102 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 10 (process 96727 thread 0x2a23): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, >> writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/ >> unix/Common/UnixC.c:301 >> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:787 >> #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >> M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >> PTHREAD/ThreadPThread.m3:826 >> #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=> type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ >> src/thread/PTHREAD/ThreadPThread.m3:729 >> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) >> at ../src/xvbt/XInput.m3:63 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 9 (process 96727 thread 0x29f3): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, >> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, >> M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, >> M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 >> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, >> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 >> #7 0x000149a7 in BresenhamIE__ShowPixel >> (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, >> M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 >> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, >> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >> at ../src/bresenham/AlgBresenham.m3:55 >> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ >> src/bresenham/AlgBresenham.m3:86 >> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) >> at ../src/ZeusPanel.m3:1534 >> #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #12 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 8 (process 96727 thread 0x2803): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, >> M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, >> M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >> src/formatter/Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, >> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >> formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) >> at ../src/formatter/Formatter.m3:615 >> #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #12 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 7 (process 96727 thread 0x2703): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, >> M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, >> M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >> src/formatter/Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, >> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >> formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) >> at ../src/formatter/Formatter.m3:615 >> #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #12 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 6 (process 96727 thread 0x2603): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, >> M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, >> M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x0073de32 in WorkerPool__ClericApply >> (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 5 (process 96727 thread 0x2313): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, >> writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ >> src/unix/Common/UnixC.c:301 >> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ >> src/thread/PTHREAD/ThreadPThread.m3:787 >> #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 >> #4 0x010202e7 in SchedulerPosix__IOAlertWait >> (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >> M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:742 >> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, >> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ >> POSIX/TCP.m3:234 >> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >> (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 >> #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #9 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #10 0x96373155 in _pthread_start () >> #11 0x96373012 in thread_start () >> >> Thread 4 (process 96727 thread 0x2003): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, >> rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:668 >> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:685 >> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) >> at ../src/lego/FileBrowserVBT.m3:259 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 3 (process 96727 thread 0x1f03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, >> M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, >> M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00a839e2 in VTView__VFontCleanUpThread >> (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 2 (process 96727 thread 0xd07): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, >> M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, >> M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) >> at ../src/vbt/VBTRep.m3:439 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 1 (process 96727 thread 0x10b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >> M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 >> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >> #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) >> at ../src/runtime/common/RTLinker.m3:399 >> #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) >> at _m3main.mc:6 >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 6 Sep 2009, at 23:18, Jay K wrote: >> >> >> >> >> >> >> >> >> >> >> [was truncated again!] >> >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of >> stack >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 18:03:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 12:03:05 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> Message-ID: <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote: > That works? $Display gets set to something random looking by > default, an actual file, I don't change it. If what you do works my > change probably does not affect. See the function SameHost in m3-ui/ > ui/xvbt/XSharedMemory.i3. I added the code to predict if the network > stuff will succeed or fail since for me it always failed and was > fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. > > - Jay (phone) > > On Sep 8, 2009, at 7:09 AM, Tony Hosking > wrote: > >> What did you change? I wonder... >> >> To get things to work on Darwin I used to have to do "xhosts +" and >> set "DISPLAY=:0.0". Is this no longer the case? >> >> On 8 Sep 2009, at 04:16, Jay K wrote: >> >>> Here is a wild wild guess: >>> One thing unusual to Trestle on Darwin, I think, is that it >>> always appears that X client and X server are different machines. >>> Well, er, um, that is how I changed it to be when it was >>> otherwise always going to fail. >>> How did it work previously? However it did work, if those >>> conditions are still present, it still has a chance of working. >>> >>> Coincidentally or not, the formsedit crashes I have reported are >>> all/mostly with a separate X client and server. >>> >>> I'll see if I can induce a hang in the otherwise working >>> LINUXLIBC6 by twiddling with this. >>> >>> The specific change I made in Darwin was in the IsSameHost code. >>> Where it would previously hit an unhandled exception, I have it >>> return FALSE. >>> I'm pretty sure that using XSharedMemory is "just" an >>> optimization, albeit a very good one. >>> >>> I looked at little at what the Juno threads are doing..and it >>> doesn't really have to do with gui code. >>> libm3/"formatter" is a usual producer/consumer thingy, signal when >>> queue is empty or nonempty. >>> We /might/ be able to demonstrate this hang without any of Trestle >>> in the picture. Might. >>> >>> I haven't looked at Mentor but it looks more complicated below. >>> I'll also see if the Juno NT crashes are gone. >>> And I'll raise the stack but stack overflow is just another wild >>> guess, right? >>> >>> On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack >>> overflow. >>> I raised the stack piecemeal up to 32meg, still overflow. At 64meg >>> it ran out of memory. >>> >>> - Jay >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 8 Sep 2009 02:09:28 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other >>> problems) >>> >>> Here's the hang backtrace for mentor. Again, all appears normal, >>> except that all the threads are paused or waiting, which is >>> suspicious. I'm stumped for now. >>> >>> Thread 21 (process 96727 thread 0x7403): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, >>> rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:668 >>> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:685 >>> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) >>> at ../src/xvbt/XClientF.m3:105 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 20 (process 96727 thread 0x7103): >>> #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:319 >>> #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, >>> M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') >>> at ../src/thread/PTHREAD/ThreadPThread.m3:669 >>> #2 0x01020024 in Thread__AlertPause >>> (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:699 >>> #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, >>> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) >>> at ../src/Animate.m3:71 >>> #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, >>> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >>> #5 0x008921f9 in GraphVBT__AnimateGraph >>> (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../ >>> src/GraphVBT.m3:656 >>> #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, >>> M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) >>> at ../src/bresenham/ViewError.m3:548 >>> #7 0x0001529a in BresenhamIE__OEDispatcher >>> (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/ >>> BresenhamIE.m3:101 >>> #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) >>> at ../src/Zeus.m3:331 >>> #9 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #10 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #11 0x96373155 in _pthread_start () >>> #12 0x96373012 in thread_start () >>> >>> Thread 19 (process 96727 thread 0x5d07): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, >>> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >>> M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep >>> (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/ >>> Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) >>> at ../src/Zeus.m3:328 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 18 (process 96727 thread 0x700b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, >>> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >>> M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep >>> (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/ >>> Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) >>> at ../src/Zeus.m3:328 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 17 (process 96727 thread 0x6e03): >>> #0 0x963493dc in _pthread_testcancel () >>> #1 0x96349275 in nanosleep$UNIX2003 () >>> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, >>> rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, >>> M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:668 >>> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:685 >>> #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ >>> src/vtext/VTCaret.m3:149 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 16 (process 96727 thread 0x435b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, >>> M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, >>> M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) >>> at ../src/ZeusPanel.m3:1425 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 15 (process 96727 thread 0x420b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) >>> at ../src/View.m3:74 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 14 (process 96727 thread 0x4103): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) >>> at ../src/View.m3:74 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 13 (process 96727 thread 0x4003): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) >>> at ../src/View.m3:74 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 12 (process 96727 thread 0x2e03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, >>> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >>> M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) >>> at ../src/xvbt/XMessenger.m3:69 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 11 (process 96727 thread 0x2b07): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, >>> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >>> M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) >>> at ../src/xvbt/XInput.m3:102 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 10 (process 96727 thread 0x2a23): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, >>> writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/ >>> unix/Common/UnixC.c:301 >>> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:787 >>> #3 0x010206cc in ThreadPThread__XIOWait >>> (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:826 >>> #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=>> type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:729 >>> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) >>> at ../src/xvbt/XInput.m3:63 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 9 (process 96727 thread 0x29f3): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, >>> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, >>> M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, >>> M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 >>> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, >>> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >>> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 >>> #7 0x000149a7 in BresenhamIE__ShowPixel >>> (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, >>> M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/ >>> BresenhamIE.m3:227 >>> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, >>> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >>> at ../src/bresenham/AlgBresenham.m3:55 >>> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) >>> at ../src/bresenham/AlgBresenham.m3:86 >>> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) >>> at ../src/ZeusPanel.m3:1534 >>> #11 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #12 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 8 (process 96727 thread 0x2803): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, >>> M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, >>> M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >>> src/formatter/Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, >>> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >>> formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #12 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 7 (process 96727 thread 0x2703): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, >>> M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, >>> M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >>> src/formatter/Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, >>> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >>> formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #12 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 6 (process 96727 thread 0x2603): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, >>> M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, >>> M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x0073de32 in WorkerPool__ClericApply >>> (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 5 (process 96727 thread 0x2313): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, >>> writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ >>> src/unix/Common/UnixC.c:301 >>> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ >>> src/thread/PTHREAD/ThreadPThread.m3:787 >>> #3 0x010206a8 in ThreadPThread__XIOWait >>> (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e >>> +308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:823 >>> #4 0x010202e7 in SchedulerPosix__IOAlertWait >>> (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >>> M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:742 >>> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, >>> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >>> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ >>> POSIX/TCP.m3:234 >>> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >>> (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 >>> #8 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #9 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #10 0x96373155 in _pthread_start () >>> #11 0x96373012 in thread_start () >>> >>> Thread 4 (process 96727 thread 0x2003): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, >>> rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:668 >>> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:685 >>> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) >>> at ../src/lego/FileBrowserVBT.m3:259 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 3 (process 96727 thread 0x1f03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, >>> M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, >>> M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00a839e2 in VTView__VFontCleanUpThread >>> (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 2 (process 96727 thread 0xd07): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, >>> M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, >>> M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) >>> at ../src/vbt/VBTRep.m3:439 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 1 (process 96727 thread 0x10b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >>> M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 >>> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >>> #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) >>> at ../src/runtime/common/RTLinker.m3:399 >>> #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) >>> at _m3main.mc:6 >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 6 Sep 2009, at 23:18, Jay K wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [was truncated again!] >>> >>> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out >>> of stack >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 18:05:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 16:05:48 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: Ok I tried Display=:0.0 and xhost +, it works, same hang. You don't actually have to do that though, at least on 10.5. DISPLAY is set to some magic and X is started up on-demand as needed. Except for that SameHost problem.. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 12:03:05 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote:That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote:Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 18:09:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 16:09:21 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO self.waitCond should be c or self.waitingOn maybe?? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 16:05:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Ok I tried Display=:0.0 and xhost +, it works, same hang. You don't actually have to do that though, at least on 10.5. DISPLAY is set to some magic and X is started up on-demand as needed. Except for that SameHost problem.. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 12:03:05 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote:That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote:Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 18:11:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 12:11:23 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: Nope. I think we need to be more careful about the mutex. Considering the options right now... On 8 Sep 2009, at 12:09, Jay K wrote: > WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO > > > self.waitCond should be c or self.waitingOn maybe?? > > - Jay > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 8 Sep 2009 16:05:48 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Ok I tried Display=:0.0 and xhost +, it works, same hang. > You don't actually have to do that though, at least on 10.5. > DISPLAY is set to some magic and X is started up on-demand as needed. > Except for that SameHost problem.. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 12:03:05 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote: > > That works? $Display gets set to something random looking by > default, an actual file, I don't change it. If what you do works my > change probably does not affect. See the function SameHost in m3-ui/ > ui/xvbt/XSharedMemory.i3. I added the code to predict if the network > stuff will succeed or fail since for me it always failed and was > fatal. > > Yes, it works for me. > > PS I think I have found the problem: a thread not waking from a call > to wait, even though its condition has been signalled. A > longstanding bug inside XWait I think... Sigh. > > > - Jay (phone) > > On Sep 8, 2009, at 7:09 AM, Tony Hosking > wrote: > > What did you change? I wonder... > > To get things to work on Darwin I used to have to do "xhosts +" and > set "DISPLAY=:0.0". Is this no longer the case? > > On 8 Sep 2009, at 04:16, Jay K wrote: > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 18:13:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 16:13:36 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: er..I don't get the waitCond vs. waitingOn. Have to study it more or just wait for your fix. Maybe they are meant to be the same??? I don't know. (To be clear, with this level of uncertainty, I'm certainly not changing it.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 16:09:21 +0000 WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO self.waitCond should be c or self.waitingOn maybe?? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 16:05:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Ok I tried Display=:0.0 and xhost +, it works, same hang. You don't actually have to do that though, at least on 10.5. DISPLAY is set to some magic and X is started up on-demand as needed. Except for that SameHost problem.. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 12:03:05 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote:That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote:Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 18:23:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 12:23:56 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: <034E072F-DFA2-43D5-A925-A60FABF60169@cs.purdue.edu> Every thread has a waitCond, which is where we park it when it waits on a condition variable. To alert a thread we can simply signal its waitCond. This avoids having to broadcast on all of the threads waiting on a condition just to get the alerted one to notice. waitingOn is the M3 CV that it is waiting on, which is where the condition wait queue resides. On 8 Sep 2009, at 12:13, Jay K wrote: > er..I don't get the waitCond vs. waitingOn. Have to study it more or > just wait for your fix. > Maybe they are meant to be the same??? I don't know. > (To be clear, with this level of uncertainty, I'm certainly not > changing it.) > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other > problems) > Date: Tue, 8 Sep 2009 16:09:21 +0000 > > WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO > > > self.waitCond should be c or self.waitingOn maybe?? > > - Jay > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 8 Sep 2009 16:05:48 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Ok I tried Display=:0.0 and xhost +, it works, same hang. > You don't actually have to do that though, at least on 10.5. > DISPLAY is set to some magic and X is started up on-demand as needed. > Except for that SameHost problem.. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 12:03:05 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote: > > That works? $Display gets set to something random looking by > default, an actual file, I don't change it. If what you do works my > change probably does not affect. See the function SameHost in m3-ui/ > ui/xvbt/XSharedMemory.i3. I added the code to predict if the network > stuff will succeed or fail since for me it always failed and was > fatal. > > Yes, it works for me. > > PS I think I have found the problem: a thread not waking from a call > to wait, even though its condition has been signalled. A > longstanding bug inside XWait I think... Sigh. > > > - Jay (phone) > > On Sep 8, 2009, at 7:09 AM, Tony Hosking > wrote: > > What did you change? I wonder... > > To get things to work on Darwin I used to have to do "xhosts +" and > set "DISPLAY=:0.0". Is this no longer the case? > > On 8 Sep 2009, at 04:16, Jay K wrote: > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Wed Sep 9 22:12:57 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 09 Sep 2009 15:12:57 -0500 Subject: [M3devel] Modula-3 page that's actually up to date Message-ID: <4AA80C49.4040006@esoteriq.org> I just found this website: http://www.eiserloh.org/~peter/modula3/ and was amazed to see it's up to date. Nice little collection of links there. From mbishop at esoteriq.org Wed Sep 9 22:19:32 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 09 Sep 2009 15:19:32 -0500 Subject: [M3devel] Quake problem installing packages Message-ID: <4AA80DD4.3060209@esoteriq.org> Installing some of the packages (Math, some of m3devtools and devlib so far) result in this error: quake runtime error: undefined variable: symbolic_link_file Always the same problem, "undefined variable: symbolic_link_file" in .M3SHIP From mbishop at esoteriq.org Wed Sep 9 22:39:40 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 09 Sep 2009 15:39:40 -0500 Subject: [M3devel] Quake problem installing packages In-Reply-To: <4AA80DD4.3060209@esoteriq.org> References: <4AA80DD4.3060209@esoteriq.org> Message-ID: <4AA8128C.1040403@esoteriq.org> Sorry, diregard this, somehow my system is still using an old CM3 instead of 5.8. Sorry. Martin Bishop wrote: > Installing some of the packages (Math, some of m3devtools and devlib > so far) result in > this error: > > > quake runtime error: undefined variable: symbolic_link_file > > > Always the same problem, "undefined variable: symbolic_link_file" in > .M3SHIP > > From hosking at cs.purdue.edu Fri Sep 11 15:45:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Message-ID: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 16:24:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 14:24:06 +0000 Subject: [M3devel] RC merge In-Reply-To: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Fri Sep 11 18:14:07 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 11 Sep 2009 18:14:07 +0200 Subject: [M3devel] elego Maintenance 12.09 Message-ID: <20090911181407.vk17th56tc4c4k4s@mail.elego.de> Hello, On Saturday, Sept. 12 from 10 AM to 4 PM CEST, we will be performing maintenance at our Gustav-Meyer-Allee site. Among other planned procedures, a UPS battery replacement will require taking the following servers completely off line for approximately one hour: -new.elego.de -old.elego.de -fedora.elego.de -bdc1.elego.de -willow.elego.de -pine.elego.de The ESXi server madrona and its hosts will not be affected by this. The elego lan will be unreachable during the battery replacement and subsequent disruptions of some services should be expected until maintenance procedures are completed in the late afternoon. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Sep 11 18:46:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 12:46:19 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote: > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 22:05:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 20:05:52 +0000 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 11 22:43:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 16:43:29 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: <49A3CCD1-581E-46F9-B6EF-0F3FE2B581EC@cs.purdue.edu> On 11 Sep 2009, at 16:05, Jay K wrote: > Tony I'll double check if I see the hang. NT386 still crashes. That's ThreadWin32 right? > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 11 22:51:11 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 16:51:11 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote: > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 11 23:05:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 17:05:57 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4AAA8078.1E75.00D7.1@scires.com> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> Message-ID: <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:28:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:28:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> Message-ID: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:30:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:30:22 +0000 Subject: [M3devel] RC merge In-Reply-To: <49A3CCD1-581E-46F9-B6EF-0F3FE2B581EC@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <49A3CCD1-581E-46F9-B6EF-0F3FE2B581EC@cs.purdue.edu> Message-ID: Correct ThreadWin32 not ThreadPThread or ThreadPosix. I narrowed the problem down to a 30 minute window in Februrary (see older mail). I'll try again with recent changes (esp. if they are in common code, which I don't think they are) - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:43:29 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge On 11 Sep 2009, at 16:05, Jay K wrote:Tony I'll double check if I see the hang. NT386 still crashes. That's ThreadWin32 right? http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:33:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:33:32 +0000 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: ps: I think there's another funny thing here: I think you can have: INTERFACE FooInterface; PROCEDURE SafeFunction(); PROCEDURE UnsafeFunction()=ADDRESS; END FooInterface. Despite being in a safe interface, UnsafeFunction either can't be called from safe code, or at least its return value can't be used? Or at least can't be done anything with but compare to NIL? I think. Therefore this interface could be said to be "partially unsafe". Perhaps not a useful middle ground though. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] RC merge Date: Fri, 11 Sep 2009 21:26:00 +0000 Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be. I propose a few options: 1 - asis, probably not 2 - rename/merge ThreadUnsafe to ThreadInternal 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too 2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal 3 maybe gratuitously breaks folks but is a clean result 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:51:11 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote:Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:26:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:26:00 +0000 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be. I propose a few options: 1 - asis, probably not 2 - rename/merge ThreadUnsafe to ThreadInternal 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too 2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal 3 maybe gratuitously breaks folks but is a clean result 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:51:11 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote:Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Sat Sep 12 02:58:04 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 11 Sep 2009 19:58:04 -0500 Subject: [M3devel] Dual Pivot Quicksort problem Message-ID: <4AAAF21C.5030209@esoteriq.org> I saw a post on reddit about a Dual Pivot Quicksort, and I translated the code from Java to Modula-3. I have it all translated, and it builds, but I am having boundary issues. Somewhere on the second pass, the variable m2 is getting the value -2. Here's the code: MODULE DualPivot; IMPORT Insertion, Fmt; PROCEDURE Sort(VAR arr: ARRAY OF INTEGER) = BEGIN SortFromTo(arr, 0, NUMBER(arr)); END Sort; PROCEDURE SortFromTo(VAR arr: ARRAY OF INTEGER; from, to: INTEGER) = BEGIN RangeCheck(NUMBER(arr), from, to); DualPivotSort(arr, from, to - 1, 3); END SortFromTo; PROCEDURE RangeCheck(len, from, to: INTEGER) RAISES {BadArgument, IndexOutOfRange} = BEGIN IF from > to THEN RAISE BadArgument(Fmt.Int(from) & " > " & Fmt.Int(to) & "\n"); END; IF from < 0 THEN RAISE IndexOutOfRange("from"); END; IF to > len THEN RAISE IndexOutOfRange("to"); END; END RangeCheck; PROCEDURE Swap(VAR arr: ARRAY OF INTEGER; i, j: INTEGER) = VAR temp := arr[i]; BEGIN arr[i] := arr[j]; arr[j] := temp; END Swap; PROCEDURE DualPivotSort(VAR arr: ARRAY OF INTEGER; left, right, div: INTEGER) = VAR len := left - right; third := len DIV div; m1 := left + third; m2 := right - third; piv1: INTEGER; piv2: INTEGER; less := left + 1; great := right - 1; dist: INTEGER; BEGIN IF len < 27 THEN Insertion.Sort(arr); END; IF m1 <= left THEN m1 := left + 1; END; IF m2 >= right THEN m2 := right - 1; END; IF arr[m1] < arr[m2] THEN Swap(arr, m1, left); Swap(arr, m2, right); ELSE Swap(arr, m1, right); Swap(arr, m2, left); END; piv1 := arr[left]; piv2 := arr[right]; FOR k := less TO great DO IF arr[k] < piv1 THEN Swap(arr, k, less + 1); ELSIF arr[k] > piv2 THEN WHILE (k < great) AND (arr[great] > piv2) DO DEC(great); END; Swap(arr, k, great - 1); IF arr[k] < piv1 THEN Swap(arr, k, less + 1); END; END; END; dist := great - less; IF dist < 13 THEN INC(div); END; Swap(arr, less - 1, left); Swap(arr, great + 1, right); DualPivotSort(arr, left, less - 2, div); DualPivotSort(arr, great + 2, right, div); IF (dist > len - 13) AND (piv1 # piv2) THEN FOR k := less TO great DO IF arr[k] = piv1 THEN Swap(arr, k, less + 1); ELSIF arr[k] = piv2 THEN Swap(arr, k, great - 1); IF arr[k] = piv1 THEN Swap(arr, k, less + 1); END; END; END; END; IF piv1 < piv2 THEN DualPivotSort(arr, less, great, div); END; END DualPivotSort; BEGIN END DualPivot. Right now when I try to run I get: *** *** runtime error: *** An array subscript was out of range. *** file "../DualPivot.m3", line 61 *** Line 61 is: IF arr[m1] < arr[m2] THEN Anyone see what is happening? It's probably off by 1 (or more) errors, but I don't see them. From hosking at cs.purdue.edu Sat Sep 12 04:19:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 22:19:49 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> Yes, that was exactly my intention. I wasn't quite sure what your problem was with the code I had returning ADDRESS, but was willing to accede. It is "safe", but you can't use the result unless in UNSAFE code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 17:33, Jay K wrote: > ps: I think there's another funny thing here: > I think you can have: > > INTERFACE FooInterface; > > PROCEDURE SafeFunction(); > PROCEDURE UnsafeFunction()=ADDRESS; > > END FooInterface. > > Despite being in a safe interface, UnsafeFunction either can't be > called > from safe code, or at least its return value can't be used? Or at > least > can't be done anything with but compare to NIL? > I think. > Therefore this interface could be said to be "partially unsafe". > > Perhaps not a useful middle ground though. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC merge > Date: Fri, 11 Sep 2009 21:26:00 +0000 > > Yes and no. I agree I made a small mess. I'm not sure you have quite > described how it should be. > > I propose a few options: > 1 - asis, probably not > 2 - rename/merge ThreadUnsafe to ThreadInternal > 3 - move the part that external folks use, probably just MyId, to > Thread, and then move ThreadUnsafe back to ThreadF, maybe > ThreadInternal to ThreadF too > > 2 at least removes one interface that I added, reducing the three > similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF > and ThreadInternal > > 3 maybe gratuitously breaks folks but is a clean result > > 4 - like you said, make all ThreadF users unsafe; but IF it is just > MyId, and I'm not sure it is, which seems harmless, right? seems > wrong to make them unsafe. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 16:51:11 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Sorry, it looks like my commit failed last night because of need to > merge with your ThreadUnsafe stuff. > > FYI, we really should think about making ThreadF UNSAFE since anyone > invoking on it is exposed to dangerous parts of the run-time > system. Is there any need for it really to be safe? > > On 11 Sep 2009, at 16:05, Jay K wrote: > > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 04:20:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 22:20:57 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: I propose leave ThreadF safe, and revert back to MyHeapState:ADDRESS in ThreadF. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 17:26, Jay K wrote: > Yes and no. I agree I made a small mess. I'm not sure you have quite > described how it should be. > > I propose a few options: > 1 - asis, probably not > 2 - rename/merge ThreadUnsafe to ThreadInternal > 3 - move the part that external folks use, probably just MyId, to > Thread, and then move ThreadUnsafe back to ThreadF, maybe > ThreadInternal to ThreadF too > > 2 at least removes one interface that I added, reducing the three > similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF > and ThreadInternal > > 3 maybe gratuitously breaks folks but is a clean result > > 4 - like you said, make all ThreadF users unsafe; but IF it is just > MyId, and I'm not sure it is, which seems harmless, right? seems > wrong to make them unsafe. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 16:51:11 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Sorry, it looks like my commit failed last night because of need to > merge with your ThreadUnsafe stuff. > > FYI, we really should think about making ThreadF UNSAFE since anyone > invoking on it is exposed to dangerous parts of the run-time > system. Is there any need for it really to be safe? > > On 11 Sep 2009, at 16:05, Jay K wrote: > > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 04:21:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 22:21:44 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> Message-ID: <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: > They aren't really in Trestle or ThreadWin32. > Well, right, often they are in ThreadWin32. > But not always. > I think it is, like, classic heap/stack corruption, via non-classic > "locking not working" and gc moving stuff when it shouldn't. > I don't have good evidence, but it usually NOT a hang/deadlock or > assertion failure, it is usually an access violation (aka SEGSIGV) > which as I understand must be the result of bugs in unsafe code. > > I did narrow it down a 30 minute window. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Fri, 11 Sep 2009 17:05:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I have my suspicions that ThreadWin32 may have similar latent bugs > in synchronization similar to those I have recently shaken out of > the pthreads implementation. The good thing is that my > implementation there is based in part on ThreadWin32, so it can't be > too far off. It is inevitable with concurrent code that you will > get different behavior at each run. The easiest things to debug are > thread lockups, which can usually be diagnosed by staring at dumps > of all the thread state. Harder is actual crashes like you are > observing. If assertions can be used to monitor program invariants > then it usually can be narrowed down. Unfortunately, I am not in a > position to debug the ThreadWin32 code. Any help would be > appreciated. The question is whether the crashes you see are in > Trestle or ThreadWin32. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 12 05:37:44 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 11 Sep 2009 20:37:44 -0700 Subject: [M3devel] RC merge In-Reply-To: <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> Message-ID: <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> I don't like the caller to have to cast. - Jay (phone) On Sep 11, 2009, at 7:19 PM, Tony Hosking wrote: > Yes, that was exactly my intention. I wasn't quite sure what your > problem was with the code I had returning ADDRESS, but was willing > to accede. It is "safe", but you can't use the result unless in > UNSAFE code. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 17:33, Jay K wrote: > >> ps: I think there's another funny thing here: >> I think you can have: >> >> INTERFACE FooInterface; >> >> PROCEDURE SafeFunction(); >> PROCEDURE UnsafeFunction()=ADDRESS; >> >> END FooInterface. >> >> Despite being in a safe interface, UnsafeFunction either can't be >> called >> from safe code, or at least its return value can't be used? Or at >> least >> can't be done anything with but compare to NIL? >> I think. >> Therefore this interface could be said to be "partially unsafe". >> >> Perhaps not a useful middle ground though. >> >> - Jay >> >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC merge >> Date: Fri, 11 Sep 2009 21:26:00 +0000 >> >> Yes and no. I agree I made a small mess. I'm not sure you have >> quite described how it should be. >> >> I propose a few options: >> 1 - asis, probably not >> 2 - rename/merge ThreadUnsafe to ThreadInternal >> 3 - move the part that external folks use, probably just MyId, to >> Thread, and then move ThreadUnsafe back to ThreadF, maybe >> ThreadInternal to ThreadF too >> >> 2 at least removes one interface that I added, reducing the three >> similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF >> and ThreadInternal >> >> 3 maybe gratuitously breaks folks but is a clean result >> >> 4 - like you said, make all ThreadF users unsafe; but IF it is >> just MyId, and I'm not sure it is, which seems harmless, right? >> seems wrong to make them unsafe. >> >> - Jay >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Fri, 11 Sep 2009 16:51:11 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] RC merge >> >> Sorry, it looks like my commit failed last night because of need to >> merge with your ThreadUnsafe stuff. >> >> FYI, we really should think about making ThreadF UNSAFE since >> anyone invoking on it is exposed to dangerous parts of the run-time >> system. Is there any need for it really to be safe? >> >> On 11 Sep 2009, at 16:05, Jay K wrote: >> >> Tony I'll double check if I see the hang. NT386 still crashes. >> >> http://www.modula3.com/cm3/ChangeLog-2009 >> >> " >> 2009-09-08 05:54 hosking >> >> * m3-libs/m3core/src/: convert/CConvert.m3, >> runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, >> runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, >> runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, >> runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, >> runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, >> runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, >> thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, >> thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, >> thread/WIN32/ThreadWin32.m3: >> >> Tidy up use of thread.inCritical to only occur in allocation >> sequences and in >> thread stoppage. This simplifies reasoning. Refactored use of >> heap lock >> in the process. This may be better implemented on PTHREAD >> targets using a >> recursive pthread mutex instead of one we roll ourselves from a >> non-recursive >> mutex. >> >> Still witnessing random hangs in Juno and mentor on I386_DARWIN. >> Strange, I thought this was working previously. >> I wonder if there is some sort of race in the GUI code somewhere? >> " >> >> ?? >> - Jay >> >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Fri, 11 Sep 2009 12:46:19 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] RC merge >> >> No, the hangs in Juno and mentor are no longer there. I cannot >> reproduce them on I386_DARWIN. >> >> On 11 Sep 2009, at 10:24, Jay K wrote: >> >> But the hangs are still present, right? Worth merging without that >> fixed? >> >> How does one do it easily? >> I wish we used Perforce. :( >> >> - Jay >> >> >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Fri, 11 Sep 2009 09:45:23 -0400 >> Subject: [M3devel] RC merge >> >> Can someone merge my recent deep fixes to pthreads threading over >> to the release branch? I won't get a chance to do so until next >> Monday at the earliest. >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Sat Sep 12 06:01:05 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 11 Sep 2009 23:01:05 -0500 Subject: [M3devel] Dual Pivot Quicksort problem In-Reply-To: <4AAAF21C.5030209@esoteriq.org> References: <4AAAF21C.5030209@esoteriq.org> Message-ID: <4AAB1D01.3020403@esoteriq.org> Edited it some more, lots of silly mistakes in that old code. Now it almost works...it sorts the array sometimes, but other times gives me a bounds error. Any idea now? MODULE DualPivot; IMPORT Insertion, Fmt, IO; PROCEDURE Sort(VAR arr: ARRAY OF INTEGER) = BEGIN SortFromTo(arr, 0, NUMBER(arr)); END Sort; PROCEDURE SortFromTo(VAR arr: ARRAY OF INTEGER; from, to: INTEGER) = BEGIN RangeCheck(NUMBER(arr), from, to); DualPivotSort(arr, from, to - 1, 3); END SortFromTo; PROCEDURE RangeCheck(len, from, to: INTEGER) RAISES {BadArgument, IndexOutOfRange} = BEGIN IF from > to THEN RAISE BadArgument(Fmt.Int(from) & " > " & Fmt.Int(to) & "\n"); END; IF from < 0 THEN RAISE IndexOutOfRange("from"); END; IF to > len THEN RAISE IndexOutOfRange("to"); END; END RangeCheck; PROCEDURE Swap(VAR arr: ARRAY OF INTEGER; i, j: INTEGER) = VAR temp := arr[i]; BEGIN arr[i] := arr[j]; arr[j] := temp; END Swap; PROCEDURE DualPivotSort(VAR arr: ARRAY OF INTEGER; left, right, div: INTEGER) = VAR len := right - left; third := len DIV div; m1 := left + third; m2 := right - third; piv1: INTEGER; piv2: INTEGER; less := left + 1; great := right - 1; dist: INTEGER; BEGIN IF len < 27 THEN Insertion.Sort(arr); RETURN; END; IF m1 <= left THEN m1 := left + 1; END; IF m2 >= right THEN m2 := right - 1; END; IO.Put("DEBUG: m1 = " & Fmt.Int(m1) & " m2 = " & Fmt.Int(m2) & " left = " & Fmt.Int(left) & " right = " & Fmt.Int(right) & "\n"); IO.Put("DEBUG: len = " & Fmt.Int(len) & " third = " & Fmt.Int(third) & "\n"); IO.Put("***\n"); IF arr[m1] < arr[m2] THEN Swap(arr, m1, left); Swap(arr, m2, right); ELSE Swap(arr, m1, right); Swap(arr, m2, left); END; piv1 := arr[left]; piv2 := arr[right]; FOR k := less TO great DO IF arr[k] < piv1 THEN Swap(arr, k, less); INC(less); ELSIF arr[k] > piv2 THEN WHILE (k < great) AND (arr[great] > piv2) DO DEC(great); END; Swap(arr, k, great); DEC(great); IF arr[k] < piv1 THEN Swap(arr, k, less); INC(less); END; END; END; dist := great - less; IF dist < 13 THEN INC(div); END; Swap(arr, less - 1, left); Swap(arr, great + 1, right); DualPivotSort(arr, left, less - 2, div); DualPivotSort(arr, great + 2, right, div); IF (dist > len - 13) AND (piv1 # piv2) THEN FOR k := less TO great DO IF arr[k] = piv1 THEN Swap(arr, k, less); INC(less); ELSIF arr[k] = piv2 THEN Swap(arr, k, great); DEC(great); IF arr[k] = piv1 THEN Swap(arr, k, less); INC(less); END; END; END; END; IF piv1 < piv2 THEN DualPivotSort(arr, less, great, div); END; END DualPivotSort; BEGIN END DualPivot. Martin Bishop wrote: > I saw a post on reddit about a Dual Pivot Quicksort, and I translated > the code from Java to Modula-3. I have it all translated, and it > builds, but I am having boundary issues. Somewhere on the second > pass, the variable m2 is getting the value -2. Here's the code: > > ... > Right now when I try to run I get: > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../DualPivot.m3", line 61 > *** > > Line 61 is: IF arr[m1] < arr[m2] THEN > > Anyone see what is happening? It's probably off by 1 (or more) errors, > but I don't see them. > > From mbishop at esoteriq.org Sat Sep 12 06:12:17 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 11 Sep 2009 23:12:17 -0500 Subject: [M3devel] Dual Pivot Quicksort problem (FIXED) In-Reply-To: <4AAB1D01.3020403@esoteriq.org> References: <4AAAF21C.5030209@esoteriq.org> <4AAB1D01.3020403@esoteriq.org> Message-ID: <4AAB1FA1.6060202@esoteriq.org> Sorry to keep posting, but I just wanted to say I fixed the problem (it isn't even in this code, it was in the insertion sort module.) Martin Bishop wrote: > Edited it some more, lots of silly mistakes in that old code. Now it > almost works...it sorts the array sometimes, but other times gives me > a bounds error. Any idea now? > > MODULE DualPivot; > > IMPORT Insertion, Fmt, IO; > > PROCEDURE Sort(VAR arr: ARRAY OF INTEGER) = > BEGIN > SortFromTo(arr, 0, NUMBER(arr)); > END Sort; > > PROCEDURE SortFromTo(VAR arr: ARRAY OF INTEGER; from, to: INTEGER) = > BEGIN > RangeCheck(NUMBER(arr), from, to); > DualPivotSort(arr, from, to - 1, 3); > END SortFromTo; > > PROCEDURE RangeCheck(len, from, to: INTEGER) RAISES {BadArgument, > IndexOutOfRange} = > BEGIN > IF from > to THEN > RAISE BadArgument(Fmt.Int(from) & " > " & Fmt.Int(to) & "\n"); > END; > IF from < 0 THEN > RAISE IndexOutOfRange("from"); > END; > IF to > len THEN > RAISE IndexOutOfRange("to"); > END; > END RangeCheck; > > PROCEDURE Swap(VAR arr: ARRAY OF INTEGER; i, j: INTEGER) = > VAR temp := arr[i]; > BEGIN > arr[i] := arr[j]; > arr[j] := temp; > END Swap; > > PROCEDURE DualPivotSort(VAR arr: ARRAY OF INTEGER; left, right, div: > INTEGER) = > VAR > len := right - left; > third := len DIV div; > m1 := left + third; > m2 := right - third; > piv1: INTEGER; > piv2: INTEGER; > less := left + 1; > great := right - 1; > dist: INTEGER; > > BEGIN > IF len < 27 THEN > Insertion.Sort(arr); > RETURN; > END; > > IF m1 <= left THEN > m1 := left + 1; > END; > > IF m2 >= right THEN > m2 := right - 1; > END; > > IO.Put("DEBUG: m1 = " & Fmt.Int(m1) & " m2 = " & Fmt.Int(m2) & > " left = " & Fmt.Int(left) & " right = " & Fmt.Int(right) & "\n"); > IO.Put("DEBUG: len = " & Fmt.Int(len) & " third = " & > Fmt.Int(third) & "\n"); > IO.Put("***\n"); > > IF arr[m1] < arr[m2] THEN > Swap(arr, m1, left); > Swap(arr, m2, right); > ELSE > Swap(arr, m1, right); > Swap(arr, m2, left); > END; > > piv1 := arr[left]; > piv2 := arr[right]; > FOR k := less TO great DO > IF arr[k] < piv1 THEN > Swap(arr, k, less); > INC(less); > ELSIF arr[k] > piv2 THEN > WHILE (k < great) AND (arr[great] > piv2) DO > DEC(great); > END; > Swap(arr, k, great); > DEC(great); > IF arr[k] < piv1 THEN > Swap(arr, k, less); > INC(less); > END; > END; > END; > > dist := great - less; > > IF dist < 13 THEN > INC(div); > END; > > Swap(arr, less - 1, left); > Swap(arr, great + 1, right); > DualPivotSort(arr, left, less - 2, div); > DualPivotSort(arr, great + 2, right, div); > IF (dist > len - 13) AND (piv1 # piv2) THEN > FOR k := less TO great DO > IF arr[k] = piv1 THEN > Swap(arr, k, less); > INC(less); > ELSIF arr[k] = piv2 THEN > Swap(arr, k, great); > DEC(great); > IF arr[k] = piv1 THEN > Swap(arr, k, less); > INC(less); > END; > END; > END; > END; > > IF piv1 < piv2 THEN > DualPivotSort(arr, less, great, div); > END; > END DualPivotSort; > > BEGIN > END DualPivot. > > Martin Bishop wrote: >> I saw a post on reddit about a Dual Pivot Quicksort, and I translated >> the code from Java to Modula-3. I have it all translated, and it >> builds, but I am having boundary issues. Somewhere on the second >> pass, the variable m2 is getting the value -2. Here's the code: >> >> ... > >> Right now when I try to run I get: >> >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "../DualPivot.m3", line 61 >> *** >> >> Line 61 is: IF arr[m1] < arr[m2] THEN >> >> Anyone see what is happening? It's probably off by 1 (or more) >> errors, but I don't see them. >> >> > > From jay.krell at cornell.edu Sat Sep 12 10:53:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Sep 2009 08:53:01 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30: 2009-02-16 02:30 hosking * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, RTProcessPosixC.i3: Tidy up. 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 2009-02-16 02:02 hosking * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: Expose DoWalkRef. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 22:21:44 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 12 11:26:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Sep 2009 09:26:51 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: Tony, - You didn't like how I factored InitMutex and InitCondition via InitMutexHelper? - XWait doesn't have to initialize the mutex, because it must already be locked, and therefore initialized? Or is that a "safety hole"? Unsafe module trusting safe caller to have adhered to its interface but it might not have to so unsafe code has to do extra work to preserve safety? Reasonable to ASSERT instead? Or are asserts allowed to be removed and can't be used to guarantee safety? (I put them in C code used by Modula-3, but I can perhaps make the rules there.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Sat, 12 Sep 2009 08:53:01 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30: 2009-02-16 02:30 hosking * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, RTProcessPosixC.i3: Tidy up. 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 2009-02-16 02:02 hosking * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: Expose DoWalkRef. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 22:21:44 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 13:38:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Sep 2009 07:38:43 -0400 Subject: [M3devel] RC merge In-Reply-To: <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> Message-ID: <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> But in this case the caller is highly privileged code that is already UNSAFE, so who cares? On 11 Sep 2009, at 23:37, jay.krell at cornell.edu wrote: > I don't like the caller to have to cast. > > - Jay (phone) > > On Sep 11, 2009, at 7:19 PM, Tony Hosking > wrote: > >> Yes, that was exactly my intention. I wasn't quite sure what your >> problem was with the code I had returning ADDRESS, but was willing >> to accede. It is "safe", but you can't use the result unless in >> UNSAFE code. >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 11 Sep 2009, at 17:33, Jay K wrote: >> >>> ps: I think there's another funny thing here: >>> I think you can have: >>> >>> INTERFACE FooInterface; >>> >>> PROCEDURE SafeFunction(); >>> PROCEDURE UnsafeFunction()=ADDRESS; >>> >>> END FooInterface. >>> >>> Despite being in a safe interface, UnsafeFunction either can't be >>> called >>> from safe code, or at least its return value can't be used? Or at >>> least >>> can't be done anything with but compare to NIL? >>> I think. >>> Therefore this interface could be said to be "partially unsafe". >>> >>> Perhaps not a useful middle ground though. >>> >>> - Jay >>> >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC merge >>> Date: Fri, 11 Sep 2009 21:26:00 +0000 >>> >>> Yes and no. I agree I made a small mess. I'm not sure you have >>> quite described how it should be. >>> >>> I propose a few options: >>> 1 - asis, probably not >>> 2 - rename/merge ThreadUnsafe to ThreadInternal >>> 3 - move the part that external folks use, probably just MyId, to >>> Thread, and then move ThreadUnsafe back to ThreadF, maybe >>> ThreadInternal to ThreadF too >>> >>> 2 at least removes one interface that I added, reducing the three >>> similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, >>> ThreadF and ThreadInternal >>> >>> 3 maybe gratuitously breaks folks but is a clean result >>> >>> 4 - like you said, make all ThreadF users unsafe; but IF it is >>> just MyId, and I'm not sure it is, which seems harmless, right? >>> seems wrong to make them unsafe. >>> >>> - Jay >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Fri, 11 Sep 2009 16:51:11 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] RC merge >>> >>> Sorry, it looks like my commit failed last night because of need >>> to merge with your ThreadUnsafe stuff. >>> >>> FYI, we really should think about making ThreadF UNSAFE since >>> anyone invoking on it is exposed to dangerous parts of the run- >>> time system. Is there any need for it really to be safe? >>> >>> On 11 Sep 2009, at 16:05, Jay K wrote: >>> >>> Tony I'll double check if I see the hang. NT386 still crashes. >>> >>> http://www.modula3.com/cm3/ChangeLog-2009 >>> >>> " >>> 2009-09-08 05:54 hosking >>> >>> * m3-libs/m3core/src/: convert/CConvert.m3, >>> runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, >>> runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, >>> runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, >>> runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, >>> runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, >>> runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, >>> thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, >>> thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, >>> thread/WIN32/ThreadWin32.m3: >>> >>> Tidy up use of thread.inCritical to only occur in allocation >>> sequences and in >>> thread stoppage. This simplifies reasoning. Refactored use of >>> heap lock >>> in the process. This may be better implemented on PTHREAD >>> targets using a >>> recursive pthread mutex instead of one we roll ourselves from a >>> non-recursive >>> mutex. >>> >>> Still witnessing random hangs in Juno and mentor on I386_DARWIN. >>> Strange, I thought this was working previously. >>> I wonder if there is some sort of race in the GUI code somewhere? >>> " >>> >>> ?? >>> - Jay >>> >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Fri, 11 Sep 2009 12:46:19 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] RC merge >>> >>> No, the hangs in Juno and mentor are no longer there. I cannot >>> reproduce them on I386_DARWIN. >>> >>> On 11 Sep 2009, at 10:24, Jay K wrote: >>> >>> But the hangs are still present, right? Worth merging without that >>> fixed? >>> >>> How does one do it easily? >>> I wish we used Perforce. :( >>> >>> - Jay >>> >>> >>> From: hosking at cs.purdue.edu >>> To: m3devel at elegosoft.com >>> Date: Fri, 11 Sep 2009 09:45:23 -0400 >>> Subject: [M3devel] RC merge >>> >>> Can someone merge my recent deep fixes to pthreads threading over >>> to the release branch? I won't get a chance to do so until next >>> Monday at the earliest. >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 14:22:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Sep 2009 08:22:51 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: <1BBBFA10-B502-4985-9F3D-24E33D5927E6@cs.purdue.edu> On 12 Sep 2009, at 05:26, Jay K wrote: > Tony, > - You didn't like how I factored InitMutex and InitCondition via > InitMutexHelper? Please keep them separate in case implementation of Condition and Mutex diverge. I've been playing with these some lately and may yet make further changes. Having shared code makes it a real pain to change one and not the other. > - XWait doesn't have to initialize the mutex, because it must already > be locked, and therefore initialized? Or is that a "safety hole"? Just in case a client invokes Wait without holding the mutex. Perhaps better to check and die. I will adjust. > Unsafe module trusting safe caller to have adhered to its interface > but it might not have to so unsafe code has to do extra work to > preserve safety? > Reasonable to ASSERT instead? Or are asserts allowed to be removed ASSERTs can be removed by compiling without assertions for performance. > and can't be used to guarantee safety? Right. > (I put them in C code used by Modula-3, but I can perhaps make > the rules there.) C coded asserts cannot be turned off by the Modula-3 compiler. Only C compiler. > > - Jay > > > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sat, 12 Sep 2009 08:53:01 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I believe it was this 30 minute window, 2009-02-16 02:00 - > 2009-02-16 02:30: > > 2009-02-16 02:30 hosking > > * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, > RTProcessPosixC.i3: > > Tidy up. > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > 2009-02-16 02:02 hosking > > * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: > > Expose DoWalkRef. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 22:21:44 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Hmmm. Not sure. Do you have the code diffs? > > On 11 Sep 2009, at 17:28, Jay K wrote: > > They aren't really in Trestle or ThreadWin32. > Well, right, often they are in ThreadWin32. > But not always. > I think it is, like, classic heap/stack corruption, via non-classic > "locking not working" and gc moving stuff when it shouldn't. > I don't have good evidence, but it usually NOT a hang/deadlock or > assertion failure, it is usually an access violation (aka SEGSIGV) > which as I understand must be the result of bugs in unsafe code. > > I did narrow it down a 30 minute window. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Fri, 11 Sep 2009 17:05:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I have my suspicions that ThreadWin32 may have similar latent bugs > in synchronization similar to those I have recently shaken out of > the pthreads implementation. The good thing is that my > implementation there is based in part on ThreadWin32, so it can't be > too far off. It is inevitable with concurrent code that you will > get different behavior at each run. The easiest things to debug are > thread lockups, which can usually be diagnosed by staring at dumps > of all the thread state. Harder is actual crashes like you are > observing. If assertions can be used to monitor program invariants > then it usually can be narrowed down. Unfortunately, I am not in a > position to debug the ThreadWin32 code. Any help would be > appreciated. The question is whether the crashes you see are in > Trestle or ThreadWin32. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 14:24:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Sep 2009 08:24:48 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> Interesting. My suspicions are that I missed something in the ThreadWin32 conversion to implement LockHeap, WaitHeap sanely. I can't debug Windows threads easily, but I strongly suggest Windows threads are in need of a rewrite to improve concurrency by making use of mutex/CVs now that Win32 supports CVs. On 12 Sep 2009, at 04:53, Jay K wrote: > I believe it was this 30 minute window, 2009-02-16 02:00 - > 2009-02-16 02:30: > > 2009-02-16 02:30 hosking > > * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, > RTProcessPosixC.i3: > > Tidy up. > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > 2009-02-16 02:02 hosking > > * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: > > Expose DoWalkRef. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 22:21:44 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Hmmm. Not sure. Do you have the code diffs? > > On 11 Sep 2009, at 17:28, Jay K wrote: > > They aren't really in Trestle or ThreadWin32. > Well, right, often they are in ThreadWin32. > But not always. > I think it is, like, classic heap/stack corruption, via non-classic > "locking not working" and gc moving stuff when it shouldn't. > I don't have good evidence, but it usually NOT a hang/deadlock or > assertion failure, it is usually an access violation (aka SEGSIGV) > which as I understand must be the result of bugs in unsafe code. > > I did narrow it down a 30 minute window. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Fri, 11 Sep 2009 17:05:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I have my suspicions that ThreadWin32 may have similar latent bugs > in synchronization similar to those I have recently shaken out of > the pthreads implementation. The good thing is that my > implementation there is based in part on ThreadWin32, so it can't be > too far off. It is inevitable with concurrent code that you will > get different behavior at each run. The easiest things to debug are > thread lockups, which can usually be diagnosed by staring at dumps > of all the thread state. Harder is actual crashes like you are > observing. If assertions can be used to monitor program invariants > then it usually can be narrowed down. Unfortunately, I am not in a > position to debug the ThreadWin32 code. Any help would be > appreciated. The question is whether the crashes you see are in > Trestle or ThreadWin32. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 12 15:18:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Sep 2009 13:18:03 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> Message-ID: If you do that, can you make it decide at runtime to chose between a pre-Vista and Vista or newer implementation? If you want, I can create ThreadWin6.m3 that is actually identical to ThreadWin32.m3 and a runtime switch between them, and then you or maybe I can start changing ThreadWin6.m3. I'm going to try to "study" ThreadPThread.m3 to inform me on how to write both ThreadWinNoCV.m3 (fix) and ThreadWinCV.m3 (making up more names). Thanks, - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Sat, 12 Sep 2009 08:24:48 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Interesting. My suspicions are that I missed something in the ThreadWin32 conversion to implement LockHeap, WaitHeap sanely. I can't debug Windows threads easily, but I strongly suggest Windows threads are in need of a rewrite to improve concurrency by making use of mutex/CVs now that Win32 supports CVs. On 12 Sep 2009, at 04:53, Jay K wrote: I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30: 2009-02-16 02:30 hosking * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, RTProcessPosixC.i3: Tidy up. 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 2009-02-16 02:02 hosking * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: Expose DoWalkRef. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 22:21:44 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 02:16:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 00:16:00 +0000 Subject: [M3devel] AllocTraced? Message-ID: Tony, - I can confirm Darwin no longer hangs. - I'm manually merging head to release. - We have two similar functions called AllocTraced now. Any chance of renaming one or combining them into one? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 07:53:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 05:53:18 +0000 Subject: [M3devel] RC merge In-Reply-To: <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> Message-ID: Imagine you are a somewhat prolific fairly happy C or C++ programmer. The whole world is unsafe, but recieves a fair amount of static checking and is therefore largely correct and perhaps doesn't even suffer much from the lack of safety. void* GetFoo(void); void* GetBar(void); or Foo_t* GetFoo(void); Bar_t* GetBar(void); ? Definitely the second. Perhaps perhaps perhaps perhaps a function should be able to be declared to return an UNTRACED REF Foo.Something, without actually importing Foo or defining Something? Clearly the safety of an /interface/ is more subtle than a boolean. Some functions may be safe and others unsafe. Even some uses of functions. Imagine for example: PROCEDURE GetFoo(): UNTRACED REF Foo.Something; Perhas a safe function could call this function, as long as it only compares the return value to NIL? Actually storing it in a variable would require IMPORT Foo, and if FOO is declared UNSAFE, then that would pollute the caller. Or maybe merely declaring a variable of UNTRACED is enough to wreck safety? Either way, I do grant, that it probably isn't worth deciding or making any language changes whatsoever. It should suffice for programmers to partition any given bunch of code conceptual interface Foo into SAFE INTERFACE Foo and UNSAFE INTERFACE FooF or FooInternal or FooUnsafe. I think I shall rename ThreadUnsafe to ThreadInternal amd merge the two ThreadInternals into one, as long as the contents of each exist in all of them, even though, granted, there aren't callers of all of them. "Unsafe" is shorter but "Internal" seems maybe better. ThreadF will remain safe and very small. We could move its resulting lone function into Thread, but I think it isn't worth breaking any callers outside m3core. Furthermore I'll endeavor to remove ADDRESS as a return type in ThreadInternal, replacing it with actual types, in order to remove casts, and make the unsafe code get just a little bit more static safety/checking. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Sat, 12 Sep 2009 07:38:43 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge But in this case the caller is highly privileged code that is already UNSAFE, so who cares? On 11 Sep 2009, at 23:37, jay.krell at cornell.edu wrote: I don't like the caller to have to cast. - Jay (phone) On Sep 11, 2009, at 7:19 PM, Tony Hosking wrote: Yes, that was exactly my intention. I wasn't quite sure what your problem was with the code I had returning ADDRESS, but was willing to accede. It is "safe", but you can't use the result unless in UNSAFE code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 17:33, Jay K wrote: ps: I think there's another funny thing here: I think you can have: INTERFACE FooInterface; PROCEDURE SafeFunction(); PROCEDURE UnsafeFunction()=ADDRESS; END FooInterface. Despite being in a safe interface, UnsafeFunction either can't be called from safe code, or at least its return value can't be used? Or at least can't be done anything with but compare to NIL? I think. Therefore this interface could be said to be "partially unsafe". Perhaps not a useful middle ground though. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] RC merge Date: Fri, 11 Sep 2009 21:26:00 +0000 Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be. I propose a few options: 1 - asis, probably not 2 - rename/merge ThreadUnsafe to ThreadInternal 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too 2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal 3 maybe gratuitously breaks folks but is a clean result 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:51:11 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote: Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote: But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Sun Sep 13 08:06:31 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Sun, 13 Sep 2009 01:06:31 -0500 Subject: [M3devel] Generic Dual Pivot Quicksort Message-ID: <4AAC8BE7.4010906@esoteriq.org> I wrote a generic version of Vladimir Yaroslavskiy's Dual Pivot Quicksort (http://permalink.gmane.org/gmane.comp.java.openjdk.core-libs.devel/2628) There's no known errors, but let me know if you find any. http://mbishop.esoteriq.org/code/Modula-3/GenericDualPivot/ From jay.krell at cornell.edu Sun Sep 13 15:51:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 13:51:02 +0000 Subject: [M3devel] RC merge In-Reply-To: <20090913094450.31FEA1A207D@async.async.caltech.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> Message-ID: The functions are meant to be unsafe either way. ThreadF.i3 clearly had a safety hole before, but not due to the functions "in question". Good point about passing in ADDRESSes..but I'm not entirely sure I understand/agree. Can safe code ("directly") generate any ADDRESSes at all? Or only get them from unsafe code in the first place? ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? I'll check. IF safe code CAN generate ADDRESSes, then this was a hole: PROCEDURE SetCurrentHandlers(h: ADDRESS); and perhaps these: PROCEDURE SuspendOthers (); (* Suspend all threads except the caller's *) PROCEDURE ResumeOthers (); Though probably not the second, since safe code can trivially hang/deadlock on its own. The public safe ThreadF.i3 now just: (*-------------------------------------------------- showthreads support ---*) TYPE State = { alive (* can run *), waiting (* waiting for a condition via Wait *), locking (* waiting for a mutex to be unlocked *), pausing (* waiting until some time is arrived *), blocking (* waiting for some IO *), dying (* done, but not yet joined *), dead (* done and joined *) }; (*-------------------------------------------------------------- identity ---*) TYPE Id = INTEGER; PROCEDURE MyId(): Id RAISES {}; (* return Id of caller *) Everything else I moved to the non-public ThreadInternal.i3. > But in Modula-3 whether an interface is unsafe or not *is* a boolean. Understood, but I still think even in unsafe code, LOOPHOLE should be minimized. C and C++ programmers are often taught to minimize casts, esp. reinterpret_cast. I think that guidance carries over to Modula's LOOPHOLE, even if you are already unsafe for other reasons. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > Date: Sun, 13 Sep 2009 02:44:50 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: > ... > > > >Imagine you are a somewhat prolific fairly happy C or C++ programmer. The w= > >hole world is unsafe=2C but recieves a fair amount of static checking and i= > >s therefore largely correct and perhaps doesn't even suffer much from the l= > >ack of safety. > > > >=20 > > > > void* GetFoo(void)=3B=20 > > > > void* GetBar(void)=3B=20 > > > >=20 > > > >or > > > >=20 > > > > Foo_t* GetFoo(void)=3B=20 > > > > Bar_t* GetBar(void)=3B=20 > > > >=20 > > > >? > > > >=20 > > > >Definitely the second. > > > >=20 > > > >Perhaps perhaps perhaps perhaps a function should be able to be declared to= > > return an UNTRACED REF Foo.Something=2C without actually importing Foo or = > >defining Something? > > > >=20 > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > >Some functions may be safe and others unsafe. > > > >Even some uses of functions. > > > >Imagine for example: > > > >=20 > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > >=20 > > > >Perhas a safe function could call this function=2C as long as it only compa= > >res the return value to NIL? > > > >Actually storing it in a variable would require IMPORT Foo=2C and if FOO is= > > declared UNSAFE=2C then that would > > > >pollute the caller. Or maybe merely declaring a variable of UNTRACED is eno= > >ugh to wreck safety? > > But in Modula-3 whether an interface is unsafe or not *is* a boolean. > It's very clearly defined what it means in the Green Book. > > If you don't declare your GetFoo as UNSAFE you can write > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > in safe code. > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > it's safer, if there's a safety problem with manipulating the fields. > > An interface can hardly assume that it is the only one injecting objects > of type ADDRESS into the "safe world" so if you're allowing the safe world > to pass these objects back in your interface you have to sanity-check > them anyhow. You do not, however, need to worry about the fields having > been changed by the safe code. > > If you need some more subtle properties than that you probably ought > to be writing UNSAFE code in the first place. Or is there some trickery > you can do along the lines of what we came up with for small integers > in pointers? > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 19:11:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 17:11:59 +0000 Subject: [M3devel] RC merge In-Reply-To: <20090913161207.2AB3B1A207D@async.async.caltech.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <20090913161207.2AB3B1A207D@async.async.caltech.edu> Message-ID: Good point, previously I could say SetCurrentHandlers(MyFPState()) in safe code. Now you can't. There's still ADDRESS used in ThreadInternal.i3 requiring LOOPHOLE but it doesn't appear easy to fix. > Arguably, hanging other threads (with which one does not share mutexes etc) Mutexes aren't the entire story there I think. Imagine some homegrown spinlock that is exported?? In either case, these functions are moved to an unsafe interface, at least until/unless some safe code needs them. Thanks, - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > Date: Sun, 13 Sep 2009 09:12:07 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: > >--_11d51f7d-f47a-4693-89d2-6f3429314a09_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > ... > >Good point about passing in ADDRESSes..but I'm not entirely sure I understa= > >nd/agree. > >Can safe code ("directly") generate any ADDRESSes at all? Or only get them = > >from > >unsafe code in the first place? > >ADDRESS only comes from ADR=2C right? And ADR isn't allowed in safe? I'll c= > >heck. > > > >IF safe code CAN generate ADDRESSes=2C then this was a hole: > >PROCEDURE SetCurrentHandlers(h: ADDRESS)=3B > > > No safe code can't generate ADDRESSes without help. But certainly > safe code can import TWO of these "quasi-unsafe" interfaces, and mix > up which address came whence... so your example is probably still > unsafe. > > > > >and perhaps these: > >PROCEDURE SuspendOthers ()=3B > >(* Suspend all threads except the caller's *) > > > >PROCEDURE ResumeOthers ()=3B > > > >Though probably not the second=2C since safe code can trivially hang/deadlo= > >ck on its own. > > Yes hanging is not a safety violation by the Modula-3 definition. > Arguably, hanging other threads (with which one does not share mutexes etc) > perhaps should be a safety violation, but can it be guaranteed? > > ... > > > >> But in Modula-3 whether an interface is unsafe or not *is* a boolean. > > > >Understood=2C but I still think even in unsafe code=2C LOOPHOLE should be m= > >inimized. > >C and C++ programmers are often taught to minimize casts=2C esp. reinterpre= > >t_cast. > >I think that guidance carries over to Modula's LOOPHOLE=2C even if you are = > >already unsafe > >for other reasons. > > Agreed! > > Mika > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 13 19:39:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 13:39:39 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> Message-ID: ThreadF has always been a non-standard, internal, "unpublished", non- standard interface. At one point it wasn't even shipped (interface not Interface). Anyway, my argument was that as such we could freely leave it as it was. I would argue that ordinary programmers should never even use it (it contains some very nasty low-level code like the GC suspend routines). On 13 Sep 2009, at 01:53, Jay K wrote: > Imagine you are a somewhat prolific fairly happy C or C++ > programmer. The whole world is unsafe, but recieves a fair amount of > static checking and is therefore largely correct and perhaps doesn't > even suffer much from the lack of safety. > > void* GetFoo(void); > void* GetBar(void); > > or > > Foo_t* GetFoo(void); > Bar_t* GetBar(void); > > ? > > Definitely the second. > > Perhaps perhaps perhaps perhaps a function should be able to be > declared to return an UNTRACED REF Foo.Something, without actually > importing Foo or defining Something? > > Clearly the safety of an /interface/ is more subtle than a boolean. > Some functions may be safe and others unsafe. > Even some uses of functions. > Imagine for example: > > PROCEDURE GetFoo(): UNTRACED REF Foo.Something; > > Perhas a safe function could call this function, as long as it only > compares the return value to NIL? > Actually storing it in a variable would require IMPORT Foo, and if > FOO is declared UNSAFE, then that would > pollute the caller. Or maybe merely declaring a variable of UNTRACED > is enough to wreck safety? > > Either way, I do grant, that it probably isn't worth deciding or > making any language changes whatsoever. > > It should suffice for programmers to partition any given bunch of > code conceptual interface Foo > > into SAFE INTERFACE Foo and UNSAFE INTERFACE FooF or FooInternal or > FooUnsafe. > > I think I shall rename ThreadUnsafe to ThreadInternal amd merge the > two ThreadInternals into one, > as long as the contents of each exist in all of them, even though, > granted, there > aren't callers of all of them. > "Unsafe" is shorter but "Internal" seems maybe better. > > ThreadF will remain safe and very small. > We could move its resulting lone function into Thread, but I think > it isn't worth breaking > any callers outside m3core. > > Furthermore I'll endeavor to remove ADDRESS as a return type in > ThreadInternal, replacing > it with actual types, in order to remove casts, and make the unsafe > code get just a little > bit more static safety/checking. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sat, 12 Sep 2009 07:38:43 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > But in this case the caller is highly privileged code that is > already UNSAFE, so who cares? > > On 11 Sep 2009, at 23:37, jay.krell at cornell.edu wrote: > > I don't like the caller to have to cast. > > - Jay (phone) > > On Sep 11, 2009, at 7:19 PM, Tony Hosking > wrote: > > Yes, that was exactly my intention. I wasn't quite sure what your > problem was with the code I had returning ADDRESS, but was willing > to accede. It is "safe", but you can't use the result unless in > UNSAFE code. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 17:33, Jay K wrote: > > ps: I think there's another funny thing here: > I think you can have: > > INTERFACE FooInterface; > > PROCEDURE SafeFunction(); > PROCEDURE UnsafeFunction()=ADDRESS; > > END FooInterface. > > Despite being in a safe interface, UnsafeFunction either can't be > called > from safe code, or at least its return value can't be used? Or at > least > can't be done anything with but compare to NIL? > I think. > Therefore this interface could be said to be "partially unsafe". > > Perhaps not a useful middle ground though. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC merge > Date: Fri, 11 Sep 2009 21:26:00 +0000 > > Yes and no. I agree I made a small mess. I'm not sure you have quite > described how it should be. > > I propose a few options: > 1 - asis, probably not > 2 - rename/merge ThreadUnsafe to ThreadInternal > 3 - move the part that external folks use, probably just MyId, to > Thread, and then move ThreadUnsafe back to ThreadF, maybe > ThreadInternal to ThreadF too > > 2 at least removes one interface that I added, reducing the three > similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF > and ThreadInternal > > 3 maybe gratuitously breaks folks but is a clean result > > 4 - like you said, make all ThreadF users unsafe; but IF it is just > MyId, and I'm not sure it is, which seems harmless, right? seems > wrong to make them unsafe. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 16:51:11 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Sorry, it looks like my commit failed last night because of need to > merge with your ThreadUnsafe stuff. > > FYI, we really should think about making ThreadF UNSAFE since anyone > invoking on it is exposed to dangerous parts of the run-time > system. Is there any need for it really to be safe? > > On 11 Sep 2009, at 16:05, Jay K wrote: > > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 13 19:43:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 13:43:48 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> Message-ID: <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> Safe code can't do anything with a value of type ADDRESS except pass it around. It must use unsafe operations (NARROW) to turn it into something usable. I think you misunderstood ThreadF in the first place. It has always been logically unsafe, if not UNSAFE. I don't want ThreadF ever to come to be something that people outside the runtime system rely on. The Id type and MyId function is simply a convenience, but not and never has been part of the standard interfaces. Can we please just revert back to the way it has always been? On 13 Sep 2009, at 09:51, Jay K wrote: > The functions are meant to be unsafe either way. > ThreadF.i3 clearly had a safety hole before, but not due to the > functions "in question". > > Good point about passing in ADDRESSes..but I'm not entirely sure I > understand/agree. > Can safe code ("directly") generate any ADDRESSes at all? Or only > get them from > unsafe code in the first place? > ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? > I'll check. > > IF safe code CAN generate ADDRESSes, then this was a hole: > PROCEDURE SetCurrentHandlers(h: ADDRESS); > > and perhaps these: > PROCEDURE SuspendOthers (); > (* Suspend all threads except the caller's *) > > PROCEDURE ResumeOthers (); > > Though probably not the second, since safe code can trivially hang/ > deadlock on its own. > > The public safe ThreadF.i3 now just: > > (*-------------------------------------------------- showthreads > support ---*) > > TYPE > State = { > alive (* can run *), > waiting (* waiting for a condition via Wait *), > locking (* waiting for a mutex to be unlocked *), > pausing (* waiting until some time is arrived *), > blocking (* waiting for some IO *), > dying (* done, but not yet joined *), > dead (* done and joined *) > }; > > (*-------------------------------------------------------------- > identity ---*) > > TYPE > Id = INTEGER; > > PROCEDURE MyId(): Id RAISES {}; > (* return Id of caller *) > > > Everything else I moved to the non-public ThreadInternal.i3. > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > Understood, but I still think even in unsafe code, LOOPHOLE should > be minimized. > C and C++ programmers are often taught to minimize casts, esp. > reinterpret_cast. > I think that guidance carries over to Modula's LOOPHOLE, even if you > are already unsafe > for other reasons. > > - Jay > > > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] RC merge > > Date: Sun, 13 Sep 2009 02:44:50 -0700 > > From: mika at async.async.caltech.edu > > > > Jay K writes: > > ... > > > > > >Imagine you are a somewhat prolific fairly happy C or C++ > programmer. The w= > > >hole world is unsafe=2C but recieves a fair amount of static > checking and i= > > >s therefore largely correct and perhaps doesn't even suffer much > from the l= > > >ack of safety. > > > > > >=20 > > > > > > void* GetFoo(void)=3B=20 > > > > > > void* GetBar(void)=3B=20 > > > > > >=20 > > > > > >or > > > > > >=20 > > > > > > Foo_t* GetFoo(void)=3B=20 > > > > > > Bar_t* GetBar(void)=3B=20 > > > > > >=20 > > > > > >? > > > > > >=20 > > > > > >Definitely the second. > > > > > >=20 > > > > > >Perhaps perhaps perhaps perhaps a function should be able to be > declared to= > > > return an UNTRACED REF Foo.Something=2C without actually > importing Foo or = > > >defining Something? > > > > > >=20 > > > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > > > >Some functions may be safe and others unsafe. > > > > > >Even some uses of functions. > > > > > >Imagine for example: > > > > > >=20 > > > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > > > >=20 > > > > > >Perhas a safe function could call this function=2C as long as it > only compa= > > >res the return value to NIL? > > > > > >Actually storing it in a variable would require IMPORT Foo=2C and > if FOO is= > > > declared UNSAFE=2C then that would > > > > > >pollute the caller. Or maybe merely declaring a variable of > UNTRACED is eno= > > >ugh to wreck safety? > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > It's very clearly defined what it means in the Green Book. > > > > If you don't declare your GetFoo as UNSAFE you can write > > > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > > > in safe code. > > > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > > it's safer, if there's a safety problem with manipulating the > fields. > > > > An interface can hardly assume that it is the only one injecting > objects > > of type ADDRESS into the "safe world" so if you're allowing the > safe world > > to pass these objects back in your interface you have to sanity- > check > > them anyhow. You do not, however, need to worry about the fields > having > > been changed by the safe code. > > > > If you need some more subtle properties than that you probably ought > > to be writing UNSAFE code in the first place. Or is there some > trickery > > you can do along the lines of what we came up with for small > integers > > in pointers? > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 20:02:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 18:02:24 +0000 Subject: [M3devel] RC merge In-Reply-To: <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> Message-ID: > The Id type and MyId function is simply a convenience But what do we do about it? It is out there and being used. It ought not have been, but it was and is. The safety hole SetCurrentHandlers(WhateverState()) was also out there as I understand. Should break the existing users? And/or move MyId to Thread.i3? Or ThreadFSafe.i3? I really don't think the way it was is the best choice. At the very least, ThreadF should either be interface instead of Interface and/or UNSAFE. But those options have the collateral damage of breaking users of ThreadF.MyId. I chose a route that doesn't have that damage and contains any churn to within m3core. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Sun, 13 Sep 2009 13:43:48 -0400 CC: mika at async.async.caltech.edu; m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Safe code can't do anything with a value of type ADDRESS except pass it around. It must use unsafe operations (NARROW) to turn it into something usable. I think you misunderstood ThreadF in the first place. It has always been logically unsafe, if not UNSAFE. I don't want ThreadF ever to come to be something that people outside the runtime system rely on. The Id type and MyId function is simply a convenience, but not and never has been part of the standard interfaces. Can we please just revert back to the way it has always been? On 13 Sep 2009, at 09:51, Jay K wrote:The functions are meant to be unsafe either way. ThreadF.i3 clearly had a safety hole before, but not due to the functions "in question". Good point about passing in ADDRESSes..but I'm not entirely sure I understand/agree. Can safe code ("directly") generate any ADDRESSes at all? Or only get them from unsafe code in the first place? ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? I'll check. IF safe code CAN generate ADDRESSes, then this was a hole: PROCEDURE SetCurrentHandlers(h: ADDRESS); and perhaps these: PROCEDURE SuspendOthers (); (* Suspend all threads except the caller's *) PROCEDURE ResumeOthers (); Though probably not the second, since safe code can trivially hang/deadlock on its own. The public safe ThreadF.i3 now just: (*-------------------------------------------------- showthreads support ---*) TYPE State = { alive (* can run *), waiting (* waiting for a condition via Wait *), locking (* waiting for a mutex to be unlocked *), pausing (* waiting until some time is arrived *), blocking (* waiting for some IO *), dying (* done, but not yet joined *), dead (* done and joined *) }; (*-------------------------------------------------------------- identity ---*) TYPE Id = INTEGER; PROCEDURE MyId(): Id RAISES {}; (* return Id of caller *) Everything else I moved to the non-public ThreadInternal.i3. > But in Modula-3 whether an interface is unsafe or not *is* a boolean. Understood, but I still think even in unsafe code, LOOPHOLE should be minimized. C and C++ programmers are often taught to minimize casts, esp. reinterpret_cast. I think that guidance carries over to Modula's LOOPHOLE, even if you are already unsafe for other reasons. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > Date: Sun, 13 Sep 2009 02:44:50 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: > ... > > > >Imagine you are a somewhat prolific fairly happy C or C++ programmer. The w= > >hole world is unsafe=2C but recieves a fair amount of static checking and i= > >s therefore largely correct and perhaps doesn't even suffer much from the l= > >ack of safety. > > > >=20 > > > > void* GetFoo(void)=3B=20 > > > > void* GetBar(void)=3B=20 > > > >=20 > > > >or > > > >=20 > > > > Foo_t* GetFoo(void)=3B=20 > > > > Bar_t* GetBar(void)=3B=20 > > > >=20 > > > >? > > > >=20 > > > >Definitely the second. > > > >=20 > > > >Perhaps perhaps perhaps perhaps a function should be able to be declared to= > > return an UNTRACED REF Foo.Something=2C without actually importing Foo or = > >defining Something? > > > >=20 > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > >Some functions may be safe and others unsafe. > > > >Even some uses of functions. > > > >Imagine for example: > > > >=20 > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > >=20 > > > >Perhas a safe function could call this function=2C as long as it only compa= > >res the return value to NIL? > > > >Actually storing it in a variable would require IMPORT Foo=2C and if FOO is= > > declared UNSAFE=2C then that would > > > >pollute the caller. Or maybe merely declaring a variable of UNTRACED is eno= > >ugh to wreck safety? > > But in Modula-3 whether an interface is unsafe or not *is* a boolean. > It's very clearly defined what it means in the Green Book. > > If you don't declare your GetFoo as UNSAFE you can write > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > in safe code. > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > it's safer, if there's a safety problem with manipulating the fields. > > An interface can hardly assume that it is the only one injecting objects > of type ADDRESS into the "safe world" so if you're allowing the safe world > to pass these objects back in your interface you have to sanity-check > them anyhow. You do not, however, need to worry about the fields having > been changed by the safe code. > > If you need some more subtle properties than that you probably ought > to be writing UNSAFE code in the first place. Or is there some trickery > you can do along the lines of what we came up with for small integers > in pointers? > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 13 20:34:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 14:34:36 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> Message-ID: <78CFFD41-8D5D-4E4C-9A9D-A7DD29DB95A9@cs.purdue.edu> I'm happy with what you have done (small safe ThreadF, internal unsafe ThreadInternal). Thanks. On 13 Sep 2009, at 14:02, Jay K wrote: > > The Id type and MyId function is simply a convenience > > But what do we do about it? > It is out there and being used. > It ought not have been, but it was and is. > > The safety hole SetCurrentHandlers(WhateverState()) was also out > there as I understand. > > Should break the existing users? > And/or move MyId to Thread.i3? > Or ThreadFSafe.i3? > > I really don't think the way it was is the best choice. > At the very least, ThreadF should either be interface instead of > Interface and/or UNSAFE. > But those options have the collateral damage of breaking users of > ThreadF.MyId. > I chose a route that doesn't have that damage and contains any churn > to within m3core. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 13 Sep 2009 13:43:48 -0400 > CC: mika at async.async.caltech.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Safe code can't do anything with a value of type ADDRESS except pass > it around. It must use unsafe operations (NARROW) to turn it into > something usable. > > I think you misunderstood ThreadF in the first place. It has always > been logically unsafe, if not UNSAFE. I don't want ThreadF ever to > come to be something that people outside the runtime system rely > on. The Id type and MyId function is simply a convenience, but not > and never has been part of the standard interfaces. > > Can we please just revert back to the way it has always been? > > On 13 Sep 2009, at 09:51, Jay K wrote: > > The functions are meant to be unsafe either way. > ThreadF.i3 clearly had a safety hole before, but not due to the > functions "in question". > > Good point about passing in ADDRESSes..but I'm not entirely sure I > understand/agree. > Can safe code ("directly") generate any ADDRESSes at all? Or only > get them from > unsafe code in the first place? > ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? > I'll check. > > IF safe code CAN generate ADDRESSes, then this was a hole: > PROCEDURE SetCurrentHandlers(h: ADDRESS); > > and perhaps these: > PROCEDURE SuspendOthers (); > (* Suspend all threads except the caller's *) > > PROCEDURE ResumeOthers (); > > Though probably not the second, since safe code can trivially hang/ > deadlock on its own. > > The public safe ThreadF.i3 now just: > > (*-------------------------------------------------- showthreads > support ---*) > > TYPE > State = { > alive (* can run *), > waiting (* waiting for a condition via Wait *), > locking (* waiting for a mutex to be unlocked *), > pausing (* waiting until some time is arrived *), > blocking (* waiting for some IO *), > dying (* done, but not yet joined *), > dead (* done and joined *) > }; > > (*-------------------------------------------------------------- > identity ---*) > > TYPE > Id = INTEGER; > > PROCEDURE MyId(): Id RAISES {}; > (* return Id of caller *) > > > Everything else I moved to the non-public ThreadInternal.i3. > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > Understood, but I still think even in unsafe code, LOOPHOLE should > be minimized. > C and C++ programmers are often taught to minimize casts, esp. > reinterpret_cast. > I think that guidance carries over to Modula's LOOPHOLE, even if you > are already unsafe > for other reasons. > > - Jay > > > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] RC merge > > Date: Sun, 13 Sep 2009 02:44:50 -0700 > > From: mika at async.async.caltech.edu > > > > Jay K writes: > > ... > > > > > >Imagine you are a somewhat prolific fairly happy C or C++ > programmer. The w= > > >hole world is unsafe=2C but recieves a fair amount of static > checking and i= > > >s therefore largely correct and perhaps doesn't even suffer much > from the l= > > >ack of safety. > > > > > >=20 > > > > > > void* GetFoo(void)=3B=20 > > > > > > void* GetBar(void)=3B=20 > > > > > >=20 > > > > > >or > > > > > >=20 > > > > > > Foo_t* GetFoo(void)=3B=20 > > > > > > Bar_t* GetBar(void)=3B=20 > > > > > >=20 > > > > > >? > > > > > >=20 > > > > > >Definitely the second. > > > > > >=20 > > > > > >Perhaps perhaps perhaps perhaps a function should be able to be > declared to= > > > return an UNTRACED REF Foo.Something=2C without actually > importing Foo or = > > >defining Something? > > > > > >=20 > > > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > > > >Some functions may be safe and others unsafe. > > > > > >Even some uses of functions. > > > > > >Imagine for example: > > > > > >=20 > > > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > > > >=20 > > > > > >Perhas a safe function could call this function=2C as long as it > only compa= > > >res the return value to NIL? > > > > > >Actually storing it in a variable would require IMPORT Foo=2C and > if FOO is= > > > declared UNSAFE=2C then that would > > > > > >pollute the caller. Or maybe merely declaring a variable of > UNTRACED is eno= > > >ugh to wreck safety? > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > It's very clearly defined what it means in the Green Book. > > > > If you don't declare your GetFoo as UNSAFE you can write > > > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > > > in safe code. > > > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > > it's safer, if there's a safety problem with manipulating the > fields. > > > > An interface can hardly assume that it is the only one injecting > objects > > of type ADDRESS into the "safe world" so if you're allowing the > safe world > > to pass these objects back in your interface you have to sanity- > check > > them anyhow. You do not, however, need to worry about the fields > having > > been changed by the safe code. > > > > If you need some more subtle properties than that you probably ought > > to be writing UNSAFE code in the first place. Or is there some > trickery > > you can do along the lines of what we came up with for small > integers > > in pointers? > > > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 14 00:07:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 18:07:05 -0400 Subject: [M3devel] RC merge In-Reply-To: <20090913203005.67D011A2079@async.async.caltech.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> <20090913203005.67D011A2079@async.async.caltech.edu> Message-ID: <0B34162D-0E83-4163-ADF3-405FC0571731@cs.purdue.edu> It will stay in ThreadF. On 13 Sep 2009, at 16:30, Mika Nystrom wrote: > > ThreadF.MyId is something I have used in otherwise perfectly safe > code, > hope it doesn't go away! It's very nice to be able to distinguish > threads from each other without extra effort from the programmer. Is > this something that is sometimes hard to provide? > > Mika > > > Tony Hosking writes: >> >> --Apple-Mail-18--321278784 >> Content-Type: text/plain; >> charset=US-ASCII; >> format=flowed; >> delsp=yes >> Content-Transfer-Encoding: 7bit >> >> Safe code can't do anything with a value of type ADDRESS except pass >> it around. It must use unsafe operations (NARROW) to turn it into >> something usable. >> >> I think you misunderstood ThreadF in the first place. It has always >> been logically unsafe, if not UNSAFE. I don't want ThreadF ever to >> come to be something that people outside the runtime system rely on. >> The Id type and MyId function is simply a convenience, but not and >> never has been part of the standard interfaces. >> >> Can we please just revert back to the way it has always been? >> >> On 13 Sep 2009, at 09:51, Jay K wrote: >> >>> The functions are meant to be unsafe either way. >>> ThreadF.i3 clearly had a safety hole before, but not due to the >>> functions "in question". >>> >>> Good point about passing in ADDRESSes..but I'm not entirely sure I >>> understand/agree. >>> Can safe code ("directly") generate any ADDRESSes at all? Or only >>> get them from >>> unsafe code in the first place? >>> ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? >>> I'll check. >>> >>> IF safe code CAN generate ADDRESSes, then this was a hole: >>> PROCEDURE SetCurrentHandlers(h: ADDRESS); >>> >>> and perhaps these: >>> PROCEDURE SuspendOthers (); >>> (* Suspend all threads except the caller's *) >>> >>> PROCEDURE ResumeOthers (); >>> >>> Though probably not the second, since safe code can trivially hang/ >>> deadlock on its own. >>> >>> The public safe ThreadF.i3 now just: >>> >>> (*-------------------------------------------------- showthreads >>> support ---*) >>> >>> TYPE >>> State = { >>> alive (* can run *), >>> waiting (* waiting for a condition via Wait *), >>> locking (* waiting for a mutex to be unlocked *), >>> pausing (* waiting until some time is arrived *), >>> blocking (* waiting for some IO *), >>> dying (* done, but not yet joined *), >>> dead (* done and joined *) >>> }; >>> >>> (*-------------------------------------------------------------- >>> identity ---*) >>> >>> TYPE >>> Id = INTEGER; >>> >>> PROCEDURE MyId(): Id RAISES {}; >>> (* return Id of caller *) >>> >>> >>> Everything else I moved to the non-public ThreadInternal.i3. >>> >>> >>>> But in Modula-3 whether an interface is unsafe or not *is* a >>> boolean. >>> >>> Understood, but I still think even in unsafe code, LOOPHOLE should >>> be minimized. >>> C and C++ programmers are often taught to minimize casts, esp. >>> reinterpret_cast. >>> I think that guidance carries over to Modula's LOOPHOLE, even if you >>> are already unsafe >>> for other reasons. >>> >>> - Jay >>> >>> >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] RC merge >>>> Date: Sun, 13 Sep 2009 02:44:50 -0700 >>>> From: mika at async.async.caltech.edu >>>> >>>> Jay K writes: >>>> ... >>>>> >>>>> Imagine you are a somewhat prolific fairly happy C or C++ >>> programmer. The w= >>>>> hole world is unsafe=2C but recieves a fair amount of static >>> checking and i= >>>>> s therefore largely correct and perhaps doesn't even suffer much >>> from the l= >>>>> ack of safety. >>>>> >>>>> =20 >>>>> >>>>> void* GetFoo(void)=3B=20 >>>>> >>>>> void* GetBar(void)=3B=20 >>>>> >>>>> =20 >>>>> >>>>> or >>>>> >>>>> =20 >>>>> >>>>> Foo_t* GetFoo(void)=3B=20 >>>>> >>>>> Bar_t* GetBar(void)=3B=20 >>>>> >>>>> =20 >>>>> >>>>> ? >>>>> >>>>> =20 >>>>> >>>>> Definitely the second. >>>>> >>>>> =20 >>>>> >>>>> Perhaps perhaps perhaps perhaps a function should be able to be >>> declared to= >>>>> return an UNTRACED REF Foo.Something=2C without actually >>> importing Foo or = >>>>> defining Something? >>>>> >>>>> =20 >>>>> >>>>> Clearly the safety of an /interface/ is more subtle than a >>>>> boolean. >>>>> >>>>> Some functions may be safe and others unsafe. >>>>> >>>>> Even some uses of functions. >>>>> >>>>> Imagine for example: >>>>> >>>>> =20 >>>>> >>>>> PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B >>>>> >>>>> =20 >>>>> >>>>> Perhas a safe function could call this function=2C as long as it >>> only compa= >>>>> res the return value to NIL? >>>>> >>>>> Actually storing it in a variable would require IMPORT Foo=2C and >>> if FOO is= >>>>> declared UNSAFE=2C then that would >>>>> >>>>> pollute the caller. Or maybe merely declaring a variable of >>> UNTRACED is eno= >>>>> ugh to wreck safety? >>>> >>>> But in Modula-3 whether an interface is unsafe or not *is* a >>> boolean. >>>> It's very clearly defined what it means in the Green Book. >>>> >>>> If you don't declare your GetFoo as UNSAFE you can write >>>> >>>> VAR x := GetFoo; BEGIN (* manipulate fields of x *) END >>>> >>>> in safe code. >>>> >>>> Declaring GetFoo to return ADDRESS won't let you do that. Hence, >>>> it's safer, if there's a safety problem with manipulating the >>> fields. >>>> >>>> An interface can hardly assume that it is the only one injecting >>> objects >>>> of type ADDRESS into the "safe world" so if you're allowing the >>> safe world >>>> to pass these objects back in your interface you have to sanity- >>> check >>>> them anyhow. You do not, however, need to worry about the fields >>> having >>>> been changed by the safe code. >>>> >>>> If you need some more subtle properties than that you probably >>>> ought >>>> to be writing UNSAFE code in the first place. Or is there some >>> trickery >>>> you can do along the lines of what we came up with for small >>> integers >>>> in pointers? >>>> >>>> Mika >> >> >> --Apple-Mail-18--321278784 >> Content-Type: text/html; >> charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> >> > space; = >> -webkit-line-break: after-white-space; ">
> apple-content-edited=3D"true">> style=3D"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; ">
> break-word; -webkit-nbsp-mode: space; -webkit-line-break: = >> after-white-space; ">> style=3D"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; >> ">
> style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >> -webkit-line-break: after-white-space; ">> span" = >> style=3D"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; >> ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">
> class=3D"Apple-style-span" style=3D"font-size: medium;">> class=3D"Apple-style-span" color=3D"#0000FF" face=3D"'Gill >> Sans'">Safe = >> code can't do anything with a value of type ADDRESS except pass it = >> around.  It must use unsafe operations (NARROW) to turn it >> into = >> something usable.
> style-span"= >> color=3D"#0000FF" face=3D"'Gill Sans'">> span" = >> style=3D"font-size: medium;">
> class=3D"Apple-style-span" color=3D"#0000FF" face=3D"'Gill >> Sans'">> class=3D"Apple-style-span" style=3D"font-size: medium;">I think you = >> misunderstood ThreadF in the first place.  It has always been = >> logically unsafe, if not UNSAFE.  I don't want ThreadF ever to >> come = >> to be something that people outside the runtime system rely on. = >>  The Id type and MyId function is simply a convenience, but >> not and = >> never has been part of the standard = >> interfaces.
> span" = >> color=3D"#0000FF" face=3D"'Gill Sans'">> span" = >> style=3D"font-size: medium;">
> class=3D"Apple-style-span" color=3D"#0000FF" face=3D"'Gill >> Sans'">> class=3D"Apple-style-span" style=3D"font-size: medium;">Can we >> please = >> just revert back to the way it has always = >> been?
> span>
= >>

On 13 Sep >> 2009, at = >> 09:51, Jay K wrote:

> class=3D"Apple-interchange-newline">
> class=3D"Apple-style-span" style=3D"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; ">
> style=3D"font-size: 10pt; font-family: Verdana; ">The functions are = >> meant to be unsafe either way.
ThreadF.i3 clearly had a safety >> hole = >> before, but not due to the functions "in question".

Good >> point = >> about passing in ADDRESSes..but I'm not entirely sure I = >> understand/agree.
Can safe code ("directly") generate any >> ADDRESSes = >> at all? Or only get them from
unsafe code in the first = >> place?
ADDRESS only comes from ADR, right? And ADR isn't allowed >> in = >> safe? I'll check.

IF safe code CAN generate ADDRESSes, then >> this = >> was a hole:
PROCEDURE SetCurrentHandlers(h: ADDRESS);

and = >> perhaps these:
PROCEDURE SuspendOthers ();
(* Suspend all >> threads = >> except the caller's *)

PROCEDURE ResumeOthers >> ();

Though = >> probably not the second, since safe code can trivially hang/ >> deadlock on = >> its own.

The public safe ThreadF.i3 now = >> just:

(*-------------------------------------------------- = >> showthreads support ---*)

TYPE
  State =3D = >> {
        >> alive    = >> (* can run *),
        = >> waiting  (* waiting for a condition via Wait = >> *),
        locking  (* = >> waiting for a mutex to be unlocked = >> *),
        pausing  (* = >> waiting until some time is arrived = >> *),
        blocking (* >> waiting = >> for some IO *),
        = >> dying    (* done, but not yet joined = >> *),
        = >> dead     (* done and joined >> *)
    = >> };< >> br >> > >>
(*--------------------------------------------------------------= >> identity ---*)

TYPE
  Id =3D >> INTEGER;

PROCEDURE = >> MyId(): Id RAISES {};
(* return Id of caller >> *)


Everything = >> else I moved to the non-public ThreadInternal.i3.


> >> But in = >> Modula-3 whether an interface is unsafe or not *is* a = >> boolean.

Understood, but I still think even in unsafe code, = >> LOOPHOLE should be minimized.
C and C++ programmers are often >> taught = >> to minimize casts, esp. reinterpret_cast.
I think that guidance = >> carries over to Modula's LOOPHOLE, even if you are already >> unsafe
for = >> other reasons.

 - Jay


> To:> class=3D"Apple-converted-space"> > href=3D"mailto:jay.krell at cornell.edu">jay.krell at cornell.edu> a>
> = >> CC: 
> href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com> a>
> = >> Subject: Re: [M3devel] RC merge> class=3D"Apple-converted-space"> 
> Date: Sun, 13 >> Sep = >> 2009 02:44:50 -0700
> From:> class=3D"Apple-converted-space"> 
> href=3D"mailto:mika at async.async.caltech.edu">mika at async.async.caltech.edu >> <= >> /a>
> > span>
> = >> Jay K writes:
> ...
> >
> >Imagine you are >> a = >> somewhat prolific fairly happy C or C++ programmer. The >> w=3D
> = >> >hole world is unsafe=3D2C but recieves a fair amount of static = >> checking and i=3D
> >s therefore largely correct and >> perhaps = >> doesn't even suffer much from the l=3D
> >ack of = >> safety.
> >
> >=3D20
> >
> > >> void* = >> GetFoo(void)=3D3B=3D20
> >
> > void* = >> GetBar(void)=3D3B=3D20
> >
> >=3D20
> = >> >
> >or
> >
> >=3D20
> >> >
> = >> > Foo_t* GetFoo(void)=3D3B=3D20
> >
> > Bar_t* = >> GetBar(void)=3D3B=3D20
> >
> >=3D20
> = >> >
> >?
> >
> >=3D20
> >> >
> = >> >Definitely the second.
> >
> >=3D20
> = >> >
> >Perhaps perhaps perhaps perhaps a function should >> be = >> able to be declared to=3D
> > return an UNTRACED REF = >> Foo.Something=3D2C without actually importing Foo or =3D
> = >> >defining Something?
> >
> >=3D20
> = >> >
> >Clearly the safety of an /interface/ is more >> subtle = >> than a boolean.
> >
> >Some functions may be safe >> and = >> others unsafe.
> >
> >Even some uses of = >> functions.
> >
> >Imagine for example:
> = >> >
> >=3D20
> >
> >PROCEDURE GetFoo(): = >> UNTRACED REF Foo.Something=3D3B
> >
> >> >=3D20
> = >> >
> >Perhas a safe function could call this >> function=3D2C as = >> long as it only compa=3D
> >res the return value to = >> NIL?
> >
> >Actually storing it in a variable >> would = >> require IMPORT Foo=3D2C and if FOO is=3D
> > declared >> UNSAFE=3D2C= >> then that would
> >
> >pollute the caller. Or >> maybe = >> merely declaring a variable of UNTRACED is eno=3D
> >ugh >> to = >> wreck safety?
>> class=3D"Apple-converted-space"> 
> But in >> Modula-3 = >> whether an interface is unsafe or not *is* a boolean.
> It's >> very = >> clearly defined what it means in the Green Book.
>> class=3D"Apple-converted-space"> 
> If you don't = >> declare your GetFoo as UNSAFE you can write
>> class=3D"Apple-converted-space"> 
> VAR x :=3D >> GetFoo; = >> BEGIN (* manipulate fields of x *) END
>> class=3D"Apple-converted-space"> 
> in safe = >> code.
> > span>
> = >> Declaring GetFoo to return ADDRESS won't let you do that. >> Hence,
> = >> it's safer, if there's a safety problem with manipulating the = >> fields.
> > span>
>= >> An interface can hardly assume that it is the only one injecting = >> objects
> of type ADDRESS into the "safe world" so if you're = >> allowing the safe world
> to pass these objects back in your = >> interface you have to sanity-check
> them anyhow. You do not, = >> however, need to worry about the fields having
> been changed >> by = >> the safe code.
>> class=3D"Apple-converted-space"> 
> If you need >> some = >> more subtle properties than that you probably ought
> to be = >> writing UNSAFE code in the first place. Or is there some = >> trickery
> you can do along the lines of what we came up with >> for = >> small integers
> in pointers?
>> class=3D"Apple-converted-space"> 
> = >> Mika

= >> >> --Apple-Mail-18--321278784-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 16:17:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 14:17:23 +0000 Subject: [M3devel] $DISPLAY on Darwin In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> Message-ID: For the record, I don't think this statement about DISPLAY is true. I leave it at the default, which does resemble the wierd form shown. With older cm3 that does cause a problem and it probably/might cause some slow down (not using shared memory where it might otherwise be possible), but it seems to work ok. (I have made many errors in checkin comments, not always noted.) - Jay >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 16:39:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 14:39:11 +0000 Subject: [M3devel] CVS problems (and no checking mail) Message-ID: cvs commit: warning: editor session failed /usr/cvs/cm3/m3-ui/ui/src/xvbt/XSharedMem.m3,v <-- xvbt/XSharedMem.m3 new revision: 1.5; previous revision: 1.4 Can't locate Carp.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line 20. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/Data/Dumper.pm line 20. Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. Can't locate bytes.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. BEGIN failed--compilation aborted at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 16:43:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 14:43:16 +0000 Subject: [M3devel] CVS problems (and no checking mail) In-Reply-To: References: Message-ID: I see this "anywhere" (just checked two places): jbook2:src jay$ cvs -z3 commit -f -m "testing CVS triggers, no diff" m3makefile /usr/cvs/cm3/m3-libs/m3core/src/m3makefile,v <-- m3makefile new revision: 1.13; previous revision: 1.12 Can't locate Carp.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line 20. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/Data/Dumper.pm line 20. Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. Can't locate bytes.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. BEGIN failed--compilation aborted at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. - Jay From: jay.krell at cornell.edu To: m3-support at elego.de; m3devel at elegosoft.com Date: Wed, 16 Sep 2009 14:39:11 +0000 Subject: [M3devel] CVS problems (and no checking mail) cvs commit: warning: editor session failed /usr/cvs/cm3/m3-ui/ui/src/xvbt/XSharedMem.m3,v <-- xvbt/XSharedMem.m3 new revision: 1.5; previous revision: 1.4 Can't locate Carp.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line 20. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/Data/Dumper.pm line 20. Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. Can't locate bytes.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. BEGIN failed--compilation aborted at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 17:18:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 15:18:54 +0000 Subject: [M3devel] formsedit crash Message-ID: The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. I will confirm and further narrow this down over the next few days. I've been building various dates/versions and seeing how they act. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Wed Sep 16 20:14:01 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 16 Sep 2009 20:14:01 +0200 Subject: [M3devel] CVS problems (and no checking mail) In-Reply-To: References: Message-ID: <20090916201401.84slxeeg0kowgcgo@mail.elego.de> Hi Jay, This will be fixed shortly, sorry about that. Mike > > I see this "anywhere" (just checked two places): > > book2:src jay$ cvs -z3 commit -f -m "testing CVS triggers, no diff" > m3makefile > /usr/cvs/cm3/m3-libs/m3core/src/m3makefile,v <-- m3makefile > new revision: 1.13; previous revision: 1.12 > Can't locate Carp.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line > 20. > BEGIN failed--compilation aborted at > /usr/lib/perl/5.8/Data/Dumper.pm line 20. > Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. > Can't locate bytes.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. > Can't locate strict.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > BEGIN failed--compilation aborted at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > > > - Jay > > > > From: jay.krell at cornell.edu > To: m3-support at elego.de; m3devel at elegosoft.com > Date: Wed, 16 Sep 2009 14:39:11 +0000 > Subject: [M3devel] CVS problems (and no checking mail) > > > > > > > > > cvs commit: warning: editor session failed > /usr/cvs/cm3/m3-ui/ui/src/xvbt/XSharedMem.m3,v <-- xvbt/XSharedMem.m3 > new revision: 1.5; previous revision: 1.4 > Can't locate Carp.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line > 20. > BEGIN failed--compilation aborted at > /usr/lib/perl/5.8/Data/Dumper.pm line 20. > Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. > Can't locate bytes.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. > Can't locate strict.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > BEGIN failed--compilation aborted at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > > > > > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Sep 18 07:19:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 05:19:25 +0000 Subject: [M3devel] the so_linger inconsistency between Posix and Windows Message-ID: I've been reading up on SO_LINGER. Search the web.. There are two or three options, depending on how you view it. onoff=0 time=ignored onoff=1 time=non-zero onoff=1 time=0 You could view this as an example of the previous. The behavior is governed by additional bits. - does the socket of buffered unset data? - is the socket blocking? Some options result in the socket being "immediately" closed and unsent buffered data not being sent, and I think possibly the other side getting an error. Some options have close return immediately but send the buffered data in the "background". This I believe is the default. Some options have close block waiting for send to finish. This has pluses/minuses. The minus is -- what timeout to use? A plus and minus is, I believe, there is an opportunity for close to timeout and fail, letting the caller know that there was a failure to deliver data. It is good to know about failure, though you'd want to know if the code was ready to somehow handle the failure. onoff=0 seems "best". onoff=1, time=0 seems "bad". onoff=1, time="large" seems "ok", depending on how large. I think onoff=0 is the default. I will verify that with some getsockopt runs. If it is the default, I think we should just remove the setsockopt(so_linger) code. One might also imagine that 1 second is not a short time, so even the Windows code isn't far off from the Posix code. The only big change would be setting 1,0 or removing setting of 1,0. What I wish we had but don't know if we have, is some major Modula-3 user of sockets on both Posix and Windows, so that the change can be tested. I think there is a basic problem in networking code, of unreliability and inconsistent timing. You don't know how long to wait for something to occur, when to give up waiting and deciding it failed. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 18 09:49:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 07:49:18 +0000 Subject: [M3devel] formsedit crash Message-ID: I have it further narrowed down to the last two weeks of 1/2007. Which is just a few changes. I fear it is the switch from user threads to pthreads on 1/23/2007. I'll narrow it down further though, and then try user threads on Solaris (which will probably require repairing initialization order to make them work again anyway). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: formsedit crash Date: Wed, 16 Sep 2009 15:18:54 +0000 The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. I will confirm and further narrow this down over the next few days. I've been building various dates/versions and seeing how they act. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Sep 18 11:37:48 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 18 Sep 2009 11:37:48 +0200 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: <1253266668.2779.27.camel@faramir.m3w.org> I've had some funny race/thread-order conditions when I was switching to pthreads.... Someone lazy got too grooved in with fixed order of execution implied by how user threads work. It was in pp package and also somewhere I can't remember right now... Will look a bit through hm3 svn (dead in house spinoff of pm3 from times when all mainstream m3 had was user threads). On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > I have it further narrowed down to the last two weeks of 1/2007. > Which is just a few changes. > I fear it is the switch from user threads to pthreads on 1/23/2007. > I'll narrow it down further though, and then try user threads on > Solaris > (which will probably require repairing initialization order to make > them work > again anyway). > > - Jay > > > > ______________________________________________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: formsedit crash > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > The formsedit crash appears to have started between 12/1/2006 and > 3/1/2007. > I will confirm and further narrow this down over the next few days. > I've been building various dates/versions and seeing how they act. > > - Jay > > > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Sep 18 12:12:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 10:12:18 +0000 Subject: [M3devel] formsedit crash In-Reply-To: <1253266668.2779.27.camel@faramir.m3w.org> References: Message-ID: I thought about this a little..but..don't Modula-3 user threads preempt at arbitrary points? - Jay > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 18 Sep 2009 11:37:48 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] formsedit crash > > I've had some funny race/thread-order conditions when I was switching to > pthreads.... Someone lazy got too grooved in with fixed order of > execution implied by how user threads work. It was in pp package and > also somewhere I can't remember right now... Will look a bit through hm3 > svn (dead in house spinoff of pm3 from times when all mainstream m3 had > was user threads). > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > > I have it further narrowed down to the last two weeks of 1/2007. > > Which is just a few changes. > > I fear it is the switch from user threads to pthreads on 1/23/2007. > > I'll narrow it down further though, and then try user threads on > > Solaris > > (which will probably require repairing initialization order to make > > them work > > again anyway). > > > > - Jay > > > > > > > > ______________________________________________________________________ > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: formsedit crash > > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > > > The formsedit crash appears to have started between 12/1/2006 and > > 3/1/2007. > > I will confirm and further narrow this down over the next few days. > > I've been building various dates/versions and seeing how they act. > > > > - Jay > > > > > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 18 14:45:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Sep 2009 08:45:18 -0400 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: Jay, formsedit now works for me on I386_DARWIN. Not sure what you are trying to track down now. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 03:49, Jay K wrote: > I have it further narrowed down to the last two weeks of 1/2007. > Which is just a few changes. > I fear it is the switch from user threads to pthreads on 1/23/2007. > I'll narrow it down further though, and then try user threads on > Solaris > (which will probably require repairing initialization order to make > them work > again anyway). > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: formsedit crash > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > The formsedit crash appears to have started between 12/1/2006 and > 3/1/2007. > I will confirm and further narrow this down over the next few days. > I've been building various dates/versions and seeing how they act. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 18 14:47:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Sep 2009 08:47:44 -0400 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: Not exactly. The inCritical counter means there are lots of places that serialize. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 06:12, Jay K wrote: > I thought about this a little..but..don't Modula-3 user threads > preempt at arbitrary points? > > - Jay > > > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Fri, 18 Sep 2009 11:37:48 +0200 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] formsedit crash > > > > I've had some funny race/thread-order conditions when I was > switching to > > pthreads.... Someone lazy got too grooved in with fixed order of > > execution implied by how user threads work. It was in pp package and > > also somewhere I can't remember right now... Will look a bit > through hm3 > > svn (dead in house spinoff of pm3 from times when all mainstream > m3 had > > was user threads). > > > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > > > I have it further narrowed down to the last two weeks of 1/2007. > > > Which is just a few changes. > > > I fear it is the switch from user threads to pthreads on > 1/23/2007. > > > I'll narrow it down further though, and then try user threads on > > > Solaris > > > (which will probably require repairing initialization order to > make > > > them work > > > again anyway). > > > > > > - Jay > > > > > > > > > > > > > ______________________________________________________________________ > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Subject: formsedit crash > > > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > > > > > The formsedit crash appears to have started between 12/1/2006 and > > > 3/1/2007. > > > I will confirm and further narrow this down over the next few > days. > > > I've been building various dates/versions and seeing how they act. > > > > > > - Jay > > > > > > > > > > > > > > -- > > Dragi?a Duri? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 18 14:47:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Sep 2009 08:47:43 -0400 Subject: [M3devel] formsedit crash In-Reply-To: <1253266668.2779.27.camel@faramir.m3w.org> References: <1253266668.2779.27.camel@faramir.m3w.org> Message-ID: Indeed, I fixed one of these races sometime back when switching to pthreads. Should be in the logs. AFAIK formsedit now works. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 05:37, Dragi?a Duri? wrote: > I've had some funny race/thread-order conditions when I was > switching to > pthreads.... Someone lazy got too grooved in with fixed order of > execution implied by how user threads work. It was in pp package and > also somewhere I can't remember right now... Will look a bit through > hm3 > svn (dead in house spinoff of pm3 from times when all mainstream m3 > had > was user threads). > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: >> I have it further narrowed down to the last two weeks of 1/2007. >> Which is just a few changes. >> I fear it is the switch from user threads to pthreads on 1/23/2007. >> I'll narrow it down further though, and then try user threads on >> Solaris >> (which will probably require repairing initialization order to make >> them work >> again anyway). >> >> - Jay >> >> >> >> ______________________________________________________________________ >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: formsedit crash >> Date: Wed, 16 Sep 2009 15:18:54 +0000 >> >> The formsedit crash appears to have started between 12/1/2006 and >> 3/1/2007. >> I will confirm and further narrow this down over the next few days. >> I've been building various dates/versions and seeing how they act. >> >> - Jay >> >> >> >> > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 18 19:50:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 17:50:33 +0000 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: formsedit on SOLgnu very often fails. With current source. -bash-3.00$ ./formsedit *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 ** I added the assert. It is that a pointer is not NIL, on the line before it is dereferenced. I've also seen this on PPC_something (Darwin?) but haven't tried recently. I might say it fails less often now, but it does still fail. The range is now narrowed down to between Jan 20 and Feb 1 2007. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 18 Sep 2009 08:45:18 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] formsedit crash Jay, formsedit now works for me on I386_DARWIN. Not sure what you are trying to track down now. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 03:49, Jay K wrote:I have it further narrowed down to the last two weeks of 1/2007. Which is just a few changes. I fear it is the switch from user threads to pthreads on 1/23/2007. I'll narrow it down further though, and then try user threads on Solaris (which will probably require repairing initialization order to make them work again anyway). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: formsedit crash Date: Wed, 16 Sep 2009 15:18:54 +0000 The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. I will confirm and further narrow this down over the next few days. I've been building various dates/versions and seeing how they act. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 18 20:07:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 18:07:38 +0000 Subject: [M3devel] formsedit crash In-Reply-To: <20090918175906.8C4991A2094@async.async.caltech.edu> References: Message-ID: There was a problem around the RC2 timeframe where garbage collection was turned off entirely. It wasn't that way for a long time, but indeed it was a very bad thing. Segfault could be due to out of memory. I think what I've been seeing is different. I've built many versions of the source tree now, including current. And the below is my finding -- SOLgnu formsedit works for very many timestamps on or prior to Jan 20 2007 and fails for very many timestamps on or after Feb 1 2007, including current. (dates are US Pacific time, don't /quite/ match up to the ChangeLog, behind about 9 hours.) Whether or not PPC_DARWIN is broken on current, not yet determined. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] formsedit crash > Date: Fri, 18 Sep 2009 10:59:06 -0700 > From: mika at async.async.caltech.edu > > > I just wanted to add that I was having enormous problems with a Trestle > application on PPC_DARWIN using sources of about six weeks ago. It was > going catatonic and leaking memory at an alarming rate (and worked > perfectly on FreeBSD/i386 using an old PM3, didn't get around to trying > with new sources). Also the occasional segfault. > > Of course I thought it was my fault, but after reviewing my code carefully > I couldn't find anything wrong, and I updated CM3 today and it looks great---no more crashing or hanging. > > Mika > > Jay K writes: > > > > > >MIME-Version: 1.0 > > > >--_20828071-d627-4e2e-af04-2e79c7e91e22_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >formsedit on SOLgnu very often fails. With current source. > > > >-bash-3.00$ ./formsedit=20 > > > > > >*** > >*** runtime error: > >*** <*ASSERT*> failed. > >*** file "../src/lego/POSIX/ScrollerVBTClass.m3"=2C line 325 > >** > > > >I added the assert. It is that a pointer is not NIL=2C on the line > >before it is dereferenced. > > > >I've also seen this on PPC_something (Darwin?) but haven't tried recently. > >I might say it fails less often now=2C but it does still fail. > > > >The range is now narrowed down to between Jan 20 and Feb 1 2007. > > > > - Jay > > > >From: hosking at cs.purdue.edu > >To: jay.krell at cornell.edu > >Date: Fri=2C 18 Sep 2009 08:45:18 -0400 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] formsedit crash > > > >Jay=2C formsedit now works for me on I386_DARWIN. Not sure what you are tr= > >ying to track down now. > > Antony Hosking | Associate Professor | Computer Science | Purdue Universit= > >y305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 49= > >4 6001 | Mobile +1 765 427 5484=20 > >On 18 Sep 2009=2C at 03:49=2C Jay K wrote:I have it further narrowed down t= > >o the last two weeks of 1/2007. > >Which is just a few changes. > >I fear it is the switch from user threads to pthreads on 1/23/2007. > >I'll narrow it down further though=2C and then try user threads on Solaris > >(which will probably require repairing initialization order to make them wo= > >rk > >again anyway). > > > > - Jay > > > > > >From: jay.krell at cornell.edu > >To: m3devel at elegosoft.com > >Subject: formsedit crash > >Date: Wed=2C 16 Sep 2009 15:18:54 +0000 > > > >The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. > >I will confirm and further narrow this down over the next few days. > >I've been building various dates/versions and seeing how they act. > > > > - Jay > > > > > > > > > > > > = > > > >--_20828071-d627-4e2e-af04-2e79c7e91e22_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >formsedit on SOLgnu very often fails. With current source.

-bash-3.0= > >0$ ./formsedit


***
*** runtime error:
*** =3B =3B= > > =3B <=3B*ASSERT*>=3B failed.
*** =3B =3B =3B file "= > >../src/lego/POSIX/ScrollerVBTClass.m3"=2C line 325
**

I added the= > > assert. It is that a pointer is not NIL=2C on the line
before it is der= > >eferenced.

I've also seen this on PPC_something (Darwin?) but haven'= > >t tried recently.
I might say it fails less often now=2C but it does sti= > >ll fail.

The range is now narrowed down to between Jan 20 and Feb 1 = > >2007.

 =3B - Jay


From: hosking at cs= > >.purdue.edu
To: jay.krell at cornell.edu
Date: Fri=2C 18 Sep 2009 08:45:= > >18 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] formsedit c= > >rash

Jay=2C formsedit now works for me on I386_DARWIN.  =3BNot s= > >ure what you are trying to track down now.

>Apple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0= > >=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B">
>d=3B"> >e=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= > >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= > >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= > >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>word-wrap: break-word=3B"> >er-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica= > >=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-w= > >eight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-inde= > >nt: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px= > >=3B"> >=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B= > > font-style: normal=3B font-variant: normal=3B font-weight: normal=3B lette= > >r-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transf= > >orm: none=3B white-space: normal=3B word-spacing: 0px=3B"> >xApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0= > >=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B"> >" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= > >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= > >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= > >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= > >d-spacing: 0px=3B"> >apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= > >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= > >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= > >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= > >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= > >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= > >ne=3B white-space: normal=3B word-spacing: 0px=3B"> >style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B">
>lass=3D"ecxApple-style-span" face=3D"Gill Sans"> >le-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B"= > >> >font-family: 'Gill Sans'=3B">Antony Hosking >t class=3D"ecxApple-style-span" face=3D"Gill Sans"> >style-span" style=3D"font-family: 'Gill Sans'=3B"> >tyle-span" style=3D"font-family: 'Gill Sans'=3B"> >nverted-space"> =3B|&nb= > >sp=3B >-family: 'Gill Sans'=3B"> >family: 'Gill Sans'=3B">Associate Professor >Apple-style-span" style=3D"font-family: 'Gill Sans'=3B"> >pple-style-span" style=3D"font-family: 'Gill Sans'=3B"> =3B| Computer S= > >cience | Purdue University
>xApple-style-span" face=3D"GillSans-Light"> >an" style=3D"font-family: GillSans-Light=3B">305 N. University Street | Wes= > >t Lafayette | IN 47907 | USA
>e-style-span" color=3D"#0000ff" face=3D"Gill Sans"> >style-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'= > >=3B"> >=3B font-family: 'Gill Sans'=3B">Office >ecxApple-style-span" face=3D"GillSans-Light"> >span" style=3D"font-family: GillSans-Light=3B"> >e-span" style=3D"font-family: GillSans-Light=3B"> =3B+1 765 494 6001 |<= > >span class=3D"ecxApple-converted-space"> =3B >><= > >span class=3D"ecxApple-style-span" style=3D"color: rgb(0=2C 0=2C 255)=3B fo= > >nt-family: 'Gill Sans'=3B"> >or: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">Mobile= > > >ass=3D"ecxApple-style-span" style=3D"font-family: GillSans-Light=3B"> >class=3D"ecxApple-style-span" style=3D"font-family: GillSans-Light=3B"> >n class=3D"ecxApple-converted-space"> =3B+1 765 427 5484<= > >/span>
>s-Light">
>n>

>ine">

>line">

On 18 Sep 2009=2C at 03:49=2C Jay K wrote:
= > >
>ple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: medium=3B font-style: normal=3B = > >font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B li= > >ne-height: normal=3B text-indent: 0px=3B text-transform: none=3B white-spac= > >e: normal=3B word-spacing: 0px=3B">
>t-size: 10pt=3B font-family: Verdana=3B">I have it further narrowed down to= > > the last two weeks of 1/2007.
Which is just a few changes.
I fear it= > > is the switch from user threads to pthreads on 1/23/2007.
I'll narrow i= > >t down further though=2C and then try user threads on Solaris
(which wil= > >l probably require repairing initialization order to make them work
agai= > >n anyway).

 =3B- Jay



From:= > > =3B
>ay.krell at cornell.edu">jay.krell at cornell.edu
To: >le-converted-space"> =3B >>m3devel at elegosoft.com
Subject: formsedit crash
Date: Wed=2C 16 S= > >ep 2009 15:18:54 +0000

The formsedit crash appears to have started b= > >etween 12/1/2006 and 3/1/2007.
I will confirm and further narrow this do= > >wn over the next few days.
I've been building various dates/versions and= > > seeing how they act.

 =3B- Jay




= > >

> >= > > > >--_20828071-d627-4e2e-af04-2e79c7e91e22_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Sep 19 00:40:15 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 19 Sep 2009 00:40:15 +0200 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: <1253313616.6910.2.camel@faramir.m3w.org> Not only inCritical, user space threads are in circular list and scheduler runs (in circles :) ) through it. Meaning, if B comes after A and before C, it's always executed before C after A's timeslice- if ready. On Fri, 2009-09-18 at 08:47 -0400, Tony Hosking wrote: > Not exactly. The inCritical counter means there are lots of places > that serialize. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > On 18 Sep 2009, at 06:12, Jay K wrote: > > > I thought about this a little..but..don't Modula-3 user threads > > preempt at arbitrary points? > > > > - Jay > > > > > > > From: dragisha at m3w.org > > > To: jay.krell at cornell.edu > > > Date: Fri, 18 Sep 2009 11:37:48 +0200 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] formsedit crash > > > > > > I've had some funny race/thread-order conditions when I was > > switching to > > > pthreads.... Someone lazy got too grooved in with fixed order of > > > execution implied by how user threads work. It was in pp package > > and > > > also somewhere I can't remember right now... Will look a bit > > through hm3 > > > svn (dead in house spinoff of pm3 from times when all mainstream > > m3 had > > > was user threads). > > > > > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > > > > I have it further narrowed down to the last two weeks of 1/2007. > > > > Which is just a few changes. > > > > I fear it is the switch from user threads to pthreads on > > 1/23/2007. > > > > I'll narrow it down further though, and then try user threads on > > > > Solaris > > > > (which will probably require repairing initialization order to > > make > > > > them work > > > > again anyway). > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > From: jay.krell at cornell.edu > > > > To: m3devel at elegosoft.com > > > > Subject: formsedit crash > > > > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > > > > > > > The formsedit crash appears to have started between 12/1/2006 > > and > > > > 3/1/2007. > > > > I will confirm and further narrow this down over the next few > > days. > > > > I've been building various dates/versions and seeing how they > > act. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > -- > > > Dragi?a Duri? > > > > > > -- Dragi?a Duri? From mbishop at esoteriq.org Sat Sep 19 01:22:06 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 18 Sep 2009 18:22:06 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? Message-ID: <4AB4161E.6050900@esoteriq.org> Why does everything install into /usr/local/cm3/* ? I tried editing my PATH variable to get the cm3 binary in there, but I still have to 'source /etc/profile' with every shell. And if I symlink it, it causes problems. Is there a reason to not just install to normal positions like /usr/bin and /usr/lib, etc? Is it possible to tell cminstall where to install other the default /usr/local/cm3 ? From jay.krell at cornell.edu Sun Sep 20 01:31:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Sep 2009 23:31:18 +0000 Subject: [M3devel] Utime.struct_tm Message-ID: struct_tm = RECORD tm_sec: int; tm_min: int; tm_hour: int; tm_mday: int; tm_mon: int; tm_year: int; tm_wday: int; tm_yday: int; tm_isdst: int; (* here *) tm_gmtoff:INTEGER; tm_zone: char_star; END; ? The fields after tm_isdst are not always present, and perhaps not always in that order. Portable code, Modula-3, C, or otherwise, cannot refer to those last two fields. C can do it with #ifdefs or autoconf-assisted and with some alternative if they are not present. ? What to do? Generally the vast majority of platform-dependency should and has been removed from the system, for much easier (and therefore generally more correct) porting. ? Today we declare struct_tm per-target. Most targets do declare the fields, but: Cygwin, Irix, HP-UX, Interix, Solaris do not. "Most" therefore leaves at least Linux, *BSD, Darwin. I do hope to bring up a few more targets, which may contribute to one set or the other. ? And I just checked that Solaris really doesn't provide the fields in C, so we can claim that mainstream platforms are part of the "problem". ? There are a few options: - leave it as system-dependent; my least favorite - define it to have the common prefix and provide copying C wrappers This allows for some portable uses. You can't just define the common prefix and allow direct calls, as that would corrupt the stack where it is an output. This would not allow for embedding the struct in any target-defined structs, but that probably never occurs. - remove it from m3core and all functions that traffic in it -- localtime, mktime, etc. This is my favorite. ok? Anyone that needs this functionality can chose from using interface Date, or writing portable C. I'm going to go ahead and do this. ok? ? And in any case, rewrite m3-libs\m3core\src\time in #ifdef'ed C, at least wherever struct_tm is used. I'm going to go ahead and do this. ok? ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 20 03:23:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 01:23:06 +0000 Subject: [M3devel] porting documentation? Message-ID: Hey, I've started writing up some new porting instructions. Can I get someone to try testing them out? By actually porting to a new platform? While I haven't really looked into this, I'm betting that I386_DFLYBSD or AMD64_DFLYBSD might be a good first choice? (DragonFly BSD, suggested platform names welcome) I would suggest you - install it in a virtual machine - work from a system with fast fork (ie: anything other than Cygwin) Anyone who has ported CM3 in the past is barred from this invitation. :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 20 05:24:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 03:24:58 +0000 Subject: [M3devel] Juno/win32threads Message-ID: Tony, the behavior still seems the same. (a74.f50): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c edi=00200000 eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 m3core!Thread__Join+0x14b: 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds:0023:001ffffc=???????? 0:000> 0:000> r edi edi=00200000 Can you maybe debug this on birch? I can e.g. put debuggers at \bin\x86\cdb (just install them locally which involves some GUI, then tar/gz them up and untar/gz..you don't need the installer to run, can just copy them around) and then you can like: ssh hudson at birch.elegosoft.com ssh elego at localhost2 /cygdrive/c/bin/x86/cdb ./Juno.exe Just be sure not to run Juno outside of a debugger..not sure what will happen, but you won't be able to see it. Or, feel free to commit some version that uses RTIO a bunch and I can send you the output. Slow turnaround that way. Clearly nobody is using any of this stuff.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 00:28:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 22:28:21 +0000 Subject: [M3devel] time.h reentrancy? Message-ID: Does anyone understand how the time.h *_r functions are supposed to behave wrt the char* tm_zone field in struct tm? This interface seems broken. Posix doesn't include the tm_zone field, so it is self-consistent. I think therefore even though DateBsd.m3 uses the _r functions, it should serialize. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 00:54:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 22:54:09 +0000 Subject: [M3devel] time.h reentrancy? In-Reply-To: References: Message-ID: My plan here is roughly: copy Utime.i3 to UtimeInternal.i3. Keeping only functions that traffic in struct_tm. In Utime.i3 define a struct_tm that doesn't have tm_zone and tm_gmtoff. UtimeInternal.i3 define a struct_tm that does include tm_zone and tm_gmtoff. Provide UtimeInternal.i3 only on platforms that use DateBsd.m3. Utime.i3 will therefore be portable. Both of them will be implemented via copying wrappers though, since the order of the fields, and the exact size of the struct, is not portable. Probably as well only the *_r functions should be provided? Not clear, since the non *_r functions have optional extra side affects such as setting tznzme. Probably keep the non *_r functions but callers must know to (maybe) serialize them. As DatePosix.m3/DateBsd.m3 do. I think most libc implementations use thread locals here, so the need to serialize is nearly zero. However there are user threads and timezone/daylight/tzname to worry about, not sure they are thread locals, or only the "direct result buffers". This area is really a mess. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 20 Sep 2009 22:28:21 +0000 Subject: [M3devel] time.h reentrancy? Does anyone understand how the time.h *_r functions are supposed to behave wrt the char* tm_zone field in struct tm? This interface seems broken. Posix doesn't include the tm_zone field, so it is self-consistent. I think therefore even though DateBsd.m3 uses the _r functions, it should serialize. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 21 04:04:20 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Sep 2009 22:04:20 -0400 Subject: [M3devel] Juno/win32threads In-Reply-To: References: Message-ID: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> I don't think anything I changed affects Windows. On 19 Sep 2009, at 23:24, Jay K wrote: > Tony, the behavior still seems the same. > > (a74.f50): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c > edi=00200000 > eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl zr > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010246 > m3core!Thread__Join+0x14b: > 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: > 0023:001ffffc=???????? > 0:000> > 0:000> r edi > edi=00200000 > > > Can you maybe debug this on birch? > > I can e.g. put debuggers at \bin\x86\cdb > (just install them locally which involves some GUI, then tar/gz > them up and untar/gz..you don't need the installer to run, can just > copy them around) > and then you can like: > > ssh hudson at birch.elegosoft.com > ssh elego at localhost2 > /cygdrive/c/bin/x86/cdb ./Juno.exe > > Just be sure not to run Juno outside of a debugger..not sure what > will happen, but you won't be able to see it. > > Or, feel free to commit some version that uses RTIO a bunch and I > can send you the output. > Slow turnaround that way. > Clearly nobody is using any of this stuff.. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 06:14:32 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 20 Sep 2009 21:14:32 -0700 Subject: [M3devel] Juno/win32threads In-Reply-To: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> Message-ID: <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> Eh? Tony, the thread changes from around feb 20 that you recently 'unmerged'? These crashes seem to date from around Feb, more precise info in my other mails.. - Jay (phone) On Sep 20, 2009, at 7:04 PM, Tony Hosking wrote: > I don't think anything I changed affects Windows. > > On 19 Sep 2009, at 23:24, Jay K wrote: > >> Tony, the behavior still seems the same. >> >> (a74.f50): Access violation - code c0000005 (first chance) >> First chance exceptions are reported before any exception handling. >> This exception may be expected and handled. >> eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c >> edi=00200000 >> eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl >> zr na pe nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00010246 >> m3core!Thread__Join+0x14b: >> 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: >> 0023:001ffffc=???????? >> 0:000> >> 0:000> r edi >> edi=00200000 >> >> >> Can you maybe debug this on birch? >> >> I can e.g. put debuggers at \bin\x86\cdb >> (just install them locally which involves some GUI, then tar/gz >> them up and untar/gz..you don't need the installer to run, can just >> copy them around) >> and then you can like: >> >> ssh hudson at birch.elegosoft.com >> ssh elego at localhost2 >> /cygdrive/c/bin/x86/cdb ./Juno.exe >> >> Just be sure not to run Juno outside of a debugger..not sure what >> will happen, but you won't be able to see it. >> >> Or, feel free to commit some version that uses RTIO a bunch and I >> can send you the output. >> Slow turnaround that way. >> Clearly nobody is using any of this stuff.. >> >> - Jay >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 21 15:53:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Sep 2009 09:53:56 -0400 Subject: [M3devel] Juno/win32threads In-Reply-To: <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> Message-ID: <562F0E0F-C56D-4A8F-B845-2F9E86599C37@cs.purdue.edu> OK, I've lost track, since we've been discussing two different things: the problems with pthreads which I just fixed, and the Windows threading problem. What is the time-frame that I should be looking at for that problem? On 21 Sep 2009, at 00:14, jay.krell at cornell.edu wrote: > Eh? Tony, the thread changes from around feb 20 that you recently > 'unmerged'? These crashes seem to date from around Feb, more precise > info in my other mails.. > > - Jay (phone) > > On Sep 20, 2009, at 7:04 PM, Tony Hosking > wrote: > >> I don't think anything I changed affects Windows. >> >> On 19 Sep 2009, at 23:24, Jay K wrote: >> >>> Tony, the behavior still seems the same. >>> >>> (a74.f50): Access violation - code c0000005 (first chance) >>> First chance exceptions are reported before any exception handling. >>> This exception may be expected and handled. >>> eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c >>> edi=00200000 >>> eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl >>> zr na pe nc >>> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >>> efl=00010246 >>> m3core!Thread__Join+0x14b: >>> 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: >>> 0023:001ffffc=???????? >>> 0:000> >>> 0:000> r edi >>> edi=00200000 >>> >>> >>> Can you maybe debug this on birch? >>> >>> I can e.g. put debuggers at \bin\x86\cdb >>> (just install them locally which involves some GUI, then tar/gz >>> them up and untar/gz..you don't need the installer to run, can >>> just copy them around) >>> and then you can like: >>> >>> ssh hudson at birch.elegosoft.com >>> ssh elego at localhost2 >>> /cygdrive/c/bin/x86/cdb ./Juno.exe >>> >>> Just be sure not to run Juno outside of a debugger..not sure what >>> will happen, but you won't be able to see it. >>> >>> Or, feel free to commit some version that uses RTIO a bunch and I >>> can send you the output. >>> Slow turnaround that way. >>> Clearly nobody is using any of this stuff.. >>> >>> - Jay >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 21 16:03:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Sep 2009 10:03:32 -0400 Subject: [M3devel] Juno/win32threads In-Reply-To: <562F0E0F-C56D-4A8F-B845-2F9E86599C37@cs.purdue.edu> References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> <562F0E0F-C56D-4A8F-B845-2F9E86599C37@cs.purdue.edu> Message-ID: P.S. I did commit back some changes to ThreadWin32.m3 which backed out some of 1.30. Did you try those? On 21 Sep 2009, at 09:53, Tony Hosking wrote: > OK, I've lost track, since we've been discussing two different > things: the problems with pthreads which I just fixed, and the > Windows threading problem. What is the time-frame that I should be > looking at for that problem? > > On 21 Sep 2009, at 00:14, jay.krell at cornell.edu wrote: > >> Eh? Tony, the thread changes from around feb 20 that you recently >> 'unmerged'? These crashes seem to date from around Feb, more >> precise info in my other mails.. >> >> - Jay (phone) >> >> On Sep 20, 2009, at 7:04 PM, Tony Hosking >> wrote: >> >>> I don't think anything I changed affects Windows. >>> >>> On 19 Sep 2009, at 23:24, Jay K wrote: >>> >>>> Tony, the behavior still seems the same. >>>> >>>> (a74.f50): Access violation - code c0000005 (first chance) >>>> First chance exceptions are reported before any exception handling. >>>> This exception may be expected and handled. >>>> eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c >>>> edi=00200000 >>>> eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl >>>> zr na pe nc >>>> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >>>> efl=00010246 >>>> m3core!Thread__Join+0x14b: >>>> 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: >>>> 0023:001ffffc=???????? >>>> 0:000> >>>> 0:000> r edi >>>> edi=00200000 >>>> >>>> >>>> Can you maybe debug this on birch? >>>> >>>> I can e.g. put debuggers at \bin\x86\cdb >>>> (just install them locally which involves some GUI, then tar/gz >>>> them up and untar/gz..you don't need the installer to run, can >>>> just copy them around) >>>> and then you can like: >>>> >>>> ssh hudson at birch.elegosoft.com >>>> ssh elego at localhost2 >>>> /cygdrive/c/bin/x86/cdb ./Juno.exe >>>> >>>> Just be sure not to run Juno outside of a debugger..not sure what >>>> will happen, but you won't be able to see it. >>>> >>>> Or, feel free to commit some version that uses RTIO a bunch and I >>>> can send you the output. >>>> Slow turnaround that way. >>>> Clearly nobody is using any of this stuff.. >>>> >>>> - Jay >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Sep 21 16:25:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 21 Sep 2009 16:25:12 +0200 Subject: [M3devel] back again -- cm3 status worse? Message-ID: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> Hi all, I'm back again from my trip to France. Though there seems to have been lots of activity during my absence, the current status is worse than when I left: o tinderbox status is comletely red o Hudson builds fail due to syntax errors o no tickets have been closed or even changed Does anybody care to fix? It would be nice if we could at least backup to the status of when I left... A summary about the activities/changes would be welcome. I'll need some days to read all the mails. So long, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Sep 21 22:13:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Sep 2009 20:13:21 +0000 Subject: [M3devel] Juno/win32threads In-Reply-To: References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> Message-ID: Yes that's what I was referring to. You were already looking at the right timeframe, around Feb 20 2009. Earlier mail has a 30 minute window identified. -Jay From: hosking at cs.purdue.edu To: hosking at cs.purdue.edu Date: Mon, 21 Sep 2009 10:03:32 -0400 CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] Juno/win32threads P.S. I did commit back some changes to ThreadWin32.m3 which backed out some of 1.30. Did you try those? On 21 Sep 2009, at 09:53, Tony Hosking wrote: OK, I've lost track, since we've been discussing two different things: the problems with pthreads which I just fixed, and the Windows threading problem. What is the time-frame that I should be looking at for that problem? On 21 Sep 2009, at 00:14, jay.krell at cornell.edu wrote: Eh? Tony, the thread changes from around feb 20 that you recently 'unmerged'? These crashes seem to date from around Feb, more precise info in my other mails.. - Jay (phone) On Sep 20, 2009, at 7:04 PM, Tony Hosking wrote: I don't think anything I changed affects Windows. On 19 Sep 2009, at 23:24, Jay K wrote: Tony, the behavior still seems the same. (a74.f50): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c edi=00200000 eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 m3core!Thread__Join+0x14b: 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds:0023:001ffffc=???????? 0:000> 0:000> r edi edi=00200000 Can you maybe debug this on birch? I can e.g. put debuggers at \bin\x86\cdb (just install them locally which involves some GUI, then tar/gz them up and untar/gz..you don't need the installer to run, can just copy them around) and then you can like: ssh hudson at birch.elegosoft.com ssh elego at localhost2 /cygdrive/c/bin/x86/cdb ./Juno.exe Just be sure not to run Juno outside of a debugger..not sure what will happen, but you won't be able to see it. Or, feel free to commit some version that uses RTIO a bunch and I can send you the output. Slow turnaround that way. Clearly nobody is using any of this stuff.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 22:16:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Sep 2009 20:16:22 +0000 Subject: [M3devel] back again -- cm3 status worse? In-Reply-To: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> Message-ID: Welcome back! Things are definitely a bit better, even if the high level status looks worse. But there are still imho two severe problems needing fixing for this release. - longstanding pthread problem fixed by Tony -- Darwin hangs fixed fix ported to release (head has further diverged) - Win32 threading/gui still has a problem (Juno crashing, worse than its usual assertion failure due to incomplete Trestle) date the problem started identified (around Feb 20 2009, but more precise information is known) - approx date the Solaris formsedit problem started identified unfortunately it was the switch from userthreads to pthreads (approx Jan 20 2007, probably 23) Tony looking at it. - Solaris tests or hudson were hung somewhere, I couldn't figure out what was running (seemingly nothing), rebooted the machine - Solaris not liking date +%s in pkgmap.sh I checked in a fix but messed up, that's the red in Tinderbox, testing now - I commited .msi building on release, I think it'll work, based on the console output, but waiting for an RC4 download to test. still should do .deb building - Usysdep reduction, only in head, not for this release - Jay > Date: Mon, 21 Sep 2009 16:25:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] back again -- cm3 status worse? > > Hi all, > > I'm back again from my trip to France. Though there seems to have been > lots of activity during my absence, the current status is worse > than when I left: > > o tinderbox status is comletely red > o Hudson builds fail due to syntax errors > o no tickets have been closed or even changed > > Does anybody care to fix? It would be nice if we could at least backup > to the status of when I left... > > A summary about the activities/changes would be welcome. I'll need > some days to read all the mails. > > So long, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 13:21:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 13:21:46 +0200 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Hi Randy, Tony, Jay and all others, thanks for your updates. Things already look better in Hudson and Tinderbox; there may still be some script failures which need manual intervention. As this mail is relevant for all M3 committers, I've CC'ed it to m3devel, too. I understand that a major bug (race condition in pthreads) has been fixed, but there are still some problems in Windows' threads and Solaris' formsedit which are currently investigated. I'll try to add some information of your summaries to the Trac roadmap soon. I think the main problem currently for release engineering is in procedure: we all need to agree to use the same tools and rules for proper collaboration. I know that I may have introduced a bit much in this respect for the small M3 community, but the m3devel list really proved inadequate at least for me to accomplish the tasks related to release engineering for 5.8. So I suggest we use all the available tools (Tinderbox, Hudson, Trac) at least for this release (and may improve the tools and procedures later). Very likely I haven't provided enough information regarding the tool use and intended procedure though, so I'll try to sum up some important points for everybody (again?): o Release engineering is performed on the cm3_branch_release_5_8. This should decouple (stabilizing) bug fixes from potentially destabilizing other commits. CVS is still used for version control; the steps needed to perform merges to the release branch are 'cvs update -j rev' (two point merge) or 'cvs update -j rev -j rev' (three point merge, general case). All merges in CVS are performed in a local workspace and need to be committed explicitly (after local testing, at least proper compilation). o The continuous integration in Hudson I tried to set up during the recent months is currently tracking the release branch and should be used as an indicator for the release quality. o After every commit to the release branch the developer involved should observe the results in the Hudson CI. The lastok-build and release-build jobs on all platforms should succeed (color blue); some tests may be expected to fail (color yellow). None of the main jobs should be read at any time (network communication problems may lead to failures though, usually indicated by `failed to join the process' in the console log). In case of any regression (build failures, more test failures), the problem should either be fixed or the changes reverted (until something better is available). o Anybody logged-in to Hudson can also start jobs manually with the build button. This should be used with case though. In general, jobs should be triggered by CVS checkins. o Trac is used to manage the procedural aspects of the release engineering process, i.e. define milestones and create, change and close tickets for issues related to bugs and other tasks. It also contains a WiKi for project documentation and is integrated with CVS and Hudson. It should be easy to use, but the current setup still has some problems (manual administration needed). Everybody who participates in source changes should also have access to trac and update related tickets at the same time. Indeed, for release engineering there should be no commit at all without an associated ticket. o The release engineer's role I'm trying to perform for the current release does mainly include janitorial services like merging fixes, writing scripts for package builds and tests, performing builds and installation and other tests. This is more than enough work for one person; others are expected to analyze failures and collaborate by providing the changes and information needed via the established tools and procedures. I think the current setup, though still a bit fragile, should be a quite good base for building and documenting a usable CM3 release. I'm not able to perform the required tasks just based on the commit and m3devel mails (I'm often even unable to read them all, and doubt others will do better there). So please use all the installed tools as best as you can. As concrete steps to continue with the 5.8 release I suggest these: (1) Review of all open tickets and appropriate updates and comments. See https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+Release+5.8+RC3 and https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+release+5.8 (links from the roadmap page of trac) (2) Create missing tickets for problems not yet described. Add complete information (error messages, stack traces etc.). Jay's list suggest a couple of new tickets I think. (3) Abandon the RC3 pacakges and retarget everything to RC4 in two or three weeks. (4) Retarget the final release to the end of October (at least). Does this sound reasonable? All help and cooperations is greatly appreciated as usual. Especially anybody to help creating and updating tickets for everything reported on m3devel and m3commit would be welcome. Olaf Quoting Tony Hosking : > I am confident that pthread-based threading is now better than it has > ever been (there was a nasty race that has been thoroughly fixed, and > the logic is now much simpler to understand). It runs all the X11 > apps (juno, mentor, formsedit) without problems. In sum, I think > pthread threading is ready for prime-time. I have never made more > than trivial changes to the WIN32 threads implementation. I don't > know the current state of things there, but hope that our Windows > enthusiasts can test things thoroughly. > > On 21 Sep 2009, at 10:46, Randy Coleburn wrote: > >> Olaf: >> >> I ran a build last night on both XP and Vista. I have not noticed >> any new problems on these platforms. I note that Jay has added >> more commits since last night, so I haven't tried these yet. (I >> am pulling from the head branch for these builds.) >> >> Also, I note that Jay says he is going to rewrite some of the Date >> stuff into C--again I would like to ask why, but I don't want to >> be seen as causing problems. Perhaps he should say why he feels >> it necessary to recode in C versus fixing whatever problem exists >> in Modula-3. I would be willing to work on any Modula-3 coding >> problem if given the chance. >> >> I am concerned about all the message traffic of late about >> suspected problems with the threading. I use threads a lot and if >> they aren't working correctly this is going to be a real problem. >> I ran a quick test using one of my multithreaded programs, but >> didn't see any problem. Unfortunately, this program requires >> connection to some specialized hardware that I don't have access >> to in order to give it a real workout. >> >> Regards, >> Randy >> >>>>> Olaf Wagner 9/21/2009 10:25 AM >>> >> Hi all, >> >> I'm back again from my trip to France. Though there seems to have been >> lots of activity during my absence, the current status is worse >> than when I left: >> >> o tinderbox status is comletely red >> o Hudson builds fail due to syntax errors >> o no tickets have been closed or even changed >> >> Does anybody care to fix? It would be nice if we could at least backup >> to the status of when I left... >> >> A summary about the activities/changes would be welcome. I'll need >> some days to read all the mails. >> >> So long, >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 22 13:55:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 11:55:36 +0000 Subject: [M3devel] web page messed up Message-ID: Olaf, this page: http://www.modula3.com/cm3/index.html has a glaring problem right at the start. I checked in a fix weeks ago. How does one get the update to appear? I'm referring to the nested frames. Surely that was a typo. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 14:16:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 12:16:25 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 15:21:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 15:21:16 +0200 Subject: [M3devel] web page messed up In-Reply-To: References: Message-ID: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> Quoting Jay K : > Olaf, this page: > > http://www.modula3.com/cm3/index.html > > has a glaring problem right at the start. It displays OK for me using Firefox and Opera. What's the problem? I won't say it looks good, but it displays its info ;-) > I checked in a fix weeks ago. > How does one get the update to appear? Copy the file to the web servers root on birch. However, only do this if you are really sure (locally tested etc.). It's the same procedure as for the releng packages, only the path is shorter. > I'm referring to the nested frames. > > Surely that was a typo. > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Tue Sep 22 15:40:12 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 09:40:12 -0400 Subject: [M3devel] web page messed up In-Reply-To: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> References: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> Message-ID: <4AB89AD2.1E75.00D7.1@scires.com> In IE, I see a box on the home page with horizontal and vertical scroll bars. Inside the box it has News items. This box doesn't appear to be resizable, so it is much smaller than the rest of the window when the window is maximized. Not sure if this is the desired behavior, but I don't like it. I also don't like the sea-sick green color scheme. IMO it is harder to read the text. I liked the prior "yellow and white" scheme better than this one. But, you won't please everybody no matter what you do. To me the most important thing now is content, so you haven't heard me complaining about the colors (at least not until now, sorry). On Firefox on Vista, the News box has same behavior as in IE. --Randy >>> Olaf Wagner 9/22/2009 9:21 AM >>> Quoting Jay K : > Olaf, this page: > > http://www.modula3.com/cm3/index.html > > has a glaring problem right at the start. It displays OK for me using Firefox and Opera. What's the problem? I won't say it looks good, but it displays its info ;-) > I checked in a fix weeks ago. > How does one get the update to appear? Copy the file to the web servers root on birch. However, only do this if you are really sure (locally tested etc.). It's the same procedure as for the releng packages, only the path is shorter. > I'm referring to the nested frames. > > Surely that was a typo. > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 15:38:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 13:38:19 +0000 Subject: [M3devel] web page messed up In-Reply-To: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> References: Message-ID: It is bad for me in Firefox. The frames are nested. See: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/www/start.html.diff?r1=1.3.2.2;r2=1.3.2.3;f=u - Jay > Date: Tue, 22 Sep 2009 15:21:16 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: web page messed up > > Quoting Jay K : > > > Olaf, this page: > > > > http://www.modula3.com/cm3/index.html > > > > has a glaring problem right at the start. > > It displays OK for me using Firefox and Opera. What's the problem? > I won't say it looks good, but it displays its info ;-) > > > I checked in a fix weeks ago. > > How does one get the update to appear? > > Copy the file to the web servers root on birch. However, only do this > if you are really sure (locally tested etc.). It's the same procedure > as for the releng packages, only the path is shorter. > > > I'm referring to the nested frames. > > > > Surely that was a typo. > > > > - Jay > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 15:45:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 15:45:55 +0200 Subject: [M3devel] Fwd: Re: CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Message-ID: <20090922154555.d98ygvj34kwosogo@mail.elegosoft.com> Forward to list as it may be of interest for others: ----- Forwarded message from wagner at elegosoft.com ----- Date: Tue, 22 Sep 2009 15:44:05 +0200 From: Olaf Wagner Reply-To: Olaf Wagner Subject: Re: [M3devel] CM3 5.8 Release Engineering,was Re: back again -- cm3 status worse? To: Randy Coleburn Quoting Randy Coleburn : > Olaf: > > You stated the following about CVS: > >>>> Olaf Wagner wagner at elegosoft.com> 9/22/2009 7:21 AM >> ( >>>> mailto:wagner at elegosoft.com> ) > ... > o Release engineering is performed on the cm3_branch_release_5_8. > This should decouple (stabilizing) bug fixes from potentially > destabilizing other commits. CVS is still used for version control; > the steps needed to perform merges to the release branch are > 'cvs update -j rev' (two point merge) or 'cvs update -j rev -j rev' > (three point merge, general case). All merges in CVS are performed > in a local workspace and need to be committed explicitly (after > local testing, at least proper compilation). > ... > > I'm sorry, but I'm not fully up-to-speed on all these various CVS > options, particularly with branching and merging. I've tried to > better understand it by reading some of the TortoiseCVS > documentation, but alas, it leaves much to be desired. No problem, I'll try to explain it in more detail. > Am I to understand that we should continue to commit changes to the > repository as before (I suppose this is the HEAD branch), then for > those changes that pertain to the release, we have to merge the > changes from the head to the release branch using one of the options > you mention? Both options are possible: (a) fix on the main trunk, then merge into release branch (b) fix directly on the release branch, back merge after the release (or just later) Anyway the merge takes place in the local workspace and should be tested locally before commit. I'll care for (b) sometime after the release. > Not sure what 2-point and 3-point merges are all about. The general case when merging looks like this: a -> b -> c -> d -> e -> f (trunk head) \->p -> q -> r -> s (branch tip) Suppose you want to merge the changes from d to e into the branch. (1) You update your workspace to the branch: cvs up -r (2) You merge in the changes (`join'): cvs up -j d -j e (3) compile and test (4) Commit to the branch (thereby creating version t): cvs commit -m 'merge changes from d to e from the main trunk' This is called a three-point-merge because you explicitly specify the start, end, and target versions. If you leave out one of the -j options above, CVS implicitly assumes the common ancestor of the versions involved as the third point (in this case b). So `cvs up -j e' would merge the changes from b to e into the workspace. Two more examples (same scenario): o To merge the changes from c to f just specify these versions: cvs up -j c -j f o To revert the change committed as q use cvs up -j q -j p which applies the inverse delta to the workspace (note the order). Does this explain it more clearly? If anybody is unsure how to merge, I'm happy if he (or she) sends me two tags or file versions for inclusion into the release branch. Two simple rules: o It is always a good idea to tag any commit with a unique tag (label). o If more than one file is involved, tags are more or less mandatory (as lists of pairs of versions for every file are very tedious to handle). I'm afraid I don't know offhand how to merge in TurtoiseCVS :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 22 15:47:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 13:47:35 +0000 Subject: [M3devel] m3 cvs web site slightly regressed? Message-ID: Browing CVS on the web, http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/#dirlist et. al.: - icons are x's - colors are missing in dir listing -- perhaps an improvement - preferred diff format doesn't have the coloring so can't really see it but unified view works ok. Problems seen on IE/XP and Firefox/Mac10.5. Not a big deal. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Sep 22 16:00:05 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 10:00:05 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: <4AB89F7B.1E75.00D7.1@scires.com> Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 16:02:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 16:02:36 +0200 Subject: [M3devel] the so_linger inconsistency between Posix and Windows In-Reply-To: References: Message-ID: <20090922160236.mnz8m23fusk4cokc@mail.elegosoft.com> Quoting Jay K : > What I wish we had but don't know if we have, is some major Modula-3 > user of sockets on both Posix and Windows, so that the change can be > tested. All stuff based on network objects. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 22 20:52:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 18:52:37 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4AB89F7B.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 20:57:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 18:57:27 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4AB89F7B.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? and new content: I don't like to speculate if there are problems, and if only one person sees them (even if it is me), that is close to speculation. It is good to get independent verification. You shouldn't need to test your specific code. Just run Juno under a debugger a few times and see if it access violates. Assertion failures I think are ok, unless they are asserting e.g. foo != NIL on the line before derefencing foo (as formsedit now does). - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Tue, 22 Sep 2009 18:52:37 +0000 > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Sep 22 23:06:20 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 17:06:20 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: <4AB90405.1E75.00D7.1@scires.com> Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy >>> Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? and new content: I don't like to speculate if there are problems, and if only one person sees them (even if it is me), that is close to speculation. It is good to get independent verification. You shouldn't need to test your specific code. Just run Juno under a debugger a few times and see if it access violates. Assertion failures I think are ok, unless they are asserting e.g. foo != NIL on the line before derefencing foo (as formsedit now does). - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Tue, 22 Sep 2009 18:52:37 +0000 > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 23:39:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 21:39:53 +0000 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB90405.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy >>> Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? and new content: I don't like to speculate if there are problems, and if only one person sees them (even if it is me), that is close to speculation. It is good to get independent verification. You shouldn't need to test your specific code. Just run Juno under a debugger a few times and see if it access violates. Assertion failures I think are ok, unless they are asserting e.g. foo != NIL on the line before derefencing foo (as formsedit now does). - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Tue, 22 Sep 2009 18:52:37 +0000 > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 22 23:46:21 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 17:46:21 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: > > Again, what I see is that many versions before around Feb 20 2007 > consistently fail with that same assertion failure. > > I have tested many versions now, recently. > > But versions after Feb 20 2007 usually access violate on the address > 0x20000 or so, sometimes other addresses, sometimes various > assertion failures. I believe this is much worse than merely always > failing the same assertion. > > > > - Jay > > > > Date: Tue, 22 Sep 2009 17:06:20 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] more info on juno on windows > > > > > Do we know whether or not Juno ever worked on Windows ? > > I don't recall ever testing it on Windows. I still have a vd5.7.0 > cm3 that I used for the project I finished up last year (August > 2008). If I run Juno on this system (Windows XP SP3), Juno crashes > with an ASSERT failure at line 165 in winvbt/WinContext.m3. The > date on the juno.exe is 8/19/2008. > > Regards, > Randy > >>>> Jay K 9/22/2009 2:57 PM >>> > Here is the truncated part from the previous: > > This change, I think, causes Juno to access violate whereas before > it "only" failed assertions. > I believe it is considered fairly ok for a safe system to terminate > with an assertion failure, > that might not be a bug at all, but considered far worse to hit a > SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Sep 22 23:58:52 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 17:58:52 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> Message-ID: <4AB91054.1E75.00D7.1@scires.com> Tony: I just tried these options. Here are results: recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line 1706, while nogc gets assert in WinContext.m3 line 165. I note that the juno window begins drawing before the crash on nogc whereas it does not on paranoidgc. recent cm3 on Vista, same results as above except that it appears to reference an illegal memory location before hitting the assert in the RTCollector when using paranoidgc. old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to abort the repeating error message. Not sure if anything else happens first because it scrolls too far. For nogc, we get same behavoir as the other tests above. Regards, Randy >>> Tony Hosking 9/22/2009 5:46 PM >>> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 00:11:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 22:11:26 +0000 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB91054.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: current: nogc "works" -- always the WinContext/PushPixmap assertion failure paranoidgc is broken the same as default -- variety of assertion failures and access violations Including but NOT limited to: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 1708 *** which is in RefSanityCheck, doesn't look useful. still many access violations at 00200000-4. I think 00200000 just happens to be some pixmap data from the splash screen that clobbered some other data but I don't know. I posted a big hex dump the other week to see if anyone could confirm it looks like pixmaps. - Jay Date: Tue, 22 Sep 2009 17:58:52 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] more info on juno on windows Tony: I just tried these options. Here are results: recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line 1706, while nogc gets assert in WinContext.m3 line 165. I note that the juno window begins drawing before the crash on nogc whereas it does not on paranoidgc. recent cm3 on Vista, same results as above except that it appears to reference an illegal memory location before hitting the assert in the RTCollector when using paranoidgc. old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to abort the repeating error message. Not sure if anything else happens first because it scrolls too far. For nogc, we get same behavoir as the other tests above. Regards, Randy >>> Tony Hosking 9/22/2009 5:46 PM >>> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 03:34:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:34:06 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB91054.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> <4AB91054.1E75.00D7.1@scires.com> Message-ID: PS Running with nogc at least makes sure that you don't get the garbage collector moving things around, so it should be easier to diagnose who is doing the clobbering. Can you debug with h/w watchpoints to see who overwrites the heap. You'd need to watch the location from which the bogus reference (00200000) gets loaded, which means figuring out where the load occurred. On 22 Sep 2009, at 17:58, Randy Coleburn wrote: > Tony: > > I just tried these options. Here are results: > > recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line > 1706, while nogc gets assert in WinContext.m3 line 165. I note that > the juno window begins drawing before the crash on nogc whereas it > does not on paranoidgc. > > recent cm3 on Vista, same results as above except that it appears to > reference an illegal memory location before hitting the assert in > the RTCollector when using paranoidgc. > > old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating > assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to > abort the repeating error message. Not sure if anything else > happens first because it scrolls too far. For nogc, we get same > behavoir as the other tests above. > > Regards, > Randy > > >>> Tony Hosking 9/22/2009 5:46 PM >>> > Have you tried running with @M3nogc? And @M3paranoidgc? > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Sep 2009, at 17:39, Jay K wrote: > >> >> Again, what I see is that many versions before around Feb 20 2007 >> consistently fail with that same assertion failure. >> >> I have tested many versions now, recently. >> >> But versions after Feb 20 2007 usually access violate on the >> address 0x20000 or so, sometimes other addresses, sometimes various >> assertion failures. I believe this is much worse than merely always >> failing the same assertion. >> >> >> >> - Jay >> >> >> >> Date: Tue, 22 Sep 2009 17:06:20 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] more info on juno on windows >> >> >> >> >> Do we know whether or not Juno ever worked on Windows ? >> >> I don't recall ever testing it on Windows. I still have a vd5.7.0 >> cm3 that I used for the project I finished up last year (August >> 2008). If I run Juno on this system (Windows XP SP3), Juno crashes >> with an ASSERT failure at line 165 in winvbt/WinContext.m3. The >> date on the juno.exe is 8/19/2008. >> >> Regards, >> Randy >> >>>>> Jay K 9/22/2009 2:57 PM >>> >> Here is the truncated part from the previous: >> >> This change, I think, causes Juno to access violate whereas before >> it "only" failed assertions. >> I believe it is considered fairly ok for a safe system to terminate >> with an assertion failure, >> that might not be a bug at all, but considered far worse to hit a >> SIGSEGV > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 03:37:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:37:58 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4AB89F7B.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> <4AB89F7B.1E75.00D7.1@scires.com> Message-ID: On 22 Sep 2009, at 10:00, Randy Coleburn wrote: > Jay your message seems truncated again. > > Threads have always worked for me in the past on Windows. Do we > have some sort of tests we can run to prove correctness of > threading? Seems to me that Juno is the only thing that isn't > working right, supposedly wrt threading. Perhaps the problem lies > in Juno and not threads. Maybe Juno is misusing threads in some way > or there is a bug in something Juno uses that exhibits itself as a > thread problem. Granted, the last time I did heavy checks on my > multithreaded code on Windows was before the date you say a problem > was introduced, so maybe it is broken now. In any event, I think > some standard regression type tests would be in order here. If we > don't have them, perhaps Tony could offer some suggestions. I would > be glad to write some of these tests if given some general ideas on > what to check for. I'm not so convinced it is the threading code per se. Could be that we just tripped over it with some random change. The fact that we see problems arising with @M3nogc suggests that the clobber is outside the GC and threading code. Something deeper in the Windows VBT stuff perhaps? > I don't want to get into a big argument with you (or anyone else), > but I do take exception with your statements about Modula-3 being > "tedious, error prone, unsafe, not portable, target-specific." > Perhaps I am misinterpreting you here and you are specifically > referencing a particular set of Modula-3 code that was done poorly. > If so, then perhaps if you could explain what is wrong with the > Modula-3 code in question, one of us can step up to the plate and > make some corrections. If the SPIN folks could write an OS in > Modula-3, surely we can write the compiler and library code in > Modula-3. IMO, writing such code in Modula-3 should give us the > benefits of Modula-3 instead of the deficiencies of C. After all, > this mail list is for Modula-3 enthusiasts. We wouldn't be spending > time if we didn't think this language was great. PS Randy, in this case I think Jay is making the point that all of the Unix interfaces clones from C header files have no guarantees that they match the original C code. Jay's changes should result in a much cleaner, easier to port system, since problems in the bridging code from M3 to C will be caught by the C compiler. > > Regards, > Randy > > >>> Jay K 9/22/2009 8:16 AM >>> > > The problem with the Modula-3 code is the same as usual. > It is tedious, error prone, unsafe, not portable, target-specific. > Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. > The other -- TimePosix.m3, probably ok. > > Not tremendously so in this case, just a little. > > The idea is to drive Usysdep.i3 to empty, but the last bits might > not be worth it. > > > > > The C layer is also tedious and error-prone, and maybe unsafe, > but it is portable and target-independent, which reduces > but tedium and error-proneness. > > > > > Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. > They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) > and > the result is that the safety guaranteeds are broken. > > > > > C code wouldn't have this problem. It would #include and > fail to compile. > > > > > > Yes there is fairly definitely a problem on Windows and it dates, I > think, to this change: > > > > > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > > > > > I'll have to reconfirm that I guess. > I had checked out and built the CVS tree at many dates/times, doing > roughly > binary search, and narrowed it down to this. > > Though Tony has undone this change. > > I admit 1) I haven't really looked at the diffs either way and 2) I > don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code > very well. > > > > ???It might be worthwhile to try to rewrite ThreadWin32.m3 from > scratch, following ThreadPThread.m3 line for line and coming up with > analogs? Along with the unscalable replacement for condition > variables -- taking one global lock around certain things to get > atomiticy? (Search the web for how to implement condition variables > on Win32, you start to get an idea, though Modula-3 doesn't take > anyone else's approach..you see all the literature is very concerned > with the atomicity of certain runs of operations, that you can get > on NT4 and newer at the cost of kernel transitions > (SignalObjectAndWait?) but that Modula-3 gets by using a "giant > lock" in some places, which might be better, might be worse). > > It also might be worthwhile reimplementing for Vista or newer, > verify it at least works, even if the pre-Vista code remains > supported for pre-Vista. (Vista adds condition variables.) > > You know, if that succeeds, it pins the blame on ThreadWin32.m3. > > If it also fails, it leaves it ambiguous as to if both > "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is > elsewhere. > > > > > It /seems/ that Juno's pixmaps are getting copied over other data. > > > > > This change, I think, causes Juno to access violate whereas before > it "only" failed assertions. > > I believe it is considered fairly ok for a safe system to terminate > with an assertion failure, > that might not be a bug at all, but considered far worse to hit a > SIGSEGV From hosking at cs.purdue.edu Wed Sep 23 03:40:27 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:40:27 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: <0BD93883-9F03-442C-940F-8729D3D9D2AE@cs.purdue.edu> On 22 Sep 2009, at 08:16, Jay K wrote: > Yes there is fairly definitely a problem on Windows and it dates, I > think, to this change: > > > 2009-02-16 02:20 hosking > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. I'm not convinced that this change itself broke things, but perhaps instead exposed the brokenness. In any case, debugging this in the head will probably be easiest. If we have an example that deterministically breaks then I think we have a place to start. My suggestion for now, since it appears to trigger the problem, is to use @M3nogc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 03:43:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:43:17 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: <3337B3AE-0503-4C26-8C9E-D34376786FAF@cs.purdue.edu> On 22 Sep 2009, at 07:21, Olaf Wagner wrote: > Hi Randy, Tony, Jay and all others, > > thanks for your updates. Things already look better in Hudson and > Tinderbox; there may still be some script failures which need manual > intervention. > > As this mail is relevant for all M3 committers, I've CC'ed it to > m3devel, too. > > I understand that a major bug (race condition in pthreads) has been > fixed, but there are still some problems in Windows' threads and I've not seen anything to confirm that there are problems in Window's threads. It sounds more like an issue in the Windows VBT code. I am not skilled sufficiently to debug Window's builds (...yet. Though with time I might get there if it becomes necessary). > Solaris' formsedit which are currently investigated. I'll try to add > some information of your summaries to the Trac roadmap soon. I'll look into this. From jay.krell at cornell.edu Wed Sep 23 03:51:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 01:51:05 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <0BD93883-9F03-442C-940F-8729D3D9D2AE@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: Tony there is something a bit gray that you are missing. The behavior with @M3nogc we don't necessarily consider bad/wrong/buggy. It is a consistent assertion failure. Not an access violation. It could just be Trestle not being fully supported on Windows. Olaf says Trestle was never fully ported. I'm not sure anyone knows what is missing, and if Juno really demonstrates that or not. However, versions before Feb 20 consistently act like current versions act with @M3nogc. Before Feb 20 without @M3nogc. Current with @M3nogc. What I'd like to see is current without @M3nogc to act just as bad but no worse than before Feb 20. I think the current behavior without @M3nogc is worse. It's just "fail vs. no fail". Now, that is apples and oranges. For example, I relatively recently changed the default initial allocation size and maybe incremental allocation sizes. In particular..I forget the exact details but I think changed from malloc to VirtualAlloc, and VirtualAlloc allocates in 64K chunks. I guess I should review that..but that was more recent I think, after Feb 20. I have to check. The code was a bit flawed somehow and I improved it somehow. I forget. Almost everything is subject to rerererereview when there is a bug, granted. I agree as well that Feb 20 might have just uncovered a preexisting problem. But much is unclear and figuring this out I don't think will be easy. :( - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 22 Sep 2009 21:40:27 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? On 22 Sep 2009, at 08:16, Jay K wrote: Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'm not convinced that this change itself broke things, but perhaps instead exposed the brokenness. In any case, debugging this in the head will probably be easiest. If we have an example that deterministically breaks then I think we have a place to start. My suggestion for now, since it appears to trigger the problem, is to use @M3nogc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 04:25:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 22:25:55 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: <52E6F992-DD37-415B-AA77-7BF305E8CC11@cs.purdue.edu> On 22 Sep 2009, at 21:51, Jay K wrote: > Tony there is something a bit gray that you are missing. Yes, clearly I am missing something. > The behavior with @M3nogc we don't necessarily consider bad/wrong/ > buggy. Right, it just takes GC out of the equation for what might be wrong. > It is a consistent assertion failure. Not an access violation. Good. We can debug that. > It could just be Trestle not being fully supported on Windows. > Olaf says Trestle was never fully ported. I don't know enough about this to say either way. > I'm not sure anyone knows what is missing, and if Juno really > demonstrates that or not. > > However, versions before Feb 20 consistently act like current > versions act with @M3nogc. > Before Feb 20 without @M3nogc. > Current with @M3nogc. What does this mean? That pre-2009-02 is just the same as post-2009-02? How does that narrow anything down to that specific time-frame? > What I'd like to see is current without @M3nogc to act just as bad > but no worse than before Feb 20. I think the current behavior > without @M3nogc is worse. It's just "fail vs. no fail". I still don't understand what this says about that particular time- frame. > Now, that is apples and oranges. For example, I relatively recently > changed the default initial allocation size and maybe incremental > allocation sizes. In particular..I forget the exact details but I > think changed from malloc to VirtualAlloc, and VirtualAlloc > allocates in 64K chunks. I guess I should review that..but that was > more recent I think, after Feb 20. I have to check. > The code was a bit flawed somehow and I improved it somehow. I > forget. Almost everything is subject to rerererereview when there is > a bug, granted. > > > I agree as well that Feb 20 might have just uncovered a preexisting > problem. > > > But much is unclear and figuring this out I don't think will be > easy. :( If we have a deterministic failure then it should be easy enough to track down. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 22 Sep 2009 21:40:27 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > again -- cm3 status worse? > > > On 22 Sep 2009, at 08:16, Jay K wrote: > > Yes there is fairly definitely a problem on Windows and it dates, I > think, to this change: > > > 2009-02-16 02:20 hosking > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > I'm not convinced that this change itself broke things, but perhaps > instead exposed the brokenness. In any case, debugging this in the > head will probably be easiest. If we have an example that > deterministically breaks then I think we have a place to start. My > suggestion for now, since it appears to trigger the problem, is to > use @M3nogc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 04:46:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 22:46:30 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <52E6F992-DD37-415B-AA77-7BF305E8CC11@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> <52E6F992-DD37-415B-AA77-7BF305E8CC11@cs.purdue.edu> Message-ID: <4B9C8CCF-897C-478D-95D7-A9030AB33B92@cs.purdue.edu> What about these? They appear to be Trestle and icon-related... 2009-02-18 11:14 jkrell * m3-libs/m3core/src/win32/WinUser.i3, m3-libs/m3core/src/win32/WinUserC.c, m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ WinTrestle.m3: workaround gcc backend bug that names <*EXTERNAL WindowFromPoint:WINAPI*> PROCEDURE WindowFromPoint (Point: POINT): HWND; WindowFromPoint at 4 instead of WindowFromPoint at 8 by adding <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) { return WindowFromPoint(*Point); } This lets I386_MINGW (NT386MINGNU) get further. 2009-02-18 10:51 jkrell * m3-sys/windowsResources/src/winRes.tmpl: adapt to MinGW which has windres instead of rc with different command line usage; detect MinGW by checking if backend mode is integrated backend or not, not great..it should really be informed by a variable in the toplevel configuration -- CONFIG_HAS_RC and CONFIG_HAS_WINDRES? On 22 Sep 2009, at 22:25, Tony Hosking wrote: > On 22 Sep 2009, at 21:51, Jay K wrote: > >> Tony there is something a bit gray that you are missing. > > Yes, clearly I am missing something. > >> The behavior with @M3nogc we don't necessarily consider bad/wrong/ >> buggy. > > Right, it just takes GC out of the equation for what might be wrong. > >> It is a consistent assertion failure. Not an access violation. > > Good. We can debug that. > >> It could just be Trestle not being fully supported on Windows. >> Olaf says Trestle was never fully ported. > > I don't know enough about this to say either way. > >> I'm not sure anyone knows what is missing, and if Juno really >> demonstrates that or not. >> >> However, versions before Feb 20 consistently act like current >> versions act with @M3nogc. >> Before Feb 20 without @M3nogc. >> Current with @M3nogc. > > What does this mean? That pre-2009-02 is just the same as > post-2009-02? How does that narrow anything down to that specific > time-frame? > >> What I'd like to see is current without @M3nogc to act just as bad >> but no worse than before Feb 20. I think the current behavior >> without @M3nogc is worse. It's just "fail vs. no fail". > > I still don't understand what this says about that particular time- > frame. > >> Now, that is apples and oranges. For example, I relatively >> recently changed the default initial allocation size and maybe >> incremental allocation sizes. In particular..I forget the exact >> details but I think changed from malloc to VirtualAlloc, and >> VirtualAlloc allocates in 64K chunks. I guess I should review >> that..but that was more recent I think, after Feb 20. I have to >> check. >> The code was a bit flawed somehow and I improved it somehow. I >> forget. Almost everything is subject to rerererereview when there >> is a bug, granted. >> >> >> I agree as well that Feb 20 might have just uncovered a preexisting >> problem. >> >> >> But much is unclear and figuring this out I don't think will be >> easy. :( > > If we have a deterministic failure then it should be easy enough to > track down. > >> >> >> - Jay >> >> >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 22 Sep 2009 21:40:27 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back >> again -- cm3 status worse? >> >> >> On 22 Sep 2009, at 08:16, Jay K wrote: >> >> Yes there is fairly definitely a problem on Windows and it dates, I >> think, to this change: >> >> >> 2009-02-16 02:20 hosking >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ >> dtoa.c, >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ >> ThreadPThreadC.i3, >> thread/WIN32/ThreadWin32.m3: >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better >> match underlying pthread semantics. >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap >> is held. >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or >> not. >> >> I'm not convinced that this change itself broke things, but perhaps >> instead exposed the brokenness. In any case, debugging this in the >> head will probably be easiest. If we have an example that >> deterministically breaks then I think we have a place to start. My >> suggestion for now, since it appears to trigger the problem, is to >> use @M3nogc. >> >> > From jay.krell at cornell.edu Wed Sep 23 05:48:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 03:48:59 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4B9C8CCF-897C-478D-95D7-A9030AB33B92@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: I'm "certain" these are ok but I can try without them. 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. 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). You still aren't understanding me. We have a consistent failure before Feb 20, but it is deemed maybe ok. It was maybe always that way. It is maybe unfinished code. Not heap corruption. Though we don't know 100% and it does merit some investigation. After Feb 20 without @M3nogc we have a "more severe" and actually fairly consistent but not completely consistent failure -- heap corruption. After Feb 20 with @M3nogc acts the same as before Feb 20 without @M3nogc. - Jay > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 22 Sep 2009 22:46:30 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? > > What about these? > They appear to be Trestle and icon-related... > 2009-02-18 11:14 jkrell > > * m3-libs/m3core/src/win32/WinUser.i3, > m3-libs/m3core/src/win32/WinUserC.c, > m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ > WinTrestle.m3: > > workaround gcc backend bug that names > > <*EXTERNAL WindowFromPoint:WINAPI*> > PROCEDURE WindowFromPoint (Point: POINT): HWND; > > WindowFromPoint at 4 instead of WindowFromPoint at 8 > > by adding > > <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> > PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; > > HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) > { > return WindowFromPoint(*Point); > } > > This lets I386_MINGW (NT386MINGNU) get further. > > 2009-02-18 10:51 jkrell > > * m3-sys/windowsResources/src/winRes.tmpl: > > adapt to MinGW which has windres instead of rc with different > command line usage; detect MinGW by checking if backend mode is > integrated backend or not, not great..it should really be informed by > a variable in the toplevel configuration -- CONFIG_HAS_RC and > CONFIG_HAS_WINDRES? > > > On 22 Sep 2009, at 22:25, Tony Hosking wrote: > > > On 22 Sep 2009, at 21:51, Jay K wrote: > > > >> Tony there is something a bit gray that you are missing. > > > > Yes, clearly I am missing something. > > > >> The behavior with @M3nogc we don't necessarily consider bad/wrong/ > >> buggy. > > > > Right, it just takes GC out of the equation for what might be wrong. > > > >> It is a consistent assertion failure. Not an access violation. > > > > Good. We can debug that. > > > >> It could just be Trestle not being fully supported on Windows. > >> Olaf says Trestle was never fully ported. > > > > I don't know enough about this to say either way. > > > >> I'm not sure anyone knows what is missing, and if Juno really > >> demonstrates that or not. > >> > >> However, versions before Feb 20 consistently act like current > >> versions act with @M3nogc. > >> Before Feb 20 without @M3nogc. > >> Current with @M3nogc. > > > > What does this mean? That pre-2009-02 is just the same as > > post-2009-02? How does that narrow anything down to that specific > > time-frame? > > > >> What I'd like to see is current without @M3nogc to act just as bad > >> but no worse than before Feb 20. I think the current behavior > >> without @M3nogc is worse. It's just "fail vs. no fail". > > > > I still don't understand what this says about that particular time- > > frame. > > > >> Now, that is apples and oranges. For example, I relatively > >> recently changed the default initial allocation size and maybe > >> incremental allocation sizes. In particular..I forget the exact > >> details but I think changed from malloc to VirtualAlloc, and > >> VirtualAlloc allocates in 64K chunks. I guess I should review > >> that..but that was more recent I think, after Feb 20. I have to > >> check. > >> The code was a bit flawed somehow and I improved it somehow. I > >> forget. Almost everything is subject to rerererereview when there > >> is a bug, granted. > >> > >> > >> I agree as well that Feb 20 might have just uncovered a preexisting > >> problem. > >> > >> > >> But much is unclear and figuring this out I don't think will be > >> easy. :( > > > > If we have a deterministic failure then it should be easy enough to > > track down. > > > >> > >> > >> - Jay > >> > >> > >> > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Date: Tue, 22 Sep 2009 21:40:27 -0400 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > >> again -- cm3 status worse? > >> > >> > >> On 22 Sep 2009, at 08:16, Jay K wrote: > >> > >> Yes there is fairly definitely a problem on Windows and it dates, I > >> think, to this change: > >> > >> > >> 2009-02-16 02:20 hosking > >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > >> dtoa.c, > >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, > >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ > >> ThreadPThreadC.i3, > >> thread/WIN32/ThreadWin32.m3: > >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > >> match underlying pthread semantics. > >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap > >> is held. > >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > >> not. > >> > >> I'm not convinced that this change itself broke things, but perhaps > >> instead exposed the brokenness. In any case, debugging this in the > >> head will probably be easiest. If we have an example that > >> deterministically breaks then I think we have a place to start. My > >> suggestion for now, since it appears to trigger the problem, is to > >> use @M3nogc. > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 05:51:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 03:51:58 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4B9C8CCF-897C-478D-95D7-A9030AB33B92@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: Plus I think I narrowed the problem down to a 30 minute window, not just a day. I build like 2:00 and 2:30 on the day of the heap/lock change. But granted it might only be revealing some other problem, that was always there or recently introduced or long ago introduced... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Wed, 23 Sep 2009 03:48:59 +0000 I'm "certain" these are ok but I can try without them. 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. 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). You still aren't understanding me. We have a consistent failure before Feb 20, but it is deemed maybe ok. It was maybe always that way. It is maybe unfinished code. Not heap corruption. Though we don't know 100% and it does merit some investigation. After Feb 20 without @M3nogc we have a "more severe" and actually fairly consistent but not completely consistent failure -- heap corruption. After Feb 20 with @M3nogc acts the same as before Feb 20 without @M3nogc. - Jay > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 22 Sep 2009 22:46:30 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? > > What about these? > They appear to be Trestle and icon-related... > 2009-02-18 11:14 jkrell > > * m3-libs/m3core/src/win32/WinUser.i3, > m3-libs/m3core/src/win32/WinUserC.c, > m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ > WinTrestle.m3: > > workaround gcc backend bug that names > > <*EXTERNAL WindowFromPoint:WINAPI*> > PROCEDURE WindowFromPoint (Point: POINT): HWND; > > WindowFromPoint at 4 instead of WindowFromPoint at 8 > > by adding > > <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> > PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; > > HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) > { > return WindowFromPoint(*Point); > } > > This lets I386_MINGW (NT386MINGNU) get further. > > 2009-02-18 10:51 jkrell > > * m3-sys/windowsResources/src/winRes.tmpl: > > adapt to MinGW which has windres instead of rc with different > command line usage; detect MinGW by checking if backend mode is > integrated backend or not, not great..it should really be informed by > a variable in the toplevel configuration -- CONFIG_HAS_RC and > CONFIG_HAS_WINDRES? > > > On 22 Sep 2009, at 22:25, Tony Hosking wrote: > > > On 22 Sep 2009, at 21:51, Jay K wrote: > > > >> Tony there is something a bit gray that you are missing. > > > > Yes, clearly I am missing something. > > > >> The behavior with @M3nogc we don't necessarily consider bad/wrong/ > >> buggy. > > > > Right, it just takes GC out of the equation for what might be wrong. > > > >> It is a consistent assertion failure. Not an access violation. > > > > Good. We can debug that. > > > >> It could just be Trestle not being fully supported on Windows. > >> Olaf says Trestle was never fully ported. > > > > I don't know enough about this to say either way. > > > >> I'm not sure anyone knows what is missing, and if Juno really > >> demonstrates that or not. > >> > >> However, versions before Feb 20 consistently act like current > >> versions act with @M3nogc. > >> Before Feb 20 without @M3nogc. > >> Current with @M3nogc. > > > > What does this mean? That pre-2009-02 is just the same as > > post-2009-02? How does that narrow anything down to that specific > > time-frame? > > > >> What I'd like to see is current without @M3nogc to act just as bad > >> but no worse than before Feb 20. I think the current behavior > >> without @M3nogc is worse. It's just "fail vs. no fail". > > > > I still don't understand what this says about that particular time- > > frame. > > > >> Now, that is apples and oranges. For example, I relatively > >> recently changed the default initial allocation size and maybe > >> incremental allocation sizes. In particular..I forget the exact > >> details but I think changed from malloc to VirtualAlloc, and > >> VirtualAlloc allocates in 64K chunks. I guess I should review > >> that..but that was more recent I think, after Feb 20. I have to > >> check. > >> The code was a bit flawed somehow and I improved it somehow. I > >> forget. Almost everything is subject to rerererereview when there > >> is a bug, granted. > >> > >> > >> I agree as well that Feb 20 might have just uncovered a preexisting > >> problem. > >> > >> > >> But much is unclear and figuring this out I don't think will be > >> easy. :( > > > > If we have a deterministic failure then it should be easy enough to > > track down. > > > >> > >> > >> - Jay > >> > >> > >> > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Date: Tue, 22 Sep 2009 21:40:27 -0400 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > >> again -- cm3 status worse? > >> > >> > >> On 22 Sep 2009, at 08:16, Jay K wrote: > >> > >> Yes there is fairly definitely a problem on Windows and it dates, I > >> think, to this change: > >> > >> > >> 2009-02-16 02:20 hosking > >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > >> dtoa.c, > >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, > >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ > >> ThreadPThreadC.i3, > >> thread/WIN32/ThreadWin32.m3: > >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > >> match underlying pthread semantics. > >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap > >> is held. > >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > >> not. > >> > >> I'm not convinced that this change itself broke things, but perhaps > >> instead exposed the brokenness. In any case, debugging this in the > >> head will probably be easiest. If we have an example that > >> deterministically breaks then I think we have a place to start. My > >> suggestion for now, since it appears to trigger the problem, is to > >> use @M3nogc. > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 06:03:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Sep 2009 00:03:22 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: On 22 Sep 2009, at 23:48, Jay K wrote: > I'm "certain" these are ok but I can try without them. > 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. > > > 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). > > > You still aren't understanding me. > > We have a consistent failure before Feb 20, but it is deemed maybe ok. > It was maybe always that way. It is maybe unfinished code. Not > heap corruption. > Though we don't know 100% and it does merit some investigation. > > After Feb 20 without @M3nogc we have a "more severe" and actually > fairly consistent but not completely consistent failure -- heap > corruption. OK, now I think I begin to understand. What happens with @M3paranoidgc on the post-2009-02 code is what you sent earlier, right? Sounds like something is being collected when it should not, resulting in a dangling reference to memory that gets reused for something else. I don't think I changed anything that would affect that. I'll take another look. The M3paranoidgc flag should catch any dangling reference. Can you try with @M3noincremental and/or @M3nogenerational? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 06:32:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Sep 2009 00:32:30 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: 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? On 22 Sep 2009, at 23:51, Jay K wrote: > Plus I think I narrowed the problem down to a 30 minute window, not > just a day. > I build like 2:00 and 2:30 on the day of the heap/lock change. > But granted it might only be revealing some other problem, that was > always there or recently introduced or long ago introduced... > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back > again -- cm3 status worse? > Date: Wed, 23 Sep 2009 03:48:59 +0000 > > I'm "certain" these are ok but I can try without them. > 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. > > > 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). > > > You still aren't understanding me. > > We have a consistent failure before Feb 20, but it is deemed maybe ok. > It was maybe always that way. It is maybe unfinished code. Not > heap corruption. > Though we don't know 100% and it does merit some investigation. > > After Feb 20 without @M3nogc we have a "more severe" and actually > fairly consistent but not completely consistent failure -- heap > corruption. > > After Feb 20 with @M3nogc acts the same as before Feb 20 without > @M3nogc. > > > - Jay > > > From: hosking at cs.purdue.edu > > To: hosking at cs.purdue.edu > > Date: Tue, 22 Sep 2009 22:46:30 -0400 > > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > again -- cm3 status worse? > > > > What about these? > > They appear to be Trestle and icon-related... > > 2009-02-18 11:14 jkrell > > > > * m3-libs/m3core/src/win32/WinUser.i3, > > m3-libs/m3core/src/win32/WinUserC.c, > > m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ > > WinTrestle.m3: > > > > workaround gcc backend bug that names > > > > <*EXTERNAL WindowFromPoint:WINAPI*> > > PROCEDURE WindowFromPoint (Point: POINT): HWND; > > > > WindowFromPoint at 4 instead of WindowFromPoint at 8 > > > > by adding > > > > <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> > > PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; > > > > HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) > > { > > return WindowFromPoint(*Point); > > } > > > > This lets I386_MINGW (NT386MINGNU) get further. > > > > 2009-02-18 10:51 jkrell > > > > * m3-sys/windowsResources/src/winRes.tmpl: > > > > adapt to MinGW which has windres instead of rc with different > > command line usage; detect MinGW by checking if backend mode is > > integrated backend or not, not great..it should really be informed > by > > a variable in the toplevel configuration -- CONFIG_HAS_RC and > > CONFIG_HAS_WINDRES? > > > > > > On 22 Sep 2009, at 22:25, Tony Hosking wrote: > > > > > On 22 Sep 2009, at 21:51, Jay K wrote: > > > > > >> Tony there is something a bit gray that you are missing. > > > > > > Yes, clearly I am missing something. > > > > > >> The behavior with @M3nogc we don't necessarily consider bad/ > wrong/ > > >> buggy. > > > > > > Right, it just takes GC out of the equation for what might be > wrong. > > > > > >> It is a consistent assertion failure. Not an access violation. > > > > > > Good. We can debug that. > > > > > >> It could just be Trestle not being fully supported on Windows. > > >> Olaf says Trestle was never fully ported. > > > > > > I don't know enough about this to say either way. > > > > > >> I'm not sure anyone knows what is missing, and if Juno really > > >> demonstrates that or not. > > >> > > >> However, versions before Feb 20 consistently act like current > > >> versions act with @M3nogc. > > >> Before Feb 20 without @M3nogc. > > >> Current with @M3nogc. > > > > > > What does this mean? That pre-2009-02 is just the same as > > > post-2009-02? How does that narrow anything down to that specific > > > time-frame? > > > > > >> What I'd like to see is current without @M3nogc to act just as > bad > > >> but no worse than before Feb 20. I think the current behavior > > >> without @M3nogc is worse. It's just "fail vs. no fail". > > > > > > I still don't understand what this says about that particular > time- > > > frame. > > > > > >> Now, that is apples and oranges. For example, I relatively > > >> recently changed the default initial allocation size and maybe > > >> incremental allocation sizes. In particular..I forget the exact > > >> details but I think changed from malloc to VirtualAlloc, and > > >> VirtualAlloc allocates in 64K chunks. I guess I should review > > >> that..but that was more recent I think, after Feb 20. I have to > > >> check. > > >> The code was a bit flawed somehow and I improved it somehow. I > > >> forget. Almost everything is subject to rerererereview when there > > >> is a bug, granted. > > >> > > >> > > >> I agree as well that Feb 20 might have just uncovered a > preexisting > > >> problem. > > >> > > >> > > >> But much is unclear and figuring this out I don't think will be > > >> easy. :( > > > > > > If we have a deterministic failure then it should be easy enough > to > > > track down. > > > > > >> > > >> > > >> - Jay > > >> > > >> > > >> > > >> From: hosking at cs.purdue.edu > > >> To: jay.krell at cornell.edu > > >> Date: Tue, 22 Sep 2009 21:40:27 -0400 > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > > >> again -- cm3 status worse? > > >> > > >> > > >> On 22 Sep 2009, at 08:16, Jay K wrote: > > >> > > >> Yes there is fairly definitely a problem on Windows and it > dates, I > > >> think, to this change: > > >> > > >> > > >> 2009-02-16 02:20 hosking > > >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > > >> dtoa.c, > > >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, > > >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > > >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > > >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > > >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > > >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ > > >> ThreadPThreadC.i3, > > >> thread/WIN32/ThreadWin32.m3: > > >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > > >> match underlying pthread semantics. > > >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap > > >> is held. > > >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > > >> not. > > >> > > >> I'm not convinced that this change itself broke things, but > perhaps > > >> instead exposed the brokenness. In any case, debugging this in > the > > >> head will probably be easiest. If we have an example that > > >> deterministically breaks then I think we have a place to start. > My > > >> suggestion for now, since it appears to trigger the problem, is > to > > >> use @M3nogc. > > >> > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 23 09:30:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 09:30:22 +0200 Subject: [M3devel] package tests regression Message-ID: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> I noticed yesterday that several package build jobs failed because of wrong timestamps (probably some changed dependency). But even after cleaning everything before compilation AMD64_LINUX and FreeBSD (which should run without any errors) show some regression: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests Perhaps some missing overrides again? Or something else? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Sep 23 09:39:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 09:39:18 +0200 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> Quoting Olaf Wagner : > I noticed yesterday that several package build jobs failed because > of wrong timestamps (probably some changed dependency). But even after > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > run without any errors) show some regression: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests Tests seem to be completely messed up for Solaris (no results at all): http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run for 11 and 23 days respectively, probably due to unavailability of the build machines. I've started those now manually. xdarwin is offline currently though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 23 09:42:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 07:42:38 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: I thought I386_OPENBSD had been up pretty well. I check it every so often. There was maybe over a week of no checkins to release actually so maybe no tests then? :) I386_DARWIN I'll leave on, and AMD64_FREEBSD.. I agree about Solaris. And I was trying to fix the date/expr stuff on Solaris. - Jay > Date: Wed, 23 Sep 2009 09:39:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Olaf Wagner : > > > I noticed yesterday that several package build jobs failed because > > of wrong timestamps (probably some changed dependency). But even after > > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > > run without any errors) show some regression: > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests > > Tests seem to be completely messed up for Solaris (no results at all): > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console > > Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run > for 11 and 23 days respectively, probably due to unavailability of the > build machines. I've started those now manually. xdarwin is offline > currently though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 09:44:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 07:44:46 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: I see the problem. My fix for Solaris is quite bad. It doesn't account for the cwd changing during pkgmap. Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; export PATH and then run m3date. Or maybe you can do an awk one liner there?? I figured C was easy enough. Or just remove the date %+s altogether? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] more package tests regression Date: Wed, 23 Sep 2009 07:42:38 +0000 I thought I386_OPENBSD had been up pretty well. I check it every so often. There was maybe over a week of no checkins to release actually so maybe no tests then? :) I386_DARWIN I'll leave on, and AMD64_FREEBSD.. I agree about Solaris. And I was trying to fix the date/expr stuff on Solaris. - Jay > Date: Wed, 23 Sep 2009 09:39:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Olaf Wagner : > > > I noticed yesterday that several package build jobs failed because > > of wrong timestamps (probably some changed dependency). But even after > > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > > run without any errors) show some regression: > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests > > Tests seem to be completely messed up for Solaris (no results at all): > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console > > Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run > for 11 and 23 days respectively, probably due to unavailability of the > build machines. I've started those now manually. xdarwin is offline > currently though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 09:48:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 07:48:17 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: PPC_LINUX should also have good availability..I'll double check in a bit... (All of xlin (Linux/x86), plin (Linux/ppc), slin (Linux/sparc), ssol (Solaris/sparc), xobsd (OpenBSD/x86) should have good availability a while now; "jbook2" (Mac/amd64/x86) and its vms (afbsd (FreeBSD/AMD64)) yeah they've been off and on, I'll leave them on; there are yet other machines...). - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] more package tests regression Date: Wed, 23 Sep 2009 07:44:46 +0000 I see the problem. My fix for Solaris is quite bad. It doesn't account for the cwd changing during pkgmap. Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; export PATH and then run m3date. Or maybe you can do an awk one liner there?? I figured C was easy enough. Or just remove the date %+s altogether? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] more package tests regression Date: Wed, 23 Sep 2009 07:42:38 +0000 I thought I386_OPENBSD had been up pretty well. I check it every so often. There was maybe over a week of no checkins to release actually so maybe no tests then? :) I386_DARWIN I'll leave on, and AMD64_FREEBSD.. I agree about Solaris. And I was trying to fix the date/expr stuff on Solaris. - Jay > Date: Wed, 23 Sep 2009 09:39:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Olaf Wagner : > > > I noticed yesterday that several package build jobs failed because > > of wrong timestamps (probably some changed dependency). But even after > > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > > run without any errors) show some regression: > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests > > Tests seem to be completely messed up for Solaris (no results at all): > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console > > Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run > for 11 and 23 days respectively, probably due to unavailability of the > build machines. I've started those now manually. xdarwin is offline > currently though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 23 11:18:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 11:18:41 +0200 Subject: [M3devel] Reasoning for /usr/local/cm3 ? Message-ID: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Quoting Martin Bishop : > Why does everything install into /usr/local/cm3/* ? I tried editing my > PATH variable to get the cm3 binary in there, but I still have to > 'source /etc/profile' with every shell. And if I symlink it, it causes > problems. The paths are different on different systems. /usr/local/cm3 is just the system-specifics-ignoring default of a generic cm3 installation. System-specific packages are currently being prepared by some people, but not yet finished as far as I know. There should be mails in the archives about download locations. > Is there a reason to not just install to normal positions like /usr/bin > and /usr/lib, etc? Is it possible to tell cminstall where to install > other the default /usr/local/cm3 ? Sure. Just give cminstall the target directory as argument. It will always install a complete tree though (bin, lib, pkg, doc, www, ...). If that doesn't suffice, you may also be able to use symlinks for the main binaries in one of your PATH directories. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 23 13:23:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 11:23:20 +0000 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > problems. > Symlink should work. Symlink /usr/bin/cm3 to /usr/local/cm3/bin? Hardlinks would not likely work. /usr/local/cm3/bin is used instead of /usr/bin, because it makes it clear what goes/came together and uninstall is just a recursive delete. "uninstall is just a recursive delete" is something a lot of people like, and sometimes it is available, sometimes not. What about that PATH=/usr/local/cm3/bin:$PATH tidbits left behind in ~/.bashrc that user put in manually... Some people would use the shorter /opt/cm3. Personally I use /cm3, possibly symlinked to ~jay/cm3. (Note: symlinks not necessarily available!) I like that /opt is shorter, but there is much inertia/momentum behind /usr/local -- the default for autoconf, but granted, not /usr/local/pkg. Some folks use /opt/pkg1 /opt/pkg2 and then blow up $PATH with lots of entries. Others use symlinks into the shared /usr/bin and whatnot. Maybe others just use full paths. There is no perfect answer here. Every approach has (large, glarying) advantages and disadvantages. It is quite unfortunate but I really just try to ignore it. I believe you could spend, uh, infinite time discussing and implementing package management and as I said, you'd still have large glarying disadvantages. Of course there are various package managers that let you put everything "intermixed" in /usr and they keep track of what came from what and allow uninstall that isn't just a recursive delete. Some people use a userid per package. One more thing before I shut up ... we produce package manager indepent packages. So not much of an installer/uninstaller, no package database. I do have code to produce .deb files checked in. I should enable that soon. I'm inclined to just produce one large cm3-linux-x86.deb, cm3-linux-amd64.deb, cm3-linux-sparc.deb, etc. Not all the broken out packages that Olaf did. No dependencies. Not ubuntuv1, debianv4, etc., just claim that are fairly portable and see what happens. They could even be easily installed on non-Debian systems -- a .deb file is a very simple format esp. if you ignore the metadata file. It is as I recall an ar file with a metadata file and a nested .tar.gz or .tar.bz2 or .tar.lzma -- and due to the .tar.lzma option, much smaller than others. (And heck, we could make .debs for Darwin and Solaris; it really just takes like two lines of .sh to install them...) - Jay > Date: Wed, 23 Sep 2009 11:18:41 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ? > > Quoting Martin Bishop : > > > Why does everything install into /usr/local/cm3/* ? I tried editing my > > PATH variable to get the cm3 binary in there, but I still have to > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > problems. > > The paths are different on different systems. /usr/local/cm3 is just > the system-specifics-ignoring default of a generic cm3 installation. > System-specific packages are currently being prepared by some > people, but not yet finished as far as I know. There should be > mails in the archives about download locations. > > > Is there a reason to not just install to normal positions like /usr/bin > > and /usr/lib, etc? Is it possible to tell cminstall where to install > > other the default /usr/local/cm3 ? > > Sure. Just give cminstall the target directory as argument. > It will always install a complete tree though (bin, lib, pkg, doc, www, ...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 23 13:48:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 13:48:36 +0200 Subject: [M3devel] more package tests regression In-Reply-To: References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: <20090923134836.9axwal8pgk4k0gcc@mail.elegosoft.com> Quoting Jay K : > > I see the problem. My fix for Solaris is quite bad. > > It doesn't account for the cwd changing during pkgmap. > > Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; > export PATH and then run m3date. > > Or maybe you can do an awk one liner there?? > > I figured C was easy enough. > > Or just remove the date %+s altogether? Tests on NT386 now show === package m3-sys/libdump === /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: line 388: ./m3date: No such file or directory /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: line 391: ./m3date: No such file or directory expr: non-numeric argument (standard_in) 1: parse error for all packages :-( Perhaps you could just comment-out the date stuff for the time being (if we don't really need it)? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 23 14:11:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 12:11:24 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923134836.9axwal8pgk4k0gcc@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: I just fixed "my part". It is to get "your part" to work -- date +%s on Solaris. If your part isn't needed, definltely delete it and mine. If you want yours though, give mine another change please, thanks. Or if it is optional, maybe just enable it on non-Solaris systems (`uname` = "SunOS")? - Jay > Date: Wed, 23 Sep 2009 13:48:36 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Jay K : > > > > > I see the problem. My fix for Solaris is quite bad. > > > > It doesn't account for the cwd changing during pkgmap. > > > > Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; > > export PATH and then run m3date. > > > > Or maybe you can do an awk one liner there?? > > > > I figured C was easy enough. > > > > Or just remove the date %+s altogether? > > Tests on NT386 now show > > === package m3-sys/libdump === > > /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: > line 388: ./m3date: No such file or directory > > /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: > line 391: ./m3date: No such file or directory > > expr: non-numeric argument > > (standard_in) 1: parse error > > for all packages :-( > > Perhaps you could just comment-out the date stuff for the time being > (if we don't really need it)? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Sep 23 16:16:49 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 23 Sep 2009 10:16:49 -0400 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: <20090923141648.GA26316@topoi.pooq.com> On Wed, Sep 23, 2009 at 11:23:20AM +0000, Jay K wrote: > > > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > > problems. > > > > > > Symlink should work. > > Symlink /usr/bin/cm3 to /usr/local/cm3/bin? There's a program called stow (http://www.gnu.org/software/stow/) to make these soft links and keep track of them. -- hendrik From mbishop at esoteriq.org Wed Sep 23 18:32:21 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 23 Sep 2009 11:32:21 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: <4ABA4D95.3060100@esoteriq.org> Jay K wrote: > > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > > problems. > > > > Symlink should work. > Symlink /usr/bin/cm3 to /usr/local/cm3/bin? > Hardlinks would not likely work. > > > /usr/local/cm3/bin is used instead of /usr/bin, because it makes it > clear what goes/came together and uninstall is just a recursive delete. > "uninstall is just a recursive delete" is something a lot of people > like, and sometimes it is available, sometimes not. What about that > PATH=/usr/local/cm3/bin:$PATH tidbits left behind in ~/.bashrc that > user put in manually... > > > Some people would use the shorter /opt/cm3. > > Personally I use /cm3, possibly symlinked to ~jay/cm3. > (Note: symlinks not necessarily available!) > > I like that /opt is shorter, but there is much inertia/momentum behind > /usr/local -- the default for autoconf, but granted, not /usr/local/pkg. > > Some folks use > /opt/pkg1 > /opt/pkg2 > > and then blow up $PATH with lots of entries. Others use symlinks into > the shared /usr/bin and whatnot. > Maybe others just use full paths. > > There is no perfect answer here. Every approach has (large, glarying) > advantages and disadvantages. > It is quite unfortunate but I really just try to ignore it. I believe > you could spend, uh, infinite time discussing and implementing package > management and as I said, you'd still have large glarying disadvantages. > > Of course there are various package managers that let you put > everything "intermixed" in /usr and they keep track of what came from > what and allow uninstall that isn't just a recursive delete. > > Some people use a userid per package. > > One more thing before I shut up ... we produce package manager > indepent packages. > So not much of an installer/uninstaller, no package database. > Thanks, I guess there really isn't a simple answer... > I do have code to produce .deb files checked in. I should enable that > soon. > I'm inclined to just produce one large cm3-linux-x86.deb, > cm3-linux-amd64.deb, cm3-linux-sparc.deb, etc. Not all the broken out > packages that Olaf did. No dependencies. Not ubuntuv1, debianv4, etc., > just claim that are fairly portable and see what happens. They could > even be easily installed on non-Debian systems -- a .deb file is a > very simple format esp. if you ignore the metadata file. It is as I > recall an ar file with a metadata file and a nested .tar.gz or > .tar.bz2 or .tar.lzma -- and due to the .tar.lzma option, much smaller > than others. (And heck, we could make .debs for Darwin and Solaris; it > really just takes like two lines of .sh to install them...) > You should definitely provide debs for the stable release. Will help get more people to try it out. > > - Jay > > > > > Date: Wed, 23 Sep 2009 11:18:41 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ? > > > > Quoting Martin Bishop : > > > > > Why does everything install into /usr/local/cm3/* ? I tried editing my > > > PATH variable to get the cm3 binary in there, but I still have to > > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > > problems. > > > > The paths are different on different systems. /usr/local/cm3 is just > > the system-specifics-ignoring default of a generic cm3 installation. > > System-specific packages are currently being prepared by some > > people, but not yet finished as far as I know. There should be > > mails in the archives about download locations. > > > > > Is there a reason to not just install to normal positions like > /usr/bin > > > and /usr/lib, etc? Is it possible to tell cminstall where to install > > > other the default /usr/local/cm3 ? > > > > Sure. Just give cminstall the target directory as argument. > > It will always install a complete tree though (bin, lib, pkg, doc, > www, ...) From mbishop at esoteriq.org Wed Sep 23 18:34:18 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 23 Sep 2009 11:34:18 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: <4ABA4E0A.3080202@esoteriq.org> Olaf Wagner wrote: > Quoting Martin Bishop : > >> Why does everything install into /usr/local/cm3/* ? I tried editing my >> PATH variable to get the cm3 binary in there, but I still have to >> 'source /etc/profile' with every shell. And if I symlink it, it causes >> problems. > > The paths are different on different systems. /usr/local/cm3 is just > the system-specifics-ignoring default of a generic cm3 installation. > System-specific packages are currently being prepared by some > people, but not yet finished as far as I know. There should be > mails in the archives about download locations. > >> Is there a reason to not just install to normal positions like /usr/bin >> and /usr/lib, etc? Is it possible to tell cminstall where to install >> other the default /usr/local/cm3 ? > > Sure. Just give cminstall the target directory as argument. > It will always install a complete tree though (bin, lib, pkg, doc, > www, ...) Oh! Didn't know that. Thanks From jay.krell at cornell.edu Wed Sep 23 20:23:08 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 23 Sep 2009 11:23:08 -0700 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <4ABA4D95.3060100@esoteriq.org> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> <4ABA4D95.3060100@esoteriq.org> Message-ID: Upon further thought symlink might not work. We can make it work on some systems e.g. Mac and cygwin. Problem I see is, how does one find the executable's fullpath? If the symlink source is in argv[0] then no posix portable way. I was looking at this for finding cm3.cfg. -jay/phone From rodney.m.bates at cox.net Wed Sep 23 20:53:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 23 Sep 2009 13:53:49 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> <4ABA4D95.3060100@esoteriq.org> Message-ID: <4ABA6EBD.7050301@cox.net> I've had this around for a while. Don't know how portable it is. It's mainly a main executable wrapper for, and delegates the real work to, FS.GetAbsolutePathname, which, if not fully portable, ought to be fixed so it is. It works on LINUXLIBC6 and AMD64_LINUX. It also changes backslashes to forward slashes. Maybe better for general script use if it returned a return code if things go awry. jay.krell at cornell.edu wrote: > Upon further thought symlink might not work. We can make it work on > some systems e.g. Mac and cygwin. Problem I see is, how does one find > the executable's fullpath? If the symlink source is in argv[0] then no > posix portable way. I was looking at this for finding cm3.cfg. > > -jay/phone > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: AbsPath.m3 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m3makefile URL: From jay.krell at cornell.edu Thu Sep 24 01:25:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 23:25:09 +0000 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <4ABA6EBD.7050301@cox.net> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> <4ABA4D95.3060100@esoteriq.org> Message-ID: I don't believe that FS.GetAbsolutePathname(RTArgs.Get(1)) is correct. mkdir /path /cwd PATH=/path cp /usr/bin/ls /path cp /usr/bin/ls /cwd cd /cwd ls You will return /cwd/ instead of the correct /path/lsh. The code I have seen to handle this is roundabout. You have to first check for dots and/or slashes. If they are present, you use GetAbsolutePathname like you do. Else you split up $PATH on the appropriate character, appending argv[0] to each element and see if it exists and/or is executable. On Windows that isn't right probably, due to "extensions", however on Windows there is a very simple way, just GetModuleFileName(NULL). I expect there is a simple way on Mac too. There might be a way to fish out the dynamic linker parameters on other systems. But I don't think Posix provides a correct simple way. - Jay > Date: Wed, 23 Sep 2009 13:53:49 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ? > > I've had this around for a while. Don't know how portable it is. > It's mainly a main executable wrapper for, and > delegates the real work to, FS.GetAbsolutePathname, > which, if not fully portable, ought to be fixed so it is. > > It works on LINUXLIBC6 and AMD64_LINUX. > > It also changes backslashes to forward slashes. > Maybe better for general script use if it returned > a return code if things go awry. > > jay.krell at cornell.edu wrote: > > Upon further thought symlink might not work. We can make it work on > > some systems e.g. Mac and cygwin. Problem I see is, how does one find > > the executable's fullpath? If the symlink source is in argv[0] then no > > posix portable way. I was looking at this for finding cm3.cfg. > > > > -jay/phone > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 24 16:24:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Sep 2009 14:24:21 +0000 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB91054.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: @M3noincremental about the same crashing @M3nogenerational about the same crashing @M3noincremental @M3nogenerational about the same crashing - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] more info on juno on windows Date: Tue, 22 Sep 2009 22:11:26 +0000 current: nogc "works" -- always the WinContext/PushPixmap assertion failure paranoidgc is broken the same as default -- variety of assertion failures and access violations Including but NOT limited to: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 1708 *** which is in RefSanityCheck, doesn't look useful. still many access violations at 00200000-4. I think 00200000 just happens to be some pixmap data from the splash screen that clobbered some other data but I don't know. I posted a big hex dump the other week to see if anyone could confirm it looks like pixmaps. - Jay Date: Tue, 22 Sep 2009 17:58:52 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] more info on juno on windows Tony: I just tried these options. Here are results: recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line 1706, while nogc gets assert in WinContext.m3 line 165. I note that the juno window begins drawing before the crash on nogc whereas it does not on paranoidgc. recent cm3 on Vista, same results as above except that it appears to reference an illegal memory location before hitting the assert in the RTCollector when using paranoidgc. old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to abort the repeating error message. Not sure if anything else happens first because it scrolls too far. For nogc, we get same behavoir as the other tests above. Regards, Randy >>> Tony Hosking 9/22/2009 5:46 PM >>> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Sep 24 16:33:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Sep 2009 10:33:23 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: <354148C0-DBA4-438C-963B-80350725E453@cs.purdue.edu> Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 24 Sep 2009, at 10:24, Jay K wrote: > @M3noincremental about the same crashing > @M3nogenerational about the same crashing > @M3noincremental @M3nogenerational about the same crashing > > - Jay > > > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more info on juno on windows > Date: Tue, 22 Sep 2009 22:11:26 +0000 > > current: > > nogc "works" -- always the WinContext/PushPixmap assertion failure I think this is indicative of a heap clobber that you are seeing. > > paranoidgc is broken the same as default -- variety of assertion > failures and access violations > Including but NOT limited to: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1708 > *** > > > which is in RefSanityCheck, doesn't look useful. > > still many access violations at 00200000-4. > I think 00200000 just happens to be some pixmap data from the splash > screen that clobbered some other data but I don't know. > I posted a big hex dump the other week to see if anyone could > confirm it looks like pixmaps. > > - Jay > > > Date: Tue, 22 Sep 2009 17:58:52 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more info on juno on windows > > Tony: > > I just tried these options. Here are results: > > recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line > 1706, while nogc gets assert in WinContext.m3 line 165. I note that > the juno window begins drawing before the crash on nogc whereas it > does not on paranoidgc. > > recent cm3 on Vista, same results as above except that it appears to > reference an illegal memory location before hitting the assert in > the RTCollector when using paranoidgc. > > old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating > assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to > abort the repeating error message. Not sure if anything else > happens first because it scrolls too far. For nogc, we get same > behavoir as the other tests above. > > Regards, > Randy > > >>> Tony Hosking 9/22/2009 5:46 PM >>> > Have you tried running with @M3nogc? And @M3paranoidgc? > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Sep 2009, at 17:39, Jay K wrote: > > > Again, what I see is that many versions before around Feb 20 2007 > consistently fail with that same assertion failure. > > I have tested many versions now, recently. > > But versions after Feb 20 2007 usually access violate on the address > 0x20000 or so, sometimes other addresses, sometimes various > assertion failures. I believe this is much worse than merely always > failing the same assertion. > > > > - Jay > > > > Date: Tue, 22 Sep 2009 17:06:20 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] more info on juno on windows > > > > > Do we know whether or not Juno ever worked on Windows ? > > I don't recall ever testing it on Windows. I still have a vd5.7.0 > cm3 that I used for the project I finished up last year (August > 2008). If I run Juno on this system (Windows XP SP3), Juno crashes > with an ASSERT failure at line 165 in winvbt/WinContext.m3. The > date on the juno.exe is 8/19/2008. > > Regards, > Randy > > Jay K 9/22/2009 2:57 PM >>> > Here is the truncated part from the previous: > > This change, I think, causes Juno to access violate whereas before > it "only" failed assertions. > I believe it is considered fairly ok for a safe system to terminate > with an assertion failure, > that might not be a bug at all, but considered far worse to hit a > SIGSEGV > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 01:28:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 25 Sep 2009 23:28:05 +0000 Subject: [M3devel] formsedit Message-ID: I can confirm that formsedit fails on PPC_DARWIN too. The same as on Solaris/sparc32. Juno and Cube work fine. Current source. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 26 02:06:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Sep 2009 20:06:07 -0400 Subject: [M3devel] formsedit In-Reply-To: References: Message-ID: OK, thanks. I think we can track this down easily. Perhaps an endianness issue? Both are big-endian whereas Intel are little. I'm not sure what other big-endian platforms M3 has ever run on, so perhaps this is a dark and dusty corner... On 25 Sep 2009, at 19:28, Jay K wrote: > I can confirm that formsedit fails on PPC_DARWIN too. The same as on > Solaris/sparc32. > Juno and Cube work fine. > Current source. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 05:19:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 03:19:54 +0000 Subject: [M3devel] formsedit In-Reply-To: References: Message-ID: I forgot to mention: This was on an actual PPC machine. I /assume/ it can be reproed under emulation on x86 but I didn't try. > big endian I could try out my HP-UX/hppa machine again. :) Seriously it was working. I also had Linux/hppa running, but not Modula-3. I have some bids on eBay for some Mac/68K machines. :) I don't think I have seen on this Linux/sparc or Linux/ppc, but I will definitely try those. I don't remember if I tried. They are up and running well, even in Hudson. I can give you ssh access to all/several of these, send me your ssh public key. Could do OPEN/NETFREE/BSD/sparc/ppc too, with a little more time. (FreeBSD/ppc is a pain to install -- no partitioner -- and I haven't succeeded, but Net/Open are easy.) - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 25 Sep 2009 20:06:07 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] formsedit OK, thanks. I think we can track this down easily. Perhaps an endianness issue? Both are big-endian whereas Intel are little. I'm not sure what other big-endian platforms M3 has ever run on, so perhaps this is a dark and dusty corner... On 25 Sep 2009, at 19:28, Jay K wrote: I can confirm that formsedit fails on PPC_DARWIN too. The same as on Solaris/sparc32. Juno and Cube work fine. Current source. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 11:44:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 09:44:46 +0000 Subject: [M3devel] birch is out of diskspace Message-ID: birch is out of diskspace I'll free up some, but probably not much. I /might/ download some older archives locally. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Sat Sep 26 11:49:15 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Sat, 26 Sep 2009 11:49:15 +0200 Subject: [M3devel] birch is out of diskspace In-Reply-To: References: Message-ID: <20090926114915.0457c6tx1c0ogssc@mail.elego.de> Quoting Jay K : > > birch is out of diskspace > I'm on it. -Mike > I'll free up some, but probably not much. > I /might/ download some older archives locally. > > - Jay > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Sep 26 12:04:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 10:04:06 +0000 Subject: [M3devel] birch is out of diskspace In-Reply-To: <20090926114915.0457c6tx1c0ogssc@mail.elego.de> References: Message-ID: Thanks. It looks like I was maybe using ~7gig and I'm down to ~1gig and still cleaning up. - Jay > Date: Sat, 26 Sep 2009 11:49:15 +0200 > From: michael.anderson at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] birch is out of diskspace > > Quoting Jay K : > > > > > birch is out of diskspace > > > > I'm on it. > > -Mike > > > I'll free up some, but probably not much. > > I /might/ download some older archives locally. > > > > - Jay > > > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 19:01:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 17:01:48 +0000 Subject: [M3devel] formsedit In-Reply-To: References: Message-ID: No problem on Linux/sparc or Linux/powerpc. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] formsedit Date: Sat, 26 Sep 2009 03:19:54 +0000 I forgot to mention: This was on an actual PPC machine. I /assume/ it can be reproed under emulation on x86 but I didn't try. > big endian I could try out my HP-UX/hppa machine again. :) Seriously it was working. I also had Linux/hppa running, but not Modula-3. I have some bids on eBay for some Mac/68K machines. :) I don't think I have seen on this Linux/sparc or Linux/ppc, but I will definitely try those. I don't remember if I tried. They are up and running well, even in Hudson. I can give you ssh access to all/several of these, send me your ssh public key. Could do OPEN/NETFREE/BSD/sparc/ppc too, with a little more time. (FreeBSD/ppc is a pain to install -- no partitioner -- and I haven't succeeded, but Net/Open are easy.) - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 25 Sep 2009 20:06:07 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] formsedit OK, thanks. I think we can track this down easily. Perhaps an endianness issue? Both are big-endian whereas Intel are little. I'm not sure what other big-endian platforms M3 has ever run on, so perhaps this is a dark and dusty corner... On 25 Sep 2009, at 19:28, Jay K wrote: I can confirm that formsedit fails on PPC_DARWIN too. The same as on Solaris/sparc32. Juno and Cube work fine. Current source. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Sep 26 21:11:02 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 26 Sep 2009 21:11:02 +0200 Subject: [M3devel] LONGINT, looks urgent... Message-ID: <1253992263.13608.17.camel@faramir.m3w.org> Spent a piece of day with pdv := osnovica * 17L DIV 100L; varying osnovica from 1, over 1791, 1793... and many more. It looks like LONGINT arithmetic in anything except simplest expressions is broken. When turned to: WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO pdv := step2; END; it works... I have no much time ATM (doing various M3+Gtk+ tasks right now, tight on delivery schedule) to check it more. My version is a bit rusty but not much. If nobody makes more research, I'll - few weeks is most earliest I can expect any free time. -- Dragi?a Duri? From dragisha at m3w.org Sun Sep 27 00:19:54 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 27 Sep 2009 00:19:54 +0200 Subject: [M3devel] Just thinking.... runtime creation of types Message-ID: <1254003594.13608.21.camel@faramir.m3w.org> What steps are needed to create modula-3 type at runtime? Obviously, it can be fully used only from some scripting engine (and I have one, already using type found on start/after plugin load)... But integration with other types will simplify things. Also - new objects can be handled where supertypes can. IMO, very useful. -- Dragi?a Duri? From hosking at cs.purdue.edu Sun Sep 27 02:26:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 26 Sep 2009 20:26:55 -0400 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <1253992263.13608.17.camel@faramir.m3w.org> References: <1253992263.13608.17.camel@faramir.m3w.org> Message-ID: <585FE8AF-3874-41B7-9663-148E923415C7@cs.purdue.edu> What platform? On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > Spent a piece of day with > > pdv := osnovica * 17L DIV 100L; > > varying osnovica from 1, over 1791, 1793... and many more. It looks > like > LONGINT arithmetic in anything except simplest expressions is broken. > When turned to: > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > pdv := step2; > END; > > it works... > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > tight on > delivery schedule) to check it more. My version is a bit rusty but not > much. If nobody makes more research, I'll - few weeks is most > earliest I > can expect any free time. > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Sep 27 07:54:03 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 27 Sep 2009 07:54:03 +0200 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <585FE8AF-3874-41B7-9663-148E923415C7@cs.purdue.edu> References: <1253992263.13608.17.camel@faramir.m3w.org> <585FE8AF-3874-41B7-9663-148E923415C7@cs.purdue.edu> Message-ID: <1254030843.13608.24.camel@faramir.m3w.org> LINUXLIBC6, sorry for missing that. On Sat, 2009-09-26 at 20:26 -0400, Tony Hosking wrote: > What platform? > > On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > > > Spent a piece of day with > > > > pdv := osnovica * 17L DIV 100L; > > > > varying osnovica from 1, over 1791, 1793... and many more. It looks > > like > > LONGINT arithmetic in anything except simplest expressions is > > broken. > > When turned to: > > > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > > pdv := step2; > > END; > > > > it works... > > > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > > tight on > > delivery schedule) to check it more. My version is a bit rusty but > > not > > much. If nobody makes more research, I'll - few weeks is most > > earliest I > > can expect any free time. > > -- > > Dragi?a Duri? > > > -- Dragi?a Duri? From dragisha at m3w.org Sun Sep 27 13:34:23 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 27 Sep 2009 13:34:23 +0200 Subject: [M3devel] Sorry if FAQ, but there's no one...? :) Message-ID: <1254051264.13608.28.camel@faramir.m3w.org> I would like to send a program binary to friend for review, with Modula-3 libraries linked statically so he does not need to install cm3. build_standalone() tries to link staticlaly Gtk+ libs I am using, and they have no .a files and I want them as .so's anyway. LINUXLIBC6 -- Dragi?a Duri? From jay.krell at cornell.edu Sun Sep 27 14:32:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Sep 2009 12:32:24 +0000 Subject: [M3devel] Sorry if FAQ, but there's no one...? :) In-Reply-To: <1254051264.13608.28.camel@faramir.m3w.org> References: <1254051264.13608.28.camel@faramir.m3w.org> Message-ID: build_standalone() should be the answer. Are your Gtk+ libraries in Modula-3 or not? If they are in Modula-3, then that makes sense. As a quick hack, how about delete or move away the .a files that are being used that you don't want used? And, your config file doesn't say -static, right? I've seen that in older ones. Can you add build_standalone() to src/m3makefile rm -rf LINUXLIBC cm3 -commands and look at it and/or show us? This area is a bit wierd and gray imho, but will probably remain exactly asis. (I'm not saying we won't solve your problem. I think the current system already does.) The full flexibility is not exposed.. That is, it isn't likely to let you pick and chose which lib is static and which is dynamic, unless the library itself is build_standalone(), in which case always static. - Jay > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sun, 27 Sep 2009 13:34:23 +0200 > Subject: [M3devel] Sorry if FAQ, but there's no one...? :) > > I would like to send a program binary to friend for review, with > Modula-3 libraries linked statically so he does not need to install cm3. > build_standalone() tries to link staticlaly Gtk+ libs I am using, and > they have no .a files and I want them as .so's anyway. > > LINUXLIBC6 > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Sep 27 14:35:30 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 27 Sep 2009 08:35:30 -0400 Subject: [M3devel] Just thinking.... runtime creation of types In-Reply-To: <1254003594.13608.21.camel@faramir.m3w.org> References: <1254003594.13608.21.camel@faramir.m3w.org> Message-ID: <20090927123529.GB3719@topoi.pooq.com> On Sun, Sep 27, 2009 at 12:19:54AM +0200, Dragi?a Duri? wrote: > What steps are needed to create modula-3 type at runtime? > > Obviously, it can be fully used only from some scripting engine (and I > have one, already using type found on start/after plugin load)... But > integration with other types will simplify things. Also - new objects > can be handled where supertypes can. IMO, very useful. > -- > Dragi?a Duri? > It could also be used for code generated at run-time -- something I've wanted to do for a while now. -- hendrik From hosking at cs.purdue.edu Sun Sep 27 15:19:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 09:19:03 -0400 Subject: [M3devel] Sorry if FAQ, but there's no one...? :) In-Reply-To: <1254051264.13608.28.camel@faramir.m3w.org> References: <1254051264.13608.28.camel@faramir.m3w.org> Message-ID: <6493A410-33FF-4611-BD2B-4ED597C2FAFD@cs.purdue.edu> You could define the gtk+ libs as system libs in the config file, prefixed with dynamic linking directives. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Sep 2009, at 07:34, Dragi?a Duri? wrote: > I would like to send a program binary to friend for review, with > Modula-3 libraries linked statically so he does not need to install > cm3. > build_standalone() tries to link staticlaly Gtk+ libs I am using, and > they have no .a files and I want them as .so's anyway. > > LINUXLIBC6 > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Sep 27 19:49:03 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 27 Sep 2009 13:49:03 -0400 Subject: [M3devel] cvs error Message-ID: <4ABF6D2D.1E75.00D7.1@scires.com> I am getting the following CVS errors when I update my sandbox: In C:\cm3\Sandbox: "C:\Program Files\CVSNT\cvs.exe" -q update -P -d CVSROOT=:ssh:rcoleburn at birch.elegosoft.com:/usr/cvs cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' Not sure why this is happening. I did not edit any of these files. Any ideas on how to resolve? Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 27 20:14:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Sep 2009 18:14:37 +0000 Subject: [M3devel] cvs error In-Reply-To: <4ABF6D2D.1E75.00D7.1@scires.com> References: <4ABF6D2D.1E75.00D7.1@scires.com> Message-ID: I don't know, but out of ignorance I often do heavy handed stuff to fix my local cvs. like cd m3-sys rm -rf m3cc # rd /q/s m3cc on NT cvs -z3 upd -dAP m3cc if I don't have any changes in m3cc. - Jay Date: Sun, 27 Sep 2009 13:49:03 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] cvs error I am getting the following CVS errors when I update my sandbox: In C:\cm3\Sandbox: "C:\Program Files\CVSNT\cvs.exe" -q update -P -d CVSROOT=:ssh:rcoleburn at birch.elegosoft.com:/usr/cvs cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' Not sure why this is happening. I did not edit any of these files. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 27 20:19:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Sep 2009 18:19:26 +0000 Subject: [M3devel] m3tests hanging Message-ID: tests seemed hung on I386_DARWIN and I386_OPENBSD. I killed some processes to let them continue. OpenBSD I think we could blame on p007 that Tony fixed already? I copied from head. I haven't had good experience with having CVS do merges -- what changes to tell it? You just have to know? I often manually diff stuff and copy diffs. In this case I just copied the entire file. I wonder if we should apply for a Perforce open source license. It does branching very well, knowing what changes are where. Darwin I don't have an explanation for. So we'll have to just watch it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 27 20:59:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 14:59:29 -0400 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <1253992263.13608.17.camel@faramir.m3w.org> References: <1253992263.13608.17.camel@faramir.m3w.org> Message-ID: <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> It works OK for me on I386_DARWIN running with the CVS head. This program produces identical output for both the INTEGER and LONGINT values. Main.m3: MODULE Main; IMPORT MainC; VAR a, i: INTEGER; aa: LONGINT; BEGIN i := 0; FOR ii := 1L TO 1793L DO INC(i); a := i * 17 DIV 100; MainC.PutInt(a); aa := ii * 17L DIV 100L; MainC.PutLong(aa); END; END Main. MainC.i3: INTERFACE MainC; <*EXTERNAL*> PROCEDURE PutLong (x: LONGINT); <*EXTERNAL*> PROCEDURE PutInt (x: INTEGER); END MainC. MainC.C: #include void PutLong (long long x) { printf("%d\n", x); } void PutInt (long x) { printf("%d\n", x); } On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > Spent a piece of day with > > pdv := osnovica * 17L DIV 100L; > > varying osnovica from 1, over 1791, 1793... and many more. It looks > like > LONGINT arithmetic in anything except simplest expressions is broken. > When turned to: > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > pdv := step2; > END; > > it works... > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > tight on > delivery schedule) to check it more. My version is a bit rusty but not > much. If nobody makes more research, I'll - few weeks is most > earliest I > can expect any free time. > -- > Dragi?a Duri? From hosking at cs.purdue.edu Sun Sep 27 21:32:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 15:32:35 -0400 Subject: [M3devel] Config file skeletons Message-ID: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> Where did all the config file skeletons go? How do I fix the SOLgnu installation to look for libz.so instead of libz.a. I thought I could simply add a "Z" entry to SYSTEM_LIBS, but I don't know where to do that anymore. That way my tinderbox builds should succeed for the cvsup packages which need libz, but which is not normally installed as a static library. From hosking at cs.purdue.edu Sun Sep 27 21:53:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 15:53:52 -0400 Subject: [M3devel] Broken CVS head Message-ID: <60D3CE30-BF24-4972-ADF1-E49183533E6A@cs.purdue.edu> Jay, CVS head is broken right now because of your changes to m3core/ src/float/m3makefile and m3core/src/Csupport/m3makefile. I'm not sure if this is because I have an old config file or what, but it looks like the quake function "FileExists" is not defined anywhere. Just as a courtesy to others, please try to test commits before pushing them to the CVS head. At minimum, one should be able to build the head without errors. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 28 02:19:01 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 27 Sep 2009 17:19:01 -0700 Subject: [M3devel] Config file skeletons In-Reply-To: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> References: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> Message-ID: <793451C3-475A-446A-8E44-6B4319599704@hotmail.com> Find . | grep SOLgnu$ M3-sys/cminstall/src/config-no-install - Jay (phone) On Sep 27, 2009, at 12:32 PM, Tony Hosking wrote: > Where did all the config file skeletons go? How do I fix the > SOLgnu installation to look for libz.so instead of libz.a. I > thought I could simply add a "Z" entry to SYSTEM_LIBS, but I don't > know where to do that anymore. That way my tinderbox builds should > succeed for the cvsup packages which need libz, but which is not > normally installed as a static library. > > From wagner at elegosoft.com Mon Sep 28 10:32:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 10:32:58 +0200 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> References: <1253992263.13608.17.camel@faramir.m3w.org> <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> Message-ID: <20090928103258.tlrry9cuocg88ss8@mail.elegosoft.com> Quoting Tony Hosking : > It works OK for me on I386_DARWIN running with the CVS head. This > program produces identical output for both the INTEGER and LONGINT > values. > > Main.m3: > > MODULE Main; > IMPORT MainC; > > VAR > a, i: INTEGER; > aa: LONGINT; > BEGIN > i := 0; > FOR ii := 1L TO 1793L DO > INC(i); > a := i * 17 DIV 100; > MainC.PutInt(a); > aa := ii * 17L DIV 100L; > MainC.PutLong(aa); > END; > END Main. > > MainC.i3: > > INTERFACE MainC; > > <*EXTERNAL*> PROCEDURE PutLong (x: LONGINT); > <*EXTERNAL*> PROCEDURE PutInt (x: INTEGER); > > END MainC. > > MainC.C: > > #include > > void PutLong (long long x) { > printf("%d\n", x); > } > > void PutInt (long x) { > printf("%d\n", x); > } > > > On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > >> Spent a piece of day with >> >> pdv := osnovica * 17L DIV 100L; >> >> varying osnovica from 1, over 1791, 1793... and many more. It looks like >> LONGINT arithmetic in anything except simplest expressions is broken. >> When turned to: >> >> WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO >> pdv := step2; >> END; >> >> it works... >> >> I have no much time ATM (doing various M3+Gtk+ tasks right now, tight on >> delivery schedule) to check it more. My version is a bit rusty but not >> much. If nobody makes more research, I'll - few weeks is most earliest I >> can expect any free time. I know that everybody else is busy, too, but we should o open a ticket for this issue in trac o add the test program to m3-sys/m3tests so that it is run on all regression test platforms automatically Any volunteers? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Sep 28 11:13:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 11:13:27 +0200 Subject: [M3devel] cvs error In-Reply-To: <4ABF6D2D.1E75.00D7.1@scires.com> References: <4ABF6D2D.1E75.00D7.1@scires.com> Message-ID: <20090928111327.ivuoyshlsgsc4sg4@mail.elegosoft.com> Quoting Randy Coleburn : > I am getting the following CVS errors when I update my sandbox: > > In C:\cm3\Sandbox: "C:\Program Files\CVSNT\cvs.exe" -q update -P -d > CVSROOT=:ssh:rcoleburn at birch.elegosoft.com:/usr/cvs > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for > `m3-sys/m3cc/gcc/fixincludes' > Not sure why this is happening. I did not edit any of these files. > > Any ideas on how to resolve? This is no error. CVS just thinks that the mentioned files should be under version control but aren't. Indeed they are probably generated by some make target, so I think it should be OK. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Sep 28 11:18:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 11:18:21 +0200 Subject: [M3devel] m3tests hanging In-Reply-To: References: Message-ID: <20090928111821.ii777ufy5cook4ko@mail.elegosoft.com> Quoting Jay K : > > tests seemed hung on I386_DARWIN and I386_OPENBSD. > I killed some processes to let them continue. > > OpenBSD I think we could blame on p007 that Tony fixed already? I > copied from head. > I haven't had good experience with having CVS do merges -- what > changes to tell it? You just have to know? I often manually diff > stuff and copy diffs. I posted a description on cvs merges some days ago, or didn't it show up on the list? > In this case I just copied the entire file. I wonder if we should > apply for a Perforce > open source license. It does branching very well, knowing what > changes are where. Not now. If everybody agrees (which I don't think, as others will prefer subversion or git or mercurial or ...) _and_ we do much branching, Perforce might be a good idea. But until now branching was only used for infrequent release branches, which CVS should be able to handle, too. > Darwin I don't have an explanation for. > So we'll have to just watch it. So p007 should now terminate on any platform with Tony's fixes? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Sep 28 11:31:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 28 Sep 2009 09:31:02 +0000 Subject: [M3devel] m3tests hanging In-Reply-To: <20090928111821.ii777ufy5cook4ko@mail.elegosoft.com> References: Message-ID: > I posted a description on cvs merges some days ago, or didn't it show > up on the list? It seems to require me to know every change in the system and what branch it is in. I do that to some extent, and when I can't, I diff my two trees. With perforce you just tell it the two branches and it knows which changes are in which branch, basically. At least it seems to keep a high water mark. > > In this case I just copied the entire file. I wonder if we should > > apply for a Perforce > > open source license. It does branching very well, knowing what > > changes are where. > > Not now. If everybody agrees (which I don't think, as others will > prefer subversion or git or mercurial or ...) _and_ we do much branching, I've done some research here sort of, at least read stuff, guaged popular opinion. I have a lot of experience with Perforce and highly recommend it. But it isn't free beer for any project and source isn't available. It isn't just merging/branching that it does well. It does basically everything well, except it isn't distributed. It has a good command line interface, a good gui, pretty good platform support. I'm not sure of its perf over slow network. Otherwise git and mercurial seem to the most popular, but git is seen as perhaps too hard to use. I might shortly have to use/learn mercurial for a small project (said project considered git as well, but chose mercurial). Subversion is better than CVS and has atomic multi-file changesets. Historically its branching support is terrible, again you have to know which changes are in which branch. They might have fixed that by now. Monotone sounds good, but git and mercurial seem more popular. Conversion from cvs seems supported well enough. Some of the systems support on-going bidirectional conversion, including accepting CVS commits. Some support read only CVS mirrors. > So p007 should now terminate on any platform with Tony's fixes? That is my hope/expectation. I haven't tested it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Sep 28 12:24:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 12:24:44 +0200 Subject: [M3devel] Config file skeletons In-Reply-To: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> References: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> Message-ID: <20090928122444.73xexhn69wcs8k0w@mail.elegosoft.com> Quoting Tony Hosking : > Where did all the config file skeletons go? How do I fix the SOLgnu > installation to look for libz.so instead of libz.a. I thought I could > simply add a "Z" entry to SYSTEM_LIBS, but I don't know where to do > that anymore. That way my tinderbox builds should succeed for the > cvsup packages which need libz, but which is not normally installed as > a static library. Wasn't the problem that libz is not yet contained in SYSTEM_LIBS, but looked up with some local quake magic? At least there's a ticket in trac related to this failure: https://projects.elego.de/cm3/ticket/1048 I don't know why it isn't fixed yet, doesn't look too difficult. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Sep 28 12:55:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 28 Sep 2009 10:55:19 +0000 Subject: [M3devel] Juno on Windows, some inconclusive investigation.. Message-ID: 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: From dragisha at m3w.org Mon Sep 28 13:17:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 28 Sep 2009 13:17:34 +0200 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> References: <1253992263.13608.17.camel@faramir.m3w.org> <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> Message-ID: <1254136654.13608.558.camel@faramir.m3w.org> Mea culpa... Test code alone works well on LINUXLIBC6, it's obviously something higher up. I've used Fmt.LongInt, but addedd to this code, it also works well. I'll check it more, for now - sorry for false alarm. On Sun, 2009-09-27 at 14:59 -0400, Tony Hosking wrote: > It works OK for me on I386_DARWIN running with the CVS head. This > program produces identical output for both the INTEGER and LONGINT > values. > > Main.m3: > > MODULE Main; > IMPORT MainC; > > VAR > a, i: INTEGER; > aa: LONGINT; > BEGIN > i := 0; > FOR ii := 1L TO 1793L DO > INC(i); > a := i * 17 DIV 100; > MainC.PutInt(a); > aa := ii * 17L DIV 100L; > MainC.PutLong(aa); > END; > END Main. > > MainC.i3: > > INTERFACE MainC; > > <*EXTERNAL*> PROCEDURE PutLong (x: LONGINT); > <*EXTERNAL*> PROCEDURE PutInt (x: INTEGER); > > END MainC. > > MainC.C: > > #include > > void PutLong (long long x) { > printf("%d\n", x); > } > > void PutInt (long x) { > printf("%d\n", x); > } > > > On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > > > Spent a piece of day with > > > > pdv := osnovica * 17L DIV 100L; > > > > varying osnovica from 1, over 1791, 1793... and many more. It looks > > like > > LONGINT arithmetic in anything except simplest expressions is broken. > > When turned to: > > > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > > pdv := step2; > > END; > > > > it works... > > > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > > tight on > > delivery schedule) to check it more. My version is a bit rusty but not > > much. If nobody makes more research, I'll - few weeks is most > > earliest I > > can expect any free time. > > -- > > Dragi?a Duri? > -- Dragi?a Duri? From jay.krell at cornell.edu Mon Sep 28 15:11:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 28 Sep 2009 13:11:28 +0000 Subject: [M3devel] help debugging Juno..sanity check? Message-ID: So, I know that ThreadWin32.T instances are prone to being overwritten. So I did this: T = BRANDED "Thread.T Win32-1.0" OBJECT > pad1: ARRAY [0..16_1000] OF CHAR; > protect: ARRAY [0..16_1] OF CHAR; > pad2: ARRAY [0..16_1000] OF CHAR; And then there are two occurences of NEW(T): next_self := NEW(T); > Protect(next_self); PROCEDURE CreateT (act: Activation): T = (* LL = 0, because allocating a traced reference may cause the allocator to start a collection which will call "SuspendOthers" which will try to acquire "activeMu". *) VAR t := NEW(T, act := act); BEGIN > Protect(t); PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); END Protect; This should catch any writes to these fields. Now, a thread can be garbage collected and reused. And I'd want to unprotect this memory. Or prevent the garbage collector from deciding any thread is garbage. Second option seems easier and suffices. So: VAR threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) threadCount: INTEGER; and more completely: PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); RTIO.PutInt(threadCount); RTIO.PutText(" "); RTIO.PutAddr(ADR(threads)); RTIO.PutText(" "); RTIO.PutAddr(ADR(t.protect)); RTIO.PutText("\n"); threads[threadCount] := t; INC(threadCount); END Protect; And just in case, I emptied out the FreeSlot function. But yet I get: 0 0xe2abe0 0x1141021 1 0xe2abe0 0x114b429 2 0xe2abe0 0x11a2311 3 0xe2abe0 0x11a48b1 4 0xe2abe0 0x11ab499 5 0xe2abe0 0x12e9f11 6 0xe2abe0 0x12d211d 7 0xe2abe0 0x11bd691 8 0xe2abe0 0x11d1011 9 0xe2abe0 0x11d3e2d 10 0xe2abe0 0x11d6759 11 0xe2abe0 0x11d8bd1 12 0xe2abe0 0x12089f1 13 0xe2abe0 0x1211455 14 0xe2abe0 0x12138cd 15 0xe2abe0 0x1215ecd 16 0xe2abe0 0x12184cd 17 0xe2abe0 0x121bcd5 18 0xe2abe0 0x121e35d Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: 23% (b60.9d4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 edi=011bd000 eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 MSVCR90!fastzero_I+0x20: 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds:0023:011bd000=0000000 0000000000000000000000000 0:003> k ChildEBP RetAddr 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db 0:003> r edi edi=011bd000 0:003> What am I confused about? Why does it seem that even if I store some pointers in globals, they are getting garbage collected and reused? I should debug BuildGlobalMap?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 28 16:04:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Sep 2009 10:04:55 -0400 Subject: [M3devel] help debugging Juno..sanity check? In-Reply-To: References: Message-ID: <4297E27D-B5E9-48D2-BA1D-1CAE6332899D@cs.purdue.edu> Huh? I don't understand the point of all of this. Threads can be moved by the GC, even if referenced from globals. The only way to prevent a thread moving is to keep a reference to it on some thread stack. (I still don't know what you are trying to achieve -- why not use a hardware breakpoint in the debugger?). That's how I found the race in ScrollerVBTClass.m3. On 28 Sep 2009, at 09:11, Jay K wrote: > So, I know that ThreadWin32.T instances are prone to being > overwritten. > > So I did this: > > > T = BRANDED "Thread.T Win32-1.0" OBJECT > > pad1: ARRAY [0..16_1000] OF CHAR; > > protect: ARRAY [0..16_1] OF CHAR; > > pad2: ARRAY [0..16_1000] OF CHAR; > > And then there are two occurences of NEW(T): > > > next_self := NEW(T); > > Protect(next_self); > > > PROCEDURE CreateT (act: Activation): T = > (* LL = 0, because allocating a traced reference may cause > the allocator to start a collection which will call > "SuspendOthers" > which will try to acquire "activeMu". *) > VAR t := NEW(T, act := act); > BEGIN > > Protect(t); > > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > END Protect; > > > This should catch any writes to these fields. > > > Now, a thread can be garbage collected and reused. > And I'd want to unprotect this memory. > Or prevent the garbage collector from deciding any thread is garbage. > Second option seems easier and suffices. > > > So: > > > VAR > threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) > threadCount: INTEGER; > > > and more completely: > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > RTIO.PutInt(threadCount); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(threads)); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(t.protect)); > RTIO.PutText("\n"); > threads[threadCount] := t; > INC(threadCount); > END Protect; > > > And just in case, I emptied out the FreeSlot function. > > > But yet I get: > > 0 0xe2abe0 0x1141021 > 1 0xe2abe0 0x114b429 > 2 0xe2abe0 0x11a2311 > 3 0xe2abe0 0x11a48b1 > 4 0xe2abe0 0x11ab499 > 5 0xe2abe0 0x12e9f11 > 6 0xe2abe0 0x12d211d > 7 0xe2abe0 0x11bd691 > 8 0xe2abe0 0x11d1011 > 9 0xe2abe0 0x11d3e2d > 10 0xe2abe0 0x11d6759 > 11 0xe2abe0 0x11d8bd1 > 12 0xe2abe0 0x12089f1 > 13 0xe2abe0 0x1211455 > 14 0xe2abe0 0x12138cd > 15 0xe2abe0 0x1215ecd > 16 0xe2abe0 0x12184cd > 17 0xe2abe0 0x121bcd5 > 18 0xe2abe0 0x121e35d > Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: > 23% > (b60.9d4): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 > edi=011bd000 > eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > MSVCR90!fastzero_I+0x20: > 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds: > 0023:011bd000=0000000 > 0000000000000000000000000 > 0:003> k > ChildEBP RetAddr > 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 > 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 > 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f > 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 > 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec > 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c > 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 > 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e > 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e > 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b > 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 > 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f > 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 > 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 > 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 > 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 > 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf > 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db > 0:003> r edi > edi=011bd000 > 0:003> > > > What am I confused about? > > Why does it seem that even if I store some pointers in globals, they > are getting garbage collected and reused? > > I should debug BuildGlobalMap?? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 07:39:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 05:39:24 +0000 Subject: [M3devel] help debugging Juno..sanity check? In-Reply-To: <4297E27D-B5E9-48D2-BA1D-1CAE6332899D@cs.purdue.edu> References: Message-ID: oops, thanks, I forgot gc is compacting. I don't see how to use a hardware breakpoint, the corruption seems to always move around. This is an attempt to set a hardware breakpoint programmatically based on what the runtime addresses happen to be. I do know these bytes are getting overwritten. If I assert they are zero in Join, inevitably the assert fails. I think I might try to vary the Juno pixmaps, see if the altered data appears in the corruption, try to prove, as it appears, that the corruption is pixmap data. Thanks, - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 28 Sep 2009 10:04:55 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] help debugging Juno..sanity check? Huh? I don't understand the point of all of this. Threads can be moved by the GC, even if referenced from globals. The only way to prevent a thread moving is to keep a reference to it on some thread stack. (I still don't know what you are trying to achieve -- why not use a hardware breakpoint in the debugger?). That's how I found the race in ScrollerVBTClass.m3. On 28 Sep 2009, at 09:11, Jay K wrote: So, I know that ThreadWin32.T instances are prone to being overwritten. So I did this: T = BRANDED "Thread.T Win32-1.0" OBJECT > pad1: ARRAY [0..16_1000] OF CHAR; > protect: ARRAY [0..16_1] OF CHAR; > pad2: ARRAY [0..16_1000] OF CHAR; And then there are two occurences of NEW(T): next_self := NEW(T); > Protect(next_self); PROCEDURE CreateT (act: Activation): T = (* LL = 0, because allocating a traced reference may cause the allocator to start a collection which will call "SuspendOthers" which will try to acquire "activeMu". *) VAR t := NEW(T, act := act); BEGIN > Protect(t); PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); END Protect; This should catch any writes to these fields. Now, a thread can be garbage collected and reused. And I'd want to unprotect this memory. Or prevent the garbage collector from deciding any thread is garbage. Second option seems easier and suffices. So: VAR threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) threadCount: INTEGER; and more completely: PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); RTIO.PutInt(threadCount); RTIO.PutText(" "); RTIO.PutAddr(ADR(threads)); RTIO.PutText(" "); RTIO.PutAddr(ADR(t.protect)); RTIO.PutText("\n"); threads[threadCount] := t; INC(threadCount); END Protect; And just in case, I emptied out the FreeSlot function. But yet I get: 0 0xe2abe0 0x1141021 1 0xe2abe0 0x114b429 2 0xe2abe0 0x11a2311 3 0xe2abe0 0x11a48b1 4 0xe2abe0 0x11ab499 5 0xe2abe0 0x12e9f11 6 0xe2abe0 0x12d211d 7 0xe2abe0 0x11bd691 8 0xe2abe0 0x11d1011 9 0xe2abe0 0x11d3e2d 10 0xe2abe0 0x11d6759 11 0xe2abe0 0x11d8bd1 12 0xe2abe0 0x12089f1 13 0xe2abe0 0x1211455 14 0xe2abe0 0x12138cd 15 0xe2abe0 0x1215ecd 16 0xe2abe0 0x12184cd 17 0xe2abe0 0x121bcd5 18 0xe2abe0 0x121e35d Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: 23% (b60.9d4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 edi=011bd000 eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 MSVCR90!fastzero_I+0x20: 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds:0023:011bd000=0000000 0000000000000000000000000 0:003> k ChildEBP RetAddr 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db 0:003> r edi edi=011bd000 0:003> What am I confused about? Why does it seem that even if I store some pointers in globals, they are getting garbage collected and reused? I should debug BuildGlobalMap?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 09:47:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 07:47:15 +0000 Subject: [M3devel] why Thread.Wait immediately after Thread.Fork? Message-ID: What is the point of Thread.Wait(Thread.Fork(NEW(ClosureType....)); vs. just: NEW(ClosureType....).apply(); ? The only reason I can think of is to ensure more stack the ClosureType().apply() than might be present on the current thread. OR maybe an assertion on the author's part that the work could/should be performed without waiting, but he hasn't made it so yet? OR maybe so user can interrupt long running operation with control-c? But that works the same on the original thread, right? OR maybe to stress test the threading library and ensure that thread creation is cheap?? These do seem like wasted threads. I have found a few examples. Here is one: m3-ui\formsvbt\src\FormsVBT.m3 PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T RAISES {Error} = BEGIN TYPECASE Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000, description := description, fv := t, state := state))) OF | TEXT (msg) => RAISE Error (msg) | VBT.T (ch) => RETURN ch ELSE <* ASSERT FALSE *> END END Parse; why not: PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T RAISES {Error} = BEGIN TYPECASE NEW (ParseClosure, stackSize := 10000, description := description, fv := t, state := state).apply() OF | TEXT (msg) => RAISE Error (msg) | VBT.T (ch) => RETURN ch ELSE <* ASSERT FALSE *> END END Parse; If the point is to ensure enough stack, perhaps a mechanism to report how much stack is left would be reasonable?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 29 10:08:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Sep 2009 10:08:56 +0200 Subject: [M3devel] why Thread.Wait immediately after Thread.Fork? In-Reply-To: References: Message-ID: <20090929100856.j46qpa66m8k4c84w@mail.elegosoft.com> My guess would be it is the stacksize. The parser will probably be a simple LL implementation, and the default size for thread stacks was (is?) notorious small in M3. What are the current defaults? Olaf Quoting Jay K : > What is the point of > > Thread.Wait(Thread.Fork(NEW(ClosureType....)); > > vs. just: > > NEW(ClosureType....).apply(); > > ? > > The only reason I can think of is to ensure more stack the > ClosureType().apply() than might be present on the current thread. > > OR maybe an assertion on the author's part that the work > could/should be performed without waiting, but he hasn't made it so > yet? > > > OR maybe so user can interrupt long running operation with > control-c? But that works the same on the original thread, right? > > > > OR maybe to stress test the threading library and ensure that thread > creation is cheap?? > > These do seem like wasted threads. > > > > I have found a few examples. Here is one: > > > > > m3-ui\formsvbt\src\FormsVBT.m3 > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > RAISES {Error} = > BEGIN > TYPECASE > Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000, > description := description, fv := t, > state := state))) OF > | TEXT (msg) => RAISE Error (msg) > | VBT.T (ch) => RETURN ch > ELSE <* ASSERT FALSE *> > END > END Parse; > > > > > why not: > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > RAISES {Error} = > BEGIN > TYPECASE > NEW (ParseClosure, stackSize := 10000, > description := description, fv := t, > state := state).apply() OF > | TEXT (msg) => RAISE Error (msg) > | VBT.T (ch) => RETURN ch > ELSE <* ASSERT FALSE *> > END > END Parse; > > > > > > If the point is to ensure enough stack, perhaps a mechanism to > report how much stack is left would be reasonable?? > > > > > - Jay > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 29 10:13:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 08:13:51 +0000 Subject: [M3devel] Juno/Win32 possibly somewhat understood Message-ID: So..in order to simplify debugging, I started removing and simplifying code, as long as the failures were similar. Sometimes I'd get an array overflow as a result -- like if I removed code that initialized stuff. I focused on: removing maybe unnecessary threads -- like the FileBrowserVBT.Watcher, the font cleanupt thread I changed uses of Wait(Fork(NEW(T)) to just NEW(T).apply() I did also remove a bunch of Trestle redraw code that was often on the stack. Eventually, while almost nothing got drawn, Juno seemed to crash less often and more consistently. So I undid/redid stuff. It seems the main thing I had altered was using fewer threads. So, a quick look at ThreadWin32.m3. It maintains some idle threads. If I remove that, Juno seems to stop crashing. I'm going to double check stuff. Like undo all my other changes. Maybe even try setting the idle thread count to 0 instead of removing the code. See if my findings repeat themselves. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 10:18:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 08:18:05 +0000 Subject: [M3devel] why Thread.Wait immediately after Thread.Fork? In-Reply-To: <20090929100856.j46qpa66m8k4c84w@mail.elegosoft.com> References: Message-ID: The defaults are still small. C:\dev2\cm3.2\m3-libs\m3core\src\thread\POSIX\ThreadPosix.m3(196): defaultStackSize := 3000; C:\dev2\cm3.2\m3-libs\m3core\src\thread\PTHREAD\ThreadPThread.m3(819):VAR defaultStackSize := 4096; I did some experimentation, and I was HOPING to find something like: Among all supported platforms, the smallest actual creatable stack is 64K, therefore set our minimum to 64K. Or even 16K. However I didn't find that to be true. I think I found I could create stacks as small as 4K, maybe even less. On the other hand, I'm sure a number of platforms cannot create such small stacks. Also I believe the Linux default stack is a whopping 8MB, so you sometimes find code that fails with smaller than that. NT defaults tend to either be 1MB or 256K, maybe doubled for 64bit. - Jay > Date: Tue, 29 Sep 2009 10:08:56 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] why Thread.Wait immediately after Thread.Fork? > > My guess would be it is the stacksize. The parser will probably > be a simple LL implementation, and the default size for thread > stacks was (is?) notorious small in M3. > > What are the current defaults? > > Olaf > > Quoting Jay K : > > > What is the point of > > > > Thread.Wait(Thread.Fork(NEW(ClosureType....)); > > > > vs. just: > > > > NEW(ClosureType....).apply(); > > > > ? > > > > The only reason I can think of is to ensure more stack the > > ClosureType().apply() than might be present on the current thread. > > > > OR maybe an assertion on the author's part that the work > > could/should be performed without waiting, but he hasn't made it so > > yet? > > > > > > OR maybe so user can interrupt long running operation with > > control-c? But that works the same on the original thread, right? > > > > > > > > OR maybe to stress test the threading library and ensure that thread > > creation is cheap?? > > > > These do seem like wasted threads. > > > > > > > > I have found a few examples. Here is one: > > > > > > > > > > m3-ui\formsvbt\src\FormsVBT.m3 > > > > > > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > > RAISES {Error} = > > BEGIN > > TYPECASE > > Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000, > > description := description, fv := t, > > state := state))) OF > > | TEXT (msg) => RAISE Error (msg) > > | VBT.T (ch) => RETURN ch > > ELSE <* ASSERT FALSE *> > > END > > END Parse; > > > > > > > > > > why not: > > > > > > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > > RAISES {Error} = > > BEGIN > > TYPECASE > > NEW (ParseClosure, stackSize := 10000, > > description := description, fv := t, > > state := state).apply() OF > > | TEXT (msg) => RAISE Error (msg) > > | VBT.T (ch) => RETURN ch > > ELSE <* ASSERT FALSE *> > > END > > END Parse; > > > > > > > > > > > > If the point is to ensure enough stack, perhaps a mechanism to > > report how much stack is left would be reasonable?? > > > > > > > > > > - Jay > > > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 11:18:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 09:18:57 +0000 Subject: [M3devel] ThreadF.MyID? Message-ID: The algorithms for thread id assignment vary on the platforms. In posix user threads and Win32 threads, it appears to be a number that increments for every new thread. Not sure what happens after 2 or 4 billion. On pthreads, it appears to be, well, we maintain an array of threads. So it is a number between 0 and n where n is the maximum number of threads that have "ever" been running at the same time. With presumably aggressive reuse of ids. Ok? They should all use the same? It's just that I'm looking at the Win32 code, comparing it to the pthread code: Win32: LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); Pthread doesn't have this code. I don't believe self.closure needs a lock. And per above, pthreads doesn't need protection here for id, since it is handled elsewhere. I know this was just discussed in a sense -- MyId is for debugging/diagnostics only and its value can't be depended on for much. The are obvious advantages/disadvantages to the two schemes. Win32/Posix recycle "never", so debugging probably easier. Pthread doesn't waste time/space on the id. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 11:24:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 09:24:49 +0000 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: Probably on Win32 should just use GetCurrentThreadId(). And pthread could just use pthread_self(). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 09:18:57 +0000 Subject: [M3devel] ThreadF.MyID? The algorithms for thread id assignment vary on the platforms. In posix user threads and Win32 threads, it appears to be a number that increments for every new thread. Not sure what happens after 2 or 4 billion. On pthreads, it appears to be, well, we maintain an array of threads. So it is a number between 0 and n where n is the maximum number of threads that have "ever" been running at the same time. With presumably aggressive reuse of ids. Ok? They should all use the same? It's just that I'm looking at the Win32 code, comparing it to the pthread code: Win32: LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); Pthread doesn't have this code. I don't believe self.closure needs a lock. And per above, pthreads doesn't need protection here for id, since it is handled elsewhere. I know this was just discussed in a sense -- MyId is for debugging/diagnostics only and its value can't be depended on for much. The are obvious advantages/disadvantages to the two schemes. Win32/Posix recycle "never", so debugging probably easier. Pthread doesn't waste time/space on the id. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 13:19:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 11:19:06 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. Message-ID: Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. At least. The Enter/Leave mechanical replacement error. However even with that, the idle thread stuff seemed to cause problems. It was there forever, I realize. Also, I should have done this first, but anyway, later, I tried merging back in your changes from Feb 16. Somewhat they are moot (lock vs. LockMutex). Somewhat they are already there (WaitHeap, heapCond => condition). Somewhat they are trivial (fixing error messages). That leaves, in my analysis, the BroadcastHeap change. With this change however, /sometimes/ Juno hangs. Is this, like, somehow equivalent to the Posix hang? Is the current code the "best"? Oh darn..it hangs either way. Just not often. Could that be "similar" to the pthread problem? Any chance you can look at it? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 15:49:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 09:49:19 -0400 Subject: [M3devel] help debugging Juno..sanity check? In-Reply-To: References: Message-ID: OK, remind me again what happens with @M3nogc. That will prevent movement, and should allow you to protect state as you originally intended, without worrying about it being GC'd or moved.. From what you are saying though, it appears that even with @M3nogc the corruption is not deterministic. Which does make it tricky to nail down where it occurs. On 29 Sep 2009, at 01:39, Jay K wrote: > oops, thanks, I forgot gc is compacting. > > I don't see how to use a hardware breakpoint, > the corruption seems to always move around. > > This is an attempt to set a hardware breakpoint programmatically based > on what the runtime addresses happen to be. > > I do know these bytes are getting overwritten. > If I assert they are zero in Join, inevitably the assert fails. > > I think I might try to vary the Juno pixmaps, see if the altered > data appears in the corruption, try to prove, as it appears, > that the corruption is pixmap data. > > Thanks, > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 28 Sep 2009 10:04:55 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help debugging Juno..sanity check? > > Huh? I don't understand the point of all of this. Threads can be > moved by the GC, even if referenced from globals. The only way to > prevent a thread moving is to keep a reference to it on some thread > stack. (I still don't know what you are trying to achieve -- why > not use a hardware breakpoint in the debugger?). That's how I found > the race in ScrollerVBTClass.m3. > > On 28 Sep 2009, at 09:11, Jay K wrote: > > So, I know that ThreadWin32.T instances are prone to being > overwritten. > > So I did this: > > > T = BRANDED "Thread.T Win32-1.0" OBJECT > > pad1: ARRAY [0..16_1000] OF CHAR; > > protect: ARRAY [0..16_1] OF CHAR; > > pad2: ARRAY [0..16_1000] OF CHAR; > > And then there are two occurences of NEW(T): > > > next_self := NEW(T); > > Protect(next_self); > > > PROCEDURE CreateT (act: Activation): T = > (* LL = 0, because allocating a traced reference may cause > the allocator to start a collection which will call > "SuspendOthers" > which will try to acquire "activeMu". *) > VAR t := NEW(T, act := act); > BEGIN > > Protect(t); > > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > END Protect; > > > This should catch any writes to these fields. > > > Now, a thread can be garbage collected and reused. > And I'd want to unprotect this memory. > Or prevent the garbage collector from deciding any thread is garbage. > Second option seems easier and suffices. > > > So: > > > VAR > threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) > threadCount: INTEGER; > > > and more completely: > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > RTIO.PutInt(threadCount); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(threads)); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(t.protect)); > RTIO.PutText("\n"); > threads[threadCount] := t; > INC(threadCount); > END Protect; > > > And just in case, I emptied out the FreeSlot function. > > > But yet I get: > > 0 0xe2abe0 0x1141021 > 1 0xe2abe0 0x114b429 > 2 0xe2abe0 0x11a2311 > 3 0xe2abe0 0x11a48b1 > 4 0xe2abe0 0x11ab499 > 5 0xe2abe0 0x12e9f11 > 6 0xe2abe0 0x12d211d > 7 0xe2abe0 0x11bd691 > 8 0xe2abe0 0x11d1011 > 9 0xe2abe0 0x11d3e2d > 10 0xe2abe0 0x11d6759 > 11 0xe2abe0 0x11d8bd1 > 12 0xe2abe0 0x12089f1 > 13 0xe2abe0 0x1211455 > 14 0xe2abe0 0x12138cd > 15 0xe2abe0 0x1215ecd > 16 0xe2abe0 0x12184cd > 17 0xe2abe0 0x121bcd5 > 18 0xe2abe0 0x121e35d > Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: > 23% > (b60.9d4): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 > edi=011bd000 > eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > MSVCR90!fastzero_I+0x20: > 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds: > 0023:011bd000=0000000 > 0000000000000000000000000 > 0:003> k > ChildEBP RetAddr > 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 > 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 > 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f > 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 > 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec > 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c > 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 > 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e > 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e > 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b > 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 > 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f > 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 > 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 > 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 > 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 > 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf > 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db > 0:003> r edi > edi=011bd000 > 0:003> > > > What am I confused about? > > Why does it seem that even if I store some pointers in globals, they > are getting garbage collected and reused? > > I should debug BuildGlobalMap?? > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 15:58:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 09:58:45 -0400 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: <317FC510-CCDE-414D-AEC2-1D9FBEE67B6D@cs.purdue.edu> MyId is not a standard interface so it can do what it likes. Also, I was trying to match thread Ids to those of the OS (as reported by gdb) which recycles them. No guarantees though. I don't think they should necessarily all be the same from one thread implementation to another. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 29 Sep 2009, at 05:18, Jay K wrote: > The algorithms for thread id assignment vary on the platforms. > > In posix user threads and Win32 threads, it appears to be a number > that increments for every new thread. > Not sure what happens after 2 or 4 billion. > > On pthreads, it appears to be, well, we maintain an array of threads. > So it is a number between 0 and n where n is the maximum number of > threads that have > "ever" been running at the same time. With presumably aggressive > reuse of ids. > > Ok? > > They should all use the same? > > It's just that I'm looking at the Win32 code, comparing it to the > pthread code: > > Win32: > LockMutex(threadMu); > cl := self.closure; > self.id := nextId; INC (nextId); > UnlockMutex(threadMu); > > Pthread doesn't have this code. > I don't believe self.closure needs a lock. > And per above, pthreads doesn't need protection here for id, since > it is handled elsewhere. > > I know this was just discussed in a sense -- MyId is for debugging/ > diagnostics only and its value can't be depended on for much. > > The are obvious advantages/disadvantages to the two schemes. > Win32/Posix recycle "never", so debugging probably easier. > Pthread doesn't waste time/space on the id. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 15:59:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 09:59:15 -0400 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: On 29 Sep 2009, at 05:24, Jay K wrote: > Probably on Win32 should just use GetCurrentThreadId(). > And pthread could just use pthread_self(). Yeah, but the type of pthread_self is indeterminate. > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 29 Sep 2009 09:18:57 +0000 > Subject: [M3devel] ThreadF.MyID? > > The algorithms for thread id assignment vary on the platforms. > > In posix user threads and Win32 threads, it appears to be a number > that increments for every new thread. > Not sure what happens after 2 or 4 billion. > > On pthreads, it appears to be, well, we maintain an array of threads. > So it is a number between 0 and n where n is the maximum number of > threads that have > "ever" been running at the same time. With presumably aggressive > reuse of ids. > > Ok? > > They should all use the same? > > It's just that I'm looking at the Win32 code, comparing it to the > pthread code: > > Win32: > LockMutex(threadMu); > cl := self.closure; > self.id := nextId; INC (nextId); > UnlockMutex(threadMu); > > Pthread doesn't have this code. > I don't believe self.closure needs a lock. > And per above, pthreads doesn't need protection here for id, since > it is handled elsewhere. > > I know this was just discussed in a sense -- MyId is for debugging/ > diagnostics only and its value can't be depended on for much. > > The are obvious advantages/disadvantages to the two schemes. > Win32/Posix recycle "never", so debugging probably easier. > Pthread doesn't waste time/space on the id. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 16:01:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 10:01:16 -0400 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: None of what you say rings any bells. I don't think any of this is in the BroadcastHeap stuff. It *may* be similar to the POSIX hang that I fixed. I'll need to look more closely at the ThreadWin32 code. But you are getting corruption, not a hang, right? On 29 Sep 2009, at 07:19, Jay K wrote: > Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. > At least. The Enter/Leave mechanical replacement error. > > However even with that, the idle thread stuff seemed to cause > problems. > It was there forever, I realize. > > Also, I should have done this first, but anyway, later, I tried > merging back in your changes from Feb 16. > Somewhat they are moot (lock vs. LockMutex). > Somewhat they are already there (WaitHeap, heapCond => condition). > Somewhat they are trivial (fixing error messages). > > That leaves, in my analysis, the BroadcastHeap change. > > With this change however, /sometimes/ Juno hangs. > Is this, like, somehow equivalent to the Posix hang? > Is the current code the "best"? > > Oh darn..it hangs either way. Just not often. > Could that be "similar" to the pthread problem? > Any chance you can look at it? > > Thanks, > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:06:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:06:28 +0000 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: Fyi, I made us dependent on pthread_self fitting in an INTEGER, though it can be smaller. There are assertions that this is ok. I kind of just trolling..looking at pthreads for inspiration how to fix win32 threads..noticing the differences. We're much better now, but it still definitely hangs sometimes. :( - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ThreadF.MyID? Date: Tue, 29 Sep 2009 09:59:15 -0400 On 29 Sep 2009, at 05:24, Jay K wrote: Probably on Win32 should just use GetCurrentThreadId(). And pthread could just use pthread_self(). Yeah, but the type of pthread_self is indeterminate. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 09:18:57 +0000 Subject: [M3devel] ThreadF.MyID? The algorithms for thread id assignment vary on the platforms. In posix user threads and Win32 threads, it appears to be a number that increments for every new thread. Not sure what happens after 2 or 4 billion. On pthreads, it appears to be, well, we maintain an array of threads. So it is a number between 0 and n where n is the maximum number of threads that have "ever" been running at the same time. With presumably aggressive reuse of ids. Ok? They should all use the same? It's just that I'm looking at the Win32 code, comparing it to the pthread code: Win32: LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); Pthread doesn't have this code. I don't believe self.closure needs a lock. And per above, pthreads doesn't need protection here for id, since it is handled elsewhere. I know this was just discussed in a sense -- MyId is for debugging/diagnostics only and its value can't be depended on for much. The are obvious advantages/disadvantages to the two schemes. Win32/Posix recycle "never", so debugging probably easier. Pthread doesn't waste time/space on the id. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:12:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:12:06 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: The corruption is gone now. The combination of fixing Enter vs. Leave, and disabling/removing the idle threads solved the corruption. Neither alone seemed to work. The Enter/Leave problem was obvious, my fault. The idle threads I didn't dig into. Maybe you didn't realize waitSema was dual purpose???? Or maybe it was just the Enter/Leave? If anyone wants, certainly retest it with each change independently. Whenever I look, the Juno hang is on "untilDone" condition variable in Juno. RTIO shows it usually signals it in Misc: C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\Juno.m3(806): Thread.Signal(w.untilDone) but it doesn't seem to always, either when it hangs or sometimes when it doesn't hang. This /could/ be a bug in Juno or Trestle..except, and this isn't conclusive: I ran Juno @M3no-trestle-await-delete in a loop on Mac and it seemed to go forever. I'll leave it a few hours when I'm not home to see the screen flashing. Of course that switch merits review and/or implementation in a different place. Very useful for testing, very dubious otherwise. We need some sort of stress or fault-injection or variation-injection tests. Run threads deterministically in every combination of order, for example. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: win32 threads...now Juno sometimes hangs.. Date: Tue, 29 Sep 2009 10:01:16 -0400 None of what you say rings any bells. I don't think any of this is in the BroadcastHeap stuff. It *may* be similar to the POSIX hang that I fixed. I'll need to look more closely at the ThreadWin32 code. But you are getting corruption, not a hang, right? On 29 Sep 2009, at 07:19, Jay K wrote: Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. At least. The Enter/Leave mechanical replacement error. However even with that, the idle thread stuff seemed to cause problems. It was there forever, I realize. Also, I should have done this first, but anyway, later, I tried merging back in your changes from Feb 16. Somewhat they are moot (lock vs. LockMutex). Somewhat they are already there (WaitHeap, heapCond => condition). Somewhat they are trivial (fixing error messages). That leaves, in my analysis, the BroadcastHeap change. With this change however, /sometimes/ Juno hangs. Is this, like, somehow equivalent to the Posix hang? Is the current code the "best"? Oh darn..it hangs either way. Just not often. Could that be "similar" to the pthread problem? Any chance you can look at it? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:14:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:14:02 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: I could have easily flubbed it but the one time I tried to debug your Broadcast change, I had a deadlock due to one thread having the cm/giant lock and waiting for cs/heap, and another thread vice versa. It's pretty easy to see in the debugger. Given the presence of cm/giant on Win32 and not on pthreads, that doesn't seem too surprising. ? And/or I could easily have mismerged. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 29 Sep 2009 10:01:16 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. None of what you say rings any bells. I don't think any of this is in the BroadcastHeap stuff. It *may* be similar to the POSIX hang that I fixed. I'll need to look more closely at the ThreadWin32 code. But you are getting corruption, not a hang, right? On 29 Sep 2009, at 07:19, Jay K wrote: Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. At least. The Enter/Leave mechanical replacement error. However even with that, the idle thread stuff seemed to cause problems. It was there forever, I realize. Also, I should have done this first, but anyway, later, I tried merging back in your changes from Feb 16. Somewhat they are moot (lock vs. LockMutex). Somewhat they are already there (WaitHeap, heapCond => condition). Somewhat they are trivial (fixing error messages). That leaves, in my analysis, the BroadcastHeap change. With this change however, /sometimes/ Juno hangs. Is this, like, somehow equivalent to the Posix hang? Is the current code the "best"? Oh darn..it hangs either way. Just not often. Could that be "similar" to the pthread problem? Any chance you can look at it? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:16:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:16:11 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:23:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:23:07 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: ps: while I consider the whole stacksize thing broken anyway, notice that using an idle thread (which you had no choice about) got you an indeterminate stack size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:16:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:48:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:48:24 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: Tony..this semaphore with a maximum value of 1, that is a strange thing, isn't it? It could just be an event, right? I tried that..it took 50 runs to hang Juno.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] win32 threads...now Juno sometimes hangs.. Date: Tue, 29 Sep 2009 14:23:07 +0000 ps: while I consider the whole stacksize thing broken anyway, notice that using an idle thread (which you had no choice about) got you an indeterminate stack size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:16:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 17:09:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 15:09:10 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: ah, well now I've got 68 runs with an event amd /slight/ expansion of the giant lock -- in InnerWait I .release before Leave(giant). Given that release almost immediates enter giant anyway, that doesn't seem a bad move. It didn't hang at 68, it did: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x207fef8 0xfb62a5 Redisplay + 0x3ae in ..\src\vbt\VBTRep.m3 0x207ff24 0xfb5e34 UncoverRedisplay + 0xdd in ..\src\vbt\VBTRep.m3 0x207ff4c 0xfb5ec5 RdApply + 0x8c in ..\src\vbt\VBTRep.m3 0x207ff8c 0x5eacb9 RunThread + 0x184 in ..\src\thread\WIN32\ThreadWin32.m3 0x207ffb4 0x5eaaea ThreadBase + 0x33 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... C:\dev2\cm3.2\m3-libs\m3core>echo 69 && \cm3\bin\Juno.exe @M3no-trestle-await- delete 69 C:\dev2\cm3.2\m3-libs\m3core>echo 70 && \cm3\bin\Juno.exe @M3no-trestle-await- delete 70 I'll try again having put back the semaphore.. I rather suspect I have it fixed though and have uncovered some other problem. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:48:24 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. Tony..this semaphore with a maximum value of 1, that is a strange thing, isn't it? It could just be an event, right? I tried that..it took 50 runs to hang Juno.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] win32 threads...now Juno sometimes hangs.. Date: Tue, 29 Sep 2009 14:23:07 +0000 ps: while I consider the whole stacksize thing broken anyway, notice that using an idle thread (which you had no choice about) got you an indeterminate stack size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:16:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 17:25:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 11:25:06 -0400 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: <0951DB0C-7A75-403E-AB56-90AAE1A22C83@cs.purdue.edu> Ah, yes, interesting. On 29 Sep 2009, at 10:23, Jay K wrote: > ps: while I consider the whole stacksize thing broken anyway, notice > that using an idle thread (which you had no choice about) got you an > indeterminate stack size. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 29 Sep 2009 14:16:11 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. > > small email truncation: > > >> We need some sort of stress or fault-injection or variation- > injection tests. > >> Run threads deterministically in every combination of order, for > example. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 17:25:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 11:25:58 -0400 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: Hmm. Possibly. I'll look more closely. On 29 Sep 2009, at 10:14, Jay K wrote: > I could have easily flubbed it but the one time I tried to debug > your Broadcast change, I had a deadlock due to one thread having the > cm/giant lock and waiting for cs/heap, and another thread vice > versa. It's pretty easy to see in the debugger. > Given the presence of cm/giant on Win32 and not on pthreads, that > doesn't seem too surprising. > ? > And/or I could easily have mismerged. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 29 Sep 2009 10:01:16 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. > > None of what you say rings any bells. I don't think any of this is > in the BroadcastHeap stuff. It *may* be similar to the POSIX hang > that I fixed. I'll need to look more closely at the ThreadWin32 > code. But you are getting corruption, not a hang, right? > > On 29 Sep 2009, at 07:19, Jay K wrote: > > Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. > At least. The Enter/Leave mechanical replacement error. > > However even with that, the idle thread stuff seemed to cause > problems. > It was there forever, I realize. > > Also, I should have done this first, but anyway, later, I tried > merging back in your changes from Feb 16. > Somewhat they are moot (lock vs. LockMutex). > Somewhat they are already there (WaitHeap, heapCond => condition). > Somewhat they are trivial (fixing error messages). > > That leaves, in my analysis, the BroadcastHeap change. > > With this change however, /sometimes/ Juno hangs. > Is this, like, somehow equivalent to the Posix hang? > Is the current code the "best"? > > Oh darn..it hangs either way. Just not often. > Could that be "similar" to the pthread problem? > Any chance you can look at it? > > Thanks, > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 17:43:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 15:43:26 +0000 Subject: [M3devel] array out of bounds in VBTRep.Redisplay? Message-ID: Anyone ever seen: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1fffef8 0xfb62a5 Redisplay + 0x3ae in ..\src\vbt\VBTRep.m3 0x1ffff24 0xfb5e34 UncoverRedisplay + 0xdd in ..\src\vbt\VBTRep.m3 0x1ffff4c 0xfb5ec5 RdApply + 0x8c in ..\src\vbt\VBTRep.m3 0x1ffff8c 0x5eacd7 RunThread + 0x184 in ..\src\thread\WIN32\ThreadWin32.m3 0x1ffffb4 0x5eab08 ThreadBase + 0x33 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... line is apparently: v[dcount[list[i].depth - 1].n] := list[i].v; This is admittedly Juno on Win32. Maybe someone can study the function for bugs? I'll leave Juno looping for hours on a non-Win32 today or so. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 18:27:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 12:27:09 -0400 Subject: [M3devel] array out of bounds in VBTRep.Redisplay? In-Reply-To: References: Message-ID: <2CF5EA91-AD04-43C0-8632-CB27E4CB429F@cs.purdue.edu> Never seen it. Probably a race. I think Windows threads must still be broken somehow. On 29 Sep 2009, at 11:43, Jay K wrote: > Anyone ever seen: > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\src\vbt\VBTRep.m3", line 644 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1fffef8 0xfb62a5 Redisplay + 0x3ae in ..\src\vbt\VBTRep.m3 > 0x1ffff24 0xfb5e34 UncoverRedisplay + 0xdd in ..\src\vbt\VBTRep.m3 > 0x1ffff4c 0xfb5ec5 RdApply + 0x8c in ..\src\vbt\VBTRep.m3 > 0x1ffff8c 0x5eacd7 RunThread + 0x184 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x1ffffb4 0x5eab08 ThreadBase + 0x33 in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > > line is apparently: > v[dcount[list[i].depth - 1].n] := list[i].v; > > > This is admittedly Juno on Win32. > Maybe someone can study the function for bugs? > I'll leave Juno looping for hours on a non-Win32 today or so. > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 19:54:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 13:54:48 -0400 Subject: [M3devel] Win32 threads Message-ID: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> I believe that the hangs we are seeing are because of the race present in AlertWait, which permit a thread to miss seeing an alert before waiting on the condition. We want the thread only to wait if there has been no alert. Unfortunately, the alert is only protected by the global mutex, which must be release before waiting. Currently, we release the mutex, then wait, with the resulting race. This requires a more complicated handshake than currently implemented. Perhaps using SignalObjectAndWait instead as well as a Win32 mutex on each thread. Similarly to ThreadPThread.m3. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Tue Sep 29 20:13:04 2009 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 29 Sep 2009 20:13:04 +0200 Subject: [M3devel] Mailing list archive Message-ID: <4AC24E30.5030304@gmx.de> Hi, I would like to fix a bug I found in 2005, but the bug's details are not in trac, but only in a mailing list archive, which isn't available anymore. https://projects.elego.de/cm3/ticket/640 Can anyone provide me with the details? Roland From jay.krell at cornell.edu Tue Sep 29 22:12:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 20:12:00 +0000 Subject: [M3devel] Win32 threads In-Reply-To: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> References: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> Message-ID: SignalObjectAndWait is widely mentioned as important to implementing condition variables on Win32, however it is documented as not being atomic. Search the web: http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx "Note that the "signal" and "wait" are not guaranteed to be performed as an atomic operation. Threads executing on other processors can observe the signaled state of the first object before the thread calling SignalObjectAndWait begins its wait on the second object." So it isn't useful, right? Thanks, - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 13:54:48 -0400 Subject: [M3devel] Win32 threads I believe that the hangs we are seeing are because of the race present in AlertWait, which permit a thread to miss seeing an alert before waiting on the condition. We want the thread only to wait if there has been no alert. Unfortunately, the alert is only protected by the global mutex, which must be release before waiting. Currently, we release the mutex, then wait, with the resulting race. This requires a more complicated handshake than currently implemented. Perhaps using SignalObjectAndWait instead as well as a Win32 mutex on each thread. Similarly to ThreadPThread.m3. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 22:26:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 20:26:07 +0000 Subject: [M3devel] Win32 threads In-Reply-To: References: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> Message-ID: 1) Would it be useful to use native alertability? 2) Or to make alerted an event, and use WaitForMultipleObjects? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Tue, 29 Sep 2009 20:12:00 +0000 Subject: Re: [M3devel] Win32 threads SignalObjectAndWait is widely mentioned as important to implementing condition variables on Win32, however it is documented as not being atomic. Search the web: http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx "Note that the "signal" and "wait" are not guaranteed to be performed as an atomic operation. Threads executing on other processors can observe the signaled state of the first object before the thread calling SignalObjectAndWait begins its wait on the second object." So it isn't useful, right? Thanks, - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 13:54:48 -0400 Subject: [M3devel] Win32 threads I believe that the hangs we are seeing are because of the race present in AlertWait, which permit a thread to miss seeing an alert before waiting on the condition. We want the thread only to wait if there has been no alert. Unfortunately, the alert is only protected by the global mutex, which must be release before waiting. Currently, we release the mutex, then wait, with the resulting race. This requires a more complicated handshake than currently implemented. Perhaps using SignalObjectAndWait instead as well as a Win32 mutex on each thread. Similarly to ThreadPThread.m3. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 29 23:26:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Sep 2009 23:26:59 +0200 Subject: [M3devel] Mailing list archive In-Reply-To: <4AC24E30.5030304@gmx.de> References: <4AC24E30.5030304@gmx.de> Message-ID: <20090929232659.xvsqww0leccswck0@mail.elegosoft.com> Quoting Roland Illig : > Hi, > > I would like to fix a bug I found in 2005, but the bug's details are > not in trac, but only in a mailing list archive, which isn't available > anymore. > > https://projects.elego.de/cm3/ticket/640 > > Can anyone provide me with the details? Here is a copy of your old mail: X-Authenticated: #530625 Date: Tue, 11 Oct 2005 10:57:29 +0200 From: Roland Illig To: m3devel at elegosoft.com Subject: quake bug: local variable disappears X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavis (elego Software Solutions GmbH) X-List-Check-m3devel-pint-elegosoft-com: approved X-Virus-Scanned: by amavis (elego Software Solutions GmbH) X-Copy: forwarded from wagner at elego.de X-Virus-Scanned: by amavis (elego Software Solutions GmbH) X-Keywords: X-UID: 12885 proc first_of(arr) is foreach e in arr if not empty(e) return e end end return "cc" end proc compile_c(source, object, includes, o_flag, d_flag) is local cmd = [] local cc = first_of([$CC, "cc"]) cmd += [cc] return try_exec(cmd) end c_source("main") c_program("test") Critical Mass Modula-3 version d5.2.7 last updated: 2004-10-31 --- building in NetBSD2_i386 --- new source -> compiling main.c "/home/roland/proj/m3/c-test/src/m3makefile", line 14: quake runtime error: undefined variable: cmd The bug only shows because of: - the order of the two "local" statements in compile_c - a procedure is called - a "foreach" loop appears in the procedure - the "return" from inside the "foreach" loop is executed Roland -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Sep 29 23:31:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 17:31:36 -0400 Subject: [M3devel] Win32 threads In-Reply-To: References: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> Message-ID: If the documentation is true then it is essentially useless in general. Typical MS. On the other hand, several MS sources on the Web claim that it *is* atomic. Perhaps they should figure out what they really mean. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 29 Sep 2009, at 16:12, Jay K wrote: > SignalObjectAndWait is widely mentioned as important to implementing > condition variables on Win32, however it is documented as not being > atomic. > Search the web: > http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx > > "Note that the "signal" and "wait" are not guaranteed to be > performed as an atomic operation. Threads executing on other > processors can observe the signaled state of the first object before > the thread calling SignalObjectAndWait begins its wait on the second > object." > > So it isn't useful, right? > > Thanks, > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Tue, 29 Sep 2009 13:54:48 -0400 > Subject: [M3devel] Win32 threads > > I believe that the hangs we are seeing are because of the race > present in AlertWait, which permit a thread to miss seeing an alert > before waiting on the condition. We want the thread only to wait if > there has been no alert. Unfortunately, the alert is only protected > by the global mutex, which must be release before waiting. > Currently, we release the mutex, then wait, with the resulting > race. This requires a more complicated handshake than currently > implemented. Perhaps using SignalObjectAndWait instead as well as a > Win32 mutex on each thread. Similarly to ThreadPThread.m3. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 1 01:23:26 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 01:23:26 +0200 Subject: [M3devel] Pickling problem from 64 to 32 bit platforms In-Reply-To: <4A9C429B.9070308@cox.net> References: <20090831191643.7djdygpgg08wksko@mail.elegosoft.com> <4A9C429B.9070308@cox.net> Message-ID: <20090901012326.ey14b7i9bc484008@mail.elegosoft.com> Quoting "Rodney M. Bates" : > Some initial observations: > > I don't understand the circumstances where this is happening. > "pickles from 64 to 32 bit" sounds to me like the pickle was written > on a 64-bit machine and read on a 32-bit machine. But the backtrace > seems to be of a run on a 64-bit machine, in part because of the > filename in the outermost frame: > > #38 0x0000000000408409 in _start () at ../sysdeps/x86_64/elf/start.S:113 > ^^^^^^ > > and in part, because all the hexadecimal addresses are 64-bit values. > > This example seems to be using version 1 of pickles: #5 > 0x000000000045ac12 in ReadRef (reader=16_00000000025b2018) at > ../src/pickle/ver1/Pickle.m3:529 > > ^^^^ > > Without some vetting, I can't say for sure, but I'm not sure this > version ever did all the > cross-target stuff completely. Did this case work earlier under the > same circumstances? > > The len parameter to String8.Hash has surely gone bad. Could there > something wrong > with operations on CARDINAL on 64-bit machines? What is the symptom > of the failure? What needs to be run to reproduce it? The tickets says: "Testing the network objects from 64 bit client to 32 bit target using Linux Debian Lenny. The perf test fails on any of the oc oq r rc object call tests." So I assume the test to be run is cm3/m3-comm/netobj/tests/perf; the client is a 64 bit machine, the server is a 32 bit machine, and we see a backtrace from the client. peter.mckinna at gmail.com who wrote the ticket may be able to provide more details. I cannot easily test this myself as I don't have the required machines close together anywhere. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Sep 1 11:45:33 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 11:45:33 +0200 Subject: [M3devel] last RC3 tasks Message-ID: <20090901114533.f2wgu748hwkg4gok@mail.elegosoft.com> Jay, I have moved the current version on the release branch from RC3 to pre-RC4. If you build any more packages for RC3, you have to explicitly set the version via the DS variable (originally datestamp for snapshots). I'd like to close the RC3 tasks in trac and retarget everything to the final release or RC4. However, there are some open issues: o I think we should offer packages for I386_DARWIN. Could you provide them? o There are some packages named pre-RC3 in the download area from you. These should probably be removed? o What's the status of the MSI installer for Windows? Automation can wait until RC4, but can we have a package on birch? o AMD64_FREEBSD looks rather incomplete and old. Have you run any tests on it? Should it be removed? When the packages are OK, I'd like to post a public announcement on comp.lang.modula3 and www.modula3.org. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Sep 1 13:02:03 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 13:02:03 +0200 Subject: [M3devel] last RC3 tasks In-Reply-To: <20090901114533.f2wgu748hwkg4gok@mail.elegosoft.com> References: <20090901114533.f2wgu748hwkg4gok@mail.elegosoft.com> Message-ID: <20090901130203.fhpolgatc4ks488g@mail.elegosoft.com> Quoting Olaf Wagner : > Jay, > > I have moved the current version on the release branch from RC3 to pre-RC4. > If you build any more packages for RC3, you have to explicitly set the > version via the DS variable (originally datestamp for snapshots). I made a mistake in the script: DS cannot be overwritten from the environment. Will fix tonight if nobody is faster. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Sep 1 14:56:28 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 01 Sep 2009 14:56:28 +0200 Subject: [M3devel] p007 not terminating on NT386 Message-ID: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> It looks as if m3test p007 does not terminate any more on NT386. This used to work. I just found this --- p007 --- a whole bunch of threads - does the memory grow ? cd ..\src\p0\p007 && cm3 -silent -DM3TESTS >NT386\stdout.build.raw 2>NT386\stderr.build.raw running for more than 5 hours. The last successful run was http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Sep 1 15:51:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 09:51:23 -0400 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> Message-ID: <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> These thread problems are relatively new (similar to Jay's problems with AutoFlushWr...). Something quite bad must have happened recently to cause them. I took a quick look at ThreadPThread.m3 but didn't notice anything obviously wrong. Something else perhaps? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 1 Sep 2009, at 08:56, Olaf Wagner wrote: > It looks as if m3test p007 does not terminate any more on NT386. > This used to work. I just found this > > --- p007 --- a whole bunch of threads - does the memory grow ? > > cd ..\src\p0\p007 && cm3 -silent -DM3TESTS >NT386\stdout.build.raw > 2>NT386\stderr.build.raw > > running for more than 5 hours. > > The last successful run was > http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/ > . > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 1 16:13:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Sep 2009 14:13:06 +0000 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> Message-ID: AutoFlushWr: on non-I386_OPENBSD, it passed in the test runs, but generally hit assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe others. on I386_OPENBSD: it hangs The code was a bit hard for me to verify the correctness of. I replaced it with an easy to understand version and the non-I386_OPENBSD problems went away. The I386_OPENBSD hang remains. In particular, AutoFlushWr layers a Wr over a Wr, but if the underlying Wr is buffered, it strives to not add an additional buffering layer. If the underlying Wr is not buffered, it does add buffering. All Wrs have a few public fields to implement buffering. AutoFlushWr copies these fields back and forth. I think it was a) optimizing which fields to copy based on knowing which fields the toplevel Wr modified when b) I think it was doing some computation them that it should not have, instead of just copying them. I just have it basically copy all the fields all the time. There are just a few. Agreed, the I386_OPENBSD hang might be related. I think I might have to try out very old versions, like I'm doing (slowly!) for the formsedit crash. Maybe not, since the I386_OPENBSD hang is easy to reproduce and only involves two threads -- not too complicated. I think p007 also hangs on Cygwin, but it always has. I tried debugging it but Cygwin seemed like a mess. Granted, it hung with Cygwin whether or not I used pthreads or NT threads. Recentness isn't particularly clear I think, since I don't think these platforms have ever had good test coverage. But I did think regular NT386 was ok here. Later, - Jay ________________________________ > From: hosking at cs.purdue.edu > To: wagner at elegosoft.com > Date: Tue, 1 Sep 2009 09:51:23 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] p007 not terminating on NT386 > > These thread problems are relatively new (similar to Jay's problems with AutoFlushWr...). Something quite bad must have happened recently to cause them. I took a quick look at ThreadPThread.m3 but didn't notice anything obviously wrong. Something else perhaps? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 1 Sep 2009, at 08:56, Olaf Wagner wrote: > > It looks as if m3test p007 does not terminate any more on NT386. > This used to work. I just found this > > --- p007 --- a whole bunch of threads - does the memory grow ? > > cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw 2>NT386\stderr.build.raw > > running for more than 5 hours. > > The last successful run was > http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > From hosking at cs.purdue.edu Tue Sep 1 16:54:26 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 10:54:26 -0400 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> Message-ID: <3B500B6D-168E-4BA7-819D-43E6C9D6BB03@cs.purdue.edu> On 1 Sep 2009, at 10:13, Jay K wrote: > > AutoFlushWr: > on non-I386_OPENBSD, it passed in the test runs, but generally hit > assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe > others. > on I386_OPENBSD: it hangs > > > The code was a bit hard for me to verify the correctness of. I > replaced it with an easy to understand version and the non- > I386_OPENBSD problems went away. The I386_OPENBSD hang remains. > > > In particular, AutoFlushWr layers a Wr over a Wr, but if the > underlying Wr is buffered, it strives to not add an additional > buffering layer. If the underlying Wr is not buffered, it does add > buffering. All Wrs have a few public fields to implement buffering. > AutoFlushWr copies these fields back and forth. I think it was a) > optimizing which fields to copy based on knowing which fields the > toplevel Wr modified when b) I think it was doing some computation > them that it should not have, instead of just copying them. I just > have it basically copy all the fields all the time. There are just a > few. OK, sounds like we all need to take a closer look at this code and satisfy ourselves that it is now correct. > Agreed, the I386_OPENBSD hang might be related. > I think I might have to try out very old versions, like I'm doing > (slowly!) for the formsedit crash. > Maybe not, since the I386_OPENBSD hang is easy to reproduce and only > involves two threads -- not too complicated. This is particularly weird, since it is clear that the main thread is trying to stop the other thread, but the other thread is not responding. I wonder if signal delivery to waiting threads is broken on OpenBSD? > I think p007 also hangs on Cygwin, but it always has. I tried > debugging it but Cygwin seemed like a mess. Granted, it hung with > Cygwin whether or not I used pthreads or NT threads. I have a feeling p007 is just buggy in itself -- it looks like there is a serious race in there. So, in this case I think the test is broken, not the platform. I'll try to clean it up. > Recentness isn't particularly clear I think, since I don't think > these platforms have ever had good test coverage. But I did think > regular NT386 was ok here. > > > Later, > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: wagner at elegosoft.com >> Date: Tue, 1 Sep 2009 09:51:23 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] p007 not terminating on NT386 >> >> These thread problems are relatively new (similar to Jay's problems >> with AutoFlushWr...). Something quite bad must have happened >> recently to cause them. I took a quick look at ThreadPThread.m3 but >> didn't notice anything obviously wrong. Something else perhaps? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 1 Sep 2009, at 08:56, Olaf Wagner wrote: >> >> It looks as if m3test p007 does not terminate any more on NT386. >> This used to work. I just found this >> >> --- p007 --- a whole bunch of threads - does the memory grow ? >> >> cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw >> 2>NT386\stderr.build.raw >> >> running for more than 5 hours. >> >> The last successful run was >> http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/ >> . >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >> 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >> DE163214194 >> >> From jay.krell at cornell.edu Tue Sep 1 19:47:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Sep 2009 17:47:13 +0000 Subject: [M3devel] p007 not terminating on NT386 In-Reply-To: <3B500B6D-168E-4BA7-819D-43E6C9D6BB03@cs.purdue.edu> References: <20090901145628.v4juo7npc4ggsgwc@mail.elegosoft.com> <4ED037C8-9F4B-48CC-B294-22FB909BF85D@cs.purdue.edu> <3B500B6D-168E-4BA7-819D-43E6C9D6BB03@cs.purdue.edu> Message-ID: > take a closer look Sure. I'm suspicious of the entire approach actually. I understand that layering/pipelining Rd/Wr can be very nice, but I think there are better approaches here. 1) Don't layer a Wr over a Wr. Just have a worker thread and a table of weakrefs to Wr. Understandable downside to this approach is without an interception point, it doesn't know if a Wr has any data worth flushing, it would needlessly flush idle Wrs. or 2) Mark the upper Wr as not buffered -- not clear to me if adding buffering to unbuffered Wr is a goal. I'm not sure unbuffered Wr even makes sense, I have to reread it.. Underlying point is that, let's say I have a "counting Wr"..you know a Wr of very little but non-zero semantic. It seems too difficult imho to layer in a Wr that does very little. But again, I should reeread. Thank you for fixing the test case. I'll have to try Cygwin again here. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 1 Sep 2009 10:54:26 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] p007 not terminating on NT386 > > On 1 Sep 2009, at 10:13, Jay K wrote: > >> >> AutoFlushWr: >> on non-I386_OPENBSD, it passed in the test runs, but generally hit >> assertion failures in manual runs -- on LINUXLIBC6, NT386, and maybe >> others. >> on I386_OPENBSD: it hangs >> >> >> The code was a bit hard for me to verify the correctness of. I >> replaced it with an easy to understand version and the non- >> I386_OPENBSD problems went away. The I386_OPENBSD hang remains. >> >> >> In particular, AutoFlushWr layers a Wr over a Wr, but if the >> underlying Wr is buffered, it strives to not add an additional >> buffering layer. If the underlying Wr is not buffered, it does add >> buffering. All Wrs have a few public fields to implement buffering. >> AutoFlushWr copies these fields back and forth. I think it was a) >> optimizing which fields to copy based on knowing which fields the >> toplevel Wr modified when b) I think it was doing some computation >> them that it should not have, instead of just copying them. I just >> have it basically copy all the fields all the time. There are just a >> few. > > OK, sounds like we all need to take a closer look at this code and > satisfy ourselves that it is now correct. > >> Agreed, the I386_OPENBSD hang might be related. >> I think I might have to try out very old versions, like I'm doing >> (slowly!) for the formsedit crash. >> Maybe not, since the I386_OPENBSD hang is easy to reproduce and only >> involves two threads -- not too complicated. > > This is particularly weird, since it is clear that the main thread is > trying to stop the other thread, but the other thread is not > responding. I wonder if signal delivery to waiting threads is broken > on OpenBSD? > >> I think p007 also hangs on Cygwin, but it always has. I tried >> debugging it but Cygwin seemed like a mess. Granted, it hung with >> Cygwin whether or not I used pthreads or NT threads. > > I have a feeling p007 is just buggy in itself -- it looks like there > is a serious race in there. So, in this case I think the test is > broken, not the platform. I'll try to clean it up. > > >> Recentness isn't particularly clear I think, since I don't think >> these platforms have ever had good test coverage. But I did think >> regular NT386 was ok here. >> >> >> Later, >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: wagner at elegosoft.com >>> Date: Tue, 1 Sep 2009 09:51:23 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] p007 not terminating on NT386 >>> >>> These thread problems are relatively new (similar to Jay's problems >>> with AutoFlushWr...). Something quite bad must have happened >>> recently to cause them. I took a quick look at ThreadPThread.m3 but >>> didn't notice anything obviously wrong. Something else perhaps? >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 1 Sep 2009, at 08:56, Olaf Wagner wrote: >>> >>> It looks as if m3test p007 does not terminate any more on NT386. >>> This used to work. I just found this >>> >>> --- p007 --- a whole bunch of threads - does the memory grow ? >>> >>> cd ..\src\p0\p007 && cm3 -silent -DM3TESTS>NT386\stdout.build.raw >>> 2>NT386\stderr.build.raw >>> >>> running for more than 5 hours. >>> >>> The last successful run was >>> http://hudson.modula3.com:8080/view/NT386/job/cm3-test-m3tests-NT386/212/ >>> . >>> >>> Olaf >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 >>> 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >>> > From rcoleburn at scires.com Wed Sep 2 02:09:25 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Sep 2009 20:09:25 -0400 Subject: [M3devel] report on Windows XP builds/tests Message-ID: <4A9D7F7B.1E75.00D7.1@scires.com> Hi, I am back from vacation. I've updated my sandbox on WindowsXP to be current with the CVS head. I tried first to run Jay's "upgrade.py", but got the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py using c:\cm3\bin\cm3.exe PATH=c:\cm3\bin;%PATH% set CM3_TARGET=NT386 set CM3_INSTALL=c:\cm3 set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 set CM3_ROOT=C:/cm3/Sandbox/cm3 ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) C:\cm3\Sandbox\cm3\scripts\python> Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: C:\cm3\bin>mentor *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 ......... ......... ... more frames ... C:\cm3\bin>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 2284 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... C:\cm3\bin> Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. I will try to run some tests on Vista platform tomorrow. Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. Let me know how I can best assist with the release effort. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 2 02:29:59 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 20:29:59 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: <4A9D7F7B.1E75.00D7.1@scires.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> Message-ID: <0FA9C0AE-2B85-4574-A90F-1C1A81DE98BB@cs.purdue.edu> Possibly something very broken in mutexes? On 1 Sep 2009, at 20:09, Randy Coleburn wrote: > Hi, I am back from vacation. > > I've updated my sandbox on WindowsXP to be current with the CVS head. > > I tried first to run Jay's "upgrade.py", but got the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > using c:\cm3\bin\cm3.exe > PATH=c:\cm3\bin;%PATH% > set CM3_TARGET=NT386 > set CM3_INSTALL=c:\cm3 > set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- > install\NT386 > set CM3_ROOT=C:/cm3/Sandbox/cm3 > ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: > \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files > \Microsoft Platform SDK for Windows Server 2003 R2\Include) > C:\cm3\Sandbox\cm3\scripts\python> > > Next I tried my upgrade script and was successful. Then I used my > "do-cm3.cmd" script to rebuild all packages and was successful, > except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib > \test". > > In catching up on my email, I noticed Olaf had asked about mentor > and juno on Windows, so I tried running these. Juno starts up and > puts up a window, but quickly crashes. mentor crashes before any > window comes up and I also get a firewall request from Windows > asking whether to block the program--I suspect it is trying to > access the network, hence the firewall request. Here are the > runtime error reports: > > C:\cm3\bin>mentor > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime > \NT386\RTSignal.m3 > 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 > 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 > 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 > 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > > C:\cm3\bin>juno > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 2284 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime > \common\RTCollector.m3 > 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 > 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 > 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 > 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 > 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 > 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 > 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 > 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 > 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > C:\cm3\bin> > > Juno crashes on an ASSERT in the collector, while mentor seems to be > trying to lock a mutex that isn't properly initialized. I have not > looked at the source code to try and debug. Let me know if you want > me to pursue further. > > I've rebuilt some of my own programs and run some very basic tests. > So far, no problems detected. > > I will try to run some tests on Vista platform tomorrow. > > Maybe it would be prudent for me to compile and run some of the > tests ya'll have been implementing. I think the scripts for these > aren't native Windows, but if you can point me to some of these, > I'll try to translate for use on Windows. > > Let me know how I can best assist with the release effort. > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 2 03:33:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 01:33:41 +0000 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: <4A9D7F7B.1E75.00D7.1@scires.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> Message-ID: Is the message about errno.h correct? caltech-parser..hm.. you are up to date? I thought I had either fixed it, or filtered it out. Mutex/mentor I'll have to look at. - Jay Date: Tue, 1 Sep 2009 20:09:25 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] report on Windows XP builds/tests Hi, I am back from vacation. I've updated my sandbox on WindowsXP to be current with the CVS head. I tried first to run Jay's "upgrade.py", but got the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py using c:\cm3\bin\cm3.exe PATH=c:\cm3\bin;%PATH% set CM3_TARGET=NT386 set CM3_INSTALL=c:\cm3 set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 set CM3_ROOT=C:/cm3/Sandbox/cm3 ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) C:\cm3\Sandbox\cm3\scripts\python> Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: C:\cm3\bin>mentor *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 ......... ......... ... more frames ... C:\cm3\bin>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 2284 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... C:\cm3\bin> Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. I will try to run some tests on Vista platform tomorrow. Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. Let me know how I can best assist with the release effort. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Wed Sep 2 03:56:02 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Tue, 01 Sep 2009 20:56:02 -0500 Subject: [M3devel] Mentor error on LINUXLIBC6 Message-ID: <4A9DD0B2.4010505@esoteriq.org> I installed the RC3 core fine, worked well, but I was adding addition packages and tried running mentor. I get: mentor: error while loading shared library libobliqlibanim.so.5: cannot open shared object file: No such file or directory. I'm guessing this is because I didn't install the Obliq package...but why should I have to? From mbishop at esoteriq.org Wed Sep 2 03:58:06 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Tue, 01 Sep 2009 20:58:06 -0500 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <4A9DD0B2.4010505@esoteriq.org> References: <4A9DD0B2.4010505@esoteriq.org> Message-ID: <4A9DD12E.2080903@esoteriq.org> Martin Bishop wrote: > I installed the RC3 core fine, worked well, but I was adding addition > packages and tried running mentor. I get: > > mentor: error while loading shared library libobliqlibanim.so.5: > cannot open shared object file: No such file or directory. > > I'm guessing this is because I didn't install the Obliq package...but > why should I have to? > Oh, and another issue (might just be me?) when I use the install scripts in each package, they complain that "cm3" is not found. If it change it to /usr/local/cm3/bin/cm3, it works just fine. From hosking at cs.purdue.edu Wed Sep 2 04:06:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 22:06:07 -0400 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <4A9DD0B2.4010505@esoteriq.org> References: <4A9DD0B2.4010505@esoteriq.org> Message-ID: <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> Because mentor depends on obliq? If you didn't install the obliq package then it can't dynamically load the shard library. On 1 Sep 2009, at 21:56, Martin Bishop wrote: > I installed the RC3 core fine, worked well, but I was adding > addition packages and tried running mentor. I get: > > mentor: error while loading shared library libobliqlibanim.so.5: > cannot open shared object file: No such file or directory. > > I'm guessing this is because I didn't install the Obliq > package...but why should I have to? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Wed Sep 2 04:53:10 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 01 Sep 2009 22:53:10 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> Message-ID: <4A9DA5DB.1E75.00D7.1@scires.com> I tried upgrade.py again, and it seemed to work this time. I think I may have forgotten to run vcvars to setup the Visual C++ command line on my prior attempt. Sorry. Here is the compiler output for the "caltech-parser\parserlib\parserlib\test" build: --- processing package "caltech-parser\parserlib\parserlib\test" --- --- building in NT386 --- LIB_INSTALL is C:\cm3\lib ignoring ..\src\m3overrides C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 The system cannot find the path specified. "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 --procedure-- -line- -file--- exec -- _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl token 73 C:\cm3\pkg\parserlib\src\parser.tmpl include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args Fatal Error: package build failed I tried running juno and mentor again. I get different results each run. Interestingly, sometimes mentor didn't crash, instead giving me an error message about not having my HOME environment var set. I tried later to set this, but mentor still crashes. Once when I ran juno it complained that it tried to join a thread twice. Sounds like something is broken in the threading or GC, or the program is coded wrongly somehow. See below for some sample runs of mentor and juno: C:\cm3\Sandbox\cm3\scripts\win>mentor *** *** runtime error: *** Exception "FormsVBT.Error" not in RAISES list *** file "..\src\FormsVBT.m3", line 73 *** *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "..\src\runtime\common\RTType.m3", line 71 *** C:\cm3\Sandbox\cm3\scripts\win>mentor Error: the HOME environment variable is undefined. Please set it to the path of your home directory and try again. C:\cm3\Sandbox\cm3\scripts\win>mentor Error: the HOME environment variable is undefined. Please set it to the path of your home directory and try again. C:\cm3\Sandbox\cm3\scripts\win>mentor *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread\WIN32\ThreadWin32.m3 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 0x12fe88 0x4e32da RegisterView + 0x30 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 Here is another run of Juno. This one dies on a different line number in same module. C:\cm3\Sandbox\cm3\scripts\win>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 1087 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common\RTCollector.m3 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime\common\RTCollector.m3 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src\JunoCompile.m3 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src\JunoCompile.m3 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src\JunoCompile.m3 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src\JunoCompile.m3 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src\JunoCompile.m3 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src\JunoCompile.m3 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src\JunoCompile.m3 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... Regards, Randy Coleburn >>> Jay K 9/1/2009 9:33 PM >>> Is the message about errno.h correct? caltech-parser..hm.. you are up to date? I thought I had either fixed it, or filtered it out. Mutex/mentor I'll have to look at. - Jay Date: Tue, 1 Sep 2009 20:09:25 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] report on Windows XP builds/tests Hi, I am back from vacation. I've updated my sandbox on WindowsXP to be current with the CVS head. I tried first to run Jay's "upgrade.py", but got the following error: C:\cm3\Sandbox\cm3\scripts\python>upgrade.py using c:\cm3\bin\cm3.exe PATH=c:\cm3\bin;%PATH% set CM3_TARGET=NT386 set CM3_INSTALL=c:\cm3 set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 set CM3_ROOT=C:/cm3/Sandbox/cm3 ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) C:\cm3\Sandbox\cm3\scripts\python> Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: C:\cm3\bin>mentor *** *** runtime error: *** Attempt to reference an illegal memory location. *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 ......... ......... ... more frames ... C:\cm3\bin>juno *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 2284 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 ......... ......... ... more frames ... C:\cm3\bin> Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. I will try to run some tests on Vista platform tomorrow. Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. Let me know how I can best assist with the release effort. Regards, Randy Coleburn CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 2 05:52:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 1 Sep 2009 23:52:39 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: <4A9DA5DB.1E75.00D7.1@scires.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: mentor (and probably other GUI apps) lock up in ways I have not seen before (it has been a long time since I tried running it, but it always used to work for me without problems about the time that I was bedding down the native threads code so logs there might give the timeframe). I suspect something is quite broken, but don't know when the brokenness got introduced. Here is a backtrace for all threads: Thread 20 (process 84568 thread 0x4f07): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:669 #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:686 #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../ src/xvbt/XClientF.m3:105 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 19 (process 84568 thread 0x4e0b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../ src/Zeus.m3:328 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 18 (process 84568 thread 0x5c0b): #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:189 #1 0x0101ee7a in ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:324 #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') at ../ src/thread/PTHREAD/ThreadPThread.m3:670 #3 0x0101f77a in Thread__AlertPause (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ ThreadPThread.m3:700 #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../ src/Animate.m3:71 #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313 #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 #7 0x00020798 in ViewIncrementalReal__ShowPixel (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ ViewIncrementalReal.m3:567 #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../ src/Zeus.m3:331 #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #11 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #12 0x96373155 in _pthread_start () #13 0x96373012 in thread_start () Thread 17 (process 84568 thread 0x6f0f): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../ src/Zeus.m3:328 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 16 (process 84568 thread 0x425b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) at ../src/ZeusPanel.m3:1425 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 15 (process 84568 thread 0x310b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) at ../src/View.m3:74 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 14 (process 84568 thread 0x3003): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) at ../src/View.m3:74 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 13 (process 84568 thread 0x2f03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) at ../src/View.m3:74 #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 12 (process 84568 thread 0x2e03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) at ../src/xvbt/XMessenger.m3:69 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 11 (process 84568 thread 0x2d03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) at ../src/xvbt/XInput.m3:102 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 10 (process 84568 thread 0x2a2b): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/unix/ Common/UnixC.c:301 #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ PTHREAD/ThreadPThread.m3:788 #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ PTHREAD/ThreadPThread.m3:827 #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ thread/PTHREAD/ThreadPThread.m3:730 #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) at ../src/xvbt/XInput.m3:63 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 9 (process 84568 thread 0x29f3): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 #7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/BresenhamIE.m3:227 #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../ src/bresenham/AlgBresenham.m3:55 #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../ src/bresenham/AlgBresenham.m3:86 #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) at ../ src/ZeusPanel.m3:1534 #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 8 (process 84568 thread 0x2803): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) at ../ src/formatter/Formatter.m3:615 #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 7 (process 84568 thread 0x2703): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) at ../ src/formatter/Formatter.m3:615 #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 6 (process 84568 thread 0x2603): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) at ../src/WorkerPool.m3:152 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 5 (process 84568 thread 0x2313): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../src/ unix/Common/UnixC.c:301 #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/ thread/PTHREAD/ThreadPThread.m3:788 #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=1 '\001') at ../src/thread/ PTHREAD/ThreadPThread.m3:827 #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ src/thread/PTHREAD/ThreadPThread.m3:743 #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/POSIX/ TCP.m3:234 #7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #9 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #10 0x96373155 in _pthread_start () #11 0x96373012 in thread_start () Thread 4 (process 84568 thread 0x2003): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:669 #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:686 #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) at ../src/lego/FileBrowserVBT.m3:259 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 3 (process 84568 thread 0x1f03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 2 (process 84568 thread 0x313): #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../ src/thread/PTHREAD/ThreadPThread.m3:669 #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:686 #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../ src/vbt/VBTRep.m3:460 #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #4 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #5 0x96373155 in _pthread_start () #6 0x96373012 in thread_start () Thread 1 (process 84568 local thread 0x2e03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../ src/trestle/Trestle.m3:884 #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ src/runtime/common/RTLinker.m3:400 #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at _m3main.mc:6 On 1 Sep 2009, at 22:53, Randy Coleburn wrote: > I tried upgrade.py again, and it seemed to work this time. I think > I may have forgotten to run vcvars to setup the Visual C++ command > line on my prior attempt. Sorry. > > Here is the compiler output for the "caltech-parser\parserlib > \parserlib\test" build: > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > > LIB_INSTALL is C:\cm3\lib > ignoring ..\src\m3overrides > > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o > CalcTok.i3 > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o > CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime > error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src > \Calc.t -o CalcTok.i3 > > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib > \parserlib\test\NT386\m3make.args > > Fatal Error: package build failed > > I tried running juno and mentor again. I get different results each > run. Interestingly, sometimes mentor didn't crash, instead giving > me an error message about not having my HOME environment var set. I > tried later to set this, but mentor still crashes. Once when I ran > juno it complained that it tried to join a thread twice. Sounds > like something is broken in the threading or GC, or the program is > coded wrongly somehow. See below for some sample runs of mentor and > juno: > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** Exception "FormsVBT.Error" not in RAISES list > *** file "..\src\FormsVBT.m3", line 73 > *** > > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "..\src\runtime\common\RTType.m3", line 71 > *** > > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 > 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 > 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 > 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 > 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 > 0x12fe88 0x4e32da RegisterView + 0x30 in .. > \NT386\MinimaxViewGameTreeBObliqView.m3 > 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in .. > \NT386\MinimaxViewGameTreeBObliqView.m3 > > Here is another run of Juno. This one dies on a different line > number in same module. > > > C:\cm3\Sandbox\cm3\scripts\win>juno > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1087 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common > \RTCollector.m3 > 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime > \common\RTCollector.m3 > 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src > \JunoCompile.m3 > 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src > \JunoCompile.m3 > 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src > \JunoCompile.m3 > 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src > \JunoCompile.m3 > 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src > \JunoCompile.m3 > 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src > \JunoCompile.m3 > 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src > \JunoCompile.m3 > 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src > \JunoCompile.m3 > ......... ......... ... more frames ... > > Regards, > Randy Coleburn > > >>> Jay K 9/1/2009 9:33 PM >>> > Is the message about errno.h correct? > caltech-parser..hm.. you are up to date? I thought I had either > fixed it, or filtered it out. > Mutex/mentor I'll have to look at. > > - Jay > > Date: Tue, 1 Sep 2009 20:09:25 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] report on Windows XP builds/tests > > Hi, I am back from vacation. > > I've updated my sandbox on WindowsXP to be current with the CVS head. > > I tried first to run Jay's "upgrade.py", but got the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > using c:\cm3\bin\cm3.exe > PATH=c:\cm3\bin;%PATH% > set CM3_TARGET=NT386 > set CM3_INSTALL=c:\cm3 > set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- > install\NT386 > set CM3_ROOT=C:/cm3/Sandbox/cm3 > ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: > \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files > \Microsoft Platform SDK for Windows Server 2003 R2\Include) > C:\cm3\Sandbox\cm3\scripts\python> > > Next I tried my upgrade script and was successful. Then I used my > "do-cm3.cmd" script to rebuild all packages and was successful, > except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib > \test". > > In catching up on my email, I noticed Olaf had asked about mentor > and juno on Windows, so I tried running these. Juno starts up and > puts up a window, but quickly crashes. mentor crashes before any > window comes up and I also get a firewall request from Windows > asking whether to block the program--I suspect it is trying to > access the network, hence the firewall request. Here are the > runtime error reports: > > C:\cm3\bin>mentor > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime > \NT386\RTSignal.m3 > 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 > 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 > 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 > 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > > C:\cm3\bin>juno > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 2284 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime > \common\RTCollector.m3 > 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 > 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 > 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 > 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 > 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 > 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 > 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 > 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 > 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > C:\cm3\bin> > > Juno crashes on an ASSERT in the collector, while mentor seems to be > trying to lock a mutex that isn't properly initialized. I have not > looked at the source code to try and debug. Let me know if you want > me to pursue further. > > I've rebuilt some of my own programs and run some very basic tests. > So far, no problems detected. > > I will try to run some tests on Vista platform tomorrow. > > Maybe it would be prudent for me to compile and run some of the > tests ya'll have been implementing. I think the scripts for these > aren't native Windows, but if you can point me to some of these, > I'll try to translate for use on Windows. > > Let me know how I can best assist with the release effort. > > Regards, > Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 2 06:00:12 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 04:00:12 +0000 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <4A9DD12E.2080903@esoteriq.org> References: <4A9DD0B2.4010505@esoteriq.org> <4A9DD12E.2080903@esoteriq.org> Message-ID: I had the same experience with cm3 not found. cm3 is expected to be on the path. Seems kind of reasonable? As to the need to have dependencies -- well, this is our simple cross platform package format. Ahem, if we just bundled everything together in one package, the dependency problem would go away. Granted, maybe that is yucky. - Jay > Date: Tue, 1 Sep 2009 20:58:06 -0500 > From: mbishop at esoteriq.org > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Mentor error on LINUXLIBC6 > > Martin Bishop wrote: > > I installed the RC3 core fine, worked well, but I was adding addition > > packages and tried running mentor. I get: > > > > mentor: error while loading shared library libobliqlibanim.so.5: > > cannot open shared object file: No such file or directory. > > > > I'm guessing this is because I didn't install the Obliq package...but > > why should I have to? > > > Oh, and another issue (might just be me?) when I use the install scripts > in each package, they complain that "cm3" is not found. If it change it > to /usr/local/cm3/bin/cm3, it works just fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 2 06:20:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 04:20:41 +0000 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: My fear is that I messed up when I factored sizeof(pthread_cond_t), sizeof(pthread_mutex_t), etc. out of the Modula-3 code. The code looks right, but it is easy to miss a level of indirection, or something. We also might as well wrap the last few that aren't wrapped, but no reason to believe that will fix anything. My dashed hope is/was that the compiler being written in Modula-3, including using multiple threads, for garbage collection, would be a good test of the overall system working. The caltech-parser problem looks familiar. I'll have to look again. - Jay ________________________________ > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Tue, 1 Sep 2009 23:52:39 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] report on Windows XP builds/tests > > mentor (and probably other GUI apps) lock up in ways I have not seen before (it has been a long time since I tried running it, but it always used to work for me without problems about the time that I was bedding down the native threads code so logs there might give the timeframe). I suspect something is quite broken, but don't know when the brokenness got introduced. Here is a backtrace for all threads: > > Thread 20 (process 84568 thread 0x4f07): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:686 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../src/xvbt/XClientF.m3:105 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 19 (process 84568 thread 0x4e0b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../src/Zeus.m3:328 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 84568 thread 0x5c0b): > #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:189 > #1 0x0101ee7a in ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ThreadPThread.m3:324 > #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:670 > #3 0x0101f77a in Thread__AlertPause (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ThreadPThread.m3:700 > #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71 > #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #7 0x00020798 in ViewIncrementalReal__ShowPixel (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ViewIncrementalReal.m3:567 > #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 > #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../src/Zeus.m3:331 > #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #11 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #12 0x96373155 in _pthread_start () > #13 0x96373012 in thread_start () > > Thread 17 (process 84568 thread 0x6f0f): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../src/Zeus.m3:328 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 16 (process 84568 thread 0x425b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) at ../src/ZeusPanel.m3:1425 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 84568 thread 0x310b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) at ../src/View.m3:74 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 84568 thread 0x3003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) at ../src/View.m3:74 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 84568 thread 0x2f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) at ../src/View.m3:74 > #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #8 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 84568 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) at ../src/xvbt/XMessenger.m3:69 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 84568 thread 0x2d03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) at ../src/xvbt/XInput.m3:102 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 84568 thread 0x2a2b): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/unix/Common/UnixC.c:301 > #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:788 > #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:827 > #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:730 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) at ../src/xvbt/XInput.m3:63 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 84568 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) at ../src/ZeusPanel.m3:1534 > #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 84568 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) at ../src/formatter/Formatter.m3:615 > #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 84568 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) at ../src/formatter/Formatter.m3:615 > #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #12 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 84568 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) at ../src/WorkerPool.m3:152 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 84568 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../src/unix/Common/UnixC.c:301 > #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/thread/PTHREAD/ThreadPThread.m3:788 > #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:827 > #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:743 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 > #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #9 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 84568 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:686 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) at ../src/lego/FileBrowserVBT.m3:259 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 84568 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 > #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #7 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 84568 thread 0x313): > #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) at ../src/thread/PTHREAD/ThreadPThread.m3:686 > #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../src/vbt/VBTRep.m3:460 > #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:547 > #4 0x010218d7 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:523 > #5 0x96373155 in _pthread_start () > #6 0x96373012 in thread_start () > > Thread 1 (process 84568 local thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 > #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:400 > #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at _m3main.mc:6 > > > On 1 Sep 2009, at 22:53, Randy Coleburn wrote: > > I tried upgrade.py again, and it seemed to work this time. I think I may have forgotten to run vcvars to setup the Visual C++ command line on my prior attempt. Sorry. > > Here is the compiler output for the "caltech-parser\parserlib\parserlib\test" build: > > --- processing package "caltech-parser\parserlib\parserlib\test" --- > --- building in NT386 --- > > LIB_INSTALL is C:\cm3\lib > ignoring ..\src\m3overrides > > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args > > Fatal Error: package build failed > > I tried running juno and mentor again. I get different results each run. Interestingly, sometimes mentor didn't crash, instead giving me an error message about not having my HOME environment var set. I tried later to set this, but mentor still crashes. Once when I ran juno it complained that it tried to join a thread twice. Sounds like something is broken in the threading or GC, or the program is coded wrongly somehow. See below for some sample runs of mentor and juno: > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** Exception "FormsVBT.Error" not in RAISES list > *** file "..\src\FormsVBT.m3", line 73 > *** > > > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "..\src\runtime\common\RTType.m3", line 71 > *** > > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > Error: the HOME environment variable is undefined. > Please set it to the path of your home directory and try again. > > C:\cm3\Sandbox\cm3\scripts\win>mentor > > *** > *** runtime error: > *** failed. > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 > 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 > 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 > 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 > 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 > 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 > 0x12fe88 0x4e32da RegisterView + 0x30 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 > 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in ..\NT386\MinimaxViewGameTreeBObliqView.m3 > > Here is another run of Juno. This one dies on a different line number in same module. > > > C:\cm3\Sandbox\cm3\scripts\win>juno > > *** > *** runtime error: > *** failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1087 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common\RTCollector.m3 > 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime\common\RTCollector.m3 > 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src\JunoCompile.m3 > 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src\JunoCompile.m3 > 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src\JunoCompile.m3 > 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src\JunoCompile.m3 > 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src\JunoCompile.m3 > 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src\JunoCompile.m3 > 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src\JunoCompile.m3 > 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > Regards, > Randy Coleburn > >>>> Jay K> 9/1/2009 9:33 PM>>> > Is the message about errno.h correct? > caltech-parser..hm.. you are up to date? I thought I had either fixed it, or filtered it out. > Mutex/mentor I'll have to look at. > > - Jay > > ________________________________ > Date: Tue, 1 Sep 2009 20:09:25 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] report on Windows XP builds/tests > > Hi, I am back from vacation. > > I've updated my sandbox on WindowsXP to be current with the CVS head. > > I tried first to run Jay's "upgrade.py", but got the following error: > > C:\cm3\Sandbox\cm3\scripts\python>upgrade.py > using c:\cm3\bin\cm3.exe > PATH=c:\cm3\bin;%PATH% > set CM3_TARGET=NT386 > set CM3_INSTALL=c:\cm3 > set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no-install\NT386 > set CM3_ROOT=C:/cm3/Sandbox/cm3 > ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include) > C:\cm3\Sandbox\cm3\scripts\python> > > Next I tried my upgrade script and was successful. Then I used my "do-cm3.cmd" script to rebuild all packages and was successful, except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib\test". > > In catching up on my email, I noticed Olaf had asked about mentor and juno on Windows, so I tried running these. Juno starts up and puts up a window, but quickly crashes. mentor crashes before any window comes up and I also get a firewall request from Windows asking whether to block the program--I suspect it is trying to access the network, hence the firewall request. Here are the runtime error reports: > > C:\cm3\bin>mentor > > *** > *** runtime error: > *** Attempt to reference an illegal memory location. > *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 > 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread\WIN32\ThreadWin32.m3 > 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 > 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 > 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 > 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 > 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 > 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 > ......... ......... ... more frames ... > > > C:\cm3\bin>juno > > *** > *** runtime error: > *** failed. > *** file "..\src\runtime\common\RTCollector.m3", line 2284 > *** > > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common\RTCollector.m3 > 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 > 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 > 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 > 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 > 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 > 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 > 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 > 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 > 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 > ......... ......... ... more frames ... > > C:\cm3\bin> > > Juno crashes on an ASSERT in the collector, while mentor seems to be trying to lock a mutex that isn't properly initialized. I have not looked at the source code to try and debug. Let me know if you want me to pursue further. > > I've rebuilt some of my own programs and run some very basic tests. So far, no problems detected. > > I will try to run some tests on Vista platform tomorrow. > > Maybe it would be prudent for me to compile and run some of the tests ya'll have been implementing. I think the scripts for these aren't native Windows, but if you can point me to some of these, I'll try to translate for use on Windows. > > Let me know how I can best assist with the release effort. > > Regards, > Randy Coleburn > From hosking at cs.purdue.edu Wed Sep 2 06:52:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 2 Sep 2009 00:52:15 -0400 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: On 2 Sep 2009, at 00:20, Jay K wrote: > My fear is that I messed up when I factored sizeof(pthread_cond_t), > sizeof(pthread_mutex_t), etc. out of the Modula-3 code. > The code looks right, but it is easy to miss a level of indirection, > or something. > We also might as well wrap the last few that aren't wrapped, but no > reason to believe that will fix anything. We'll need to look into this. The weird thing is that it *mostly* works. I'd have thought getting those wrong would break everywhere. Still, probably worth rechecking. > My dashed hope is/was that the compiler being written in Modula-3, > including using multiple threads, for garbage collection, would be a > good test of the overall system working. I don't think the compiler is a multi-threaded mutator. The GC piggybacks work on the mutator by default, rather than running in separate threads. > The caltech-parser problem looks familiar. I'll have to look again. > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> To: rcoleburn at scires.com >> Date: Tue, 1 Sep 2009 23:52:39 -0400 >> CC: m3devel at elegosoft.com; jay.krell at cornell.edu >> Subject: Re: [M3devel] report on Windows XP builds/tests >> >> mentor (and probably other GUI apps) lock up in ways I have not >> seen before (it has been a long time since I tried running it, but >> it always used to work for me without problems about the time that >> I was bedding down the native threads code so logs there might give >> the timeframe). I suspect something is quite broken, but don't know >> when the brokenness got introduced. Here is a backtrace for all >> threads: >> >> Thread 20 (process 84568 thread 0x4f07): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, >> rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:669 >> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:686 >> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../ >> src/xvbt/XClientF.m3:105 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 19 (process 84568 thread 0x4e0b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, >> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >> M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >> M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../ >> src/Zeus.m3:328 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 18 (process 84568 thread 0x5c0b): >> #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) >> at ../src/thread/PTHREAD/ThreadPThread.m3:189 >> #1 0x0101ee7a in ThreadPThread__XTestAlert >> (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:324 >> #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, >> M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') >> at ../src/thread/PTHREAD/ThreadPThread.m3:670 >> #3 0x0101f77a in Thread__AlertPause >> (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:700 >> #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, >> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) >> at ../src/Animate.m3:71 >> #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, >> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >> #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, >> M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 >> #7 0x00020798 in ViewIncrementalReal__ShowPixel >> (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ >> ViewIncrementalReal.m3:567 >> #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, >> M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 >> #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../ >> src/Zeus.m3:331 >> #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #11 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #12 0x96373155 in _pthread_start () >> #13 0x96373012 in thread_start () >> >> Thread 17 (process 84568 thread 0x6f0f): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, >> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >> M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >> M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../ >> src/Zeus.m3:328 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 16 (process 84568 thread 0x425b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, >> M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, >> M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) >> at ../src/ZeusPanel.m3:1425 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 15 (process 84568 thread 0x310b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) >> at ../src/View.m3:74 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 14 (process 84568 thread 0x3003): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) >> at ../src/View.m3:74 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 13 (process 84568 thread 0x2f03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) >> at ../src/View.m3:74 >> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #8 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 12 (process 84568 thread 0x2e03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, >> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >> M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) >> at ../src/xvbt/XMessenger.m3:69 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 11 (process 84568 thread 0x2d03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, >> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >> M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) >> at ../src/xvbt/XInput.m3:102 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 10 (process 84568 thread 0x2a2b): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, >> writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/ >> unix/Common/UnixC.c:301 >> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:788 >> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:827 >> #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, >> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:730 >> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) >> at ../src/xvbt/XInput.m3:63 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 9 (process 84568 thread 0x29f3): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, >> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, >> M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, >> M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 >> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, >> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 >> #7 0x000149a7 in BresenhamIE__ShowPixel >> (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/ >> BresenhamIE.m3:227 >> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, >> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >> at ../src/bresenham/AlgBresenham.m3:55 >> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../ >> src/bresenham/AlgBresenham.m3:86 >> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) >> at ../src/ZeusPanel.m3:1534 >> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #12 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 8 (process 84568 thread 0x2803): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, >> M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, >> M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >> Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, >> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) >> at ../src/formatter/Formatter.m3:615 >> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #12 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 7 (process 84568 thread 0x2703): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, >> M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, >> M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >> Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, >> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) >> at ../src/formatter/Formatter.m3:615 >> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #12 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 6 (process 84568 thread 0x2603): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, >> M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, >> M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >> #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) >> at ../src/WorkerPool.m3:152 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 5 (process 84568 thread 0x2313): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, >> writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../ >> src/unix/Common/UnixC.c:301 >> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:788 >> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:827 >> #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, >> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:743 >> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, >> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/ >> POSIX/TCP.m3:234 >> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >> (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 >> #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #9 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #10 0x96373155 in _pthread_start () >> #11 0x96373012 in thread_start () >> >> Thread 4 (process 84568 thread 0x2003): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, >> rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:669 >> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:686 >> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) >> at ../src/lego/FileBrowserVBT.m3:259 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 3 (process 84568 thread 0x1f03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, >> M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, >> M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00a839e2 in VTView__VFontCleanUpThread >> (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 >> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #7 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 2 (process 84568 thread 0x313): >> #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, >> M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../ >> src/thread/PTHREAD/ThreadPThread.m3:669 >> #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) >> at ../src/thread/PTHREAD/ThreadPThread.m3:686 >> #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../ >> src/vbt/VBTRep.m3:460 >> #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) >> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >> #4 0x010218d7 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:523 >> #5 0x96373155 in _pthread_start () >> #6 0x96373012 in thread_start () >> >> Thread 1 (process 84568 local thread 0x2e03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, >> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >> M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../ >> src/trestle/Trestle.m3:884 >> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >> M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 >> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >> #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ >> src/runtime/common/RTLinker.m3:400 >> #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at >> _m3main.mc:6 >> >> >> On 1 Sep 2009, at 22:53, Randy Coleburn wrote: >> >> I tried upgrade.py again, and it seemed to work this time. I think >> I may have forgotten to run vcvars to setup the Visual C++ command >> line on my prior attempt. Sorry. >> >> Here is the compiler output for the "caltech-parser\parserlib >> \parserlib\test" build: >> >> --- processing package "caltech-parser\parserlib\parserlib\test" --- >> --- building in NT386 --- >> >> LIB_INSTALL is C:\cm3\lib >> ignoring ..\src\m3overrides >> >> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >> CalcTok.i3 >> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >> CalcTok.i3 >> The system cannot find the path specified. >> "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime >> error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok .. >> \src\Calc.t -o CalcTok.i3 >> >> --procedure-- -line- -file--- >> exec -- >> _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl >> _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl >> _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl >> _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl >> token 73 C:\cm3\pkg\parserlib\src\parser.tmpl >> include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib >> \test\src\m3makefile >> 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test >> \NT386\m3make.args >> >> Fatal Error: package build failed >> >> I tried running juno and mentor again. I get different results each >> run. Interestingly, sometimes mentor didn't crash, instead giving >> me an error message about not having my HOME environment var set. I >> tried later to set this, but mentor still crashes. Once when I ran >> juno it complained that it tried to join a thread twice. Sounds >> like something is broken in the threading or GC, or the program is >> coded wrongly somehow. See below for some sample runs of mentor and >> juno: >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> >> *** >> *** runtime error: >> *** Exception "FormsVBT.Error" not in RAISES list >> *** file "..\src\FormsVBT.m3", line 73 >> *** >> >> >> >> *** >> *** runtime error: >> *** An enumeration or subrange value was out of range. >> *** file "..\src\runtime\common\RTType.m3", line 71 >> *** >> >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> Error: the HOME environment variable is undefined. >> Please set it to the path of your home directory and try again. >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> Error: the HOME environment variable is undefined. >> Please set it to the path of your home directory and try again. >> >> C:\cm3\Sandbox\cm3\scripts\win>mentor >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread >> \WIN32\ThreadWin32.m3 >> 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 >> 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 >> 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 >> 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 >> 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 >> 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 >> 0x12fe88 0x4e32da RegisterView + 0x30 in .. >> \NT386\MinimaxViewGameTreeBObliqView.m3 >> 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in .. >> \NT386\MinimaxViewGameTreeBObliqView.m3 >> >> Here is another run of Juno. This one dies on a different line >> number in same module. >> >> >> C:\cm3\Sandbox\cm3\scripts\win>juno >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 1087 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common >> \RTCollector.m3 >> 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime >> \common\RTCollector.m3 >> 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src >> \JunoCompile.m3 >> 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src >> \JunoCompile.m3 >> 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src >> \JunoCompile.m3 >> 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src >> \JunoCompile.m3 >> 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src >> \JunoCompile.m3 >> 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src >> \JunoCompile.m3 >> 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src >> \JunoCompile.m3 >> 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src >> \JunoCompile.m3 >> ......... ......... ... more frames ... >> >> Regards, >> Randy Coleburn >> >>>>> Jay K> 9/1/2009 9:33 PM>>> >> Is the message about errno.h correct? >> caltech-parser..hm.. you are up to date? I thought I had either >> fixed it, or filtered it out. >> Mutex/mentor I'll have to look at. >> >> - Jay >> >> ________________________________ >> Date: Tue, 1 Sep 2009 20:09:25 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] report on Windows XP builds/tests >> >> Hi, I am back from vacation. >> >> I've updated my sandbox on WindowsXP to be current with the CVS head. >> >> I tried first to run Jay's "upgrade.py", but got the following error: >> >> C:\cm3\Sandbox\cm3\scripts\python>upgrade.py >> using c:\cm3\bin\cm3.exe >> PATH=c:\cm3\bin;%PATH% >> set CM3_TARGET=NT386 >> set CM3_INSTALL=c:\cm3 >> set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- >> install\NT386 >> set CM3_ROOT=C:/cm3/Sandbox/cm3 >> ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: >> \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files >> \Microsoft Platform SDK for Windows Server 2003 R2\Include) >> C:\cm3\Sandbox\cm3\scripts\python> >> >> Next I tried my upgrade script and was successful. Then I used my >> "do-cm3.cmd" script to rebuild all packages and was successful, >> except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib >> \test". >> >> In catching up on my email, I noticed Olaf had asked about mentor >> and juno on Windows, so I tried running these. Juno starts up and >> puts up a window, but quickly crashes. mentor crashes before any >> window comes up and I also get a firewall request from Windows >> asking whether to block the program--I suspect it is trying to >> access the network, hence the firewall request. Here are the >> runtime error reports: >> >> C:\cm3\bin>mentor >> >> *** >> *** runtime error: >> *** Attempt to reference an illegal memory location. >> *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread >> \WIN32\ThreadWin32.m3 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime >> \NT386\RTSignal.m3 >> 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread >> \WIN32\ThreadWin32.m3 >> 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 >> 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 >> 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >> 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >> 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 >> 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >> 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >> 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 >> ......... ......... ... more frames ... >> >> >> C:\cm3\bin>juno >> >> *** >> *** runtime error: >> *** failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 2284 >> *** >> >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common >> \RTCollector.m3 >> 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 >> 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 >> 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 >> 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 >> 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 >> 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 >> 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 >> 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 >> 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 >> ......... ......... ... more frames ... >> >> C:\cm3\bin> >> >> Juno crashes on an ASSERT in the collector, while mentor seems to >> be trying to lock a mutex that isn't properly initialized. I have >> not looked at the source code to try and debug. Let me know if you >> want me to pursue further. >> >> I've rebuilt some of my own programs and run some very basic tests. >> So far, no problems detected. >> >> I will try to run some tests on Vista platform tomorrow. >> >> Maybe it would be prudent for me to compile and run some of the >> tests ya'll have been implementing. I think the scripts for these >> aren't native Windows, but if you can point me to some of these, >> I'll try to translate for use on Windows. >> >> Let me know how I can best assist with the release effort. >> >> Regards, >> Randy Coleburn >> From jay.krell at cornell.edu Wed Sep 2 07:15:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 05:15:46 +0000 Subject: [M3devel] report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: Yep, no matter what the problem is, that's my other dashed hope -- that'd it'd either work very little or very much, and not somewhere in between as it does. It seems a little surprising to see things only 4-aligned below, but I'd have to check the related sizes, if they are 4 then ok. I also checked the parameter order for calloc. calloc(n,1) could reasonably provide something unaligned, but calloc(1,n) that I use should be n or "max" aligned, whichever is smaller. I can't claim that I thought of this at the time, maybe I just got lucky. I'll /try/ to look at this shortly. Nice that it occurs on NT too. :) It could be something else entirely, but this an obvious area to double double double check, and if not too difficult, test with it reverted and sort of prove by showing the opposite behavior with the opposite state (which isn't conclusive, but you understand..) Hm noticably on NT I didn't make this change for dynamically allocated structures, only static ones. That part is also a little bit to be focused on, but /seemingly/ easier to get correct. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Wed, 2 Sep 2009 00:52:15 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] report on Windows XP builds/tests > > On 2 Sep 2009, at 00:20, Jay K wrote: > >> My fear is that I messed up when I factored sizeof(pthread_cond_t), >> sizeof(pthread_mutex_t), etc. out of the Modula-3 code. >> The code looks right, but it is easy to miss a level of indirection, >> or something. >> We also might as well wrap the last few that aren't wrapped, but no >> reason to believe that will fix anything. > > We'll need to look into this. The weird thing is that it *mostly* > works. I'd have thought getting those wrong would break everywhere. > Still, probably worth rechecking. > >> My dashed hope is/was that the compiler being written in Modula-3, >> including using multiple threads, for garbage collection, would be a >> good test of the overall system working. > > I don't think the compiler is a multi-threaded mutator. > > The GC piggybacks work on the mutator by default, rather than running > in separate threads. > >> The caltech-parser problem looks familiar. I'll have to look again. >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> To: rcoleburn at scires.com >>> Date: Tue, 1 Sep 2009 23:52:39 -0400 >>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu >>> Subject: Re: [M3devel] report on Windows XP builds/tests >>> >>> mentor (and probably other GUI apps) lock up in ways I have not >>> seen before (it has been a long time since I tried running it, but >>> it always used to work for me without problems about the time that >>> I was bedding down the native threads code so logs there might give >>> the timeframe). I suspect something is quite broken, but don't know >>> when the brokenness got introduced. Here is a backtrace for all >>> threads: >>> >>> Thread 20 (process 84568 thread 0x4f07): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0fbcd9c, >>> rem=0xb0fbcd94) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1d7354c, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:669 >>> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:686 >>> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1d7353c) at ../ >>> src/xvbt/XClientF.m3:105 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c299c0) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c299c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 19 (process 84568 thread 0x4e0b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84134, >>> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1d37118, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >>> M3_Bl0jv4_c=0x1d37118) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >>> M3_B74vJ1_view=0x1d37044) at ../src/Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84128) at ../ >>> src/Zeus.m3:328 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40a40) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c40a40) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 18 (process 84568 thread 0x5c0b): >>> #0 0x01020e19 in ThreadPThread__UnlockMutex (M3_AYIbX3_m=0x1e840bc) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:189 >>> #1 0x0101ee7a in ThreadPThread__XTestAlert >>> (M3_BXP32l_self=0x1e840bc) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:324 >>> #2 0x0101f348 in ThreadPThread__XPause (M3_BXP32l_self=0x1e840bc, >>> M3_CtKayy_n=0.0010560248047113419, M3_AicXUJ_alertable=1 '\001') >>> at ../src/thread/PTHREAD/ThreadPThread.m3:670 >>> #3 0x0101f77a in Thread__AlertPause >>> (M3_CtKayy_n=0.0010560248047113419) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:700 >>> #4 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e8b104, >>> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e880f8, M3_BUucNs_duration=1) >>> at ../src/Animate.m3:71 >>> #5 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e880f8, >>> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >>> #6 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e8800c, >>> M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 >>> #7 0x00020798 in ViewIncrementalReal__ShowPixel >>> (M3_BK0xTW_view=0x1da725c, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >>> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../src/bresenham/ >>> ViewIncrementalReal.m3:567 >>> #8 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1da725c, >>> M3_Af40ku_evt=0x1f4e01c) at ../I386_DARWIN/BresenhamIE.m3:101 >>> #9 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e840b0) at ../ >>> src/Zeus.m3:331 >>> #10 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40960) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #11 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c40960) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #12 0x96373155 in _pthread_start () >>> #13 0x96373012 in thread_start () >>> >>> Thread 17 (process 84568 thread 0x6f0f): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1e84044, >>> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1df3bac, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1bd1024, >>> M3_Bl0jv4_c=0x1df3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1bce6f0, >>> M3_B74vJ1_view=0x1df3b00) at ../src/Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e84038) at ../ >>> src/Zeus.m3:328 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c40610) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c40610) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 16 (process 84568 thread 0x425b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d7e534, >>> M3_AYIbX3_m=0x1d4bd28, M3_Bl0jv4_c=0x1d4bd44, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d4bd28, >>> M3_Bl0jv4_c=0x1d4bd44) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1d7e524) >>> at ../src/ZeusPanel.m3:1425 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3aa10) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3aa10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 15 (process 84568 thread 0x310b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1eb9e68, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1de15d4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1de15d4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1df3b00) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1eb9e5c) >>> at ../src/View.m3:74 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39760) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c39760) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 14 (process 84568 thread 0x3003): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1df32e4, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1da73c4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1da73c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1da725c) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1df32d8) >>> at ../src/View.m3:74 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c395d0) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c395d0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 13 (process 84568 thread 0x2f03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d512e4, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d3932c, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1d3932c) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1d37044) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d512d8) >>> at ../src/View.m3:74 >>> #7 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39160) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #8 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c39160) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 12 (process 84568 thread 0x2e03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d392a4, >>> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375a4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >>> M3_Bl0jv4_c=0x1d375a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1d39294) >>> at ../src/xvbt/XMessenger.m3:69 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38e10) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38e10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 11 (process 84568 thread 0x2d03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d39254, >>> M3_AYIbX3_m=0x1d3722c, M3_Bl0jv4_c=0x1d375c4, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1d3722c, >>> M3_Bl0jv4_c=0x1d375c4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1d39244) >>> at ../src/xvbt/XInput.m3:102 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38d40) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38d40) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 10 (process 84568 thread 0x2a2b): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023463 in Unix__select (nfds=7, readfds=0x1d356f4, >>> writefds=0x1d35704, exceptfds=0x1d35714, timeout=0x0) at ../src/ >>> unix/Common/UnixC.c:301 >>> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:788 >>> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d39204, >>> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:827 >>> #4 0x0101f62c in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:730 >>> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1d391f4) >>> at ../src/xvbt/XInput.m3:63 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38c70) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38c70) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 9 (process 84568 thread 0x29f3): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bd1164, >>> M3_AYIbX3_m=0x1bd1024, M3_Bl0jv4_c=0x1bd1030, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bd1024, >>> M3_Bl0jv4_c=0x1bd1030) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1bce6f0, >>> M3_Ao6Rbg_initiator=0x1bd1cc8, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:306 >>> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1bd1cc8, >>> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >>> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1f4e01c) at ../src/Zeus.m3:246 >>> #7 0x000149a7 in BresenhamIE__ShowPixel >>> (M3_CfiRBL_initiator=0x1bd1cc8, M3_AcxOUs_x=4, M3_AcxOUs_y=2, >>> M3_AcxOUs_p1=-2, M3_AcxOUs_p2=10) at ../I386_DARWIN/ >>> BresenhamIE.m3:227 >>> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1bd1cc8, >>> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >>> at ../src/bresenham/AlgBresenham.m3:55 >>> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1bd1cc8) at ../ >>> src/bresenham/AlgBresenham.m3:86 >>> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1bd1150) >>> at ../src/ZeusPanel.m3:1534 >>> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c2a110) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #12 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c2a110) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 8 (process 84568 thread 0x2803): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d6200c, >>> M3_AYIbX3_m=0x1d43fb4, M3_Bl0jv4_c=0x1d43fc0, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d43fb4, >>> M3_Bl0jv4_c=0x1d43fc0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d43658, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >>> Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d43658, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d43658, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d43658, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d43658, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, >>> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d43fd0) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29240) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #12 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29240) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 7 (process 84568 thread 0x2703): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d435f0, >>> M3_AYIbX3_m=0x1d435c4, M3_Bl0jv4_c=0x1d435d0, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d435c4, >>> M3_Bl0jv4_c=0x1d435d0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d42c68, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/ >>> Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d42c68, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d42c68, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d42c68, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d42c68, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, >>> M3_CCuODf_op=0x1d44c28) at ../src/formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d435e0) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29060) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #12 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29060) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 6 (process 84568 thread 0x2603): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1d449dc, >>> M3_AYIbX3_m=0x1d448d4, M3_Bl0jv4_c=0x1d449c0, M3_AicXUJ_alertable=1 >>> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01022311 in Thread__AlertWait (M3_AYIbX3_m=0x1d448d4, >>> M3_Bl0jv4_c=0x1d449c0) at ../src/thread/PTHREAD/ThreadPThread.m3:267 >>> #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d449d0) >>> at ../src/WorkerPool.m3:152 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e00) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c28e00) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 5 (process 84568 thread 0x2313): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023463 in Unix__select (nfds=4, readfds=0x1d46014, >>> writefds=0x1d46024, exceptfds=0x1d46034, timeout=0xb0206b40) at ../ >>> src/unix/Common/UnixC.c:301 >>> #2 0x0101dba2 in ThreadPThread__XIOWait__CallSelect.770 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b40) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:788 >>> #3 0x0101f155 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d2a5bc, >>> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:827 >>> #4 0x0101f4ec in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:743 >>> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d2a594, >>> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >>> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d2a594) at ../src/ >>> POSIX/TCP.m3:234 >>> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >>> (M3_Dbz8GV_self=0x1d2a5b0) at ../src/LocalObjectSpace.m3:307 >>> #8 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29130) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #9 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29130) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #10 0x96373155 in _pthread_start () >>> #11 0x96373012 in thread_start () >>> >>> Thread 4 (process 84568 thread 0x2003): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022c22 in ThreadPThread__Nanosleep (req=0xb0184dbc, >>> rem=0xb0184db4) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101f32c in ThreadPThread__XPause (M3_BXP32l_self=0x1bc7a08, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:669 >>> #4 0x0101f8da in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:686 >>> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1bc7a00) >>> at ../src/lego/FileBrowserVBT.m3:259 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 3 (process 84568 thread 0x1f03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bc50d4, >>> M3_AYIbX3_m=0x1bc50b0, M3_Bl0jv4_c=0x1bc50bc, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bc50b0, >>> M3_Bl0jv4_c=0x1bc50bc) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00a839e2 in VTView__VFontCleanUpThread >>> (M3_EMTrVz_cl=0x1bc50cc) at ../src/vtext/VTView.m3:111 >>> #6 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #7 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 2 (process 84568 thread 0x313): >>> #0 0x0101f32f in ThreadPThread__XPause (M3_BXP32l_self=0x1bbc6c8, >>> M3_CtKayy_n=0.050000000000000003, M3_AicXUJ_alertable=0 '\0') at ../ >>> src/thread/PTHREAD/ThreadPThread.m3:669 >>> #1 0x0101f8da in Thread__Pause (M3_CtKayy_n=0.050000000000000003) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:686 >>> #2 0x00bf36ce in VBTRep__MeterMaid (M3_EMTrVz_self=0x1bbc6bc) at ../ >>> src/vbt/VBTRep.m3:460 >>> #3 0x010215d1 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:547 >>> #4 0x010218d7 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:523 >>> #5 0x96373155 in _pthread_start () >>> #6 0x96373012 in thread_start () >>> >>> Thread 1 (process 84568 local thread 0x2e03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x01021c08 in ThreadPThread__XWait (M3_BXP32l_self=0x1bbc00c, >>> M3_AYIbX3_m=0x1bbc500, M3_Bl0jv4_c=0x1d7e580, M3_AicXUJ_alertable=0 >>> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 >>> #4 0x01021d71 in Thread__Wait (M3_AYIbX3_m=0x1bbc500, >>> M3_Bl0jv4_c=0x1d7e580) at ../src/thread/PTHREAD/ThreadPThread.m3:278 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1bfdd44) at ../ >>> src/trestle/Trestle.m3:884 >>> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >>> M3_DYb95R_path=0x1d758c0) at ../src/ZeusPanel.m3:477 >>> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >>> #8 0x0100edbf in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ >>> src/runtime/common/RTLinker.m3:400 >>> #9 0x00002578 in main (argc=1, argv=0xbfffee00, envp=0xbfffee08) at >>> _m3main.mc:6 >>> >>> >>> On 1 Sep 2009, at 22:53, Randy Coleburn wrote: >>> >>> I tried upgrade.py again, and it seemed to work this time. I think >>> I may have forgotten to run vcvars to setup the Visual C++ command >>> line on my prior attempt. Sorry. >>> >>> Here is the compiler output for the "caltech-parser\parserlib >>> \parserlib\test" build: >>> >>> --- processing package "caltech-parser\parserlib\parserlib\test" --- >>> --- building in NT386 --- >>> >>> LIB_INSTALL is C:\cm3\lib >>> ignoring ..\src\m3overrides >>> >>> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >>> CalcTok.i3 >>> C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o >>> CalcTok.i3 >>> The system cannot find the path specified. >>> "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime >>> error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok .. >>> \src\Calc.t -o CalcTok.i3 >>> >>> --procedure-- -line- -file--- >>> exec -- >>> _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl >>> _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl >>> _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl >>> _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl >>> token 73 C:\cm3\pkg\parserlib\src\parser.tmpl >>> include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib >>> \test\src\m3makefile >>> 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test >>> \NT386\m3make.args >>> >>> Fatal Error: package build failed >>> >>> I tried running juno and mentor again. I get different results each >>> run. Interestingly, sometimes mentor didn't crash, instead giving >>> me an error message about not having my HOME environment var set. I >>> tried later to set this, but mentor still crashes. Once when I ran >>> juno it complained that it tried to join a thread twice. Sounds >>> like something is broken in the threading or GC, or the program is >>> coded wrongly somehow. See below for some sample runs of mentor and >>> juno: >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> >>> *** >>> *** runtime error: >>> *** Exception "FormsVBT.Error" not in RAISES list >>> *** file "..\src\FormsVBT.m3", line 73 >>> *** >>> >>> >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "..\src\runtime\common\RTType.m3", line 71 >>> *** >>> >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> Error: the HOME environment variable is undefined. >>> Please set it to the path of your home directory and try again. >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> Error: the HOME environment variable is undefined. >>> Please set it to the path of your home directory and try again. >>> >>> C:\cm3\Sandbox\cm3\scripts\win>mentor >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\thread\WIN32\ThreadWin32.m3", line 453 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x12fc48 0x84ad19 CheckSlot + 0x28 in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> 0x12fc8c 0x84b8ba Fork + 0x2a1 in ..\src\thread\WIN32\ThreadWin32.m3 >>> 0x12fcc4 0x1221c8c Parse + 0x5c in ..\src\FormsVBT.m3 >>> 0x12fd7c 0x1247c0c Insert + 0x149 in ..\src\FVRuntime.m3 >>> 0x12fde8 0x164cd6b UpdateSessionMenu + 0x3c9 in ..\src\ZeusPanel.m3 >>> 0x12fe18 0x164c997 GetGroupInfo + 0xb5 in ..\src\ZeusPanel.m3 >>> 0x12fe60 0x164d842 RegisterView + 0xf5 in ..\src\ZeusPanel.m3 >>> 0x12fe88 0x4e32da RegisterView + 0x30 in .. >>> \NT386\MinimaxViewGameTreeBObliqView.m3 >>> 0x12fe9c 0x4e43c7 MinimaxViewGameTreeBObliqView_M3 + 0x39 in .. >>> \NT386\MinimaxViewGameTreeBObliqView.m3 >>> >>> Here is another run of Juno. This one dies on a different line >>> number in same module. >>> >>> >>> C:\cm3\Sandbox\cm3\scripts\win>juno >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\runtime\common\RTCollector.m3", line 1087 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x263fb34 0x5d115f CleanBetween + 0x48 in ..\src\runtime\common >>> \RTCollector.m3 >>> 0x263fb7c 0x5d4cd9 CheckLoadTracedRef + 0xfa in ..\src\runtime >>> \common\RTCollector.m3 >>> 0x263fbc4 0x100117f6 AnnotateAtoms.Expr0 + 0x401 in ..\src >>> \JunoCompile.m3 >>> 0x263fbe8 0x10011f09 AnnotateAtoms.ExprList0 + 0xc0 in ..\src >>> \JunoCompile.m3 >>> 0x263fc34 0x100121b4 AnnotateAtoms.Cmd0 + 0x253 in ..\src >>> \JunoCompile.m3 >>> 0x263fc80 0x10012b74 AnnotateAtoms.Cmd0 + 0xc13 in ..\src >>> \JunoCompile.m3 >>> 0x263fccc 0x100128a2 AnnotateAtoms.Cmd0 + 0x941 in ..\src >>> \JunoCompile.m3 >>> 0x263fd18 0x10012c4e AnnotateAtoms.Cmd0 + 0xced in ..\src >>> \JunoCompile.m3 >>> 0x263fd64 0x10012225 AnnotateAtoms.Cmd0 + 0x2c4 in ..\src >>> \JunoCompile.m3 >>> 0x263fdb0 0x10012a9a AnnotateAtoms.Cmd0 + 0xb39 in ..\src >>> \JunoCompile.m3 >>> ......... ......... ... more frames ... >>> >>> Regards, >>> Randy Coleburn >>> >>>>>> Jay K> 9/1/2009 9:33 PM>>> >>> Is the message about errno.h correct? >>> caltech-parser..hm.. you are up to date? I thought I had either >>> fixed it, or filtered it out. >>> Mutex/mentor I'll have to look at. >>> >>> - Jay >>> >>> ________________________________ >>> Date: Tue, 1 Sep 2009 20:09:25 -0400 >>> From: rcoleburn at scires.com >>> To: m3devel at elegosoft.com >>> Subject: [M3devel] report on Windows XP builds/tests >>> >>> Hi, I am back from vacation. >>> >>> I've updated my sandbox on WindowsXP to be current with the CVS head. >>> >>> I tried first to run Jay's "upgrade.py", but got the following error: >>> >>> C:\cm3\Sandbox\cm3\scripts\python>upgrade.py >>> using c:\cm3\bin\cm3.exe >>> PATH=c:\cm3\bin;%PATH% >>> set CM3_TARGET=NT386 >>> set CM3_INSTALL=c:\cm3 >>> set M3CONFIG=C:\cm3\Sandbox\cm3\m3-sys\cminstall\src\config-no- >>> install\NT386 >>> set CM3_ROOT=C:/cm3/Sandbox/cm3 >>> ERROR: errno.h not found in %INCLUDE%(C:\msdev\80\VC\include;C: >>> \Program Files\Microsoft SDKs\Windows\v6.0A\Include;C:\Program Files >>> \Microsoft Platform SDK for Windows Server 2003 R2\Include) >>> C:\cm3\Sandbox\cm3\scripts\python> >>> >>> Next I tried my upgrade script and was successful. Then I used my >>> "do-cm3.cmd" script to rebuild all packages and was successful, >>> except for "m3-sys\m3cc" and "caltech-parser\parserlib\parserlib >>> \test". >>> >>> In catching up on my email, I noticed Olaf had asked about mentor >>> and juno on Windows, so I tried running these. Juno starts up and >>> puts up a window, but quickly crashes. mentor crashes before any >>> window comes up and I also get a firewall request from Windows >>> asking whether to block the program--I suspect it is trying to >>> access the network, hence the firewall request. Here are the >>> runtime error reports: >>> >>> C:\cm3\bin>mentor >>> >>> *** >>> *** runtime error: >>> *** Attempt to reference an illegal memory location. >>> *** pc = 0x849590 = LockMutex + 0x9c in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x2abf97c 0x846fdd SystemError + 0x66 in ..\src\runtime >>> \NT386\RTSignal.m3 >>> 0x2abf9b8 0x849590 LockMutex + 0x9c in ..\src\thread >>> \WIN32\ThreadWin32.m3 >>> 0x2abf9e8 0x1405c72 Be + 0x3e in ..\src\split\TextVBT.m3 >>> 0x2abfb24 0x1235764 pText + 0x6f4 in ..\src\FormsVBT.m3 >>> 0x2abfb84 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x2abfbb0 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x2abfc90 0x1227c9a pMButton + 0x11c in ..\src\FormsVBT.m3 >>> 0x2abfcf0 0x12234b1 Item + 0x48b in ..\src\FormsVBT.m3 >>> 0x2abfd1c 0x124107a OneChild + 0xf8 in ..\src\FormsVBT.m3 >>> 0x2abfe24 0x1227520 pShape + 0x19c in ..\src\FormsVBT.m3 >>> ......... ......... ... more frames ... >>> >>> >>> C:\cm3\bin>juno >>> >>> *** >>> *** runtime error: >>> *** failed. >>> *** file "..\src\runtime\common\RTCollector.m3", line 2284 >>> *** >>> >>> Stack trace: >>> FP PC Procedure >>> --------- --------- ------------------------------- >>> 0x210f9d8 0x5d4e43 CheckStoreTraced + 0xde in ..\src\runtime\common >>> \RTCollector.m3 >>> 0x210fa38 0x10041c74 Unnest + 0x124 in ..\src\JunoCompileNF.m3 >>> 0x210fac8 0x10040a49 B1 + 0x3d0 in ..\src\JunoCompileNF.m3 >>> 0x210faf4 0x1003f9b6 Normalize + 0x46 in ..\src\JunoCompileNF.m3 >>> 0x210fb20 0x10016b9f Cmd.C2pp + 0x20 in ..\src\JunoCompile.m3 >>> 0x210fb70 0x10016ac3 Cmd.C2p + 0x618 in ..\src\JunoCompile.m3 >>> 0x210fbcc 0x1001594b Cmd.C2 + 0x9c8 in ..\src\JunoCompile.m3 >>> 0x210fc24 0x100156b8 Cmd.C2 + 0x735 in ..\src\JunoCompile.m3 >>> 0x210fc7c 0x100151a0 Cmd.C2 + 0x21d in ..\src\JunoCompile.m3 >>> 0x210fcc8 0x10016b43 Cmd.C2p + 0x698 in ..\src\JunoCompile.m3 >>> ......... ......... ... more frames ... >>> >>> C:\cm3\bin> >>> >>> Juno crashes on an ASSERT in the collector, while mentor seems to >>> be trying to lock a mutex that isn't properly initialized. I have >>> not looked at the source code to try and debug. Let me know if you >>> want me to pursue further. >>> >>> I've rebuilt some of my own programs and run some very basic tests. >>> So far, no problems detected. >>> >>> I will try to run some tests on Vista platform tomorrow. >>> >>> Maybe it would be prudent for me to compile and run some of the >>> tests ya'll have been implementing. I think the scripts for these >>> aren't native Windows, but if you can point me to some of these, >>> I'll try to translate for use on Windows. >>> >>> Let me know how I can best assist with the release effort. >>> >>> Regards, >>> Randy Coleburn >>> > From wagner at elegosoft.com Wed Sep 2 08:39:23 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 08:39:23 +0200 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> References: <4A9DD0B2.4010505@esoteriq.org> <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> Message-ID: <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> Quoting Tony Hosking : > Because mentor depends on obliq? If you didn't install the obliq > package then it can't dynamically load the shard library. This is strange. mentor should be built standalone. Is build_standalone() broken on LINUXLIBC6? And I don't see a direct obliq dependency. Ah, that's in src/minimax/m3makefile; I've probably missed it when extracting the dependencies. > On 1 Sep 2009, at 21:56, Martin Bishop wrote: > >> I installed the RC3 core fine, worked well, but I was adding >> addition packages and tried running mentor. I get: >> >> mentor: error while loading shared library libobliqlibanim.so.5: >> cannot open shared object file: No such file or directory. >> >> I'm guessing this is because I didn't install the Obliq >> package...but why should I have to? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 2 08:45:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 06:45:36 +0000 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> References: <4A9DD0B2.4010505@esoteriq.org> <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> Message-ID: Why should mentor be standalone? - Jay ---------------------------------------- > Date: Wed, 2 Sep 2009 08:39:23 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Mentor error on LINUXLIBC6 > > Quoting Tony Hosking : > >> Because mentor depends on obliq? If you didn't install the obliq >> package then it can't dynamically load the shard library. > > This is strange. mentor should be built standalone. > Is build_standalone() broken on LINUXLIBC6? > > And I don't see a direct obliq dependency. Ah, that's in > src/minimax/m3makefile; I've probably missed it when extracting the > dependencies. > >> On 1 Sep 2009, at 21:56, Martin Bishop wrote: >> >>> I installed the RC3 core fine, worked well, but I was adding >>> addition packages and tried running mentor. I get: >>> >>> mentor: error while loading shared library libobliqlibanim.so.5: >>> cannot open shared object file: No such file or directory. >>> >>> I'm guessing this is because I didn't install the Obliq >>> package...but why should I have to? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Wed Sep 2 08:49:47 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 08:49:47 +0200 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> Message-ID: <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> Quoting Tony Hosking : > On 2 Sep 2009, at 00:20, Jay K wrote: > >> My fear is that I messed up when I factored sizeof(pthread_cond_t), >> sizeof(pthread_mutex_t), etc. out of the Modula-3 code. >> The code looks right, but it is easy to miss a level of >> indirection, or something. >> We also might as well wrap the last few that aren't wrapped, but no >> reason to believe that will fix anything. > > We'll need to look into this. The weird thing is that it *mostly* > works. I'd have thought getting those wrong would break everywhere. > Still, probably worth rechecking. If something this fundamental is broken in the runtime, we can probably forget all the RC3 packages built so far and just hope for RC4? Why has nobody noticed this before? We really need some more tests that are able to detect such breakage. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Sep 2 08:56:25 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 08:56:25 +0200 Subject: [M3devel] Mentor error on LINUXLIBC6 In-Reply-To: References: <4A9DD0B2.4010505@esoteriq.org> <8B1837B5-A5E0-483F-B372-E06D77C8E04E@cs.purdue.edu> <20090902083923.9ztixbhv7og0k4kg@mail.elegosoft.com> Message-ID: <20090902085625.crri91x21ws800os@mail.elegosoft.com> Quoting Jay K : > Why should mentor be standalone? You are correct. build_standalone() is a local modification in one of my workspaces for debugging. Sorry for the confusion. Still the dependency seems to be missing in the documentation (anim --> obliq). Probably the sub-makefiles weren't processed :-( Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 2 09:11:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 07:11:28 +0000 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> Message-ID: we can't answer the question until we determine the problem! :) - Jay ---------------------------------------- > Date: Wed, 2 Sep 2009 08:49:47 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests > > Quoting Tony Hosking : > >> On 2 Sep 2009, at 00:20, Jay K wrote: >> >>> My fear is that I messed up when I factored sizeof(pthread_cond_t), >>> sizeof(pthread_mutex_t), etc. out of the Modula-3 code. >>> The code looks right, but it is easy to miss a level of >>> indirection, or something. >>> We also might as well wrap the last few that aren't wrapped, but no >>> reason to believe that will fix anything. >> >> We'll need to look into this. The weird thing is that it *mostly* >> works. I'd have thought getting those wrong would break everywhere. >> Still, probably worth rechecking. > > If something this fundamental is broken in the runtime, we can > probably forget all the RC3 packages built so far and just hope > for RC4? > > Why has nobody noticed this before? We really need some more tests > that are able to detect such breakage. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Sep 2 10:41:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 08:41:59 +0000 Subject: [M3devel] duplicate FileBrowserVBT.m3 Message-ID: C:\dev2\cm3.2\m3-lectern\lectern\src\FileBrowserVBT.m3 C:\dev2\cm3.2\m3-ui\vbtkit\src\lego\FileBrowserVBT.m3 These are nearly identical. I don't entirely believe the comment about directories on Windows. - directories to have timestamps - it is up to the file system, not the operating system, You can see ext3 file systems over the network from Windows via SMB, etc. (and you can see FAT and NTFS on Linux, Solaris, Mac, etc. via SMB, NFS, etc.) They should be merged. Probably m3-ui/vbtkit is where the merge should go. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 2 11:26:02 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 02 Sep 2009 11:26:02 +0200 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> Message-ID: <20090902112602.eecq6rptkwk4k480@mail.elegosoft.com> Quoting Jay K : > we can't answer the question until we determine the problem! :) Of course. I have opened ticket #1070 in trac for this issue. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 2 11:30:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Sep 2009 09:30:08 +0000 Subject: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests In-Reply-To: <20090902112602.eecq6rptkwk4k480@mail.elegosoft.com> References: <4A9D7F7B.1E75.00D7.1@scires.com> <4A9DA5DB.1E75.00D7.1@scires.com> <20090902084947.09ueyoaddcows8gs@mail.elegosoft.com> <20090902112602.eecq6rptkwk4k480@mail.elegosoft.com> Message-ID: er, now that I experience it, of course, it is worse. I see the intermittent hangs of Juno on I386_DARWIN. I see Juno and/or mentor always/usually crashing on NT. The Juno crash is particularly nice because it is always accessing the same invalid address, or a fixed offset from it (the invalid address is in a register and the instruction contains an offset). @M3nogc seems to perturb it. NT has fewer changes here. I'm going to try 5.7.0 and 5.7.1 snapshots. Getting daily or weekly snapshots automatically from Hudson would be nice. - Jay > Date: Wed, 2 Sep 2009 11:26:02 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Release impacts, was: Re: report on Windows XP builds/tests > > Quoting Jay K : > > > we can't answer the question until we determine the problem! :) > > Of course. > > I have opened ticket #1070 in trac for this issue. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Thu Sep 3 00:46:42 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 02 Sep 2009 18:46:42 -0400 Subject: [M3devel] cm3.cfg for Windows Message-ID: <4A9EBD88.1E75.00D7.1@scires.com> Jay: After running your "upgrade.py" I notice that the "cm3\bin\cm3.cfg" file has been replaced and now contains 134 lines instead of the 2 lines you had described earlier. Let me know if I should switch back to the 2-line variant you described earlier, or if the new 134-line file is the new way forward. Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 3 03:15:12 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 2 Sep 2009 18:15:12 -0700 Subject: [M3devel] cm3.cfg for Windows In-Reply-To: <4A9EBD88.1E75.00D7.1@scires.com> References: <4A9EBD88.1E75.00D7.1@scires.com> Message-ID: <3D5C4155-A36D-4E87-AAB5-6AAC2E18A7BE@hotmail.com> They are both valid. The larger one makes some guesses and delegates back to the cvs tree. It is nice for when you are actively editing the files and don't want to also copy them. It also will delegate to the installed ones and there its value is honoring the CM3_TARGET environment variable. Upgrade.py should probably have a command line option. Really upgrade is just a LITTLE more than do-pkg and might need some rethinking. It also copies cm3 for example which is really a workaround for cm3 not shipping itself. For you probably the two liner. - Jay (phone) On Sep 2, 2009, at 3:46 PM, "Randy Coleburn" wrote: > Jay: > > After running your "upgrade.py" I notice that the "cm3\bin\cm3.cfg" > file has been replaced and now contains 134 lines instead of the 2 > lines you had described earlier. > > Let me know if I should switch back to the 2-line variant you > described earlier, or if the new 134-line file is the new way forward. > > Regards, > Randy From michael.anderson at elego.de Wed Sep 2 13:07:43 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 02 Sep 2009 13:07:43 +0200 Subject: [M3devel] elego Server Maintenance 04.09.09 Message-ID: <20090902130743.pp6nlfuumo8k4008@mail.elego.de> Liebe Kollegen, Liebe Elego-Kunden, In der Nacht von Freitag, dem 04.09 auf Samstag, den 05.09 werden wir um 22.00 CET Uhr planmaessige Wartungsarbeiten an unseren Servern durchfuehren. Es kann zur kurzeitigen Unterbrechung mancher Dienste kommen. Voraussichtliche Dauer der Wartung: 120 Min. Wir bitten um Verst?ndnis. - die elego Admins On Friday, September 4 at 10 PM CET, we will perform scheduled maintenance on our servers. Brief interruptions of service may occur. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Sep 3 15:15:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Sep 2009 13:15:09 +0000 Subject: [M3devel] some data on Juno crash on Win32 Message-ID: summary: 5.7.0 and 5.7.1 of unknown date: both always fail 5.7.0 always fails an assert (various?) 5.7.1 sometimes fails an assert (various) 5.7.1 sometimes access violates, always on address 00200000, plus or minus 4. Current source always access violates, same address. Since 5.7.1 and current source always access violate (aka SIGSEGV) on the same location, every run, I'm more inclined to look at this. And then hope everything else is "the same" problem. But of course there might be multiple problems. It might be good to check for the hang in various from http://www.opencm3.net/uploaded-archives/index.html. Also see what all we can get from http://www.opencm3.net/snaps/snapshot-index.html. I'm going to see if I can get the index update with the many files I noticed in the file system. longer story: 5.7.0 visual glitch and usually: visual glitch might have been the problem with import the bit set data. *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x59cf830 0xf01c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x59cf8f8 0xf0fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x59cfd54 0xf0dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x59cfdbc 0xf085be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x59cfe04 0xf06ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x59cfe30 0x7e418734 0x59cfe98 0x7e418816 0x59cfef8 0x7e4189cd 0x59cff08 0x7e4196c7 0x59cff50 0xf0bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 5.7.1 no visual glitch and usually either same as above, or access violating accessing address 001ffffc or (6c4.13b8): Access violation - code c0000005 (first chance) m3core!RTCollector__Move+0x3d: 005beeb4 8b5e00 mov ebx,dword ptr [esi] ds:0023:001ffffc=???????? 0:007> r esi esi=001ffffc 0:007> k ChildEBP RetAddr WARNING: Stack unwind information not available. Following frames may be wrong. 0213e5c0 005badd1 m3core!RTCollector__Move+0x3d 0213e604 005ba6aa m3core!RTHeapMap__Walk+0x467 0213e628 005ba640 m3core!RTHeapMap__DoWalkRef+0x62 0213e654 005c0ab8 m3core!RTHeapMap__WalkRef+0x100 0213e67c 005c092c m3core!RTCollector__CleanBetween+0xdd 0213e6a8 005c0222 m3core!RTCollector__CleanPage+0x5b 0213e6fc 005bfc34 m3core!RTCollector__CollectSomeInStateZero+0x5b2 0213e710 005bf933 m3core!RTCollector__CollectSome+0x6e 0213e740 005c17cb m3core!RTCollector__CollectEnough+0x90 0213e7a0 005b7c23 m3core!RTHeapRep__AllocTraced+0xef 0213e7e4 005b74f8 m3core!RTAllocator__GetOpenArray+0x61 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3ui.dll - 0213e808 00f94c01 m3core!RTHooks__AllocateOpenArray+0x19 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3vbtkit.dll - 0213e85c 00ea330c m3ui!ScrnPixmap__NewRaw+0x16d 0213e898 00ea518b m3vbtkit!Image__InitGray+0x7f 0213e96c 00ea4b8a m3vbtkit!Image__pgm2+0x78 0213ea04 00ec2f4a m3vbtkit!Image__FromRd+0x179 0213ea48 00e93855 m3vbtkit!VBTKitResources__GetPixmap+0x9a 0213ea88 00e91058 m3vbtkit!ScrollerVBTClass__InitGraphics+0x18e *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3formsvbt.dll - 0213eac4 00e43fa2 m3vbtkit!ScrollerVBTClass__Init+0x58 0213ebf4 00e33106 m3formsvbt!FormsVBT__pTextEdit+0x9f5 don't believe that stack much, at least where the offsets are large. There are no symbols, just exports. *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 490 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x25efc5c 0x5d9eae CheckSlot + 0x28 in ..\src\thread\WIN32\ThreadWin32.m3 0x25efca0 0x5da9c8 Fork + 0x298 in ..\src\thread\WIN32\ThreadWin32.m3 0x25efcf0 0xf9240d Mark + 0x383 in ..\src\vbt\VBTRep.m3 0x25efd14 0xf88076 Mark + 0x4b in ..\src\vbt\VBT.m3 0x25efd34 0xfaccfd NewShape + 0xaa in ..\src\split\HVSplit.m3 0x25efd70 0xf87dca NewShape + 0x1d3 in ..\src\vbt\VBT.m3 0x25efd88 0xf8dc63 NewShapeDefault + 0x16 in ..\src\vbt\VBTClass.m3 0x25efdc4 0xf87dca NewShape + 0x1d3 in ..\src\vbt\VBT.m3 0x25efe20 0xfbee4d SetAndAlign + 0x1d1 in ..\src\split\TextVBT.m3 0x25efe38 0xfbf836 Redisplay + 0x15 in ..\src\split\TextVBT.m3 ......... ......... ... more frames ... more commonly accessing 00200000, er, well, notice the offset: (1350.f08): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000005 edx=0060b148 esi=011b8a3c edi=0120dfcc eip=005dabcf esp=0012f964 ebp=0012f98c iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\m3core.dll - m3core!Thread__Join+0x133: 005dabcf 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> k *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\n et\modula3\cm3-std-NT386-d5.7.1\bin\juno-compiler.dll - ChildEBP RetAddr WARNING: Stack unwind information not available. Following frames may be wrong. 0012f98c 1000e2b1 m3core!Thread__Join+0x133 *** ERROR: Module load completed but symbols could not be loaded for Juno.exe 0012f9d0 0041c7e5 juno_compiler!JunoCompile__ProcDecl+0x1f5 0012fa08 0041d1cf Juno+0x1c7e5 0012fab4 0041d088 Juno+0x1d1cf 0012fae8 0043d425 Juno+0x1d088 0012fb28 0043d61e Juno+0x3d425 0012fbc8 0043df47 Juno+0x3d61e 0012fd70 0044b61e Juno+0x3df47 0012fee0 005c8d14 Juno+0x4b61e 0012ff24 005c82ec m3core!RTLinker__RunMainBody+0x25a 0012ff3c 005c8395 m3core!RTLinker__AddUnitI+0xf7 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 0012ff7c 004b0d74 Juno+0x1038 0012ffc0 7c817077 Juno+0xb0d74 0012fff0 00000000 kernel32!BaseProcessStart+0x23 *** *** runtime error: *** Thread client error: attempt to join with thread twice *** file "..\src\thread\WIN32\ThreadWin32.m3", line 708 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f954 0x5db678 Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3 0x12f98c 0x5dab36 Join + 0x9a in ..\src\thread\WIN32\ThreadWin32.m3 0x12f9d0 0x1000e2b1 ProcDecl + 0x1f5 in ..\src\JunoCompile.m3 0x12fa08 0x41c7e5 Pass2 + 0x1a5 in ..\src\Editor.m3 0x12fab4 0x41d1cf Compile2 + 0x137 in ..\src\Editor.m3 0x12fae8 0x41d088 Compile + 0x53 in ..\src\Editor.m3 0x12fb28 0x43d425 CompileEditor + 0x2c in ..\src\Juno.m3 0x12fbc8 0x43d61e CompileModule + 0x12c in ..\src\Juno.m3 0x12fd70 0x43df47 CompileModules + 0x2d3 in ..\src\Juno.m3 - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Sep 3 15:44:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 03 Sep 2009 15:44:36 +0200 Subject: [M3devel] some data on Juno crash on Win32 In-Reply-To: References: Message-ID: <20090903154436.w1aooqqaskg4scg4@mail.elegosoft.com> Quoting Jay K : > summary: 5.7.0 and 5.7.1 of unknown date: > > both always fail > > 5.7.0 always fails an assert (various?) > > 5.7.1 sometimes fails an assert (various) > > 5.7.1 sometimes access violates, always on address 00200000, plus or minus 4. > > Current source always access violates, same address. > > Since 5.7.1 and current source always access violate (aka SIGSEGV) > on the same > location, every run, I'm more inclined to look at this. This is all on Windows/NT386, isn't it? Or on POSIX platforms, too? I seem to remember that Juno always crashed on a PaintBrush operation on Windows, while the various mentor applications crashed at different points, but all relating to insufficient Trestle/Win support. On POSIX platforms both applications always ran OK AFAIR. Olaf > And then hope everything else is "the same" problem. > > But of course there might be multiple problems. > > It might be good to check for the hang in various from > http://www.opencm3.net/uploaded-archives/index.html. > > Also see what all we can get from > http://www.opencm3.net/snaps/snapshot-index.html. > > I'm going to see if I can get the index update with the many files I > noticed in the file system. The same file name pattern for all files would help here. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Sep 3 17:44:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Sep 2009 15:44:17 +0000 Subject: [M3devel] This is a pixmap? Message-ID: Does this look like a pixmap to anyone? This is the parameter to Win32 Join. PROCEDURE Join(t: T): REFANY = VAR res: REFANY; BEGIN LOCK threadMu DO IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; WHILE NOT t.completed DO Wait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; t.cond := NIL; IF perfOn THEN PerfChanged(t.id, State.dead) END; END; RETURN res; END Join; Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. t is at @ebp + here. The pointer then is 00200000 at the start of the second line of the second dump. If we can confirm this is pixmap, we can hunt more around in the gui code. 0:000> dd @ebp+8 0012f964 012ac6a8 02827bf4 02827974 02824c3c 0012f974 02829c40 02829c40 0012f98c 00000006 0012f984 011b9838 012ac6a8 0012f9fc 00000004 0012f994 10017170 000001c7 02829c40 0012f9d8 0012f9a4 0041ffea 02824c3c 02827bf4 02827974 0012f9b4 028250b8 02827974 02827904 02824dd8 0012f9c4 02824c3c 02827bf4 02824d9c 02824d9c 0012f9d4 02824dd8 0012fa8c 00420b98 028250b8 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> .lastevent Last event: ee0.13a4: Access violation - code c0000005 (first chance) debugger time: Thu Sep 3 07:43:12.390 2009 (GMT-7) 0:000> u . l1 m3core!Thread__Join+0x173: 005ebb01 8b5ffc mov ebx,dword ptr [edi-4] 0:000> r edi edi=00200000 0:000> Here is the entire bitmappy looking thing. 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> dd 012ac728 00200000 00200000 00200000 00200000 012ac738 00200000 00200000 00200000 00200000 012ac748 00200000 00200000 00200000 00200000 012ac758 00200000 00200000 00200000 00200000 012ac768 00200000 00200000 00200000 00200000 012ac778 00200000 00200000 00200000 00200000 012ac788 00200000 00200000 00200000 00200000 012ac798 00200000 00200000 00200000 00200000 0:000> 012ac7a8 00200000 00200000 00200000 00200000 012ac7b8 00200000 00200000 00200000 00200000 012ac7c8 00200000 00200000 00200000 00200000 012ac7d8 00200000 00200000 00200000 00200000 012ac7e8 00200000 00200000 00200000 00200000 012ac7f8 00200000 00200000 00200000 00200000 012ac808 00200000 00200000 00200000 00200000 012ac818 00200000 00200000 00200000 00200000 0:000> 012ac828 00200000 00200000 00200000 00200000 012ac838 00200000 00200000 00200000 00200000 012ac848 00200000 00200000 00200000 00200000 012ac858 00200000 00200000 00200000 00200000 012ac868 00200000 00200000 00200000 00200000 012ac878 00200000 00200000 00200000 00200000 012ac888 00200000 00200000 00200000 00200000 012ac898 00200000 00200000 00200000 00200000 0:000> 012ac8a8 00200000 00200000 00200000 00200000 012ac8b8 00200000 00200000 00200000 00200000 012ac8c8 00200000 00200000 00200000 00200000 012ac8d8 00200000 00200000 00200000 00200000 012ac8e8 00200000 00200000 00200000 00200000 012ac8f8 00200000 00200000 00200000 00200000 012ac908 00200000 00200000 00200000 00200000 012ac918 00200000 00200000 00200000 00200000 0:000> 012ac928 00200000 00200000 00200000 00200000 012ac938 00200000 00200000 00200000 00200000 012ac948 00200000 00200000 00200000 00200000 012ac958 00200000 00200000 00200000 00200000 012ac968 00200000 00200000 00200000 00200000 012ac978 00200000 00200000 00200000 00200000 012ac988 00200000 00200000 00200000 00200000 012ac998 00200000 00200000 00200000 00200000 0:000> 012ac9a8 00200000 00200000 00200000 00200000 012ac9b8 00200000 00200000 00200000 00200000 012ac9c8 00200000 00200000 00200000 00200000 012ac9d8 00200000 00200000 00200000 00200000 012ac9e8 00200000 00200000 00200000 00200000 012ac9f8 00200000 00200000 00200000 00200000 012aca08 00200000 00200000 00200000 00200000 012aca18 00200000 00200000 00200000 00200000 0:000> 012aca28 00200000 00200000 00200000 00200000 012aca38 00200000 00200000 00200000 00200000 012aca48 00200000 00200000 00200000 00200000 012aca58 00200000 00200000 00200000 00200000 012aca68 00200000 00200000 00200000 00200000 012aca78 00200000 00200000 00200000 00200000 012aca88 00200000 00200000 00200000 00200000 012aca98 00200000 00200000 00200000 00200000 0:000> 012acaa8 00200000 00200000 00200000 00200000 012acab8 00200000 00200000 00200000 00200000 012acac8 00200000 00200000 00200000 00200000 012acad8 00200000 00200000 00200000 00200000 012acae8 00200000 00200000 00200000 00200000 012acaf8 00200000 00200000 00200000 00200000 012acb08 00200000 00200000 00200000 00200000 012acb18 00200000 00200000 00200000 00200000 0:000> 012acb28 00200000 00200000 00200000 00200000 012acb38 00200000 00200000 00200000 00200000 012acb48 00200000 00200000 00200000 00200000 012acb58 00200000 00200000 00200000 00200000 012acb68 00200000 00200000 00200000 00200000 012acb78 00200000 00200000 00200000 00200000 012acb88 00200000 00200000 00200000 00200000 012acb98 00200000 00200000 00200000 00200000 0:000> 012acba8 00200000 00200000 00200000 00200000 012acbb8 00200000 00200000 00200000 00200000 012acbc8 00200000 00200000 00200000 00200000 012acbd8 00200000 00200000 00200000 00200000 012acbe8 00200000 00200000 00200000 00200000 012acbf8 00200000 00200000 00200000 00200000 012acc08 00200000 00200000 00200000 00200000 012acc18 00200000 00200000 00200000 00200000 0:000> 012acc28 00200000 00200000 00200000 00200000 012acc38 00200000 00200000 00200000 00200000 012acc48 00200000 00200000 00200000 00200000 012acc58 00200000 00200000 00200000 00200000 012acc68 00200000 00200000 00200000 00200000 012acc78 00200000 00200000 00200000 00200000 012acc88 00200000 00200000 00200000 00200000 012acc98 00200000 00200000 00200000 00200000 0:000> 012acca8 00200000 00200000 00200000 00200000 012accb8 00200000 00200000 00200000 00200000 012accc8 00200000 00200000 00200000 00200000 012accd8 00200000 00200000 00200000 00200000 012acce8 00200000 00200000 00200000 00200000 012accf8 00200000 00200000 00200000 00200000 012acd08 00200000 00200000 00200000 00200000 012acd18 00200000 00200000 00200000 00200000 0:000> 012acd28 00200000 00200000 00200000 00200000 012acd38 00200000 00200000 00200000 00200000 012acd48 00200000 00200000 00200000 00200000 012acd58 00200000 00200000 00200000 00200000 012acd68 00200000 00200000 00200000 00200000 012acd78 00200000 00200000 00200000 00200000 012acd88 00200000 00200000 00200000 00200000 012acd98 00200000 00200000 00200000 00200000 0:000> 012acda8 00200000 00200000 00200000 00200000 012acdb8 00200000 00200000 00200000 00200000 012acdc8 00200000 00200000 00200000 00200000 012acdd8 00200000 00200000 00200000 00200000 012acde8 00200000 00200000 00200000 00200000 012acdf8 00200000 00200000 00200000 00200000 012ace08 00200000 00200000 00200000 00200000 012ace18 00200000 00200000 00200000 00200000 0:000> 012ace28 00200000 00200000 00200000 00200000 012ace38 00200000 00200000 00200000 00200000 012ace48 00200000 00200000 00200000 00200000 012ace58 00200000 00200000 00200000 00200000 012ace68 00200000 00200000 00200000 00200000 012ace78 00200000 00200000 00200000 00200000 012ace88 00200000 00200000 00200000 00200000 012ace98 00200000 00200000 00200000 00200000 0:000> 012acea8 00200000 00200000 00200000 00200000 012aceb8 00200000 00200000 00200000 00200000 012acec8 00200000 00200000 00200000 00200000 012aced8 00200000 00200000 00200000 00200000 012acee8 00200000 00200000 00200000 00200000 012acef8 00200000 00200000 00200000 00200000 012acf08 00200000 00200000 00200000 00200000 012acf18 00200000 00200000 00200000 00200000 0:000> 012acf28 00200000 00200000 00200000 00200000 012acf38 00200000 00200000 00200000 00200000 012acf48 00200000 00200000 00200000 00200000 012acf58 00200000 00200000 00200000 00200000 012acf68 00200000 00200000 00200000 00200000 012acf78 00200000 00200000 00200000 00200000 012acf88 00200000 00200000 00200000 00200000 012acf98 00200000 00200000 00200000 00200000 0:000> 012acfa8 00200000 00200000 00200000 00200000 012acfb8 00200000 00200000 00200000 00200000 012acfc8 00200000 00200000 00200000 00200000 012acfd8 00200000 00200000 00200000 00200000 012acfe8 00200000 00200000 00200000 00200000 012acff8 00200000 00200000 00200000 00200000 012ad008 00200000 00200000 00200000 00200000 012ad018 00200000 00200000 00200000 00200000 0:000> 012ad028 00200000 00200000 00200000 00200000 012ad038 00200000 00200000 00200000 00200000 012ad048 00200000 00200000 00200000 00200000 012ad058 00200000 00200000 00200000 00200000 012ad068 00200000 00200000 00200000 00200000 012ad078 00200000 00200000 00200000 00200000 012ad088 00200000 00200000 00200000 00200000 012ad098 00200000 00200000 00200000 00200000 0:000> 012ad0a8 00200000 00200000 00200000 00200000 012ad0b8 00200000 00200000 00200000 00200000 012ad0c8 00200000 00200000 00200000 00200000 012ad0d8 00200000 00200000 00200000 00200000 012ad0e8 00200000 00200000 00200000 00200000 012ad0f8 00200000 00200000 00200000 00200000 012ad108 00200000 00200000 00200000 00200000 012ad118 00200000 00200000 00200000 00200000 0:000> 012ad128 00200000 00200000 00200000 00200000 012ad138 00200000 00200000 00200000 00200000 012ad148 00200000 00200000 00200000 00200000 012ad158 00200000 00200000 00200000 00200000 012ad168 00200000 00200000 00200000 00200000 012ad178 00200000 00200000 00200000 00200000 012ad188 00200000 00200000 00200000 00200000 012ad198 00200000 00200000 00200000 00200000 0:000> 012ad1a8 00200000 00200000 00200000 00200000 012ad1b8 00200000 00200000 00200000 00200000 012ad1c8 00200000 00200000 00200000 00200000 012ad1d8 00200000 00200000 00200000 00200000 012ad1e8 00200000 00200000 00200000 00200000 012ad1f8 00200000 00200000 00200000 00200000 012ad208 00200000 00200000 00200000 00200000 012ad218 00200000 00200000 00200000 00200000 0:000> 012ad228 00200000 00200000 00200000 00200000 012ad238 00200000 00200000 00200000 00200000 012ad248 00200000 00200000 00200000 00200000 012ad258 00200000 00200000 00200000 00200000 012ad268 00200000 00200000 00200000 00200000 012ad278 00200000 00200000 00200000 00200000 012ad288 00200000 00200000 00200000 00200000 012ad298 00200000 00200000 00200000 00200000 0:000> 012ad2a8 00200000 00200000 00200000 00200000 012ad2b8 00200000 00200000 00200000 00200000 012ad2c8 00200000 00200000 00200000 00200000 012ad2d8 00200000 00200000 00200000 00200000 012ad2e8 00200000 00200000 00200000 00200000 012ad2f8 00200000 00200000 00200000 00200000 012ad308 00200000 00200000 00200000 00200000 012ad318 00200000 00200000 00200000 00200000 0:000> 012ad328 00200000 00200000 00200000 00200000 012ad338 00200000 00200000 00200000 00200000 012ad348 00200000 00200000 00200000 00200000 012ad358 00200000 00200000 00200000 00200000 012ad368 00200000 00200000 00200000 00200000 012ad378 00200000 00200000 00200000 00200000 012ad388 00200000 00200000 00200000 00200000 012ad398 00200000 00200000 00200000 00200000 0:000> 012ad3a8 00200000 00200000 00200000 00200000 012ad3b8 00200000 00200000 00200000 00200000 012ad3c8 00200000 00200000 00200000 00200000 012ad3d8 00200000 00200000 00200000 00200000 012ad3e8 00200000 00200000 00200000 00200000 012ad3f8 00200000 00200000 00200000 00200000 012ad408 00200000 00200000 00200000 00200000 012ad418 00200000 00200000 00200000 00200000 0:000> 012ad428 00200000 00200000 00200000 00200000 012ad438 00200000 00200000 00200000 00200000 012ad448 00200000 00200000 00200000 00200000 012ad458 00200000 00200000 00200000 00200000 012ad468 00200000 00200000 00200000 00200000 012ad478 00200000 00200000 00200000 00200000 012ad488 00200000 00200000 00200000 00200000 012ad498 00200000 00200000 00200000 00200000 0:000> 012ad4a8 00200000 00200000 00200000 00200000 012ad4b8 00200000 00200000 00200000 00200000 012ad4c8 00200000 00200000 00200000 00200000 012ad4d8 00200000 00200000 00200000 00200000 012ad4e8 00200000 00200000 00200000 00200000 012ad4f8 00200000 00200000 00200000 00200000 012ad508 00200000 00200000 00200000 00200000 012ad518 00200000 00200000 00200000 00200000 0:000> 012ad528 00200000 00200000 00200000 00200000 012ad538 00200000 00200000 00200000 00200000 012ad548 00200000 00200000 00200000 00200000 012ad558 00200000 00200000 00200000 00200000 012ad568 00200000 00200000 00200000 00200000 012ad578 00200000 00200000 00200000 00200000 012ad588 00200000 00200000 00200000 00200000 012ad598 00200000 00200000 00200000 00200000 0:000> 012ad5a8 00200000 00200000 00200000 00200000 012ad5b8 00200000 00200000 00200000 00200000 012ad5c8 00200000 00200000 00200000 00200000 012ad5d8 00200000 00200000 00200000 00200000 012ad5e8 00200000 00200000 00200000 00200000 012ad5f8 00200000 00200000 00200000 00200000 012ad608 00200000 00200000 00200000 00200000 012ad618 00200000 00200000 00200000 00200000 0:000> 012ad628 00200000 00200000 00200000 00200000 012ad638 00200000 00200000 00200000 00200000 012ad648 00200000 00200000 00200000 00200000 012ad658 00200000 00200000 00200000 00200000 012ad668 00200000 00200000 00200000 00200000 012ad678 00200000 00200000 00200000 00200000 012ad688 00200000 00200000 00200000 00200000 012ad698 00200000 00200000 00200000 00200000 0:000> 012ad6a8 00200000 00200000 00200000 00200000 012ad6b8 00200000 00200000 00200000 00200000 012ad6c8 00200000 00200000 00200000 00200000 012ad6d8 00200000 00200000 00200000 00200000 012ad6e8 00200000 00200000 00200000 00200000 012ad6f8 00200000 00200000 00200000 00200000 012ad708 00200000 00200000 00200000 00200000 012ad718 00200000 00200000 00200000 00200000 0:000> 012ad728 00200000 00200000 00200000 00200000 012ad738 00200000 00200000 00200000 00200000 012ad748 00200000 00200000 00200000 00200000 012ad758 00200000 00200000 00200000 00200000 012ad768 00200000 00200000 00200000 00200000 012ad778 00200000 00200000 00200000 00200000 012ad788 00200000 00200000 00200000 00200000 012ad798 00200000 00200000 00200000 00200000 0:000> 012ad7a8 00200000 00200000 00200000 00200000 012ad7b8 00200000 00200000 00200000 00200000 012ad7c8 00200000 00200000 00200000 00200000 012ad7d8 00200000 00200000 00200000 00200000 012ad7e8 00200000 00200000 00200000 00200000 012ad7f8 00200000 00200000 00200000 00200000 012ad808 00200000 00200000 00200000 00200000 012ad818 00200000 00200000 00200000 00200000 0:000> 012ad828 00200000 00200000 00200000 00200000 012ad838 00200000 00200000 00200000 00200000 012ad848 00200000 00200000 00200000 00200000 012ad858 00200000 00200000 00200000 00200000 012ad868 00200000 00200000 00200000 00200000 012ad878 00200000 00200000 00200000 00200000 012ad888 00200000 00200000 00200000 00200000 012ad898 00200000 00200000 00200000 00200000 0:000> 012ad8a8 00200000 00200000 00200000 00200000 012ad8b8 00200000 00200000 00200000 00200000 012ad8c8 00200000 00200000 00200000 00200000 012ad8d8 00200000 00200000 00200000 00200000 012ad8e8 00200000 00200000 00200000 00200000 012ad8f8 00200000 00200000 00200000 00200000 012ad908 00200000 00200000 00200000 00200000 012ad918 00200000 00200000 00200000 00200000 0:000> 012ad928 00200000 00200000 00200000 00200000 012ad938 00200000 00200000 00200000 00200000 012ad948 00200000 00200000 00200000 00200000 012ad958 00200000 00200000 00200000 00200000 012ad968 00200000 00200000 00200000 00200000 012ad978 00200000 00200000 00200000 00200000 012ad988 00200000 00200000 00200000 00200000 012ad998 00200000 00200000 00200000 00200000 0:000> 012ad9a8 00200000 00200000 00200000 00200000 012ad9b8 00200000 00200000 00200000 00200000 012ad9c8 00200000 00200000 00200000 00200000 012ad9d8 00200000 00200000 00200000 00200000 012ad9e8 00200000 00200000 00200000 00200000 012ad9f8 00200000 00200000 00200000 00200000 012ada08 00200000 00200000 00200000 00200000 012ada18 00200000 00200000 00200000 00200000 0:000> 012ada28 00200000 00200000 00200000 00200000 012ada38 00200000 00200000 00200000 00200000 012ada48 00200000 00200000 00200000 00200000 012ada58 00200000 00200000 00200000 00200000 012ada68 00200000 00200000 00200000 00200000 012ada78 00200000 00200000 00200000 00200000 012ada88 00200000 00200000 00200000 00200000 012ada98 00200000 00200000 00200000 00200000 0:000> 012adaa8 00200000 00200000 00200000 00200000 012adab8 00200000 00200000 00200000 00200000 012adac8 00200000 00200000 00200000 00200000 012adad8 00200000 00200000 00200000 00200000 012adae8 00200000 00200000 00200000 00200000 012adaf8 00200000 00200000 00200000 00200000 012adb08 00200000 00200000 00200000 00200000 012adb18 00200000 00200000 00200000 00200000 0:000> 012adb28 00200000 00200000 00200000 00200000 012adb38 00200000 00200000 00200000 00200000 012adb48 00200000 00200000 00200000 00200000 012adb58 00200000 00200000 00200000 00200000 012adb68 00200000 00200000 00200000 00200000 012adb78 00200000 00200000 00200000 00200000 012adb88 00200000 00200000 00200000 00200000 012adb98 00200000 00200000 00200000 00200000 0:000> 012adba8 00200000 00200000 00200000 00200000 012adbb8 00200000 00200000 00200000 00200000 012adbc8 00200000 00200000 00200000 00200000 012adbd8 00200000 00200000 00200000 00200000 012adbe8 00200000 00200000 00200000 00200000 012adbf8 00200000 00200000 00200000 00200000 012adc08 00200000 00200000 00200000 00200000 012adc18 00200000 00200000 00200000 00200000 0:000> 012adc28 00200000 00200000 00200000 00200000 012adc38 00200000 00200000 00200000 00200000 012adc48 00200000 00200000 00200000 00200000 012adc58 00200000 00200000 00200000 00200000 012adc68 00200000 00200000 00200000 00200000 012adc78 00200000 00200000 00200000 00200000 012adc88 00200000 00200000 00200000 00200000 012adc98 00200000 00200000 00200000 00200000 0:000> 012adca8 00200000 00200000 00200000 00200000 012adcb8 00200000 00200000 00200000 00200000 012adcc8 00200000 00200000 00200000 00200000 012adcd8 00200000 00200000 00200000 00200000 012adce8 00200000 00200000 00200000 00200000 012adcf8 00200000 00200000 00200000 00200000 012add08 00200000 00200000 00200000 00200000 012add18 00200000 00200000 00200000 00200000 0:000> 012add28 00200000 00200000 00200000 00200000 012add38 00200000 00200000 00200000 00200000 012add48 00200000 00200000 00200000 00200000 012add58 00200000 00200000 00200000 00200000 012add68 00200000 00200000 00200000 00200000 012add78 00200000 00200000 00200000 00200000 012add88 00200000 00200000 00200000 00200000 012add98 00200000 00200000 00200000 00200000 0:000> 012adda8 00200000 00200000 00200000 00200000 012addb8 00200000 00200000 00200000 00200000 012addc8 00200000 00200000 00200000 00200000 012addd8 00200000 00200000 00200000 00200000 012adde8 00200000 00200000 00200000 00200000 012addf8 00200000 00200000 00200000 00200000 012ade08 00200000 00200000 00200000 00200000 012ade18 00200000 00200000 00200000 00200000 0:000> 012ade28 00200000 00200000 00200000 00200000 012ade38 00200000 00200000 00200000 00200000 012ade48 00200000 00200000 00200000 00200000 012ade58 00200000 00200000 00200000 00200000 012ade68 00200000 00200000 00200000 00200000 012ade78 00200000 00200000 00200000 00200000 012ade88 00200000 00200000 00200000 00200000 012ade98 00200000 00200000 00200000 00200000 0:000> 012adea8 00200000 00200000 00200000 00200000 012adeb8 00200000 00200000 00200000 00200000 012adec8 00200000 00200000 00200000 00200000 012aded8 00200000 00200000 00200000 00200000 012adee8 00200000 00200000 00200000 00200000 012adef8 00200000 00200000 00200000 00200000 012adf08 00200000 00200000 00200000 00200000 012adf18 00200000 00200000 00200000 00200000 0:000> 012adf28 00200000 00200000 00200000 00200000 012adf38 00200000 00200000 00200000 00200000 012adf48 00200000 00200000 00200000 00200000 012adf58 00200000 00200000 00200000 00200000 012adf68 00200000 00200000 00200000 00200000 012adf78 00200000 00200000 00200000 00200000 012adf88 00200000 00200000 00200000 00200000 012adf98 00200000 00200000 00200000 00200000 0:000> 012adfa8 00200000 00200000 00200000 00200000 012adfb8 00200000 00200000 00200000 00200000 012adfc8 00200000 00200000 00200000 00200000 012adfd8 00200000 00200000 00200000 00200000 012adfe8 00200000 00200000 00200000 00200000 012adff8 00200000 00200000 00200000 00200000 012ae008 00200000 00200000 00200000 00200000 012ae018 00200000 00200000 00200000 00200000 0:000> 012ae028 00200000 00200000 00200000 00200000 012ae038 00200000 00200000 00200000 00200000 012ae048 00200000 00200000 00200000 00200000 012ae058 00200000 00200000 00200000 00200000 012ae068 00200000 00200000 00200000 00200000 012ae078 00200000 00200000 00200000 00200000 012ae088 00200000 00200000 00200000 00200000 012ae098 00200000 00200000 00200000 00200000 0:000> 012ae0a8 00200000 00200000 00200000 00200000 012ae0b8 00200000 00200000 00200000 00200000 012ae0c8 00200000 00200000 00200000 00200000 012ae0d8 00200000 00200000 00200000 00200000 012ae0e8 00200000 00200000 00200000 00200000 012ae0f8 00200000 00200000 00200000 00200000 012ae108 00200000 00200000 00200000 00200000 012ae118 00200000 00200000 00200000 00200000 0:000> 012ae128 00200000 00200000 00200000 00200000 012ae138 00200000 00200000 00200000 00200000 012ae148 00200000 00200000 00200000 00200000 012ae158 00200000 00200000 00200000 00200000 012ae168 00200000 00200000 00200000 00200000 012ae178 00200000 00200000 00200000 00200000 012ae188 00200000 00200000 00200000 00200000 012ae198 00200000 00200000 00200000 00200000 0:000> 012ae1a8 00200000 00200000 00200000 00200000 012ae1b8 00200000 00200000 00200000 00200000 012ae1c8 00200000 00200000 00200000 00200000 012ae1d8 00200000 00200000 00200000 00200000 012ae1e8 00200000 00200000 00200000 00200000 012ae1f8 00200000 00200000 00200000 00200000 012ae208 00200000 00200000 00200000 00200000 012ae218 00200000 00200000 00200000 00200000 0:000> 012ae228 00200000 00200000 00200000 00200000 012ae238 00200000 00200000 00200000 00200000 012ae248 00200000 00200000 00200000 00200000 012ae258 00200000 00200000 00200000 00200000 012ae268 00200000 00200000 00200000 00200000 012ae278 00200000 00200000 00200000 00200000 012ae288 00200000 00200000 00200000 00200000 012ae298 00200000 00200000 00200000 00200000 0:000> 012ae2a8 00200000 00200000 00200000 00200000 012ae2b8 00200000 00200000 00200000 00200000 012ae2c8 00200000 00200000 00200000 00200000 012ae2d8 00200000 00200000 00200000 00200000 012ae2e8 00200000 00200000 00200000 00200000 012ae2f8 00200000 00200000 00200000 00200000 012ae308 00200000 00200000 00200000 00200000 012ae318 00200000 00200000 00200000 00200000 0:000> 012ae328 00200000 00200000 00200000 00200000 012ae338 00200000 00200000 00200000 00200000 012ae348 00200000 00200000 00200000 00200000 012ae358 00200000 00200000 00200000 00200000 012ae368 00200000 00200000 00200000 00200000 012ae378 00200000 00200000 00200000 00200000 012ae388 00200000 00200000 00200000 00200000 012ae398 00200000 00200000 00200000 00200000 0:000> 012ae3a8 00200000 00200000 00200000 00200000 012ae3b8 00200000 00200000 00200000 00200000 012ae3c8 00200000 00200000 00200000 00200000 012ae3d8 00200000 00200000 00200000 00200000 012ae3e8 00200000 00200000 00200000 00200000 012ae3f8 00200000 00200000 00200000 00200000 012ae408 00200000 00200000 00200000 00200000 012ae418 00200000 00200000 00200000 00200000 0:000> 012ae428 00200000 00200000 00200000 00200000 012ae438 00200000 00200000 00200000 00200000 012ae448 00200000 00200000 00200000 00200000 012ae458 00200000 00200000 00200000 00200000 012ae468 00200000 00200000 00200000 00200000 012ae478 00200000 00200000 00200000 00200000 012ae488 00200000 00200000 00200000 00200000 012ae498 00200000 00200000 00200000 00200000 0:000> 012ae4a8 00200000 00200000 00200000 00200000 012ae4b8 00200000 00200000 00200000 00200000 012ae4c8 00200000 00200000 00200000 00200000 012ae4d8 00200000 00200000 00200000 00200000 012ae4e8 00200000 00200000 00200000 00200000 012ae4f8 00200000 00200000 00200000 00200000 012ae508 00200000 00200000 00200000 00200000 012ae518 00200000 00200000 00200000 00200000 0:000> 012ae528 00200000 00200000 00200000 00200000 012ae538 00200000 00200000 00200000 00200000 012ae548 00200000 00200000 00200000 00200000 012ae558 00200000 00200000 00200000 00200000 012ae568 00200000 00200000 00200000 00200000 012ae578 00200000 00200000 00200000 00200000 012ae588 00200000 00200000 00200000 00200000 012ae598 00200000 00200000 00200000 00200000 0:000> 012ae5a8 00200000 00200000 00200000 00200000 012ae5b8 00200000 00200000 00200000 00200000 012ae5c8 00200000 00200000 00200000 00200000 012ae5d8 00200000 00200000 00200000 00200000 012ae5e8 00200000 00200000 00200000 00200000 012ae5f8 00200000 00200000 00200000 00200000 012ae608 00200000 00200000 00200000 00200000 012ae618 00200000 00200000 00200000 00200000 0:000> 012ae628 00200000 00200000 00200000 00200000 012ae638 00200000 00200000 00200000 00200000 012ae648 00200000 00200000 00200000 00200000 012ae658 00200000 00200000 00200000 00200000 012ae668 00200000 00200000 00200000 00200000 012ae678 00200000 00200000 00200000 00200000 012ae688 00200000 00200000 00200000 00200000 012ae698 00200000 00200000 00200000 00200000 0:000> 012ae6a8 00200000 00200000 00200000 00200000 012ae6b8 00200000 00200000 00200000 00200000 012ae6c8 00200000 00200000 00200000 00200000 012ae6d8 00200000 00200000 00200000 00200000 012ae6e8 00200000 00200000 00200000 00200000 012ae6f8 00200000 00200000 00200000 00200000 012ae708 00200000 00200000 00200000 00200000 012ae718 00200000 00200000 00200000 00200000 0:000> 012ae728 00200000 00200000 00200000 00200000 012ae738 00200000 00200000 00200000 00200000 012ae748 00200000 00200000 00200000 00200000 012ae758 00200000 00200000 00200000 00200000 012ae768 00200000 00200000 00200000 00200000 012ae778 00200000 00200000 00200000 00200000 012ae788 00200000 00200000 00200000 00200000 012ae798 00200000 00200000 00200000 00200000 0:000> 012ae7a8 00200000 00200000 00200000 00200000 012ae7b8 00200000 00200000 00200000 00200000 012ae7c8 00200000 00200000 00200000 00200000 012ae7d8 00200000 00200000 00200000 00200000 012ae7e8 00200000 00200000 00200000 00200000 012ae7f8 00200000 00200000 00200000 00200000 012ae808 00200000 00200000 00200000 00200000 012ae818 00200000 00200000 00200000 00200000 0:000> 012ae828 00200000 00200000 00200000 00200000 012ae838 00200000 00200000 00200000 00200000 012ae848 00200000 00200000 00200000 00200000 012ae858 00200000 00200000 00200000 00200000 012ae868 00200000 00200000 00200000 00200000 012ae878 00200000 00200000 00200000 00200000 012ae888 00200000 00200000 00200000 00200000 012ae898 00200000 00200000 00200000 00200000 0:000> 012ae8a8 00200000 00200000 00200000 00200000 012ae8b8 00200000 00200000 00200000 00200000 012ae8c8 00200000 00200000 00200000 00200000 012ae8d8 00200000 00200000 00200000 00200000 012ae8e8 00200000 00200000 00200000 00200000 012ae8f8 00200000 00200000 00200000 00200000 012ae908 00200000 00200000 00200000 00200000 012ae918 00200000 00200000 00200000 00200000 0:000> 012ae928 00200000 00200000 00200000 00200000 012ae938 00200000 00200000 00200000 00200000 012ae948 00200000 00200000 00200000 00200000 012ae958 00200000 00200000 00200000 00200000 012ae968 00200000 00200000 00200000 00200000 012ae978 00200000 00200000 00200000 00200000 012ae988 00200000 00200000 00200000 00200000 012ae998 00200000 00200000 00200000 00200000 0:000> 012ae9a8 00200000 00200000 00200000 00200000 012ae9b8 00200000 00200000 00200000 00200000 012ae9c8 00200000 00200000 00200000 00200000 012ae9d8 00200000 00200000 00200000 00200000 012ae9e8 00200000 00200000 00200000 00200000 012ae9f8 00200000 00200000 00200000 00200000 012aea08 00200000 00200000 00200000 00200000 012aea18 00200000 00200000 00200000 00200000 0:000> 012aea28 00200000 00200000 00200000 00200000 012aea38 00200000 00200000 00200000 00200000 012aea48 00200000 00200000 00200000 00200000 012aea58 00200000 00200000 00200000 00200000 012aea68 00200000 00200000 00200000 00200000 012aea78 00200000 00200000 00200000 00200000 012aea88 00200000 00200000 00200000 00200000 012aea98 00200000 00200000 00200000 00200000 0:000> 012aeaa8 00200000 00200000 00200000 00200000 012aeab8 00200000 00200000 00200000 00200000 012aeac8 00200000 00200000 00200000 00200000 012aead8 00200000 00200000 00200000 00200000 012aeae8 00200000 00200000 00200000 00200000 012aeaf8 00200000 00200000 00200000 00200000 012aeb08 00200000 00200000 00200000 00200000 012aeb18 00200000 00200000 00200000 00200000 0:000> 012aeb28 00200000 00200000 00200000 00200000 012aeb38 00200000 00200000 00200000 00200000 012aeb48 00200000 00200000 00200000 00200000 012aeb58 00200000 00200000 00200000 00200000 012aeb68 00200000 00200000 00200000 00200000 012aeb78 00200000 00200000 00200000 00200000 012aeb88 00200000 00200000 00200000 00200000 012aeb98 00200000 00200000 00200000 00200000 0:000> 012aeba8 00200000 00200000 00200000 00200000 012aebb8 00200000 00200000 00200000 00200000 012aebc8 00200000 00200000 00200000 00200000 012aebd8 00200000 00200000 00200000 00200000 012aebe8 00200000 00200000 00200000 00200000 012aebf8 00200000 00200000 00200000 00200000 012aec08 00200000 00200000 00200000 00200000 012aec18 00200000 00200000 00200000 00200000 0:000> 012aec28 00200000 00200000 00200000 00200000 012aec38 00200000 00200000 00200000 00200000 012aec48 00200000 00200000 00200000 00200000 012aec58 00200000 00200000 00200000 00200000 012aec68 00200000 00200000 00200000 00200000 012aec78 00200000 00200000 00200000 00200000 012aec88 00200000 00200000 00200000 00200000 012aec98 00200000 00200000 00200000 00200000 0:000> 012aeca8 00200000 00200000 00200000 00200000 012aecb8 00200000 00200000 00200000 00200000 012aecc8 00200000 00200000 00200000 00200000 012aecd8 00200000 00200000 00200000 00200000 012aece8 00200000 00200000 00200000 00200000 012aecf8 00200000 00200000 00200000 00200000 012aed08 00200000 00200000 00200000 00200000 012aed18 00200000 00200000 00200000 00200000 0:000> 012aed28 00200000 00200000 00200000 00200000 012aed38 00200000 00200000 00200000 00200000 012aed48 00200000 00200000 00200000 00200000 012aed58 00200000 00200000 00200000 00200000 012aed68 00200000 00200000 00200000 00200000 012aed78 00200000 00200000 00200000 00200000 012aed88 00200000 00200000 00200000 00200000 012aed98 00200000 00200000 00200000 00200000 0:000> 012aeda8 00200000 00200000 00200000 00200000 012aedb8 00200000 00200000 00200000 00200000 012aedc8 00200000 00200000 00200000 00200000 012aedd8 00200000 00200000 00200000 00200000 012aede8 00200000 00200000 00200000 00200000 012aedf8 00200000 00200000 00200000 00200000 012aee08 00200000 00200000 00200000 00200000 012aee18 00200000 00200000 00200000 00200000 0:000> 012aee28 00200000 00200000 00200000 00200000 012aee38 00200000 00200000 00200000 00200000 012aee48 00200000 00200000 00200000 00200000 012aee58 00200000 00200000 00200000 00200000 012aee68 00200000 00200000 00200000 00200000 012aee78 00200000 00200000 00200000 00200000 012aee88 00200000 00200000 00200000 00200000 012aee98 00200000 00200000 00200000 00200000 0:000> 012aeea8 00200000 00200000 00200000 00200000 012aeeb8 00200000 00200000 00200000 00200000 012aeec8 00200000 00200000 00200000 00200000 012aeed8 00200000 00200000 00200000 00200000 012aeee8 00200000 00200000 00200000 00200000 012aeef8 00200000 00200000 00200000 00200000 012aef08 00200000 00200000 00200000 00200000 012aef18 00200000 00200000 00200000 00200000 0:000> 012aef28 00200000 00200000 00200000 00200000 012aef38 00200000 00200000 00200000 00200000 012aef48 00200000 00200000 00200000 00200000 012aef58 00200000 00200000 00200000 00200000 012aef68 00200000 00200000 00200000 00200000 012aef78 00200000 00200000 00200000 00200000 012aef88 00200000 00200000 00200000 00200000 012aef98 00200000 00200000 00200000 00200000 0:000> 012aefa8 00200000 00200000 00200000 00200000 012aefb8 00200000 00200000 00200000 00200000 012aefc8 00200000 00200000 00200000 00200000 012aefd8 00200000 00200000 00200000 00200000 012aefe8 00200000 00200000 00200000 00200000 012aeff8 00200000 00200000 00200000 00200000 012af008 00200000 00200000 00200000 00200000 012af018 00200000 00200000 00200000 00200000 0:000> 012af028 00200000 00200000 00200000 00200000 012af038 00200000 00200000 00200000 00200000 012af048 00200000 00200000 00200000 00200000 012af058 00200000 00200000 00200000 00200000 012af068 00200000 00200000 00200000 00200000 012af078 00200000 00200000 00200000 00200000 012af088 00200000 00200000 00200000 00200000 012af098 00200000 00200000 00200000 00200000 0:000> 012af0a8 00200000 00200000 00200000 00200000 012af0b8 00200000 00200000 00200000 00200000 012af0c8 00200000 00200000 00200000 00200000 012af0d8 00200000 00200000 00200000 00200000 012af0e8 00200000 00200000 00200000 00200000 012af0f8 00200000 00200000 00200000 00200000 012af108 00200000 00200000 00200000 00200000 012af118 00200000 00200000 00200000 00200000 0:000> 012af128 00200000 00200000 00200000 00200000 012af138 00200000 00200000 00200000 00200000 012af148 00200000 00200000 00200000 00200000 012af158 00200000 00200000 00200000 00200000 012af168 00200000 00200000 00200000 00200000 012af178 00200000 00200000 00200000 00200000 012af188 00200000 00200000 00200000 00200000 012af198 00200000 00200000 00200000 00200000 0:000> 012af1a8 00200000 00200000 00200000 00200000 012af1b8 00200000 00200000 00200000 00200000 012af1c8 00200000 00200000 00200000 00200000 012af1d8 00200000 00200000 00200000 00200000 012af1e8 00200000 00200000 00200000 00200000 012af1f8 00200000 00200000 00200000 00200000 012af208 00200000 00200000 00200000 00200000 012af218 00200000 00200000 00200000 00200000 0:000> 012af228 00200000 00200000 00200000 00200000 012af238 00200000 00200000 00200000 00200000 012af248 00200000 00200000 00200000 00200000 012af258 00200000 00200000 00200000 00200000 012af268 00200000 00200000 00200000 00200000 012af278 00200000 00200000 00200000 00200000 012af288 00200000 00200000 00200000 00200000 012af298 00200000 00200000 00200000 00200000 0:000> 012af2a8 00200000 00200000 00200000 00200000 012af2b8 00200000 00200000 00200000 00200000 012af2c8 00200000 00200000 00200000 00200000 012af2d8 00200000 00200000 00200000 00200000 012af2e8 00200000 00200000 00200000 00200000 012af2f8 00200000 00200000 00200000 00200000 012af308 00200000 00200000 00200000 00200000 012af318 00200000 00200000 00200000 00200000 0:000> 012af328 00200000 00200000 00200000 00200000 012af338 00200000 00200000 00200000 00200000 012af348 00200000 00200000 00200000 00200000 012af358 00200000 00200000 00200000 00200000 012af368 00200000 00200000 00200000 00200000 012af378 00200000 00200000 00200000 00200000 012af388 00200000 00200000 00200000 00200000 012af398 00200000 00200000 00200000 00200000 0:000> 012af3a8 00200000 00200000 00200000 00200000 012af3b8 00200000 00200000 00200000 00200000 012af3c8 00200000 00200000 00200000 00200000 012af3d8 00200000 00200000 00200000 00200000 012af3e8 00200000 00200000 00200000 00200000 012af3f8 00200000 00200000 00200000 00200000 012af408 00200000 00200000 00200000 00200000 012af418 00200000 00200000 00200000 00200000 0:000> 012af428 00200000 00200000 00200000 00200000 012af438 00200000 00200000 00200000 00200000 012af448 00200000 00200000 00200000 00200000 012af458 00200000 00200000 00200000 00200000 012af468 00200000 00200000 00200000 00200000 012af478 00200000 00200000 00200000 00200000 012af488 00200000 00200000 00200000 00200000 012af498 00200000 00200000 00200000 00200000 0:000> 012af4a8 00200000 00200000 00200000 00200000 012af4b8 00200000 00200000 00200000 00200000 012af4c8 00200000 00200000 00200000 00200000 012af4d8 00200000 00200000 00200000 00200000 012af4e8 00200000 00200000 00200000 00200000 012af4f8 00200000 00200000 00200000 00200000 012af508 00200000 00200000 00200000 00200000 012af518 00200000 00200000 00200000 00200000 0:000> 012af528 00200000 00200000 00200000 00200000 012af538 00200000 00200000 00200000 00200000 012af548 00200000 00200000 00200000 00200000 012af558 00200000 00200000 00200000 00200000 012af568 00200000 00200000 00200000 00200000 012af578 00200000 00200000 00200000 00200000 012af588 00200000 00200000 00200000 00200000 012af598 00200000 00200000 00200000 00200000 0:000> 012af5a8 00200000 00200000 00200000 00200000 012af5b8 00200000 00200000 00200000 00200000 012af5c8 00200000 00200000 00200000 00200000 012af5d8 00200000 00200000 00200000 00200000 012af5e8 00200000 00200000 00200000 00200000 012af5f8 00200000 00200000 00200000 00200000 012af608 00200000 00200000 00200000 00200000 012af618 00200000 00200000 00200000 00200000 0:000> 012af628 00200000 00200000 00200000 00200000 012af638 00200000 00200000 00200000 00200000 012af648 00200000 00200000 00200000 00200000 012af658 00200000 00200000 00200000 00200000 012af668 00200000 00200000 00200000 00200000 012af678 00200000 00200000 00200000 00200000 012af688 00200000 00200000 00200000 00200000 012af698 00200000 00200000 00200000 00200000 0:000> 012af6a8 00200000 00200000 00200000 00200000 012af6b8 00200000 00200000 00200000 00200000 012af6c8 00200000 00200000 00200000 00200000 012af6d8 00200000 00200000 00200000 00200000 012af6e8 00200000 00200000 00200000 00200000 012af6f8 00200000 00200000 00200000 00200000 012af708 00200000 00200000 00200000 00200000 012af718 00200000 00200000 00200000 00200000 0:000> 012af728 00200000 00200000 00200000 00200000 012af738 00200000 00200000 00200000 00200000 012af748 00200000 00200000 00200000 00200000 012af758 00200000 00200000 00200000 00200000 012af768 00200000 00200000 00200000 00200000 012af778 00200000 00200000 00200000 00200000 012af788 00200000 00200000 00200000 00200000 012af798 00200000 00200000 00200000 00200000 0:000> 012af7a8 00200000 00200000 00200000 00200000 012af7b8 00200000 00200000 00200000 00200000 012af7c8 00200000 00200000 00200000 00200000 012af7d8 00200000 00200000 00200000 00200000 012af7e8 00200000 00200000 00200000 00200000 012af7f8 00200000 00200000 00200000 00200000 012af808 00200000 00200000 00200000 00200000 012af818 00200000 00200000 00200000 00200000 0:000> 012af828 00200000 00200000 00200000 00200000 012af838 00200000 00200000 00200000 00200000 012af848 00200000 00200000 00200000 00200000 012af858 00200000 00200000 00200000 00200000 012af868 00200000 00200000 00200000 00200000 012af878 00200000 00200000 00200000 00200000 012af888 00200000 00200000 00200000 00200000 012af898 00200000 00200000 00200000 00200000 0:000> 012af8a8 00200000 00200000 00200000 00200000 012af8b8 00200000 00200000 00200000 00200000 012af8c8 00200000 00200000 00200000 00200000 012af8d8 00200000 00200000 00200000 00200000 012af8e8 00200000 00200000 00200000 00200000 012af8f8 00200000 00200000 00200000 00200000 012af908 00200000 00200000 00200000 00200000 012af918 00200000 00200000 00200000 00200000 0:000> 012af928 00200000 00200000 00200000 00200000 012af938 00200000 00200000 00200000 00200000 012af948 00200000 00200000 00200000 00200000 012af958 00200000 00200000 00200000 00200000 012af968 00200000 00200000 00200000 00200000 012af978 00200000 00200000 00200000 00200000 012af988 00200000 00200000 00200000 00200000 012af998 00200000 00200000 00200000 00200000 0:000> 012af9a8 00200000 00200000 00200000 00200000 012af9b8 00200000 00200000 00200000 00200000 012af9c8 00200000 00200000 00200000 00200000 012af9d8 00200000 00200000 00200000 00200000 012af9e8 00200000 00200000 00200000 00200000 012af9f8 00200000 00200000 00200000 00200000 012afa08 00200000 00200000 00200000 00200000 012afa18 00200000 00200000 00200000 00200000 0:000> 012afa28 00200000 00200000 00200000 00200000 012afa38 00200000 00200000 00200000 00200000 012afa48 00200000 00200000 00200000 00200000 012afa58 00200000 00200000 00200000 00200000 012afa68 00200000 00200000 00200000 00200000 012afa78 00200000 00200000 00200000 00200000 012afa88 00200000 00200000 00200000 00200000 012afa98 00200000 00200000 00200000 00200000 0:000> 012afaa8 00200000 00200000 00200000 00200000 012afab8 00200000 00200000 00200000 00200000 012afac8 00200000 00200000 00200000 00200000 012afad8 00200000 00200000 00200000 00200000 012afae8 00200000 00200000 00200000 00200000 012afaf8 00200000 00200000 00200000 00200000 012afb08 00200000 00200000 00200000 00200000 012afb18 00200000 00200000 00200000 00200000 0:000> 012afb28 00200000 00200000 00200000 00200000 012afb38 00200000 00200000 00200000 00200000 012afb48 00200000 00200000 00200000 00200000 012afb58 00200000 00200000 00200000 00200000 012afb68 00200000 00200000 00200000 00200000 012afb78 00200000 00200000 00200000 00200000 012afb88 00200000 00200000 00200000 00200000 012afb98 00200000 00200000 00200000 00200000 0:000> 012afba8 00200000 00200000 00200000 00200000 012afbb8 00200000 00200000 00200000 00200000 012afbc8 00200000 00200000 00200000 00200000 012afbd8 00200000 00200000 00200000 00200000 012afbe8 00200000 00200000 00200000 00200000 012afbf8 00200000 00200000 00200000 00200000 012afc08 00200000 00200000 00200000 00200000 012afc18 00200000 00200000 00200000 00200000 0:000> 012afc28 00200000 00200000 00200000 00200000 012afc38 00200000 00200000 00200000 00200000 012afc48 00200000 00200000 00200000 00200000 012afc58 00200000 00200000 00200000 00200000 012afc68 00200000 00200000 00200000 00200000 012afc78 00200000 00200000 00200000 00200000 012afc88 00200000 00200000 00200000 00200000 012afc98 00200000 00200000 00200000 00200000 0:000> 012afca8 00200000 00200000 00200000 00200000 012afcb8 00200000 00200000 00200000 00200000 012afcc8 00200000 00200000 00200000 00200000 012afcd8 00200000 00200000 00200000 00200000 012afce8 00200000 00200000 00200000 00200000 012afcf8 00200000 00200000 00200000 00200000 012afd08 00200000 00200000 00200000 00200000 012afd18 00200000 00200000 00200000 00200000 0:000> 012afd28 00200000 00200000 00200000 00200000 012afd38 00200000 00200000 00200000 00200000 012afd48 00200000 00200000 00200000 00200000 012afd58 00200000 00200000 00200000 00200000 012afd68 00200000 00200000 00200000 00200000 012afd78 00200000 00200000 00200000 00200000 012afd88 00200000 00200000 00200000 00200000 012afd98 00200000 00200000 00200000 00200000 0:000> 012afda8 00200000 00200000 00200000 00200000 012afdb8 00200000 00200000 00200000 00200000 012afdc8 00200000 00200000 00200000 00200000 012afdd8 00200000 00200000 00200000 00200000 012afde8 00200000 00200000 00200000 00200000 012afdf8 00200000 00200000 00200000 00200000 012afe08 00200000 00200000 00200000 00200000 012afe18 00200000 00200000 00200000 00200000 0:000> 012afe28 00200000 00200000 00200000 00200000 012afe38 00200000 00200000 00200000 00200000 012afe48 00200000 00200000 00200000 00200000 012afe58 00200000 00200000 00200000 00200000 012afe68 00200000 00200000 00200000 00200000 012afe78 00200000 00200000 00200000 00200000 012afe88 00200000 00200000 00200000 00200000 012afe98 00200000 00200000 00200000 00200000 0:000> 012afea8 00200000 00200000 00200000 00200000 012afeb8 00200000 00200000 00200000 00200000 012afec8 00200000 00200000 00200000 00200000 012afed8 00200000 00200000 00200000 00200000 012afee8 00200000 00200000 00200000 00200000 012afef8 00200000 00200000 00200000 00200000 012aff08 00200000 00200000 00200000 00200000 012aff18 00200000 00200000 00200000 00200000 0:000> 012aff28 00200000 00200000 00200000 00200000 012aff38 00200000 00200000 00200000 00200000 012aff48 00200000 00200000 00200000 00200000 012aff58 00200000 00200000 00200000 00200000 012aff68 00200000 00200000 00200000 00200000 012aff78 00200000 00200000 00200000 00200000 012aff88 00200000 00200000 00200000 00200000 012aff98 00200000 00200000 00200000 00200000 0:000> 012affa8 00200000 00200000 00200000 00200000 012affb8 00200000 00200000 00200000 00200000 012affc8 00200000 00200000 00200000 00200000 012affd8 00200000 00200000 00200000 00200000 012affe8 00200000 00200000 00200000 00200000 012afff8 00200000 00200000 00000013 00000001 012b0008 00200026 012b0014 0000172e 00000000 012b0018 00000000 00000000 00000000 00000000 0:000> 012b0028 00000000 00000000 00000000 00000000 012b0038 00000000 00000000 00000000 00000000 012b0048 00000000 00000000 00000000 00000000 012b0058 00000000 00000000 00000000 00000000 012b0068 00000000 00000000 00000000 00000000 012b0078 00000000 00000000 00000000 00000000 012b0088 00000000 00000000 00000000 00000000 012b0098 00000000 00000000 00000000 00000000 0:000> 012b00a8 00000000 00000000 00000000 00000000 012b00b8 00000000 00000000 00000000 00000000 012b00c8 00000000 00000000 00000000 00000000 012b00d8 00000000 00000000 00000000 00000000 012b00e8 00000000 00000000 00000000 00000000 012b00f8 00000000 00000000 00000000 00000000 012b0108 00000000 00000000 00000000 00000000 012b0118 00000000 00000000 00000000 00000000 0:000> 012b0128 00000000 00000000 00000000 00000000 012b0138 00000000 00000000 00000000 00000000 012b0148 00000000 00000000 00000000 00000000 012b0158 00000000 00000000 00000000 00000000 012b0168 00000000 00000000 00000000 00000000 012b0178 00000000 00000000 00000000 00000000 012b0188 00000000 00000000 00000000 00000000 012b0198 00000000 00000000 00000000 00000000 0:000> 012b01a8 00000000 00000000 00000000 00000000 012b01b8 00000000 00000000 00000000 00000000 012b01c8 00000000 00000000 00000000 00000000 012b01d8 00000000 00000000 00000000 00000000 012b01e8 00000000 00000000 00000000 00000000 012b01f8 00000000 00000000 00000000 00000000 012b0208 00000000 00000000 00000000 00000000 012b0218 00000000 00000000 00000000 00000000 0:000> 012b0228 00000000 00000000 00000000 00000000 012b0238 00000000 00000000 00000000 00000000 012b0248 00000000 00000000 00000000 00000000 012b0258 00000000 00000000 00000000 00000000 012b0268 00000000 00000000 00000000 00000000 012b0278 00000000 00000000 00000000 00000000 012b0288 00000000 00000000 00000000 00000000 012b0298 00000000 00000000 00000000 00000000 0:000> 012b02a8 00000000 00000000 00000000 00000000 012b02b8 00000000 00000000 00000000 00000000 012b02c8 00000000 00000000 00000000 00000000 012b02d8 00000000 00000000 00000000 00000000 012b02e8 00000000 00000000 00000000 00000000 012b02f8 00000000 00000000 00000000 00000000 012b0308 00000000 00000000 00000000 00000000 012b0318 00000000 00000000 00000000 00000000 0:000> 012b0328 00000000 00000000 00000000 00000000 012b0338 00000000 00000000 00000000 00000000 012b0348 00000000 00000000 55000000 55005500 012b0358 55005500 55005500 55005500 55005500 012b0368 55005500 55005500 55005500 55005500 012b0378 55005500 55005500 55005500 55005500 012b0388 55005500 55005500 55005500 55005500 012b0398 55005500 55005500 55005500 55005500 0:000> 012b03a8 55005500 55005500 55005500 55005500 012b03b8 55005500 55005500 55005500 55005500 012b03c8 55005500 55005500 55005500 55005500 012b03d8 55005500 55005500 55005500 55005500 012b03e8 55005500 55005500 55005500 55005500 012b03f8 55005500 55005500 55005500 55005500 012b0408 55005500 55005500 55005500 55005500 012b0418 55005500 55005500 55005500 55005500 0:000> 012b0428 55005500 55005500 55005500 55005500 012b0438 55005500 55005500 55005500 55005500 012b0448 55005500 55005500 55005500 55005500 012b0458 55005500 55005500 00000000 55000000 012b0468 55000055 55000055 55000055 55000055 012b0478 55000055 55000055 55000055 55000055 012b0488 55000055 55000055 55000055 55000055 012b0498 55000055 55000055 55000055 55000055 0:000> 012b04a8 55000055 55000055 55000055 55000055 012b04b8 55000055 55000055 55000055 55000055 012b04c8 55000055 55000055 55000055 55000055 012b04d8 55000055 55000055 55000055 55000055 012b04e8 55000055 55000055 55000055 55000055 012b04f8 55000055 55000055 55000055 55000055 012b0508 55000055 55000055 55000055 55000055 012b0518 55000055 55000055 55000055 55000055 0:000> 012b0528 55000055 55000055 55000055 55000055 012b0538 55000055 55000055 55000055 55000055 012b0548 55000055 55000055 55000055 55000055 012b0558 55000055 55000055 55000055 55000055 012b0568 55000055 55000055 55000055 00000000 012b0578 00000000 00555555 00555555 00555555 012b0588 00555555 00555555 00555555 00555555 012b0598 00555555 00555555 00555555 00555555 0:000> 012b05a8 00555555 00555555 00555555 00555555 012b05b8 00555555 00555555 00555555 00555555 012b05c8 00555555 00555555 00555555 00555555 012b05d8 00555555 00555555 00555555 00555555 012b05e8 00555555 00555555 00555555 00555555 012b05f8 00555555 00555555 00555555 00555555 012b0608 00555555 00555555 00555555 00555555 012b0618 00555555 00555555 00555555 00555555 0:000> 012b0628 00555555 00555555 00555555 00555555 012b0638 00555555 00555555 00555555 00555555 012b0648 00555555 00555555 00555555 00555555 012b0658 00555555 00555555 00555555 00555555 012b0668 00555555 00555555 00555555 00555555 012b0678 00555555 00555555 00555555 00555555 012b0688 00000000 55000000 55005500 55005500 012b0698 55005500 55005500 55005500 55005500 0:000> 012b06a8 55005500 55005500 55005500 55005500 012b06b8 55005500 55005500 55005500 55005500 012b06c8 55005500 55005500 55005500 55005500 012b06d8 55005500 55005500 55005500 55005500 012b06e8 55005500 55005500 55005500 55005500 012b06f8 55005500 55005500 55005500 55005500 012b0708 55005500 55005500 55005500 55005500 012b0718 55005500 55005500 55005500 55005500 0:000> 012b0728 55005500 55005500 55005500 55005500 012b0738 55005500 55005500 55005500 55005500 012b0748 55005500 55005500 55005500 55005500 012b0758 55005500 55005500 55005500 55005500 012b0768 55005500 55005500 55005500 55005500 012b0778 55005500 55005500 55005500 55005500 012b0788 55005500 55005500 55005500 55005500 012b0798 55005500 00000000 00000000 00555500 0:000> 012b07a8 00555500 00555500 00555500 00555500 012b07b8 00555500 00555500 00555500 00555500 012b07c8 00555500 00555500 00555500 00555500 012b07d8 00555500 00555500 00555500 00555500 012b07e8 00555500 00555500 00555500 00555500 012b07f8 00555500 00555500 00555500 00555500 012b0808 00555500 00555500 00555500 00555500 012b0818 00555500 00555500 00555500 00555500 0:000> 012b0828 00555500 00555500 00555500 00555500 012b0838 00555500 00555500 00555500 00555500 012b0848 00555500 00555500 00555500 00555500 012b0858 00555500 00555500 00555500 00555500 012b0868 00555500 00555500 00555500 00555500 012b0878 00555500 00555500 00555500 00555500 012b0888 00555500 00555500 00555500 00555500 012b0898 00555500 00555500 00555500 00555500 0:000> 012b08a8 00555500 00555500 00000000 55000000 012b08b8 55550055 55550055 55550055 55550055 012b08c8 55550055 55550055 55550055 55550055 012b08d8 55550055 55550055 55550055 55550055 012b08e8 55550055 55550055 55550055 55550055 012b08f8 55550055 55550055 55550055 55550055 012b0908 55550055 55550055 55550055 55550055 012b0918 55550055 55550055 55550055 55550055 0:000> 012b0928 55550055 55550055 55550055 55550055 012b0938 55550055 55550055 55550055 55550055 012b0948 55550055 55550055 55550055 55550055 012b0958 55550055 55550055 55550055 55550055 012b0968 55550055 55550055 55550055 55550055 012b0978 55550055 55550055 55550055 55550055 012b0988 55550055 55550055 55550055 55550055 012b0998 55550055 55550055 55550055 55550055 0:000> 012b09a8 55550055 55550055 55550055 55550055 012b09b8 55550055 55550055 55550055 00000000 012b09c8 55000000 55005500 55005500 55005500 012b09d8 55005500 55005500 55005500 55005500 012b09e8 55005500 55005500 55005500 55005500 012b09f8 55005500 55005500 55005500 55005500 012b0a08 55005500 55005500 55005500 55005500 012b0a18 55005500 55005500 55005500 55005500 0:000> 012b0a28 55005500 55005500 55005500 55005500 012b0a38 55005500 55005500 55005500 55005500 012b0a48 55005500 55005500 55005500 55005500 012b0a58 55005500 55005500 55005500 55005500 012b0a68 55005500 55005500 55005500 55005500 012b0a78 55005500 55005500 55005500 55005500 012b0a88 55005500 55005500 55005500 55005500 012b0a98 55005500 55005500 55005500 55005500 0:000> 012b0aa8 55005500 55005500 55005500 55005500 012b0ab8 55005500 55005500 55005500 55005500 012b0ac8 55005500 55005500 55005500 55005500 012b0ad8 00000000 55000000 55000055 55000055 012b0ae8 55000055 55000055 55000055 55000055 012b0af8 55000055 55000055 55000055 55000055 012b0b08 55000055 55000055 55000055 55000055 012b0b18 55000055 55000055 55000055 55000055 0:000> 012b0b28 55000055 55000055 55000055 55000055 012b0b38 55000055 55000055 55000055 55000055 012b0b48 55000055 55000055 55000055 55000055 012b0b58 55000055 55000055 55000055 55000055 012b0b68 55000055 55000055 55000055 55000055 012b0b78 55000055 55000055 55000055 55000055 012b0b88 55000055 55000055 55000055 55000055 012b0b98 55000055 55000055 55000055 55000055 0:000> 012b0ba8 55000055 55000055 55000055 55000055 012b0bb8 55000055 55000055 55000055 55000055 012b0bc8 55000055 55000055 55000055 55000055 012b0bd8 55000055 55000055 55000055 55000055 012b0be8 55000055 00000000 00000000 00555555 012b0bf8 00555555 00555555 00555555 00555555 012b0c08 00555555 00555555 00555555 00555555 012b0c18 00555555 00555555 00555555 00555555 0:000> 012b0c28 00555555 00555555 00555555 00555555 012b0c38 00555555 00555555 00555555 00555555 012b0c48 00555555 00555555 00555555 00555555 012b0c58 00555555 00555555 00555555 00555555 012b0c68 00555555 00555555 00555555 00555555 012b0c78 00555555 00555555 00555555 00555555 012b0c88 00555555 00555555 00555555 00555555 012b0c98 00555555 00555555 00555555 00555555 0:000> 012b0ca8 00555555 00555555 00555555 00555555 012b0cb8 00555555 00555555 00555555 00555555 012b0cc8 00555555 00555555 00555555 00555555 012b0cd8 00555555 00555555 00555555 00555555 012b0ce8 00555555 00555555 00555555 00555555 012b0cf8 00555555 00555555 00000000 55000000 012b0d08 55005500 55005500 55005500 55005500 012b0d18 55005500 55005500 55005500 55005500 0:000> 012b0d28 55005500 55005500 55005500 55005500 012b0d38 55005500 55005500 55005500 55005500 012b0d48 55005500 55005500 55005500 55005500 012b0d58 55005500 55005500 55005500 55005500 012b0d68 55005500 55005500 55005500 55005500 012b0d78 55005500 55005500 55005500 55005500 012b0d88 55005500 55005500 55005500 55005500 012b0d98 55005500 55005500 55005500 55005500 0:000> 012b0da8 55005500 55005500 55005500 55005500 012b0db8 55005500 55005500 55005500 55005500 012b0dc8 55005500 55005500 55005500 55005500 012b0dd8 55005500 55005500 55005500 55005500 012b0de8 55005500 55005500 55005500 55005500 012b0df8 55005500 55005500 55005500 55005500 012b0e08 55005500 55005500 55005500 00000000 012b0e18 00000000 00555500 00555500 00555500 0:000> 012b0e28 00555500 00555500 00555500 00555500 012b0e38 00555500 00555500 00555500 00555500 012b0e48 00555500 00555500 00555500 00555500 012b0e58 00555500 00555500 00555500 00555500 012b0e68 00555500 00555500 00555500 00555500 012b0e78 00555500 00555500 00555500 00555500 012b0e88 00555500 00555500 00555500 00555500 012b0e98 00555500 00555500 00555500 00555500 0:000> 012b0ea8 00555500 00555500 00555500 00555500 012b0eb8 00555500 00555500 00555500 00555500 012b0ec8 00555500 00555500 00555500 00555500 012b0ed8 00555500 00555500 00555500 00555500 012b0ee8 00555500 00555500 00555500 00555500 012b0ef8 00555500 00555500 00555500 00555500 012b0f08 00555500 00555500 00555500 00555500 012b0f18 00555500 00555500 00555500 00555500 0:000> 012b0f28 00000000 55000000 55550055 55550055 012b0f38 55550055 55550055 55550055 55550055 012b0f48 55550055 55550055 55550055 55550055 012b0f58 55550055 55550055 55550055 55550055 012b0f68 55550055 55550055 55550055 55550055 012b0f78 55550055 55550055 55550055 55550055 012b0f88 55550055 55550055 55550055 55550055 012b0f98 55550055 55550055 55550055 55550055 0:000> 012b0fa8 55550055 55550055 55550055 55550055 012b0fb8 55550055 55550055 55550055 55550055 012b0fc8 55550055 55550055 55550055 55550055 012b0fd8 55550055 55550055 55550055 55550055 012b0fe8 55550055 55550055 55550055 55550055 012b0ff8 55550055 55550055 55550055 55550055 012b1008 55550055 55550055 55550055 55550055 012b1018 55550055 55550055 55550055 55550055 0:000> 012b1028 55550055 55550055 55550055 55550055 012b1038 55550055 00000000 55000000 55005500 012b1048 55005500 55005500 55005500 55005500 012b1058 55005500 55005500 55005500 55005500 012b1068 55005500 55005500 55005500 55005500 012b1078 55005500 55005500 55005500 55005500 012b1088 55005500 55005500 55005500 55005500 012b1098 55005500 55005500 55005500 55005500 0:000> 012b10a8 55005500 55005500 55005500 55005500 012b10b8 55005500 55005500 55005500 55005500 012b10c8 55005500 55005500 55005500 55005500 012b10d8 55005500 55005500 55005500 55005500 012b10e8 55005500 55005500 55005500 55005500 012b10f8 55005500 55005500 55005500 55005500 012b1108 55005500 55005500 55005500 55005500 012b1118 55005500 55005500 55005500 55005500 0:000> 012b1128 55005500 55005500 55005500 55005500 012b1138 55005500 55005500 55005500 55005500 012b1148 55005500 55005500 00000000 55000000 012b1158 55000055 55000055 55000055 55000055 012b1168 55000055 55000055 55000055 55000055 012b1178 55000055 55000055 55000055 55000055 012b1188 55000055 55000055 55000055 55000055 012b1198 55000055 55000055 55000055 55000055 0:000> 012b11a8 55000055 55000055 55000055 55000055 012b11b8 55000055 55000055 55000055 55000055 012b11c8 55000055 55000055 55000055 55000055 012b11d8 55000055 55000055 55000055 55000055 012b11e8 55000055 55000055 55000055 55000055 012b11f8 55000055 55000055 55000055 55000055 012b1208 55000055 55000055 55000055 55000055 012b1218 55000055 55000055 55000055 55000055 0:000> 012b1228 55000055 55000055 55000055 55000055 012b1238 55000055 55000055 55000055 55000055 012b1248 55000055 55000055 55000055 55000055 012b1258 55000055 55000055 55000055 00000000 012b1268 00000000 00555555 00555555 00555555 012b1278 00555555 00555555 00555555 00555555 012b1288 00555555 00555555 00555555 00555555 012b1298 00555555 00555555 00555555 00555555 0:000> 012b12a8 00555555 00555555 00555555 00555555 012b12b8 00555555 00555555 00555555 00555555 012b12c8 00555555 00555555 00555555 00555555 012b12d8 00555555 00555555 00555555 00555555 012b12e8 00555555 00555555 00555555 00555555 012b12f8 00555555 00555555 00555555 00555555 012b1308 00555555 00555555 00555555 00555555 012b1318 00555555 00555555 00555555 00555555 0:000> 012b1328 00555555 00555555 00555555 00555555 012b1338 00555555 00555555 00555555 00555555 012b1348 00555555 00555555 00555555 00555555 012b1358 00555555 00555555 00555555 00555555 012b1368 00555555 00555555 00555555 00555555 012b1378 00000000 55000000 55005500 55005500 012b1388 55005500 55005500 55005500 55005500 012b1398 55005500 55005500 55005500 55005500 0:000> 012b13a8 55005500 55005500 55005500 55005500 012b13b8 55005500 55005500 55005500 55005500 012b13c8 55005500 55005500 55005500 55005500 012b13d8 55005500 55005500 55005500 55005500 012b13e8 55005500 55005500 55005500 55005500 012b13f8 55005500 55005500 55005500 55005500 012b1408 55005500 55005500 55005500 55005500 012b1418 55005500 55005500 55005500 55005500 0:000> 012b1428 55005500 55005500 55005500 55005500 012b1438 55005500 55005500 55005500 55005500 012b1448 55005500 55005500 55005500 55005500 012b1458 55005500 55005500 55005500 55005500 012b1468 55005500 55005500 55005500 55005500 012b1478 55005500 55005500 55005500 55005500 012b1488 55005500 00000000 00000000 00555500 012b1498 00555500 00555500 00555500 00555500 0:000> 012b14a8 00555500 00555500 00555500 00555500 012b14b8 00555500 00555500 00555500 00555500 012b14c8 00555500 00555500 00555500 00555500 012b14d8 00555500 00555500 00555500 00555500 012b14e8 00555500 00555500 00555500 00555500 012b14f8 00555500 00555500 00555500 00555500 012b1508 00555500 00555500 00555500 00555500 012b1518 00555500 00555500 00555500 00555500 0:000> 012b1528 00555500 00555500 00555500 00555500 012b1538 00555500 00555500 00555500 00555500 012b1548 00555500 00555500 00555500 00555500 012b1558 00555500 00555500 00555500 00555500 012b1568 00555500 00555500 00555500 00555500 012b1578 00555500 00555500 00555500 00555500 012b1588 00555500 00555500 00555500 00555500 012b1598 00555500 00555500 00000000 55000000 0:000> 012b15a8 55550055 55550055 55550055 55550055 012b15b8 55550055 55550055 55550055 55550055 012b15c8 55550055 55550055 55550055 55550055 012b15d8 55550055 55550055 55550055 55550055 012b15e8 55550055 ff550055 ffffffff ffffffff 012b15f8 ffffffff 55550055 ffffffff ffffffff 012b1608 555500ff 55550055 55550055 55550055 012b1618 55550055 55550055 ffff0055 ffffffff 0:000> 012b1628 5555ffff 55550055 ff550055 ffffffff 012b1638 55ffffff 55550055 55550055 55550055 012b1648 55550055 55550055 55550055 55550055 012b1658 55550055 55550055 55550055 55550055 012b1668 55550055 55550055 55550055 55550055 012b1678 55550055 55550055 55550055 55550055 012b1688 55550055 55550055 55550055 55550055 012b1698 55550055 55550055 55550055 55550055 0:000> 012b16a8 55550055 55550055 55550055 00000000 012b16b8 55000000 55005500 55005500 55005500 012b16c8 55005500 55005500 55005500 55005500 012b16d8 55005500 55005500 55005500 55005500 012b16e8 55005500 55005500 55005500 55005500 012b16f8 55005500 55005500 55005500 ffffff00 012b1708 ffffffff 550055ff 55005500 ff005500 012b1718 55ffffff 55005500 55005500 55005500 0:000> 012b1728 55005500 55005500 55005500 ff005500 012b1738 ffffffff 55ffffff 55005500 55005500 012b1748 ffffff00 550055ff 55005500 55005500 012b1758 55005500 55005500 55005500 55005500 012b1768 55005500 ff005500 ffffffff 55ffffff 012b1778 55005500 55005500 55005500 55005500 012b1788 55005500 55005500 55005500 55005500 012b1798 55005500 55005500 55005500 55005500 0:000> 012b17a8 55005500 55005500 55005500 55005500 012b17b8 55005500 55005500 55005500 55005500 012b17c8 00000000 55000000 55000055 55000055 012b17d8 55000055 55000055 55000055 55000055 012b17e8 ffffff55 ffffffff ffffffff ffffffff 012b17f8 ffffffff ffffffff 55000055 55000055 012b1808 55000055 55000055 55000055 55000055 012b1818 ffff0055 ffffffff 55000055 55000055 0:000> 012b1828 55000055 5500ffff 55000055 55000055 012b1838 55000055 55000055 55000055 55000055 012b1848 55000055 ffffffff ffffffff 55000055 012b1858 55000055 ffff0055 55000055 55000055 012b1868 55000055 55000055 55000055 55000055 012b1878 55000055 55000055 ffffffff 550000ff 012b1888 ffffff55 5500ffff 55000055 55000055 012b1898 55000055 55000055 55000055 55000055 0:000> 012b18a8 55000055 55000055 55000055 55000055 012b18b8 ffffff55 55ffffff 55000055 55000055 012b18c8 55000055 55000055 55000055 55000055 012b18d8 55000055 00000000 00000000 00555555 012b18e8 00555555 00555555 00555555 00555555 012b18f8 00555555 ffffff55 ffffffff ffffffff 012b1908 ffffffff ffffffff ffffffff 00555555 012b1918 00555555 00555555 00555555 00555555 0:000> 012b1928 00555555 ffff5555 ffffffff 00555555 012b1938 00555555 00555555 0055ffff 00555555 012b1948 00555555 00555555 00555555 00555555 012b1958 00555555 00555555 ffffff55 ffffffff 012b1968 005555ff 00555555 ffff5555 00555555 012b1978 00555555 00555555 00555555 00555555 012b1988 00555555 00555555 ff555555 00ffffff 012b1998 00555555 ff555555 00ffffff 00555555 0:000> 012b19a8 00555555 00555555 00555555 00555555 012b19b8 00555555 00555555 00555555 00555555 012b19c8 ffff5555 ffffffff ffffffff 0055ffff 012b19d8 00555555 00555555 00555555 00555555 012b19e8 00555555 00555555 00000000 55000000 012b19f8 55005500 55005500 55005500 55005500 012b1a08 55005500 55005500 55005500 ffff5500 012b1a18 ffffffff ffffffff ffffffff 55005500 0:000> 012b1a28 55005500 55005500 00005500 55005500 012b1a38 55005500 55005500 ffff5500 ffffffff 012b1a48 55005500 55005500 55005500 5500ffff 012b1a58 55005500 00005500 00550055 00550000 012b1a68 55000055 55005500 55005500 ffffff00 012b1a78 ffffffff 550055ff 55005500 ffff5500 012b1a88 55005500 55005500 00550000 00000055 012b1a98 00550055 55005500 55005500 ffff5500 0:000> 012b1aa8 5500ffff 55005500 55005500 ffffffff 012b1ab8 55005500 55005500 00005500 00550055 012b1ac8 00550000 55000055 55005500 55005500 012b1ad8 55005500 ffffff00 ffffffff ffffffff 012b1ae8 ffffffff 55005500 55005500 55005500 012b1af8 55005500 55005500 55005500 00000000 012b1b08 00000000 00555500 00555500 00555500 012b1b18 00555500 00555500 00555500 00555500 0:000> 012b1b28 ff555500 ffffffff ffffffff 00ffffff 012b1b38 00555500 00555500 00555500 00005500 012b1b48 00555500 00555500 00555500 ffff5500 012b1b58 ffffffff 00555500 00555500 00555500 012b1b68 0055ffff 00555500 55555500 00550000 012b1b78 55550000 00550000 00555500 00555500 012b1b88 ffffff00 ffffffff 0055ffff 00555500 012b1b98 ffff5500 00555500 00555500 00005500 0:000> 012b1ba8 00000055 00005555 00555500 00555500 012b1bb8 ffffff00 0055ffff 00555500 00555500 012b1bc8 ffffffff 005555ff 00555500 55555500 012b1bd8 00550000 55550000 00550000 00555500 012b1be8 00555500 ff555500 ffffffff ffffffff 012b1bf8 ffffffff ffffffff 005555ff 00555500 012b1c08 00555500 00555500 00555500 00555500 012b1c18 00000000 55000000 55550055 55550055 0:000> 012b1c28 55550055 55550055 55550055 55550055 012b1c38 55550055 55550055 ffffffff ffffffff 012b1c48 5555ffff 55550055 55550055 55550055 012b1c58 00000055 55550000 55550055 55550055 012b1c68 ffff0055 ffffffff 55550055 55550055 012b1c78 55550055 5555ffff 55550055 55550055 012b1c88 00005555 55000000 55555555 55550055 012b1c98 55550055 55ffff55 ffffffff 55ffffff 0:000> 012b1ca8 55550055 ffff0055 55550055 55550055 012b1cb8 55555555 00000000 55555500 55550055 012b1cc8 55550055 ffffffff 555500ff 55550055 012b1cd8 55550055 ffffff55 5555ffff 55550055 012b1ce8 55550055 00005555 55000000 55555555 012b1cf8 55550055 55550055 ffff0055 ffffffff 012b1d08 ffffffff ffffffff ffffffff 5555ffff 012b1d18 55550055 55550055 55550055 55550055 0:000> 012b1d28 55550055 00000000 55000000 55005500 012b1d38 55005500 55005500 55005500 55005500 012b1d48 55005500 55005500 55005500 ffffffff 012b1d58 ffffffff 5500ffff 55005500 55005500 012b1d68 55005500 00000000 55000000 55005500 012b1d78 55005500 ffff5500 ffffffff 55005500 012b1d88 55005500 55005500 5500ffff 55005500 012b1d98 00005500 00000055 00000000 55000055 0:000> 012b1da8 55005500 55005500 55ffff00 ffffffff 012b1db8 ffffffff 55005500 ffff5500 55005500 012b1dc8 55005500 00550000 00000000 00550000 012b1dd8 55005500 ff005500 ffffffff 550055ff 012b1de8 55005500 55005500 ffffff00 55ffffff 012b1df8 55005500 00005500 00000055 00000000 012b1e08 55000055 55005500 55005500 ffff5500 012b1e18 ffffffff ffffffff ffffffff ffffffff 0:000> 012b1e28 5500ffff 55005500 55005500 55005500 012b1e38 55005500 55005500 00000000 55000000 012b1e48 55000055 55000055 55000055 55000055 012b1e58 55000055 55000055 55000055 55000055 012b1e68 ffffffff ffffffff 5500ffff 55000055 012b1e78 55000055 55000055 00000055 55000000 012b1e88 55000055 55000055 ffff0055 ffffffff 012b1e98 55000055 55000055 55000055 5500ffff 0:000> 012b1ea8 55000055 00000055 00005555 00000000 012b1eb8 55005555 55000055 55000055 55ffff55 012b1ec8 ffffff55 ffffffff 550000ff ffff0055 012b1ed8 55000055 55000055 55550055 00000000 012b1ee8 55550000 55000055 ff000055 ffffffff 012b1ef8 55000055 55000055 55000055 ffff0055 012b1f08 55ffffff 55000055 00000055 00005555 012b1f18 00000000 55005555 55000055 55000055 0:000> 012b1f28 ffffff55 ffffffff ffffffff ffffffff 012b1f38 ffffffff 55ffffff 55000055 55000055 012b1f48 55000055 55000055 55000055 00000000 012b1f58 00000000 00555555 00555555 00555555 012b1f68 00555555 00555555 00555555 00555555 012b1f78 00555555 ffffffff ffffffff 0055ffff 012b1f88 00555555 00555555 00555555 00000000 012b1f98 00000000 00555555 00555555 ffff5555 0:000> 012b1fa8 ffffffff 00555555 00555555 00555555 012b1fb8 0055ffff 00555555 55555555 00000000 012b1fc8 00000000 00555500 00555555 00555555 012b1fd8 00ffff55 ffff5555 ffffffff 005555ff 012b1fe8 ffff5555 00555555 00555555 00005555 012b1ff8 00000000 55000000 00555555 ff555555 012b2008 ffffffff 00555555 00555555 00555555 012b2018 ffff5555 00ffffff 00555555 55555555 0:000> 012b2028 00000000 00000000 00555500 00555555 012b2038 00555555 ffffffff 005555ff ffff5555 012b2048 ffffffff ffffffff 00ffffff 00555555 012b2058 00555555 00555555 00555555 00555555 012b2068 00000000 55000000 55005500 55005500 012b2078 55005500 55005500 55005500 55005500 012b2088 55005500 55005500 ffffffff ffffffff 012b2098 5500ffff 55005500 55005500 55005500 0:000> 012b20a8 00000000 55000000 55005500 55005500 012b20b8 ffff5500 ffffffff 55005500 55005500 012b20c8 55005500 5500ffff 55005500 00005500 012b20d8 00000055 00000000 55000055 55005500 012b20e8 55005500 55ffff00 ff005500 ffffffff 012b20f8 5500ffff ffff5500 55005500 55005500 012b2108 00550000 00000000 00550000 55005500 012b2118 ffff5500 ffffffff 55005500 55005500 0:000> 012b2128 55005500 ffff5500 ffffffff 55005500 012b2138 00005500 00000055 00000000 55000055 012b2148 55005500 55005500 55ffffff 55005500 012b2158 55005500 ffffffff ffffffff ffffffff 012b2168 55005500 55005500 55005500 55005500 012b2178 55005500 00000000 00000000 00555500 012b2188 00555500 00555500 00555500 00555500 012b2198 00555500 00555500 00555500 ffffffff 0:000> 012b21a8 ffffffff 0055ffff 00555500 00555500 012b21b8 00555500 00000000 00000000 00555500 012b21c8 00555500 ffff5500 ffffffff 00555500 012b21d8 00555500 00555500 0055ffff 00555500 012b21e8 55555500 00000000 00000000 00550000 012b21f8 00555500 00555500 00ffff00 00555500 012b2208 ffffffff 00ffffff ffff5500 00555500 012b2218 00555500 00005500 00000000 00000000 0:000> 012b2228 00555500 ffff5500 ffffffff 00555500 012b2238 00555500 00555500 ffff5500 ffffffff 012b2248 00555500 55555500 00000000 00000000 012b2258 00550000 00555500 ff555500 0055ffff 012b2268 00555500 00555500 ffffff00 ffffffff 012b2278 ffffffff 00555500 00555500 00555500 012b2288 00555500 00555500 00000000 55000000 012b2298 55550055 55550055 55550055 55550055 0:000> 012b22a8 55550055 55550055 55550055 55550055 012b22b8 ffffffff ffffffff 5555ffff 55550055 012b22c8 55550055 00000055 00000000 00000000 012b22d8 55550000 55550055 ffff0055 ffffffff 012b22e8 55550055 55550055 55550055 5555ffff 012b22f8 55550055 00550055 00000000 00000000 012b2308 55550000 55550055 55550055 55ffff55 012b2318 55550055 ffffff55 ffffffff ffff0055 0:000> 012b2328 55550055 55550055 00000055 00000000 012b2338 00000000 55550055 ffff0055 ffffffff 012b2348 55550055 55550055 55550055 ffff0055 012b2358 ffffffff 55550055 00550055 00000000 012b2368 00000000 55550000 55550055 ff550055 012b2378 555500ff 55550055 55550055 ffff0055 012b2388 ffffffff ffffffff 55550055 55550055 012b2398 55550055 55550055 55550055 00000000 0:000> 012b23a8 55000000 55005500 55005500 55005500 012b23b8 55005500 55005500 55005500 55005500 012b23c8 55005500 ffffffff ffffffff 5500ffff 012b23d8 55005500 55005500 00005500 00000000 012b23e8 00000000 55005500 55005500 ffff5500 012b23f8 ffffffff 55005500 55005500 55005500 012b2408 5500ffff 55005500 00005500 00000000 012b2418 00000000 55000000 55005500 55005500 0:000> 012b2428 55ffff00 55005500 ffffff00 ffffffff 012b2438 ffff55ff 55005500 55005500 00000000 012b2448 00000000 00000000 55005500 ffff5500 012b2458 ffffffff 55005500 55005500 55005500 012b2468 ffff5500 ffffffff 55005500 00005500 012b2478 00000000 00000000 55000000 55005500 012b2488 ffff5500 55005500 55005500 55005500 012b2498 ffff5500 ffffffff ffffffff 55005500 0:000> 012b24a8 55005500 55005500 55005500 55005500 012b24b8 00000000 55000000 55000055 55000055 012b24c8 55000055 55000055 55000055 55000055 012b24d8 55000055 55000055 ffffffff ffffffff 012b24e8 5500ffff 55000055 55000055 00000055 012b24f8 00000000 00000000 55000000 55000055 012b2508 ffff0055 ffffffff 55000055 55000055 012b2518 55000055 5500ffff 55000055 00000055 0:000> 012b2528 00000000 00000000 55000000 55000055 012b2538 55000055 55ffff55 55000055 ffff0055 012b2548 ffffffff ffff00ff 55000055 55000055 012b2558 00000055 00000000 00000000 55000055 012b2568 ffff0055 ffffffff 55000055 55000055 012b2578 55000055 ffff0055 ffffffff 55000055 012b2588 00000055 00000000 00000000 55000000 012b2598 55000055 55000055 55000055 55000055 0:000> 012b25a8 55000055 ff000055 ffffffff ffffffff 012b25b8 55000055 55000055 55000055 55000055 012b25c8 55000055 00000000 00000000 00555555 012b25d8 00555555 00555555 00555555 00555555 012b25e8 00555555 00555555 00555555 ffffffff 012b25f8 ffffffff 0055ffff 00555555 00555555 012b2608 00555555 00000000 00000000 00555555 012b2618 00555555 ffff5555 ffffffff 00555555 0:000> 012b2628 00555555 00555555 0055ffff 00555555 012b2638 55555555 00000000 00000000 00555500 012b2648 00555555 00555555 00ffff55 00555555 012b2658 ff555555 ffffffff ffffffff 00555555 012b2668 00555555 00005555 00000000 55000000 012b2678 00555555 ffff5555 ffffffff 00555555 012b2688 00555555 00555555 ffff5555 ffffffff 012b2698 00555555 55555555 00000000 00000000 0:000> 012b26a8 00555500 00555555 00555555 00555555 012b26b8 00555555 00555555 ff555555 ffffffff 012b26c8 ffffffff 00555555 00555555 00555555 012b26d8 00555555 00555555 00000000 55000000 012b26e8 55005500 55005500 55005500 55005500 012b26f8 55005500 55005500 55005500 55005500 012b2708 ffffffff ffffffff 5500ffff 55005500 012b2718 55005500 55005500 00000000 55000000 0:000> 012b2728 55005500 55005500 ffff5500 ffffffff 012b2738 55005500 55005500 55005500 5500ffff 012b2748 55005500 00005500 00000055 00000000 012b2758 55000055 55005500 55005500 55ffff00 012b2768 55005500 55005500 ffffffff ffffffff 012b2778 55005500 55005500 00550000 00000000 012b2788 00550000 55005500 ffff5500 ffffffff 012b2798 55005500 55005500 55005500 ffff5500 0:000> 012b27a8 ffffffff 55005500 00005500 00000055 012b27b8 00000000 55000055 55005500 55005500 012b27c8 55005500 55005500 55005500 ff005500 012b27d8 ffffffff 55ffffff 55005500 55005500 012b27e8 55005500 55005500 55005500 00000000 012b27f8 00000000 00555500 00555500 00555500 012b2808 00555500 00555500 00555500 00555500 012b2818 00555500 ffffffff ffffffff 0055ffff 0:000> 012b2828 00555500 00555500 00555500 00000000 012b2838 00000000 00555500 00555500 ffff5500 012b2848 ffffffff 00555500 00555500 00555500 012b2858 0055ffff 00555500 55555500 00000000 012b2868 00000000 00550000 00555500 00555500 012b2878 00ffff00 00555500 00555500 ffffff00 012b2888 ffffffff 00555500 00555500 00005500 012b2898 00000000 00000000 00555500 ff555500 0:000> 012b28a8 ffffffff 00555500 00555500 00555500 012b28b8 ffff5500 00ffffff 00555500 55555500 012b28c8 00000000 00000000 00550000 00555500 012b28d8 00555500 00555500 00555500 00555500 012b28e8 ff555500 ffffffff 00ffffff 00555500 012b28f8 00555500 00555500 00555500 00555500 012b2908 00000000 55000000 55550055 55550055 012b2918 55550055 55550055 55550055 55550055 0:000> 012b2928 55550055 55550055 ffffffff ffffffff 012b2938 5555ffff 55550055 55550055 55550055 012b2948 00000055 55550000 55550055 55550055 012b2958 ffff0055 ffffffff 55550055 55550055 012b2968 55550055 555500ff 55550055 55550055 012b2978 00005555 55000000 55555555 55550055 012b2988 55550055 55ffff55 55550055 55550055 012b2998 ffffff55 ffffffff 55550055 55550055 0:000> 012b29a8 55555555 00000000 55555500 55550055 012b29b8 ff550055 ffffffff 55550055 55550055 012b29c8 55550055 ffff0055 55ffffff 55550055 012b29d8 55550055 00005555 55000000 55555555 012b29e8 55550055 55550055 55550055 55550055 012b29f8 55550055 ff550055 ffffffff 55ffffff 012b2a08 55550055 55550055 55550055 55550055 012b2a18 55550055 00000000 55000000 55005500 0:000> 012b2a28 55005500 55005500 55005500 55005500 012b2a38 55005500 55005500 55005500 ffffffff 012b2a48 ffffffff 5500ffff 55005500 55005500 012b2a58 55005500 00000000 55000000 55005500 012b2a68 55005500 ff005500 ffffffff 55005500 012b2a78 55005500 ff005500 550055ff 55005500 012b2a88 00005500 00000055 00000000 55000055 012b2a98 55005500 55005500 55ffff00 55005500 0:000> 012b2aa8 55005500 ffff5500 ffffffff 55005500 012b2ab8 55005500 00550000 00000000 00550000 012b2ac8 55005500 ff005500 ffffffff 550055ff 012b2ad8 55005500 55005500 ffffff00 55ffffff 012b2ae8 55005500 00005500 00000055 00000000 012b2af8 55000055 55005500 55005500 55005500 012b2b08 55005500 55005500 ff005500 ffffffff 012b2b18 5500ffff 55005500 55005500 55005500 0:000> 012b2b28 55005500 55005500 00000000 55000000 012b2b38 55000055 55000055 55000055 55000055 012b2b48 55000055 55000055 55000055 55000055 012b2b58 ffffffff ffffffff 5500ffff 55000055 012b2b68 55000055 55000055 00000055 55000000 012b2b78 55000055 55000055 ff000055 ffffffff 012b2b88 550000ff 55000055 ff000055 550000ff 012b2b98 55000055 00000055 00005555 00000000 0:000> 012b2ba8 55005555 55000055 55000055 55ffff55 012b2bb8 55000055 55000055 ff000055 ffffffff 012b2bc8 55000055 55000055 55550055 00000000 012b2bd8 55550000 55000055 55000055 ffffffff 012b2be8 550000ff 55000055 55000055 ffffff55 012b2bf8 5500ffff 55000055 00000055 00005555 012b2c08 00000000 55005555 55000055 55000055 012b2c18 55000055 55000055 55000055 ffff0055 0:000> 012b2c28 ffffffff 5500ffff 55000055 55000055 012b2c38 55000055 55000055 55000055 00000000 012b2c48 00000000 00555555 00555555 00555555 012b2c58 00555555 00555555 00555555 00555555 012b2c68 00555555 ffffffff ffffffff 0055ffff 012b2c78 00555555 00555555 00555555 00005555 012b2c88 00555500 00555555 00555555 00555555 012b2c98 ffffffff 005555ff 00555555 ffff5555 0:000> 012b2ca8 00555555 00555555 55555555 00555500 012b2cb8 55550000 00555500 00555555 00555555 012b2cc8 00ffff55 00555555 00555555 00555555 012b2cd8 ffffffff 00555555 00555555 55005555 012b2ce8 00000055 55005555 00555555 00555555 012b2cf8 ffffff55 005555ff 00555555 00555555 012b2d08 ffffff55 005555ff 00555555 55555555 012b2d18 00555500 55550000 00555500 00555555 0:000> 012b2d28 00555555 00555555 00555555 00555555 012b2d38 ffff5555 ffffffff 005555ff 00555555 012b2d48 00555555 00555555 00555555 00555555 012b2d58 00000000 55000000 55005500 55005500 012b2d68 55005500 55005500 55005500 55005500 012b2d78 55005500 55005500 ffffffff ffffffff 012b2d88 5500ffff 55005500 55005500 55005500 012b2d98 00005500 55005500 55005500 55005500 0:000> 012b2da8 55005500 ffffff00 55ffffff 55005500 012b2db8 55ffff00 55005500 55005500 00005500 012b2dc8 00550055 00550000 55000055 55005500 012b2dd8 55005500 55ffff00 55005500 55005500 012b2de8 55005500 ffffff00 55005500 55005500 012b2df8 00550000 00000055 00550055 55005500 012b2e08 55005500 ffffff00 5500ffff 55005500 012b2e18 55005500 ffffffff 55005500 55005500 0:000> 012b2e28 00005500 00550055 00550000 55000055 012b2e38 55005500 55005500 55005500 55005500 012b2e48 55005500 ffff5500 ffffffff 55005500 012b2e58 55005500 55005500 55005500 55005500 012b2e68 55005500 00000000 00000000 00555500 012b2e78 00555500 00555500 00555500 00555500 012b2e88 00555500 00555500 00555500 ffffffff 012b2e98 ffffffff 0055ffff 00555500 00555500 0:000> 012b2ea8 00555500 00555500 00555500 00555500 012b2eb8 00555500 00555500 ffff5500 ffffffff 012b2ec8 ffffffff 0055ffff 00555500 00555500 012b2ed8 00555500 00555500 00555500 00555500 012b2ee8 00555500 00555500 ffffffff 00555500 012b2ef8 00555500 00555500 ffff5500 00555500 012b2f08 00555500 00555500 00555500 00555500 012b2f18 00555500 00555500 ff555500 00ffffff 0:000> 012b2f28 00555500 ff555500 00ffffff 00555500 012b2f38 00555500 00555500 00555500 00555500 012b2f48 00555500 00555500 00555500 00555500 012b2f58 00555500 00555500 ffffff00 ffffffff 012b2f68 00555500 00555500 00555500 00555500 012b2f78 00555500 00555500 00000000 55000000 012b2f88 55550055 55550055 55550055 55550055 012b2f98 55550055 55550055 55550055 55550055 0:000> 012b2fa8 ffffffff ffffffff 5555ffff 55550055 012b2fb8 55550055 55550055 55550055 55550055 012b2fc8 55550055 55550055 55550055 55550055 012b2fd8 ffffff55 55ffffff 55550055 55550055 012b2fe8 55550055 55550055 55550055 55550055 012b2ff8 55550055 55550055 ffff0055 ffffffff 012b3008 5555ffff 55550055 55550055 ffff0055 012b3018 55550055 55550055 55550055 55550055 0:000> 012b3028 55550055 55550055 55550055 55550055 012b3038 ffffffff 55550055 ffff0055 5555ffff 012b3048 55550055 55550055 55550055 55550055 012b3058 55550055 55550055 55550055 55550055 012b3068 55550055 55550055 55550055 ffffff55 012b3078 55ffffff 55550055 55550055 55550055 012b3088 55550055 55550055 55550055 00000000 012b3098 55000000 55005500 55005500 55005500 0:000> 012b30a8 55005500 55005500 55005500 55005500 012b30b8 55005500 ffffffff ffffffff 5500ffff 012b30c8 55005500 55005500 55005500 55005500 012b30d8 55005500 55005500 55005500 55005500 012b30e8 55005500 55005500 55005500 55005500 012b30f8 55005500 55005500 55005500 55005500 012b3108 55005500 55005500 55005500 55005500 012b3118 55005500 55005500 55005500 55005500 0:000> 012b3128 55005500 55005500 55005500 55005500 012b3138 55005500 55005500 55005500 55005500 012b3148 55005500 ff005500 ffffffff 55ffffff 012b3158 55005500 55005500 55005500 55005500 012b3168 55005500 55005500 55005500 55005500 012b3178 55005500 55005500 55005500 55005500 012b3188 ffffffff 5500ffff 55005500 55005500 012b3198 55005500 55005500 55005500 55005500 0:000> 012b31a8 00000000 55000000 55000055 55000055 012b31b8 55000055 55000055 55000055 55000055 012b31c8 55000055 55000055 ffffffff ffffffff 012b31d8 5500ffff 55000055 55000055 55000055 012b31e8 55000055 55000055 55000055 55000055 012b31f8 55000055 55000055 55000055 55000055 012b3208 55000055 55000055 55000055 55000055 012b3218 55000055 55000055 55000055 55000055 0:000> 012b3228 55000055 55000055 55000055 55000055 012b3238 55000055 55000055 55000055 55000055 012b3248 55000055 55000055 55000055 55000055 012b3258 55000055 55000055 55000055 55000055 012b3268 55000055 55000055 55000055 55000055 012b3278 55000055 55000055 55000055 55000055 012b3288 55000055 55000055 55000055 55000055 012b3298 ff000055 ffffffff 550000ff 55000055 0:000> 012b32a8 55000055 55000055 55000055 55000055 012b32b8 55000055 00000000 00000000 00555555 012b32c8 00555555 00555555 00555555 00555555 012b32d8 00555555 00555555 00555555 ffffffff 012b32e8 ffffffff 0055ffff 00555555 00555555 012b32f8 00555555 00555555 00555555 00555555 012b3308 00555555 00555555 00555555 00555555 012b3318 00555555 00555555 00555555 00555555 0:000> 012b3328 00555555 00555555 00555555 00555555 012b3338 00555555 00555555 00555555 00555555 012b3348 00555555 00555555 00555555 00555555 012b3358 00555555 00555555 00555555 00555555 012b3368 00555555 00555555 00555555 00555555 012b3378 00555555 00555555 00555555 00555555 012b3388 00555555 00555555 00555555 00555555 012b3398 00555555 00555555 00555555 00555555 0:000> 012b33a8 00555555 ff555555 ffffffff 00555555 012b33b8 00555555 00555555 00555555 00555555 012b33c8 00555555 00555555 00000000 55000000 012b33d8 55005500 55005500 55005500 55005500 012b33e8 55005500 55005500 55005500 55005500 012b33f8 ffffffff ffffffff 5500ffff 55005500 012b3408 55005500 55005500 55005500 55005500 012b3418 55005500 55005500 55005500 55005500 0:000> 012b3428 55005500 55005500 55005500 55005500 012b3438 55005500 55005500 55005500 55005500 012b3448 55005500 55005500 55005500 55005500 012b3458 55005500 55005500 55005500 55005500 012b3468 55005500 55005500 55005500 55005500 012b3478 55005500 55005500 55005500 55005500 012b3488 55005500 55005500 55005500 55005500 012b3498 55005500 55005500 55005500 55005500 0:000> 012b34a8 55005500 55005500 55005500 55005500 012b34b8 55005500 55005500 ffff5500 55ffffff 012b34c8 55005500 55005500 55005500 55005500 012b34d8 55005500 55005500 55005500 00000000 012b34e8 00000000 00555500 00555500 00555500 012b34f8 00555500 00555500 00555500 00555500 012b3508 00555500 ffffffff ffffffff 0055ffff 012b3518 00555500 00555500 00555500 00555500 0:000> 012b3528 00555500 00555500 00555500 00555500 012b3538 00555500 00555500 00555500 00555500 012b3548 00555500 00555500 00555500 00555500 012b3558 00555500 00555500 00555500 00555500 012b3568 00555500 00555500 00555500 00555500 012b3578 00555500 00555500 00555500 00555500 012b3588 00555500 00555500 00555500 00555500 012b3598 00555500 00555500 00555500 00555500 0:000> 012b35a8 00555500 00555500 00555500 00555500 012b35b8 00555500 00555500 00555500 00555500 012b35c8 00555500 00555500 00555500 ffffff00 012b35d8 005555ff 00555500 00555500 00555500 012b35e8 00555500 00555500 00555500 00555500 012b35f8 00000000 55000000 55550055 55550055 012b3608 55550055 55550055 55550055 55550055 012b3618 55550055 55550055 ffffffff ffffffff 0:000> 012b3628 5555ffff 55550055 55550055 55550055 012b3638 55550055 55550055 55550055 55550055 012b3648 55550055 55550055 55550055 55550055 012b3658 55550055 55550055 55550055 55550055 012b3668 55550055 55550055 55550055 55550055 012b3678 55550055 55550055 55550055 55550055 012b3688 55550055 55550055 55550055 55550055 012b3698 55550055 55550055 55550055 55550055 0:000> 012b36a8 55550055 55550055 55550055 55550055 012b36b8 55550055 55550055 55550055 55550055 012b36c8 55550055 55550055 55550055 55550055 012b36d8 55550055 55550055 55550055 55550055 012b36e8 ffffffff 55550055 55550055 55550055 012b36f8 55550055 55550055 55550055 55550055 012b3708 55550055 00000000 55000000 55005500 012b3718 55005500 55005500 55005500 55005500 0:000> 012b3728 55005500 55005500 55005500 ffffffff 012b3738 ffffffff 5500ffff 55005500 55005500 012b3748 55005500 55005500 55005500 55005500 012b3758 55005500 55005500 55005500 55005500 012b3768 55005500 55005500 55005500 55005500 012b3778 55005500 55005500 55005500 55005500 012b3788 55005500 55005500 55005500 55005500 012b3798 55005500 55005500 55005500 55005500 0:000> 012b37a8 55005500 55005500 55005500 55005500 012b37b8 55005500 55005500 55005500 55005500 012b37c8 55005500 55005500 55005500 55005500 012b37d8 55005500 55005500 55005500 55005500 012b37e8 55005500 55005500 55005500 55005500 012b37f8 55005500 55ffffff 55005500 55005500 012b3808 55005500 55ffff00 55005500 55005500 012b3818 55005500 55005500 00000000 55000000 0:000> 012b3828 55000055 55000055 55000055 55000055 012b3838 55000055 55000055 55000055 55000055 012b3848 ffffffff ffffffff 5500ffff 55000055 012b3858 55000055 55000055 55000055 55000055 012b3868 55000055 55000055 00000055 55000055 012b3878 55000055 55000055 55000055 55000055 012b3888 55000055 00000055 55000000 55000055 012b3898 55000055 55000055 55000055 55000055 0:000> 012b38a8 55000055 00000000 55000055 55000055 012b38b8 55000055 55000055 55000055 55000055 012b38c8 00000055 55000000 55000055 55000055 012b38d8 55000055 55000055 55000055 55000055 012b38e8 55000000 55000055 55000055 55000055 012b38f8 55000055 55000055 55000055 55000055 012b3908 55000055 ff000055 5500ffff 55000055 012b3918 55000055 55000055 5500ffff 55000055 0:000> 012b3928 55000055 55000055 55000055 00000000 012b3938 00000000 00555555 00555555 00555555 012b3948 00555555 00555555 00555555 00555555 012b3958 00555555 ffffffff ffffffff 0055ffff 012b3968 00555555 00555555 00555555 00555555 012b3978 00555555 00555555 00555555 00000000 012b3988 00550000 00555555 00555555 00555555 012b3998 00555555 00555555 00000055 00000000 0:000> 012b39a8 00555555 00555555 00555555 00555555 012b39b8 00555555 00555555 00000000 00555500 012b39c8 00555555 00555555 00555555 00555555 012b39d8 00555555 00000055 00000000 00555555 012b39e8 00555555 00555555 00555555 00555555 012b39f8 00555555 00000000 00555500 00555555 012b3a08 00555555 00555555 00555555 00555555 012b3a18 00555555 00555555 ffff5555 005555ff 0:000> 012b3a28 00555555 00555555 00555555 0055ffff 012b3a38 00555555 00555555 00555555 00555555 012b3a48 00000000 55000000 55005500 55005500 012b3a58 55005500 55005500 55005500 55005500 012b3a68 55005500 55005500 ffffffff ffffffff 012b3a78 5500ffff 55005500 55005500 55005500 012b3a88 55005500 55005500 55005500 00005500 012b3a98 00000000 55000000 55005500 55005500 0:000> 012b3aa8 55005500 55005500 55005500 00000000 012b3ab8 00000000 55005500 55005500 55005500 012b3ac8 55005500 55005500 00005500 00000000 012b3ad8 55000000 55005500 55005500 55005500 012b3ae8 55005500 00005500 00000000 00000000 012b3af8 55005500 55005500 55005500 55005500 012b3b08 55005500 00000000 00000000 55000000 012b3b18 55005500 55005500 55005500 55005500 0:000> 012b3b28 55005500 55005500 55005500 ffffff00 012b3b38 55005500 55005500 55005500 ff005500 012b3b48 5500ffff 55005500 55005500 55005500 012b3b58 55005500 00000000 00000000 00555500 012b3b68 00555500 00555500 00555500 00555500 012b3b78 00555500 00555500 00555500 ffffffff 012b3b88 ffffffff 0055ffff 00555500 00555500 012b3b98 00555500 00555500 00555500 00555500 0:000> 012b3ba8 00000000 00000000 00000000 00555500 012b3bb8 00555500 00555500 00555500 00005500 012b3bc8 00000000 00000000 00550000 00555500 012b3bd8 00555500 00555500 00555500 00000000 012b3be8 00000000 00000000 00555500 00555500 012b3bf8 00555500 00555500 00005500 00000000 012b3c08 00000000 00550000 00555500 00555500 012b3c18 00555500 00555500 00000000 00000000 0:000> 012b3c28 00000000 00555500 00555500 00555500 012b3c38 00555500 00555500 00555500 00555500 012b3c48 00ffffff 00555500 00555500 00555500 012b3c58 ffff5500 0055ffff 00555500 00555500 012b3c68 00555500 00555500 00000000 55000000 012b3c78 55550055 55550055 55550055 55550055 012b3c88 55550055 55550055 55550055 55550055 012b3c98 ffffffff ffffffff 5555ffff 55550055 0:000> 012b3ca8 55550055 55550055 55550055 55550055 012b3cb8 00550055 00000000 00000000 00000000 012b3cc8 55550000 55550055 55550055 55550055 012b3cd8 00000055 00000000 00000000 00000000 012b3ce8 55550055 55550055 55550055 00550055 012b3cf8 00000000 00000000 00000000 55550000 012b3d08 55550055 55550055 55550055 00000055 012b3d18 00000000 00000000 55000000 55550055 0:000> 012b3d28 55550055 55550055 00000055 00000000 012b3d38 00000000 00000000 55550000 55550055 012b3d48 55550055 55550055 55550055 55550055 012b3d58 ff550055 ffffffff ffffffff ffffffff 012b3d68 ffffffff ffffffff 555500ff 55550055 012b3d78 55550055 55550055 55550055 00000000 012b3d88 55000000 55005500 55005500 55005500 012b3d98 55005500 55005500 5500ff00 55005500 0:000> 012b3da8 55005500 ffffffff ffffffff 5500ffff 012b3db8 55005500 55005500 55005500 55005500 012b3dc8 55005500 00005500 00000000 00000000 012b3dd8 00000000 55000000 55005500 55005500 012b3de8 55005500 00000000 00000000 00000000 012b3df8 00000000 55005500 55005500 55005500 012b3e08 00000000 00000000 00000000 00000000 012b3e18 55000000 55005500 55005500 00005500 0:000> 012b3e28 00000000 55000000 00000000 00000000 012b3e38 55005500 55005500 55005500 00000000 012b3e48 00000000 00005500 00000000 55000000 012b3e58 55005500 55005500 55005500 55005500 012b3e68 55005500 ffff5500 ffffffff ffffffff 012b3e78 ffffffff ffffffff ffffffff 550055ff 012b3e88 55005500 55005500 55005500 55005500 012b3e98 00000000 55000000 55000055 55000055 0:000> 012b3ea8 55000055 55000055 ff000055 ffffffff 012b3eb8 55000055 55000055 ffffffff ffffffff 012b3ec8 5500ffff 55000055 55000055 55000055 012b3ed8 55000055 55000055 00000000 00000000 012b3ee8 55000000 00000000 00000000 55000000 012b3ef8 55000055 00000055 00000000 55000000 012b3f08 00000055 00000000 55000000 55000055 012b3f18 55000055 00000000 00000000 55000055 0:000> 012b3f28 00000000 00000000 55000055 55000055 012b3f38 00000055 00000000 55000000 00000055 012b3f48 00000000 55000000 55000055 55000055 012b3f58 00000000 00000000 00000055 00000000 012b3f68 00000000 55000055 55000055 55000055 012b3f78 55000055 55000055 ffffff55 ffffffff 012b3f88 ffffffff ffffffff ffffffff ffffffff 012b3f98 550000ff 55000055 55000055 55000055 0:000> 012b3fa8 55000055 00000000 00000000 00555555 012b3fb8 00555555 00555555 00555555 ffff5555 012b3fc8 ffffffff 005555ff 00555555 ffffffff 012b3fd8 ffffffff 0055ffff 00555555 00555555 012b3fe8 00555555 00555555 00555555 00000000 012b3ff8 00000000 00555555 00005555 00000000 012b4008 00550000 00555555 00000055 00000000 012b4018 00555500 00555555 00000000 00000000 0:000> 012b4028 00555555 00555555 00000000 00000000 012b4038 00555555 00000055 00000000 00550000 012b4048 00555555 00000000 00000000 00555500 012b4058 00555555 00000000 00000000 00555555 012b4068 00005555 00000000 00000000 00555555 012b4078 00000055 00000000 00555500 00555555 012b4088 00555555 00555555 00555555 ffffff55 012b4098 ffffffff ffffffff ffffffff ffffffff 0:000> 012b40a8 ffffffff 005555ff 00555555 00555555 012b40b8 00555555 00555555 00000000 55000000 012b40c8 55005500 55005500 55005500 55005500 012b40d8 ffffff00 ffffffff 5500ffff 55005500 012b40e8 ffffffff ffffffff 5500ffff 55005500 012b40f8 55005500 55005500 55005500 00005500 012b4108 00000000 55000000 55005500 00005500 012b4118 00000000 55000000 00005500 00000000 0:000> 012b4128 00000000 55005500 55005500 00000000 012b4138 00000000 55005500 00000000 00000000 012b4148 55000000 55005500 00005500 00000000 012b4158 55000000 00005500 00000000 55000000 012b4168 55005500 55005500 00000000 00000000 012b4178 55005500 00000000 00000000 55005500 012b4188 55005500 00005500 00000000 55000000 012b4198 55005500 55005500 55005500 55005500 0:000> 012b41a8 ffffffff ffffffff ffffffff ffffffff 012b41b8 ffffffff ffffffff 550055ff 55005500 012b41c8 55005500 55005500 55005500 00000000 012b41d8 00000000 00555500 00555500 00555500 012b41e8 00555500 ffffff00 ffffffff 0055ffff 012b41f8 00555500 ffffffff ffffffff 005555ff 012b4208 00555500 00555500 00555500 00555500 012b4218 00000000 00000000 00555500 00555500 0:000> 012b4228 00555500 00000000 00000000 00005500 012b4238 00000000 00550000 00555500 00555500 012b4248 00005500 00000000 00000000 00000000 012b4258 00000000 00555500 00555500 00555500 012b4268 00000000 00000000 00005500 00000000 012b4278 00550000 00555500 00555500 00005500 012b4288 00000000 00550000 00000000 00000000 012b4298 00555500 00555500 00555500 00000000 0:000> 012b42a8 00000000 00555500 00555500 00555500 012b42b8 ff555500 ffffffff ffffffff ffffffff 012b42c8 ffffffff ffffffff ffffffff 00555500 012b42d8 00555500 00555500 00555500 00555500 012b42e8 00000000 55000000 55550055 55550055 012b42f8 55550055 55550055 ffffff55 ffffffff 012b4308 5555ffff 55550055 ffffffff ffffffff 012b4318 555500ff 55550055 55550055 55550055 0:000> 012b4328 00550055 00000000 55000000 55550055 012b4338 55550055 55550055 00000055 00000000 012b4348 00000000 00000000 55550000 55550055 012b4358 55550055 55550055 00000000 00000000 012b4368 00000000 55000000 55550055 55550055 012b4378 55550055 00000055 00000000 00000000 012b4388 00000000 55550000 55550055 55550055 012b4398 00550055 00000000 00000000 00000000 0:000> 012b43a8 55550000 55550055 55550055 55550055 012b43b8 00000055 00000000 55550000 55550055 012b43c8 55550055 ffff0055 ffffffff ffffffff 012b43d8 ffffffff ffffffff ffffffff ffffffff 012b43e8 55550055 55550055 55550055 55550055 012b43f8 55550055 00000000 55000000 55005500 012b4408 55005500 55005500 55005500 ffffff00 012b4418 ffffffff 5500ffff 55005500 ffffffff 0:000> 012b4428 ffffffff 550055ff 55005500 55005500 012b4438 55005500 00000000 00000000 55000000 012b4448 55005500 55005500 55005500 00005500 012b4458 00000000 00000000 00000000 55005500 012b4468 55005500 55005500 55005500 00000000 012b4478 00000000 00000000 55005500 55005500 012b4488 55005500 55005500 00005500 00000000 012b4498 00000000 55000000 55005500 55005500 0:000> 012b44a8 55005500 55005500 00000000 00000000 012b44b8 00000000 55005500 55005500 55005500 012b44c8 55005500 00005500 00000000 55000000 012b44d8 55005500 55005500 ffffff00 ffffffff 012b44e8 ffffffff ffffffff ffffffff ffffffff 012b44f8 ffffffff 55005500 55005500 55005500 012b4508 55005500 55005500 00000000 55000000 012b4518 55000055 55000055 55000055 55000055 0:000> 012b4528 ffff0055 ffffffff 550000ff 55000055 012b4538 ffffffff ffffffff 55000055 55000055 012b4548 55000055 55000055 00000055 00000000 012b4558 55000055 55000055 55000055 55000055 012b4568 55000055 00000055 00000000 55000000 012b4578 55000055 55000055 55000055 55000055 012b4588 00000055 00000000 00000000 55000055 012b4598 55000055 55000055 55000055 55000055 0:000> 012b45a8 00000000 00000000 55000000 55000055 012b45b8 55000055 55000055 55000055 00000055 012b45c8 00000000 00000000 55000055 55000055 012b45d8 55000055 55000055 55000055 00000000 012b45e8 55000000 55000055 55000055 ffffff55 012b45f8 ffffffff ffffffff ffffffff ffffffff 012b4608 ffffffff ffffffff 55000055 55000055 012b4618 55000055 55000055 55000055 00000000 0:000> 012b4628 00000000 00555555 00555555 00555555 012b4638 00555555 ffff5555 ffffffff 00555555 012b4648 00555555 ffffffff 00ffffff 00555555 012b4658 00555555 00555555 00555555 00000055 012b4668 00000000 00555555 00555555 00555555 012b4678 00555555 00555555 00005555 00000000 012b4688 00555500 00555555 00555555 00555555 012b4698 00555555 00555555 00000000 00000000 0:000> 012b46a8 00555555 00555555 00555555 00555555 012b46b8 00555555 00005555 00000000 00555555 012b46c8 00555555 00555555 00555555 00555555 012b46d8 00555555 00000000 00550000 00555555 012b46e8 00555555 00555555 00555555 00555555 012b46f8 00000055 00000000 00555555 00555555 012b4708 00555555 00555555 00555555 00555555 012b4718 00555555 00555555 00555555 00555555 0:000> 012b4728 00555555 00555555 00555555 00555555 012b4738 00000000 55000000 55005500 55005500 012b4748 55005500 55005500 ff005500 ffffffff 012b4758 55005500 ff005500 ffffffff 55ffffff 012b4768 55005500 55005500 55005500 55005500 012b4778 00005500 55000000 55005500 55005500 012b4788 55005500 55005500 55005500 00005500 012b4798 55000000 55005500 55005500 55005500 0:000> 012b47a8 55005500 55005500 55005500 00000000 012b47b8 55005500 55005500 55005500 55005500 012b47c8 55005500 55005500 00005500 55000000 012b47d8 55005500 55005500 55005500 55005500 012b47e8 55005500 55005500 00000000 55005500 012b47f8 55005500 55005500 55005500 55005500 012b4808 55005500 00005500 55000000 55005500 012b4818 55005500 55005500 55005500 55005500 0:000> 012b4828 55005500 55005500 55005500 55005500 012b4838 55005500 55005500 55005500 55005500 012b4848 55005500 00000000 00000000 00555500 012b4858 00555500 00555500 00555500 00555500 012b4868 ffffffff 005555ff ffff5500 ffffffff 012b4878 005555ff 00555500 00555500 00555500 012b4888 00555500 00005500 00555500 00555500 012b4898 00555500 00555500 00555500 00555500 0:000> 012b48a8 00555500 00550000 00555500 00555500 012b48b8 00555500 00555500 00555500 00555500 012b48c8 00555500 00555500 00555500 00555500 012b48d8 00555500 00555500 00555500 00555500 012b48e8 00550000 00555500 00555500 00555500 012b48f8 00555500 00555500 00555500 00005500 012b4908 00555500 00555500 00555500 00555500 012b4918 00555500 00555500 00555500 00550000 0:000> 012b4928 00555500 00555500 00555500 00555500 012b4938 00555500 00555500 00555500 00555500 012b4948 00555500 00555500 00555500 00555500 012b4958 00555500 00555500 00000000 55000000 012b4968 55550055 55550055 55550055 55550055 012b4978 55550055 ffffff55 ffffffff ffffffff 012b4988 ffffffff 55550055 55550055 55550055 012b4998 55550055 55550055 55550055 55550055 0:000> 012b49a8 55550055 55550055 55550055 55550055 012b49b8 55550055 55550055 55550055 55550055 012b49c8 55550055 55550055 55550055 55550055 012b49d8 55550055 55550055 55550055 55550055 012b49e8 55550055 55550055 55550055 55550055 012b49f8 55550055 55550055 55550055 55550055 012b4a08 55550055 55550055 55550055 55550055 012b4a18 55550055 55550055 55550055 55550055 0:000> 012b4a28 55550055 55550055 55550055 55550055 012b4a38 55550055 55550055 55550055 55550055 012b4a48 55550055 55550055 55550055 55550055 012b4a58 55550055 55550055 55550055 55550055 012b4a68 55550055 55550055 55550055 00000000 012b4a78 55000000 55005500 55005500 55005500 012b4a88 55005500 55005500 55005500 ffffffff 012b4a98 ffffffff 550055ff 55005500 55005500 0:000> 012b4aa8 55005500 55005500 55005500 55005500 012b4ab8 55005500 55005500 55005500 55005500 012b4ac8 55005500 55005500 55005500 55005500 012b4ad8 55005500 55005500 55005500 55005500 012b4ae8 55005500 55005500 55005500 55005500 012b4af8 55005500 55005500 55005500 55005500 012b4b08 55005500 55005500 55005500 55005500 012b4b18 55005500 55005500 55005500 55005500 0:000> 012b4b28 55005500 55005500 55005500 55005500 012b4b38 55005500 55005500 55005500 55005500 012b4b48 55005500 55005500 55005500 55005500 012b4b58 55005500 55005500 55005500 55005500 012b4b68 55005500 55005500 55005500 55005500 012b4b78 55005500 55005500 55005500 55005500 012b4b88 00000000 55000000 55000055 55000055 012b4b98 55000055 55000055 55000055 55000055 0:000> 012b4ba8 55000055 55000055 55000055 55000055 012b4bb8 55000055 55000055 55000055 55000055 012b4bc8 55000055 55000055 55000055 55000055 012b4bd8 55000055 55000055 55000055 55000055 012b4be8 55000055 55000055 55000055 55000055 012b4bf8 55000055 55000055 55000055 55000055 012b4c08 55000055 55000055 55000055 55000055 012b4c18 55000055 55000055 55000055 55000055 0:000> 012b4c28 55000055 55000055 55000055 55000055 012b4c38 55000055 55000055 55000055 55000055 012b4c48 55000055 55000055 55000055 55000055 012b4c58 55000055 55000055 55000055 55000055 012b4c68 55000055 55000055 55000055 55000055 012b4c78 55000055 55000055 55000055 55000055 012b4c88 55000055 55000055 55000055 55000055 012b4c98 55000055 00000000 00000000 00555555 0:000> 012b4ca8 00555555 00555555 00555555 00555555 012b4cb8 00555555 00555555 00555555 00555555 012b4cc8 00555555 00555555 00555555 00555555 012b4cd8 00555555 00555555 00555555 00555555 012b4ce8 00555555 00555555 00555555 00555555 012b4cf8 00555555 00555555 00555555 00555555 012b4d08 00555555 00555555 00555555 00555555 012b4d18 00555555 00555555 00555555 00555555 0:000> 012b4d28 00555555 00555555 00555555 00555555 012b4d38 00555555 00555555 00555555 00555555 012b4d48 00555555 00555555 00555555 00555555 012b4d58 00555555 00555555 00555555 00555555 012b4d68 00555555 00555555 00555555 00555555 012b4d78 00555555 00555555 00555555 00555555 012b4d88 00555555 00555555 00555555 00555555 012b4d98 00555555 00555555 00555555 00555555 0:000> 012b4da8 00555555 00555555 00000000 55000000 012b4db8 55005500 55005500 55005500 55005500 012b4dc8 55005500 55005500 55005500 55005500 012b4dd8 55005500 55005500 55005500 55005500 012b4de8 55005500 55005500 55005500 55005500 012b4df8 55005500 55005500 55005500 55005500 012b4e08 55005500 55005500 55005500 55005500 012b4e18 55005500 55005500 55005500 55005500 0:000> 012b4e28 55005500 55005500 55005500 55005500 012b4e38 55005500 55005500 55005500 55005500 012b4e48 55005500 55005500 55005500 55005500 012b4e58 55005500 55005500 55005500 55005500 012b4e68 55005500 55005500 55005500 55005500 012b4e78 55005500 55005500 55005500 55005500 012b4e88 55005500 55005500 55005500 55005500 012b4e98 55005500 55005500 55005500 55005500 0:000> 012b4ea8 55005500 55005500 55005500 55005500 012b4eb8 55005500 55005500 55005500 00000000 012b4ec8 00000000 00555500 00555500 00555500 012b4ed8 00555500 00555500 00555500 00555500 012b4ee8 00555500 00555500 00555500 00555500 012b4ef8 00555500 00555500 00555500 00555500 012b4f08 00555500 00555500 00555500 00555500 012b4f18 00555500 00555500 00555500 00555500 0:000> 012b4f28 00555500 00555500 00555500 00555500 012b4f38 00555500 00555500 00555500 00555500 012b4f48 00555500 00555500 00555500 00555500 012b4f58 00555500 00555500 00555500 00555500 012b4f68 00555500 00555500 00555500 00555500 012b4f78 00555500 00555500 00555500 00555500 012b4f88 00555500 00555500 00555500 00555500 012b4f98 00555500 00555500 00555500 00555500 0:000> 012b4fa8 00555500 00555500 00555500 00555500 012b4fb8 00555500 00555500 00555500 00555500 012b4fc8 00555500 00555500 00555500 00555500 012b4fd8 00000000 55000000 55550055 55550055 012b4fe8 55550055 55550055 55550055 55550055 012b4ff8 55550055 55550055 55550055 55550055 012b5008 55550055 55550055 55550055 55550055 012b5018 55550055 55550055 55550055 55550055 0:000> 012b5028 55550055 55550055 55550055 55550055 012b5038 55550055 55550055 55550055 55550055 012b5048 55550055 55550055 55550055 55550055 012b5058 55550055 55550055 55550055 55550055 012b5068 55550055 55550055 55550055 55550055 012b5078 55550055 55550055 55550055 55550055 012b5088 55550055 55550055 55550055 55550055 012b5098 55550055 55550055 55550055 55550055 0:000> 012b50a8 55550055 55550055 55550055 55550055 012b50b8 55550055 55550055 55550055 55550055 012b50c8 55550055 55550055 55550055 55550055 012b50d8 55550055 55550055 55550055 55550055 012b50e8 55550055 00000000 55000000 55005500 012b50f8 55005500 55005500 55005500 55005500 012b5108 55005500 55005500 55005500 55005500 012b5118 55005500 55005500 55005500 55005500 0:000> 012b5128 55005500 55005500 55005500 55005500 012b5138 55005500 55005500 55005500 55005500 012b5148 55005500 55005500 55005500 55005500 012b5158 55005500 55005500 55005500 55005500 012b5168 55005500 55005500 55005500 55005500 012b5178 55005500 55005500 55005500 55005500 012b5188 55005500 55005500 55005500 55005500 012b5198 55005500 55005500 55005500 55005500 0:000> 012b51a8 55005500 55005500 55005500 55005500 012b51b8 55005500 55005500 55005500 55005500 012b51c8 55005500 55005500 55005500 55005500 012b51d8 55005500 55005500 55005500 55005500 012b51e8 55005500 55005500 55005500 55005500 012b51f8 55005500 55005500 00000000 55000000 012b5208 55000055 55000055 55000055 55000055 012b5218 55000055 55000055 55000055 55000055 0:000> 012b5228 55000055 55000055 55000055 55000055 012b5238 55000055 55000055 55000055 55000055 012b5248 55000055 55000055 55000055 55000055 012b5258 55000055 55000055 55000055 55000055 012b5268 55000055 55000055 55000055 55000055 012b5278 55000055 55000055 55000055 55000055 012b5288 55000055 55000055 55000055 55000055 012b5298 55000055 55000055 55000055 55000055 0:000> 012b52a8 55000055 55000055 55000055 55000055 012b52b8 55000055 55000055 55000055 55000055 012b52c8 55000055 55000055 55000055 55000055 012b52d8 55000055 55000055 55000055 55000055 012b52e8 55000055 55000055 55000055 55000055 012b52f8 55000055 55000055 55000055 55000055 012b5308 55000055 55000055 55000055 00000000 012b5318 00000000 00555555 00555555 00555555 0:000> 012b5328 00555555 00555555 00555555 00555555 012b5338 00555555 00555555 00555555 00555555 012b5348 00555555 00555555 00555555 00555555 012b5358 00555555 00555555 00555555 00555555 012b5368 00555555 00555555 00555555 00555555 012b5378 00555555 00555555 00555555 00555555 012b5388 00555555 00555555 00555555 00555555 012b5398 00555555 00555555 00555555 00555555 0:000> 012b53a8 00555555 00555555 00555555 00555555 012b53b8 00555555 00555555 00555555 00555555 012b53c8 00555555 00555555 00555555 00555555 012b53d8 00555555 00555555 00555555 00555555 012b53e8 00555555 00555555 00555555 00555555 012b53f8 00555555 00555555 00555555 00555555 012b5408 00555555 00555555 00555555 00555555 012b5418 00555555 00555555 00555555 00555555 0:000> 012b5428 00000000 55000000 55005500 55005500 012b5438 55005500 55005500 55005500 55005500 012b5448 55005500 55005500 55005500 55005500 012b5458 55005500 55005500 55005500 55005500 012b5468 55005500 55005500 55005500 55005500 012b5478 55005500 55005500 55005500 55005500 012b5488 55005500 55005500 55005500 55005500 012b5498 55005500 55005500 55005500 55005500 0:000> 012b54a8 55005500 55005500 55005500 55005500 012b54b8 55005500 55005500 55005500 55005500 012b54c8 55005500 55005500 55005500 55005500 012b54d8 55005500 55005500 55005500 55005500 012b54e8 55005500 55005500 55005500 55005500 012b54f8 55005500 55005500 55005500 55005500 012b5508 55005500 55005500 55005500 55005500 012b5518 55005500 55005500 55005500 55005500 0:000> 012b5528 55005500 55005500 55005500 55005500 012b5538 55005500 00000000 00000000 00555500 012b5548 00555500 00555500 00555500 00555500 012b5558 00555500 00555500 00555500 00555500 012b5568 00555500 00555500 00555500 00555500 012b5578 00555500 00555500 00555500 00555500 012b5588 00555500 00555500 00555500 00555500 012b5598 00555500 00555500 00555500 00555500 0:000> 012b55a8 00555500 00555500 00555500 00555500 012b55b8 00555500 00555500 00555500 00555500 012b55c8 00555500 00555500 00555500 00555500 012b55d8 00555500 00555500 00555500 00555500 012b55e8 00555500 00555500 00555500 00555500 012b55f8 00555500 00555500 00555500 00555500 012b5608 00555500 00555500 00555500 00555500 012b5618 00555500 00555500 00555500 00555500 0:000> 012b5628 00555500 00555500 00555500 00555500 012b5638 00555500 00555500 00555500 00555500 012b5648 00555500 00555500 00000000 55000000 012b5658 55550055 55550055 55550055 55550055 012b5668 55550055 55550055 55550055 55550055 012b5678 55550055 55550055 55550055 55550055 012b5688 55550055 55550055 55550055 55550055 012b5698 55550055 55550055 55550055 55550055 0:000> 012b56a8 55550055 55550055 55550055 55550055 012b56b8 55550055 55550055 55550055 55550055 012b56c8 55550055 55550055 55550055 55550055 012b56d8 55550055 55550055 55550055 55550055 012b56e8 55550055 55550055 55550055 55550055 012b56f8 55550055 55550055 55550055 55550055 012b5708 55550055 55550055 55550055 55550055 012b5718 55550055 55550055 55550055 55550055 0:000> 012b5728 55550055 55550055 55550055 55550055 012b5738 55550055 55550055 55550055 55550055 012b5748 55550055 55550055 55550055 55550055 012b5758 55550055 55550055 55550055 00000000 012b5768 55000000 55005500 55005500 55005500 012b5778 55005500 55005500 55005500 55005500 012b5788 55005500 55005500 55005500 55005500 012b5798 55005500 55005500 55005500 55005500 0:000> 012b57a8 55005500 55005500 55005500 55005500 012b57b8 55005500 55005500 55005500 55005500 012b57c8 55005500 55005500 55005500 55005500 012b57d8 55005500 55005500 55005500 55005500 012b57e8 55005500 55005500 55005500 55005500 012b57f8 55005500 55005500 55005500 55005500 012b5808 55005500 55005500 55005500 55005500 012b5818 55005500 55005500 55005500 55005500 0:000> 012b5828 55005500 55005500 55005500 55005500 012b5838 55005500 55005500 55005500 55005500 012b5848 55005500 55005500 55005500 55005500 012b5858 55005500 55005500 55005500 55005500 012b5868 55005500 55005500 55005500 55005500 012b5878 00000000 55000000 55000055 55000055 012b5888 55000055 55000055 55000055 55000055 012b5898 55000055 55000055 55000055 55000055 0:000> 012b58a8 55000055 55000055 55000055 55000055 012b58b8 55000055 55000055 55000055 55000055 012b58c8 55000055 55000055 55000055 55000055 012b58d8 55000055 55000055 55000055 55000055 012b58e8 55000055 55000055 55000055 55000055 012b58f8 55000055 55000055 55000055 55000055 012b5908 55000055 55000055 55000055 55000055 012b5918 55000055 55000055 55000055 55000055 0:000> 012b5928 55000055 55000055 55000055 55000055 012b5938 55000055 55000055 55000055 55000055 012b5948 55000055 55000055 55000055 55000055 012b5958 55000055 55000055 55000055 55000055 012b5968 55000055 55000055 55000055 55000055 012b5978 55000055 55000055 55000055 55000055 012b5988 55000055 00000000 00000000 00000000 012b5998 00000000 00000000 00000000 00000000 0:000> 012b59a8 00000000 00000000 00000000 00000000 012b59b8 00000000 00000000 00000000 00000000 012b59c8 00000000 00000000 00000000 00000000 012b59d8 00000000 00000000 00000000 00000000 012b59e8 00000000 00000000 00000000 00000000 012b59f8 00000000 00000000 00000000 00000000 012b5a08 00000000 00000000 00000000 00000000 012b5a18 00000000 00000000 00000000 00000000 0:000> 012b5a28 00000000 00000000 00000000 00000000 012b5a38 00000000 00000000 00000000 00000000 012b5a48 00000000 00000000 00000000 00000000 012b5a58 00000000 00000000 00000000 00000000 012b5a68 00000000 00000000 00000000 00000000 012b5a78 00000000 00000000 00000000 00000000 012b5a88 00000000 00000000 00000000 00000000 012b5a98 00000000 00000000 00000000 00000000 0:000> 012b5aa8 00000000 00000000 00000000 00000000 012b5ab8 00000000 00000000 00000000 00000000 012b5ac8 00000000 00000000 00000000 00000000 012b5ad8 00000000 00000000 00000000 00000000 012b5ae8 00000000 00000000 00000000 00000000 012b5af8 00000000 00000000 00000000 00000000 012b5b08 00000000 00000000 00000000 00000000 012b5b18 00000000 00000000 00000000 00000000 0:000> 012b5b28 00000000 00000000 00000000 00000000 012b5b38 00000000 00000000 00000000 00000000 012b5b48 00000000 00000000 00000000 00000000 012b5b58 00000000 00000000 00000000 00000000 012b5b68 00000000 00000000 00000000 00000000 012b5b78 00000000 00000000 00000000 00000000 012b5b88 00000000 00000000 00000000 00000000 012b5b98 00000000 00000000 00000000 00000000 0:000> 012b5ba8 00000000 00000000 00000000 00000000 012b5bb8 00000000 00000000 00000000 00000000 012b5bc8 00000000 00000000 00000000 00000000 012b5bd8 00000000 00000000 00000000 00000000 012b5be8 00000000 00000000 00000000 00000000 012b5bf8 00000000 00000000 00000000 00000000 012b5c08 00000000 00000000 00000000 00000000 012b5c18 00000000 00000000 00000000 00000000 0:000> 012b5c28 00000000 00000000 00000000 00000000 012b5c38 00000000 00000000 00000000 00000000 012b5c48 00000000 00000000 00000000 00000000 012b5c58 00000000 00000000 00000000 00000000 012b5c68 00000000 00000000 00000000 00000000 012b5c78 00000000 00000000 00000000 00000000 012b5c88 00000000 00000000 00000000 00000000 012b5c98 00000000 00000000 00000000 00000000 0:000> 012b5ca8 00000000 00000000 00000000 00000000 012b5cb8 00000000 00000000 00000000 00000000 012b5cc8 00000000 00200b16 00eb7e38 02216808 012b5cd8 00200898 01354828 00000000 00000000 012b5ce8 02214018 012b5d48 00000000 000002c2 012b5cf8 000000d5 0000012b 0118cd08 00000000 012b5d08 00000000 00000040 00000000 00000000 012b5d18 00000000 00000000 00000000 00000000 0:000> 012b5d28 02216830 c7c34f80 c7c34f80 c7c34f80 012b5d38 c7c34f80 00000000 00000000 002004ba 012b5d48 00000000 02216894 012b5e64 012b5cdc 012b5d58 00000056 00200470 00000000 022168ac 012b5d68 022168bc 0020052e 00e66248 00e63b70 012b5d78 00000000 011a0648 00e63b60 00200546 012b5d88 00e6609c 00e64e10 00000001 4061c71c 012b5d98 c7c34f80 c7c34f80 00200882 01353ec0 0:000> 012b5da8 00000000 00000000 02214018 012b5e64 012b5db8 00000000 000002c2 0000012b 00000137 012b5dc8 0118cd08 00000000 00000000 00000040 012b5dd8 00000000 00000000 00000000 00000000 012b5de8 00000000 00000000 012b5e10 c7c34f80 012b5df8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b5e08 c7c34f80 00200a3c 01340ff0 00000000 012b5e18 00000000 012b5da4 00000000 00000000 0:000> 012b5e28 000002c2 0000012b 00000137 0118cd08 012b5e38 00000000 00000000 00000040 00000000 012b5e48 00000000 00000000 00000000 00000052 012b5e58 00000000 00000000 002004ba 00000000 012b5e68 012b5d48 012b6118 012b5da4 0000000c 012b5e78 00200470 00000000 022168cc 022168bc 012b5e88 00200332 012b5e94 00000001 022168dc 012b5e98 00200470 00000000 0119e8cc 012b5eac 0:000> 012b5ea8 00200470 00000000 022168e8 012b5ebc 012b5eb8 00200470 00000000 022168dc 00000000 012b5ec8 00200470 00000000 012b5e9c 012b5e7c 012b5ed8 0020052e 00e66248 00e63b70 00000000 012b5ee8 011a0648 00e63b60 00200546 00e6609c 012b5ef8 00e63c80 00000001 c7c34f80 00000000 012b5f08 00000000 00200546 00e6609c 00e63900 012b5f18 00000000 c7c34f80 c7c34f80 c7c34f80 0:000> 012b5f28 00200470 00000000 022168dc 012b5ecc 012b5f38 00200470 00000000 022168dc 00000000 012b5f48 0020052e 00e66248 00e63b70 00000000 012b5f58 011a0648 00e63b60 00200548 00e6607c 012b5f68 00e64e10 00000001 022168dc 00200544 012b5f78 00e660bc 00e64564 00000000 40000000 012b5f88 00200544 00e660bc 00e64578 00000000 012b5f98 00000000 00200532 00e661e4 00e6458c 0:000> 012b5fa8 00000000 00000000 00200532 00e661e4 012b5fb8 00e645a4 00000000 00000001 00200532 012b5fc8 00e661e4 00e645b8 00000000 00000000 012b5fd8 00200534 01341518 00e64e10 00000000 012b5fe8 012b5ff8 00000001 00000001 00200540 012b5ff8 012b6000 00000003 012b5fa0 012b5fb4 012b6008 012b5fc8 00200548 00e6607c 00e6418c 012b6018 00000000 00000000 002008a0 01354e98 0:000> 012b6028 00000000 00000000 012b60ac 00000000 012b6038 00000000 000002c2 00000137 00000151 012b6048 0118cd08 00000000 00000000 00000040 012b6058 00000000 00000000 00000000 00000000 012b6068 022168dc 00000007 0119ff40 3f349f4a 012b6078 00000000 00000002 00000000 3f000000 012b6088 3f000000 000000b8 0000020a 00000137 012b6098 00000151 000000b8 0000014c 00000000 0:000> 012b60a8 00200898 01354828 00000000 00000000 012b60b8 02214018 012b6118 00000000 000002c2 012b60c8 00000137 00000151 0118cd08 00000000 012b60d8 00000000 00000040 00000000 00000000 012b60e8 00000000 00000000 00000000 00000000 012b60f8 012b6024 c7c34f80 c7c34f80 c7c34f80 012b6108 c7c34f80 00000000 00000000 002004ba 012b6118 00000000 012b5e64 012b6234 012b60ac 012b6128 0000001a 00200470 00000000 022168f8 012b6138 022168bc 0020052e 00e66248 00e63b70 012b6148 00000000 011a0648 00e63b60 00200546 012b6158 00e6609c 00e64e10 00000001 4061c71c 012b6168 c7c34f80 c7c34f80 00200882 01353ec0 012b6178 00000000 00000000 02214018 012b6234 012b6188 00000000 000002c2 00000151 0000015d 012b6198 0118cd08 00000000 00000000 00000040 012b61a8 00000000 00000000 00000000 00000000 012b61b8 00000000 00000000 012b61e0 c7c34f80 012b61c8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b61d8 c7c34f80 00200a3c 01340ff0 00000000 012b61e8 00000000 012b6174 00000000 00000000 012b61f8 000002c2 00000151 0000015d 0118cd08 012b6208 00000000 00000000 00000040 00000000 012b6218 00000000 00000000 00000000 00000052 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 3 17:45:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 3 Sep 2009 15:45:39 +0000 Subject: [M3devel] some data on Juno crash on Win32 In-Reply-To: <20090903154436.w1aooqqaskg4scg4@mail.elegosoft.com> References: <20090903154436.w1aooqqaskg4scg4@mail.elegosoft.com> Message-ID: This is on NT. Posix often hangs. If I blow up the initial heap size by a factor of 100, to avoid any garbage collection occuring, the crashes and hangs go away. NT then just fails assertions. I think @M3nogc causes the same thing. So, duh, I think something is trashing the heap. Maybe the gui code. - Jay > Date: Thu, 3 Sep 2009 15:44:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] some data on Juno crash on Win32 > > Quoting Jay K : > > > summary: 5.7.0 and 5.7.1 of unknown date: > > > > both always fail > > > > 5.7.0 always fails an assert (various?) > > > > 5.7.1 sometimes fails an assert (various) > > > > 5.7.1 sometimes access violates, always on address 00200000, plus or minus 4. > > > > Current source always access violates, same address. > > > > Since 5.7.1 and current source always access violate (aka SIGSEGV) > > on the same > > location, every run, I'm more inclined to look at this. > > This is all on Windows/NT386, isn't it? Or on POSIX platforms, too? > I seem to remember that Juno always crashed on a PaintBrush operation > on Windows, while the various mentor applications crashed at > different points, but all relating to insufficient Trestle/Win > support. > > On POSIX platforms both applications always ran OK AFAIR. > > Olaf > > > And then hope everything else is "the same" problem. > > > > But of course there might be multiple problems. > > > > It might be good to check for the hang in various from > > http://www.opencm3.net/uploaded-archives/index.html. > > > > Also see what all we can get from > > http://www.opencm3.net/snaps/snapshot-index.html. > > > > I'm going to see if I can get the index update with the many files I > > noticed in the file system. > > The same file name pattern for all files would help here. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Sep 3 20:32:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 03 Sep 2009 20:32:27 +0200 Subject: [M3devel] RC3, RC4? Message-ID: <20090903203227.smcanrumcgo84w4o@mail.elegosoft.com> Hi again, I'm about to leave for my holidays and will be back again on September 22. I probably won't be able to check my email for about two weeks, nor will I further the CM3 release engineering in this time. For 5.8 RC3, packages for most target platforms have been built and are available on www.opencm3.net. But there is a possibly critical problem described in ticket #1070, which may make it necessary to rebuild all packages (which should then be named RC4). I trust that Jay and Tony and anybody else who is interested track down the problem and fix it, and update tickets and roadmap at https://projects.elego.de/cm3/roadmap appropriately. I hope to see a usable set of packages at my return :-) I'll have a look at my mail again later tonight and tomorrow morning, but won't do much more concerning CM3 now. If anybody wants to go on and build RC4, here is what should be done: 1. Apply the tag release_CM3_5_8_RC4 to an appropriate and consistent configuration in CVS containing all needed fixes. 2. Update cm3/scripts/version to 5.8.4 etc. 3. Insert the tag as default into scripts/make-dist.sh (optional). 4. Build installation packages on all target platforms, most easily done via the makedist-jobs in http://hudson.modula3.com:8080/view/makedist/. 5. When the packages are available, they should be tested with http://hudson.modula3.com:8080/view/test-install/. Of course, all regression test results available at http://hudson.modula3.com:8080/ should be examined before the build. 6. Update the release documentation in cm3/www/releng and cm3/www and install this on birch.elegosoft.com. If anybody needs access to Hudson or Trac, please refer to admins at elego.de; Kay, Mike or Michael will help you. That's it for now, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Sep 4 04:02:47 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 02:02:47 +0000 Subject: [M3devel] This is a pixmap? Message-ID: Trying again due to truncation. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: This is a pixmap? Date: Thu, 3 Sep 2009 15:44:17 +0000 Does this look like a pixmap to anyone? This is the parameter to Win32 Join. PROCEDURE Join(t: T): REFANY = VAR res: REFANY; BEGIN LOCK threadMu DO IF t.joined THEN Die(ThisLine(), "attempt to join with thread twice"); END; WHILE NOT t.completed DO Wait(threadMu, t.cond) END; res := t.result; t.result := NIL; t.joined := TRUE; t.cond := NIL; IF perfOn THEN PerfChanged(t.id, State.dead) END; END; RETURN res; END Join; Very very often the crash is of the form of reading a pointer from 16 bytes into t and dereferencing it, plus or minus 4. t is at @ebp + here. The pointer then is 00200000 at the start of the second line of the second dump. If we can confirm this is pixmap, we can hunt more around in the gui code. 0:000> dd @ebp+8 0012f964 012ac6a8 02827bf4 02827974 02824c3c 0012f974 02829c40 02829c40 0012f98c 00000006 0012f984 011b9838 012ac6a8 0012f9fc 00000004 0012f994 10017170 000001c7 02829c40 0012f9d8 0012f9a4 0041ffea 02824c3c 02827bf4 02827974 0012f9b4 028250b8 02827974 02827904 02824dd8 0012f9c4 02824c3c 02827bf4 02824d9c 02824d9c 0012f9d4 02824dd8 0012fa8c 00420b98 028250b8 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> .lastevent Last event: ee0.13a4: Access violation - code c0000005 (first chance) debugger time: Thu Sep 3 07:43:12.390 2009 (GMT-7) 0:000> u . l1 m3core!Thread__Join+0x173: 005ebb01 8b5ffc mov ebx,dword ptr [edi-4] 0:000> r edi edi=00200000 0:000> Here is the entire bitmappy looking thing. 0:000> dd 012ac6a8 012ac6a8 00000000 01119638 00000000 02829c40 012ac6b8 00200000 022153dc 00200000 00000000 012ac6c8 000006ec 00200000 00200000 00200000 012ac6d8 00200000 00200000 00200000 00200000 012ac6e8 00200000 00200000 00200000 00200000 012ac6f8 00200000 00200000 00200000 00200000 012ac708 00200000 00200000 00200000 00200000 012ac718 00200000 00200000 00200000 00200000 0:000> dd 012ac728 00200000 00200000 00200000 00200000 012ac738 00200000 00200000 00200000 00200000 012ac748 00200000 00200000 00200000 00200000 012ac758 00200000 00200000 00200000 00200000 012ac768 00200000 00200000 00200000 00200000 012ac778 00200000 00200000 00200000 00200000 012ac788 00200000 00200000 00200000 00200000 012ac798 00200000 00200000 00200000 00200000 0:000> 012ac7a8 00200000 00200000 00200000 00200000 012ac7b8 00200000 00200000 00200000 00200000 012ac7c8 00200000 00200000 00200000 00200000 012ac7d8 00200000 00200000 00200000 00200000 012ac7e8 00200000 00200000 00200000 00200000 012ac7f8 00200000 00200000 00200000 00200000 012ac808 00200000 00200000 00200000 00200000 012ac818 00200000 00200000 00200000 00200000 0:000> 012ac828 00200000 00200000 00200000 00200000 012ac838 00200000 00200000 00200000 00200000 012ac848 00200000 00200000 00200000 00200000 012ac858 00200000 00200000 00200000 00200000 012ac868 00200000 00200000 00200000 00200000 012ac878 00200000 00200000 00200000 00200000 012ac888 00200000 00200000 00200000 00200000 012ac898 00200000 00200000 00200000 00200000 0:000> 012ac8a8 00200000 00200000 00200000 00200000 012ac8b8 00200000 00200000 00200000 00200000 012ac8c8 00200000 00200000 00200000 00200000 012ac8d8 00200000 00200000 00200000 00200000 012ac8e8 00200000 00200000 00200000 00200000 012ac8f8 00200000 00200000 00200000 00200000 012ac908 00200000 00200000 00200000 00200000 012ac918 00200000 00200000 00200000 00200000 0:000> 012ac928 00200000 00200000 00200000 00200000 012ac938 00200000 00200000 00200000 00200000 012ac948 00200000 00200000 00200000 00200000 012ac958 00200000 00200000 00200000 00200000 012ac968 00200000 00200000 00200000 00200000 012ac978 00200000 00200000 00200000 00200000 012ac988 00200000 00200000 00200000 00200000 012ac998 00200000 00200000 00200000 00200000 0:000> 012ac9a8 00200000 00200000 00200000 00200000 012ac9b8 00200000 00200000 00200000 00200000 012ac9c8 00200000 00200000 00200000 00200000 012ac9d8 00200000 00200000 00200000 00200000 012ac9e8 00200000 00200000 00200000 00200000 012ac9f8 00200000 00200000 00200000 00200000 012aca08 00200000 00200000 00200000 00200000 012aca18 00200000 00200000 00200000 00200000 0:000> 012aca28 00200000 00200000 00200000 00200000 012aca38 00200000 00200000 00200000 00200000 012aca48 00200000 00200000 00200000 00200000 012aca58 00200000 00200000 00200000 00200000 012aca68 00200000 00200000 00200000 00200000 012aca78 00200000 00200000 00200000 00200000 012aca88 00200000 00200000 00200000 00200000 012aca98 00200000 00200000 00200000 00200000 0:000> 012acaa8 00200000 00200000 00200000 00200000 012acab8 00200000 00200000 00200000 00200000 012acac8 00200000 00200000 00200000 00200000 012acad8 00200000 00200000 00200000 00200000 012acae8 00200000 00200000 00200000 00200000 012acaf8 00200000 00200000 00200000 00200000 012acb08 00200000 00200000 00200000 00200000 012acb18 00200000 00200000 00200000 00200000 0:000> 012acb28 00200000 00200000 00200000 00200000 012acb38 00200000 00200000 00200000 00200000 012acb48 00200000 00200000 00200000 00200000 012acb58 00200000 00200000 00200000 00200000 012acb68 00200000 00200000 00200000 00200000 012acb78 00200000 00200000 00200000 00200000 012acb88 00200000 00200000 00200000 00200000 012acb98 00200000 00200000 00200000 00200000 0:000> 012acba8 00200000 00200000 00200000 00200000 012acbb8 00200000 00200000 00200000 00200000 012acbc8 00200000 00200000 00200000 00200000 012acbd8 00200000 00200000 00200000 00200000 012acbe8 00200000 00200000 00200000 00200000 012acbf8 00200000 00200000 00200000 00200000 012acc08 00200000 00200000 00200000 00200000 012acc18 00200000 00200000 00200000 00200000 0:000> 012acc28 00200000 00200000 00200000 00200000 012acc38 00200000 00200000 00200000 00200000 012acc48 00200000 00200000 00200000 00200000 012acc58 00200000 00200000 00200000 00200000 012acc68 00200000 00200000 00200000 00200000 012acc78 00200000 00200000 00200000 00200000 012acc88 00200000 00200000 00200000 00200000 012acc98 00200000 00200000 00200000 00200000 0:000> 012acca8 00200000 00200000 00200000 00200000 012accb8 00200000 00200000 00200000 00200000 012accc8 00200000 00200000 00200000 00200000 012accd8 00200000 00200000 00200000 00200000 012acce8 00200000 00200000 00200000 00200000 012accf8 00200000 00200000 00200000 00200000 012acd08 00200000 00200000 00200000 00200000 012acd18 00200000 00200000 00200000 00200000 0:000> 012acd28 00200000 00200000 00200000 00200000 012acd38 00200000 00200000 00200000 00200000 012acd48 00200000 00200000 00200000 00200000 012acd58 00200000 00200000 00200000 00200000 012acd68 00200000 00200000 00200000 00200000 012acd78 00200000 00200000 00200000 00200000 012acd88 00200000 00200000 00200000 00200000 012acd98 00200000 00200000 00200000 00200000 0:000> 012acda8 00200000 00200000 00200000 00200000 012acdb8 00200000 00200000 00200000 00200000 012acdc8 00200000 00200000 00200000 00200000 012acdd8 00200000 00200000 00200000 00200000 012acde8 00200000 00200000 00200000 00200000 012acdf8 00200000 00200000 00200000 00200000 012ace08 00200000 00200000 00200000 00200000 012ace18 00200000 00200000 00200000 00200000 0:000> 012ace28 00200000 00200000 00200000 00200000 012ace38 00200000 00200000 00200000 00200000 012ace48 00200000 00200000 00200000 00200000 012ace58 00200000 00200000 00200000 00200000 012ace68 00200000 00200000 00200000 00200000 012ace78 00200000 00200000 00200000 00200000 012ace88 00200000 00200000 00200000 00200000 012ace98 00200000 00200000 00200000 00200000 0:000> 012acea8 00200000 00200000 00200000 00200000 012aceb8 00200000 00200000 00200000 00200000 012acec8 00200000 00200000 00200000 00200000 012aced8 00200000 00200000 00200000 00200000 012acee8 00200000 00200000 00200000 00200000 012acef8 00200000 00200000 00200000 00200000 012acf08 00200000 00200000 00200000 00200000 012acf18 00200000 00200000 00200000 00200000 0:000> 012acf28 00200000 00200000 00200000 00200000 012acf38 00200000 00200000 00200000 00200000 012acf48 00200000 00200000 00200000 00200000 012acf58 00200000 00200000 00200000 00200000 012acf68 00200000 00200000 00200000 00200000 012acf78 00200000 00200000 00200000 00200000 012acf88 00200000 00200000 00200000 00200000 012acf98 00200000 00200000 00200000 00200000 0:000> 012acfa8 00200000 00200000 00200000 00200000 012acfb8 00200000 00200000 00200000 00200000 012acfc8 00200000 00200000 00200000 00200000 012acfd8 00200000 00200000 00200000 00200000 012acfe8 00200000 00200000 00200000 00200000 012acff8 00200000 00200000 00200000 00200000 012ad008 00200000 00200000 00200000 00200000 012ad018 00200000 00200000 00200000 00200000 0:000> 012ad028 00200000 00200000 00200000 00200000 012ad038 00200000 00200000 00200000 00200000 012ad048 00200000 00200000 00200000 00200000 012ad058 00200000 00200000 00200000 00200000 012ad068 00200000 00200000 00200000 00200000 012ad078 00200000 00200000 00200000 00200000 012ad088 00200000 00200000 00200000 00200000 012ad098 00200000 00200000 00200000 00200000 0:000> 012ad0a8 00200000 00200000 00200000 00200000 012ad0b8 00200000 00200000 00200000 00200000 012ad0c8 00200000 00200000 00200000 00200000 012ad0d8 00200000 00200000 00200000 00200000 012ad0e8 00200000 00200000 00200000 00200000 012ad0f8 00200000 00200000 00200000 00200000 012ad108 00200000 00200000 00200000 00200000 012ad118 00200000 00200000 00200000 00200000 0:000> 012ad128 00200000 00200000 00200000 00200000 012ad138 00200000 00200000 00200000 00200000 012ad148 00200000 00200000 00200000 00200000 012ad158 00200000 00200000 00200000 00200000 012ad168 00200000 00200000 00200000 00200000 012ad178 00200000 00200000 00200000 00200000 012ad188 00200000 00200000 00200000 00200000 012ad198 00200000 00200000 00200000 00200000 0:000> 012ad1a8 00200000 00200000 00200000 00200000 012ad1b8 00200000 00200000 00200000 00200000 012ad1c8 00200000 00200000 00200000 00200000 012ad1d8 00200000 00200000 00200000 00200000 012ad1e8 00200000 00200000 00200000 00200000 012ad1f8 00200000 00200000 00200000 00200000 012ad208 00200000 00200000 00200000 00200000 012ad218 00200000 00200000 00200000 00200000 0:000> 012ad228 00200000 00200000 00200000 00200000 012ad238 00200000 00200000 00200000 00200000 012ad248 00200000 00200000 00200000 00200000 012ad258 00200000 00200000 00200000 00200000 012ad268 00200000 00200000 00200000 00200000 012ad278 00200000 00200000 00200000 00200000 012ad288 00200000 00200000 00200000 00200000 012ad298 00200000 00200000 00200000 00200000 0:000> 012ad2a8 00200000 00200000 00200000 00200000 012ad2b8 00200000 00200000 00200000 00200000 012ad2c8 00200000 00200000 00200000 00200000 012ad2d8 00200000 00200000 00200000 00200000 012ad2e8 00200000 00200000 00200000 00200000 012ad2f8 00200000 00200000 00200000 00200000 012ad308 00200000 00200000 00200000 00200000 012ad318 00200000 00200000 00200000 00200000 0:000> 012ad328 00200000 00200000 00200000 00200000 012ad338 00200000 00200000 00200000 00200000 012ad348 00200000 00200000 00200000 00200000 012ad358 00200000 00200000 00200000 00200000 012ad368 00200000 00200000 00200000 00200000 012ad378 00200000 00200000 00200000 00200000 012ad388 00200000 00200000 00200000 00200000 012ad398 00200000 00200000 00200000 00200000 0:000> 012ad3a8 00200000 00200000 00200000 00200000 012ad3b8 00200000 00200000 00200000 00200000 012ad3c8 00200000 00200000 00200000 00200000 012ad3d8 00200000 00200000 00200000 00200000 012ad3e8 00200000 00200000 00200000 00200000 012ad3f8 00200000 00200000 00200000 00200000 012ad408 00200000 00200000 00200000 00200000 012ad418 00200000 00200000 00200000 00200000 0:000> 012ad428 00200000 00200000 00200000 00200000 012ad438 00200000 00200000 00200000 00200000 012ad448 00200000 00200000 00200000 00200000 012ad458 00200000 00200000 00200000 00200000 012ad468 00200000 00200000 00200000 00200000 012ad478 00200000 00200000 00200000 00200000 012ad488 00200000 00200000 00200000 00200000 012ad498 00200000 00200000 00200000 00200000 0:000> 012ad4a8 00200000 00200000 00200000 00200000 012ad4b8 00200000 00200000 00200000 00200000 012ad4c8 00200000 00200000 00200000 00200000 012ad4d8 00200000 00200000 00200000 00200000 012ad4e8 00200000 00200000 00200000 00200000 012ad4f8 00200000 00200000 00200000 00200000 012ad508 00200000 00200000 00200000 00200000 012ad518 00200000 00200000 00200000 00200000 0:000> 012ad528 00200000 00200000 00200000 00200000 012ad538 00200000 00200000 00200000 00200000 012ad548 00200000 00200000 00200000 00200000 012ad558 00200000 00200000 00200000 00200000 012ad568 00200000 00200000 00200000 00200000 012ad578 00200000 00200000 00200000 00200000 012ad588 00200000 00200000 00200000 00200000 012ad598 00200000 00200000 00200000 00200000 0:000> 012ad5a8 00200000 00200000 00200000 00200000 012ad5b8 00200000 00200000 00200000 00200000 012ad5c8 00200000 00200000 00200000 00200000 012ad5d8 00200000 00200000 00200000 00200000 012ad5e8 00200000 00200000 00200000 00200000 012ad5f8 00200000 00200000 00200000 00200000 012ad608 00200000 00200000 00200000 00200000 012ad618 00200000 00200000 00200000 00200000 0:000> 012ad628 00200000 00200000 00200000 00200000 012ad638 00200000 00200000 00200000 00200000 012ad648 00200000 00200000 00200000 00200000 012ad658 00200000 00200000 00200000 00200000 012ad668 00200000 00200000 00200000 00200000 012ad678 00200000 00200000 00200000 00200000 012ad688 00200000 00200000 00200000 00200000 012ad698 00200000 00200000 00200000 00200000 0:000> 012ad6a8 00200000 00200000 00200000 00200000 012ad6b8 00200000 00200000 00200000 00200000 012ad6c8 00200000 00200000 00200000 00200000 012ad6d8 00200000 00200000 00200000 00200000 012ad6e8 00200000 00200000 00200000 00200000 012ad6f8 00200000 00200000 00200000 00200000 012ad708 00200000 00200000 00200000 00200000 012ad718 00200000 00200000 00200000 00200000 0:000> 012ad728 00200000 00200000 00200000 00200000 012ad738 00200000 00200000 00200000 00200000 012ad748 00200000 00200000 00200000 00200000 012ad758 00200000 00200000 00200000 00200000 012ad768 00200000 00200000 00200000 00200000 012ad778 00200000 00200000 00200000 00200000 012ad788 00200000 00200000 00200000 00200000 012ad798 00200000 00200000 00200000 00200000 0:000> 012ad7a8 00200000 00200000 00200000 00200000 012ad7b8 00200000 00200000 00200000 00200000 012ad7c8 00200000 00200000 00200000 00200000 012ad7d8 00200000 00200000 00200000 00200000 012ad7e8 00200000 00200000 00200000 00200000 012ad7f8 00200000 00200000 00200000 00200000 012ad808 00200000 00200000 00200000 00200000 012ad818 00200000 00200000 00200000 00200000 0:000> 012ad828 00200000 00200000 00200000 00200000 012ad838 00200000 00200000 00200000 00200000 012ad848 00200000 00200000 00200000 00200000 012ad858 00200000 00200000 00200000 00200000 012ad868 00200000 00200000 00200000 00200000 012ad878 00200000 00200000 00200000 00200000 012ad888 00200000 00200000 00200000 00200000 012ad898 00200000 00200000 00200000 00200000 0:000> 012ad8a8 00200000 00200000 00200000 00200000 012ad8b8 00200000 00200000 00200000 00200000 012ad8c8 00200000 00200000 00200000 00200000 012ad8d8 00200000 00200000 00200000 00200000 012ad8e8 00200000 00200000 00200000 00200000 012ad8f8 00200000 00200000 00200000 00200000 012ad908 00200000 00200000 00200000 00200000 012ad918 00200000 00200000 00200000 00200000 0:000> 012ad928 00200000 00200000 00200000 00200000 012ad938 00200000 00200000 00200000 00200000 012ad948 00200000 00200000 00200000 00200000 012ad958 00200000 00200000 00200000 00200000 012ad968 00200000 00200000 00200000 00200000 012ad978 00200000 00200000 00200000 00200000 012ad988 00200000 00200000 00200000 00200000 012ad998 00200000 00200000 00200000 00200000 0:000> 012ad9a8 00200000 00200000 00200000 00200000 012ad9b8 00200000 00200000 00200000 00200000 012ad9c8 00200000 00200000 00200000 00200000 012ad9d8 00200000 00200000 00200000 00200000 012ad9e8 00200000 00200000 00200000 00200000 012ad9f8 00200000 00200000 00200000 00200000 012ada08 00200000 00200000 00200000 00200000 012ada18 00200000 00200000 00200000 00200000 0:000> 012ada28 00200000 00200000 00200000 00200000 012ada38 00200000 00200000 00200000 00200000 012ada48 00200000 00200000 00200000 00200000 012ada58 00200000 00200000 00200000 00200000 012ada68 00200000 00200000 00200000 00200000 012ada78 00200000 00200000 00200000 00200000 012ada88 00200000 00200000 00200000 00200000 012ada98 00200000 00200000 00200000 00200000 0:000> 012adaa8 00200000 00200000 00200000 00200000 012adab8 00200000 00200000 00200000 00200000 012adac8 00200000 00200000 00200000 00200000 012adad8 00200000 00200000 00200000 00200000 012adae8 00200000 00200000 00200000 00200000 012adaf8 00200000 00200000 00200000 00200000 012adb08 00200000 00200000 00200000 00200000 012adb18 00200000 00200000 00200000 00200000 0:000> 012adb28 00200000 00200000 00200000 00200000 012adb38 00200000 00200000 00200000 00200000 012adb48 00200000 00200000 00200000 00200000 012adb58 00200000 00200000 00200000 00200000 012adb68 00200000 00200000 00200000 00200000 012adb78 00200000 00200000 00200000 00200000 012adb88 00200000 00200000 00200000 00200000 012adb98 00200000 00200000 00200000 00200000 0:000> 012adba8 00200000 00200000 00200000 00200000 012adbb8 00200000 00200000 00200000 00200000 012adbc8 00200000 00200000 00200000 00200000 012adbd8 00200000 00200000 00200000 00200000 012adbe8 00200000 00200000 00200000 00200000 012adbf8 00200000 00200000 00200000 00200000 012adc08 00200000 00200000 00200000 00200000 012adc18 00200000 00200000 00200000 00200000 0:000> 012adc28 00200000 00200000 00200000 00200000 012adc38 00200000 00200000 00200000 00200000 012adc48 00200000 00200000 00200000 00200000 012adc58 00200000 00200000 00200000 00200000 012adc68 00200000 00200000 00200000 00200000 012adc78 00200000 00200000 00200000 00200000 012adc88 00200000 00200000 00200000 00200000 012adc98 00200000 00200000 00200000 00200000 0:000> 012adca8 00200000 00200000 00200000 00200000 012adcb8 00200000 00200000 00200000 00200000 012adcc8 00200000 00200000 00200000 00200000 012adcd8 00200000 00200000 00200000 00200000 012adce8 00200000 00200000 00200000 00200000 012adcf8 00200000 00200000 00200000 00200000 012add08 00200000 00200000 00200000 00200000 012add18 00200000 00200000 00200000 00200000 0:000> 012add28 00200000 00200000 00200000 00200000 012add38 00200000 00200000 00200000 00200000 012add48 00200000 00200000 00200000 00200000 012add58 00200000 00200000 00200000 00200000 012add68 00200000 00200000 00200000 00200000 012add78 00200000 00200000 00200000 00200000 012add88 00200000 00200000 00200000 00200000 012add98 00200000 00200000 00200000 00200000 0:000> 012adda8 00200000 00200000 00200000 00200000 012addb8 00200000 00200000 00200000 00200000 012addc8 00200000 00200000 00200000 00200000 012addd8 00200000 00200000 00200000 00200000 012adde8 00200000 00200000 00200000 00200000 012addf8 00200000 00200000 00200000 00200000 012ade08 00200000 00200000 00200000 00200000 012ade18 00200000 00200000 00200000 00200000 0:000> 012ade28 00200000 00200000 00200000 00200000 012ade38 00200000 00200000 00200000 00200000 012ade48 00200000 00200000 00200000 00200000 012ade58 00200000 00200000 00200000 00200000 012ade68 00200000 00200000 00200000 00200000 012ade78 00200000 00200000 00200000 00200000 012ade88 00200000 00200000 00200000 00200000 012ade98 00200000 00200000 00200000 00200000 0:000> 012adea8 00200000 00200000 00200000 00200000 012adeb8 00200000 00200000 00200000 00200000 012adec8 00200000 00200000 00200000 00200000 012aded8 00200000 00200000 00200000 00200000 012adee8 00200000 00200000 00200000 00200000 012adef8 00200000 00200000 00200000 00200000 012adf08 00200000 00200000 00200000 00200000 012adf18 00200000 00200000 00200000 00200000 0:000> 012adf28 00200000 00200000 00200000 00200000 012adf38 00200000 00200000 00200000 00200000 012adf48 00200000 00200000 00200000 00200000 012adf58 00200000 00200000 00200000 00200000 012adf68 00200000 00200000 00200000 00200000 012adf78 00200000 00200000 00200000 00200000 012adf88 00200000 00200000 00200000 00200000 012adf98 00200000 00200000 00200000 00200000 0:000> 012adfa8 00200000 00200000 00200000 00200000 012adfb8 00200000 00200000 00200000 00200000 012adfc8 00200000 00200000 00200000 00200000 012adfd8 00200000 00200000 00200000 00200000 012adfe8 00200000 00200000 00200000 00200000 012adff8 00200000 00200000 00200000 00200000 012ae008 00200000 00200000 00200000 00200000 012ae018 00200000 00200000 00200000 00200000 0:000> 012ae028 00200000 00200000 00200000 00200000 012ae038 00200000 00200000 00200000 00200000 012ae048 00200000 00200000 00200000 00200000 012ae058 00200000 00200000 00200000 00200000 012ae068 00200000 00200000 00200000 00200000 012ae078 00200000 00200000 00200000 00200000 012ae088 00200000 00200000 00200000 00200000 012ae098 00200000 00200000 00200000 00200000 0:000> 012ae0a8 00200000 00200000 00200000 00200000 012ae0b8 00200000 00200000 00200000 00200000 012ae0c8 00200000 00200000 00200000 00200000 012ae0d8 00200000 00200000 00200000 00200000 012ae0e8 00200000 00200000 00200000 00200000 012ae0f8 00200000 00200000 00200000 00200000 012ae108 00200000 00200000 00200000 00200000 012ae118 00200000 00200000 00200000 00200000 0:000> 012ae128 00200000 00200000 00200000 00200000 012ae138 00200000 00200000 00200000 00200000 012ae148 00200000 00200000 00200000 00200000 012ae158 00200000 00200000 00200000 00200000 012ae168 00200000 00200000 00200000 00200000 012ae178 00200000 00200000 00200000 00200000 012ae188 00200000 00200000 00200000 00200000 012ae198 00200000 00200000 00200000 00200000 0:000> 012ae1a8 00200000 00200000 00200000 00200000 012ae1b8 00200000 00200000 00200000 00200000 012ae1c8 00200000 00200000 00200000 00200000 012ae1d8 00200000 00200000 00200000 00200000 012ae1e8 00200000 00200000 00200000 00200000 012ae1f8 00200000 00200000 00200000 00200000 012ae208 00200000 00200000 00200000 00200000 012ae218 00200000 00200000 00200000 00200000 0:000> 012ae228 00200000 00200000 00200000 00200000 012ae238 00200000 00200000 00200000 00200000 012ae248 00200000 00200000 00200000 00200000 012ae258 00200000 00200000 00200000 00200000 012ae268 00200000 00200000 00200000 00200000 012ae278 00200000 00200000 00200000 00200000 012ae288 00200000 00200000 00200000 00200000 012ae298 00200000 00200000 00200000 00200000 0:000> 012ae2a8 00200000 00200000 00200000 00200000 012ae2b8 00200000 00200000 00200000 00200000 012ae2c8 00200000 00200000 00200000 00200000 012ae2d8 00200000 00200000 00200000 00200000 012ae2e8 00200000 00200000 00200000 00200000 012ae2f8 00200000 00200000 00200000 00200000 012ae308 00200000 00200000 00200000 00200000 012ae318 00200000 00200000 00200000 00200000 0:000> 012ae328 00200000 00200000 00200000 00200000 012ae338 00200000 00200000 00200000 00200000 012ae348 00200000 00200000 00200000 00200000 012ae358 00200000 00200000 00200000 00200000 012ae368 00200000 00200000 00200000 00200000 012ae378 00200000 00200000 00200000 00200000 012ae388 00200000 00200000 00200000 00200000 012ae398 00200000 00200000 00200000 00200000 0:000> 012ae3a8 00200000 00200000 00200000 00200000 012ae3b8 00200000 00200000 00200000 00200000 012ae3c8 00200000 00200000 00200000 00200000 012ae3d8 00200000 00200000 00200000 00200000 012ae3e8 00200000 00200000 00200000 00200000 012ae3f8 00200000 00200000 00200000 00200000 012ae408 00200000 00200000 00200000 00200000 012ae418 00200000 00200000 00200000 00200000 0:000> 012ae428 00200000 00200000 00200000 00200000 012ae438 00200000 00200000 00200000 00200000 012ae448 00200000 00200000 00200000 00200000 012ae458 00200000 00200000 00200000 00200000 012ae468 00200000 00200000 00200000 00200000 012ae478 00200000 00200000 00200000 00200000 012ae488 00200000 00200000 00200000 00200000 012ae498 00200000 00200000 00200000 00200000 0:000> 012ae4a8 00200000 00200000 00200000 00200000 012ae4b8 00200000 00200000 00200000 00200000 012ae4c8 00200000 00200000 00200000 00200000 012ae4d8 00200000 00200000 00200000 00200000 012ae4e8 00200000 00200000 00200000 00200000 012ae4f8 00200000 00200000 00200000 00200000 012ae508 00200000 00200000 00200000 00200000 012ae518 00200000 00200000 00200000 00200000 0:000> 012ae528 00200000 00200000 00200000 00200000 012ae538 00200000 00200000 00200000 00200000 012ae548 00200000 00200000 00200000 00200000 012ae558 00200000 00200000 00200000 00200000 012ae568 00200000 00200000 00200000 00200000 012ae578 00200000 00200000 00200000 00200000 012ae588 00200000 00200000 00200000 00200000 012ae598 00200000 00200000 00200000 00200000 0:000> 012ae5a8 00200000 00200000 00200000 00200000 012ae5b8 00200000 00200000 00200000 00200000 012ae5c8 00200000 00200000 00200000 00200000 012ae5d8 00200000 00200000 00200000 00200000 012ae5e8 00200000 00200000 00200000 00200000 012ae5f8 00200000 00200000 00200000 00200000 012ae608 00200000 00200000 00200000 00200000 012ae618 00200000 00200000 00200000 00200000 0:000> 012ae628 00200000 00200000 00200000 00200000 012ae638 00200000 00200000 00200000 00200000 012ae648 00200000 00200000 00200000 00200000 012ae658 00200000 00200000 00200000 00200000 012ae668 00200000 00200000 00200000 00200000 012ae678 00200000 00200000 00200000 00200000 012ae688 00200000 00200000 00200000 00200000 012ae698 00200000 00200000 00200000 00200000 0:000> 012ae6a8 00200000 00200000 00200000 00200000 012ae6b8 00200000 00200000 00200000 00200000 012ae6c8 00200000 00200000 00200000 00200000 012ae6d8 00200000 00200000 00200000 00200000 012ae6e8 00200000 00200000 00200000 00200000 012ae6f8 00200000 00200000 00200000 00200000 012ae708 00200000 00200000 00200000 00200000 012ae718 00200000 00200000 00200000 00200000 0:000> 012ae728 00200000 00200000 00200000 00200000 012ae738 00200000 00200000 00200000 00200000 012ae748 00200000 00200000 00200000 00200000 012ae758 00200000 00200000 00200000 00200000 012ae768 00200000 00200000 00200000 00200000 012ae778 00200000 00200000 00200000 00200000 012ae788 00200000 00200000 00200000 00200000 012ae798 00200000 00200000 00200000 00200000 0:000> 012ae7a8 00200000 00200000 00200000 00200000 012ae7b8 00200000 00200000 00200000 00200000 012ae7c8 00200000 00200000 00200000 00200000 012ae7d8 00200000 00200000 00200000 00200000 012ae7e8 00200000 00200000 00200000 00200000 012ae7f8 00200000 00200000 00200000 00200000 012ae808 00200000 00200000 00200000 00200000 012ae818 00200000 00200000 00200000 00200000 0:000> 012ae828 00200000 00200000 00200000 00200000 012ae838 00200000 00200000 00200000 00200000 012ae848 00200000 00200000 00200000 00200000 012ae858 00200000 00200000 00200000 00200000 012ae868 00200000 00200000 00200000 00200000 012ae878 00200000 00200000 00200000 00200000 012ae888 00200000 00200000 00200000 00200000 012ae898 00200000 00200000 00200000 00200000 0:000> 012ae8a8 00200000 00200000 00200000 00200000 012ae8b8 00200000 00200000 00200000 00200000 012ae8c8 00200000 00200000 00200000 00200000 012ae8d8 00200000 00200000 00200000 00200000 012ae8e8 00200000 00200000 00200000 00200000 012ae8f8 00200000 00200000 00200000 00200000 012ae908 00200000 00200000 00200000 00200000 012ae918 00200000 00200000 00200000 00200000 0:000> 012ae928 00200000 00200000 00200000 00200000 012ae938 00200000 00200000 00200000 00200000 012ae948 00200000 00200000 00200000 00200000 012ae958 00200000 00200000 00200000 00200000 012ae968 00200000 00200000 00200000 00200000 012ae978 00200000 00200000 00200000 00200000 012ae988 00200000 00200000 00200000 00200000 012ae998 00200000 00200000 00200000 00200000 0:000> 012ae9a8 00200000 00200000 00200000 00200000 012ae9b8 00200000 00200000 00200000 00200000 012ae9c8 00200000 00200000 00200000 00200000 012ae9d8 00200000 00200000 00200000 00200000 012ae9e8 00200000 00200000 00200000 00200000 012ae9f8 00200000 00200000 00200000 00200000 012aea08 00200000 00200000 00200000 00200000 012aea18 00200000 00200000 00200000 00200000 0:000> 012aea28 00200000 00200000 00200000 00200000 012aea38 00200000 00200000 00200000 00200000 012aea48 00200000 00200000 00200000 00200000 012aea58 00200000 00200000 00200000 00200000 012aea68 00200000 00200000 00200000 00200000 012aea78 00200000 00200000 00200000 00200000 012aea88 00200000 00200000 00200000 00200000 012aea98 00200000 00200000 00200000 00200000 0:000> 012aeaa8 00200000 00200000 00200000 00200000 012aeab8 00200000 00200000 00200000 00200000 012aeac8 00200000 00200000 00200000 00200000 012aead8 00200000 00200000 00200000 00200000 012aeae8 00200000 00200000 00200000 00200000 012aeaf8 00200000 00200000 00200000 00200000 012aeb08 00200000 00200000 00200000 00200000 012aeb18 00200000 00200000 00200000 00200000 0:000> 012aeb28 00200000 00200000 00200000 00200000 012aeb38 00200000 00200000 00200000 00200000 012aeb48 00200000 00200000 00200000 00200000 012aeb58 00200000 00200000 00200000 00200000 012aeb68 00200000 00200000 00200000 00200000 012aeb78 00200000 00200000 00200000 00200000 012aeb88 00200000 00200000 00200000 00200000 012aeb98 00200000 00200000 00200000 00200000 0:000> 012aeba8 00200000 00200000 00200000 00200000 012aebb8 00200000 00200000 00200000 00200000 012aebc8 00200000 00200000 00200000 00200000 012aebd8 00200000 00200000 00200000 00200000 012aebe8 00200000 00200000 00200000 00200000 012aebf8 00200000 00200000 00200000 00200000 012aec08 00200000 00200000 00200000 00200000 012aec18 00200000 00200000 00200000 00200000 0:000> 012aec28 00200000 00200000 00200000 00200000 012aec38 00200000 00200000 00200000 00200000 012aec48 00200000 00200000 00200000 00200000 012aec58 00200000 00200000 00200000 00200000 012aec68 00200000 00200000 00200000 00200000 012aec78 00200000 00200000 00200000 00200000 012aec88 00200000 00200000 00200000 00200000 012aec98 00200000 00200000 00200000 00200000 0:000> 012aeca8 00200000 00200000 00200000 00200000 012aecb8 00200000 00200000 00200000 00200000 012aecc8 00200000 00200000 00200000 00200000 012aecd8 00200000 00200000 00200000 00200000 012aece8 00200000 00200000 00200000 00200000 012aecf8 00200000 00200000 00200000 00200000 012aed08 00200000 00200000 00200000 00200000 012aed18 00200000 00200000 00200000 00200000 0:000> 012aed28 00200000 00200000 00200000 00200000 012aed38 00200000 00200000 00200000 00200000 012aed48 00200000 00200000 00200000 00200000 012aed58 00200000 00200000 00200000 00200000 012aed68 00200000 00200000 00200000 00200000 012aed78 00200000 00200000 00200000 00200000 012aed88 00200000 00200000 00200000 00200000 012aed98 00200000 00200000 00200000 00200000 0:000> 012aeda8 00200000 00200000 00200000 00200000 012aedb8 00200000 00200000 00200000 00200000 012aedc8 00200000 00200000 00200000 00200000 012aedd8 00200000 00200000 00200000 00200000 012aede8 00200000 00200000 00200000 00200000 012aedf8 00200000 00200000 00200000 00200000 012aee08 00200000 00200000 00200000 00200000 012aee18 00200000 00200000 00200000 00200000 0:000> 012aee28 00200000 00200000 00200000 00200000 012aee38 00200000 00200000 00200000 00200000 012aee48 00200000 00200000 00200000 00200000 012aee58 00200000 00200000 00200000 00200000 012aee68 00200000 00200000 00200000 00200000 012aee78 00200000 00200000 00200000 00200000 012aee88 00200000 00200000 00200000 00200000 012aee98 00200000 00200000 00200000 00200000 0:000> 012aeea8 00200000 00200000 00200000 00200000 012aeeb8 00200000 00200000 00200000 00200000 012aeec8 00200000 00200000 00200000 00200000 012aeed8 00200000 00200000 00200000 00200000 012aeee8 00200000 00200000 00200000 00200000 012aeef8 00200000 00200000 00200000 00200000 012aef08 00200000 00200000 00200000 00200000 012aef18 00200000 00200000 00200000 00200000 0:000> 012aef28 00200000 00200000 00200000 00200000 012aef38 00200000 00200000 00200000 00200000 012aef48 00200000 00200000 00200000 00200000 012aef58 00200000 00200000 00200000 00200000 012aef68 00200000 00200000 00200000 00200000 012aef78 00200000 00200000 00200000 00200000 012aef88 00200000 00200000 00200000 00200000 012aef98 00200000 00200000 00200000 00200000 0:000> 012aefa8 00200000 00200000 00200000 00200000 012aefb8 00200000 00200000 00200000 00200000 012aefc8 00200000 00200000 00200000 00200000 012aefd8 00200000 00200000 00200000 00200000 012aefe8 00200000 00200000 00200000 00200000 012aeff8 00200000 00200000 00200000 00200000 012af008 00200000 00200000 00200000 00200000 012af018 00200000 00200000 00200000 00200000 0:000> 012af028 00200000 00200000 00200000 00200000 012af038 00200000 00200000 00200000 00200000 012af048 00200000 00200000 00200000 00200000 012af058 00200000 00200000 00200000 00200000 012af068 00200000 00200000 00200000 00200000 012af078 00200000 00200000 00200000 00200000 012af088 00200000 00200000 00200000 00200000 012af098 00200000 00200000 00200000 00200000 0:000> 012af0a8 00200000 00200000 00200000 00200000 012af0b8 00200000 00200000 00200000 00200000 012af0c8 00200000 00200000 00200000 00200000 012af0d8 00200000 00200000 00200000 00200000 012af0e8 00200000 00200000 00200000 00200000 012af0f8 00200000 00200000 00200000 00200000 012af108 00200000 00200000 00200000 00200000 012af118 00200000 00200000 00200000 00200000 0:000> 012af128 00200000 00200000 00200000 00200000 012af138 00200000 00200000 00200000 00200000 012af148 00200000 00200000 00200000 00200000 012af158 00200000 00200000 00200000 00200000 012af168 00200000 00200000 00200000 00200000 012af178 00200000 00200000 00200000 00200000 012af188 00200000 00200000 00200000 00200000 012af198 00200000 00200000 00200000 00200000 0:000> 012af1a8 00200000 00200000 00200000 00200000 012af1b8 00200000 00200000 00200000 00200000 012af1c8 00200000 00200000 00200000 00200000 012af1d8 00200000 00200000 00200000 00200000 012af1e8 00200000 00200000 00200000 00200000 012af1f8 00200000 00200000 00200000 00200000 012af208 00200000 00200000 00200000 00200000 012af218 00200000 00200000 00200000 00200000 0:000> 012af228 00200000 00200000 00200000 00200000 012af238 00200000 00200000 00200000 00200000 012af248 00200000 00200000 00200000 00200000 012af258 00200000 00200000 00200000 00200000 012af268 00200000 00200000 00200000 00200000 012af278 00200000 00200000 00200000 00200000 012af288 00200000 00200000 00200000 00200000 012af298 00200000 00200000 00200000 00200000 0:000> 012af2a8 00200000 00200000 00200000 00200000 012af2b8 00200000 00200000 00200000 00200000 012af2c8 00200000 00200000 00200000 00200000 012af2d8 00200000 00200000 00200000 00200000 012af2e8 00200000 00200000 00200000 00200000 012af2f8 00200000 00200000 00200000 00200000 012af308 00200000 00200000 00200000 00200000 012af318 00200000 00200000 00200000 00200000 0:000> 012af328 00200000 00200000 00200000 00200000 012af338 00200000 00200000 00200000 00200000 012af348 00200000 00200000 00200000 00200000 012af358 00200000 00200000 00200000 00200000 012af368 00200000 00200000 00200000 00200000 012af378 00200000 00200000 00200000 00200000 012af388 00200000 00200000 00200000 00200000 012af398 00200000 00200000 00200000 00200000 0:000> 012af3a8 00200000 00200000 00200000 00200000 012af3b8 00200000 00200000 00200000 00200000 012af3c8 00200000 00200000 00200000 00200000 012af3d8 00200000 00200000 00200000 00200000 012af3e8 00200000 00200000 00200000 00200000 012af3f8 00200000 00200000 00200000 00200000 012af408 00200000 00200000 00200000 00200000 012af418 00200000 00200000 00200000 00200000 0:000> 012af428 00200000 00200000 00200000 00200000 012af438 00200000 00200000 00200000 00200000 012af448 00200000 00200000 00200000 00200000 012af458 00200000 00200000 00200000 00200000 012af468 00200000 00200000 00200000 00200000 012af478 00200000 00200000 00200000 00200000 012af488 00200000 00200000 00200000 00200000 012af498 00200000 00200000 00200000 00200000 0:000> 012af4a8 00200000 00200000 00200000 00200000 012af4b8 00200000 00200000 00200000 00200000 012af4c8 00200000 00200000 00200000 00200000 012af4d8 00200000 00200000 00200000 00200000 012af4e8 00200000 00200000 00200000 00200000 012af4f8 00200000 00200000 00200000 00200000 012af508 00200000 00200000 00200000 00200000 012af518 00200000 00200000 00200000 00200000 0:000> 012af528 00200000 00200000 00200000 00200000 012af538 00200000 00200000 00200000 00200000 012af548 00200000 00200000 00200000 00200000 012af558 00200000 00200000 00200000 00200000 012af568 00200000 00200000 00200000 00200000 012af578 00200000 00200000 00200000 00200000 012af588 00200000 00200000 00200000 00200000 012af598 00200000 00200000 00200000 00200000 0:000> 012af5a8 00200000 00200000 00200000 00200000 012af5b8 00200000 00200000 00200000 00200000 012af5c8 00200000 00200000 00200000 00200000 012af5d8 00200000 00200000 00200000 00200000 012af5e8 00200000 00200000 00200000 00200000 012af5f8 00200000 00200000 00200000 00200000 012af608 00200000 00200000 00200000 00200000 012af618 00200000 00200000 00200000 00200000 0:000> 012af628 00200000 00200000 00200000 00200000 012af638 00200000 00200000 00200000 00200000 012af648 00200000 00200000 00200000 00200000 012af658 00200000 00200000 00200000 00200000 012af668 00200000 00200000 00200000 00200000 012af678 00200000 00200000 00200000 00200000 012af688 00200000 00200000 00200000 00200000 012af698 00200000 00200000 00200000 00200000 0:000> 012af6a8 00200000 00200000 00200000 00200000 012af6b8 00200000 00200000 00200000 00200000 012af6c8 00200000 00200000 00200000 00200000 012af6d8 00200000 00200000 00200000 00200000 012af6e8 00200000 00200000 00200000 00200000 012af6f8 00200000 00200000 00200000 00200000 012af708 00200000 00200000 00200000 00200000 012af718 00200000 00200000 00200000 00200000 0:000> 012af728 00200000 00200000 00200000 00200000 012af738 00200000 00200000 00200000 00200000 012af748 00200000 00200000 00200000 00200000 012af758 00200000 00200000 00200000 00200000 012af768 00200000 00200000 00200000 00200000 012af778 00200000 00200000 00200000 00200000 012af788 00200000 00200000 00200000 00200000 012af798 00200000 00200000 00200000 00200000 0:000> 012af7a8 00200000 00200000 00200000 00200000 012af7b8 00200000 00200000 00200000 00200000 012af7c8 00200000 00200000 00200000 00200000 012af7d8 00200000 00200000 00200000 00200000 012af7e8 00200000 00200000 00200000 00200000 012af7f8 00200000 00200000 00200000 00200000 012af808 00200000 00200000 00200000 00200000 012af818 00200000 00200000 00200000 00200000 0:000> 012af828 00200000 00200000 00200000 00200000 012af838 00200000 00200000 00200000 00200000 012af848 00200000 00200000 00200000 00200000 012af858 00200000 00200000 00200000 00200000 012af868 00200000 00200000 00200000 00200000 012af878 00200000 00200000 00200000 00200000 012af888 00200000 00200000 00200000 00200000 012af898 00200000 00200000 00200000 00200000 0:000> 012af8a8 00200000 00200000 00200000 00200000 012af8b8 00200000 00200000 00200000 00200000 012af8c8 00200000 00200000 00200000 00200000 012af8d8 00200000 00200000 00200000 00200000 012af8e8 00200000 00200000 00200000 00200000 012af8f8 00200000 00200000 00200000 00200000 012af908 00200000 00200000 00200000 00200000 012af918 00200000 00200000 00200000 00200000 0:000> 012af928 00200000 00200000 00200000 00200000 012af938 00200000 00200000 00200000 00200000 012af948 00200000 00200000 00200000 00200000 012af958 00200000 00200000 00200000 00200000 012af968 00200000 00200000 00200000 00200000 012af978 00200000 00200000 00200000 00200000 012af988 00200000 00200000 00200000 00200000 012af998 00200000 00200000 00200000 00200000 0:000> 012af9a8 00200000 00200000 00200000 00200000 012af9b8 00200000 00200000 00200000 00200000 012af9c8 00200000 00200000 00200000 00200000 012af9d8 00200000 00200000 00200000 00200000 012af9e8 00200000 00200000 00200000 00200000 012af9f8 00200000 00200000 00200000 00200000 012afa08 00200000 00200000 00200000 00200000 012afa18 00200000 00200000 00200000 00200000 0:000> 012afa28 00200000 00200000 00200000 00200000 012afa38 00200000 00200000 00200000 00200000 012afa48 00200000 00200000 00200000 00200000 012afa58 00200000 00200000 00200000 00200000 012afa68 00200000 00200000 00200000 00200000 012afa78 00200000 00200000 00200000 00200000 012afa88 00200000 00200000 00200000 00200000 012afa98 00200000 00200000 00200000 00200000 0:000> 012afaa8 00200000 00200000 00200000 00200000 012afab8 00200000 00200000 00200000 00200000 012afac8 00200000 00200000 00200000 00200000 012afad8 00200000 00200000 00200000 00200000 012afae8 00200000 00200000 00200000 00200000 012afaf8 00200000 00200000 00200000 00200000 012afb08 00200000 00200000 00200000 00200000 012afb18 00200000 00200000 00200000 00200000 0:000> 012afb28 00200000 00200000 00200000 00200000 012afb38 00200000 00200000 00200000 00200000 012afb48 00200000 00200000 00200000 00200000 012afb58 00200000 00200000 00200000 00200000 012afb68 00200000 00200000 00200000 00200000 012afb78 00200000 00200000 00200000 00200000 012afb88 00200000 00200000 00200000 00200000 012afb98 00200000 00200000 00200000 00200000 0:000> 012afba8 00200000 00200000 00200000 00200000 012afbb8 00200000 00200000 00200000 00200000 012afbc8 00200000 00200000 00200000 00200000 012afbd8 00200000 00200000 00200000 00200000 012afbe8 00200000 00200000 00200000 00200000 012afbf8 00200000 00200000 00200000 00200000 012afc08 00200000 00200000 00200000 00200000 012afc18 00200000 00200000 00200000 00200000 0:000> 012afc28 00200000 00200000 00200000 00200000 012afc38 00200000 00200000 00200000 00200000 012afc48 00200000 00200000 00200000 00200000 012afc58 00200000 00200000 00200000 00200000 012afc68 00200000 00200000 00200000 00200000 012afc78 00200000 00200000 00200000 00200000 012afc88 00200000 00200000 00200000 00200000 012afc98 00200000 00200000 00200000 00200000 0:000> 012afca8 00200000 00200000 00200000 00200000 012afcb8 00200000 00200000 00200000 00200000 012afcc8 00200000 00200000 00200000 00200000 012afcd8 00200000 00200000 00200000 00200000 012afce8 00200000 00200000 00200000 00200000 012afcf8 00200000 00200000 00200000 00200000 012afd08 00200000 00200000 00200000 00200000 012afd18 00200000 00200000 00200000 00200000 0:000> 012afd28 00200000 00200000 00200000 00200000 012afd38 00200000 00200000 00200000 00200000 012afd48 00200000 00200000 00200000 00200000 012afd58 00200000 00200000 00200000 00200000 012afd68 00200000 00200000 00200000 00200000 012afd78 00200000 00200000 00200000 00200000 012afd88 00200000 00200000 00200000 00200000 012afd98 00200000 00200000 00200000 00200000 0:000> 012afda8 00200000 00200000 00200000 00200000 012afdb8 00200000 00200000 00200000 00200000 012afdc8 00200000 00200000 00200000 00200000 012afdd8 00200000 00200000 00200000 00200000 012afde8 00200000 00200000 00200000 00200000 012afdf8 00200000 00200000 00200000 00200000 012afe08 00200000 00200000 00200000 00200000 012afe18 00200000 00200000 00200000 00200000 0:000> 012afe28 00200000 00200000 00200000 00200000 012afe38 00200000 00200000 00200000 00200000 012afe48 00200000 00200000 00200000 00200000 012afe58 00200000 00200000 00200000 00200000 012afe68 00200000 00200000 00200000 00200000 012afe78 00200000 00200000 00200000 00200000 012afe88 00200000 00200000 00200000 00200000 012afe98 00200000 00200000 00200000 00200000 0:000> 012afea8 00200000 00200000 00200000 00200000 012afeb8 00200000 00200000 00200000 00200000 012afec8 00200000 00200000 00200000 00200000 012afed8 00200000 00200000 00200000 00200000 012afee8 00200000 00200000 00200000 00200000 012afef8 00200000 00200000 00200000 00200000 012aff08 00200000 00200000 00200000 00200000 012aff18 00200000 00200000 00200000 00200000 0:000> 012aff28 00200000 00200000 00200000 00200000 012aff38 00200000 00200000 00200000 00200000 012aff48 00200000 00200000 00200000 00200000 012aff58 00200000 00200000 00200000 00200000 012aff68 00200000 00200000 00200000 00200000 012aff78 00200000 00200000 00200000 00200000 012aff88 00200000 00200000 00200000 00200000 012aff98 00200000 00200000 00200000 00200000 0:000> 012affa8 00200000 00200000 00200000 00200000 012affb8 00200000 00200000 00200000 00200000 012affc8 00200000 00200000 00200000 00200000 012affd8 00200000 00200000 00200000 00200000 012affe8 00200000 00200000 00200000 00200000 012afff8 00200000 00200000 00000013 00000001 012b0008 00200026 012b0014 0000172e 00000000 012b0018 00000000 00000000 00000000 00000000 0:000> 012b0028 00000000 00000000 00000000 00000000 012b0038 00000000 00000000 00000000 00000000 012b0048 00000000 00000000 00000000 00000000 012b0058 00000000 00000000 00000000 00000000 012b0068 00000000 00000000 00000000 00000000 012b0078 00000000 00000000 00000000 00000000 012b0088 00000000 00000000 00000000 00000000 012b0098 00000000 00000000 00000000 00000000 0:000> 012b00a8 00000000 00000000 00000000 00000000 012b00b8 00000000 00000000 00000000 00000000 012b00c8 00000000 00000000 00000000 00000000 012b00d8 00000000 00000000 00000000 00000000 012b00e8 00000000 00000000 00000000 00000000 012b00f8 00000000 00000000 00000000 00000000 012b0108 00000000 00000000 00000000 00000000 012b0118 00000000 00000000 00000000 00000000 0:000> 012b0128 00000000 00000000 00000000 00000000 012b0138 00000000 00000000 00000000 00000000 012b0148 00000000 00000000 00000000 00000000 012b0158 00000000 00000000 00000000 00000000 012b0168 00000000 00000000 00000000 00000000 012b0178 00000000 00000000 00000000 00000000 012b0188 00000000 00000000 00000000 00000000 012b0198 00000000 00000000 00000000 00000000 0:000> 012b01a8 00000000 00000000 00000000 00000000 012b01b8 00000000 00000000 00000000 00000000 012b01c8 00000000 00000000 00000000 00000000 012b01d8 00000000 00000000 00000000 00000000 012b01e8 00000000 00000000 00000000 00000000 012b01f8 00000000 00000000 00000000 00000000 012b0208 00000000 00000000 00000000 00000000 012b0218 00000000 00000000 00000000 00000000 0:000> 012b0228 00000000 00000000 00000000 00000000 012b0238 00000000 00000000 00000000 00000000 012b0248 00000000 00000000 00000000 00000000 012b0258 00000000 00000000 00000000 00000000 012b0268 00000000 00000000 00000000 00000000 012b0278 00000000 00000000 00000000 00000000 012b0288 00000000 00000000 00000000 00000000 012b0298 00000000 00000000 00000000 00000000 0:000> 012b02a8 00000000 00000000 00000000 00000000 012b02b8 00000000 00000000 00000000 00000000 012b02c8 00000000 00000000 00000000 00000000 012b02d8 00000000 00000000 00000000 00000000 012b02e8 00000000 00000000 00000000 00000000 012b02f8 00000000 00000000 00000000 00000000 012b0308 00000000 00000000 00000000 00000000 012b0318 00000000 00000000 00000000 00000000 0:000> 012b0328 00000000 00000000 00000000 00000000 012b0338 00000000 00000000 00000000 00000000 012b0348 00000000 00000000 55000000 55005500 012b0358 55005500 55005500 55005500 55005500 012b0368 55005500 55005500 55005500 55005500 012b0378 55005500 55005500 55005500 55005500 012b0388 55005500 55005500 55005500 55005500 012b0398 55005500 55005500 55005500 55005500 0:000> 012b03a8 55005500 55005500 55005500 55005500 012b03b8 55005500 55005500 55005500 55005500 012b03c8 55005500 55005500 55005500 55005500 012b03d8 55005500 55005500 55005500 55005500 012b03e8 55005500 55005500 55005500 55005500 012b03f8 55005500 55005500 55005500 55005500 012b0408 55005500 55005500 55005500 55005500 012b0418 55005500 55005500 55005500 55005500 0:000> 012b0428 55005500 55005500 55005500 55005500 012b0438 55005500 55005500 55005500 55005500 012b0448 55005500 55005500 55005500 55005500 012b0458 55005500 55005500 00000000 55000000 012b0468 55000055 55000055 55000055 55000055 012b0478 55000055 55000055 55000055 55000055 012b0488 55000055 55000055 55000055 55000055 012b0498 55000055 55000055 55000055 55000055 0:000> 012b04a8 55000055 55000055 55000055 55000055 012b04b8 55000055 55000055 55000055 55000055 012b04c8 55000055 55000055 55000055 55000055 012b04d8 55000055 55000055 55000055 55000055 012b04e8 55000055 55000055 55000055 55000055 012b04f8 55000055 55000055 55000055 55000055 012b0508 55000055 55000055 55000055 55000055 012b0518 55000055 55000055 55000055 55000055 0:000> 012b0528 55000055 55000055 55000055 55000055 012b0538 55000055 55000055 55000055 55000055 012b0548 55000055 55000055 55000055 55000055 012b0558 55000055 55000055 55000055 55000055 012b0568 55000055 55000055 55000055 00000000 012b0578 00000000 00555555 00555555 00555555 012b0588 00555555 00555555 00555555 00555555 012b0598 00555555 00555555 00555555 00555555 0:000> 012b05a8 00555555 00555555 00555555 00555555 012b05b8 00555555 00555555 00555555 00555555 012b05c8 00555555 00555555 00555555 00555555 012b05d8 00555555 00555555 00555555 00555555 012b05e8 00555555 00555555 00555555 00555555 012b05f8 00555555 00555555 00555555 00555555 012b0608 00555555 00555555 00555555 00555555 012b0618 00555555 00555555 00555555 00555555 0:000> 012b0628 00555555 00555555 00555555 00555555 012b0638 00555555 00555555 00555555 00555555 012b0648 00555555 00555555 00555555 00555555 012b0658 00555555 00555555 00555555 00555555 012b0668 00555555 00555555 00555555 00555555 012b0678 00555555 00555555 00555555 00555555 012b0688 00000000 55000000 55005500 55005500 012b0698 55005500 55005500 55005500 55005500 0:000> 012b06a8 55005500 55005500 55005500 55005500 012b06b8 55005500 55005500 55005500 55005500 012b06c8 55005500 55005500 55005500 55005500 012b06d8 55005500 55005500 55005500 55005500 012b06e8 55005500 55005500 55005500 55005500 012b06f8 55005500 55005500 55005500 55005500 012b0708 55005500 55005500 55005500 55005500 012b0718 55005500 55005500 55005500 55005500 0:000> 012b0728 55005500 55005500 55005500 55005500 012b0738 55005500 55005500 55005500 55005500 012b0748 55005500 55005500 55005500 55005500 012b0758 55005500 55005500 55005500 55005500 012b0768 55005500 55005500 55005500 55005500 012b0778 55005500 55005500 55005500 55005500 012b0788 55005500 55005500 55005500 55005500 012b0798 55005500 00000000 00000000 00555500 0:000> 012b07a8 00555500 00555500 00555500 00555500 012b07b8 00555500 00555500 00555500 00555500 012b07c8 00555500 00555500 00555500 00555500 012b07d8 00555500 00555500 00555500 00555500 012b07e8 00555500 00555500 00555500 00555500 012b07f8 00555500 00555500 00555500 00555500 012b0808 00555500 00555500 00555500 00555500 012b0818 00555500 00555500 00555500 00555500 0:000> 012b0828 00555500 00555500 00555500 00555500 012b0838 00555500 00555500 00555500 00555500 012b0848 00555500 00555500 00555500 00555500 012b0858 00555500 00555500 00555500 00555500 012b0868 00555500 00555500 00555500 00555500 012b0878 00555500 00555500 00555500 00555500 012b0888 00555500 00555500 00555500 00555500 012b0898 00555500 00555500 00555500 00555500 0:000> 012b08a8 00555500 00555500 00000000 55000000 012b08b8 55550055 55550055 55550055 55550055 012b08c8 55550055 55550055 55550055 55550055 012b08d8 55550055 55550055 55550055 55550055 012b08e8 55550055 55550055 55550055 55550055 012b08f8 55550055 55550055 55550055 55550055 012b0908 55550055 55550055 55550055 55550055 012b0918 55550055 55550055 55550055 55550055 0:000> 012b0928 55550055 55550055 55550055 55550055 012b0938 55550055 55550055 55550055 55550055 012b0948 55550055 55550055 55550055 55550055 012b0958 55550055 55550055 55550055 55550055 012b0968 55550055 55550055 55550055 55550055 012b0978 55550055 55550055 55550055 55550055 012b0988 55550055 55550055 55550055 55550055 012b0998 55550055 55550055 55550055 55550055 0:000> 012b09a8 55550055 55550055 55550055 55550055 012b09b8 55550055 55550055 55550055 00000000 012b09c8 55000000 55005500 55005500 55005500 012b09d8 55005500 55005500 55005500 55005500 012b09e8 55005500 55005500 55005500 55005500 012b09f8 55005500 55005500 55005500 55005500 012b0a08 55005500 55005500 55005500 55005500 012b0a18 55005500 55005500 55005500 55005500 0:000> 012b0a28 55005500 55005500 55005500 55005500 012b0a38 55005500 55005500 55005500 55005500 012b0a48 55005500 55005500 55005500 55005500 012b0a58 55005500 55005500 55005500 55005500 012b0a68 55005500 55005500 55005500 55005500 012b0a78 55005500 55005500 55005500 55005500 012b0a88 55005500 55005500 55005500 55005500 012b0a98 55005500 55005500 55005500 55005500 0:000> 012b0aa8 55005500 55005500 55005500 55005500 012b0ab8 55005500 55005500 55005500 55005500 012b0ac8 55005500 55005500 55005500 55005500 012b0ad8 00000000 55000000 55000055 55000055 012b0ae8 55000055 55000055 55000055 55000055 012b0af8 55000055 55000055 55000055 55000055 012b0b08 55000055 55000055 55000055 55000055 012b0b18 55000055 55000055 55000055 55000055 0:000> 012b0b28 55000055 55000055 55000055 55000055 012b0b38 55000055 55000055 55000055 55000055 012b0b48 55000055 55000055 55000055 55000055 012b0b58 55000055 55000055 55000055 55000055 012b0b68 55000055 55000055 55000055 55000055 012b0b78 55000055 55000055 55000055 55000055 012b0b88 55000055 55000055 55000055 55000055 012b0b98 55000055 55000055 55000055 55000055 0:000> 012b0ba8 55000055 55000055 55000055 55000055 012b0bb8 55000055 55000055 55000055 55000055 012b0bc8 55000055 55000055 55000055 55000055 012b0bd8 55000055 55000055 55000055 55000055 012b0be8 55000055 00000000 00000000 00555555 012b0bf8 00555555 00555555 00555555 00555555 012b0c08 00555555 00555555 00555555 00555555 012b0c18 00555555 00555555 00555555 00555555 0:000> 012b0c28 00555555 00555555 00555555 00555555 012b0c38 00555555 00555555 00555555 00555555 012b0c48 00555555 00555555 00555555 00555555 012b0c58 00555555 00555555 00555555 00555555 012b0c68 00555555 00555555 00555555 00555555 012b0c78 00555555 00555555 00555555 00555555 012b0c88 00555555 00555555 00555555 00555555 012b0c98 00555555 00555555 00555555 00555555 0:000> 012b0ca8 00555555 00555555 00555555 00555555 012b0cb8 00555555 00555555 00555555 00555555 012b0cc8 00555555 00555555 00555555 00555555 012b0cd8 00555555 00555555 00555555 00555555 012b0ce8 00555555 00555555 00555555 00555555 012b0cf8 00555555 00555555 00000000 55000000 012b0d08 55005500 55005500 55005500 55005500 012b0d18 55005500 55005500 55005500 55005500 0:000> 012b0d28 55005500 55005500 55005500 55005500 012b0d38 55005500 55005500 55005500 55005500 012b0d48 55005500 55005500 55005500 55005500 012b0d58 55005500 55005500 55005500 55005500 012b0d68 55005500 55005500 55005500 55005500 012b0d78 55005500 55005500 55005500 55005500 012b0d88 55005500 55005500 55005500 55005500 012b0d98 55005500 55005500 55005500 55005500 0:000> 012b0da8 55005500 55005500 55005500 55005500 012b0db8 55005500 55005500 55005500 55005500 012b0dc8 55005500 55005500 55005500 55005500 012b0dd8 55005500 55005500 55005500 55005500 012b0de8 55005500 55005500 55005500 55005500 012b0df8 55005500 55005500 55005500 55005500 012b0e08 55005500 55005500 55005500 00000000 012b0e18 00000000 00555500 00555500 00555500 0:000> 012b0e28 00555500 00555500 00555500 00555500 012b0e38 00555500 00555500 00555500 00555500 012b0e48 00555500 00555500 00555500 00555500 012b0e58 00555500 00555500 00555500 00555500 012b0e68 00555500 00555500 00555500 00555500 012b0e78 00555500 00555500 00555500 00555500 012b0e88 00555500 00555500 00555500 00555500 012b0e98 00555500 00555500 00555500 00555500 0:000> 012b0ea8 00555500 00555500 00555500 00555500 012b0eb8 00555500 00555500 00555500 00555500 012b0ec8 00555500 00555500 00555500 00555500 012b0ed8 00555500 00555500 00555500 00555500 012b0ee8 00555500 00555500 00555500 00555500 012b0ef8 00555500 00555500 00555500 00555500 012b0f08 00555500 00555500 00555500 00555500 012b0f18 00555500 00555500 00555500 00555500 0:000> 012b0f28 00000000 55000000 55550055 55550055 012b0f38 55550055 55550055 55550055 55550055 012b0f48 55550055 55550055 55550055 55550055 012b0f58 55550055 55550055 55550055 55550055 012b0f68 55550055 55550055 55550055 55550055 012b0f78 55550055 55550055 55550055 55550055 012b0f88 55550055 55550055 55550055 55550055 012b0f98 55550055 55550055 55550055 55550055 0:000> 012b0fa8 55550055 55550055 55550055 55550055 012b0fb8 55550055 55550055 55550055 55550055 012b0fc8 55550055 55550055 55550055 55550055 012b0fd8 55550055 55550055 55550055 55550055 012b0fe8 55550055 55550055 55550055 55550055 012b0ff8 55550055 55550055 55550055 55550055 012b1008 55550055 55550055 55550055 55550055 012b1018 55550055 55550055 55550055 55550055 0:000> 012b1028 55550055 55550055 55550055 55550055 012b1038 55550055 00000000 55000000 55005500 012b1048 55005500 55005500 55005500 55005500 012b1058 55005500 55005500 55005500 55005500 012b1068 55005500 55005500 55005500 55005500 012b1078 55005500 55005500 55005500 55005500 012b1088 55005500 55005500 55005500 55005500 012b1098 55005500 55005500 55005500 55005500 0:000> 012b10a8 55005500 55005500 55005500 55005500 012b10b8 55005500 55005500 55005500 55005500 012b10c8 55005500 55005500 55005500 55005500 012b10d8 55005500 55005500 55005500 55005500 012b10e8 55005500 55005500 55005500 55005500 012b10f8 55005500 55005500 55005500 55005500 012b1108 55005500 55005500 55005500 55005500 012b1118 55005500 55005500 55005500 55005500 0:000> 012b1128 55005500 55005500 55005500 55005500 012b1138 55005500 55005500 55005500 55005500 012b1148 55005500 55005500 00000000 55000000 012b1158 55000055 55000055 55000055 55000055 012b1168 55000055 55000055 55000055 55000055 012b1178 55000055 55000055 55000055 55000055 012b1188 55000055 55000055 55000055 55000055 012b1198 55000055 55000055 55000055 55000055 0:000> 012b11a8 55000055 55000055 55000055 55000055 012b11b8 55000055 55000055 55000055 55000055 012b11c8 55000055 55000055 55000055 55000055 012b11d8 55000055 55000055 55000055 55000055 012b11e8 55000055 55000055 55000055 55000055 012b11f8 55000055 55000055 55000055 55000055 012b1208 55000055 55000055 55000055 55000055 012b1218 55000055 55000055 55000055 55000055 0:000> 012b1228 55000055 55000055 55000055 55000055 012b1238 55000055 55000055 55000055 55000055 012b1248 55000055 55000055 55000055 55000055 012b1258 55000055 55000055 55000055 00000000 012b1268 00000000 00555555 00555555 00555555 012b1278 00555555 00555555 00555555 00555555 012b1288 00555555 00555555 00555555 00555555 012b1298 00555555 00555555 00555555 00555555 0:000> 012b12a8 00555555 00555555 00555555 00555555 012b12b8 00555555 00555555 00555555 00555555 012b12c8 00555555 00555555 00555555 00555555 012b12d8 00555555 00555555 00555555 00555555 012b12e8 00555555 00555555 00555555 00555555 012b12f8 00555555 00555555 00555555 00555555 012b1308 00555555 00555555 00555555 00555555 012b1318 00555555 00555555 00555555 00555555 0:000> 012b1328 00555555 00555555 00555555 00555555 012b1338 00555555 00555555 00555555 00555555 012b1348 00555555 00555555 00555555 00555555 012b1358 00555555 00555555 00555555 00555555 012b1368 00555555 00555555 00555555 00555555 012b1378 00000000 55000000 55005500 55005500 012b1388 55005500 55005500 55005500 55005500 012b1398 55005500 55005500 55005500 55005500 0:000> 012b13a8 55005500 55005500 55005500 55005500 012b13b8 55005500 55005500 55005500 55005500 012b13c8 55005500 55005500 55005500 55005500 012b13d8 55005500 55005500 55005500 55005500 012b13e8 55005500 55005500 55005500 55005500 012b13f8 55005500 55005500 55005500 55005500 012b1408 55005500 55005500 55005500 55005500 012b1418 55005500 55005500 55005500 55005500 0:000> 012b1428 55005500 55005500 55005500 55005500 012b1438 55005500 55005500 55005500 55005500 012b1448 55005500 55005500 55005500 55005500 012b1458 55005500 55005500 55005500 55005500 012b1468 55005500 55005500 55005500 55005500 012b1478 55005500 55005500 55005500 55005500 012b1488 55005500 00000000 00000000 00555500 012b1498 00555500 00555500 00555500 00555500 0:000> 012b14a8 00555500 00555500 00555500 00555500 012b14b8 00555500 00555500 00555500 00555500 012b14c8 00555500 00555500 00555500 00555500 012b14d8 00555500 00555500 00555500 00555500 012b14e8 00555500 00555500 00555500 00555500 012b14f8 00555500 00555500 00555500 00555500 012b1508 00555500 00555500 00555500 00555500 012b1518 00555500 00555500 00555500 00555500 0:000> 012b1528 00555500 00555500 00555500 00555500 012b1538 00555500 00555500 00555500 00555500 012b1548 00555500 00555500 00555500 00555500 012b1558 00555500 00555500 00555500 00555500 012b1568 00555500 00555500 00555500 00555500 012b1578 00555500 00555500 00555500 00555500 012b1588 00555500 00555500 00555500 00555500 012b1598 00555500 00555500 00000000 55000000 0:000> 012b15a8 55550055 55550055 55550055 55550055 012b15b8 55550055 55550055 55550055 55550055 012b15c8 55550055 55550055 55550055 55550055 012b15d8 55550055 55550055 55550055 55550055 012b15e8 55550055 ff550055 ffffffff ffffffff 012b15f8 ffffffff 55550055 ffffffff ffffffff 012b1608 555500ff 55550055 55550055 55550055 012b1618 55550055 55550055 ffff0055 ffffffff 0:000> 012b1628 5555ffff 55550055 ff550055 ffffffff 012b1638 55ffffff 55550055 55550055 55550055 012b1648 55550055 55550055 55550055 55550055 012b1658 55550055 55550055 55550055 55550055 012b1668 55550055 55550055 55550055 55550055 012b1678 55550055 55550055 55550055 55550055 012b1688 55550055 55550055 55550055 55550055 012b1698 55550055 55550055 55550055 55550055 0:000> 012b16a8 55550055 55550055 55550055 00000000 012b16b8 55000000 55005500 55005500 55005500 012b16c8 55005500 55005500 55005500 55005500 012b16d8 55005500 55005500 55005500 55005500 012b16e8 55005500 55005500 55005500 55005500 012b16f8 55005500 55005500 55005500 ffffff00 012b1708 ffffffff 550055ff 55005500 ff005500 012b1718 55ffffff 55005500 55005500 55005500 0:000> 012b1728 55005500 55005500 55005500 ff005500 012b1738 ffffffff 55ffffff 55005500 55005500 012b1748 ffffff00 550055ff 55005500 55005500 012b1758 55005500 55005500 55005500 55005500 012b1768 55005500 ff005500 ffffffff 55ffffff 012b1778 55005500 55005500 55005500 55005500 012b1788 55005500 55005500 55005500 55005500 012b1798 55005500 55005500 55005500 55005500 0:000> 012b17a8 55005500 55005500 55005500 55005500 012b17b8 55005500 55005500 55005500 55005500 012b17c8 00000000 55000000 55000055 55000055 012b17d8 55000055 55000055 55000055 55000055 012b17e8 ffffff55 ffffffff ffffffff ffffffff 012b17f8 ffffffff ffffffff 55000055 55000055 012b1808 55000055 55000055 55000055 55000055 012b1818 ffff0055 ffffffff 55000055 55000055 0:000> 012b1828 55000055 5500ffff 55000055 55000055 012b1838 55000055 55000055 55000055 55000055 012b1848 55000055 ffffffff ffffffff 55000055 012b1858 55000055 ffff0055 55000055 55000055 012b1868 55000055 55000055 55000055 55000055 012b1878 55000055 55000055 ffffffff 550000ff 012b1888 ffffff55 5500ffff 55000055 55000055 012b1898 55000055 55000055 55000055 55000055 0:000> 012b18a8 55000055 55000055 55000055 55000055 012b18b8 ffffff55 55ffffff 55000055 55000055 012b18c8 55000055 55000055 55000055 55000055 012b18d8 55000055 00000000 00000000 00555555 012b18e8 00555555 00555555 00555555 00555555 012b18f8 00555555 ffffff55 ffffffff ffffffff 012b1908 ffffffff ffffffff ffffffff 00555555 012b1918 00555555 00555555 00555555 00555555 0:000> 012b1928 00555555 ffff5555 ffffffff 00555555 012b1938 00555555 00555555 0055ffff 00555555 012b1948 00555555 00555555 00555555 00555555 012b1958 00555555 00555555 ffffff55 ffffffff 012b1968 005555ff 00555555 ffff5555 00555555 012b1978 00555555 00555555 00555555 00555555 012b1988 00555555 00555555 ff555555 00ffffff 012b1998 00555555 ff555555 00ffffff 00555555 0:000> 012b19a8 00555555 00555555 00555555 00555555 012b19b8 00555555 00555555 00555555 00555555 012b19c8 ffff5555 ffffffff ffffffff 0055ffff 012b19d8 00555555 00555555 00555555 00555555 012b19e8 00555555 00555555 00000000 55000000 012b19f8 55005500 55005500 55005500 55005500 012b1a08 55005500 55005500 55005500 ffff5500 012b1a18 ffffffff ffffffff ffffffff 55005500 0:000> 012b1a28 55005500 55005500 00005500 55005500 012b1a38 55005500 55005500 ffff5500 ffffffff 012b1a48 55005500 55005500 55005500 5500ffff 012b1a58 55005500 00005500 00550055 00550000 012b1a68 55000055 55005500 55005500 ffffff00 012b1a78 ffffffff 550055ff 55005500 ffff5500 012b1a88 55005500 55005500 00550000 00000055 012b1a98 00550055 55005500 55005500 ffff5500 0:000> 012b1aa8 5500ffff 55005500 55005500 ffffffff 012b1ab8 55005500 55005500 00005500 00550055 012b1ac8 00550000 55000055 55005500 55005500 012b1ad8 55005500 ffffff00 ffffffff ffffffff 012b1ae8 ffffffff 55005500 55005500 55005500 012b1af8 55005500 55005500 55005500 00000000 012b1b08 00000000 00555500 00555500 00555500 012b1b18 00555500 00555500 00555500 00555500 0:000> 012b1b28 ff555500 ffffffff ffffffff 00ffffff 012b1b38 00555500 00555500 00555500 00005500 012b1b48 00555500 00555500 00555500 ffff5500 012b1b58 ffffffff 00555500 00555500 00555500 012b1b68 0055ffff 00555500 55555500 00550000 012b1b78 55550000 00550000 00555500 00555500 012b1b88 ffffff00 ffffffff 0055ffff 00555500 012b1b98 ffff5500 00555500 00555500 00005500 0:000> 012b1ba8 00000055 00005555 00555500 00555500 012b1bb8 ffffff00 0055ffff 00555500 00555500 012b1bc8 ffffffff 005555ff 00555500 55555500 012b1bd8 00550000 55550000 00550000 00555500 012b1be8 00555500 ff555500 ffffffff ffffffff 012b1bf8 ffffffff ffffffff 005555ff 00555500 012b1c08 00555500 00555500 00555500 00555500 012b1c18 00000000 55000000 55550055 55550055 0:000> 012b1c28 55550055 55550055 55550055 55550055 012b1c38 55550055 55550055 ffffffff ffffffff 012b1c48 5555ffff 55550055 55550055 55550055 012b1c58 00000055 55550000 55550055 55550055 012b1c68 ffff0055 ffffffff 55550055 55550055 012b1c78 55550055 5555ffff 55550055 55550055 012b1c88 00005555 55000000 55555555 55550055 012b1c98 55550055 55ffff55 ffffffff 55ffffff 0:000> 012b1ca8 55550055 ffff0055 55550055 55550055 012b1cb8 55555555 00000000 55555500 55550055 012b1cc8 55550055 ffffffff 555500ff 55550055 012b1cd8 55550055 ffffff55 5555ffff 55550055 012b1ce8 55550055 00005555 55000000 55555555 012b1cf8 55550055 55550055 ffff0055 ffffffff 012b1d08 ffffffff ffffffff ffffffff 5555ffff 012b1d18 55550055 55550055 55550055 55550055 0:000> 012b1d28 55550055 00000000 55000000 55005500 012b1d38 55005500 55005500 55005500 55005500 012b1d48 55005500 55005500 55005500 ffffffff 012b1d58 ffffffff 5500ffff 55005500 55005500 012b1d68 55005500 00000000 55000000 55005500 012b1d78 55005500 ffff5500 ffffffff 55005500 012b1d88 55005500 55005500 5500ffff 55005500 012b1d98 00005500 00000055 00000000 55000055 0:000> 012b1da8 55005500 55005500 55ffff00 ffffffff 012b1db8 ffffffff 55005500 ffff5500 55005500 012b1dc8 55005500 00550000 00000000 00550000 012b1dd8 55005500 ff005500 ffffffff 550055ff 012b1de8 55005500 55005500 ffffff00 55ffffff 012b1df8 55005500 00005500 00000055 00000000 012b1e08 55000055 55005500 55005500 ffff5500 012b1e18 ffffffff ffffffff ffffffff ffffffff 0:000> 012b1e28 5500ffff 55005500 55005500 55005500 012b1e38 55005500 55005500 00000000 55000000 012b1e48 55000055 55000055 55000055 55000055 012b1e58 55000055 55000055 55000055 55000055 012b1e68 ffffffff ffffffff 5500ffff 55000055 012b1e78 55000055 55000055 00000055 55000000 012b1e88 55000055 55000055 ffff0055 ffffffff 012b1e98 55000055 55000055 55000055 5500ffff 0:000> 012b1ea8 55000055 00000055 00005555 00000000 012b1eb8 55005555 55000055 55000055 55ffff55 012b1ec8 ffffff55 ffffffff 550000ff ffff0055 012b1ed8 55000055 55000055 55550055 00000000 012b1ee8 55550000 55000055 ff000055 ffffffff 012b1ef8 55000055 55000055 55000055 ffff0055 012b1f08 55ffffff 55000055 00000055 00005555 012b1f18 00000000 55005555 55000055 55000055 0:000> 012b1f28 ffffff55 ffffffff ffffffff ffffffff 012b1f38 ffffffff 55ffffff 55000055 55000055 012b1f48 55000055 55000055 55000055 00000000 012b1f58 00000000 00555555 00555555 00555555 012b1f68 00555555 00555555 00555555 00555555 012b1f78 00555555 ffffffff ffffffff 0055ffff 012b1f88 00555555 00555555 00555555 00000000 012b1f98 00000000 00555555 00555555 ffff5555 0:000> 012b1fa8 ffffffff 00555555 00555555 00555555 012b1fb8 0055ffff 00555555 55555555 00000000 012b1fc8 00000000 00555500 00555555 00555555 012b1fd8 00ffff55 ffff5555 ffffffff 005555ff 012b1fe8 ffff5555 00555555 00555555 00005555 012b1ff8 00000000 55000000 00555555 ff555555 012b2008 ffffffff 00555555 00555555 00555555 012b2018 ffff5555 00ffffff 00555555 55555555 0:000> 012b2028 00000000 00000000 00555500 00555555 012b2038 00555555 ffffffff 005555ff ffff5555 012b2048 ffffffff ffffffff 00ffffff 00555555 012b2058 00555555 00555555 00555555 00555555 012b2068 00000000 55000000 55005500 55005500 012b2078 55005500 55005500 55005500 55005500 012b2088 55005500 55005500 ffffffff ffffffff 012b2098 5500ffff 55005500 55005500 55005500 0:000> 012b20a8 00000000 55000000 55005500 55005500 012b20b8 ffff5500 ffffffff 55005500 55005500 012b20c8 55005500 5500ffff 55005500 00005500 012b20d8 00000055 00000000 55000055 55005500 012b20e8 55005500 55ffff00 ff005500 ffffffff 012b20f8 5500ffff ffff5500 55005500 55005500 012b2108 00550000 00000000 00550000 55005500 012b2118 ffff5500 ffffffff 55005500 55005500 0:000> 012b2128 55005500 ffff5500 ffffffff 55005500 012b2138 00005500 00000055 00000000 55000055 012b2148 55005500 55005500 55ffffff 55005500 012b2158 55005500 ffffffff ffffffff ffffffff 012b2168 55005500 55005500 55005500 55005500 012b2178 55005500 00000000 00000000 00555500 012b2188 00555500 00555500 00555500 00555500 012b2198 00555500 00555500 00555500 ffffffff 0:000> 012b21a8 ffffffff 0055ffff 00555500 00555500 012b21b8 00555500 00000000 00000000 00555500 012b21c8 00555500 ffff5500 ffffffff 00555500 012b21d8 00555500 00555500 0055ffff 00555500 012b21e8 55555500 00000000 00000000 00550000 012b21f8 00555500 00555500 00ffff00 00555500 012b2208 ffffffff 00ffffff ffff5500 00555500 012b2218 00555500 00005500 00000000 00000000 0:000> 012b2228 00555500 ffff5500 ffffffff 00555500 012b2238 00555500 00555500 ffff5500 ffffffff 012b2248 00555500 55555500 00000000 00000000 012b2258 00550000 00555500 ff555500 0055ffff 012b2268 00555500 00555500 ffffff00 ffffffff 012b2278 ffffffff 00555500 00555500 00555500 012b2288 00555500 00555500 00000000 55000000 012b2298 55550055 55550055 55550055 55550055 0:000> 012b22a8 55550055 55550055 55550055 55550055 012b22b8 ffffffff ffffffff 5555ffff 55550055 012b22c8 55550055 00000055 00000000 00000000 012b22d8 55550000 55550055 ffff0055 ffffffff 012b22e8 55550055 55550055 55550055 5555ffff 012b22f8 55550055 00550055 00000000 00000000 012b2308 55550000 55550055 55550055 55ffff55 012b2318 55550055 ffffff55 ffffffff ffff0055 0:000> 012b2328 55550055 55550055 00000055 00000000 012b2338 00000000 55550055 ffff0055 ffffffff 012b2348 55550055 55550055 55550055 ffff0055 012b2358 ffffffff 55550055 00550055 00000000 012b2368 00000000 55550000 55550055 ff550055 012b2378 555500ff 55550055 55550055 ffff0055 012b2388 ffffffff ffffffff 55550055 55550055 012b2398 55550055 55550055 55550055 00000000 0:000> 012b23a8 55000000 55005500 55005500 55005500 012b23b8 55005500 55005500 55005500 55005500 012b23c8 55005500 ffffffff ffffffff 5500ffff 012b23d8 55005500 55005500 00005500 00000000 012b23e8 00000000 55005500 55005500 ffff5500 012b23f8 ffffffff 55005500 55005500 55005500 012b2408 5500ffff 55005500 00005500 00000000 012b2418 00000000 55000000 55005500 55005500 0:000> 012b2428 55ffff00 55005500 ffffff00 ffffffff 012b2438 ffff55ff 55005500 55005500 00000000 012b2448 00000000 00000000 55005500 ffff5500 012b2458 ffffffff 55005500 55005500 55005500 012b2468 ffff5500 ffffffff 55005500 00005500 012b2478 00000000 00000000 55000000 55005500 012b2488 ffff5500 55005500 55005500 55005500 012b2498 ffff5500 ffffffff ffffffff 55005500 0:000> 012b24a8 55005500 55005500 55005500 55005500 012b24b8 00000000 55000000 55000055 55000055 012b24c8 55000055 55000055 55000055 55000055 012b24d8 55000055 55000055 ffffffff ffffffff 012b24e8 5500ffff 55000055 55000055 00000055 012b24f8 00000000 00000000 55000000 55000055 012b2508 ffff0055 ffffffff 55000055 55000055 012b2518 55000055 5500ffff 55000055 00000055 0:000> 012b2528 00000000 00000000 55000000 55000055 012b2538 55000055 55ffff55 55000055 ffff0055 012b2548 ffffffff ffff00ff 55000055 55000055 012b2558 00000055 00000000 00000000 55000055 012b2568 ffff0055 ffffffff 55000055 55000055 012b2578 55000055 ffff0055 ffffffff 55000055 012b2588 00000055 00000000 00000000 55000000 012b2598 55000055 55000055 55000055 55000055 0:000> 012b25a8 55000055 ff000055 ffffffff ffffffff 012b25b8 55000055 55000055 55000055 55000055 012b25c8 55000055 00000000 00000000 00555555 012b25d8 00555555 00555555 00555555 00555555 012b25e8 00555555 00555555 00555555 ffffffff 012b25f8 ffffffff 0055ffff 00555555 00555555 012b2608 00555555 00000000 00000000 00555555 012b2618 00555555 ffff5555 ffffffff 00555555 0:000> 012b2628 00555555 00555555 0055ffff 00555555 012b2638 55555555 00000000 00000000 00555500 012b2648 00555555 00555555 00ffff55 00555555 012b2658 ff555555 ffffffff ffffffff 00555555 012b2668 00555555 00005555 00000000 55000000 012b2678 00555555 ffff5555 ffffffff 00555555 012b2688 00555555 00555555 ffff5555 ffffffff 012b2698 00555555 55555555 00000000 00000000 0:000> 012b26a8 00555500 00555555 00555555 00555555 012b26b8 00555555 00555555 ff555555 ffffffff 012b26c8 ffffffff 00555555 00555555 00555555 012b26d8 00555555 00555555 00000000 55000000 012b26e8 55005500 55005500 55005500 55005500 012b26f8 55005500 55005500 55005500 55005500 012b2708 ffffffff ffffffff 5500ffff 55005500 012b2718 55005500 55005500 00000000 55000000 0:000> 012b2728 55005500 55005500 ffff5500 ffffffff 012b2738 55005500 55005500 55005500 5500ffff 012b2748 55005500 00005500 00000055 00000000 012b2758 55000055 55005500 55005500 55ffff00 012b2768 55005500 55005500 ffffffff ffffffff 012b2778 55005500 55005500 00550000 00000000 012b2788 00550000 55005500 ffff5500 ffffffff 012b2798 55005500 55005500 55005500 ffff5500 0:000> 012b27a8 ffffffff 55005500 00005500 00000055 012b27b8 00000000 55000055 55005500 55005500 012b27c8 55005500 55005500 55005500 ff005500 012b27d8 ffffffff 55ffffff 55005500 55005500 012b27e8 55005500 55005500 55005500 00000000 012b27f8 00000000 00555500 00555500 00555500 012b2808 00555500 00555500 00555500 00555500 012b2818 00555500 ffffffff ffffffff 0055ffff 0:000> 012b2828 00555500 00555500 00555500 00000000 012b2838 00000000 00555500 00555500 ffff5500 012b2848 ffffffff 00555500 00555500 00555500 012b2858 0055ffff 00555500 55555500 00000000 012b2868 00000000 00550000 00555500 00555500 012b2878 00ffff00 00555500 00555500 ffffff00 012b2888 ffffffff 00555500 00555500 00005500 012b2898 00000000 00000000 00555500 ff555500 0:000> 012b28a8 ffffffff 00555500 00555500 00555500 012b28b8 ffff5500 00ffffff 00555500 55555500 012b28c8 00000000 00000000 00550000 00555500 012b28d8 00555500 00555500 00555500 00555500 012b28e8 ff555500 ffffffff 00ffffff 00555500 012b28f8 00555500 00555500 00555500 00555500 012b2908 00000000 55000000 55550055 55550055 012b2918 55550055 55550055 55550055 55550055 0:000> 012b2928 55550055 55550055 ffffffff ffffffff 012b2938 5555ffff 55550055 55550055 55550055 012b2948 00000055 55550000 55550055 55550055 012b2958 ffff0055 ffffffff 55550055 55550055 012b2968 55550055 555500ff 55550055 55550055 012b2978 00005555 55000000 55555555 55550055 012b2988 55550055 55ffff55 55550055 55550055 012b2998 ffffff55 ffffffff 55550055 55550055 0:000> 012b29a8 55555555 00000000 55555500 55550055 012b29b8 ff550055 ffffffff 55550055 55550055 012b29c8 55550055 ffff0055 55ffffff 55550055 012b29d8 55550055 00005555 55000000 55555555 012b29e8 55550055 55550055 55550055 55550055 012b29f8 55550055 ff550055 ffffffff 55ffffff 012b2a08 55550055 55550055 55550055 55550055 012b2a18 55550055 00000000 55000000 55005500 0:000> 012b2a28 55005500 55005500 55005500 55005500 012b2a38 55005500 55005500 55005500 ffffffff 012b2a48 ffffffff 5500ffff 55005500 55005500 012b2a58 55005500 00000000 55000000 55005500 012b2a68 55005500 ff005500 ffffffff 55005500 012b2a78 55005500 ff005500 550055ff 55005500 012b2a88 00005500 00000055 00000000 55000055 012b2a98 55005500 55005500 55ffff00 55005500 0:000> 012b2aa8 55005500 ffff5500 ffffffff 55005500 012b2ab8 55005500 00550000 00000000 00550000 012b2ac8 55005500 ff005500 ffffffff 550055ff 012b2ad8 55005500 55005500 ffffff00 55ffffff 012b2ae8 55005500 00005500 00000055 00000000 012b2af8 55000055 55005500 55005500 55005500 012b2b08 55005500 55005500 ff005500 ffffffff 012b2b18 5500ffff 55005500 55005500 55005500 0:000> 012b2b28 55005500 55005500 00000000 55000000 012b2b38 55000055 55000055 55000055 55000055 012b2b48 55000055 55000055 55000055 55000055 012b2b58 ffffffff ffffffff 5500ffff 55000055 012b2b68 55000055 55000055 00000055 55000000 012b2b78 55000055 55000055 ff000055 ffffffff 012b2b88 550000ff 55000055 ff000055 550000ff 012b2b98 55000055 00000055 00005555 00000000 0:000> 012b2ba8 55005555 55000055 55000055 55ffff55 012b2bb8 55000055 55000055 ff000055 ffffffff 012b2bc8 55000055 55000055 55550055 00000000 012b2bd8 55550000 55000055 55000055 ffffffff 012b2be8 550000ff 55000055 55000055 ffffff55 012b2bf8 5500ffff 55000055 00000055 00005555 012b2c08 00000000 55005555 55000055 55000055 012b2c18 55000055 55000055 55000055 ffff0055 0:000> 012b2c28 ffffffff 5500ffff 55000055 55000055 012b2c38 55000055 55000055 55000055 00000000 012b2c48 00000000 00555555 00555555 00555555 012b2c58 00555555 00555555 00555555 00555555 012b2c68 00555555 ffffffff ffffffff 0055ffff 012b2c78 00555555 00555555 00555555 00005555 012b2c88 00555500 00555555 00555555 00555555 012b2c98 ffffffff 005555ff 00555555 ffff5555 0:000> 012b2ca8 00555555 00555555 55555555 00555500 012b2cb8 55550000 00555500 00555555 00555555 012b2cc8 00ffff55 00555555 00555555 00555555 012b2cd8 ffffffff 00555555 00555555 55005555 012b2ce8 00000055 55005555 00555555 00555555 012b2cf8 ffffff55 005555ff 00555555 00555555 012b2d08 ffffff55 005555ff 00555555 55555555 012b2d18 00555500 55550000 00555500 00555555 0:000> 012b2d28 00555555 00555555 00555555 00555555 012b2d38 ffff5555 ffffffff 005555ff 00555555 012b2d48 00555555 00555555 00555555 00555555 012b2d58 00000000 55000000 55005500 55005500 012b2d68 55005500 55005500 55005500 55005500 012b2d78 55005500 55005500 ffffffff ffffffff 012b2d88 5500ffff 55005500 55005500 55005500 012b2d98 00005500 55005500 55005500 55005500 0:000> 012b2da8 55005500 ffffff00 55ffffff 55005500 012b2db8 55ffff00 55005500 55005500 00005500 012b2dc8 00550055 00550000 55000055 55005500 012b2dd8 55005500 55ffff00 55005500 55005500 012b2de8 55005500 ffffff00 55005500 55005500 012b2df8 00550000 00000055 00550055 55005500 012b2e08 55005500 ffffff00 5500ffff 55005500 012b2e18 55005500 ffffffff 55005500 55005500 0:000> 012b2e28 00005500 00550055 00550000 55000055 012b2e38 55005500 55005500 55005500 55005500 012b2e48 55005500 ffff5500 ffffffff 55005500 012b2e58 55005500 55005500 55005500 55005500 012b2e68 55005500 00000000 00000000 00555500 012b2e78 00555500 00555500 00555500 00555500 012b2e88 00555500 00555500 00555500 ffffffff 012b2e98 ffffffff 0055ffff 00555500 00555500 0:000> 012b2ea8 00555500 00555500 00555500 00555500 012b2eb8 00555500 00555500 ffff5500 ffffffff 012b2ec8 ffffffff 0055ffff 00555500 00555500 012b2ed8 00555500 00555500 00555500 00555500 012b2ee8 00555500 00555500 ffffffff 00555500 012b2ef8 00555500 00555500 ffff5500 00555500 012b2f08 00555500 00555500 00555500 00555500 012b2f18 00555500 00555500 ff555500 00ffffff 0:000> 012b2f28 00555500 ff555500 00ffffff 00555500 012b2f38 00555500 00555500 00555500 00555500 012b2f48 00555500 00555500 00555500 00555500 012b2f58 00555500 00555500 ffffff00 ffffffff 012b2f68 00555500 00555500 00555500 00555500 012b2f78 00555500 00555500 00000000 55000000 012b2f88 55550055 55550055 55550055 55550055 012b2f98 55550055 55550055 55550055 55550055 0:000> 012b2fa8 ffffffff ffffffff 5555ffff 55550055 012b2fb8 55550055 55550055 55550055 55550055 012b2fc8 55550055 55550055 55550055 55550055 012b2fd8 ffffff55 55ffffff 55550055 55550055 012b2fe8 55550055 55550055 55550055 55550055 012b2ff8 55550055 55550055 ffff0055 ffffffff 012b3008 5555ffff 55550055 55550055 ffff0055 012b3018 55550055 55550055 55550055 55550055 0:000> 012b3028 55550055 55550055 55550055 55550055 012b3038 ffffffff 55550055 ffff0055 5555ffff 012b3048 55550055 55550055 55550055 55550055 012b3058 55550055 55550055 55550055 55550055 012b3068 55550055 55550055 55550055 ffffff55 012b3078 55ffffff 55550055 55550055 55550055 012b3088 55550055 55550055 55550055 00000000 012b3098 55000000 55005500 55005500 55005500 0:000> 012b30a8 55005500 55005500 55005500 55005500 012b30b8 55005500 ffffffff ffffffff 5500ffff 012b30c8 55005500 55005500 55005500 55005500 012b30d8 55005500 55005500 55005500 55005500 012b30e8 55005500 55005500 55005500 55005500 012b30f8 55005500 55005500 55005500 55005500 012b3108 55005500 55005500 55005500 55005500 012b3118 55005500 55005500 55005500 55005500 0:000> 012b3128 55005500 55005500 55005500 55005500 012b3138 55005500 55005500 55005500 55005500 012b3148 55005500 ff005500 ffffffff 55ffffff 012b3158 55005500 55005500 55005500 55005500 012b3168 55005500 55005500 55005500 55005500 012b3178 55005500 55005500 55005500 55005500 012b3188 ffffffff 5500ffff 55005500 55005500 012b3198 55005500 55005500 55005500 55005500 0:000> 012b31a8 00000000 55000000 55000055 55000055 012b31b8 55000055 55000055 55000055 55000055 012b31c8 55000055 55000055 ffffffff ffffffff 012b31d8 5500ffff 55000055 55000055 55000055 012b31e8 55000055 55000055 55000055 55000055 012b31f8 55000055 55000055 55000055 55000055 012b3208 55000055 55000055 55000055 55000055 012b3218 55000055 55000055 55000055 55000055 0:000> 012b3228 55000055 55000055 55000055 55000055 012b3238 55000055 55000055 55000055 55000055 012b3248 55000055 55000055 55000055 55000055 012b3258 55000055 55000055 55000055 55000055 012b3268 55000055 55000055 55000055 55000055 012b3278 55000055 55000055 55000055 55000055 012b3288 55000055 55000055 55000055 55000055 012b3298 ff000055 ffffffff 550000ff 55000055 0:000> 012b32a8 55000055 55000055 55000055 55000055 012b32b8 55000055 00000000 00000000 00555555 012b32c8 00555555 00555555 00555555 00555555 012b32d8 00555555 00555555 00555555 ffffffff 012b32e8 ffffffff 0055ffff 00555555 00555555 012b32f8 00555555 00555555 00555555 00555555 012b3308 00555555 00555555 00555555 00555555 012b3318 00555555 00555555 00555555 00555555 0:000> 012b3328 00555555 00555555 00555555 00555555 012b3338 00555555 00555555 00555555 00555555 012b3348 00555555 00555555 00555555 00555555 012b3358 00555555 00555555 00555555 00555555 012b3368 00555555 00555555 00555555 00555555 012b3378 00555555 00555555 00555555 00555555 012b3388 00555555 00555555 00555555 00555555 012b3398 00555555 00555555 00555555 00555555 0:000> 012b33a8 00555555 ff555555 ffffffff 00555555 012b33b8 00555555 00555555 00555555 00555555 012b33c8 00555555 00555555 00000000 55000000 012b33d8 55005500 55005500 55005500 55005500 012b33e8 55005500 55005500 55005500 55005500 012b33f8 ffffffff ffffffff 5500ffff 55005500 012b3408 55005500 55005500 55005500 55005500 012b3418 55005500 55005500 55005500 55005500 0:000> 012b3428 55005500 55005500 55005500 55005500 012b3438 55005500 55005500 55005500 55005500 012b3448 55005500 55005500 55005500 55005500 012b3458 55005500 55005500 55005500 55005500 012b3468 55005500 55005500 55005500 55005500 012b3478 55005500 55005500 55005500 55005500 012b3488 55005500 55005500 55005500 55005500 012b3498 55005500 55005500 55005500 55005500 0:000> 012b34a8 55005500 55005500 55005500 55005500 012b34b8 55005500 55005500 ffff5500 55ffffff 012b34c8 55005500 55005500 55005500 55005500 012b34d8 55005500 55005500 55005500 00000000 012b34e8 00000000 00555500 00555500 00555500 012b34f8 00555500 00555500 00555500 00555500 012b3508 00555500 ffffffff ffffffff 0055ffff 012b3518 00555500 00555500 00555500 00555500 0:000> 012b3528 00555500 00555500 00555500 00555500 012b3538 00555500 00555500 00555500 00555500 012b3548 00555500 00555500 00555500 00555500 012b3558 00555500 00555500 00555500 00555500 012b3568 00555500 00555500 00555500 00555500 012b3578 00555500 00555500 00555500 00555500 012b3588 00555500 00555500 00555500 00555500 012b3598 00555500 00555500 00555500 00555500 0:000> 012b35a8 00555500 00555500 00555500 00555500 012b35b8 00555500 00555500 00555500 00555500 012b35c8 00555500 00555500 00555500 ffffff00 012b35d8 005555ff 00555500 00555500 00555500 012b35e8 00555500 00555500 00555500 00555500 012b35f8 00000000 55000000 55550055 55550055 012b3608 55550055 55550055 55550055 55550055 012b3618 55550055 55550055 ffffffff ffffffff 0:000> 012b3628 5555ffff 55550055 55550055 55550055 012b3638 55550055 55550055 55550055 55550055 012b3648 55550055 55550055 55550055 55550055 012b3658 55550055 55550055 55550055 55550055 012b3668 55550055 55550055 55550055 55550055 012b3678 55550055 55550055 55550055 55550055 012b3688 55550055 55550055 55550055 55550055 012b3698 55550055 55550055 55550055 55550055 0:000> 012b36a8 55550055 55550055 55550055 55550055 012b36b8 55550055 55550055 55550055 55550055 012b36c8 55550055 55550055 55550055 55550055 012b36d8 55550055 55550055 55550055 55550055 012b36e8 ffffffff 55550055 55550055 55550055 012b36f8 55550055 55550055 55550055 55550055 012b3708 55550055 00000000 55000000 55005500 012b3718 55005500 55005500 55005500 55005500 0:000> 012b3728 55005500 55005500 55005500 ffffffff 012b3738 ffffffff 5500ffff 55005500 55005500 012b3748 55005500 55005500 55005500 55005500 012b3758 55005500 55005500 55005500 55005500 012b3768 55005500 55005500 55005500 55005500 012b3778 55005500 55005500 55005500 55005500 012b3788 55005500 55005500 55005500 55005500 012b3798 55005500 55005500 55005500 55005500 0:000> 012b37a8 55005500 55005500 55005500 55005500 012b37b8 55005500 55005500 55005500 55005500 012b37c8 55005500 55005500 55005500 55005500 012b37d8 55005500 55005500 55005500 55005500 012b37e8 55005500 55005500 55005500 55005500 012b37f8 55005500 55ffffff 55005500 55005500 012b3808 55005500 55ffff00 55005500 55005500 012b3818 55005500 55005500 00000000 55000000 0:000> 012b3828 55000055 55000055 55000055 55000055 012b3838 55000055 55000055 55000055 55000055 012b3848 ffffffff ffffffff 5500ffff 55000055 012b3858 55000055 55000055 55000055 55000055 012b3868 55000055 55000055 00000055 55000055 012b3878 55000055 55000055 55000055 55000055 012b3888 55000055 00000055 55000000 55000055 012b3898 55000055 55000055 55000055 55000055 0:000> 012b38a8 55000055 00000000 55000055 55000055 012b38b8 55000055 55000055 55000055 55000055 012b38c8 00000055 55000000 55000055 55000055 012b38d8 55000055 55000055 55000055 55000055 012b38e8 55000000 55000055 55000055 55000055 012b38f8 55000055 55000055 55000055 55000055 012b3908 55000055 ff000055 5500ffff 55000055 012b3918 55000055 55000055 5500ffff 55000055 0:000> 012b3928 55000055 55000055 55000055 00000000 012b3938 00000000 00555555 00555555 00555555 012b3948 00555555 00555555 00555555 00555555 012b3958 00555555 ffffffff ffffffff 0055ffff 012b3968 00555555 00555555 00555555 00555555 012b3978 00555555 00555555 00555555 00000000 012b3988 00550000 00555555 00555555 00555555 012b3998 00555555 00555555 00000055 00000000 0:000> 012b39a8 00555555 00555555 00555555 00555555 012b39b8 00555555 00555555 00000000 00555500 012b39c8 00555555 00555555 00555555 00555555 012b39d8 00555555 00000055 00000000 00555555 012b39e8 00555555 00555555 00555555 00555555 012b39f8 00555555 00000000 00555500 00555555 012b3a08 00555555 00555555 00555555 00555555 012b3a18 00555555 00555555 ffff5555 005555ff 0:000> 012b3a28 00555555 00555555 00555555 0055ffff 012b3a38 00555555 00555555 00555555 00555555 012b3a48 00000000 55000000 55005500 55005500 012b3a58 55005500 55005500 55005500 55005500 012b3a68 55005500 55005500 ffffffff ffffffff 012b3a78 5500ffff 55005500 55005500 55005500 012b3a88 55005500 55005500 55005500 00005500 012b3a98 00000000 55000000 55005500 55005500 0:000> 012b3aa8 55005500 55005500 55005500 00000000 012b3ab8 00000000 55005500 55005500 55005500 012b3ac8 55005500 55005500 00005500 00000000 012b3ad8 55000000 55005500 55005500 55005500 012b3ae8 55005500 00005500 00000000 00000000 012b3af8 55005500 55005500 55005500 55005500 012b3b08 55005500 00000000 00000000 55000000 012b3b18 55005500 55005500 55005500 55005500 0:000> 012b3b28 55005500 55005500 55005500 ffffff00 012b3b38 55005500 55005500 55005500 ff005500 012b3b48 5500ffff 55005500 55005500 55005500 012b3b58 55005500 00000000 00000000 00555500 012b3b68 00555500 00555500 00555500 00555500 012b3b78 00555500 00555500 00555500 ffffffff 012b3b88 ffffffff 0055ffff 00555500 00555500 012b3b98 00555500 00555500 00555500 00555500 0:000> 012b3ba8 00000000 00000000 00000000 00555500 012b3bb8 00555500 00555500 00555500 00005500 012b3bc8 00000000 00000000 00550000 00555500 012b3bd8 00555500 00555500 00555500 00000000 012b3be8 00000000 00000000 00555500 00555500 012b3bf8 00555500 00555500 00005500 00000000 012b3c08 00000000 00550000 00555500 00555500 012b3c18 00555500 00555500 00000000 00000000 0:000> 012b3c28 00000000 00555500 00555500 00555500 012b3c38 00555500 00555500 00555500 00555500 012b3c48 00ffffff 00555500 00555500 00555500 012b3c58 ffff5500 0055ffff 00555500 00555500 012b3c68 00555500 00555500 00000000 55000000 012b3c78 55550055 55550055 55550055 55550055 012b3c88 55550055 55550055 55550055 55550055 012b3c98 ffffffff ffffffff 5555ffff 55550055 0:000> 012b3ca8 55550055 55550055 55550055 55550055 012b3cb8 00550055 00000000 00000000 00000000 012b3cc8 55550000 55550055 55550055 55550055 012b3cd8 00000055 00000000 00000000 00000000 012b3ce8 55550055 55550055 55550055 00550055 012b3cf8 00000000 00000000 00000000 55550000 012b3d08 55550055 55550055 55550055 00000055 012b3d18 00000000 00000000 55000000 55550055 0:000> 012b3d28 55550055 55550055 00000055 00000000 012b3d38 00000000 00000000 55550000 55550055 012b3d48 55550055 55550055 55550055 55550055 012b3d58 ff550055 ffffffff ffffffff ffffffff 012b3d68 ffffffff ffffffff 555500ff 55550055 012b3d78 55550055 55550055 55550055 00000000 012b3d88 55000000 55005500 55005500 55005500 012b3d98 55005500 55005500 5500ff00 55005500 0:000> 012b3da8 55005500 ffffffff ffffffff 5500ffff 012b3db8 55005500 55005500 55005500 55005500 012b3dc8 55005500 00005500 00000000 00000000 012b3dd8 00000000 55000000 55005500 55005500 012b3de8 55005500 00000000 00000000 00000000 012b3df8 00000000 55005500 55005500 55005500 012b3e08 00000000 00000000 00000000 00000000 012b3e18 55000000 55005500 55005500 00005500 0:000> 012b3e28 00000000 55000000 00000000 00000000 012b3e38 55005500 55005500 55005500 00000000 012b3e48 00000000 00005500 00000000 55000000 012b3e58 55005500 55005500 55005500 55005500 012b3e68 55005500 ffff5500 ffffffff ffffffff 012b3e78 ffffffff ffffffff ffffffff 550055ff 012b3e88 55005500 55005500 55005500 55005500 012b3e98 00000000 55000000 55000055 55000055 0:000> 012b3ea8 55000055 55000055 ff000055 ffffffff 012b3eb8 55000055 55000055 ffffffff ffffffff 012b3ec8 5500ffff 55000055 55000055 55000055 012b3ed8 55000055 55000055 00000000 00000000 012b3ee8 55000000 00000000 00000000 55000000 012b3ef8 55000055 00000055 00000000 55000000 012b3f08 00000055 00000000 55000000 55000055 012b3f18 55000055 00000000 00000000 55000055 0:000> 012b3f28 00000000 00000000 55000055 55000055 012b3f38 00000055 00000000 55000000 00000055 012b3f48 00000000 55000000 55000055 55000055 012b3f58 00000000 00000000 00000055 00000000 012b3f68 00000000 55000055 55000055 55000055 012b3f78 55000055 55000055 ffffff55 ffffffff 012b3f88 ffffffff ffffffff ffffffff ffffffff 012b3f98 550000ff 55000055 55000055 55000055 0:000> 012b3fa8 55000055 00000000 00000000 00555555 012b3fb8 00555555 00555555 00555555 ffff5555 012b3fc8 ffffffff 005555ff 00555555 ffffffff 012b3fd8 ffffffff 0055ffff 00555555 00555555 012b3fe8 00555555 00555555 00555555 00000000 012b3ff8 00000000 00555555 00005555 00000000 012b4008 00550000 00555555 00000055 00000000 012b4018 00555500 00555555 00000000 00000000 0:000> 012b4028 00555555 00555555 00000000 00000000 012b4038 00555555 00000055 00000000 00550000 012b4048 00555555 00000000 00000000 00555500 012b4058 00555555 00000000 00000000 00555555 012b4068 00005555 00000000 00000000 00555555 012b4078 00000055 00000000 00555500 00555555 012b4088 00555555 00555555 00555555 ffffff55 012b4098 ffffffff ffffffff ffffffff ffffffff 0:000> 012b40a8 ffffffff 005555ff 00555555 00555555 012b40b8 00555555 00555555 00000000 55000000 012b40c8 55005500 55005500 55005500 55005500 012b40d8 ffffff00 ffffffff 5500ffff 55005500 012b40e8 ffffffff ffffffff 5500ffff 55005500 012b40f8 55005500 55005500 55005500 00005500 012b4108 00000000 55000000 55005500 00005500 012b4118 00000000 55000000 00005500 00000000 0:000> 012b4128 00000000 55005500 55005500 00000000 012b4138 00000000 55005500 00000000 00000000 012b4148 55000000 55005500 00005500 00000000 012b4158 55000000 00005500 00000000 55000000 012b4168 55005500 55005500 00000000 00000000 012b4178 55005500 00000000 00000000 55005500 012b4188 55005500 00005500 00000000 55000000 012b4198 55005500 55005500 55005500 55005500 0:000> 012b41a8 ffffffff ffffffff ffffffff ffffffff 012b41b8 ffffffff ffffffff 550055ff 55005500 012b41c8 55005500 55005500 55005500 00000000 012b41d8 00000000 00555500 00555500 00555500 012b41e8 00555500 ffffff00 ffffffff 0055ffff 012b41f8 00555500 ffffffff ffffffff 005555ff 012b4208 00555500 00555500 00555500 00555500 012b4218 00000000 00000000 00555500 00555500 0:000> 012b4228 00555500 00000000 00000000 00005500 012b4238 00000000 00550000 00555500 00555500 012b4248 00005500 00000000 00000000 00000000 012b4258 00000000 00555500 00555500 00555500 012b4268 00000000 00000000 00005500 00000000 012b4278 00550000 00555500 00555500 00005500 012b4288 00000000 00550000 00000000 00000000 012b4298 00555500 00555500 00555500 00000000 0:000> 012b42a8 00000000 00555500 00555500 00555500 012b42b8 ff555500 ffffffff ffffffff ffffffff 012b42c8 ffffffff ffffffff ffffffff 00555500 012b42d8 00555500 00555500 00555500 00555500 012b42e8 00000000 55000000 55550055 55550055 012b42f8 55550055 55550055 ffffff55 ffffffff 012b4308 5555ffff 55550055 ffffffff ffffffff 012b4318 555500ff 55550055 55550055 55550055 0:000> 012b4328 00550055 00000000 55000000 55550055 012b4338 55550055 55550055 00000055 00000000 012b4348 00000000 00000000 55550000 55550055 012b4358 55550055 55550055 00000000 00000000 012b4368 00000000 55000000 55550055 55550055 012b4378 55550055 00000055 00000000 00000000 012b4388 00000000 55550000 55550055 55550055 012b4398 00550055 00000000 00000000 00000000 0:000> 012b43a8 55550000 55550055 55550055 55550055 012b43b8 00000055 00000000 55550000 55550055 012b43c8 55550055 ffff0055 ffffffff ffffffff 012b43d8 ffffffff ffffffff ffffffff ffffffff 012b43e8 55550055 55550055 55550055 55550055 012b43f8 55550055 00000000 55000000 55005500 012b4408 55005500 55005500 55005500 ffffff00 012b4418 ffffffff 5500ffff 55005500 ffffffff 0:000> 012b4428 ffffffff 550055ff 55005500 55005500 012b4438 55005500 00000000 00000000 55000000 012b4448 55005500 55005500 55005500 00005500 012b4458 00000000 00000000 00000000 55005500 012b4468 55005500 55005500 55005500 00000000 012b4478 00000000 00000000 55005500 55005500 012b4488 55005500 55005500 00005500 00000000 012b4498 00000000 55000000 55005500 55005500 0:000> 012b44a8 55005500 55005500 00000000 00000000 012b44b8 00000000 55005500 55005500 55005500 012b44c8 55005500 00005500 00000000 55000000 012b44d8 55005500 55005500 ffffff00 ffffffff 012b44e8 ffffffff ffffffff ffffffff ffffffff 012b44f8 ffffffff 55005500 55005500 55005500 012b4508 55005500 55005500 00000000 55000000 012b4518 55000055 55000055 55000055 55000055 0:000> 012b4528 ffff0055 ffffffff 550000ff 55000055 012b4538 ffffffff ffffffff 55000055 55000055 012b4548 55000055 55000055 00000055 00000000 012b4558 55000055 55000055 55000055 55000055 012b4568 55000055 00000055 00000000 55000000 012b4578 55000055 55000055 55000055 55000055 012b4588 00000055 00000000 00000000 55000055 012b4598 55000055 55000055 55000055 55000055 0:000> 012b45a8 00000000 00000000 55000000 55000055 012b45b8 55000055 55000055 55000055 00000055 012b45c8 00000000 00000000 55000055 55000055 012b45d8 55000055 55000055 55000055 00000000 012b45e8 55000000 55000055 55000055 ffffff55 012b45f8 ffffffff ffffffff ffffffff ffffffff 012b4608 ffffffff ffffffff 55000055 55000055 012b4618 55000055 55000055 55000055 00000000 0:000> 012b4628 00000000 00555555 00555555 00555555 012b4638 00555555 ffff5555 ffffffff 00555555 012b4648 00555555 ffffffff 00ffffff 00555555 012b4658 00555555 00555555 00555555 00000055 012b4668 00000000 00555555 00555555 00555555 012b4678 00555555 00555555 00005555 00000000 012b4688 00555500 00555555 00555555 00555555 012b4698 00555555 00555555 00000000 00000000 0:000> 012b46a8 00555555 00555555 00555555 00555555 012b46b8 00555555 00005555 00000000 00555555 012b46c8 00555555 00555555 00555555 00555555 012b46d8 00555555 00000000 00550000 00555555 012b46e8 00555555 00555555 00555555 00555555 012b46f8 00000055 00000000 00555555 00555555 012b4708 00555555 00555555 00555555 00555555 012b4718 00555555 00555555 00555555 00555555 0:000> 012b4728 00555555 00555555 00555555 00555555 012b4738 00000000 55000000 55005500 55005500 012b4748 55005500 55005500 ff005500 ffffffff 012b4758 55005500 ff005500 ffffffff 55ffffff 012b4768 55005500 55005500 55005500 55005500 012b4778 00005500 55000000 55005500 55005500 012b4788 55005500 55005500 55005500 00005500 012b4798 55000000 55005500 55005500 55005500 0:000> 012b47a8 55005500 55005500 55005500 00000000 012b47b8 55005500 55005500 55005500 55005500 012b47c8 55005500 55005500 00005500 55000000 012b47d8 55005500 55005500 55005500 55005500 012b47e8 55005500 55005500 00000000 55005500 012b47f8 55005500 55005500 55005500 55005500 012b4808 55005500 00005500 55000000 55005500 012b4818 55005500 55005500 55005500 55005500 0:000> 012b4828 55005500 55005500 55005500 55005500 012b4838 55005500 55005500 55005500 55005500 012b4848 55005500 00000000 00000000 00555500 012b4858 00555500 00555500 00555500 00555500 012b4868 ffffffff 005555ff ffff5500 ffffffff 012b4878 005555ff 00555500 00555500 00555500 012b4888 00555500 00005500 00555500 00555500 012b4898 00555500 00555500 00555500 00555500 0:000> 012b48a8 00555500 00550000 00555500 00555500 012b48b8 00555500 00555500 00555500 00555500 012b48c8 00555500 00555500 00555500 00555500 012b48d8 00555500 00555500 00555500 00555500 012b48e8 00550000 00555500 00555500 00555500 012b48f8 00555500 00555500 00555500 00005500 012b4908 00555500 00555500 00555500 00555500 012b4918 00555500 00555500 00555500 00550000 0:000> 012b4928 00555500 00555500 00555500 00555500 012b4938 00555500 00555500 00555500 00555500 012b4948 00555500 00555500 00555500 00555500 012b4958 00555500 00555500 00000000 55000000 012b4968 55550055 55550055 55550055 55550055 012b4978 55550055 ffffff55 ffffffff ffffffff 012b4988 ffffffff 55550055 55550055 55550055 012b4998 55550055 55550055 55550055 55550055 0:000> 012b49a8 55550055 55550055 55550055 55550055 012b49b8 55550055 55550055 55550055 55550055 012b49c8 55550055 55550055 55550055 55550055 012b49d8 55550055 55550055 55550055 55550055 012b49e8 55550055 55550055 55550055 55550055 012b49f8 55550055 55550055 55550055 55550055 012b4a08 55550055 55550055 55550055 55550055 012b4a18 55550055 55550055 55550055 55550055 0:000> 012b4a28 55550055 55550055 55550055 55550055 012b4a38 55550055 55550055 55550055 55550055 012b4a48 55550055 55550055 55550055 55550055 012b4a58 55550055 55550055 55550055 55550055 012b4a68 55550055 55550055 55550055 00000000 012b4a78 55000000 55005500 55005500 55005500 012b4a88 55005500 55005500 55005500 ffffffff 012b4a98 ffffffff 550055ff 55005500 55005500 0:000> 012b4aa8 55005500 55005500 55005500 55005500 012b4ab8 55005500 55005500 55005500 55005500 012b4ac8 55005500 55005500 55005500 55005500 012b4ad8 55005500 55005500 55005500 55005500 012b4ae8 55005500 55005500 55005500 55005500 012b4af8 55005500 55005500 55005500 55005500 012b4b08 55005500 55005500 55005500 55005500 012b4b18 55005500 55005500 55005500 55005500 0:000> 012b4b28 55005500 55005500 55005500 55005500 012b4b38 55005500 55005500 55005500 55005500 012b4b48 55005500 55005500 55005500 55005500 012b4b58 55005500 55005500 55005500 55005500 012b4b68 55005500 55005500 55005500 55005500 012b4b78 55005500 55005500 55005500 55005500 012b4b88 00000000 55000000 55000055 55000055 012b4b98 55000055 55000055 55000055 55000055 0:000> 012b4ba8 55000055 55000055 55000055 55000055 012b4bb8 55000055 55000055 55000055 55000055 012b4bc8 55000055 55000055 55000055 55000055 012b4bd8 55000055 55000055 55000055 55000055 012b4be8 55000055 55000055 55000055 55000055 012b4bf8 55000055 55000055 55000055 55000055 012b4c08 55000055 55000055 55000055 55000055 012b4c18 55000055 55000055 55000055 55000055 0:000> 012b4c28 55000055 55000055 55000055 55000055 012b4c38 55000055 55000055 55000055 55000055 012b4c48 55000055 55000055 55000055 55000055 012b4c58 55000055 55000055 55000055 55000055 012b4c68 55000055 55000055 55000055 55000055 012b4c78 55000055 55000055 55000055 55000055 012b4c88 55000055 55000055 55000055 55000055 012b4c98 55000055 00000000 00000000 00555555 0:000> 012b4ca8 00555555 00555555 00555555 00555555 012b4cb8 00555555 00555555 00555555 00555555 012b4cc8 00555555 00555555 00555555 00555555 012b4cd8 00555555 00555555 00555555 00555555 012b4ce8 00555555 00555555 00555555 00555555 012b4cf8 00555555 00555555 00555555 00555555 012b4d08 00555555 00555555 00555555 00555555 012b4d18 00555555 00555555 00555555 00555555 0:000> 012b4d28 00555555 00555555 00555555 00555555 012b4d38 00555555 00555555 00555555 00555555 012b4d48 00555555 00555555 00555555 00555555 012b4d58 00555555 00555555 00555555 00555555 012b4d68 00555555 00555555 00555555 00555555 012b4d78 00555555 00555555 00555555 00555555 012b4d88 00555555 00555555 00555555 00555555 012b4d98 00555555 00555555 00555555 00555555 0:000> 012b4da8 00555555 00555555 00000000 55000000 012b4db8 55005500 55005500 55005500 55005500 012b4dc8 55005500 55005500 55005500 55005500 012b4dd8 55005500 55005500 55005500 55005500 012b4de8 55005500 55005500 55005500 55005500 012b4df8 55005500 55005500 55005500 55005500 012b4e08 55005500 55005500 55005500 55005500 012b4e18 55005500 55005500 55005500 55005500 0:000> 012b4e28 55005500 55005500 55005500 55005500 012b4e38 55005500 55005500 55005500 55005500 012b4e48 55005500 55005500 55005500 55005500 012b4e58 55005500 55005500 55005500 55005500 012b4e68 55005500 55005500 55005500 55005500 012b4e78 55005500 55005500 55005500 55005500 012b4e88 55005500 55005500 55005500 55005500 012b4e98 55005500 55005500 55005500 55005500 0:000> 012b4ea8 55005500 55005500 55005500 55005500 012b4eb8 55005500 55005500 55005500 00000000 012b4ec8 00000000 00555500 00555500 00555500 012b4ed8 00555500 00555500 00555500 00555500 012b4ee8 00555500 00555500 00555500 00555500 012b4ef8 00555500 00555500 00555500 00555500 012b4f08 00555500 00555500 00555500 00555500 012b4f18 00555500 00555500 00555500 00555500 0:000> 012b4f28 00555500 00555500 00555500 00555500 012b4f38 00555500 00555500 00555500 00555500 012b4f48 00555500 00555500 00555500 00555500 012b4f58 00555500 00555500 00555500 00555500 012b4f68 00555500 00555500 00555500 00555500 012b4f78 00555500 00555500 00555500 00555500 012b4f88 00555500 00555500 00555500 00555500 012b4f98 00555500 00555500 00555500 00555500 0:000> 012b4fa8 00555500 00555500 00555500 00555500 012b4fb8 00555500 00555500 00555500 00555500 012b4fc8 00555500 00555500 00555500 00555500 012b4fd8 00000000 55000000 55550055 55550055 012b4fe8 55550055 55550055 55550055 55550055 012b4ff8 55550055 55550055 55550055 55550055 012b5008 55550055 55550055 55550055 55550055 012b5018 55550055 55550055 55550055 55550055 0:000> 012b5028 55550055 55550055 55550055 55550055 012b5038 55550055 55550055 55550055 55550055 012b5048 55550055 55550055 55550055 55550055 012b5058 55550055 55550055 55550055 55550055 012b5068 55550055 55550055 55550055 55550055 012b5078 55550055 55550055 55550055 55550055 012b5088 55550055 55550055 55550055 55550055 012b5098 55550055 55550055 55550055 55550055 0:000> 012b50a8 55550055 55550055 55550055 55550055 012b50b8 55550055 55550055 55550055 55550055 012b50c8 55550055 55550055 55550055 55550055 012b50d8 55550055 55550055 55550055 55550055 012b50e8 55550055 00000000 55000000 55005500 012b50f8 55005500 55005500 55005500 55005500 012b5108 55005500 55005500 55005500 55005500 012b5118 55005500 55005500 55005500 55005500 0:000> 012b5128 55005500 55005500 55005500 55005500 012b5138 55005500 55005500 55005500 55005500 012b5148 55005500 55005500 55005500 55005500 012b5158 55005500 55005500 55005500 55005500 012b5168 55005500 55005500 55005500 55005500 012b5178 55005500 55005500 55005500 55005500 012b5188 55005500 55005500 55005500 55005500 012b5198 55005500 55005500 55005500 55005500 0:000> 012b51a8 55005500 55005500 55005500 55005500 012b51b8 55005500 55005500 55005500 55005500 012b51c8 55005500 55005500 55005500 55005500 012b51d8 55005500 55005500 55005500 55005500 012b51e8 55005500 55005500 55005500 55005500 012b51f8 55005500 55005500 00000000 55000000 012b5208 55000055 55000055 55000055 55000055 012b5218 55000055 55000055 55000055 55000055 0:000> 012b5228 55000055 55000055 55000055 55000055 012b5238 55000055 55000055 55000055 55000055 012b5248 55000055 55000055 55000055 55000055 012b5258 55000055 55000055 55000055 55000055 012b5268 55000055 55000055 55000055 55000055 012b5278 55000055 55000055 55000055 55000055 012b5288 55000055 55000055 55000055 55000055 012b5298 55000055 55000055 55000055 55000055 0:000> 012b52a8 55000055 55000055 55000055 55000055 012b52b8 55000055 55000055 55000055 55000055 012b52c8 55000055 55000055 55000055 55000055 012b52d8 55000055 55000055 55000055 55000055 012b52e8 55000055 55000055 55000055 55000055 012b52f8 55000055 55000055 55000055 55000055 012b5308 55000055 55000055 55000055 00000000 012b5318 00000000 00555555 00555555 00555555 0:000> 012b5328 00555555 00555555 00555555 00555555 012b5338 00555555 00555555 00555555 00555555 012b5348 00555555 00555555 00555555 00555555 012b5358 00555555 00555555 00555555 00555555 012b5368 00555555 00555555 00555555 00555555 012b5378 00555555 00555555 00555555 00555555 012b5388 00555555 00555555 00555555 00555555 012b5398 00555555 00555555 00555555 00555555 0:000> 012b53a8 00555555 00555555 00555555 00555555 012b53b8 00555555 00555555 00555555 00555555 012b53c8 00555555 00555555 00555555 00555555 012b53d8 00555555 00555555 00555555 00555555 012b53e8 00555555 00555555 00555555 00555555 012b53f8 00555555 00555555 00555555 00555555 012b5408 00555555 00555555 00555555 00555555 012b5418 00555555 00555555 00555555 00555555 0:000> 012b5428 00000000 55000000 55005500 55005500 012b5438 55005500 55005500 55005500 55005500 012b5448 55005500 55005500 55005500 55005500 012b5458 55005500 55005500 55005500 55005500 012b5468 55005500 55005500 55005500 55005500 012b5478 55005500 55005500 55005500 55005500 012b5488 55005500 55005500 55005500 55005500 012b5498 55005500 55005500 55005500 55005500 0:000> 012b54a8 55005500 55005500 55005500 55005500 012b54b8 55005500 55005500 55005500 55005500 012b54c8 55005500 55005500 55005500 55005500 012b54d8 55005500 55005500 55005500 55005500 012b54e8 55005500 55005500 55005500 55005500 012b54f8 55005500 55005500 55005500 55005500 012b5508 55005500 55005500 55005500 55005500 012b5518 55005500 55005500 55005500 55005500 0:000> 012b5528 55005500 55005500 55005500 55005500 012b5538 55005500 00000000 00000000 00555500 012b5548 00555500 00555500 00555500 00555500 012b5558 00555500 00555500 00555500 00555500 012b5568 00555500 00555500 00555500 00555500 012b5578 00555500 00555500 00555500 00555500 012b5588 00555500 00555500 00555500 00555500 012b5598 00555500 00555500 00555500 00555500 0:000> 012b55a8 00555500 00555500 00555500 00555500 012b55b8 00555500 00555500 00555500 00555500 012b55c8 00555500 00555500 00555500 00555500 012b55d8 00555500 00555500 00555500 00555500 012b55e8 00555500 00555500 00555500 00555500 012b55f8 00555500 00555500 00555500 00555500 012b5608 00555500 00555500 00555500 00555500 012b5618 00555500 00555500 00555500 00555500 0:000> 012b5628 00555500 00555500 00555500 00555500 012b5638 00555500 00555500 00555500 00555500 012b5648 00555500 00555500 00000000 55000000 012b5658 55550055 55550055 55550055 55550055 012b5668 55550055 55550055 55550055 55550055 012b5678 55550055 55550055 55550055 55550055 012b5688 55550055 55550055 55550055 55550055 012b5698 55550055 55550055 55550055 55550055 0:000> 012b56a8 55550055 55550055 55550055 55550055 012b56b8 55550055 55550055 55550055 55550055 012b56c8 55550055 55550055 55550055 55550055 012b56d8 55550055 55550055 55550055 55550055 012b56e8 55550055 55550055 55550055 55550055 012b56f8 55550055 55550055 55550055 55550055 012b5708 55550055 55550055 55550055 55550055 012b5718 55550055 55550055 55550055 55550055 0:000> 012b5728 55550055 55550055 55550055 55550055 012b5738 55550055 55550055 55550055 55550055 012b5748 55550055 55550055 55550055 55550055 012b5758 55550055 55550055 55550055 00000000 012b5768 55000000 55005500 55005500 55005500 012b5778 55005500 55005500 55005500 55005500 012b5788 55005500 55005500 55005500 55005500 012b5798 55005500 55005500 55005500 55005500 0:000> 012b57a8 55005500 55005500 55005500 55005500 012b57b8 55005500 55005500 55005500 55005500 012b57c8 55005500 55005500 55005500 55005500 012b57d8 55005500 55005500 55005500 55005500 012b57e8 55005500 55005500 55005500 55005500 012b57f8 55005500 55005500 55005500 55005500 012b5808 55005500 55005500 55005500 55005500 012b5818 55005500 55005500 55005500 55005500 0:000> 012b5828 55005500 55005500 55005500 55005500 012b5838 55005500 55005500 55005500 55005500 012b5848 55005500 55005500 55005500 55005500 012b5858 55005500 55005500 55005500 55005500 012b5868 55005500 55005500 55005500 55005500 012b5878 00000000 55000000 55000055 55000055 012b5888 55000055 55000055 55000055 55000055 012b5898 55000055 55000055 55000055 55000055 0:000> 012b58a8 55000055 55000055 55000055 55000055 012b58b8 55000055 55000055 55000055 55000055 012b58c8 55000055 55000055 55000055 55000055 012b58d8 55000055 55000055 55000055 55000055 012b58e8 55000055 55000055 55000055 55000055 012b58f8 55000055 55000055 55000055 55000055 012b5908 55000055 55000055 55000055 55000055 012b5918 55000055 55000055 55000055 55000055 0:000> 012b5928 55000055 55000055 55000055 55000055 012b5938 55000055 55000055 55000055 55000055 012b5948 55000055 55000055 55000055 55000055 012b5958 55000055 55000055 55000055 55000055 012b5968 55000055 55000055 55000055 55000055 012b5978 55000055 55000055 55000055 55000055 012b5988 55000055 00000000 00000000 00000000 012b5998 00000000 00000000 00000000 00000000 0:000> 012b59a8 00000000 00000000 00000000 00000000 012b59b8 00000000 00000000 00000000 00000000 012b59c8 00000000 00000000 00000000 00000000 012b59d8 00000000 00000000 00000000 00000000 012b59e8 00000000 00000000 00000000 00000000 012b59f8 00000000 00000000 00000000 00000000 012b5a08 00000000 00000000 00000000 00000000 012b5a18 00000000 00000000 00000000 00000000 0:000> 012b5a28 00000000 00000000 00000000 00000000 012b5a38 00000000 00000000 00000000 00000000 012b5a48 00000000 00000000 00000000 00000000 012b5a58 00000000 00000000 00000000 00000000 012b5a68 00000000 00000000 00000000 00000000 012b5a78 00000000 00000000 00000000 00000000 012b5a88 00000000 00000000 00000000 00000000 012b5a98 00000000 00000000 00000000 00000000 0:000> 012b5aa8 00000000 00000000 00000000 00000000 012b5ab8 00000000 00000000 00000000 00000000 012b5ac8 00000000 00000000 00000000 00000000 012b5ad8 00000000 00000000 00000000 00000000 012b5ae8 00000000 00000000 00000000 00000000 012b5af8 00000000 00000000 00000000 00000000 012b5b08 00000000 00000000 00000000 00000000 012b5b18 00000000 00000000 00000000 00000000 0:000> 012b5b28 00000000 00000000 00000000 00000000 012b5b38 00000000 00000000 00000000 00000000 012b5b48 00000000 00000000 00000000 00000000 012b5b58 00000000 00000000 00000000 00000000 012b5b68 00000000 00000000 00000000 00000000 012b5b78 00000000 00000000 00000000 00000000 012b5b88 00000000 00000000 00000000 00000000 012b5b98 00000000 00000000 00000000 00000000 0:000> 012b5ba8 00000000 00000000 00000000 00000000 012b5bb8 00000000 00000000 00000000 00000000 012b5bc8 00000000 00000000 00000000 00000000 012b5bd8 00000000 00000000 00000000 00000000 012b5be8 00000000 00000000 00000000 00000000 012b5bf8 00000000 00000000 00000000 00000000 012b5c08 00000000 00000000 00000000 00000000 012b5c18 00000000 00000000 00000000 00000000 0:000> 012b5c28 00000000 00000000 00000000 00000000 012b5c38 00000000 00000000 00000000 00000000 012b5c48 00000000 00000000 00000000 00000000 012b5c58 00000000 00000000 00000000 00000000 012b5c68 00000000 00000000 00000000 00000000 012b5c78 00000000 00000000 00000000 00000000 012b5c88 00000000 00000000 00000000 00000000 012b5c98 00000000 00000000 00000000 00000000 0:000> 012b5ca8 00000000 00000000 00000000 00000000 012b5cb8 00000000 00000000 00000000 00000000 012b5cc8 00000000 00200b16 00eb7e38 02216808 012b5cd8 00200898 01354828 00000000 00000000 012b5ce8 02214018 012b5d48 00000000 000002c2 012b5cf8 000000d5 0000012b 0118cd08 00000000 012b5d08 00000000 00000040 00000000 00000000 012b5d18 00000000 00000000 00000000 00000000 0:000> 012b5d28 02216830 c7c34f80 c7c34f80 c7c34f80 012b5d38 c7c34f80 00000000 00000000 002004ba 012b5d48 00000000 02216894 012b5e64 012b5cdc 012b5d58 00000056 00200470 00000000 022168ac 012b5d68 022168bc 0020052e 00e66248 00e63b70 012b5d78 00000000 011a0648 00e63b60 00200546 012b5d88 00e6609c 00e64e10 00000001 4061c71c 012b5d98 c7c34f80 c7c34f80 00200882 01353ec0 0:000> 012b5da8 00000000 00000000 02214018 012b5e64 012b5db8 00000000 000002c2 0000012b 00000137 012b5dc8 0118cd08 00000000 00000000 00000040 012b5dd8 00000000 00000000 00000000 00000000 012b5de8 00000000 00000000 012b5e10 c7c34f80 012b5df8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b5e08 c7c34f80 00200a3c 01340ff0 00000000 012b5e18 00000000 012b5da4 00000000 00000000 0:000> 012b5e28 000002c2 0000012b 00000137 0118cd08 012b5e38 00000000 00000000 00000040 00000000 012b5e48 00000000 00000000 00000000 00000052 012b5e58 00000000 00000000 002004ba 00000000 012b5e68 012b5d48 012b6118 012b5da4 0000000c 012b5e78 00200470 00000000 022168cc 022168bc 012b5e88 00200332 012b5e94 00000001 022168dc 012b5e98 00200470 00000000 0119e8cc 012b5eac 0:000> 012b5ea8 00200470 00000000 022168e8 012b5ebc 012b5eb8 00200470 00000000 022168dc 00000000 012b5ec8 00200470 00000000 012b5e9c 012b5e7c 012b5ed8 0020052e 00e66248 00e63b70 00000000 012b5ee8 011a0648 00e63b60 00200546 00e6609c 012b5ef8 00e63c80 00000001 c7c34f80 00000000 012b5f08 00000000 00200546 00e6609c 00e63900 012b5f18 00000000 c7c34f80 c7c34f80 c7c34f80 0:000> 012b5f28 00200470 00000000 022168dc 012b5ecc 012b5f38 00200470 00000000 022168dc 00000000 012b5f48 0020052e 00e66248 00e63b70 00000000 012b5f58 011a0648 00e63b60 00200548 00e6607c 012b5f68 00e64e10 00000001 022168dc 00200544 012b5f78 00e660bc 00e64564 00000000 40000000 012b5f88 00200544 00e660bc 00e64578 00000000 012b5f98 00000000 00200532 00e661e4 00e6458c 0:000> 012b5fa8 00000000 00000000 00200532 00e661e4 012b5fb8 00e645a4 00000000 00000001 00200532 012b5fc8 00e661e4 00e645b8 00000000 00000000 012b5fd8 00200534 01341518 00e64e10 00000000 012b5fe8 012b5ff8 00000001 00000001 00200540 012b5ff8 012b6000 00000003 012b5fa0 012b5fb4 012b6008 012b5fc8 00200548 00e6607c 00e6418c 012b6018 00000000 00000000 002008a0 01354e98 0:000> 012b6028 00000000 00000000 012b60ac 00000000 012b6038 00000000 000002c2 00000137 00000151 012b6048 0118cd08 00000000 00000000 00000040 012b6058 00000000 00000000 00000000 00000000 012b6068 022168dc 00000007 0119ff40 3f349f4a 012b6078 00000000 00000002 00000000 3f000000 012b6088 3f000000 000000b8 0000020a 00000137 012b6098 00000151 000000b8 0000014c 00000000 0:000> 012b60a8 00200898 01354828 00000000 00000000 012b60b8 02214018 012b6118 00000000 000002c2 012b60c8 00000137 00000151 0118cd08 00000000 012b60d8 00000000 00000040 00000000 00000000 012b60e8 00000000 00000000 00000000 00000000 012b60f8 012b6024 c7c34f80 c7c34f80 c7c34f80 012b6108 c7c34f80 00000000 00000000 002004ba 012b6118 00000000 012b5e64 012b6234 012b60ac 012b6128 0000001a 00200470 00000000 022168f8 012b6138 022168bc 0020052e 00e66248 00e63b70 012b6148 00000000 011a0648 00e63b60 00200546 012b6158 00e6609c 00e64e10 00000001 4061c71c 012b6168 c7c34f80 c7c34f80 00200882 01353ec0 012b6178 00000000 00000000 02214018 012b6234 012b6188 00000000 000002c2 00000151 0000015d 012b6198 0118cd08 00000000 00000000 00000040 012b61a8 00000000 00000000 00000000 00000000 012b61b8 00000000 00000000 012b61e0 c7c34f80 012b61c8 c7c34f80 c7c34f80 4061c71c c7c34f80 012b61d8 c7c34f80 00200a3c 01340ff0 00000000 012b61e8 00000000 012b6174 00000000 00000000 012b61f8 000002c2 00000151 0000015d 0118cd08 012b6208 00000000 00000000 00000040 00000000 012b6218 00000000 00000000 00000000 00000052 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 04:27:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 02:27:09 +0000 Subject: [M3devel] FW: This is a pixmap? Message-ID: resorting to an attachment since this is important and keeps getting truncated -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jay.krell at cornell.edu Fri Sep 4 10:33:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 08:33:36 +0000 Subject: [M3devel] updating web site? Message-ID: http://modula3.elegosoft.com/cm3/index.html (http://modula3.elegosoft.com/cm3/start.html) looks really bad, with the nested frame I believe I fixed this days ago: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/www/start.html.diff?r1=1.3.2.2;r2=1.3.2.3 How does one get the web site to update? Maybe use head instead of the release branch? Maybe I didn't move the tag forward? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 10:54:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) Message-ID: short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 11:12:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 09:12:23 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 13:52:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 11:52:28 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 16:06:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 14:06:08 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 16:07:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 14:07:46 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 16:40:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 14:40:49 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Sep 4 17:10:53 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 04 Sep 2009 11:10:53 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: <4AA0F5A7.1E75.00D7.1@scires.com> Jay said: >This we shall blame on Trestle not fully being ported to Win32, I guess. >At the very least, it seems to the behavior going back a while. >You can occasionally see this in head, but usually you see #3. I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 4 18:44:21 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 4 Sep 2009 12:44:21 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non- Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote: > no..still unsolved..not sure if I misobserved or what..will have to > backtrack.. > > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:07:46 +0000 > > (Well, duh, it wasn't ProcessPools(SuspendPool), that just has > assertions) > > - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:06:08 +0000 > > Restoring the: > ThreadF.ProcessPools(ClosePool); > > 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. > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 11:52:28 +0000 > > I have narrowed it way down to between "2009-02-16 02:00Z" and -D > "2009-02-16 02:30Z". > So please review this change. > I have reviewed it and tried to partly undo it, without luck yet. > There is a semantic change in BroadcastHeap where the broadcast used > to happen upon the next unlock > and now I think happens right away. I tried restoring that, but > again, no luck for me. > > Thanks, > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 09:12:23 +0000 > > I have narrowed it down further to between 2/15/2009 and 2/18/2009. > Next I will try old text code in head to see if it is that. > > Tony, can you double check this stuff: > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > > 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..). > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 08:54:54 +0000 > Subject: [M3devel] Juno on NT (presumably canary for other problems) > > short story: > > > I narrowed it down to between 2/15/2009 and 2/20/2009. > I will keep digging. > > There are actually a lot of changes in that brief period. > I will narrow it further. > > > long story: > > Juno on NT, as canary for other problems. > Juno on NT has three behaviors. > > > Behavior #1 > > > The most common historical behavior, an assertion failure: > C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\winvbt\WinContext.m3", line 165 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt > \WinContext.m3 > 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 > 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 > 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe30 0x7e418734 > 0x1b3fe98 0x7e418816 > 0x1b3fef8 0x7e4189cd > 0x1b3ff08 0x7e4196c7 > 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt > \WinTrestle.m3 > ......... ......... ... more frames ... > (1860.1d80): Break instruction exception - code 80000003 (first > chance) > eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 > edi=005d526b > eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz > na po nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00000202 > ntdll!DbgBreakPoint: > 7c90120e cc int 3 > 0:003> .lines > Line number information will be loaded > 0:003> k999 > ChildEBP RetAddr > 01b3f5bc 005d52b7 ntdll!DbgBreakPoint > 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime > \WIN32\RTOS.m3 @ 29] > 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common > \RTProcess. > m3 @ 66] > 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime > \common\RTError.m > 3 @ 118] > 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common > \RTError.m3 @ > 40] > 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime > \common\RTExcep > tion.m3 @ 79] > 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src > \runtime\commo > n\RTException.m3 @ 39] > 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src > \runtime\commo > n\RTException.m3 @ 47] > 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime > \common\RTHook > s.m3 @ 110] > 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt > \WinContext.m3 @ 1 > 7] > 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt > \WinContext.m3 > @ 167] > 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt > \WinPaint.m3 @ 71 > 2] > 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt > \WinPaint.m3 @ 5 > 1] > 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt > \WinTrestle > .m3 @ 1574] > 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt > \WinTrestle.m3 > @ 1163] > 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 > 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 > 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 > 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf > 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src > \winvbt\WinTrestl > e.m3 @ 2450] > 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread > \WIN32\Threa > dWin32.m3 @ 579] > 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread > \WIN32\Threa > dWin32.m3 @ 548] > 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 > 0:003> > > > This we shall blame on Trestle not fully being ported to Win32, I > guess. > At the very least, it seems to the behavior going back a while. > You can occasionally see this in head, but usually you see #3. > > > Behavior #2 > > Sometimes, rarely, Juno hangs in startup on NT. > I believe I have seen this both with fairly old and current versions. > This occurs very rarely. I might look into it more after #3 is solved. > > > Behavior #3 > > > An access violation (SIGSEGV to Unix folks) during startup. > This is the most common behavior with current source, going back a > few months. > It is almost always accessing address 00200000 and the instruction > pointer is very > often in Thread__Join, but neither are always true. > Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. > > > C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe > (1ac4.1e9c): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 > edi=02812974 > eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > m3core!Thread__Join+0x13f: > 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds: > 0023:001ffffc=???????? > 0:000> r ebx > ebx=00200000 > 0:000> .lines > Line number information will be loaded > 0:000> k > ChildEBP RetAddr > 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread > \WIN32\ThreadWin32.m3 > @ 710] > 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src > \JunoCompile. > m3 @ 256] > 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] > 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] > 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] > 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] > 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ > 174] > 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ > 263] > 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] > 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime > \common\RTLi > nker.m3 @ 399] > 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime > \common\RTLinker > .m3 @ 113] > 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime > \common\RTLinker. > m3 @ 122] > 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] > 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld > \self_x86\c > rt\src\crtexe.c @ 582] > 0012fff0 00000000 kernel32!BaseProcessStart+0x23 > 0:000> > > #4 sometimes other, for example: > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 411 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common > \RTCollector.m3 > 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common > \RTCollector.m > 3 > 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common > \RTCollector.m3 > 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src > \runtime\common\RT > Collector.m3 > 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common > \RTCollector.m3 > 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common > \RTCollector. > m3 > 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common > \RTCollector.m3 > ......... ......... ... more frames ... > (14b0.121c): Break instruction exception - code 80000003 (first > chance) > > for example: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\src\vbt\VBTRep.m3", line 644 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 > 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 > 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 > 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > (1c3c.e3c): Break instruction exception - code 80000003 (first chance) > > I figure these are just a variation of #3. > > Now, I finally learned how to give CVS a date to checkout or update. > And NT builds very fast due to the integrated backend. > So I have been building various dates. > > The change between #3 and #1 happened around mid February 2009. > Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, > #4 above is from 2009/02/20. > And 2009/02/20 also access violates on 00200000 often. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 21:44:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 19:44:51 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: <4AA0F5A7.1E75.00D7.1@scires.com> References: <4AA0F5A7.1E75.00D7.1@scires.com> Message-ID: Randy, thanks, understood. Actually Juno does draw a bunch of fancy stuff before the assertion failure. And formsedit at least historically works, and I thought mentor but I'll have to retest after Tony fixes, and with old versions. Yes please test anything you can. I can get you an HP-UX toolset if you need..assumiing I can resolve why last I powered the machine on I couldn't see it on the network. At some point we might even get HP-UX in Hudson. :) - Jay Date: Fri, 4 Sep 2009 11:10:53 -0400 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay said: >This we shall blame on Trestle not fully being ported to Win32, I guess. >At the very least, it seems to the behavior going back a while. >You can occasionally see this in head, but usually you see #3. I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 21:42:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 19:42:58 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: > no..still unsolved..not sure if I misobserved or what..will have to backtrack.. To clarify, the problem is between "2009-02-16 02:00Z" and "2009-02-16 02:30Z", just that I don't know either of - a small change to "2009-02-16 02:30Z" to fix it - and applying such to head - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Date: Fri, 4 Sep 2009 14:40:49 +0000 Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Fri Sep 4 22:21:47 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 04 Sep 2009 16:21:47 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: <4AA0F5A7.1E75.00D7.1@scires.com> Message-ID: <4AA13E82.1E75.00D7.1@scires.com> Jay: Yeah I see the Juno window start up on most runs, but then it crashes so quickly that you can't see much before the window disappears. I use formsedit quite a bit. I recall that back when we purchased Reactor/cm3 v4.1, that Farshad and company had to make some patches to formsedit because it crashed on certain platforms. Critical Mass provided us with the patched executables, but I never got the sources. Not sure if the patches got put into what we have now. There are some problems now with formsedit that I've documented in the past. One of the big ones has to deal with keeping the cursor placement in sync between what is shown on the display and what the program actually thinks, particularly when switching between mouse and keyboard movement. Similarly, I know that Reactor was a work in progress. Although I worked with Farshad to obtain the sources for the open source release as CM3IDE, I'm not confident that all the latest greatest sources actually made it to me in the version Farshad supplied. He had to dig back through some archives to obtain them. I've noticed some operational differences between my old "Reactor" and the new "CM3IDE". Monday is a holiday for me, so I'll try to devote some time this long weekend on running more tests. If you want me to run stuff on HP-UX, I'll have to pull the machine "out-of-moth-balls" so to speak because its been a long time since I've used it. I think I still have three HP-UX machines. One of them had a hard drive problem with one of its SCSI drives so that may take some to repair. I'll also try to look at some of the scripts ya'll are using for the automated tests and see if there is a way I can run some of these tests on XP and Vista (unless ya'll already have that covered on a VM for Hudson--let me know if I don't need to do this). Regards, Randy >>> Jay K 9/4/2009 3:44 PM >>> Randy, thanks, understood. Actually Juno does draw a bunch of fancy stuff before the assertion failure. And formsedit at least historically works, and I thought mentor but I'll have to retest after Tony fixes, and with old versions. Yes please test anything you can. I can get you an HP-UX toolset if you need..assumiing I can resolve why last I powered the machine on I couldn't see it on the network. At some point we might even get HP-UX in Hudson. :) - Jay Date: Fri, 4 Sep 2009 11:10:53 -0400 From: rcoleburn at scires.com To: jay.krell at cornell.edu; m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay said: >This we shall blame on Trestle not fully being ported to Win32, I guess. >At the very least, it seems to the behavior going back a while. >You can occasionally see this in head, but usually you see #3. I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 4 23:20:13 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 4 Sep 2009 21:20:13 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: <4AA13E82.1E75.00D7.1@scires.com> References: <4AA0F5A7.1E75.00D7.1@scires.com> <4AA13E82.1E75.00D7.1@scires.com> Message-ID: > unless ya'll already have that covered on a VM for Hudson We do. Another wouldn't hurt much though, except time/energy. Maybe document the setup. We had a bunch of problems, though some were due to wierdo missteps that I would have called out had I been paying close attention. That is, setup is more like "leave the defaults, don't do extra wierd stuff". CVSNT by default changes line endings, breaking all .sh files. Maybe there is a setting to fix it? I'm not sure. The documentation is very confusing on this point. It talks about a keyword setting on a per file basis. Or maybe a checkout/update option? So Cygwin text mode mounts were used, which partly fixes the problem, but leaves caltech-parser broken (it should be fixed to allow for \n, \r, or \r\n.). Had I noticed I would have avoided the text mode mount in the first place. Fixed by: Use Cygwin cvs as I've been using all along. Don't use textmode mounts, use the default. Also cygwin mount cygexec was being used. I don't know what that really does. No longer used. It's not the default. Cygwin sshd has a bug that breaks Visual C++ link.exe. Seriously. We switched to another sshd, and paid a small licensing fee. Sometimes reboot needed to get sshd/ssh/scp working. The initial setup up cm3 itself has some kinks as well that Olaf pledges to improve after the current release -- where to find a baseline cm3 to start with and possibly m3core/libm3. It's probably easier, though still a small pain, to run the Tinderbox stuff. I checked in a document detailing my experience. Tinderbox doesn't require Java or sshd. I would still avoid CVSNT unless that behavior can be remedied. - Jay ________________________________ > Date: Fri, 4 Sep 2009 16:21:47 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) > > > > > > > > > > Jay: > > > > Yeah I see the Juno window start up on most runs, but then it crashes so quickly that you can't see much before the window disappears. > > > > I use formsedit quite a bit. I recall that back when we purchased Reactor/cm3 v4.1, that Farshad and company had to make some patches to formsedit because it crashed on certain platforms. Critical Mass provided us with the patched executables, but I never got the sources. Not sure if the patches got put into what we have now. > > > > There are some problems now with formsedit that I've documented in the past. One of the big ones has to deal with keeping the cursor placement in sync between what is shown on the display and what the program actually thinks, particularly when switching between mouse and keyboard movement. > > > > Similarly, I know that Reactor was a work in progress. Although I worked with Farshad to obtain the sources for the open source release as CM3IDE, I'm not confident that all the latest greatest sources actually made it to me in the version Farshad supplied. He had to dig back through some archives to obtain them. I've noticed some operational differences between my old "Reactor" and the new "CM3IDE". > > > > Monday is a holiday for me, so I'll try to devote some time this long weekend on running more tests. If you want me to run stuff on HP-UX, I'll have to pull the machine "out-of-moth-balls" so to speak because its been a long time since I've used it. I think I still have three HP-UX machines. One of them had a hard drive problem with one of its SCSI drives so that may take some to repair. I'll also try to look at some of the scripts ya'll are using for the automated tests and see if there is a way I can run some of these tests on XP and Vista (unless ya'll already have that covered on a VM for Hudson--let me know if I don't need to do this). > > > > Regards, > > Randy > >>>> Jay K 9/4/2009 3:44 PM>>> > Randy, thanks, understood. Actually Juno does draw a bunch of fancy stuff before the assertion failure. And formsedit at least historically works, and I thought mentor but I'll have to retest after Tony fixes, and with old versions. Yes please test anything you can. I can get you an HP-UX toolset if you need..assumiing I can resolve why last I powered the machine on I couldn't see it on the network. At some point we might even get HP-UX in Hudson. :) > > - Jay > > > > > ________________________________ > > > Date: Fri, 4 Sep 2009 11:10:53 -0400 > From: rcoleburn at scires.com > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) > > > > > Jay said: > >>This we shall blame on Trestle not fully being ported to Win32, I guess. >>At the very least, it seems to the behavior going back a while. >>You can occasionally see this in head, but usually you see #3. > > I think there are some things that aren't fully ported as you say, but I have been using Trestle and FormsVBT on Windows since the mid nineties. My company paid Critical Mass to get Trestle/FormsVBT working on Windows so we could write code whose GUI behaved the same on both HPUX and WindowsNT. I am pretty sure that all those changes got factored into what we have now. At least, I am able to build my GUI apps and they do run on XP and Vista. Granted, I haven't done extensive tests with them using latest sources. Maybe I should do some checking here. > > > > Regards, > > Randy From jay.krell at cornell.edu Sun Sep 6 14:30:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Sep 2009 12:30:27 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Tony both of these timestamps are somewhat prone to hanging during Juno I386_DARWIN startup. But they don't crash, er..well they do both fail assertions in text, but I just put current source in to address that. I'm going to search backward for a time that doesn't hang. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 4 Sep 2009 12:44:21 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non-Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote:no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 6 16:04:55 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Sep 2009 14:04:55 +0000 Subject: [M3devel] XSharedMem.m3 Message-ID: The file m3-ui/ui/src/xvbt/XSharedMem.m3 has a bug. The function IsSameHost is wrong. What does it matter either way? Can the code that uses it just depend on the shared memory stuff working? Or is it important to know if really on the same machine? That is, can it just be hardcoded as TRUE and back progatate that assumption to its callers? Apple's X11 does like this: bash-3.2$ echo $DISPLAY /tmp/launch-gTYtJF/:0 which causes this IsSameHost code to fail. You can see I put in a band-aid a while ago, but it isn't really fixed. Why have I never heard of this problem in other X code? Because X seems to stink so I don't pay much attention to it.. Because X is little used on Macs? Little used in general? .. (note that Interix seems to lack some of this XSharedMem stuff, therefore so far no Modula-3 gui apps on it. Now that I see this optionality though, maybe it is easy to workaround?) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 6 18:11:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 6 Sep 2009 16:11:28 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Tony, I386_DARWIN Juno is very prone to hang during startup going back at least until 2007/12/01. But they certainly don't always hang. I haven't found a version yet that doesn't hang. I'll look some more. I guess soon I should try other platforms? Sometimes there is a pause and it continues. Perhaps the hangs I'm just being too impatient on?? But, then, it's a bit inconsistent. Has it ever worked? Race condition in Juno maybe? It isn't always easy to build these old dates. Caveats: I'm using just current cm3cg. I started seeing as complain about older cm3cg output. Current config files. Build standalone (as current config files do with older compilers automatically, for "old" == missing the symlink functions). Patched XSharedMem/IsSameHost to always be FALSE, though TRUE would be correct, FALSE seems safe, I have to read that code.. Here is 2007/12/01 hung. It got as far as displaying "Curve" in the startup text that goes by. (gdb) thread apply all bt Thread 9 (process 32852 thread 0x294f): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1e8c in Thread__AlertWait () #5 0x00290988 in Formatter__Allocate () #6 0x00291137 in Formatter__Probe () #7 0x0029178e in Formatter__Peek () #8 0x00291677 in Formatter__PeekOp () #9 0x00291d18 in Formatter__PrintUntil () #10 0x002918d2 in Formatter__PrintTop () #11 0x002e3651 in ThreadPThread__RunThread () #12 0x002e33a3 in ThreadPThread__ThreadBase () #13 0x96f74155 in _pthread_start () #14 0x96f74012 in thread_start () Thread 8 (process 32852 thread 0x2603): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001aad83 in XMessenger__Messenger () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 7 (process 32852 thread 0x2503): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001b68da in XInput__FilterXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 6 (process 32852 thread 0x240f): #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () #1 0x96fc8261 in select () #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () #3 0x002e4b05 in ThreadPThread__XIOWait () #4 0x002e4614 in SchedulerPosix__IOWait () #5 0x001b65f5 in XInput__WaitForXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 5 (process 32852 thread 0x2303): #0 0x96f433a6 in mach_wait_until () #1 0x96fba3ad in nanosleep () #2 0x002e423c in ThreadPThread__XPause () #3 0x002e4393 in Thread__Pause () #4 0x0011113a in FileBrowserVBT__Watcher () #5 0x002e3651 in ThreadPThread__RunThread () #6 0x002e33a3 in ThreadPThread__ThreadBase () #7 0x96f74155 in _pthread_start () #8 0x96f74012 in thread_start () Thread 4 (process 32852 thread 0x2203): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001883f9 in VTView__VFontCleanUpThread () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 3 (process 32852 thread 0x2103): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001eb9c2 in VBTRep__MeterMaid () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 2 (process 32852 thread 0x313): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e65ec in RTOS__WaitHeap () #6 0x002d2d54 in RTCollector__WeakCleaner () #7 0x002e3651 in ThreadPThread__RunThread () #8 0x002e33a3 in ThreadPThread__ThreadBase () #9 0x96f74155 in _pthread_start () #10 0x96f74012 in thread_start () Thread 1 (process 32852 local thread 0x2d03): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e3ddb in Thread__Join () #6 0x0028f53d in Formatter__Close () #7 0x00079485 in JunoUnparse__Expr () #8 0x00021721 in Editor__Pass4 () #9 0x00022048 in EditorUI__CompileUI () #10 0x0003e7f8 in Juno__CompileEditor () #11 0x0003e98d in Juno__CompileModule () #12 0x0003f3be in Juno__CompileModules () #13 0x0004d43d in Juno_M3 () #14 0x002d71fa in RTLinker__RunMainBody () #15 0x002d67b0 in RTLinker__AddUnitI () #16 0x002d682e in RTLinker__AddUnit () #17 0x00003c88 in main () - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Sun, 6 Sep 2009 12:30:27 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Tony both of these timestamps are somewhat prone to hanging during Juno I386_DARWIN startup. But they don't crash, er..well they do both fail assertions in text, but I just put current source in to address that. I'm going to search backward for a time that doesn't hang. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 4 Sep 2009 12:44:21 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non-Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote:no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 03:49:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 01:49:28 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack. Current LINUXLIBC6 Juno doesn't seem to ever hang. So I conclude, with obvious non scientific firmness, that the Darwin-specific threading has never really worked and that the problem lies with it, not within the common code (or perhaps in the common code but only in how it mixes with the Darwin code). - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Sun, 6 Sep 2009 16:11:28 +0000 Tony, I386_DARWIN Juno is very prone to hang during startup going back at least until 2007/12/01. But they certainly don't always hang. I haven't found a version yet that doesn't hang. I'll look some more. I guess soon I should try other platforms? Sometimes there is a pause and it continues. Perhaps the hangs I'm just being too impatient on?? But, then, it's a bit inconsistent. Has it ever worked? Race condition in Juno maybe? It isn't always easy to build these old dates. Caveats: I'm using just current cm3cg. I started seeing as complain about older cm3cg output. Current config files. Build standalone (as current config files do with older compilers automatically, for "old" == missing the symlink functions). Patched XSharedMem/IsSameHost to always be FALSE, though TRUE would be correct, FALSE seems safe, I have to read that code.. Here is 2007/12/01 hung. It got as far as displaying "Curve" in the startup text that goes by. (gdb) thread apply all bt Thread 9 (process 32852 thread 0x294f): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1e8c in Thread__AlertWait () #5 0x00290988 in Formatter__Allocate () #6 0x00291137 in Formatter__Probe () #7 0x0029178e in Formatter__Peek () #8 0x00291677 in Formatter__PeekOp () #9 0x00291d18 in Formatter__PrintUntil () #10 0x002918d2 in Formatter__PrintTop () #11 0x002e3651 in ThreadPThread__RunThread () #12 0x002e33a3 in ThreadPThread__ThreadBase () #13 0x96f74155 in _pthread_start () #14 0x96f74012 in thread_start () Thread 8 (process 32852 thread 0x2603): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001aad83 in XMessenger__Messenger () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 7 (process 32852 thread 0x2503): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001b68da in XInput__FilterXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 6 (process 32852 thread 0x240f): #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () #1 0x96fc8261 in select () #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () #3 0x002e4b05 in ThreadPThread__XIOWait () #4 0x002e4614 in SchedulerPosix__IOWait () #5 0x001b65f5 in XInput__WaitForXInput () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 5 (process 32852 thread 0x2303): #0 0x96f433a6 in mach_wait_until () #1 0x96fba3ad in nanosleep () #2 0x002e423c in ThreadPThread__XPause () #3 0x002e4393 in Thread__Pause () #4 0x0011113a in FileBrowserVBT__Watcher () #5 0x002e3651 in ThreadPThread__RunThread () #6 0x002e33a3 in ThreadPThread__ThreadBase () #7 0x96f74155 in _pthread_start () #8 0x96f74012 in thread_start () Thread 4 (process 32852 thread 0x2203): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001883f9 in VTView__VFontCleanUpThread () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 3 (process 32852 thread 0x2103): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x001eb9c2 in VBTRep__MeterMaid () #6 0x002e3651 in ThreadPThread__RunThread () #7 0x002e33a3 in ThreadPThread__ThreadBase () #8 0x96f74155 in _pthread_start () #9 0x96f74012 in thread_start () Thread 2 (process 32852 thread 0x313): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e65ec in RTOS__WaitHeap () #6 0x002d2d54 in RTCollector__WeakCleaner () #7 0x002e3651 in ThreadPThread__RunThread () #8 0x002e33a3 in ThreadPThread__ThreadBase () #9 0x96f74155 in _pthread_start () #10 0x96f74012 in thread_start () Thread 1 (process 32852 local thread 0x2d03): #0 0x96f432ce in semaphore_wait_signal_trap () #1 0x96f752c6 in _pthread_cond_wait () #2 0x96fba539 in pthread_cond_wait () #3 0x002e1947 in ThreadPThread__XWait () #4 0x002e1ef9 in Thread__Wait () #5 0x002e3ddb in Thread__Join () #6 0x0028f53d in Formatter__Close () #7 0x00079485 in JunoUnparse__Expr () #8 0x00021721 in Editor__Pass4 () #9 0x00022048 in EditorUI__CompileUI () #10 0x0003e7f8 in Juno__CompileEditor () #11 0x0003e98d in Juno__CompileModule () #12 0x0003f3be in Juno__CompileModules () #13 0x0004d43d in Juno_M3 () #14 0x002d71fa in RTLinker__RunMainBody () #15 0x002d67b0 in RTLinker__AddUnitI () #16 0x002d682e in RTLinker__AddUnit () #17 0x00003c88 in main () - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Sun, 6 Sep 2009 12:30:27 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Tony both of these timestamps are somewhat prone to hanging during Juno I386_DARWIN startup. But they don't crash, er..well they do both fail assertions in text, but I just put current source in to address that. I'm going to search backward for a time that doesn't hang. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 4 Sep 2009 12:44:21 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] Juno on NT (presumably canary for other problems) Jay, I can rapidly diagnose any problems in the code you have been messing with. Let me get a version on the head that "works" (at least for non-Windows) and then we can move on to see what other problems there may be in the WIndows part of the workd. -- Tony Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 4 Sep 2009, at 10:40, Jay K wrote:no..still unsolved..not sure if I misobserved or what..will have to backtrack.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:07:46 +0000 (Well, duh, it wasn't ProcessPools(SuspendPool), that just has assertions) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 14:06:08 +0000 Restoring the: ThreadF.ProcessPools(ClosePool); 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. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 11:52:28 +0000 I have narrowed it way down to between "2009-02-16 02:00Z" and -D "2009-02-16 02:30Z". So please review this change. I have reviewed it and tried to partly undo it, without luck yet. There is a semantic change in BroadcastHeap where the broadcast used to happen upon the next unlock and now I think happens right away. I tried restoring that, but again, no luck for me. Thanks, - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Subject: RE: [M3devel] Juno on NT (presumably canary for other problems) Date: Fri, 4 Sep 2009 09:12:23 +0000 I have narrowed it down further to between 2/15/2009 and 2/18/2009. Next I will try old text code in head to see if it is that. Tony, can you double check this stuff: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 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..). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Fri, 4 Sep 2009 08:54:54 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) short story: I narrowed it down to between 2/15/2009 and 2/20/2009. I will keep digging. There are actually a lot of changes in that brief period. I will narrow it further. long story: Juno on NT, as canary for other problems. Juno on NT has three behaviors. Behavior #1 The most common historical behavior, an assertion failure: C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x1b3fe30 0x7e418734 0x1b3fe98 0x7e418816 0x1b3fef8 0x7e4189cd 0x1b3ff08 0x7e4196c7 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... (1860.1d80): Break instruction exception - code 80000003 (first chance) eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 edi=005d526b eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 ntdll!DbgBreakPoint: 7c90120e cc int 3 0:003> .lines Line number information will be loaded 0:003> k999 ChildEBP RetAddr 01b3f5bc 005d52b7 ntdll!DbgBreakPoint 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29] 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess. m3 @ 66] 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m 3 @ 118] 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common\RTError.m3 @ 40] 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime\common\RTExcep tion.m3 @ 79] 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src\runtime\commo n\RTException.m3 @ 39] 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src\runtime\commo n\RTException.m3 @ 47] 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src\runtime\common \RTException.m3 @ 25] 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime\ex_frame\RTExFr ame.m3 @ 29] 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime\common\RTHook s.m3 @ 110] 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt\WinContext.m3 @ 1 7] 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt\WinContext.m3 @ 167] 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt\WinPaint.m3 @ 71 2] 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt\WinPaint.m3 @ 5 1] 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt\WinTrestle .m3 @ 1574] 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt\WinTrestle.m3 @ 1163] 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestl e.m3 @ 2450] 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\Threa dWin32.m3 @ 579] 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\Threa dWin32.m3 @ 548] 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 0:003> This we shall blame on Trestle not fully being ported to Win32, I guess. At the very least, it seems to the behavior going back a while. You can occasionally see this in head, but usually you see #3. Behavior #2 Sometimes, rarely, Juno hangs in startup on NT. I believe I have seen this both with fairly old and current versions. This occurs very rarely. I might look into it more after #3 is solved. Behavior #3 An access violation (SIGSEGV to Unix folks) during startup. This is the most common behavior with current source, going back a few months. It is almost always accessing address 00200000 and the instruction pointer is very often in Thread__Join, but neither are always true. Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe (1ac4.1e9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 edi=02812974 eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 m3core!Thread__Join+0x13f: 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds:0023:001ffffc=???????? 0:000> r ebx ebx=00200000 0:000> .lines Line number information will be loaded 0:000> k ChildEBP RetAddr 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread\WIN32\ThreadWin32.m3 @ 710] 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src\JunoCompile. m3 @ 256] 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ 174] 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ 263] 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime\common\RTLi nker.m3 @ 399] 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime\common\RTLinker .m3 @ 113] 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime\common\RTLinker. m3 @ 122] 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\c rt\src\crtexe.c @ 582] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 0:000> #4 sometimes other, for example: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 411 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common\RTCollector.m3 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common\RTHeapMap.m3 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common\RTHeapMap.m3 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common\RTHeapMap.m3 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common\RTCollector.m 3 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common\RTCollector.m3 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src\runtime\common\RT Collector.m3 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common\RTCollector.m3 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common\RTCollector. m3 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common\RTCollector.m3 ......... ......... ... more frames ... (14b0.121c): Break instruction exception - code 80000003 (first chance) for example: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread\WIN32\ThreadWin32.m3 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... (1c3c.e3c): Break instruction exception - code 80000003 (first chance) I figure these are just a variation of #3. Now, I finally learned how to give CVS a date to checkout or update. And NT builds very fast due to the integrated backend. So I have been building various dates. The change between #3 and #1 happened around mid February 2009. Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, #4 above is from 2009/02/20. And 2009/02/20 also access violates on 00200000 often. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 04:34:29 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 02:34:29 +0000 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: [was truncated] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack. Current LINUXLIBC6 Juno doesn't seem to ever hang. So I conclude, with obvious non scientific firmness, that the Darwin-specific threading has never really worked and that the problem lies with it, not within the common code (or perhaps in the common code but only in how it mixes with the Darwin code). - Jay From: jay.krell at cornell.edu [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 05:18:40 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 03:18:40 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack. Current LINUXLIBC6 Juno doesn't seem to ever hang. So I conclude, with obvious non scientific firmness, that the Darwin-specific threading has never really worked and that the problem lies with it, not within the common code (or perhaps in the common code but only in how it mixes with the Darwin code). - Jay From: jay.krell at cornell.edu [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 11:33:39 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 09:33:39 +0000 Subject: [M3devel] (no subject) Message-ID: Tony, can you..um, trick question sort of, briefly explain the differences between pthreads and Modula-3 threads? The "trick" part is that, to an audience (me) who is not all that familiar with the nuances of either? I'll see if I can find my green book and other reference material (online). I understand the basics of threading very well, if that helps. Eh, not much to it really. I'm not super familiar with condition variables, as Win32 didn't historically have them. But I think I understand them. Specific questions: Can Modula-3 threads be implemented more directly upon pthreads? Why do we need to maintain a waiting list? Is "alert" the same as "cancel" in pthread vocabulary? Or almost the same? I understand..there might be a difficult problem..does Modula-3 allow catching an alert? I think so. Does Posix allow canceling a cancel? I think not. Posix allows, what I think of as try/finally, for alert. Modula-3 probably does too. Even though you can't stop the cancel, you can run "cleanup" code that runs before the cancel completes. However mapping Modula-3 to Posix here would be tricky. As I see things..any function with a try/finally would have to be contorted into a form that passes a pointer to itself, along with parameters, to C code that does pthread_cleanup_push/pop around calling the function pointer. At least given the Darwin implementation. Other implementations might simply be able to call push at the start and pop at the end. But on Darwin these functions are macros where push introduces a local variable that pop references. I guess maybe one could to the "reverse engineering" approach (just by reading the header). But it'd still be ugly. I have to do more research here. I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is thinner than the current ThreadPThread.m3 and see how it fairs, specifically if the Juno hangs go away. "writing" being an exaggeration because it should be very small. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 7 17:06:41 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Sep 2009 11:06:41 -0400 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: It used to work... :-) On 6 Sep 2009, at 21:49, Jay K wrote: > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack. > Current LINUXLIBC6 Juno doesn't seem to ever hang. > So I conclude, with obvious non scientific firmness, that the Darwin- > specific threading has never really worked and that the problem lies > with it, not within the common code (or perhaps in the common code > but only in how it mixes with the Darwin code). > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Sun, 6 Sep 2009 16:11:28 +0000 > > Tony, I386_DARWIN Juno is very prone to hang during startup going > back at least until 2007/12/01. > But they certainly don't always hang. > I haven't found a version yet that doesn't hang. I'll look some > more. I guess soon I should try other platforms? > Sometimes there is a pause and it continues. Perhaps the hangs I'm > just being too impatient on?? > But, then, it's a bit inconsistent. > Has it ever worked? > Race condition in Juno maybe? > It isn't always easy to build these old dates. > Caveats: > I'm using just current cm3cg. I started seeing as complain about > older cm3cg output. > Current config files. > Build standalone (as current config files do with older compilers > automatically, for "old" == missing the symlink functions). > Patched XSharedMem/IsSameHost to always be FALSE, though TRUE > would be correct, FALSE seems safe, I have to read that code.. > > Here is 2007/12/01 hung. > It got as far as displaying "Curve" in the startup text that goes by. > > (gdb) thread apply all bt > > Thread 9 (process 32852 thread 0x294f): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1e8c in Thread__AlertWait () > #5 0x00290988 in Formatter__Allocate () > #6 0x00291137 in Formatter__Probe () > #7 0x0029178e in Formatter__Peek () > #8 0x00291677 in Formatter__PeekOp () > #9 0x00291d18 in Formatter__PrintUntil () > #10 0x002918d2 in Formatter__PrintTop () > #11 0x002e3651 in ThreadPThread__RunThread () > #12 0x002e33a3 in ThreadPThread__ThreadBase () > #13 0x96f74155 in _pthread_start () > #14 0x96f74012 in thread_start () > > Thread 8 (process 32852 thread 0x2603): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001aad83 in XMessenger__Messenger () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 7 (process 32852 thread 0x2503): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001b68da in XInput__FilterXInput () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 6 (process 32852 thread 0x240f): > #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () > #1 0x96fc8261 in select () > #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () > #3 0x002e4b05 in ThreadPThread__XIOWait () > #4 0x002e4614 in SchedulerPosix__IOWait () > #5 0x001b65f5 in XInput__WaitForXInput () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 5 (process 32852 thread 0x2303): > #0 0x96f433a6 in mach_wait_until () > #1 0x96fba3ad in nanosleep () > #2 0x002e423c in ThreadPThread__XPause () > #3 0x002e4393 in Thread__Pause () > #4 0x0011113a in FileBrowserVBT__Watcher () > #5 0x002e3651 in ThreadPThread__RunThread () > #6 0x002e33a3 in ThreadPThread__ThreadBase () > #7 0x96f74155 in _pthread_start () > #8 0x96f74012 in thread_start () > > Thread 4 (process 32852 thread 0x2203): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001883f9 in VTView__VFontCleanUpThread () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > Thread 3 (process 32852 thread 0x2103): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x001eb9c2 in VBTRep__MeterMaid () > #6 0x002e3651 in ThreadPThread__RunThread () > #7 0x002e33a3 in ThreadPThread__ThreadBase () > #8 0x96f74155 in _pthread_start () > #9 0x96f74012 in thread_start () > > > Thread 2 (process 32852 thread 0x313): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x002e65ec in RTOS__WaitHeap () > #6 0x002d2d54 in RTCollector__WeakCleaner () > #7 0x002e3651 in ThreadPThread__RunThread () > #8 0x002e33a3 in ThreadPThread__ThreadBase () > #9 0x96f74155 in _pthread_start () > #10 0x96f74012 in thread_start () > > Thread 1 (process 32852 local thread 0x2d03): > #0 0x96f432ce in semaphore_wait_signal_trap () > #1 0x96f752c6 in _pthread_cond_wait () > #2 0x96fba539 in pthread_cond_wait () > #3 0x002e1947 in ThreadPThread__XWait () > #4 0x002e1ef9 in Thread__Wait () > #5 0x002e3ddb in Thread__Join () > #6 0x0028f53d in Formatter__Close () > #7 0x00079485 in JunoUnparse__Expr () > #8 0x00021721 in Editor__Pass4 () > #9 0x00022048 in EditorUI__CompileUI () > #10 0x0003e7f8 in Juno__CompileEditor () > #11 0x0003e98d in Juno__CompileModule () > #12 0x0003f3be in Juno__CompileModules () > #13 0x0004d43d in Juno_M3 () > #14 0x002d71fa in RTLinker__RunMainBody () > #15 0x002d67b0 in RTLinker__AddUnitI () > #16 0x002d682e in RTLinker__AddUnit () > #17 0x00003c88 in main () > > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 6 Sep 2009 12:30:27 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other > problems) > > Tony both of these timestamps are somewhat prone to hanging during > Juno I386_DARWIN startup. But they don't crash, er..well they do > both fail assertions in text, but I just put current source in to > address that. I'm going to search backward for a time that doesn't > hang. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 4 Sep 2009 12:44:21 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Juno on NT (presumably canary for other > problems) > > Jay, > > I can rapidly diagnose any problems in the code you have been > messing with. Let me get a version on the head that "works" (at > least for non-Windows) and then we can move on to see what other > problems there may be in the WIndows part of the workd. > > -- Tony > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 4 Sep 2009, at 10:40, Jay K wrote: > > no..still unsolved..not sure if I misobserved or what..will have to > backtrack.. > > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:07:46 +0000 > > (Well, duh, it wasn't ProcessPools(SuspendPool), that just has > assertions) > > - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 14:06:08 +0000 > > Restoring the: > ThreadF.ProcessPools(ClosePool); > > 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. > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 11:52:28 +0000 > > I have narrowed it way down to between "2009-02-16 02:00Z" and -D > "2009-02-16 02:30Z". > So please review this change. > I have reviewed it and tried to partly undo it, without luck yet. > There is a semantic change in BroadcastHeap where the broadcast used > to happen upon the next unlock > and now I think happens right away. I tried restoring that, but > again, no luck for me. > > Thanks, > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: RE: [M3devel] Juno on NT (presumably canary for other > problems) > Date: Fri, 4 Sep 2009 09:12:23 +0000 > > I have narrowed it down further to between 2/15/2009 and 2/18/2009. > Next I will try old text code in head to see if it is that. > > Tony, can you double check this stuff: > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > > 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..). > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 4 Sep 2009 08:54:54 +0000 > Subject: [M3devel] Juno on NT (presumably canary for other problems) > > short story: > > > I narrowed it down to between 2/15/2009 and 2/20/2009. > I will keep digging. > > There are actually a lot of changes in that brief period. > I will narrow it further. > > > long story: > > Juno on NT, as canary for other problems. > Juno on NT has three behaviors. > > > Behavior #1 > > > The most common historical behavior, an assertion failure: > C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\winvbt\WinContext.m3", line 165 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt > \WinContext.m3 > 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 > 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 > 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt > \WinTrestle.m3 > 0x1b3fe30 0x7e418734 > 0x1b3fe98 0x7e418816 > 0x1b3fef8 0x7e4189cd > 0x1b3ff08 0x7e4196c7 > 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt > \WinTrestle.m3 > ......... ......... ... more frames ... > (1860.1d80): Break instruction exception - code 80000003 (first > chance) > eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 > edi=005d526b > eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl nz > na po nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00000202 > ntdll!DbgBreakPoint: > 7c90120e cc int 3 > 0:003> .lines > Line number information will be loaded > 0:003> k999 > ChildEBP RetAddr > 01b3f5bc 005d52b7 ntdll!DbgBreakPoint > 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime > \WIN32\RTOS.m3 @ 29] > 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime\common > \RTProcess. > m3 @ 66] > 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime > \common\RTError.m > 3 @ 118] > 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common > \RTError.m3 @ > 40] > 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime > \common\RTExcep > tion.m3 @ 79] > 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src > \runtime\commo > n\RTException.m3 @ 39] > 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src > \runtime\commo > n\RTException.m3 @ 47] > 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src > \runtime\common > \RTException.m3 @ 25] > 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime > \ex_frame\RTExFr > ame.m3 @ 29] > 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime > \common\RTHook > s.m3 @ 110] > 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt > \WinContext.m3 @ 1 > 7] > 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt > \WinContext.m3 > @ 167] > 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt > \WinPaint.m3 @ 71 > 2] > 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt > \WinPaint.m3 @ 5 > 1] > 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src\winvbt > \WinTrestle > .m3 @ 1574] > 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt > \WinTrestle.m3 > @ 1163] > 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 > 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 > 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 > 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf > 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src > \winvbt\WinTrestl > e.m3 @ 2450] > 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread > \WIN32\Threa > dWin32.m3 @ 579] > 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread > \WIN32\Threa > dWin32.m3 @ 548] > 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 > 0:003> > > > This we shall blame on Trestle not fully being ported to Win32, I > guess. > At the very least, it seems to the behavior going back a while. > You can occasionally see this in head, but usually you see #3. > > > Behavior #2 > > Sometimes, rarely, Juno hangs in startup on NT. > I believe I have seen this both with fairly old and current versions. > This occurs very rarely. I might look into it more after #3 is solved. > > > Behavior #3 > > > An access violation (SIGSEGV to Unix folks) during startup. > This is the most common behavior with current source, going back a > few months. > It is almost always accessing address 00200000 and the instruction > pointer is very > often in Thread__Join, but neither are always true. > Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. > > > C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe > (1ac4.1e9c): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 > edi=02812974 > eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > m3core!Thread__Join+0x13f: > 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds: > 0023:001ffffc=???????? > 0:000> r ebx > ebx=00200000 > 0:000> .lines > Line number information will be loaded > 0:000> k > ChildEBP RetAddr > 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread > \WIN32\ThreadWin32.m3 > @ 710] > 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src > \JunoCompile. > m3 @ 256] > 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] > 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ 813] > 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] > 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ 140] > 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ > 174] > 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ > 263] > 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] > 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime > \common\RTLi > nker.m3 @ 399] > 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime > \common\RTLinker > .m3 @ 113] > 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime > \common\RTLinker. > m3 @ 122] > 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] > 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld > \self_x86\c > rt\src\crtexe.c @ 582] > 0012fff0 00000000 kernel32!BaseProcessStart+0x23 > 0:000> > > #4 sometimes other, for example: > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 411 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common > \RTCollector.m3 > 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common > \RTHeapMap.m3 > 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common > \RTCollector.m > 3 > 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common > \RTCollector.m3 > 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src > \runtime\common\RT > Collector.m3 > 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common > \RTCollector.m3 > 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common > \RTCollector. > m3 > 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common > \RTCollector.m3 > ......... ......... ... more frames ... > (14b0.121c): Break instruction exception - code 80000003 (first > chance) > > for example: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\src\vbt\VBTRep.m3", line 644 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 > 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 > 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 > 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > (1c3c.e3c): Break instruction exception - code 80000003 (first chance) > > I figure these are just a variation of #3. > > Now, I finally learned how to give CVS a date to checkout or update. > And NT builds very fast due to the integrated backend. > So I have been building various dates. > > The change between #3 and #1 happened around mid February 2009. > Specifically, ignoring the rare #2, 2009/02/15 always fails an assert, > #4 above is from 2009/02/20. > And 2009/02/20 also access violates on 00200000 often. > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 7 17:17:50 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 7 Sep 2009 11:17:50 -0400 Subject: [M3devel] (no subject) In-Reply-To: References: Message-ID: Jay, Before you go off half cocked and brew up some new threads system might I suggest that it would be better to find and fix the current problem. I am sceptical that there is a much thinner M3 thread implementation on top of pthreads than we currently have. I am in the process of tracking down the problem on I386_DARWIN (I see at least one thing broken right now, and will have a fix soon). In answer to your question, the wait list is to deal with M3 alerts, which are not the same as pthread cancellation. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Sep 2009, at 05:33, Jay K wrote: > Tony, can you..um, trick question sort of, briefly explain the > differences between pthreads and Modula-3 threads? > The "trick" part is that, to an audience (me) who is not all that > familiar with the nuances of either? > I'll see if I can find my green book and other reference material > (online). > > > I understand the basics of threading very well, if that helps. > Eh, not much to it really. > > > I'm not super familiar with condition variables, as Win32 didn't > historically have them. > But I think I understand them. > > > Specific questions: > Can Modula-3 threads be implemented more directly upon pthreads? > > > Why do we need to maintain a waiting list? > > > Is "alert" the same as "cancel" in pthread vocabulary? Or almost > the same? > > > I understand..there might be a difficult problem..does Modula-3 > allow catching an alert? I think so. > Does Posix allow canceling a cancel? I think not. > > > Posix allows, what I think of as try/finally, for alert. Modula-3 > probably does too. Even though you can't stop the cancel, you can > run "cleanup" code that runs before the cancel completes. > > > However mapping Modula-3 to Posix here would be tricky. As I see > things..any function with a try/finally would have to be contorted > into a form that passes a pointer to itself, along with parameters, > to C code that does pthread_cleanup_push/pop around calling the > function pointer. At least given the Darwin implementation. Other > implementations might simply be able to call push at the start and > pop at the end. But on Darwin these functions are macros where push > introduces a local variable that pop references. I guess maybe one > could to the "reverse engineering" approach (just by reading the > header). But it'd still be ugly. > > > I have to do more research here. > > > I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is > thinner than the current ThreadPThread.m3 and see how it fairs, > specifically if the Juno hangs go away. > "writing" being an exaggeration because it should be very small. > > > Thanks, > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Sep 7 17:30:52 2009 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 7 Sep 2009 15:30:52 +0000 (GMT) Subject: [M3devel] (no subject) Threads Primitives In-Reply-To: Message-ID: <258903.40993.qm@web23604.mail.ird.yahoo.com> Hi all: Please consider this reading:? "Synchronization Primitives for Threads" which has a formal definition and proof for threads primitives: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.1092 and? "Pthreads and Applications of Mutex-Abstraction" http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5367 Also the formal definition of the thread Interface from DEC SRC research Report 20 (revised in the Green book, Systems programming with Modula-3 as? Chapter 5): ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/abstracts/src-rr-020.html and? an introduction to programming with Threads DEC SRC research Report 35 (revised in the Green book, Systems programming with Modula-3 as? Chapter 4) ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/SRC-035.pdf Hope it helps --- El lun, 7/9/09, Jay K escribi?: De: Jay K Asunto: [M3devel] (no subject) Para: "Tony" , "m3devel" Fecha: lunes, 7 septiembre, 2009 4:33 #yiv792797967 .hmmessage P { margin:0px;padding:0px;} #yiv792797967 { font-size:10pt;font-family:Verdana;} Tony, can you..um, trick question sort of, briefly explain the differences between pthreads and Modula-3 threads? The "trick" part is that, to an audience (me) who is not all that familiar with the nuances of either? I'll see if I can find my green book and other reference material (online). I understand the basics of threading very well, if that helps. Eh, not much to it really. I'm not super familiar with condition variables, as Win32 didn't historically have them. But I think I understand them. Specific questions: ? Can Modula-3 threads be implemented more directly upon pthreads? ? Why do we need to maintain a waiting list? ? Is "alert" the same as "cancel" in pthread vocabulary? Or almost the same? ? I understand..there might be a difficult problem..does Modula-3 allow catching an alert? I think so. ? Does Posix allow canceling a cancel? I think not. ? Posix allows, what I think of as try/finally, for alert. Modula-3 probably does too. Even though you can't stop the cancel, you can run "cleanup" code that runs before the cancel completes. However mapping Modula-3 to Posix here would be tricky. As I see things..any function with a try/finally would have to be contorted into a form that passes a pointer to itself, along with parameters, to C code that does pthread_cleanup_push/pop around calling the function pointer. At least given the Darwin implementation. Other implementations might simply be able to call push at the start and pop at the end. But on Darwin these functions are macros where push introduces a local variable that pop references. I guess maybe one could to the "reverse engineering" approach (just by reading the header). But it'd still be ugly. I have to do more research here. I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is thinner than the current ThreadPThread.m3 and see how it fairs, specifically if the Juno hangs go away. "writing" being an exaggeration because it should be very small. Thanks, ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 7 18:03:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 7 Sep 2009 16:03:21 +0000 Subject: [M3devel] Modula-3 threads vs. pthreads? In-Reply-To: References: Message-ID: To answer part of my question the same as you did, this (buggy -- race conditions) program demonstrates that Alert is catchable, whereas apparently pthread_cancel is not. MODULE Main; IMPORT IO, Thread; PROCEDURE ThreadMain (<* UNUSED *> closure: Thread.Closure): REFANY = VAR i := 0; BEGIN TRY LOOP TRY Thread.AlertPause(0.01D0); IO.PutInt(i); IO.Put("\n"); EXCEPT Thread.Alerted => IO.Put("Thread.Alerted 1\n"); INC(i, 1); IF i = 10 THEN (*RAISE Thread.Alerted;*) RETURN NIL; END; ELSE IO.Put("Thread.Alerted 3?\n"); END END; FINALLY IO.Put("Thread.Alerted 2\n"); END; RETURN NIL; END ThreadMain; VAR a := Thread.Fork(NEW(Thread.Closure, apply := ThreadMain)); BEGIN FOR i := 1 TO 10 DO Thread.Pause(1.0D0); Thread.Alert(a); END; EVAL Thread.Join(a); END Main. Thanks, - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: Date: Mon, 7 Sep 2009 11:17:50 -0400 Jay, Before you go off half cocked and brew up some new threads system might I suggest that it would be better to find and fix the current problem. I am sceptical that there is a much thinner M3 thread implementation on top of pthreads than we currently have. I am in the process of tracking down the problem on I386_DARWIN (I see at least one thing broken right now, and will have a fix soon). In answer to your question, the wait list is to deal with M3 alerts, which are not the same as pthread cancellation. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Sep 2009, at 05:33, Jay K wrote:Tony, can you..um, trick question sort of, briefly explain the differences between pthreads and Modula-3 threads? The "trick" part is that, to an audience (me) who is not all that familiar with the nuances of either? I'll see if I can find my green book and other reference material (online). I understand the basics of threading very well, if that helps. Eh, not much to it really. I'm not super familiar with condition variables, as Win32 didn't historically have them. But I think I understand them. Specific questions: Can Modula-3 threads be implemented more directly upon pthreads? Why do we need to maintain a waiting list? Is "alert" the same as "cancel" in pthread vocabulary? Or almost the same? I understand..there might be a difficult problem..does Modula-3 allow catching an alert? I think so. Does Posix allow canceling a cancel? I think not. Posix allows, what I think of as try/finally, for alert. Modula-3 probably does too. Even though you can't stop the cancel, you can run "cleanup" code that runs before the cancel completes. However mapping Modula-3 to Posix here would be tricky. As I see things..any function with a try/finally would have to be contorted into a form that passes a pointer to itself, along with parameters, to C code that does pthread_cleanup_push/pop around calling the function pointer. At least given the Darwin implementation. Other implementations might simply be able to call push at the start and pop at the end. But on Darwin these functions are macros where push introduces a local variable that pop references. I guess maybe one could to the "reverse engineering" approach (just by reading the header). But it'd still be ugly. I have to do more research here. I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is thinner than the current ThreadPThread.m3 and see how it fairs, specifically if the Juno hangs go away. "writing" being an exaggeration because it should be very small. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Mon Sep 7 14:22:03 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Mon, 07 Sep 2009 14:22:03 +0200 Subject: [M3devel] Server Maint. birch.elego.de tonight 22:00 CEST Message-ID: <20090907142203.thu0879lw4oosc8w@mail.elego.de> Hallo, Heute Abend um 22:00 Uhr CEST wird der Server birch.elego.de kurz herunterfahren um eine fehlerhafte Festplatte zu ersetzen. Betroffen werden www/ftp.elegosoft.com, die modula3 Websites, sowie die modula3 cvs Repositories and continuous-integration Dienste. Wir bitten um Verst?ndnis. - die elego Admins The server birch.elego.de will be taken offline for a short time this evening at 22:00 CEST in order to replace a failing disk drive. The internet sites www/ftp.elegosoft.de, www/ftp.elego.de, the modula3 sites, as well as the modula3 cvs repositories and continuous integration servers will be affected. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 8 03:22:29 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Mon, 7 Sep 2009 18:22:29 -0700 Subject: [M3devel] Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: When did it work? I have looked quite a bit and have not found anything that works. - Jay (phone) On Sep 7, 2009, at 8:06 AM, Tony Hosking wrote: > It used to work... > > :-) > > On 6 Sep 2009, at 21:49, Jay K wrote: > >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of >> stack. >> Current LINUXLIBC6 Juno doesn't seem to ever hang. >> So I conclude, with obvious non scientific firmness, that the >> Darwin-specific threading has never really worked and that the >> problem lies with it, not within the common code (or perhaps in the >> common code but only in how it mixes with the Darwin code). >> >> - Jay >> >> >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Sun, 6 Sep 2009 16:11:28 +0000 >> >> Tony, I386_DARWIN Juno is very prone to hang during startup going >> back at least until 2007/12/01. >> But they certainly don't always hang. >> I haven't found a version yet that doesn't hang. I'll look some >> more. I guess soon I should try other platforms? >> Sometimes there is a pause and it continues. Perhaps the hangs >> I'm just being too impatient on?? >> But, then, it's a bit inconsistent. >> Has it ever worked? >> Race condition in Juno maybe? >> It isn't always easy to build these old dates. >> Caveats: >> I'm using just current cm3cg. I started seeing as complain about >> older cm3cg output. >> Current config files. >> Build standalone (as current config files do with older compilers >> automatically, for "old" == missing the symlink functions). >> Patched XSharedMem/IsSameHost to always be FALSE, though TRUE >> would be correct, FALSE seems safe, I have to read that code.. >> >> Here is 2007/12/01 hung. >> It got as far as displaying "Curve" in the startup text that goes by. >> >> (gdb) thread apply all bt >> >> Thread 9 (process 32852 thread 0x294f): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1e8c in Thread__AlertWait () >> #5 0x00290988 in Formatter__Allocate () >> #6 0x00291137 in Formatter__Probe () >> #7 0x0029178e in Formatter__Peek () >> #8 0x00291677 in Formatter__PeekOp () >> #9 0x00291d18 in Formatter__PrintUntil () >> #10 0x002918d2 in Formatter__PrintTop () >> #11 0x002e3651 in ThreadPThread__RunThread () >> #12 0x002e33a3 in ThreadPThread__ThreadBase () >> #13 0x96f74155 in _pthread_start () >> #14 0x96f74012 in thread_start () >> >> Thread 8 (process 32852 thread 0x2603): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001aad83 in XMessenger__Messenger () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 7 (process 32852 thread 0x2503): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001b68da in XInput__FilterXInput () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 6 (process 32852 thread 0x240f): >> #0 0x96f7a3ca in select$DARWIN_EXTSN$NOCANCEL () >> #1 0x96fc8261 in select () >> #2 0x002e4dab in ThreadPThread__XIOWait__CallSelect.1042 () >> #3 0x002e4b05 in ThreadPThread__XIOWait () >> #4 0x002e4614 in SchedulerPosix__IOWait () >> #5 0x001b65f5 in XInput__WaitForXInput () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 5 (process 32852 thread 0x2303): >> #0 0x96f433a6 in mach_wait_until () >> #1 0x96fba3ad in nanosleep () >> #2 0x002e423c in ThreadPThread__XPause () >> #3 0x002e4393 in Thread__Pause () >> #4 0x0011113a in FileBrowserVBT__Watcher () >> #5 0x002e3651 in ThreadPThread__RunThread () >> #6 0x002e33a3 in ThreadPThread__ThreadBase () >> #7 0x96f74155 in _pthread_start () >> #8 0x96f74012 in thread_start () >> >> Thread 4 (process 32852 thread 0x2203): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001883f9 in VTView__VFontCleanUpThread () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> Thread 3 (process 32852 thread 0x2103): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x001eb9c2 in VBTRep__MeterMaid () >> #6 0x002e3651 in ThreadPThread__RunThread () >> #7 0x002e33a3 in ThreadPThread__ThreadBase () >> #8 0x96f74155 in _pthread_start () >> #9 0x96f74012 in thread_start () >> >> >> Thread 2 (process 32852 thread 0x313): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x002e65ec in RTOS__WaitHeap () >> #6 0x002d2d54 in RTCollector__WeakCleaner () >> #7 0x002e3651 in ThreadPThread__RunThread () >> #8 0x002e33a3 in ThreadPThread__ThreadBase () >> #9 0x96f74155 in _pthread_start () >> #10 0x96f74012 in thread_start () >> >> Thread 1 (process 32852 local thread 0x2d03): >> #0 0x96f432ce in semaphore_wait_signal_trap () >> #1 0x96f752c6 in _pthread_cond_wait () >> #2 0x96fba539 in pthread_cond_wait () >> #3 0x002e1947 in ThreadPThread__XWait () >> #4 0x002e1ef9 in Thread__Wait () >> #5 0x002e3ddb in Thread__Join () >> #6 0x0028f53d in Formatter__Close () >> #7 0x00079485 in JunoUnparse__Expr () >> #8 0x00021721 in Editor__Pass4 () >> #9 0x00022048 in EditorUI__CompileUI () >> #10 0x0003e7f8 in Juno__CompileEditor () >> #11 0x0003e98d in Juno__CompileModule () >> #12 0x0003f3be in Juno__CompileModules () >> #13 0x0004d43d in Juno_M3 () >> #14 0x002d71fa in RTLinker__RunMainBody () >> #15 0x002d67b0 in RTLinker__AddUnitI () >> #16 0x002d682e in RTLinker__AddUnit () >> #17 0x00003c88 in main () >> >> >> - Jay >> >> >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Sun, 6 Sep 2009 12:30:27 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Juno on NT (presumably canary for other >> problems) >> >> Tony both of these timestamps are somewhat prone to hanging during >> Juno I386_DARWIN startup. But they don't crash, er..well they do >> both fail assertions in text, but I just put current source in to >> address that. I'm going to search backward for a time that doesn't >> hang. >> >> - Jay >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Fri, 4 Sep 2009 12:44:21 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Juno on NT (presumably canary for other >> problems) >> >> Jay, >> >> I can rapidly diagnose any problems in the code you have been >> messing with. Let me get a version on the head that "works" (at >> least for non-Windows) and then we can move on to see what other >> problems there may be in the WIndows part of the workd. >> >> -- Tony >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 4 Sep 2009, at 10:40, Jay K wrote: >> >> no..still unsolved..not sure if I misobserved or what..will have to >> backtrack.. >> >> >> - Jay >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 14:07:46 +0000 >> >> (Well, duh, it wasn't ProcessPools(SuspendPool), that just has >> assertions) >> >> - Jay >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 14:06:08 +0000 >> >> Restoring the: >> ThreadF.ProcessPools(ClosePool); >> >> 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. >> >> - Jay >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 11:52:28 +0000 >> >> I have narrowed it way down to between "2009-02-16 02:00Z" and -D >> "2009-02-16 02:30Z". >> So please review this change. >> I have reviewed it and tried to partly undo it, without luck yet. >> There is a semantic change in BroadcastHeap where the broadcast >> used to happen upon the next unlock >> and now I think happens right away. I tried restoring that, but >> again, no luck for me. >> >> Thanks, >> - Jay >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com; hosking at cs.purdue.edu >> Subject: RE: [M3devel] Juno on NT (presumably canary for other >> problems) >> Date: Fri, 4 Sep 2009 09:12:23 +0000 >> >> I have narrowed it down further to between 2/15/2009 and 2/18/2009. >> Next I will try old text code in head to see if it is that. >> >> Tony, can you double check this stuff: >> >> 2009-02-16 02:20 hosking >> >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ >> dtoa.c, >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ >> ThreadPThreadC.i3, >> thread/WIN32/ThreadWin32.m3: >> >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better >> match underlying pthread semantics. >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap >> is held. >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or >> not. >> >> >> 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..). >> >> >> - Jay >> >> >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Fri, 4 Sep 2009 08:54:54 +0000 >> Subject: [M3devel] Juno on NT (presumably canary for other problems) >> >> short story: >> >> >> I narrowed it down to between 2/15/2009 and 2/20/2009. >> I will keep digging. >> >> There are actually a lot of changes in that brief period. >> I will narrow it further. >> >> >> long story: >> >> Juno on NT, as canary for other problems. >> Juno on NT has three behaviors. >> >> >> Behavior #1 >> >> >> The most common historical behavior, an assertion failure: >> C:\cm3.2009-02-20>\bin\x86\cdb \cm3.2009-02-01\bin\Juno.exe >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "..\src\winvbt\WinContext.m3", line 165 >> *** >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x1b3f830 0xf61c9a PushPixmap + 0x43c in ..\src\winvbt >> \WinContext.m3 >> 0x1b3f8f8 0xf6fdcc PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 >> 0x1b3fd54 0xf6dcf5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 >> 0x1b3fdbc 0xf685be PaintBatchVBT + 0x12d in ..\src\winvbt >> \WinTrestle.m3 >> 0x1b3fe04 0xf66ebd WindowProc + 0x699 in ..\src\winvbt >> \WinTrestle.m3 >> 0x1b3fe30 0x7e418734 >> 0x1b3fe98 0x7e418816 >> 0x1b3fef8 0x7e4189cd >> 0x1b3ff08 0x7e4196c7 >> 0x1b3ff50 0xf6bc99 MessengerApply + 0x21f in ..\src\winvbt >> \WinTrestle.m3 >> ......... ......... ... more frames ... >> (1860.1d80): Break instruction exception - code 80000003 (first >> chance) >> eax=00000001 ebx=000000a5 ecx=00001e2f edx=7c90e514 esi=01b3f5d8 >> edi=005d526b >> eip=7c90120e esp=01b3f5c0 ebp=01b3f5d8 iopl=0 nv up ei pl >> nz na po nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00000202 >> ntdll!DbgBreakPoint: >> 7c90120e cc int 3 >> 0:003> .lines >> Line number information will be loaded >> 0:003> k999 >> ChildEBP RetAddr >> 01b3f5bc 005d52b7 ntdll!DbgBreakPoint >> 01b3f5d8 005cbd9e m3core!RTOS__Crash+0x4c [..\src\runtime >> \WIN32\RTOS.m3 @ 29] >> 01b3f5f0 005c9b0e m3core!RTProcess__Crash+0x68 [..\src\runtime >> \common\RTProcess. >> m3 @ 66] >> 01b3f608 005c9822 m3core!RTError__EndError+0x37 [..\src\runtime >> \common\RTError.m >> 3 @ 118] >> 01b3f620 005ca0c3 m3core!RTError__MsgS+0x8d [..\src\runtime\common >> \RTError.m3 @ >> 40] >> 01b3f668 005c9e61 m3core!RTException__Crash+0x1d0 [..\src\runtime >> \common\RTExcep >> tion.m3 @ 79] >> 01b3f6a0 005c9dc1 m3core!RTException__DefaultBackstop+0x6f [..\src >> \runtime\commo >> n\RTException.m3 @ 39] >> 01b3f6bc 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src >> \runtime\common >> \RTException.m3 @ 25] >> 01b3f6e8 005c9eeb m3core!RTException__Raise+0x63 [..\src\runtime >> \ex_frame\RTExFr >> ame.m3 @ 29] >> 01b3f718 005c9dc1 m3core!RTException__DefaultBackstop+0xf9 [..\src >> \runtime\commo >> n\RTException.m3 @ 47] >> 01b3f734 005d6df3 m3core!RTException__InvokeBackstop+0x28 [..\src >> \runtime\common >> \RTException.m3 @ 25] >> 01b3f760 005b5669 m3core!RTException__Raise+0x63 [..\src\runtime >> \ex_frame\RTExFr >> ame.m3 @ 29] >> 01b3f7a4 00f62a39 m3core!RTHooks__ReportFault+0x93 [..\src\runtime >> \common\RTHook >> s.m3 @ 110] >> 01b3f7b4 00f61c9a m3ui!MM_WinContext_CRASH+0x11 [..\src\winvbt >> \WinContext.m3 @ 1 >> 7] >> 01b3f830 00f6fdcc m3ui!WinContext__PushPixmap+0x43c [..\src\winvbt >> \WinContext.m3 >> @ 167] >> 01b3f8f8 00f6dcf5 m3ui!WinPaint__PixmapCom+0x932 [..\src\winvbt >> \WinPaint.m3 @ 71 >> 2] >> 01b3fd54 00f685be m3ui!WinPaint__PaintBatch+0x225 [..\src\winvbt >> \WinPaint.m3 @ 5 >> 1] >> 01b3fdbc 00f66ebd m3ui!WinTrestle__PaintBatchVBT+0x12d [..\src >> \winvbt\WinTrestle >> .m3 @ 1574] >> 01b3fe04 7e418734 m3ui!WinTrestle__WindowProc+0x699 [..\src\winvbt >> \WinTrestle.m3 >> @ 1163] >> 01b3fe30 7e418816 USER32!InternalCallWinProc+0x28 >> 01b3fe98 7e4189cd USER32!UserCallWinProcCheckWow+0x150 >> 01b3fef8 7e4196c7 USER32!DispatchMessageWorker+0x306 >> 01b3ff08 00f6bc99 USER32!DispatchMessageA+0xf >> 01b3ff50 005d9e8a m3ui!WinTrestle__MessengerApply+0x21f [..\src >> \winvbt\WinTrestl >> e.m3 @ 2450] >> 01b3ff88 005d9c23 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread >> \WIN32\Threa >> dWin32.m3 @ 579] >> 01b3ffb4 7c80b729 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread >> \WIN32\Threa >> dWin32.m3 @ 548] >> 01b3ffec 00000000 kernel32!BaseThreadStart+0x37 >> 0:003> >> >> >> This we shall blame on Trestle not fully being ported to Win32, I >> guess. >> At the very least, it seems to the behavior going back a while. >> You can occasionally see this in head, but usually you see #3. >> >> >> Behavior #2 >> >> Sometimes, rarely, Juno hangs in startup on NT. >> I believe I have seen this both with fairly old and current versions. >> This occurs very rarely. I might look into it more after #3 is >> solved. >> >> >> Behavior #3 >> >> >> An access violation (SIGSEGV to Unix folks) during startup. >> This is the most common behavior with current source, going back a >> few months. >> It is almost always accessing address 00200000 and the instruction >> pointer is very >> often in Thread__Join, but neither are always true. >> Sometimes it accesses 00200000 elsewhere. Sometimes it accesses NULL. >> >> >> C:\cm3.2009-02-20>\bin\x86\cdb -g \cm3.2009-03-01\bin\Juno.exe >> (1ac4.1e9c): Access violation - code c0000005 (first chance) >> First chance exceptions are reported before any exception handling. >> This exception may be expected and handled. >> eax=00000001 ebx=00200000 ecx=00000004 edx=0060b150 esi=021a6600 >> edi=02812974 >> eip=005dac96 esp=0012f97c ebp=0012f9a0 iopl=0 nv up ei pl >> nz na pe nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00010206 >> m3core!Thread__Join+0x13f: >> 005dac96 8b53fc mov edx,dword ptr [ebx-4] ds: >> 0023:001ffffc=???????? >> 0:000> r ebx >> ebx=00200000 >> 0:000> .lines >> Line number information will be loaded >> 0:000> k >> ChildEBP RetAddr >> 0012f9a0 1000e263 m3core!Thread__Join+0x13f [..\src\thread >> \WIN32\ThreadWin32.m3 >> @ 710] >> 0012f9e4 0041c7b7 juno_compiler!JunoCompile__ProcDecl+0x1f9 [..\src >> \JunoCompile. >> m3 @ 256] >> 0012fa1c 0041d195 Juno!Editor__Pass2+0x1a5 [..\src\Editor.m3 @ 730] >> 0012fac8 0041d04e Juno!Editor__Compile2+0x137 [..\src\Editor.m3 @ >> 813] >> 0012fafc 0043d555 Juno!Editor__Compile+0x53 [..\src\Editor.m3 @ 793] >> 0012fb3c 0043d74e Juno!Juno__CompileEditor+0x2c [..\src\Juno.m3 @ >> 140] >> 0012fbd8 0043e079 Juno!Juno__CompileModule+0x12c [..\src\Juno.m3 @ >> 174] >> 0012fd80 0044b6a5 Juno!Juno__CompileModules+0x2d1 [..\src\Juno.m3 @ >> 263] >> 0012fee0 005c8e14 Juno!Juno_M3+0x1fa1 [..\src\Juno.m3 @ 2134] >> 0012ff24 005c83ec m3core!RTLinker__RunMainBody+0x25a [..\src\runtime >> \common\RTLi >> nker.m3 @ 399] >> 0012ff3c 005c8495 m3core!RTLinker__AddUnitI+0xf7 [..\src\runtime >> \common\RTLinker >> .m3 @ 113] >> 0012ff60 00401038 m3core!RTLinker__AddUnit+0xa1 [..\src\runtime >> \common\RTLinker. >> m3 @ 122] >> 0012ff7c 004b0d84 Juno!main+0x38 [_m3main.mc @ 4] >> 0012ffc0 7c817077 Juno!__tmainCRTStartup+0x10f [f:\dd\vctools >> \crt_bld\self_x86\c >> rt\src\crtexe.c @ 582] >> 0012fff0 00000000 kernel32!BaseProcessStart+0x23 >> 0:000> >> >> #4 sometimes other, for example: >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "..\src\runtime\common\RTCollector.m3", line 411 >> *** >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x12f710 0x5bf033 Move + 0xcc in ..\src\runtime\common >> \RTCollector.m3 >> 0x12f754 0x5bae91 Walk + 0x467 in ..\src\runtime\common >> \RTHeapMap.m3 >> 0x12f778 0x5ba76a DoWalkRef + 0x62 in ..\src\runtime\common >> \RTHeapMap.m3 >> 0x12f7a4 0x5ba700 WalkRef + 0x100 in ..\src\runtime\common >> \RTHeapMap.m3 >> 0x12f7cc 0x5c0bb0 CleanBetween + 0xe1 in ..\src\runtime\common >> \RTCollector.m >> 3 >> 0x12f7f8 0x5c0a20 CleanPage + 0x5b in ..\src\runtime\common >> \RTCollector.m3 >> 0x12f84c 0x5c0312 CollectSomeInStateZero + 0x5b2 in ..\src >> \runtime\common\RT >> Collector.m3 >> 0x12f860 0x5bfd24 CollectSome + 0x6e in ..\src\runtime\common >> \RTCollector.m3 >> 0x12f890 0x5bfa23 CollectEnough + 0x90 in ..\src\runtime\common >> \RTCollector. >> m3 >> 0x12f8f0 0x5c18c0 AllocTraced + 0xef in ..\src\runtime\common >> \RTCollector.m3 >> ......... ......... ... more frames ... >> (14b0.121c): Break instruction exception - code 80000003 (first >> chance) >> >> for example: >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "..\src\vbt\VBTRep.m3", line 644 >> *** >> Stack trace: >> FP PC Procedure >> --------- --------- ------------------------------- >> 0x260fee8 0xf92ae9 Redisplay + 0x38d in ..\src\vbt\VBTRep.m3 >> 0x260ff10 0xf926a8 UncoverRedisplay + 0xd2 in ..\src\vbt\VBTRep.m3 >> 0x260ff38 0xf9272a RdApply + 0x7d in ..\src\vbt\VBTRep.m3 >> 0x260ff88 0x5da3ab RunThread + 0x207 in ..\src\thread >> \WIN32\ThreadWin32.m3 >> 0x260ffb4 0x5da133 ThreadBase + 0x3a in ..\src\thread >> \WIN32\ThreadWin32.m3 >> ......... ......... ... more frames ... >> (1c3c.e3c): Break instruction exception - code 80000003 (first >> chance) >> >> I figure these are just a variation of #3. >> >> Now, I finally learned how to give CVS a date to checkout or update. >> And NT builds very fast due to the integrated backend. >> So I have been building various dates. >> >> The change between #3 and #1 happened around mid February 2009. >> Specifically, ignoring the rare #2, 2009/02/15 always fails an >> assert, >> #4 above is from 2009/02/20. >> And 2009/02/20 also access violates on 00200000 often. >> >> >> - Jay >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 07:58:53 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 01:58:53 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: Here's the hang I see for juno running on I386_DARWIN. If the stack is overflowing this could cause a hang. Otherwise, I see nothing innately suspicious in these thread backtraces. Any ideas? Thread 8 (process 94794 thread 0x2a9f): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x17a6844, M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e7a6 in Thread__AlertWait (M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824) at ../src/thread/PTHREAD/ThreadPThread.m3:267 #5 0x0075cdf2 in Formatter__Allocate (M3_ACp9GL_t=0x16e99fc, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x0075cf0a in Formatter__Probe (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x0075d2b8 in Formatter__Peek (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x0075d2ff in Formatter__PeekOp (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x0075db25 in Formatter__PrintUntil (M3_ACp9GL_t=0x16e99fc, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x2162430) at ../src/ formatter/Formatter.m3:708 #10 0x0075dfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x17a6834) at ../ src/formatter/Formatter.m3:615 #11 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1527e00) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #12 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1527e00) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 7 (process 94794 thread 0x2503): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x1705d88, M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044a0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044a0) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x004c1962 in XMessenger__Messenger (M3_EVlqQO_self=0x1705d78) at ../src/xvbt/XMessenger.m3:69 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1511f60) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1511f60) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 6 (process 94794 thread 0x2407): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x1705d38, M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044c0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x1704128, M3_Bl0jv4_c=0x17044c0) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x004c7bc2 in XInput__FilterXInput (M3_DSd60P_self=0x1705d28) at ../src/xvbt/XInput.m3:102 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1511de0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1511de0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 5 (process 94794 thread 0x230f): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x00944503 in Unix__select (nfds=4, readfds=0x17a90c4, writefds=0x17a90d4, exceptfds=0x17a90e4, timeout=0x0) at ../src/unix/ Common/UnixC.c:301 #2 0x00941970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ PTHREAD/ThreadPThread.m3:788 #3 0x009416cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1705ce8, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ PTHREAD/ThreadPThread.m3:827 #4 0x009411b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ thread/PTHREAD/ThreadPThread.m3:730 #5 0x004c920b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1705cd8) at ../src/xvbt/XInput.m3:63 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1511d10) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1511d10) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 4 (process 94794 thread 0x2203): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x00943cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x00940d7c in ThreadPThread__XPause (M3_BXP32l_self=0x1640ed8, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:669 #4 0x00940ef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:686 #5 0x0031bd53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1640ed0) at ../src/lego/FileBrowserVBT.m3:259 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1510200) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1510200) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 3 (process 94794 thread 0x2103): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x160c410, M3_AYIbX3_m=0x160c3ec, M3_Bl0jv4_c=0x160c3f8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x160c3ec, M3_Bl0jv4_c=0x160c3f8) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0038d9e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x160c408) at ../src/vtext/VTView.m3:111 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x15103a0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x15103a0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 2 (process 94794 thread 0x1003): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x16079d8, M3_AYIbX3_m=0x1607998, M3_Bl0jv4_c=0x16079a4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x1607998, M3_Bl0jv4_c=0x16079a4) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x004fd3d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x16079cc) at ../ src/vbt/VBTRep.m3:439 #6 0x00940243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x150fdd0) at ../src/thread/PTHREAD/ThreadPThread.m3:547 #7 0x0093ff74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x150fdd0) at ../src/thread/PTHREAD/ ThreadPThread.m3:523 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 1 (process 94794 thread 0x10b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0093e189 in ThreadPThread__XWait (M3_BXP32l_self=0x160000c, M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:227 #4 0x0093e823 in Thread__Wait (M3_AYIbX3_m=0x17a6818, M3_Bl0jv4_c=0x17a6824) at ../src/thread/PTHREAD/ThreadPThread.m3:278 #5 0x0075c592 in Formatter__WaitUntilEmpty (M3_ACp9GL_t=0x16e99fc, M3_Cwb5VA_index=) at ../src/formatter/Formatter.m3:491 #6 0x0076092a in Formatter__Flush (M3_ACp9GL_t=0x16e99fc) at ../src/ formatter/Formatter.m3:219 #7 0x0014d2f3 in JunoUnparse__Unparse (M3_ACp9GL_fmt=0x16e99fc, M3_Dpy7Ic_ast=0x16e9520, M3_AcxOUs_tokens=2147483647, M3_AcxOUs_indent=0, M3_AcxOUs_prec=3, M3_AicXUJ_debug=0 '\0', M3_AicXUJ_private=1 '\001', M3_Dpy7Ic_errast=0x0) at ../src/ JunoUnparse.m3:1016 #8 0x0014d5f9 in JunoUnparse__Expr (M3_BxxOH1_wr=0x16e9548, M3_ATZ4pH_ast=0x16e9520, M3_Cwb5VA_tokens=, M3_Cwb5VA_indent=, M3_Cwb5VA_width=, M3_Cwb5VA_prec=, M3_AicXUJ_debug=0 '\0') at ../src/ JunoUnparse.m3:52 #9 0x0001da6e in Editor__Pass4 (M3_EchL3i_rt=0x16df008, M3_ALfX9C_ed=0x240ddbc, M3_ClYh8q_scp=0x161b7dc) at ../src/Editor.m3:904 #10 0x0002204d in EditorUI__CompileUI (M3_EchL3i_rt=0x16df008, M3_ALfX9C_te=0x240ddbc, M3_AcxOUs_time=0, M3_ClYh8q_scp=0x161b7dc) at ../src/Editor.m3:1007 #11 0x00046b70 in Juno__CompileEditor (M3_EchL3i_rt=0x16df008, M3_ALfX9C_ed=0x240ddbc, M3_AcxOUs_time=0, M3_ClYh8q_scp=0x16dedd8, M3_A0YqHX_modName=0xbfffe870, M3_EmmWP2_entity=0xbfffe86c, M3_AicXUJ_uniqueModName=1 '\001') at ../src/Juno.m3:140 #12 0x00046eeb in Juno__CompileModule (M3_BtMpDB_w=0x1764f78, M3_Bd56fi_mod=0x2408b00, M3_EkTcCb_rd=0x240d7d0, M3_AicXUJ_augment=0 '\0') at ../src/Juno.m3:174 #13 0x00047b59 in Juno__CompileModules (M3_BtMpDB_w=0x1764f78, M3_EkTcCb_rd=0x17a35a4, M3_Al6NTd_modList=0xbfffec94, M3_AicXUJ_fromRsrc=1 '\001') at ../src/Juno.m3:263 #14 0x0004a9d9 in Juno_M3 (M3_AcxOUs_mode=1) at ../src/Juno.m3:2134 #15 0x0092fb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x5aee0) at ../ src/runtime/common/RTLinker.m3:399 #16 0x00002518 in main (argc=1, argv=0xbfffedec, envp=0xbfffedf4) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 08:09:28 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 02:09:28 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: Message-ID: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:668 #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:685 #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ src/xvbt/XClientF.m3:105 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103): #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ thread/PTHREAD/ThreadPThread.m3:319 #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../ src/thread/PTHREAD/ThreadPThread.m3:669 #2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ ThreadPThread.m3:699 #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ src/Animate.m3:71 #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313 #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ src/bresenham/ViewError.m3:548 #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ src/Zeus.m3:331 #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #11 0x96373155 in _pthread_start () #12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ src/Zeus.m3:328 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ src/Zeus.m3:328 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03): #0 0x963493dc in _pthread_testcancel () #1 0x96349275 in nanosleep$UNIX2003 () #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:668 #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ PTHREAD/ThreadPThread.m3:685 #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/ vtext/VTCaret.m3:149 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ src/trestle/Trestle.m3:884 #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74 #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #9 0x96373155 in _pthread_start () #10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ Common/UnixC.c:301 #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ PTHREAD/ThreadPThread.m3:787 #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ PTHREAD/ThreadPThread.m3:826 #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ thread/PTHREAD/ThreadPThread.m3:729 #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 #7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../ src/bresenham/AlgBresenham.m3:55 #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ src/bresenham/AlgBresenham.m3:86 #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../ src/ZeusPanel.m3:1534 #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../ src/formatter/Formatter.m3:615 #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ formatter/Formatter.m3:440 #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ formatter/Formatter.m3:708 #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../ src/formatter/Formatter.m3:615 #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #13 0x96373155 in _pthread_start () #14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313): #0 0x963916fa in select$DARWIN_EXTSN () #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/ unix/Common/UnixC.c:301 #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/ thread/PTHREAD/ThreadPThread.m3:787 #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ src/thread/PTHREAD/ThreadPThread.m3:742 #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/ TCP.m3:234 #7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #10 0x96373155 in _pthread_start () #11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003): #0 0x9634946e in __semwait_signal () #1 0x963492ef in nanosleep$UNIX2003 () #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ ThreadPThread.m3:668 #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ PTHREAD/ThreadPThread.m3:685 #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ src/vbt/VBTRep.m3:439 #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546 #7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ ThreadPThread.m3:522 #8 0x96373155 in _pthread_start () #9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b): #0 0x963422ce in semaphore_wait_signal_trap () #1 0x963742c6 in _pthread_cond_wait () #2 0x963b9539 in pthread_cond_wait () #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ src/trestle/Trestle.m3:884 #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ src/runtime/common/RTLinker.m3:399 #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:09:31 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:09:31 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <20090908074840.EB4811A2079@async.async.caltech.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <20090908074840.EB4811A2079@async.async.caltech.edu> Message-ID: Nice thing about pthreads is everyone uses them. Whatever tools they have, we can use. ..Jay > To: hosking at cs.purdue.edu; jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) > Date: Tue, 8 Sep 2009 00:48:40 -0700 > From: mika at async.async.caltech.edu > > > A nice thing about the user threads system is that it has a beautiful > deadlock detector... do you have anything like this in the pthreads > environment? > > Mika > > Tony Hosking writes: > > > >--Apple-Mail-13--794937978 > >Content-Type: text/plain; > > charset=US-ASCII; > > format=flowed; > > delsp=yes > >Content-Transfer-Encoding: 7bit > > > >Here's the hang backtrace for mentor. Again, all appears normal, > >except that all the threads are paused or waiting, which is > >suspicious. I'm stumped for now. > > > >Thread 21 (process 96727 thread 0x7403): > >#0 0x9634946e in __semwait_signal () > >#1 0x963492ef in nanosleep$UNIX2003 () > >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > >rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > >M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > >ThreadPThread.m3:668 > >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:685 > >#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > >src/xvbt/XClientF.m3:105 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 20 (process 96727 thread 0x7103): > >#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > >thread/PTHREAD/ThreadPThread.m3:319 > >#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > >M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../ > >src/thread/PTHREAD/ThreadPThread.m3:669 > >#2 0x01020024 in Thread__AlertPause > >(M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:699 > >#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > >M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > >src/Animate.m3:71 > >#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > >M3_BUucNs_duration=1) at ../src/MGV.m3:313 > >#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > >M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > >#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > >M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > >src/bresenham/ViewError.m3:548 > >#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > >M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > >#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > >src/Zeus.m3:331 > >#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#10 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#11 0x96373155 in _pthread_start () > >#12 0x96373012 in thread_start () > > > >Thread 19 (process 96727 thread 0x5d07): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > >M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > >M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > >M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > >src/Zeus.m3:328 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 18 (process 96727 thread 0x700b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > >M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > >M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > >M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > >src/Zeus.m3:328 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 17 (process 96727 thread 0x6e03): > >#0 0x963493dc in _pthread_testcancel () > >#1 0x96349275 in nanosleep$UNIX2003 () > >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > >rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > >M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > >ThreadPThread.m3:668 > >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:685 > >#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/ > >vtext/VTCaret.m3:149 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 16 (process 96727 thread 0x435b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > >M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > >M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > >at ../src/ZeusPanel.m3:1425 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 15 (process 96727 thread 0x420b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > >at ../src/View.m3:74 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 14 (process 96727 thread 0x4103): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > >at ../src/View.m3:74 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 13 (process 96727 thread 0x4003): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > >at ../src/View.m3:74 > >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#8 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#9 0x96373155 in _pthread_start () > >#10 0x96373012 in thread_start () > > > >Thread 12 (process 96727 thread 0x2e03): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > >M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > >M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > >at ../src/xvbt/XMessenger.m3:69 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 11 (process 96727 thread 0x2b07): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > >M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > >M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > >at ../src/xvbt/XInput.m3:102 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 10 (process 96727 thread 0x2a23): > >#0 0x963916fa in select$DARWIN_EXTSN () > >#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > >writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > >Common/UnixC.c:301 > >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > >(M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:787 > >#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > >M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > >M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > >PTHREAD/ThreadPThread.m3:826 > >#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, > >M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/ > >thread/PTHREAD/ThreadPThread.m3:729 > >#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > >at ../src/xvbt/XInput.m3:63 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 9 (process 96727 thread 0x29f3): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > >M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > >M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > >M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > >M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > >#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > >M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > >M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > >M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > >#7 0x000149a7 in BresenhamIE__ShowPixel > >(M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > >M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > >#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > >M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../ > >src/bresenham/AlgBresenham.m3:55 > >#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > >src/bresenham/AlgBresenham.m3:86 > >#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../ > >src/ZeusPanel.m3:1534 > >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#12 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#13 0x96373155 in _pthread_start () > >#14 0x96373012 in thread_start () > > > >Thread 8 (process 96727 thread 0x2803): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > >M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > >M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > >M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > >formatter/Formatter.m3:440 > >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > >M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > >M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > >formatter/Formatter.m3:708 > >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../ > >src/formatter/Formatter.m3:615 > >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#12 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#13 0x96373155 in _pthread_start () > >#14 0x96373012 in thread_start () > > > >Thread 7 (process 96727 thread 0x2703): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > >M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > >M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > >M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > >formatter/Formatter.m3:440 > >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > >M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > >M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > >M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > >formatter/Formatter.m3:708 > >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../ > >src/formatter/Formatter.m3:615 > >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#12 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#13 0x96373155 in _pthread_start () > >#14 0x96373012 in thread_start () > > > >Thread 6 (process 96727 thread 0x2603): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > >M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > >M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > >at ../src/WorkerPool.m3:152 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 5 (process 96727 thread 0x2313): > >#0 0x963916fa in select$DARWIN_EXTSN () > >#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > >writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/ > >unix/Common/UnixC.c:301 > >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > >(M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/ > >thread/PTHREAD/ThreadPThread.m3:787 > >#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > >M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > >M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > >#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= >type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > >src/thread/PTHREAD/ThreadPThread.m3:742 > >#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > >M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > >#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/ > >TCP.m3:234 > >#7 0x006dbc6b in LocalObjectSpace__SpaceAccept > >(M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > >#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#9 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#10 0x96373155 in _pthread_start () > >#11 0x96373012 in thread_start () > > > >Thread 4 (process 96727 thread 0x2003): > >#0 0x9634946e in __semwait_signal () > >#1 0x963492ef in nanosleep$UNIX2003 () > >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > >rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > >M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > >ThreadPThread.m3:668 > >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > >PTHREAD/ThreadPThread.m3:685 > >#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > >at ../src/lego/FileBrowserVBT.m3:259 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 3 (process 96727 thread 0x1f03): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > >M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > >M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) > >at ../src/vtext/VTView.m3:111 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 2 (process 96727 thread 0xd07): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > >M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > >M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > >src/vbt/VBTRep.m3:439 > >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >#7 0x0101ef74 in ThreadPThread__ThreadBase > >(M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > >ThreadPThread.m3:522 > >#8 0x96373155 in _pthread_start () > >#9 0x96373012 in thread_start () > > > >Thread 1 (process 96727 thread 0x10b): > >#0 0x963422ce in semaphore_wait_signal_trap () > >#1 0x963742c6 in _pthread_cond_wait () > >#2 0x963b9539 in pthread_cond_wait () > >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > >M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > >M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > >src/trestle/Trestle.m3:884 > >#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > >M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > >#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > >#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > >src/runtime/common/RTLinker.m3:399 > >#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > >_m3main.mc:6 > > > > > >Antony Hosking | Associate Professor | Computer Science | Purdue > >University > >305 N. University Street | West Lafayette | IN 47907 | USA > >Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > >On 6 Sep 2009, at 23:18, Jay K wrote: > > > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> [was truncated again!] > >> > >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > >> stack > > > > > >--Apple-Mail-13--794937978 > >Content-Type: text/html; > > charset=US-ASCII > >Content-Transfer-Encoding: quoted-printable > > > > >-webkit-line-break: after-white-space; ">Here's the hang backtrace for = > >mentor.  Again, all appears normal, except that all the threads are = > >paused or waiting, which is suspicious.  I'm stumped for = > >now.

Thread 21 (process 96727 thread = > >0x7403):
#0  0x9634946e in __semwait_signal = > >()
#1  0x963492ef in nanosleep$UNIX2003 ()
#2 = > > 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb15d4db0, = > >rem=3D0xb15d4db8) at = > >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  0x0101fd7c = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1f3f880, M3_CtKayy_n=3D1, = > >M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  0x0101fef3 = > >in Thread__Pause (M3_CtKayy_n=3D1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  0x00bc9cf4 = > >in XClientF__MeterMaid (M3_AS2y1X_cl=3D0x1f3f870) at = > >../src/xvbt/XClientF.m3:105
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c441d0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c441d0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 20 (process 96727 thread = > >0x7103):
#0  ThreadPThread__XTestAlert = > >(M3_BXP32l_self=3D0x1e5c134) at = > >../src/thread/PTHREAD/ThreadPThread.m3:319
#1  0x0101fd9b = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e5c134, = > >M3_CtKayy_n=3D0.0056863520294427872, M3_AicXUJ_alertable=3D1 '\001') at = > >../src/thread/PTHREAD/ThreadPThread.m3:669
#2  0x01020024 = > >in Thread__AlertPause (M3_CtKayy_n=3D0.0056863520294427872) at = > >../src/thread/PTHREAD/ThreadPThread.m3:699
#3  0x008f9ea1 = > >in Animate__Do (M3_CCfZY3_t=3D0x1e7e3fc, M3_DsL7Zz_mg=3D0x0, = > >M3_AdEaVQ_v=3D0x1e5e0f8, M3_BUucNs_duration=3D1) at = > >../src/Animate.m3:71
#4  0x00909610 in MGV__Animation = > >(M3_AdEaVQ_v=3D0x1e5e0f8, M3_BUucNs_duration=3D1) at = > >../src/MGV.m3:313
#5  0x008921f9 in = > >GraphVBT__AnimateGraph (M3_Cj00zi_graph=3D0x1e5e00c, M3_BUucNs_t0=3D0, = > >M3_BUucNs_t1=3D1) at ../src/GraphVBT.m3:656
#6 = > > 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=3D0x1ed3060, = > >M3_AcxOUs_x=3D3, M3_AcxOUs_y=3D2, M3_AcxOUs_p1=3D6, M3_AcxOUs_p2=3D-2) = > >at ../src/bresenham/ViewError.m3:548
#7  0x0001529a in = > >BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D0x1ed3060, = > >M3_Af40ku_evt=3D0x1e08014) at = > >../I386_DARWIN/BresenhamIE.m3:101
#8  0x007abb9b in = > >Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c128) at = > >../src/Zeus.m3:331
#9  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fd80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#10 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3fd80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#11 0x96373155 in = > >_pthread_start ()
#12 0x96373012 in thread_start = > >()

Thread 19 (process 96727 thread = > >0x5d07):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c0bc, = > >M3_AYIbX3_m=3D0x1e3f9bc, M3_Bl0jv4_c=3D0x1edf34c, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc, = > >M3_Bl0jv4_c=3D0x1edf34c) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x007ab7f2 = > >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc, = > >M3_B74vJ1_view=3D0x1edf25c) at ../src/Zeus.m3:361
#6 = > > 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c0b0) at = > >../src/Zeus.m3:328
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fc80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3fc80) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 18 (process 96727 thread = > >0x700b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c044, = > >M3_AYIbX3_m=3D0x1e3f9bc, M3_Bl0jv4_c=3D0x1ee3bac, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc, = > >M3_Bl0jv4_c=3D0x1ee3bac) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x007ab7f2 = > >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc, = > >M3_B74vJ1_view=3D0x1ee3b00) at ../src/Zeus.m3:361
#6 = > > 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c038) at = > >../src/Zeus.m3:328
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fa90) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3fa90) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 17 (process 96727 thread = > >0x6e03):
#0  0x963493dc in _pthread_testcancel = > >()
#1  0x96349275 in nanosleep$UNIX2003 ()
#2 = > > 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb134add0, = > >rem=3D0xb134add8) at = > >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  0x0101fd7c = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e54388, M3_CtKayy_n=3D0.5, = > >M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  0x0101fef3 = > >in Thread__Pause (M3_CtKayy_n=3D0.5) at = > >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  0x00a6f0c0 = > >in VTCaret__Blinker (M3_Axogco_arg=3D0x1e5437c) at = > >../src/vtext/VTCaret.m3:149
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3f9c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c3f9c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 16 (process 96727 thread = > >0x435b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1df30c8, = > >M3_AYIbX3_m=3D0x1e3bb94, M3_Bl0jv4_c=3D0x1e3bbb0, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3bb94, = > >M3_Bl0jv4_c=3D0x1e3bbb0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x007baaa1 = > >in ZeusPanel__PanelThread (M3_CvdnuP_pc=3D0x1df30b8) at = > >../src/ZeusPanel.m3:1425
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c39830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c39830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 15 (process 96727 thread = > >0x420b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d67e68, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1d22688, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1d22688) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ee3b00) at = > >../src/trestle/Trestle.m3:884
#6  0x007a98b1 in = > >View__WaiterThread (M3_C7vPGX_waiter=3D0x1d67e5c) at = > >../src/View.m3:74
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c305c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c305c0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 14 (process 96727 thread = > >0x4103):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ee32e4, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1edf3c4, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1edf3c4) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1edf25c) at = > >../src/trestle/Trestle.m3:884
#6  0x007a98b1 in = > >View__WaiterThread (M3_C7vPGX_waiter=3D0x1ee32d8) at = > >../src/View.m3:74
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38bf0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38bf0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 13 (process 96727 thread = > >0x4003):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1edb2e4, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1ed532c, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1ed532c) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ed3060) at = > >../src/trestle/Trestle.m3:884
#6  0x007a98b1 in = > >View__WaiterThread (M3_C7vPGX_waiter=3D0x1edb2d8) at = > >../src/View.m3:74
#7  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38780) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38780) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  0x96373155 = > >in _pthread_start ()
#10 0x96373012 in thread_start = > >()

Thread 12 (process 96727 thread = > >0x2e03):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed52a4, = > >M3_AYIbX3_m=3D0x1ed327c, M3_Bl0jv4_c=3D0x1ed35f4, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c, = > >M3_Bl0jv4_c=3D0x1ed35f4) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00bb7962 = > >in XMessenger__Messenger (M3_EVlqQO_self=3D0x1ed5294) at = > >../src/xvbt/XMessenger.m3:69
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38420) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38420) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 11 (process 96727 thread = > >0x2b07):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed5254, = > >M3_AYIbX3_m=3D0x1ed327c, M3_Bl0jv4_c=3D0x1ed3614, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c, = > >M3_Bl0jv4_c=3D0x1ed3614) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00bbdbc2 = > >in XInput__FilterXInput (M3_DSd60P_self=3D0x1ed5244) at = > >../src/xvbt/XInput.m3:102
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38320) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38320) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 10 (process 96727 thread = > >0x2a23):
#0  0x963916fa in select$DARWIN_EXTSN = > >()
#1  0x01023503 in Unix__select (nfds=3D7, = > >readfds=3D0x2813d54, writefds=3D0x2813d64, exceptfds=3D0x2813d74, = > >timeout=3D0x0) at ../src/unix/Common/UnixC.c:301
#2 = > > 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 = > >(M3_Cwb5VA_nfd=3D<unknown type>, M3_A4bqCj_timeout=3D0x0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:787
#3  0x010206cc = > >in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1ed5204, = > >M3_Cwb5VA_fd=3D<unknown type>, M3_AicXUJ_read=3D1 '\001', = > >M3_CtKayy_interval=3D-1, M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:826
#4  0x010201b4 = > >in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3D<unknown type>, = > >M3_AicXUJ_read=3D1 '\001', M3_CtKayy_timeoutInterval=3D-1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:729
#5  0x00bbf20b = > >in XInput__WaitForXInput (M3_Bkyxhg_self=3D0x1ed51f4) at = > >../src/xvbt/XInput.m3:63
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38250) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c38250) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 9 (process 96727 thread = > >0x29f3):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e3fafc, = > >M3_AYIbX3_m=3D0x1e3f9bc, M3_Bl0jv4_c=3D0x1e3f9c8, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3f9bc, = > >M3_Bl0jv4_c=3D0x1e3f9c8) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x007ab312 = > >in Zeus__AlgToViews (M3_CQpoHd_zeus=3D0x1e3ccfc, = > >M3_Ao6Rbg_initiator=3D0x1ecd9cc, M3_BMhQCx_dispatchProc=3D0x150e0, = > >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:306
#6 = > > 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D0x1ecd9cc, = > >M3_DsvzJ6_style=3D0 '\0', M3_AcxOUs_priority=3D1, = > >M3_Bd56fi_eventName=3D0x1d9d60, M3_BMhQCx_dispatchProc=3D0x150e0, = > >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:246
#7 = > > 0x000149a7 in BresenhamIE__ShowPixel = > >(M3_CfiRBL_initiator=3D0x1ecd9cc, M3_AcxOUs_x=3D3, M3_AcxOUs_y=3D2, = > >M3_AcxOUs_p1=3D6, M3_AcxOUs_p2=3D-2) at = > >../I386_DARWIN/BresenhamIE.m3:227
#8  0x000175b7 in = > >AlgBresenham__DrawLine (M3_ECecEc_alg=3D0x1ecd9cc, M3_AcxOUs_x1=3D0, = > >M3_AcxOUs_y1=3D0, M3_AcxOUs_x2=3D10, M3_AcxOUs_y2=3D6) at = > >../src/bresenham/AlgBresenham.m3:55
#9  0x0001788f in = > >AlgBresenham__Run (M3_ECecEc_alg=3D0x1ecd9cc) at = > >../src/bresenham/AlgBresenham.m3:86
#10 0x007bb729 in = > >ZeusPanel__AlgThread (M3_Dijbki_ac=3D0x1e3fae8) at = > >../src/ZeusPanel.m3:1534
#11 0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29fd0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c29fd0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >_pthread_start ()
#14 0x96373012 in thread_start = > >()

Thread 8 (process 96727 thread = > >0x2803):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d8e01c, = > >M3_AYIbX3_m=3D0x1d71fdc, M3_Bl0jv4_c=3D0x1d71fe8, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d71fdc, = > >M3_Bl0jv4_c=3D0x1d71fe8) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x00e3bdf2 = > >in Formatter__Allocate (M3_ACp9GL_t=3D0x1d71680, M3_DBiloZ_this=3D1 = > >'\001', M3_Cwb5VA_minSize=3D<unknown type>) at = > >../src/formatter/Formatter.m3:440
#6  0x00e3bf0a in = > >Formatter__Probe (M3_ACp9GL_t=3D0x1d71680, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:542
#7 = > > 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d71680, = > >M3_Cwb5VA_i=3D<unknown type>) at = > >../src/formatter/Formatter.m3:592
#8  0x00e3c2ff in = > >Formatter__PeekOp (M3_ACp9GL_t=3D0x1d71680, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:577
#9 = > > 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d71680, = > >M3_DOUxXw_mode=3D1 '\001', M3_ElBLGV_pos=3D0xb038ce90, = > >M3_Cwb5VA_maxL=3D<unknown type>, M3_CCuODf_op=3D0x1d72c08) at = > >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in = > >Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d8e00c) at = > >../src/formatter/Formatter.m3:615
#11 0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29140) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c29140) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >_pthread_start ()
#14 0x96373012 in thread_start = > >()

Thread 7 (process 96727 thread = > >0x2703):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d71618, = > >M3_AYIbX3_m=3D0x1d715ec, M3_Bl0jv4_c=3D0x1d715f8, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d715ec, = > >M3_Bl0jv4_c=3D0x1d715f8) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x00e3bdf2 = > >in Formatter__Allocate (M3_ACp9GL_t=3D0x1d70c90, M3_DBiloZ_this=3D1 = > >'\001', M3_Cwb5VA_minSize=3D<unknown type>) at = > >../src/formatter/Formatter.m3:440
#6  0x00e3bf0a in = > >Formatter__Probe (M3_ACp9GL_t=3D0x1d70c90, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:542
#7 = > > 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d70c90, = > >M3_Cwb5VA_i=3D<unknown type>) at = > >../src/formatter/Formatter.m3:592
#8  0x00e3c2ff in = > >Formatter__PeekOp (M3_ACp9GL_t=3D0x1d70c90, M3_Cwb5VA_i=3D<unknown = > >type>) at ../src/formatter/Formatter.m3:577
#9 = > > 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d70c90, = > >M3_DOUxXw_mode=3D1 '\001', M3_ElBLGV_pos=3D0xb030ae90, = > >M3_Cwb5VA_maxL=3D<unknown type>, M3_CCuODf_op=3D0x1d72c08) at = > >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in = > >Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d71608) at = > >../src/formatter/Formatter.m3:615
#11 0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c221e0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c221e0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >_pthread_start ()
#14 0x96373012 in thread_start = > >()

Thread 6 (process 96727 thread = > >0x2603):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d729bc, = > >M3_AYIbX3_m=3D0x1d728b4, M3_Bl0jv4_c=3D0x1d729a0, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d728b4, = > >M3_Bl0jv4_c=3D0x1d729a0) at = > >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  0x0073de32 = > >in WorkerPool__ClericApply (M3_BSwVRC_self=3D0x1d729b0) at = > >../src/WorkerPool.m3:152
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28e10) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c28e10) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 5 (process 96727 thread = > >0x2313):
#0  0x963916fa in select$DARWIN_EXTSN = > >()
#1  0x01023503 in Unix__select (nfds=3D4, = > >readfds=3D0x1d74014, writefds=3D0x1d74024, exceptfds=3D0x1d74034, = > >timeout=3D0xb0206b20) at ../src/unix/Common/UnixC.c:301
#2 = > > 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 = > >(M3_Cwb5VA_nfd=3D<unknown type>, M3_A4bqCj_timeout=3D0xb0206b20) = > >at ../src/thread/PTHREAD/ThreadPThread.m3:787
#3 = > > 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1d585bc, = > >M3_Cwb5VA_fd=3D<unknown type>, M3_AicXUJ_read=3D1 '\001', = > >M3_CtKayy_interval=3D1.7976931348623157e+308, M3_AicXUJ_alertable=3D1 = > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823
#4 = > > 0x010202e7 in SchedulerPosix__IOAlertWait = > >(M3_Cwb5VA_fd=3D<unknown type>, M3_AicXUJ_read=3D1 '\001', = > >M3_CtKayy_timeoutInterval=3D-1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:742
#5  0x00dd3cc2 = > >in TCPMisc__Accept=46rom (M3_AahksS_c=3D0x1d58594, = > >M3_DoBjMZ_peer=3D0xb0206cb4) at ../src/POSIX/TCP.m3:458
#6 = > > 0x00dd3da8 in TCP__Accept (M3_AahksS_c=3D0x1d58594) at = > >../src/POSIX/TCP.m3:234
#7  0x006dbc6b in = > >LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=3D0x1d585b0) at = > >../src/LocalObjectSpace.m3:307
#8  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28d60) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#9  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c28d60) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#10 0x96373155 in = > >_pthread_start ()
#11 0x96373012 in thread_start = > >()

Thread 4 (process 96727 thread = > >0x2003):
#0  0x9634946e in __semwait_signal = > >()
#1  0x963492ef in nanosleep$UNIX2003 ()
#2 = > > 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb0184dd0, = > >rem=3D0xb0184dd8) at = > >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  0x0101fd7c = > >in ThreadPThread__XPause (M3_BXP32l_self=3D0x1d0ba08, M3_CtKayy_n=3D1, = > >M3_AicXUJ_alertable=3D0 '\0') at = > >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  0x0101fef3 = > >in Thread__Pause (M3_CtKayy_n=3D1) at = > >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  0x00a11d53 = > >in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D0x1d0ba00) at = > >../src/lego/FileBrowserVBT.m3:259
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c21830) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 3 (process 96727 thread = > >0x1f03):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d090d4, = > >M3_AYIbX3_m=3D0x1d090b0, M3_Bl0jv4_c=3D0x1d090bc, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d090b0, = > >M3_Bl0jv4_c=3D0x1d090bc) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00a839e2 = > >in VTView__VFontCleanUpThread (M3_EMTrVz_cl=3D0x1d090cc) at = > >../src/vtext/VTView.m3:111
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21310) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c21310) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 2 (process 96727 thread = > >0xd07):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d006c8, = > >M3_AYIbX3_m=3D0x1d00688, M3_Bl0jv4_c=3D0x1d00694, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00688, = > >M3_Bl0jv4_c=3D0x1d00694) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00bf33d2 = > >in VBTRep__MeterMaid (M3_EMTrVz_self=3D0x1d006bc) at = > >../src/vbt/VBTRep.m3:439
#6  0x0101f243 in = > >ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21390) at = > >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  0x0101ef74 = > >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D0x1c21390) at = > >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  0x96373155 = > >in _pthread_start ()
#9  0x96373012 in thread_start = > >()

Thread 1 (process 96727 thread = > >0x10b):
#0  0x963422ce in semaphore_wait_signal_trap = > >()
#1  0x963742c6 in _pthread_cond_wait ()
#2 = > > 0x963b9539 in pthread_cond_wait ()
#3  0x0101d189 = > >in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d0000c, = > >M3_AYIbX3_m=3D0x1d00500, M3_Bl0jv4_c=3D0x1df3114, M3_AicXUJ_alertable=3D0 = > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 = > > 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500, = > >M3_Bl0jv4_c=3D0x1df3114) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  0x00c40602 = > >in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1e3a204) at = > >../src/trestle/Trestle.m3:884
#6  0x007c09eb in = > >ZeusPanel__Interact (M3_Bd56fi_title=3D0x290db0, = > >M3_DYb95R_path=3D0x1d498c0) at ../src/ZeusPanel.m3:477
#7 = > > 0x001b0ede in Main_M3 (M3_AcxOUs_mode=3D1) at = > >../src/Main.m3:165
#8  0x0100eb1f in = > >RTLinker__RunMainBody (M3_DjPxE3_m=3D0x1d6060) at = > >../src/runtime/common/RTLinker.m3:399
#9  0x00002578 in = > >main (argc=3D1, argv=3D0xbfffedb8, envp=3D0xbfffedc0) at = > >_m3main.mc:6


>class=3D"Apple-style-span" style=3D"font-size: 12px; ">
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = > >-webkit-line-break: after-white-space; "> >style=3D"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; ">
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = > >-webkit-line-break: after-white-space; "> >style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; "> >class=3D"Apple-style-span" style=3D"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; ">
>class=3D"Apple-style-span" color=3D"#0000FF"> >class=3D"Apple-style-span" face=3D"Gill Sans"> >class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = > >'Gill Sans'; "> >0, 255); font-family: 'Gill Sans'; ">Antony = > >Hosking >face=3D"Gill Sans"> >'Gill Sans'; "> >'Gill Sans'; "> | >class=3D"Apple-converted-space">  >class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; "> >class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; = > >">Associate Professor >style=3D"font-family: 'Gill Sans'; "> >style=3D"font-family: 'Gill Sans'; "> | Computer Science | Purdue = > >University
> face=3D"GillSans-Light"> >style=3D"font-family: GillSans-Light; ">305 N. University Street | West = > >Lafayette | IN 47907 | USA
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"> >class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = > >'Gill Sans'; "> >0, 255); font-family: 'Gill Sans'; ">Office >class=3D"Apple-style-span" face=3D"GillSans-Light"> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; = > >"> +1 765 494 6001 | >class=3D"Apple-converted-space">  >class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"> >class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: = > >'Gill Sans'; "> >0, 255); font-family: 'Gill Sans'; ">Mobile >class=3D"Apple-style-span" face=3D"GillSans-Light"> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "> >class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "> >class=3D"Apple-converted-space"> +1 765 427 = > >5484
>face=3D"GillSans-Light">
>class=3D"khtml-block-placeholder">
>>

>class=3D"Apple-interchange-newline">

>class=3D"Apple-interchange-newline">

On 6 Sep 2009, = > >at 23:18, Jay K wrote:

>class=3D"Apple-interchange-newline">
>type=3D"cite">









[was truncated = > >again!]

PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes = > >runs out of stack

= > > > >--Apple-Mail-13--794937978-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:16:41 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:16:41 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:50:08 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:50:08 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 10:53:34 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 08:53:34 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Wow. I've seen it hang for up to 30 seconds, but if I am patient, I can run it many times in a row with no infinite hang. This is with the stack size code removed. Now to try without it, and if it always proceeds after a possibly long wait, well..that's still pretty bad, but... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:50:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 11:00:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 09:00:07 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Hm..setting the stack 1meg never seems to hang now. I'll dig a bit more and try mentor too. Another thing different about Darwin, I should have pointed out, I think, it doesn't optimize by default like the others, meaning it will use more stack than the others. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:53:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Wow. I've seen it hang for up to 30 seconds, but if I am patient, I can run it many times in a row with no infinite hang. This is with the stack size code removed. Now to try without it, and if it always proceeds after a possibly long wait, well..that's still pretty bad, but... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:50:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 11:15:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 09:15:20 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Hm. I take that back. 1meg I might have been running Linux Juno in a nearby terminal. Without the stack code Juno does still often hang. I have seen it also pause a few seconds with one word in the status, then quite a while later advance to another, and then sit there. Usually after a minute I declare failure. But I have seen it progress after counting to 30. Arg this stinks.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 09:00:07 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm..setting the stack 1meg never seems to hang now. I'll dig a bit more and try mentor too. Another thing different about Darwin, I should have pointed out, I think, it doesn't optimize by default like the others, meaning it will use more stack than the others. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:53:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Wow. I've seen it hang for up to 30 seconds, but if I am patient, I can run it many times in a row with no infinite hang. This is with the stack size code removed. Now to try without it, and if it always proceeds after a possibly long wait, well..that's still pretty bad, but... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 08:50:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Hm. - Making SameHost FALSE on Linux didn't induce hang. - I'm seeing Juno often "hang" for a few seconds without displaying anything, but I wait, and then it comes up fine. And then the next run works ok. I see both behaviors often. This is with the stack size code removed from ThreadPThreadC.c. I'll try restoring it too. What is different about Darwin? Well obviously the same world suspend works. Can we use the portable way instead?? I realize the portable way probably isn't as good? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 12:07:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 10:07:16 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: > What is different about Darwin? > Well obviously the same world suspend works. Can we use the portable way instead?? sem_init returns ENOSYS on Darwin, so no. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 13:18:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 11:18:59 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <20090908082345.B34371A2079@async.async.caltech.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <20090908074840.EB4811A2079@async.async.caltech.edu> <20090908082345.B34371A2079@async.async.caltech.edu> Message-ID: Thanks. Well, userthreads on I386_DARWIN don't seem to work presently. == package /Users/jay/dev2/cm3/m3-sys/cm3ide == +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in I386_DARWIN --- ignoring ../src/m3overrides /cm3/bin/m3bundle -name CM3_IDE_Bundle -F/var/folders/QG/QGSTvYqCGfSGxXo0rUMOX++++TI/-Tmp-/qk *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x464b7 = PushEFrame + 0x63 in ../src/thread/POSIX/ThreadPosix.m3 *** Maybe I'll look into that.. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; hosking at cs.purdue.edu > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) > Date: Tue, 8 Sep 2009 01:23:45 -0700 > From: mika at async.async.caltech.edu > > I really meant it as a debugging hint: > > if you deadlock the user threads you get an instant core dump, also lots > of diagnostics to stderr, which will tell you which LOCK or Thread.Acquire > is creating the dependency cycle. > > If you're debugging deadlocks, that's one way to look for them. > That being said I've never seen mentor or Juno hang on FreeBSD4... > > I haven't used the pthreads much (a bit, when porting to Linux and OS > X as well as when testing the new stuff on FreeBSD). Is it possible to > get deadlock detection with them? As I recall, it's not automatic the > way it is with the user threads. > > Mika > > Jay K writes: > >--_d2a2b05c-dd99-4149-b3de-8867976ffb79_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Nice thing about pthreads is everyone uses them. > >Whatever tools they have=2C we can use. > > > > ..Jay > > > >> To: hosking at cs.purdue.edu=3B jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other proble= > >ms)=20 > >> Date: Tue=2C 8 Sep 2009 00:48:40 -0700 > >> From: mika at async.async.caltech.edu > >>=20 > >>=20 > >> A nice thing about the user threads system is that it has a beautiful > >> deadlock detector... do you have anything like this in the pthreads > >> environment? > >>=20 > >> Mika > >>=20 > >> Tony Hosking writes: > >> > > >> >--Apple-Mail-13--794937978 > >> >Content-Type: text/plain=3B > >> > charset=3DUS-ASCII=3B > >> > format=3Dflowed=3B > >> > delsp=3Dyes > >> >Content-Transfer-Encoding: 7bit > >> > > >> >Here's the hang backtrace for mentor. Again=2C all appears normal=2C =20 > >> >except that all the threads are paused or waiting=2C which is =20 > >> >suspicious. I'm stumped for now. > >> > > >> >Thread 21 (process 96727 thread 0x7403): > >> >#0 0x9634946e in __semwait_signal () > >> >#1 0x963492ef in nanosleep$UNIX2003 () > >> >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb15d4db0=2C =20 > >> >rem=3D0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >> >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=3D0x1f3f880=2C = > >=20 > >> >M3_CtKayy_n=3D1=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHREA= > >D/=20 > >> >ThreadPThread.m3:668 > >> >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ../src/thread/=20 > >> >PTHREAD/ThreadPThread.m3:685 > >> >#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=3D0x1f3f870) at ../= > >=20 > >> >src/xvbt/XClientF.m3:105 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c441d0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c441d0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 20 (process 96727 thread 0x7103): > >> >#0 ThreadPThread__XTestAlert (M3_BXP32l_self=3D0x1e5c134) at ../src/=20 > >> >thread/PTHREAD/ThreadPThread.m3:319 > >> >#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e5c134=2C = > >=20 > >> >M3_CtKayy_n=3D0.0056863520294427872=2C M3_AicXUJ_alertable=3D1 '\001') a= > >t ../=20 > >> >src/thread/PTHREAD/ThreadPThread.m3:669 > >> >#2 0x01020024 in Thread__AlertPause =20 > >> >(M3_CtKayy_n=3D0.0056863520294427872) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:699 > >> >#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=3D0x1e7e3fc=2C =20 > >> >M3_DsL7Zz_mg=3D0x0=2C M3_AdEaVQ_v=3D0x1e5e0f8=2C M3_BUucNs_duration=3D1)= > > at ../=20 > >> >src/Animate.m3:71 > >> >#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=3D0x1e5e0f8=2C =20 > >> >M3_BUucNs_duration=3D1) at ../src/MGV.m3:313 > >> >#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=3D0x1e5e00c=2C= > > =20 > >> >M3_BUucNs_t0=3D0=2C M3_BUucNs_t1=3D1) at ../src/GraphVBT.m3:656 > >> >#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=3D0x1ed3060=2C =20 > >> >M3_AcxOUs_x=3D3=2C M3_AcxOUs_y=3D2=2C M3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2= > >=3D-2) at ../=20 > >> >src/bresenham/ViewError.m3:548 > >> >#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D0x1ed3060=2C = > >=20 > >> >M3_Af40ku_evt=3D0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > >> >#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c128) at ../=20 > >> >src/Zeus.m3:331 > >> >#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fd80) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#10 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3fd80) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#11 0x96373155 in _pthread_start () > >> >#12 0x96373012 in thread_start () > >> > > >> >Thread 19 (process 96727 thread 0x5d07): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c0bc=2C =20 > >> >M3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1edf34c=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc=2C =20 > >> >M3_Bl0jv4_c=3D0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc=2C = > >=20 > >> >M3_B74vJ1_view=3D0x1edf25c) at ../src/Zeus.m3:361 > >> >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c0b0) at ../=20 > >> >src/Zeus.m3:328 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fc80) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3fc80) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 18 (process 96727 thread 0x700b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c044=2C =20 > >> >M3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1ee3bac=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc=2C =20 > >> >M3_Bl0jv4_c=3D0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc=2C = > >=20 > >> >M3_B74vJ1_view=3D0x1ee3b00) at ../src/Zeus.m3:361 > >> >#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c038) at ../=20 > >> >src/Zeus.m3:328 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fa90) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3fa90) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 17 (process 96727 thread 0x6e03): > >> >#0 0x963493dc in _pthread_testcancel () > >> >#1 0x96349275 in nanosleep$UNIX2003 () > >> >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb134add0=2C =20 > >> >rem=3D0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >> >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=3D0x1e54388=2C = > >=20 > >> >M3_CtKayy_n=3D0.5=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHR= > >EAD/=20 > >> >ThreadPThread.m3:668 > >> >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D0.5) at ../src/thread/=20 > >> >PTHREAD/ThreadPThread.m3:685 > >> >#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=3D0x1e5437c) at ../src= > >/=20 > >> >vtext/VTCaret.m3:149 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3f9c0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c3f9c0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 16 (process 96727 thread 0x435b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1df30c8=2C =20 > >> >M3_AYIbX3_m=3D0x1e3bb94=2C M3_Bl0jv4_c=3D0x1e3bbb0=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3bb94=2C =20 > >> >M3_Bl0jv4_c=3D0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=3D0x1df30b8) =20 > >> >at ../src/ZeusPanel.m3:1425 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c39830) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c39830) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 15 (process 96727 thread 0x420b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d67e68=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1d22688=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ee3b00) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=3D0x1d67e5c) =20 > >> >at ../src/View.m3:74 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c305c0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c305c0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 14 (process 96727 thread 0x4103): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ee32e4=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1edf3c4=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1edf25c) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=3D0x1ee32d8) =20 > >> >at ../src/View.m3:74 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38bf0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38bf0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 13 (process 96727 thread 0x4003): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1edb2e4=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1ed532c=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ed3060) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=3D0x1edb2d8) =20 > >> >at ../src/View.m3:74 > >> >#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38780) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#8 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38780) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#9 0x96373155 in _pthread_start () > >> >#10 0x96373012 in thread_start () > >> > > >> >Thread 12 (process 96727 thread 0x2e03): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed52a4=2C =20 > >> >M3_AYIbX3_m=3D0x1ed327c=2C M3_Bl0jv4_c=3D0x1ed35f4=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c=2C =20 > >> >M3_Bl0jv4_c=3D0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=3D0x1ed5294) =20 > >> >at ../src/xvbt/XMessenger.m3:69 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38420) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38420) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 11 (process 96727 thread 0x2b07): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1ed5254=2C =20 > >> >M3_AYIbX3_m=3D0x1ed327c=2C M3_Bl0jv4_c=3D0x1ed3614=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c=2C =20 > >> >M3_Bl0jv4_c=3D0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=3D0x1ed5244) =20 > >> >at ../src/xvbt/XInput.m3:102 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38320) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38320) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 10 (process 96727 thread 0x2a23): > >> >#0 0x963916fa in select$DARWIN_EXTSN () > >> >#1 0x01023503 in Unix__select (nfds=3D7=2C readfds=3D0x2813d54=2C =20 > >> >writefds=3D0x2813d64=2C exceptfds=3D0x2813d74=2C timeout=3D0x0) at ../sr= > >c/unix/=20 > >> >Common/UnixC.c:301 > >> >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =20 > >> >(M3_Cwb5VA_nfd=3D=2C M3_A4bqCj_timeout=3D0x0) at ../src/th= > >read/=20 > >> >PTHREAD/ThreadPThread.m3:787 > >> >#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1ed5204=2C = > >=20 > >> >M3_Cwb5VA_fd=3D=2C M3_AicXUJ_read=3D1 '\001'=2C =20 > >> >M3_CtKayy_interval=3D-1=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/threa= > >d/=20 > >> >PTHREAD/ThreadPThread.m3:826 > >> >#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3D= > >=2C =20 > >> >M3_AicXUJ_read=3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D-1) at ../src/= > >=20 > >> >thread/PTHREAD/ThreadPThread.m3:729 > >> >#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=3D0x1ed51f4) =20 > >> >at ../src/xvbt/XInput.m3:63 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38250) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c38250) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 9 (process 96727 thread 0x29f3): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e3fafc=2C =20 > >> >M3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1e3f9c8=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1e3f9bc=2C =20 > >> >M3_Bl0jv4_c=3D0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=3D0x1e3ccfc=2C =20 > >> >M3_Ao6Rbg_initiator=3D0x1ecd9cc=2C M3_BMhQCx_dispatchProc=3D0x150e0=2C = > >=20 > >> >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:306 > >> >#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D0x1ecd9cc=2C =20 > >> >M3_DsvzJ6_style=3D0 '\0'=2C M3_AcxOUs_priority=3D1=2C =20 > >> >M3_Bd56fi_eventName=3D0x1d9d60=2C M3_BMhQCx_dispatchProc=3D0x150e0=2C =20 > >> >M3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:246 > >> >#7 0x000149a7 in BresenhamIE__ShowPixel =20 > >> >(M3_CfiRBL_initiator=3D0x1ecd9cc=2C M3_AcxOUs_x=3D3=2C M3_AcxOUs_y=3D2= > >=2C =20 > >> >M3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2=3D-2) at ../I386_DARWIN/BresenhamIE.m3:= > >227 > >> >#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=3D0x1ecd9cc=2C = > >=20 > >> >M3_AcxOUs_x1=3D0=2C M3_AcxOUs_y1=3D0=2C M3_AcxOUs_x2=3D10=2C M3_AcxOUs_y= > >2=3D6) at ../=20 > >> >src/bresenham/AlgBresenham.m3:55 > >> >#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=3D0x1ecd9cc) at ../=20 > >> >src/bresenham/AlgBresenham.m3:86 > >> >#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=3D0x1e3fae8) at ../= > >=20 > >> >src/ZeusPanel.m3:1534 > >> >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29fd0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#12 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c29fd0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#13 0x96373155 in _pthread_start () > >> >#14 0x96373012 in thread_start () > >> > > >> >Thread 8 (process 96727 thread 0x2803): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d8e01c=2C =20 > >> >M3_AYIbX3_m=3D0x1d71fdc=2C M3_Bl0jv4_c=3D0x1d71fe8=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d71fdc=2C =20 > >> >M3_Bl0jv4_c=3D0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_DBiloZ_this=3D1 '\001'=2C M3_Cwb5VA_minSize=3D) at ../s= > >rc/=20 > >> >formatter/Formatter.m3:440 > >> >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:542 > >> >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:592 > >> >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:577 > >> >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d71680=2C =20 > >> >M3_DOUxXw_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb038ce90=2C =20 > >> >M3_Cwb5VA_maxL=3D=2C M3_CCuODf_op=3D0x1d72c08) at ../src/= > >=20 > >> >formatter/Formatter.m3:708 > >> >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d8e00c) at ..= > >/=20 > >> >src/formatter/Formatter.m3:615 > >> >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29140) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#12 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c29140) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#13 0x96373155 in _pthread_start () > >> >#14 0x96373012 in thread_start () > >> > > >> >Thread 7 (process 96727 thread 0x2703): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d71618=2C =20 > >> >M3_AYIbX3_m=3D0x1d715ec=2C M3_Bl0jv4_c=3D0x1d715f8=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d715ec=2C =20 > >> >M3_Bl0jv4_c=3D0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_DBiloZ_this=3D1 '\001'=2C M3_Cwb5VA_minSize=3D) at ../s= > >rc/=20 > >> >formatter/Formatter.m3:440 > >> >#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:542 > >> >#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:592 > >> >#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_Cwb5VA_i=3D) at ../src/formatter/Formatter.m3:577 > >> >#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d70c90=2C =20 > >> >M3_DOUxXw_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb030ae90=2C =20 > >> >M3_Cwb5VA_maxL=3D=2C M3_CCuODf_op=3D0x1d72c08) at ../src/= > >=20 > >> >formatter/Formatter.m3:708 > >> >#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d71608) at ..= > >/=20 > >> >src/formatter/Formatter.m3:615 > >> >#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c221e0) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#12 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c221e0) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#13 0x96373155 in _pthread_start () > >> >#14 0x96373012 in thread_start () > >> > > >> >Thread 6 (process 96727 thread 0x2603): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d729bc=2C =20 > >> >M3_AYIbX3_m=3D0x1d728b4=2C M3_Bl0jv4_c=3D0x1d729a0=2C M3_AicXUJ_alertabl= > >e=3D1 =20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d728b4=2C =20 > >> >M3_Bl0jv4_c=3D0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > >> >#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=3D0x1d729b0) = > >=20 > >> >at ../src/WorkerPool.m3:152 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28e10) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c28e10) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 5 (process 96727 thread 0x2313): > >> >#0 0x963916fa in select$DARWIN_EXTSN () > >> >#1 0x01023503 in Unix__select (nfds=3D4=2C readfds=3D0x1d74014=2C =20 > >> >writefds=3D0x1d74024=2C exceptfds=3D0x1d74034=2C timeout=3D0xb0206b20) a= > >t ../src/=20 > >> >unix/Common/UnixC.c:301 > >> >#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =20 > >> >(M3_Cwb5VA_nfd=3D=2C M3_A4bqCj_timeout=3D0xb0206b20) at ..= > >/src/=20 > >> >thread/PTHREAD/ThreadPThread.m3:787 > >> >#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1d585bc=2C = > >=20 > >> >M3_Cwb5VA_fd=3D=2C M3_AicXUJ_read=3D1 '\001'=2C =20 > >> >M3_CtKayy_interval=3D1.7976931348623157e+308=2C M3_AicXUJ_alertable=3D1 = > >=20 > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > >> >#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3D >=20 > >> >type>=2C M3_AicXUJ_read=3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D-1) at= > > ../=20 > >> >src/thread/PTHREAD/ThreadPThread.m3:742 > >> >#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=3D0x1d58594=2C =20 > >> >M3_DoBjMZ_peer=3D0xb0206cb4) at ../src/POSIX/TCP.m3:458 > >> >#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=3D0x1d58594) at ../src/POSIX/= > >=20 > >> >TCP.m3:234 > >> >#7 0x006dbc6b in LocalObjectSpace__SpaceAccept =20 > >> >(M3_Dbz8GV_self=3D0x1d585b0) at ../src/LocalObjectSpace.m3:307 > >> >#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28d60) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#9 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c28d60) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#10 0x96373155 in _pthread_start () > >> >#11 0x96373012 in thread_start () > >> > > >> >Thread 4 (process 96727 thread 0x2003): > >> >#0 0x9634946e in __semwait_signal () > >> >#1 0x963492ef in nanosleep$UNIX2003 () > >> >#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb0184dd0=2C =20 > >> >rem=3D0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > >> >#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=3D0x1d0ba08=2C = > >=20 > >> >M3_CtKayy_n=3D1=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHREA= > >D/=20 > >> >ThreadPThread.m3:668 > >> >#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ../src/thread/=20 > >> >PTHREAD/ThreadPThread.m3:685 > >> >#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D0x1d0ba00) =20 > >> >at ../src/lego/FileBrowserVBT.m3:259 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21830) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c21830) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 3 (process 96727 thread 0x1f03): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d090d4=2C =20 > >> >M3_AYIbX3_m=3D0x1d090b0=2C M3_Bl0jv4_c=3D0x1d090bc=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d090b0=2C =20 > >> >M3_Bl0jv4_c=3D0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=3D0x1d090cc) = > >=20 > >> >at ../src/vtext/VTView.m3:111 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21310) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c21310) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 2 (process 96727 thread 0xd07): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d006c8=2C =20 > >> >M3_AYIbX3_m=3D0x1d00688=2C M3_Bl0jv4_c=3D0x1d00694=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00688=2C =20 > >> >M3_Bl0jv4_c=3D0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=3D0x1d006bc) at ../= > >=20 > >> >src/vbt/VBTRep.m3:439 > >> >#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21390) =20 > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:546 > >> >#7 0x0101ef74 in ThreadPThread__ThreadBase =20 > >> >(M3_AJWxb1_param=3D0x1c21390) at ../src/thread/PTHREAD/=20 > >> >ThreadPThread.m3:522 > >> >#8 0x96373155 in _pthread_start () > >> >#9 0x96373012 in thread_start () > >> > > >> >Thread 1 (process 96727 thread 0x10b): > >> >#0 0x963422ce in semaphore_wait_signal_trap () > >> >#1 0x963742c6 in _pthread_cond_wait () > >> >#2 0x963b9539 in pthread_cond_wait () > >> >#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d0000c=2C =20 > >> >M3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c=3D0x1df3114=2C M3_AicXUJ_alertabl= > >e=3D0 =20 > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > >> >#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C =20 > >> >M3_Bl0jv4_c=3D0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > >> >#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1e3a204) at ../= > >=20 > >> >src/trestle/Trestle.m3:884 > >> >#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=3D0x290db0=2C =20 > >> >M3_DYb95R_path=3D0x1d498c0) at ../src/ZeusPanel.m3:477 > >> >#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=3D1) at ../src/Main.m3:165 > >> >#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=3D0x1d6060) at ../= > >=20 > >> >src/runtime/common/RTLinker.m3:399 > >> >#9 0x00002578 in main (argc=3D1=2C argv=3D0xbfffedb8=2C envp=3D0xbfffed= > >c0) at =20 > >> >_m3main.mc:6 > >> > > >> > > >> >Antony Hosking | Associate Professor | Computer Science | Purdue =20 > >> >University > >> >305 N. University Street | West Lafayette | IN 47907 | USA > >> >Office +1 765 494 6001 | Mobile +1 765 427 5484 > >> > > >> > > >> > > >> > > >> >On 6 Sep 2009=2C at 23:18=2C Jay K wrote: > >> > > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> [was truncated again!] > >> >> > >> >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes runs out of = > >=20 > >> >> stack > >> > > >> > > >> >--Apple-Mail-13--794937978 > >> >Content-Type: text/html=3B > >> > charset=3DUS-ASCII > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > >=3B =3D > >> >-webkit-line-break: after-white-space=3B ">Here's the hang backtrace for= > > =3D > >> >mentor.  =3BAgain=2C all appears normal=2C except that all the threa= > >ds are =3D > >> >paused or waiting=2C which is suspicious.  =3BI'm stumped for =3D > >> >now.

Thread 21 (process 96727 thread =3D > >> >0x7403):
#0  =3B0x9634946e in __semwait_signal =3D > >> >()
#1  =3B0x963492ef in nanosleep$UNIX2003 ()
#2= > > =3D > >> > =3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb15d4db0=2C = > >=3D > >> >rem=3D3D0xb15d4db8) at =3D > >> >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  =3B0x0101fd= > >7c =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1f3f880=2C M3_CtKayy_n=3D= > >3D1=2C =3D > >> >M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  =3B0x0101fe= > >f3 =3D > >> >in Thread__Pause (M3_CtKayy_n=3D3D1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  =3B0x00bc9c= > >f4 =3D > >> >in XClientF__MeterMaid (M3_AS2y1X_cl=3D3D0x1f3f870) at =3D > >> >../src/xvbt/XClientF.m3:105
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c441d0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c441d0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 20 (process 96727 thread =3D > >> >0x7103):
#0  =3BThreadPThread__XTestAlert =3D > >> >(M3_BXP32l_self=3D3D0x1e5c134) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:319
#1  =3B0x0101fd= > >9b =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1e5c134=2C =3D > >> >M3_CtKayy_n=3D3D0.0056863520294427872=2C M3_AicXUJ_alertable=3D3D1 '\001= > >') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:669
#2  =3B0x010200= > >24 =3D > >> >in Thread__AlertPause (M3_CtKayy_n=3D3D0.0056863520294427872) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:699
#3  =3B0x008f9e= > >a1 =3D > >> >in Animate__Do (M3_CCfZY3_t=3D3D0x1e7e3fc=2C M3_DsL7Zz_mg=3D3D0x0=2C =3D > >> >M3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_duration=3D3D1) at =3D > >> >../src/Animate.m3:71
#4  =3B0x00909610 in MGV__Animation = > >=3D > >> >(M3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_duration=3D3D1) at =3D > >> >../src/MGV.m3:313
#5  =3B0x008921f9 in =3D > >> >GraphVBT__AnimateGraph (M3_Cj00zi_graph=3D3D0x1e5e00c=2C M3_BUucNs_t0=3D= > >3D0=2C =3D > >> >M3_BUucNs_t1=3D3D1) at ../src/GraphVBT.m3:656
#6 =3D > >> > =3B0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=3D3D0x1ed3060= > >=2C =3D > >> >M3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y=3D3D2=2C M3_AcxOUs_p1=3D3D6=2C M3_AcxOU= > >s_p2=3D3D-2) =3D > >> >at ../src/bresenham/ViewError.m3:548
#7  =3B0x0001529a in = > >=3D > >> >BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D3D0x1ed3060=2C =3D > >> >M3_Af40ku_evt=3D3D0x1e08014) at =3D > >> >../I386_DARWIN/BresenhamIE.m3:101
#8  =3B0x007abb9b in =3D > >> >Zeus__ViewThread (M3_BH3Tll_self=3D3D0x1e5c128) at =3D > >> >../src/Zeus.m3:331
#9  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fd80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#10 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3fd80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#11 0x96373155 in = > >=3D > >> >_pthread_start ()
#12 0x96373012 in thread_start =3D > >> >()

Thread 19 (process 96727 thread =3D > >> >0x5d07):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e5c0bc=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1edf34c=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1edf34c) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x007ab7= > >f2 =3D > >> >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D > >> >M3_B74vJ1_view=3D3D0x1edf25c) at ../src/Zeus.m3:361
#6 =3D > >> > =3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D3D0x1e5c0b0) at= > > =3D > >> >../src/Zeus.m3:328
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fc80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3fc80) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 18 (process 96727 thread =3D > >> >0x700b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e5c044=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1ee3bac=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1ee3bac) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x007ab7= > >f2 =3D > >> >in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D > >> >M3_B74vJ1_view=3D3D0x1ee3b00) at ../src/Zeus.m3:361
#6 =3D > >> > =3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D3D0x1e5c038) at= > > =3D > >> >../src/Zeus.m3:328
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fa90) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3fa90) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 17 (process 96727 thread =3D > >> >0x6e03):
#0  =3B0x963493dc in _pthread_testcancel =3D > >> >()
#1  =3B0x96349275 in nanosleep$UNIX2003 ()
#2= > > =3D > >> > =3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb134add0=2C = > >=3D > >> >rem=3D3D0xb134add8) at =3D > >> >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  =3B0x0101fd= > >7c =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1e54388=2C M3_CtKayy_n=3D= > >3D0.5=2C =3D > >> >M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  =3B0x0101fe= > >f3 =3D > >> >in Thread__Pause (M3_CtKayy_n=3D3D0.5) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  =3B0x00a6f0= > >c0 =3D > >> >in VTCaret__Blinker (M3_Axogco_arg=3D3D0x1e5437c) at =3D > >> >../src/vtext/VTCaret.m3:149
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3f9c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c3f9c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 16 (process 96727 thread =3D > >> >0x435b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1df30c8=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3bb94=2C M3_Bl0jv4_c=3D3D0x1e3bbb0=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1e3bb94=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1e3bbb0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x007baa= > >a1 =3D > >> >in ZeusPanel__PanelThread (M3_CvdnuP_pc=3D3D0x1df30b8) at =3D > >> >../src/ZeusPanel.m3:1425
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c39830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c39830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 15 (process 96727 thread =3D > >> >0x420b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d67e68=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1d22688=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1d22688) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1ee3b00) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007a98b1 in =3D > >> >View__WaiterThread (M3_C7vPGX_waiter=3D3D0x1d67e5c) at =3D > >> >../src/View.m3:74
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c305c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c305c0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 14 (process 96727 thread =3D > >> >0x4103):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ee32e4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1edf3c4=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1edf3c4) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1edf25c) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007a98b1 in =3D > >> >View__WaiterThread (M3_C7vPGX_waiter=3D3D0x1ee32d8) at =3D > >> >../src/View.m3:74
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38bf0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38bf0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 13 (process 96727 thread =3D > >> >0x4003):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1edb2e4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1ed532c=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1ed532c) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1ed3060) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007a98b1 in =3D > >> >View__WaiterThread (M3_C7vPGX_waiter=3D3D0x1edb2d8) at =3D > >> >../src/View.m3:74
#7  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38780) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#8  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38780) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#9  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#10 0x96373012 in thread_start =3D > >> >()

Thread 12 (process 96727 thread =3D > >> >0x2e03):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed52a4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed35f4=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed327c=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1ed35f4) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00bb79= > >62 =3D > >> >in XMessenger__Messenger (M3_EVlqQO_self=3D3D0x1ed5294) at =3D > >> >../src/xvbt/XMessenger.m3:69
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38420) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38420) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 11 (process 96727 thread =3D > >> >0x2b07):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed5254=2C =3D > >> >M3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed3614=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed327c=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1ed3614) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00bbdb= > >c2 =3D > >> >in XInput__FilterXInput (M3_DSd60P_self=3D3D0x1ed5244) at =3D > >> >../src/xvbt/XInput.m3:102
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38320) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38320) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 10 (process 96727 thread =3D > >> >0x2a23):
#0  =3B0x963916fa in select$DARWIN_EXTSN =3D > >> >()
#1  =3B0x01023503 in Unix__select (nfds=3D3D7=2C =3D > >> >readfds=3D3D0x2813d54=2C writefds=3D3D0x2813d64=2C exceptfds=3D3D0x2813d= > >74=2C =3D > >> >timeout=3D3D0x0) at ../src/unix/Common/UnixC.c:301
#2 =3D > >> > =3B0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =3D > >> >(M3_Cwb5VA_nfd=3D3D<=3Bunknown type>=3B=2C M3_A4bqCj_timeout=3D3D0x0= > >) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:787
#3  =3B0x010206= > >cc =3D > >> >in ThreadPThread__XIOWait (M3_BXP32l_self=3D3D0x1ed5204=2C =3D > >> >M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C M3_AicXUJ_read=3D3D1 '\001'= > >=2C =3D > >> >M3_CtKayy_interval=3D3D-1=2C M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:826
#4  =3B0x010201= > >b4 =3D > >> >in SchedulerPosix__IOWait (M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C = > >=3D > >> >M3_AicXUJ_read=3D3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D3D-1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:729
#5  =3B0x00bbf2= > >0b =3D > >> >in XInput__WaitForXInput (M3_Bkyxhg_self=3D3D0x1ed51f4) at =3D > >> >../src/xvbt/XInput.m3:63
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38250) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38250) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 9 (process 96727 thread =3D > >> >0x29f3):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e3fafc=2C =3D > >> >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1e3f9c8=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1e3f9c8) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x007ab3= > >12 =3D > >> >in Zeus__AlgToViews (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D > >> >M3_Ao6Rbg_initiator=3D3D0x1ecd9cc=2C M3_BMhQCx_dispatchProc=3D3D0x150e0= > >=2C =3D > >> >M3_Af40ku_evtArgs=3D3D0x1e08014) at ../src/Zeus.m3:306
#6 =3D > >> > =3B0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D3D0x1ecd9cc= > >=2C =3D > >> >M3_DsvzJ6_style=3D3D0 '\0'=2C M3_AcxOUs_priority=3D3D1=2C =3D > >> >M3_Bd56fi_eventName=3D3D0x1d9d60=2C M3_BMhQCx_dispatchProc=3D3D0x150e0= > >=2C =3D > >> >M3_Af40ku_evtArgs=3D3D0x1e08014) at ../src/Zeus.m3:246
#7 =3D > >> > =3B0x000149a7 in BresenhamIE__ShowPixel =3D > >> >(M3_CfiRBL_initiator=3D3D0x1ecd9cc=2C M3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y= > >=3D3D2=2C =3D > >> >M3_AcxOUs_p1=3D3D6=2C M3_AcxOUs_p2=3D3D-2) at =3D > >> >../I386_DARWIN/BresenhamIE.m3:227
#8  =3B0x000175b7 in =3D > >> >AlgBresenham__DrawLine (M3_ECecEc_alg=3D3D0x1ecd9cc=2C M3_AcxOUs_x1=3D3D= > >0=2C =3D > >> >M3_AcxOUs_y1=3D3D0=2C M3_AcxOUs_x2=3D3D10=2C M3_AcxOUs_y2=3D3D6) at =3D > >> >../src/bresenham/AlgBresenham.m3:55
#9  =3B0x0001788f in = > >=3D > >> >AlgBresenham__Run (M3_ECecEc_alg=3D3D0x1ecd9cc) at =3D > >> >../src/bresenham/AlgBresenham.m3:86
#10 0x007bb729 in =3D > >> >ZeusPanel__AlgThread (M3_Dijbki_ac=3D3D0x1e3fae8) at =3D > >> >../src/ZeusPanel.m3:1534
#11 0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c29fd0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c29fd0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >=3D > >> >_pthread_start ()
#14 0x96373012 in thread_start =3D > >> >()

Thread 8 (process 96727 thread =3D > >> >0x2803):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d8e01c=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d71fdc=2C M3_Bl0jv4_c=3D3D0x1d71fe8=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1d71fdc=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1d71fe8) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x00e3bd= > >f2 =3D > >> >in Formatter__Allocate (M3_ACp9GL_t=3D3D0x1d71680=2C M3_DBiloZ_this=3D3D= > >1 =3D > >> >'\001'=2C M3_Cwb5VA_minSize=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:440
#6  =3B0x00e3bf0a in =3D > >> >Formatter__Probe (M3_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D<=3Bunk= > >nown =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:542
#7 =3D > >> > =3B0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d71680=2C =3D > >> >M3_Cwb5VA_i=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:592
#8  =3B0x00e3c2ff in =3D > >> >Formatter__PeekOp (M3_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D<=3Bun= > >known =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:577
#9 =3D > >> > =3B0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D3D0x1d71680= > >=2C =3D > >> >M3_DOUxXw_mode=3D3D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb038ce90=2C =3D > >> >M3_Cwb5VA_maxL=3D3D<=3Bunknown type>=3B=2C M3_CCuODf_op=3D3D0x1d72c0= > >8) at =3D > >> >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in =3D > >> >Formatter__PrintTop (M3_B5Nhtj_self=3D3D0x1d8e00c) at =3D > >> >../src/formatter/Formatter.m3:615
#11 0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c29140) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c29140) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >=3D > >> >_pthread_start ()
#14 0x96373012 in thread_start =3D > >> >()

Thread 7 (process 96727 thread =3D > >> >0x2703):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d71618=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d715ec=2C M3_Bl0jv4_c=3D3D0x1d715f8=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1d715ec=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1d715f8) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x00e3bd= > >f2 =3D > >> >in Formatter__Allocate (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_DBiloZ_this=3D3D= > >1 =3D > >> >'\001'=2C M3_Cwb5VA_minSize=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:440
#6  =3B0x00e3bf0a in =3D > >> >Formatter__Probe (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D<=3Bunk= > >nown =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:542
#7 =3D > >> > =3B0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d70c90=2C =3D > >> >M3_Cwb5VA_i=3D3D<=3Bunknown type>=3B) at =3D > >> >../src/formatter/Formatter.m3:592
#8  =3B0x00e3c2ff in =3D > >> >Formatter__PeekOp (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D<=3Bun= > >known =3D > >> >type>=3B) at ../src/formatter/Formatter.m3:577
#9 =3D > >> > =3B0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D3D0x1d70c90= > >=2C =3D > >> >M3_DOUxXw_mode=3D3D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb030ae90=2C =3D > >> >M3_Cwb5VA_maxL=3D3D<=3Bunknown type>=3B=2C M3_CCuODf_op=3D3D0x1d72c0= > >8) at =3D > >> >../src/formatter/Formatter.m3:708
#10 0x00e3cfc9 in =3D > >> >Formatter__PrintTop (M3_B5Nhtj_self=3D3D0x1d71608) at =3D > >> >../src/formatter/Formatter.m3:615
#11 0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c221e0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#12 0x0101ef74 in = > >=3D > >> >ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c221e0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#13 0x96373155 in = > >=3D > >> >_pthread_start ()
#14 0x96373012 in thread_start =3D > >> >()

Thread 6 (process 96727 thread =3D > >> >0x2603):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d729bc=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d728b4=2C M3_Bl0jv4_c=3D3D0x1d729a0=2C M3_AicXUJ_aler= > >table=3D3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x1d728b4=2C = > >=3D > >> >M3_Bl0jv4_c=3D3D0x1d729a0) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:266
#5  =3B0x0073de= > >32 =3D > >> >in WorkerPool__ClericApply (M3_BSwVRC_self=3D3D0x1d729b0) at =3D > >> >../src/WorkerPool.m3:152
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c28e10) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c28e10) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 5 (process 96727 thread =3D > >> >0x2313):
#0  =3B0x963916fa in select$DARWIN_EXTSN =3D > >> >()
#1  =3B0x01023503 in Unix__select (nfds=3D3D4=2C =3D > >> >readfds=3D3D0x1d74014=2C writefds=3D3D0x1d74024=2C exceptfds=3D3D0x1d740= > >34=2C =3D > >> >timeout=3D3D0xb0206b20) at ../src/unix/Common/UnixC.c:301
#2 = > >=3D > >> > =3B0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =3D > >> >(M3_Cwb5VA_nfd=3D3D<=3Bunknown type>=3B=2C M3_A4bqCj_timeout=3D3D0xb= > >0206b20) =3D > >> >at ../src/thread/PTHREAD/ThreadPThread.m3:787
#3 =3D > >> > =3B0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=3D3D0x1d585= > >bc=2C =3D > >> >M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C M3_AicXUJ_read=3D3D1 '\001'= > >=2C =3D > >> >M3_CtKayy_interval=3D3D1.7976931348623157e+308=2C M3_AicXUJ_alertable=3D= > >3D1 =3D > >> >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823
#4 =3D > >> > =3B0x010202e7 in SchedulerPosix__IOAlertWait =3D > >> >(M3_Cwb5VA_fd=3D3D<=3Bunknown type>=3B=2C M3_AicXUJ_read=3D3D1 '\001= > >'=2C =3D > >> >M3_CtKayy_timeoutInterval=3D3D-1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:742
#5  =3B0x00dd3c= > >c2 =3D > >> >in TCPMisc__Accept=3D46rom (M3_AahksS_c=3D3D0x1d58594=2C =3D > >> >M3_DoBjMZ_peer=3D3D0xb0206cb4) at ../src/POSIX/TCP.m3:458
#6 = > >=3D > >> > =3B0x00dd3da8 in TCP__Accept (M3_AahksS_c=3D3D0x1d58594) at =3D > >> >../src/POSIX/TCP.m3:234
#7  =3B0x006dbc6b in =3D > >> >LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=3D3D0x1d585b0) at =3D > >> >../src/LocalObjectSpace.m3:307
#8  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c28d60) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#9  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c28d60) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#10 0x96373155 in = > >=3D > >> >_pthread_start ()
#11 0x96373012 in thread_start =3D > >> >()

Thread 4 (process 96727 thread =3D > >> >0x2003):
#0  =3B0x9634946e in __semwait_signal =3D > >> >()
#1  =3B0x963492ef in nanosleep$UNIX2003 ()
#2= > > =3D > >> > =3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb0184dd0=2C = > >=3D > >> >rem=3D3D0xb0184dd8) at =3D > >> >../src/thread/PTHREAD/ThreadPThreadC.c:318
#3  =3B0x0101fd= > >7c =3D > >> >in ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1d0ba08=2C M3_CtKayy_n=3D= > >3D1=2C =3D > >> >M3_AicXUJ_alertable=3D3D0 '\0') at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:668
#4  =3B0x0101fe= > >f3 =3D > >> >in Thread__Pause (M3_CtKayy_n=3D3D1) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:685
#5  =3B0x00a11d= > >53 =3D > >> >in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D3D0x1d0ba00) at =3D > >> >../src/lego/FileBrowserVBT.m3:259
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21830) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 3 (process 96727 thread =3D > >> >0x1f03):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d090d4=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d090b0=2C M3_Bl0jv4_c=3D3D0x1d090bc=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d090b0=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1d090bc) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00a839= > >e2 =3D > >> >in VTView__VFontCleanUpThread (M3_EMTrVz_cl=3D3D0x1d090cc) at =3D > >> >../src/vtext/VTView.m3:111
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21310) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21310) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 2 (process 96727 thread =3D > >> >0xd07):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d006c8=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00688=2C M3_Bl0jv4_c=3D3D0x1d00694=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00688=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1d00694) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00bf33= > >d2 =3D > >> >in VBTRep__MeterMaid (M3_EMTrVz_self=3D3D0x1d006bc) at =3D > >> >../src/vbt/VBTRep.m3:439
#6  =3B0x0101f243 in =3D > >> >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21390) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:546
#7  =3B0x0101ef= > >74 =3D > >> >in ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21390) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:522
#8  =3B0x963731= > >55 =3D > >> >in _pthread_start ()
#9  =3B0x96373012 in thread_start =3D > >> >()

Thread 1 (process 96727 thread =3D > >> >0x10b):
#0  =3B0x963422ce in semaphore_wait_signal_trap = > >=3D > >> >()
#1  =3B0x963742c6 in _pthread_cond_wait ()
#2= > > =3D > >> > =3B0x963b9539 in pthread_cond_wait ()
#3  =3B0x0101d1= > >89 =3D > >> >in ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d0000c=2C =3D > >> >M3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1df3114=2C M3_AicXUJ_aler= > >table=3D3D0 =3D > >> >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
#4 =3D > >> > =3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D > >> >M3_Bl0jv4_c=3D3D0x1df3114) at =3D > >> >../src/thread/PTHREAD/ThreadPThread.m3:277
#5  =3B0x00c406= > >02 =3D > >> >in Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1e3a204) at =3D > >> >../src/trestle/Trestle.m3:884
#6  =3B0x007c09eb in =3D > >> >ZeusPanel__Interact (M3_Bd56fi_title=3D3D0x290db0=2C =3D > >> >M3_DYb95R_path=3D3D0x1d498c0) at ../src/ZeusPanel.m3:477
#7 = > >=3D > >> > =3B0x001b0ede in Main_M3 (M3_AcxOUs_mode=3D3D1) at =3D > >> >../src/Main.m3:165
#8  =3B0x0100eb1f in =3D > >> >RTLinker__RunMainBody (M3_DjPxE3_m=3D3D0x1d6060) at =3D > >> >../src/runtime/common/RTLinker.m3:399
#9  =3B0x00002578 in= > > =3D > >> >main (argc=3D3D1=2C argv=3D3D0xbfffedb8=2C envp=3D3D0xbfffedc0) at =3D > >> >_m3main.mc:6


>> >class=3D3D"Apple-style-span" style=3D3D"font-size: 12px=3B ">
>> >style=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode: space=3B =3D > >> >-webkit-line-break: after-white-space=3B "> >span" =3D > >> >style=3D3D"border-collapse: separate=3B -webkit-border-horizontal-spacin= > >g: =3D > >> >0px=3B -webkit-border-vertical-spacing: 0px=3B color: rgb(0=2C 0=2C 0)= > >=3B =3D > >> >font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B =3D > >> >font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B= > > =3D > >> >line-height: normal=3B -webkit-text-decorations-in-effect: none=3B =3D > >> >text-indent: 0px=3B -webkit-text-size-adjust: auto=3B text-transform: no= > >ne=3B =3D > >> >orphans: 2=3B white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "= > >>
>> >style=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode: space=3B =3D > >> >-webkit-line-break: after-white-space=3B "> >span" =3D > >> >style=3D3D"border-collapse: separate=3B -webkit-border-horizontal-spacin= > >g: =3D > >> >0px=3B -webkit-border-vertical-spacing: 0px=3B color: rgb(0=2C 0=2C 0)= > >=3B =3D > >> >font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B =3D > >> >font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B= > > =3D > >> >line-height: normal=3B -webkit-text-decorations-in-effect: none=3B =3D > >> >text-indent: 0px=3B -webkit-text-size-adjust: auto=3B text-transform: no= > >ne=3B =3D > >> >orphans: 2=3B white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "= > >> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B "> >> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: separate=3B =3D > >> >-webkit-border-horizontal-spacing: 0px=3B -webkit-border-vertical-spacin= > >g: =3D > >> >0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 1= > >2px=3B =3D > >> >font-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D > >> >letter-spacing: normal=3B line-height: normal=3B =3D > >> >-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D > >> >-webkit-text-size-adjust: auto=3B text-transform: none=3B orphans: 2=3B = > >=3D > >> >white-space: normal=3B widows: 2=3B word-spacing: 0px=3B ">
>=3D > >> >class=3D3D"Apple-style-span" color=3D3D"#0000FF"> >> >class=3D3D"Apple-style-span" face=3D3D"Gill Sans"> >> >class=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B fon= > >t-family: =3D > >> >'Gill Sans'=3B "> >b(0=2C =3D > > >0=2C 255)=3B font-family: 'Gill Sans'=3B ">Antony =3D > >> >Hosking >=3D > >> >face=3D3D"Gill Sans"> >family: =3D > >> >'Gill Sans'=3B "> >ly: =3D > >> >'Gill Sans'=3B "> =3B= > >| >> >class=3D3D"Apple-converted-space"> =3B >> >class=3D3D"Apple-style-span" style=3D3D"font-family: 'Gill Sans'=3B "> >pan =3D > >> >class=3D3D"Apple-style-span" style=3D3D"font-family: 'Gill Sans'=3B =3D > >> >">Associate Professor >=3D > >> >style=3D3D"font-family: 'Gill Sans'=3B "> >an" =3D > >> >style=3D3D"font-family: 'Gill Sans'=3B "> =3B| Computer Science | Pu= > >rdue =3D > >> >University
>pan"=3D > >> > face=3D3D"GillSans-Light"> >> >style=3D3D"font-family: GillSans-Light=3B ">305 N. University Street | W= > >est =3D > >> >Lafayette | IN 47907 | USA
>> >class=3D3D"Apple-style-span" color=3D3D"#0000FF" face=3D3D"Gill Sans"> >pan =3D > >> >class=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B fon= > >t-family: =3D > >> >'Gill Sans'=3B "> >b(0=2C =3D > >> >0=2C 255)=3B font-family: 'Gill Sans'=3B ">Office >ont =3D > >> >class=3D3D"Apple-style-span" face=3D3D"GillSans-Light"> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B "= > >> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B = > >=3D > >> >"> =3B+1 765 494 6001 | >> >class=3D3D"Apple-converted-space"> =3B >ont =3D > >> >class=3D3D"Apple-style-span" color=3D3D"#0000FF" face=3D3D"Gill Sans"> >pan =3D > >> >class=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B fon= > >t-family: =3D > >> >'Gill Sans'=3B "> >b(0=2C =3D > >> >0=2C 255)=3B font-family: 'Gill Sans'=3B ">Mobile >ont =3D > >> >class=3D3D"Apple-style-span" face=3D3D"GillSans-Light"> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B "= > >> >> >class=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-Light=3B "= > >> >> >class=3D3D"Apple-converted-space"> =3B+1 765 427 =3D > >> >5484
>=3D > >> >face=3D3D"GillSans-Light">
>> >class=3D3D"khtml-block-placeholder">
>span=3D > >> >>
>> >class=3D3D"Apple-interchange-newline">
<= > >br =3D > >> >class=3D3D"Apple-interchange-newline">

On 6 Sep 2009= > >=2C =3D > >> >at 23:18=2C Jay K wrote:

>> >class=3D3D"Apple-interchange-newline">
>> >type=3D3D"cite">









[was truncated = > >=3D > >> >again!]

PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes= > > =3D > >> >runs out of stack

=3D > >> > > >> >--Apple-Mail-13--794937978-- > > > >--_d2a2b05c-dd99-4149-b3de-8867976ffb79_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >Nice thing about pthreads is everyone uses them.
Whatever tools they hav= > >e=2C we can use.

 =3B ..Jay

>=3B To: hosking at cs.purdue.= > >edu=3B jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com
>=3B = > >Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems= > >)
>=3B Date: Tue=2C 8 Sep 2009 00:48:40 -0700
>=3B From: mika at as= > >ync.async.caltech.edu
>=3B
>=3B
>=3B A nice thing about th= > >e user threads system is that it has a beautiful
>=3B deadlock detecto= > >r... do you have anything like this in the pthreads
>=3B environment?<= > >br>>=3B
>=3B Mika
>=3B
>=3B Tony Hosking writes:
= > >>=3B >=3B
>=3B >=3B--Apple-Mail-13--794937978
>=3B >=3BCo= > >ntent-Type: text/plain=3B
>=3B >=3B charset=3DUS-ASCII=3B
>=3B > > = > >>=3B format=3Dflowed=3B
>=3B >=3B delsp=3Dyes
>=3B >=3BCon > >t= > >ent-Transfer-Encoding: 7bit
>=3B >=3B
>=3B >=3BHere's the han= > >g backtrace for mentor. Again=2C all appears normal=2C
>=3B >=3Be= > >xcept that all the threads are paused or waiting=2C which is
>=3B &g= > >t=3Bsuspicious. I'm stumped for now.
>=3B >=3B
>=3B >=3BThre= > >ad 21 (process 96727 thread 0x7403):
>=3B >=3B#0 0x9634946e in __se= > >mwait_signal ()
>=3B >=3B#1 0x963492ef in nanosleep$UNIX2003 ()
= > >>=3B >=3B#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb15d4db0= > >=2C
>=3B >=3Brem=3D0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThr= > >eadC.c:318
>=3B >=3B#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP3= > >2l_self=3D0x1f3f880=2C
>=3B >=3BM3_CtKayy_n=3D1=2C M3_AicXUJ_alert= > >able=3D0 '\0') at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:= > >668
>=3B >=3B#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ..= > >/src/thread/
>=3B >=3BPTHREAD/ThreadPThread.m3:685
>=3B >=3B= > >#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=3D0x1f3f870) at ../ >>>=3B >=3Bsrc/xvbt/XClientF.m3:105
>=3B >=3B#6 0x0101f243 in Th= > >readPThread__RunThread (M3_BeUkBA_me=3D0x1c441d0)
>=3B >=3Bat ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x0101ef74 in Th= > >readPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c441d0) at = > >../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >= > >=3B#8 0x96373155 in _pthread_start ()
>=3B >=3B#9 0x96373012 in th= > >read_start ()
>=3B >=3B
>=3B >=3BThread 20 (process 96727 thr= > >ead 0x7103):
>=3B >=3B#0 ThreadPThread__XTestAlert (M3_BXP32l_self= > >=3D0x1e5c134) at ../src/
>=3B >=3Bthread/PTHREAD/ThreadPThread.m3:3= > >19
>=3B >=3B#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self= > >=3D0x1e5c134=2C
>=3B >=3BM3_CtKayy_n=3D0.0056863520294427872=2C M3= > >_AicXUJ_alertable=3D1 '\001') at ../
>=3B >=3Bsrc/thread/PTHREAD/Th= > >readPThread.m3:669
>=3B >=3B#2 0x01020024 in Thread__AlertPause >r>>=3B >=3B(M3_CtKayy_n=3D0.0056863520294427872) at ../src/thread/PTHRE= > >AD/
>=3B >=3BThreadPThread.m3:699
>=3B >=3B#3 0x008f9ea1 in= > > Animate__Do (M3_CCfZY3_t=3D0x1e7e3fc=2C
>=3B >=3BM3_DsL7Zz_mg=3D0= > >x0=2C M3_AdEaVQ_v=3D0x1e5e0f8=2C M3_BUucNs_duration=3D1) at ../
>=3B = > >>=3Bsrc/Animate.m3:71
>=3B >=3B#4 0x00909610 in MGV__Animation (M= > >3_AdEaVQ_v=3D0x1e5e0f8=2C
>=3B >=3BM3_BUucNs_duration=3D1) at ../s= > >rc/MGV.m3:313
>=3B >=3B#5 0x008921f9 in GraphVBT__AnimateGraph (M3_= > >Cj00zi_graph=3D0x1e5e00c=2C
>=3B >=3BM3_BUucNs_t0=3D0=2C M3_BUucNs= > >_t1=3D1) at ../src/GraphVBT.m3:656
>=3B >=3B#6 0x00019be8 in ViewEr= > >ror__ShowPixel (M3_AoJTjZ_view=3D0x1ed3060=2C
>=3B >=3BM3_AcxOUs_x= > >=3D3=2C M3_AcxOUs_y=3D2=2C M3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2=3D-2) at ../ >r>>=3B >=3Bsrc/bresenham/ViewError.m3:548
>=3B >=3B#7 0x0001529= > >a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=3D0x1ed3060=2C
>=3B >= > >=3BM3_Af40ku_evt=3D0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101
>= > >=3B >=3B#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c128) a= > >t ../
>=3B >=3Bsrc/Zeus.m3:331
>=3B >=3B#9 0x0101f243 in Th= > >readPThread__RunThread (M3_BeUkBA_me=3D0x1c3fd80)
>=3B >=3Bat ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#10 0x0101ef74 in Th= > >readPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c3fd80) at = > >../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >= > >=3B#11 0x96373155 in _pthread_start ()
>=3B >=3B#12 0x96373012 in th= > >read_start ()
>=3B >=3B
>=3B >=3BThread 19 (process 96727 thr= > >ead 0x5d07):
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap (= > >)
>=3B >=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B#= > >2 0x963b9539 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in Thr= > >eadPThread__XWait (M3_BXP32l_self=3D0x1e5c0bc=2C
>=3B >=3BM3_AYIbX= > >3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1edf34c=2C M3_AicXUJ_alertable=3D1
= > >>=3B >=3B'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>= > >=3B >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1e3f9bc=2C = > >
>=3B >=3BM3_Bl0jv4_c=3D0x1edf34c) at ../src/thread/PTHREAD/ThreadPT= > >hread.m3:266
>=3B >=3B#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_C= > >QpoHd_zeus=3D0x1e3ccfc=2C
>=3B >=3BM3_B74vJ1_view=3D0x1edf25c) at = > >../src/Zeus.m3:361
>=3B >=3B#6 0x007abaa2 in Zeus__ViewThread (M3_B= > >H3Tll_self=3D0x1e5c0b0) at ../
>=3B >=3Bsrc/Zeus.m3:328
>=3B &= > >gt=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3fc80) = > >
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B &= > >gt=3B#8 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWx= > >b1_param=3D0x1c3fc80) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThr= > >ead.m3:522
>=3B >=3B#9 0x96373155 in _pthread_start ()
>=3B &g= > >t=3B#10 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThre= > >ad 18 (process 96727 thread 0x700b):
>=3B >=3B#0 0x963422ce in sema= > >phore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread_cond_w= > >ait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>=3B >= > >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1e5c044=2C <= > >br>>=3B >=3BM3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0jv4_c=3D0x1ee3bac=2C M3_Ai= > >cXUJ_alertable=3D1
>=3B >=3B'\001') at ../src/thread/PTHREAD/Threa= > >dPThread.m3:226
>=3B >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYI= > >bX3_m=3D0x1e3f9bc=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1ee3bac) at ../src/t= > >hread/PTHREAD/ThreadPThread.m3:266
>=3B >=3B#5 0x007ab7f2 in Zeus__= > >WakeZeusAndSleep (M3_CQpoHd_zeus=3D0x1e3ccfc=2C
>=3B >=3BM3_B74vJ1= > >_view=3D0x1ee3b00) at ../src/Zeus.m3:361
>=3B >=3B#6 0x007abaa2 in = > >Zeus__ViewThread (M3_BH3Tll_self=3D0x1e5c038) at ../
>=3B >=3Bsrc/Z= > >eus.m3:328
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_B= > >eUkBA_me=3D0x1c3fa90)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThr= > >ead.m3:546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase >>>=3B >=3B(M3_AJWxb1_param=3D0x1c3fa90) at ../src/thread/PTHREAD/
&= > >gt=3B >=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread= > >_start ()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >= > >=3B
>=3B >=3BThread 17 (process 96727 thread 0x6e03):
>=3B >= > >=3B#0 0x963493dc in _pthread_testcancel ()
>=3B >=3B#1 0x96349275 = > >in nanosleep$UNIX2003 ()
>=3B >=3B#2 0x01022cc4 in ThreadPThread__N= > >anosleep (req=3D0xb134add0=2C
>=3B >=3Brem=3D0xb134add8) at ../src= > >/thread/PTHREAD/ThreadPThreadC.c:318
>=3B >=3B#3 0x0101fd7c in Thre= > >adPThread__XPause (M3_BXP32l_self=3D0x1e54388=2C
>=3B >=3BM3_CtKay= > >y_n=3D0.5=2C M3_AicXUJ_alertable=3D0 '\0') at ../src/thread/PTHREAD/
&g= > >t=3B >=3BThreadPThread.m3:668
>=3B >=3B#4 0x0101fef3 in Thread__P= > >ause (M3_CtKayy_n=3D0.5) at ../src/thread/
>=3B >=3BPTHREAD/ThreadP= > >Thread.m3:685
>=3B >=3B#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco= > >_arg=3D0x1e5437c) at ../src/
>=3B >=3Bvtext/VTCaret.m3:149
>= > >=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c3f= > >9c0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>= > >=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3= > >_AJWxb1_param=3D0x1c3f9c0) at ../src/thread/PTHREAD/
>=3B >=3BThrea= > >dPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthread_start ()
>= > >=3B >=3B#9 0x96373012 in thread_start ()
>=3B >=3B
>=3B >= > >=3BThread 16 (process 96727 thread 0x435b):
>=3B >=3B#0 0x963422ce = > >in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread= > >_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>= > >=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1df30c= > >8=2C
>=3B >=3BM3_AYIbX3_m=3D0x1e3bb94=2C M3_Bl0jv4_c=3D0x1e3bbb0= > >=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/thread/PTHREA= > >D/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread__Wait (M3_A= > >YIbX3_m=3D0x1e3bb94=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1e3bbb0) at ../src= > >/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x007baaa1 in Zeus= > >Panel__PanelThread (M3_CvdnuP_pc=3D0x1df30b8)
>=3B >=3Bat ../src/Z= > >eusPanel.m3:1425
>=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread= > > (M3_BeUkBA_me=3D0x1c39830)
>=3B >=3Bat ../src/thread/PTHREAD/Thre= > >adPThread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBas= > >e
>=3B >=3B(M3_AJWxb1_param=3D0x1c39830) at ../src/thread/PTHREAD/= > >
>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x96373155 in _p= > >thread_start ()
>=3B >=3B#9 0x96373012 in thread_start ()
>=3B= > > >=3B
>=3B >=3BThread 15 (process 96727 thread 0x420b):
>=3B = > >>=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0= > >x963742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthrea= > >d_cond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_B= > >XP32l_self=3D0x1d67e68=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_B= > >l0jv4_c=3D0x1d22688=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at .= > >./src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in= > > Thread__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0= > >x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 = > > 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ee3b00) at ../
&g= > >t=3B >=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007a98b1 in Vie= > >w__WaiterThread (M3_C7vPGX_waiter=3D0x1d67e5c)
>=3B >=3Bat ../src/= > >View.m3:74
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_B= > >eUkBA_me=3D0x1c305c0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThr= > >ead.m3:546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase >>>=3B >=3B(M3_AJWxb1_param=3D0x1c305c0) at ../src/thread/PTHREAD/
&= > >gt=3B >=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread= > >_start ()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >= > >=3B
>=3B >=3BThread 14 (process 96727 thread 0x4103):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1ee32e4=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_Bl0j= > >v4_c=3D0x1edf3c4=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Th= > >read__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1e= > >df3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x= > >00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1edf25c) at ../
>= > >=3B >=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007a98b1 in View= > >__WaiterThread (M3_C7vPGX_waiter=3D0x1ee32d8)
>=3B >=3Bat ../src/V= > >iew.m3:74
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_Be= > >UkBA_me=3D0x1c38bf0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThre= > >ad.m3:546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase
= > >>=3B >=3B(M3_AJWxb1_param=3D0x1c38bf0) at ../src/thread/PTHREAD/
&g= > >t=3B >=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread_= > >start ()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >=3B= > >
>=3B >=3BThread 13 (process 96727 thread 0x4003):
>=3B >=3B#= > >0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742= > >c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_= > >wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_s= > >elf=3D0x1edb2e4=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_Bl0jv4_c= > >=3D0x1ed532c=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/t= > >hread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread= > >__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1ed532= > >c) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x00c4= > >0602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1ed3060) at ../
>=3B &g= > >t=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007a98b1 in View__Wait= > >erThread (M3_C7vPGX_waiter=3D0x1edb2d8)
>=3B >=3Bat ../src/View.m3= > >:74
>=3B >=3B#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_m= > >e=3D0x1c38780)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:= > >546
>=3B >=3B#8 0x0101ef74 in ThreadPThread__ThreadBase
>=3B= > > >=3B(M3_AJWxb1_param=3D0x1c38780) at ../src/thread/PTHREAD/
>=3B &= > >gt=3BThreadPThread.m3:522
>=3B >=3B#9 0x96373155 in _pthread_start = > >()
>=3B >=3B#10 0x96373012 in thread_start ()
>=3B >=3B
&g= > >t=3B >=3BThread 12 (process 96727 thread 0x2e03):
>=3B >=3B#0 0x9= > >63422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in = > >_pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait (= > >)
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D= > >0x1ed52a4=2C
>=3B >=3BM3_AYIbX3_m=3D0x1ed327c=2C M3_Bl0jv4_c=3D0x1= > >ed35f4=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/thread/= > >PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread__Wait= > > (M3_AYIbX3_m=3D0x1ed327c=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1ed35f4) at = > >../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x00bb7962 i= > >n XMessenger__Messenger (M3_EVlqQO_self=3D0x1ed5294)
>=3B >=3Bat .= > >./src/xvbt/XMessenger.m3:69
>=3B >=3B#6 0x0101f243 in ThreadPThread= > >__RunThread (M3_BeUkBA_me=3D0x1c38420)
>=3B >=3Bat ../src/thread/P= > >THREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread= > >__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c38420) at ../src/thre= > >ad/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x963= > >73155 in _pthread_start ()
>=3B >=3B#9 0x96373012 in thread_start (= > >)
>=3B >=3B
>=3B >=3BThread 11 (process 96727 thread 0x2b07):= > >
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B = > >>=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b953= > >9 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__= > >XWait (M3_BXP32l_self=3D0x1ed5254=2C
>=3B >=3BM3_AYIbX3_m=3D0x1ed3= > >27c=2C M3_Bl0jv4_c=3D0x1ed3614=2C M3_AicXUJ_alertable=3D0
>=3B >= > >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 = > >0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1ed327c=2C
>=3B >=3BM3= > >_Bl0jv4_c=3D0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>= > >=3B >=3B#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=3D0x1ed524= > >4)
>=3B >=3Bat ../src/xvbt/XInput.m3:102
>=3B >=3B#6 0x010= > >1f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c38320)
>=3B &g= > >t=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x010= > >1ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1= > >c38320) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
= > >>=3B >=3B#8 0x96373155 in _pthread_start ()
>=3B >=3B#9 0x9637= > >3012 in thread_start ()
>=3B >=3B
>=3B >=3BThread 10 (process= > > 96727 thread 0x2a23):
>=3B >=3B#0 0x963916fa in select$DARWIN_EXTS= > >N ()
>=3B >=3B#1 0x01023503 in Unix__select (nfds=3D7=2C readfds=3D= > >0x2813d54=2C
>=3B >=3Bwritefds=3D0x2813d64=2C exceptfds=3D0x2813d7= > >4=2C timeout=3D0x0) at ../src/unix/
>=3B >=3BCommon/UnixC.c:301
= > >>=3B >=3B#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762
= > >>=3B >=3B(M3_Cwb5VA_nfd=3D<=3Bunknown type>=3B=2C M3_A4bqCj_timeout= > >=3D0x0) at ../src/thread/
>=3B >=3BPTHREAD/ThreadPThread.m3:787
= > >>=3B >=3B#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=3D0x1= > >ed5204=2C
>=3B >=3BM3_Cwb5VA_fd=3D<=3Bunknown type>=3B=2C M3_A= > >icXUJ_read=3D1 '\001'=2C
>=3B >=3BM3_CtKayy_interval=3D-1=2C M3_Ai= > >cXUJ_alertable=3D0 '\0') at ../src/thread/
>=3B >=3BPTHREAD/ThreadP= > >Thread.m3:826
>=3B >=3B#4 0x010201b4 in SchedulerPosix__IOWait (M3_= > >Cwb5VA_fd=3D<=3Bunknown type>=3B=2C
>=3B >=3BM3_AicXUJ_read=3D= > >1 '\001'=2C M3_CtKayy_timeoutInterval=3D-1) at ../src/
>=3B >=3Bthr= > >ead/PTHREAD/ThreadPThread.m3:729
>=3B >=3B#5 0x00bbf20b in XInput__= > >WaitForXInput (M3_Bkyxhg_self=3D0x1ed51f4)
>=3B >=3Bat ../src/xvbt= > >/XInput.m3:63
>=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M= > >3_BeUkBA_me=3D0x1c38250)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadP= > >Thread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase = > >
>=3B >=3B(M3_AJWxb1_param=3D0x1c38250) at ../src/thread/PTHREAD/ >r>>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthr= > >ead_start ()
>=3B >=3B#9 0x96373012 in thread_start ()
>=3B &g= > >t=3B
>=3B >=3BThread 9 (process 96727 thread 0x29f3):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1e3fafc=2C
>=3B >=3BM3_AYIbX3_m=3D0x1e3f9bc=2C M3_Bl0j= > >v4_c=3D0x1e3f9c8=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Th= > >read__Wait (M3_AYIbX3_m=3D0x1e3f9bc=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1e= > >3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x= > >007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=3D0x1e3ccfc=2C
>=3B >= > >=3BM3_Ao6Rbg_initiator=3D0x1ecd9cc=2C M3_BMhQCx_dispatchProc=3D0x150e0=2C = > >
>=3B >=3BM3_Af40ku_evtArgs=3D0x1e08014) at ../src/Zeus.m3:306
&g= > >t=3B >=3B#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D0x1ecd9c= > >c=2C
>=3B >=3BM3_DsvzJ6_style=3D0 '\0'=2C M3_AcxOUs_priority=3D1= > >=2C
>=3B >=3BM3_Bd56fi_eventName=3D0x1d9d60=2C M3_BMhQCx_dispatchP= > >roc=3D0x150e0=2C
>=3B >=3BM3_Af40ku_evtArgs=3D0x1e08014) at ../src= > >/Zeus.m3:246
>=3B >=3B#7 0x000149a7 in BresenhamIE__ShowPixel
= > >>=3B >=3B(M3_CfiRBL_initiator=3D0x1ecd9cc=2C M3_AcxOUs_x=3D3=2C M3_AcxO= > >Us_y=3D2=2C
>=3B >=3BM3_AcxOUs_p1=3D6=2C M3_AcxOUs_p2=3D-2) at ../= > >I386_DARWIN/BresenhamIE.m3:227
>=3B >=3B#8 0x000175b7 in AlgBresenh= > >am__DrawLine (M3_ECecEc_alg=3D0x1ecd9cc=2C
>=3B >=3BM3_AcxOUs_x1= > >=3D0=2C M3_AcxOUs_y1=3D0=2C M3_AcxOUs_x2=3D10=2C M3_AcxOUs_y2=3D6) at ../ <= > >br>>=3B >=3Bsrc/bresenham/AlgBresenham.m3:55
>=3B >=3B#9 0x0001= > >788f in AlgBresenham__Run (M3_ECecEc_alg=3D0x1ecd9cc) at ../
>=3B >= > >=3Bsrc/bresenham/AlgBresenham.m3:86
>=3B >=3B#10 0x007bb729 in ZeusP= > >anel__AlgThread (M3_Dijbki_ac=3D0x1e3fae8) at ../
>=3B >=3Bsrc/Zeus= > >Panel.m3:1534
>=3B >=3B#11 0x0101f243 in ThreadPThread__RunThread (M= > >3_BeUkBA_me=3D0x1c29fd0)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadP= > >Thread.m3:546
>=3B >=3B#12 0x0101ef74 in ThreadPThread__ThreadBase = > >
>=3B >=3B(M3_AJWxb1_param=3D0x1c29fd0) at ../src/thread/PTHREAD/ >r>>=3B >=3BThreadPThread.m3:522
>=3B >=3B#13 0x96373155 in _pthr= > >ead_start ()
>=3B >=3B#14 0x96373012 in thread_start ()
>=3B &g= > >t=3B
>=3B >=3BThread 8 (process 96727 thread 0x2803):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1d8e01c=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d71fdc=2C M3_Bl0j= > >v4_c=3D0x1d71fe8=2C M3_AicXUJ_alertable=3D1
>=3B >=3B'\001') at ..= > >/src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d7a6 in = > >Thread__AlertWait (M3_AYIbX3_m=3D0x1d71fdc=2C
>=3B >=3BM3_Bl0jv4_c= > >=3D0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266
>=3B >= > >=3B#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=3D0x1d71680=2C
&= > >gt=3B >=3BM3_DBiloZ_this=3D1 '\001'=2C M3_Cwb5VA_minSize=3D<=3Bunknown = > >type>=3B) at ../src/
>=3B >=3Bformatter/Formatter.m3:440
>= > >=3B >=3B#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=3D0x1d71680=2C <= > >br>>=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>=3B) at ../src/formatter= > >/Formatter.m3:542
>=3B >=3B#7 0x00e3c2b8 in Formatter__Peek (M3_ACp= > >9GL_t=3D0x1d71680=2C
>=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>= > >=3B) at ../src/formatter/Formatter.m3:592
>=3B >=3B#8 0x00e3c2ff in= > > Formatter__PeekOp (M3_ACp9GL_t=3D0x1d71680=2C
>=3B >=3BM3_Cwb5VA_= > >i=3D<=3Bunknown type>=3B) at ../src/formatter/Formatter.m3:577
>= > >=3B >=3B#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=3D0x1d71680= > >=2C
>=3B >=3BM3_DOUxXw_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb038ce= > >90=2C
>=3B >=3BM3_Cwb5VA_maxL=3D<=3Bunknown type>=3B=2C M3_CCu= > >ODf_op=3D0x1d72c08) at ../src/
>=3B >=3Bformatter/Formatter.m3:708<= > >br>>=3B >=3B#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1= > >d8e00c) at ../
>=3B >=3Bsrc/formatter/Formatter.m3:615
>=3B &g= > >t=3B#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c29140) = > >
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B &g= > >t=3B#12 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb= > >1_param=3D0x1c29140) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThre= > >ad.m3:522
>=3B >=3B#13 0x96373155 in _pthread_start ()
>=3B >= > >=3B#14 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThrea= > >d 7 (process 96727 thread 0x2703):
>=3B >=3B#0 0x963422ce in semaph= > >ore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread_cond_wai= > >t ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>=3B >= > >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d71618=2C <= > >br>>=3B >=3BM3_AYIbX3_m=3D0x1d715ec=2C M3_Bl0jv4_c=3D0x1d715f8=2C M3_Ai= > >cXUJ_alertable=3D1
>=3B >=3B'\001') at ../src/thread/PTHREAD/Threa= > >dPThread.m3:226
>=3B >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYI= > >bX3_m=3D0x1d715ec=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1d715f8) at ../src/t= > >hread/PTHREAD/ThreadPThread.m3:266
>=3B >=3B#5 0x00e3bdf2 in Format= > >ter__Allocate (M3_ACp9GL_t=3D0x1d70c90=2C
>=3B >=3BM3_DBiloZ_this= > >=3D1 '\001'=2C M3_Cwb5VA_minSize=3D<=3Bunknown type>=3B) at ../src/ >>>=3B >=3Bformatter/Formatter.m3:440
>=3B >=3B#6 0x00e3bf0a in = > >Formatter__Probe (M3_ACp9GL_t=3D0x1d70c90=2C
>=3B >=3BM3_Cwb5VA_i= > >=3D<=3Bunknown type>=3B) at ../src/formatter/Formatter.m3:542
>=3B= > > >=3B#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D0x1d70c90=2C
&= > >gt=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>=3B) at ../src/formatter/For= > >matter.m3:592
>=3B >=3B#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9G= > >L_t=3D0x1d70c90=2C
>=3B >=3BM3_Cwb5VA_i=3D<=3Bunknown type>=3B= > >) at ../src/formatter/Formatter.m3:577
>=3B >=3B#9 0x00e3cb25 in Fo= > >rmatter__PrintUntil (M3_ACp9GL_t=3D0x1d70c90=2C
>=3B >=3BM3_DOUxXw= > >_mode=3D1 '\001'=2C M3_ElBLGV_pos=3D0xb030ae90=2C
>=3B >=3BM3_Cwb5= > >VA_maxL=3D<=3Bunknown type>=3B=2C M3_CCuODf_op=3D0x1d72c08) at ../src/ = > >
>=3B >=3Bformatter/Formatter.m3:708
>=3B >=3B#10 0x00e3cfc9 = > >in Formatter__PrintTop (M3_B5Nhtj_self=3D0x1d71608) at ../
>=3B >= > >=3Bsrc/formatter/Formatter.m3:615
>=3B >=3B#11 0x0101f243 in ThreadP= > >Thread__RunThread (M3_BeUkBA_me=3D0x1c221e0)
>=3B >=3Bat ../src/th= > >read/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#12 0x0101ef74 in ThreadP= > >Thread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c221e0) at ../sr= > >c/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B >=3B#13= > > 0x96373155 in _pthread_start ()
>=3B >=3B#14 0x96373012 in thread_s= > >tart ()
>=3B >=3B
>=3B >=3BThread 6 (process 96727 thread 0x2= > >603):
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
&g= > >t=3B >=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x96= > >3b9539 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThr= > >ead__XWait (M3_BXP32l_self=3D0x1d729bc=2C
>=3B >=3BM3_AYIbX3_m=3D0= > >x1d728b4=2C M3_Bl0jv4_c=3D0x1d729a0=2C M3_AicXUJ_alertable=3D1
>=3B = > >>=3B'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>=3B >= > >=3B#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D0x1d728b4=2C
>= > >=3B >=3BM3_Bl0jv4_c=3D0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m= > >3:266
>=3B >=3B#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_= > >self=3D0x1d729b0)
>=3B >=3Bat ../src/WorkerPool.m3:152
>=3B &= > >gt=3B#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28e10) = > >
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B &= > >gt=3B#7 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWx= > >b1_param=3D0x1c28e10) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThr= > >ead.m3:522
>=3B >=3B#8 0x96373155 in _pthread_start ()
>=3B &g= > >t=3B#9 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThre= > >ad 5 (process 96727 thread 0x2313):
>=3B >=3B#0 0x963916fa in selec= > >t$DARWIN_EXTSN ()
>=3B >=3B#1 0x01023503 in Unix__select (nfds=3D4= > >=2C readfds=3D0x1d74014=2C
>=3B >=3Bwritefds=3D0x1d74024=2C except= > >fds=3D0x1d74034=2C timeout=3D0xb0206b20) at ../src/
>=3B >=3Bunix/C= > >ommon/UnixC.c:301
>=3B >=3B#2 0x01020970 in ThreadPThread__XIOWait_= > >_CallSelect.762
>=3B >=3B(M3_Cwb5VA_nfd=3D<=3Bunknown type>=3B= > >=2C M3_A4bqCj_timeout=3D0xb0206b20) at ../src/
>=3B >=3Bthread/PTHR= > >EAD/ThreadPThread.m3:787
>=3B >=3B#3 0x010206a8 in ThreadPThread__X= > >IOWait (M3_BXP32l_self=3D0x1d585bc=2C
>=3B >=3BM3_Cwb5VA_fd=3D<= > >=3Bunknown type>=3B=2C M3_AicXUJ_read=3D1 '\001'=2C
>=3B >=3BM3_= > >CtKayy_interval=3D1.7976931348623157e+308=2C M3_AicXUJ_alertable=3D1
&= > >gt=3B >=3B'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823
>=3B= > > >=3B#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=3D<=3B= > >unknown
>=3B >=3Btype>=3B=2C M3_AicXUJ_read=3D1 '\001'=2C M3_CtK= > >ayy_timeoutInterval=3D-1) at ../
>=3B >=3Bsrc/thread/PTHREAD/Thread= > >PThread.m3:742
>=3B >=3B#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_Aa= > >hksS_c=3D0x1d58594=2C
>=3B >=3BM3_DoBjMZ_peer=3D0xb0206cb4) at ../= > >src/POSIX/TCP.m3:458
>=3B >=3B#6 0x00dd3da8 in TCP__Accept (M3_Aahk= > >sS_c=3D0x1d58594) at ../src/POSIX/
>=3B >=3BTCP.m3:234
>=3B &g= > >t=3B#7 0x006dbc6b in LocalObjectSpace__SpaceAccept
>=3B >=3B(M3_D= > >bz8GV_self=3D0x1d585b0) at ../src/LocalObjectSpace.m3:307
>=3B >=3B#= > >8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c28d60)
&= > >gt=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#= > >9 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_par= > >am=3D0x1c28d60) at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3= > >:522
>=3B >=3B#10 0x96373155 in _pthread_start ()
>=3B >=3B#1= > >1 0x96373012 in thread_start ()
>=3B >=3B
>=3B >=3BThread 4 (= > >process 96727 thread 0x2003):
>=3B >=3B#0 0x9634946e in __semwait_s= > >ignal ()
>=3B >=3B#1 0x963492ef in nanosleep$UNIX2003 ()
>=3B = > >>=3B#2 0x01022cc4 in ThreadPThread__Nanosleep (req=3D0xb0184dd0=2C
= > >>=3B >=3Brem=3D0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:31= > >8
>=3B >=3B#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self= > >=3D0x1d0ba08=2C
>=3B >=3BM3_CtKayy_n=3D1=2C M3_AicXUJ_alertable=3D= > >0 '\0') at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:668
= > >>=3B >=3B#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=3D1) at ../src/th= > >read/
>=3B >=3BPTHREAD/ThreadPThread.m3:685
>=3B >=3B#5 0x0= > >0a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=3D0x1d0ba00)
>=3B &= > >gt=3Bat ../src/lego/FileBrowserVBT.m3:259
>=3B >=3B#6 0x0101f243 in= > > ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21830)
>=3B >=3Bat .= > >./src/thread/PTHREAD/ThreadPThread.m3:546
>=3B >=3B#7 0x0101ef74 in= > > ThreadPThread__ThreadBase
>=3B >=3B(M3_AJWxb1_param=3D0x1c21830) = > >at ../src/thread/PTHREAD/
>=3B >=3BThreadPThread.m3:522
>=3B &= > >gt=3B#8 0x96373155 in _pthread_start ()
>=3B >=3B#9 0x96373012 in = > >thread_start ()
>=3B >=3B
>=3B >=3BThread 3 (process 96727 th= > >read 0x1f03):
>=3B >=3B#0 0x963422ce in semaphore_wait_signal_trap = > >()
>=3B >=3B#1 0x963742c6 in _pthread_cond_wait ()
>=3B >=3B= > >#2 0x963b9539 in pthread_cond_wait ()
>=3B >=3B#3 0x0101d189 in Th= > >readPThread__XWait (M3_BXP32l_self=3D0x1d090d4=2C
>=3B >=3BM3_AYIb= > >X3_m=3D0x1d090b0=2C M3_Bl0jv4_c=3D0x1d090bc=2C M3_AicXUJ_alertable=3D0 >>>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226
>=3B= > > >=3B#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D0x1d090b0=2C
>= > >=3B >=3BM3_Bl0jv4_c=3D0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m= > >3:277
>=3B >=3B#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTr= > >Vz_cl=3D0x1d090cc)
>=3B >=3Bat ../src/vtext/VTView.m3:111
>= > >=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=3D0x1c21= > >310)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:546
>= > >=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase
>=3B >=3B(M3= > >_AJWxb1_param=3D0x1c21310) at ../src/thread/PTHREAD/
>=3B >=3BThrea= > >dPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthread_start ()
>= > >=3B >=3B#9 0x96373012 in thread_start ()
>=3B >=3B
>=3B >= > >=3BThread 2 (process 96727 thread 0xd07):
>=3B >=3B#0 0x963422ce in= > > semaphore_wait_signal_trap ()
>=3B >=3B#1 0x963742c6 in _pthread_c= > >ond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_cond_wait ()
>= > >=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=3D0x1d006c= > >8=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00688=2C M3_Bl0jv4_c=3D0x1d00694= > >=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../src/thread/PTHREA= > >D/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Thread__Wait (M3_A= > >YIbX3_m=3D0x1d00688=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1d00694) at ../src= > >/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x00bf33d2 in VBTR= > >ep__MeterMaid (M3_EMTrVz_self=3D0x1d006bc) at ../
>=3B >=3Bsrc/vbt/= > >VBTRep.m3:439
>=3B >=3B#6 0x0101f243 in ThreadPThread__RunThread (M= > >3_BeUkBA_me=3D0x1c21390)
>=3B >=3Bat ../src/thread/PTHREAD/ThreadP= > >Thread.m3:546
>=3B >=3B#7 0x0101ef74 in ThreadPThread__ThreadBase = > >
>=3B >=3B(M3_AJWxb1_param=3D0x1c21390) at ../src/thread/PTHREAD/ >r>>=3B >=3BThreadPThread.m3:522
>=3B >=3B#8 0x96373155 in _pthr= > >ead_start ()
>=3B >=3B#9 0x96373012 in thread_start ()
>=3B &g= > >t=3B
>=3B >=3BThread 1 (process 96727 thread 0x10b):
>=3B >= > >=3B#0 0x963422ce in semaphore_wait_signal_trap ()
>=3B >=3B#1 0x96= > >3742c6 in _pthread_cond_wait ()
>=3B >=3B#2 0x963b9539 in pthread_c= > >ond_wait ()
>=3B >=3B#3 0x0101d189 in ThreadPThread__XWait (M3_BXP3= > >2l_self=3D0x1d0000c=2C
>=3B >=3BM3_AYIbX3_m=3D0x1d00500=2C M3_Bl0j= > >v4_c=3D0x1df3114=2C M3_AicXUJ_alertable=3D0
>=3B >=3B'\0') at ../s= > >rc/thread/PTHREAD/ThreadPThread.m3:226
>=3B >=3B#4 0x0101d823 in Th= > >read__Wait (M3_AYIbX3_m=3D0x1d00500=2C
>=3B >=3BM3_Bl0jv4_c=3D0x1d= > >f3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277
>=3B >=3B#5 0x= > >00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=3D0x1e3a204) at ../
>= > >=3B >=3Bsrc/trestle/Trestle.m3:884
>=3B >=3B#6 0x007c09eb in Zeus= > >Panel__Interact (M3_Bd56fi_title=3D0x290db0=2C
>=3B >=3BM3_DYb95R_= > >path=3D0x1d498c0) at ../src/ZeusPanel.m3:477
>=3B >=3B#7 0x001b0ede= > > in Main_M3 (M3_AcxOUs_mode=3D1) at ../src/Main.m3:165
>=3B >=3B#8 = > >0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=3D0x1d6060) at ../
>= > >=3B >=3Bsrc/runtime/common/RTLinker.m3:399
>=3B >=3B#9 0x00002578= > > in main (argc=3D1=2C argv=3D0xbfffedb8=2C envp=3D0xbfffedc0) at
>= > >=3B >=3B_m3main.mc:6
>=3B >=3B
>=3B >=3B
>=3B >=3BAn= > >tony Hosking | Associate Professor | Computer Science | Purdue
>=3B = > >>=3BUniversity
>=3B >=3B305 N. University Street | West Lafayette = > >| IN 47907 | USA
>=3B >=3BOffice +1 765 494 6001 | Mobile +1 765 427= > > 5484
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B >r>>=3B >=3BOn 6 Sep 2009=2C at 23:18=2C Jay K wrote:
>=3B >=3B >r>>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>= > >=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B &g= > >t=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B&g= > >t=3B [was truncated again!]
>=3B >=3B>=3B
>=3B >=3B>=3B P= > >PC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes runs out of
&= > >gt=3B >=3B>=3B stack
>=3B >=3B
>=3B >=3B
>=3B >=3B= > >--Apple-Mail-13--794937978
>=3B >=3BContent-Type: text/html=3B
&g= > >t=3B >=3B charset=3DUS-ASCII
>=3B >=3BContent-Transfer-Encoding: q > >= > >uoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>=3B<=3Bbody= > > style=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode: space=3B =3D
>= > >=3B >=3B-webkit-line-break: after-white-space=3B ">=3BHere's the hang b= > >acktrace for =3D
>=3B >=3Bmentor. &=3Bnbsp=3BAgain=2C all appears= > > normal=2C except that all the threads are =3D
>=3B >=3Bpaused or wa= > >iting=2C which is suspicious. &=3Bnbsp=3BI'm stumped for =3D
>=3B &= > >gt=3Bnow.<=3Bdiv>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3B= > >div>=3BThread 21 (process 96727 thread =3D
>=3B >=3B0x7403):<=3B= > >/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x9634946e in __semwait_signal = > >=3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963= > >492ef in nanosleep$UNIX2003 ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x01022cc4 in ThreadPThread__Nanosleep (req=3D3D0xb= > >15d4db0=2C =3D
>=3B >=3Brem=3D3D0xb15d4db8) at =3D
>=3B >=3B.= > >./src/thread/PTHREAD/ThreadPThreadC.c:318<=3B/div>=3B<=3Bdiv>=3B#3 = > >&=3Bnbsp=3B0x0101fd7c =3D
>=3B >=3Bin ThreadPThread__XPause (M3_B= > >XP32l_self=3D3D0x1f3f880=2C M3_CtKayy_n=3D3D1=2C =3D
>=3B >=3BM3_Aic= > >XUJ_alertable=3D3D0 '\0') at =3D
>=3B >=3B../src/thread/PTHREAD/Thre= > >adPThread.m3:668<=3B/div>=3B<=3Bdiv>=3B#4 &=3Bnbsp=3B0x0101fef3 = > >=3D
>=3B >=3Bin Thread__Pause (M3_CtKayy_n=3D3D1) at =3D
>=3B &= > >gt=3B../src/thread/PTHREAD/ThreadPThread.m3:685<=3B/div>=3B<=3Bdiv>= > >=3B#5 &=3Bnbsp=3B0x00bc9cf4 =3D
>=3B >=3Bin XClientF__MeterMaid (= > >M3_AS2y1X_cl=3D3D0x1f3f870) at =3D
>=3B >=3B../src/xvbt/XClientF.m3:= > >105<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>= > >=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c441d0) at =3D
&= > >gt=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<= > >=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThrea= > >d__ThreadBase (M3_AJWxb1_param=3D3D0x1c441d0) at =3D
>=3B >=3B../src= > >/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &= > >=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>= > >=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>=3B= > > >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<= > >=3Bdiv>=3BThread 20 (process 96727 thread =3D
>=3B >=3B0x7103):<= > >=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3BThreadPThread__XTestAlert =3D<= > >br>>=3B >=3B(M3_BXP32l_self=3D3D0x1e5c134) at =3D
>=3B >=3B../sr= > >c/thread/PTHREAD/ThreadPThread.m3:319<=3B/div>=3B<=3Bdiv>=3B#1 &= > >=3Bnbsp=3B0x0101fd9b =3D
>=3B >=3Bin ThreadPThread__XPause (M3_BXP32= > >l_self=3D3D0x1e5c134=2C =3D
>=3B >=3BM3_CtKayy_n=3D3D0.0056863520294= > >427872=2C M3_AicXUJ_alertable=3D3D1 '\001') at =3D
>=3B >=3B../src/t= > >hread/PTHREAD/ThreadPThread.m3:669<=3B/div>=3B<=3Bdiv>=3B#2 &=3B= > >nbsp=3B0x01020024 =3D
>=3B >=3Bin Thread__AlertPause (M3_CtKayy_n=3D= > >3D0.0056863520294427872) at =3D
>=3B >=3B../src/thread/PTHREAD/Threa= > >dPThread.m3:699<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x008f9ea1 = > >=3D
>=3B >=3Bin Animate__Do (M3_CCfZY3_t=3D3D0x1e7e3fc=2C M3_DsL7Zz_= > >mg=3D3D0x0=2C =3D
>=3B >=3BM3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_du= > >ration=3D3D1) at =3D
>=3B >=3B../src/Animate.m3:71<=3B/div>=3B&l= > >t=3Bdiv>=3B#4 &=3Bnbsp=3B0x00909610 in MGV__Animation =3D
>=3B &g= > >t=3B(M3_AdEaVQ_v=3D3D0x1e5e0f8=2C M3_BUucNs_duration=3D3D1) at =3D
>= > >=3B >=3B../src/MGV.m3:313<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B= > >0x008921f9 in =3D
>=3B >=3BGraphVBT__AnimateGraph (M3_Cj00zi_graph= > >=3D3D0x1e5e00c=2C M3_BUucNs_t0=3D3D0=2C =3D
>=3B >=3BM3_BUucNs_t1=3D= > >3D1) at ../src/GraphVBT.m3:656<=3B/div>=3B<=3Bdiv>=3B#6 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view= > >=3D3D0x1ed3060=2C =3D
>=3B >=3BM3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y=3D3D= > >2=2C M3_AcxOUs_p1=3D3D6=2C M3_AcxOUs_p2=3D3D-2) =3D
>=3B >=3Bat ../s= > >rc/bresenham/ViewError.m3:548<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp= > >=3B0x0001529a in =3D
>=3B >=3BBresenhamIE__OEDispatcher (M3_Ao6Rbg_v= > >=3D3D0x1ed3060=2C =3D
>=3B >=3BM3_Af40ku_evt=3D3D0x1e08014) at =3D >r>>=3B >=3B../I386_DARWIN/BresenhamIE.m3:101<=3B/div>=3B<=3Bdiv&g= > >t=3B#8 &=3Bnbsp=3B0x007abb9b in =3D
>=3B >=3BZeus__ViewThread (M3= > >_BH3Tll_self=3D3D0x1e5c128) at =3D
>=3B >=3B../src/Zeus.m3:331<=3B= > >/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >= > >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fd80) at =3D
>=3B &= > >gt=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>= > >=3B#10 0x0101ef74 in =3D
>=3B >=3BThreadPThread__ThreadBase (M3_AJWx= > >b1_param=3D3D0x1c3fd80) at =3D
>=3B >=3B../src/thread/PTHREAD/Thread= > >PThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#11 0x96373155 in =3D
>= > >=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#12 0x96373012 in= > > thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr= > >>=3B<=3B/div>=3B<=3Bdiv>=3BThread 19 (process 96727 thread =3D >>>=3B >=3B0x5d07):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963= > >422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B&= > >lt=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/di= > >v>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pt= > >hread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d18= > >9 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e5c0bc= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1edf= > >34c=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../src/thre= > >ad/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x= > >1e3f9bc=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1edf34c) at =3D
>=3B = > >>=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div>=3B<=3Bdiv&g= > >t=3B#5 &=3Bnbsp=3B0x007ab7f2 =3D
>=3B >=3Bin Zeus__WakeZeusAndSle= > >ep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D
>=3B >=3BM3_B74vJ1_view=3D3D= > >0x1edf25c) at ../src/Zeus.m3:361<=3B/div>=3B<=3Bdiv>=3B#6 =3D
&g= > >t=3B >=3B&=3Bnbsp=3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=3D3= > >D0x1e5c0b0) at =3D
>=3B >=3B../src/Zeus.m3:328<=3B/div>=3B<=3B= > >div>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__= > >RunThread (M3_BeUkBA_me=3D3D0x1c3fc80) at =3D
>=3B >=3B../src/thread= > >/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp= > >=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_p= > >aram=3D3D0x1c3fc80) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThr= > >ead.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373155 =3D >>>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#10 0x9637= > >3012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B&= > >lt=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 18 (process 96727 thread= > > =3D
>=3B >=3B0x700b):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp= > >=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/di= > >v>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()&= > >lt=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b95= > >39 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0= > >x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0= > >x1e5c044=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D= > >3D0x1ee3bac=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../= > >src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 = > >=3D
>=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX= > >3_m=3D3D0x1e3f9bc=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1ee3bac) at =3D<= > >br>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div>=3B&= > >lt=3Bdiv>=3B#5 &=3Bnbsp=3B0x007ab7f2 =3D
>=3B >=3Bin Zeus__Wake= > >ZeusAndSleep (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C =3D
>=3B >=3BM3_B74vJ1= > >_view=3D3D0x1ee3b00) at ../src/Zeus.m3:361<=3B/div>=3B<=3Bdiv>=3B#6= > > =3D
>=3B >=3B&=3Bnbsp=3B0x007abaa2 in Zeus__ViewThread (M3_BH3Tl= > >l_self=3D3D0x1e5c038) at =3D
>=3B >=3B../src/Zeus.m3:328<=3B/div&g= > >t=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThrea= > >dPThread__RunThread (M3_BeUkBA_me=3D3D0x1c3fa90) at =3D
>=3B >=3B../= > >src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8 &a= > >mp=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3= > >_AJWxb1_param=3D3D0x1c3fa90) at =3D
>=3B >=3B../src/thread/PTHREAD/T= > >hreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x963731= > >55 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#= > >10 0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 17 (process 967= > >27 thread =3D
>=3B >=3B0x6e03):<=3B/div>=3B<=3Bdiv>=3B#0 &am= > >p=3Bnbsp=3B0x963493dc in _pthread_testcancel =3D
>=3B >=3B()<=3B/d= > >iv>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x96349275 in nanosleep$UNIX2003 ()= > ><=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x01022= > >cc4 in ThreadPThread__Nanosleep (req=3D3D0xb134add0=2C =3D
>=3B >=3B= > >rem=3D3D0xb134add8) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThr= > >eadC.c:318<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101fd7c =3D >>>=3B >=3Bin ThreadPThread__XPause (M3_BXP32l_self=3D3D0x1e54388=2C M3_= > >CtKayy_n=3D3D0.5=2C =3D
>=3B >=3BM3_AicXUJ_alertable=3D3D0 '\0') at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:668<=3B/div>= > >=3B<=3Bdiv>=3B#4 &=3Bnbsp=3B0x0101fef3 =3D
>=3B >=3Bin Thread= > >__Pause (M3_CtKayy_n=3D3D0.5) at =3D
>=3B >=3B../src/thread/PTHREAD/= > >ThreadPThread.m3:685<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00a6f= > >0c0 =3D
>=3B >=3Bin VTCaret__Blinker (M3_Axogco_arg=3D3D0x1e5437c) a= > >t =3D
>=3B >=3B../src/vtext/VTCaret.m3:149<=3B/div>=3B<=3Bdiv&= > >gt=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunT= > >hread (M3_BeUkBA_me=3D3D0x1c3f9c0) at =3D
>=3B >=3B../src/thread/PTH= > >READ/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x= > >0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param= > >=3D3D0x1c3f9c0) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.= > >m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>= > >=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp= > >=3B0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 16 (process 967= > >27 thread =3D
>=3B >=3B0x435b):<=3B/div>=3B<=3Bdiv>=3B#0 &am= > >p=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()&= > >lt=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_= > >wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B= > >0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3B= > >nbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_se= > >lf=3D3D0x1df30c8=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1e3bb94=2C M3_Bl0= > >jv4_c=3D3D0x1e3bbb0=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') = > >at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>= > >=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIb= > >X3_m=3D3D0x1e3bb94=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1e3bbb0) at =3D= > >
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B= > ><=3Bdiv>=3B#5 &=3Bnbsp=3B0x007baaa1 =3D
>=3B >=3Bin ZeusPanel= > >__PanelThread (M3_CvdnuP_pc=3D3D0x1df30b8) at =3D
>=3B >=3B../src/Ze= > >usPanel.m3:1425<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 i= > >n =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c39830)= > > at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/di= > >v>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin Th= > >readPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c39830) at =3D
>=3B &g= > >t=3B../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>= > >=3B#8 &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<= > >=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D= > >
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div&= > >gt=3B<=3Bdiv>=3BThread 15 (process 96727 thread =3D
>=3B >=3B0x4= > >20b):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphor= > >e_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 = > >&=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv&= > >gt=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait (= > >)<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B &= > >gt=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d67e68=2C =3D
>=3B= > > >=3BM3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1d22688=2C M3_AicXUJ_= > >alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPT= > >hread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnb= > >sp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D
>=3B= > > >=3BM3_Bl0jv4_c=3D3D0x1d22688) at =3D
>=3B >=3B../src/thread/PTHR= > >EAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x0= > >0c40602 =3D
>=3B >=3Bin Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1ee3= > >b00) at =3D
>=3B >=3B../src/trestle/Trestle.m3:884<=3B/div>=3B&l= > >t=3Bdiv>=3B#6 &=3Bnbsp=3B0x007a98b1 in =3D
>=3B >=3BView__Waite= > >rThread (M3_C7vPGX_waiter=3D3D0x1d67e5c) at =3D
>=3B >=3B../src/View= > >.m3:74<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
= > >>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c305c0) at =3D >r>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B&l= > >t=3Bdiv>=3B#8 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThre= > >ad__ThreadBase (M3_AJWxb1_param=3D3D0x1c305c0) at =3D
>=3B >=3B../sr= > >c/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &= > >=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>= > >=3B<=3Bdiv>=3B#10 0x96373012 in thread_start =3D
>=3B >=3B()<= > >=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BTh= > >read 14 (process 96727 thread =3D
>=3B >=3B0x4103):<=3B/div>=3B&= > >lt=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D= > >
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742= > >c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B = > >>=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<= > >=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThrea= > >d__XWait (M3_BXP32l_self=3D3D0x1ee32e4=2C =3D
>=3B >=3BM3_AYIbX3_m= > >=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1edf3c4=2C M3_AicXUJ_alertable=3D3D0 = > >=3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226<= > >=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823= > > in Thread__Wait (M3_AYIbX3_m=3D3D0x1d00500=2C =3D
>=3B >=3BM3_Bl0jv= > >4_c=3D3D0x1edf3c4) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThre= > >ad.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00c40602 =3D
= > >>=3B >=3Bin Trestle__AwaitDelete (M3_BFdKo9_v=3D3D0x1edf25c) at =3D
= > >>=3B >=3B../src/trestle/Trestle.m3:884<=3B/div>=3B<=3Bdiv>=3B#6= > > &=3Bnbsp=3B0x007a98b1 in =3D
>=3B >=3BView__WaiterThread (M3_C7v= > >PGX_waiter=3D3D0x1ee32d8) at =3D
>=3B >=3B../src/View.m3:74<=3B/di= > >v>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BTh= > >readPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38bf0) at =3D
>=3B >=3B= > >../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8= > > &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase = > >(M3_AJWxb1_param=3D3D0x1c38bf0) at =3D
>=3B >=3B../src/thread/PTHREA= > >D/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x963= > >73155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>= > >=3B#10 0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<= > >=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 13 (process= > > 96727 thread =3D
>=3B >=3B0x4003):<=3B/div>=3B<=3Bdiv>=3B#0= > > &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >= > >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread= > >_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bn= > >bsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &= > >amp=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP= > >32l_self=3D3D0x1edb2e4=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d00500=2C = > >M3_Bl0jv4_c=3D3D0x1ed532c=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B= > >'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdi= > >v>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_= > >AYIbX3_m=3D3D0x1d00500=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1ed532c) at= > > =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div&g= > >t=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00c40602 =3D
>=3B >=3Bin Trest= > >le__AwaitDelete (M3_BFdKo9_v=3D3D0x1ed3060) at =3D
>=3B >=3B../src/t= > >restle/Trestle.m3:884<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x007a= > >98b1 in =3D
>=3B >=3BView__WaiterThread (M3_C7vPGX_waiter=3D3D0x1edb= > >2d8) at =3D
>=3B >=3B../src/View.m3:74<=3B/div>=3B<=3Bdiv>= > >=3B#7 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunThr= > >ead (M3_BeUkBA_me=3D3D0x1c38780) at =3D
>=3B >=3B../src/thread/PTHRE= > >AD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x01= > >01ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D= > >3D0x1c38780) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:= > >522<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373155 =3D
>=3B= > > >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#10 0x96373012 in= > > thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr= > >>=3B<=3B/div>=3B<=3Bdiv>=3BThread 12 (process 96727 thread =3D >>>=3B >=3B0x2e03):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963= > >422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B&= > >lt=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/di= > >v>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pt= > >hread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d18= > >9 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed52a4= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed3= > >5f4=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread= > >/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed32= > >7c=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1ed35f4) at =3D
>=3B >= > >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>= > >=3B#5 &=3Bnbsp=3B0x00bb7962 =3D
>=3B >=3Bin XMessenger__Messenger= > > (M3_EVlqQO_self=3D3D0x1ed5294) at =3D
>=3B >=3B../src/xvbt/XMesseng= > >er.m3:69<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D >r>>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38420) at =3D= > >
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B= > ><=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPTh= > >read__ThreadBase (M3_AJWxb1_param=3D3D0x1c38420) at =3D
>=3B >=3B../= > >src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &a= > >mp=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div&g= > >t=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>= > >=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B&l= > >t=3Bdiv>=3BThread 11 (process 96727 thread =3D
>=3B >=3B0x2b07):&l= > >t=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_= > >signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3B= > >nbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2= > > =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B= > >/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin= > > ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1ed5254=2C =3D
>=3B >=3B= > >M3_AYIbX3_m=3D3D0x1ed327c=2C M3_Bl0jv4_c=3D3D0x1ed3614=2C M3_AicXUJ_alertab= > >le=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m= > >3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x= > >0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1ed327c=2C =3D
>=3B >=3B= > >M3_Bl0jv4_c=3D3D0x1ed3614) at =3D
>=3B >=3B../src/thread/PTHREAD/Thr= > >eadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00bbdbc2= > > =3D
>=3B >=3Bin XInput__FilterXInput (M3_DSd60P_self=3D3D0x1ed5244)= > > at =3D
>=3B >=3B../src/xvbt/XInput.m3:102<=3B/div>=3B<=3Bdiv&= > >gt=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunT= > >hread (M3_BeUkBA_me=3D3D0x1c38320) at =3D
>=3B >=3B../src/thread/PTH= > >READ/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x= > >0101ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param= > >=3D3D0x1c38320) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.= > >m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>= > >=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp= > >=3B0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 10 (process 967= > >27 thread =3D
>=3B >=3B0x2a23):<=3B/div>=3B<=3Bdiv>=3B#0 &am= > >p=3Bnbsp=3B0x963916fa in select$DARWIN_EXTSN =3D
>=3B >=3B()<=3B/d= > >iv>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x01023503 in Unix__select (nfds=3D= > >3D7=2C =3D
>=3B >=3Breadfds=3D3D0x2813d54=2C writefds=3D3D0x2813d64= > >=2C exceptfds=3D3D0x2813d74=2C =3D
>=3B >=3Btimeout=3D3D0x0) at ../s= > >rc/unix/Common/UnixC.c:301<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B &= > >gt=3B&=3Bnbsp=3B0x01020970 in ThreadPThread__XIOWait__CallSelect.762 =3D= > >
>=3B >=3B(M3_Cwb5VA_nfd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C= > > M3_A4bqCj_timeout=3D3D0x0) at =3D
>=3B >=3B../src/thread/PTHREAD/Th= > >readPThread.m3:787<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x010206c= > >c =3D
>=3B >=3Bin ThreadPThread__XIOWait (M3_BXP32l_self=3D3D0x1ed52= > >04=2C =3D
>=3B >=3BM3_Cwb5VA_fd=3D3D&=3Blt=3Bunknown type&=3Bg= > >t=3B=2C M3_AicXUJ_read=3D3D1 '\001'=2C =3D
>=3B >=3BM3_CtKayy_interv= > >al=3D3D-1=2C M3_AicXUJ_alertable=3D3D0 '\0') at =3D
>=3B >=3B../src/= > >thread/PTHREAD/ThreadPThread.m3:826<=3B/div>=3B<=3Bdiv>=3B#4 &= > >=3Bnbsp=3B0x010201b4 =3D
>=3B >=3Bin SchedulerPosix__IOWait (M3_Cwb5= > >VA_fd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C =3D
>=3B >=3BM3_Ai= > >cXUJ_read=3D3D1 '\001'=2C M3_CtKayy_timeoutInterval=3D3D-1) at =3D
>= > >=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:729<=3B/div>=3B<=3Bd= > >iv>=3B#5 &=3Bnbsp=3B0x00bbf20b =3D
>=3B >=3Bin XInput__WaitForX= > >Input (M3_Bkyxhg_self=3D3D0x1ed51f4) at =3D
>=3B >=3B../src/xvbt/XIn= > >put.m3:63<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D<= > >br>>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c38250) at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>= > >=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin Thread= > >PThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c38250) at =3D
>=3B >=3B= > >../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8= > > &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/di= > >v>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
&g= > >t=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B&= > >lt=3Bdiv>=3BThread 9 (process 96727 thread =3D
>=3B >=3B0x29f3):&l= > >t=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_= > >signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3B= > >nbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2= > > =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B= > >/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin= > > ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1e3fafc=2C =3D
>=3B >=3B= > >M3_AYIbX3_m=3D3D0x1e3f9bc=2C M3_Bl0jv4_c=3D3D0x1e3f9c8=2C M3_AicXUJ_alertab= > >le=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m= > >3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x= > >0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1e3f9bc=2C =3D
>=3B >=3B= > >M3_Bl0jv4_c=3D3D0x1e3f9c8) at =3D
>=3B >=3B../src/thread/PTHREAD/Thr= > >eadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x007ab312= > > =3D
>=3B >=3Bin Zeus__AlgToViews (M3_CQpoHd_zeus=3D3D0x1e3ccfc=2C = > >=3D
>=3B >=3BM3_Ao6Rbg_initiator=3D3D0x1ecd9cc=2C M3_BMhQCx_dispatch= > >Proc=3D3D0x150e0=2C =3D
>=3B >=3BM3_Af40ku_evtArgs=3D3D0x1e08014) at= > > ../src/Zeus.m3:306<=3B/div>=3B<=3Bdiv>=3B#6 =3D
>=3B >=3B&a= > >mp=3Bnbsp=3B0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=3D3D0x1ecd9cc= > >=2C =3D
>=3B >=3BM3_DsvzJ6_style=3D3D0 '\0'=2C M3_AcxOUs_priority=3D= > >3D1=2C =3D
>=3B >=3BM3_Bd56fi_eventName=3D3D0x1d9d60=2C M3_BMhQCx_di= > >spatchProc=3D3D0x150e0=2C =3D
>=3B >=3BM3_Af40ku_evtArgs=3D3D0x1e080= > >14) at ../src/Zeus.m3:246<=3B/div>=3B<=3Bdiv>=3B#7 =3D
>=3B &g= > >t=3B&=3Bnbsp=3B0x000149a7 in BresenhamIE__ShowPixel =3D
>=3B >=3B= > >(M3_CfiRBL_initiator=3D3D0x1ecd9cc=2C M3_AcxOUs_x=3D3D3=2C M3_AcxOUs_y=3D3D= > >2=2C =3D
>=3B >=3BM3_AcxOUs_p1=3D3D6=2C M3_AcxOUs_p2=3D3D-2) at =3D<= > >br>>=3B >=3B../I386_DARWIN/BresenhamIE.m3:227<=3B/div>=3B<=3Bdiv&= > >gt=3B#8 &=3Bnbsp=3B0x000175b7 in =3D
>=3B >=3BAlgBresenham__DrawL= > >ine (M3_ECecEc_alg=3D3D0x1ecd9cc=2C M3_AcxOUs_x1=3D3D0=2C =3D
>=3B >= > >=3BM3_AcxOUs_y1=3D3D0=2C M3_AcxOUs_x2=3D3D10=2C M3_AcxOUs_y2=3D3D6) at =3D<= > >br>>=3B >=3B../src/bresenham/AlgBresenham.m3:55<=3B/div>=3B<=3Bdi= > >v>=3B#9 &=3Bnbsp=3B0x0001788f in =3D
>=3B >=3BAlgBresenham__Run= > > (M3_ECecEc_alg=3D3D0x1ecd9cc) at =3D
>=3B >=3B../src/bresenham/AlgB= > >resenham.m3:86<=3B/div>=3B<=3Bdiv>=3B#10 0x007bb729 in =3D
>= > >=3B >=3BZeusPanel__AlgThread (M3_Dijbki_ac=3D3D0x1e3fae8) at =3D
>= > >=3B >=3B../src/ZeusPanel.m3:1534<=3B/div>=3B<=3Bdiv>=3B#11 0x0101= > >f243 in =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c= > >29fd0) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<= > >=3B/div>=3B<=3Bdiv>=3B#12 0x0101ef74 in =3D
>=3B >=3BThreadPTh= > >read__ThreadBase (M3_AJWxb1_param=3D3D0x1c29fd0) at =3D
>=3B >=3B../= > >src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#13 0= > >x96373155 in =3D
>=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv= > >>=3B#14 0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B= > ><=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 8 (proce= > >ss 96727 thread =3D
>=3B >=3B0x2803):<=3B/div>=3B<=3Bdiv>=3B= > >#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >= > >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread= > >_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bn= > >bsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &= > >amp=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP= > >32l_self=3D3D0x1d8e01c=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d71fdc=2C = > >M3_Bl0jv4_c=3D3D0x1d71fe8=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B= > >'\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3B= > >div>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWa= > >it (M3_AYIbX3_m=3D3D0x1d71fdc=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1d71= > >fe8) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:266<= > >=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00e3bdf2 =3D
>=3B >= > >=3Bin Formatter__Allocate (M3_ACp9GL_t=3D3D0x1d71680=2C M3_DBiloZ_this=3D3D= > >1 =3D
>=3B >=3B'\001'=2C M3_Cwb5VA_minSize=3D3D&=3Blt=3Bunknown t= > >ype&=3Bgt=3B) at =3D
>=3B >=3B../src/formatter/Formatter.m3:440&l= > >t=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x00e3bf0a in =3D
>=3B &= > >gt=3BFormatter__Probe (M3_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D&=3B= > >lt=3Bunknown =3D
>=3B >=3Btype&=3Bgt=3B) at ../src/formatter/Form= > >atter.m3:542<=3B/div>=3B<=3Bdiv>=3B#7 =3D
>=3B >=3B&=3Bnb= > >sp=3B0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d71680=2C =3D
>= > >=3B >=3BM3_Cwb5VA_i=3D3D&=3Blt=3Bunknown type&=3Bgt=3B) at =3D
&= > >gt=3B >=3B../src/formatter/Formatter.m3:592<=3B/div>=3B<=3Bdiv>= > >=3B#8 &=3Bnbsp=3B0x00e3c2ff in =3D
>=3B >=3BFormatter__PeekOp (M3= > >_ACp9GL_t=3D3D0x1d71680=2C M3_Cwb5VA_i=3D3D&=3Blt=3Bunknown =3D
>= > >=3B >=3Btype&=3Bgt=3B) at ../src/formatter/Formatter.m3:577<=3B/div&= > >gt=3B<=3Bdiv>=3B#9 =3D
>=3B >=3B&=3Bnbsp=3B0x00e3cb25 in Form= > >atter__PrintUntil (M3_ACp9GL_t=3D3D0x1d71680=2C =3D
>=3B >=3BM3_DOUx= > >Xw_mode=3D3D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb038ce90=2C =3D
>=3B >= > >=3BM3_Cwb5VA_maxL=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_CCuODf_op= > >=3D3D0x1d72c08) at =3D
>=3B >=3B../src/formatter/Formatter.m3:708<= > >=3B/div>=3B<=3Bdiv>=3B#10 0x00e3cfc9 in =3D
>=3B >=3BFormatter= > >__PrintTop (M3_B5Nhtj_self=3D3D0x1d8e00c) at =3D
>=3B >=3B../src/for= > >matter/Formatter.m3:615<=3B/div>=3B<=3Bdiv>=3B#11 0x0101f243 in =3D= > >
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c29140) at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>= > >=3B<=3Bdiv>=3B#12 0x0101ef74 in =3D
>=3B >=3BThreadPThread__Thre= > >adBase (M3_AJWxb1_param=3D3D0x1c29140) at =3D
>=3B >=3B../src/thread= > >/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#13 0x96373155 = > >in =3D
>=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#14 = > >0x96373012 in thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv&= > >gt=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BThread 7 (process 96727 t= > >hread =3D
>=3B >=3B0x2703):<=3B/div>=3B<=3Bdiv>=3B#0 &=3B= > >nbsp=3B0x963422ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<= > >=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wa= > >it ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x= > >963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnb= > >sp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self= > >=3D3D0x1d71618=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d715ec=2C M3_Bl0jv= > >4_c=3D3D0x1d715f8=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') = > >at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>= > >=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3= > >_AYIbX3_m=3D3D0x1d715ec=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1d715f8) a= > >t =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div&= > >gt=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00e3bdf2 =3D
>=3B >=3Bin Form= > >atter__Allocate (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_DBiloZ_this=3D3D1 =3D
&= > >gt=3B >=3B'\001'=2C M3_Cwb5VA_minSize=3D3D&=3Blt=3Bunknown type&=3B= > >gt=3B) at =3D
>=3B >=3B../src/formatter/Formatter.m3:440<=3B/div&g= > >t=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x00e3bf0a in =3D
>=3B >=3BForma= > >tter__Probe (M3_ACp9GL_t=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D&=3Blt=3Bunkno= > >wn =3D
>=3B >=3Btype&=3Bgt=3B) at ../src/formatter/Formatter.m3:5= > >42<=3B/div>=3B<=3Bdiv>=3B#7 =3D
>=3B >=3B&=3Bnbsp=3B0x00e= > >3c2b8 in Formatter__Peek (M3_ACp9GL_t=3D3D0x1d70c90=2C =3D
>=3B >=3B= > >M3_Cwb5VA_i=3D3D&=3Blt=3Bunknown type&=3Bgt=3B) at =3D
>=3B >= > >=3B../src/formatter/Formatter.m3:592<=3B/div>=3B<=3Bdiv>=3B#8 &= > >=3Bnbsp=3B0x00e3c2ff in =3D
>=3B >=3BFormatter__PeekOp (M3_ACp9GL_t= > >=3D3D0x1d70c90=2C M3_Cwb5VA_i=3D3D&=3Blt=3Bunknown =3D
>=3B >=3Bt= > >ype&=3Bgt=3B) at ../src/formatter/Formatter.m3:577<=3B/div>=3B<=3B= > >div>=3B#9 =3D
>=3B >=3B&=3Bnbsp=3B0x00e3cb25 in Formatter__Prin= > >tUntil (M3_ACp9GL_t=3D3D0x1d70c90=2C =3D
>=3B >=3BM3_DOUxXw_mode=3D3= > >D1 '\001'=2C M3_ElBLGV_pos=3D3D0xb030ae90=2C =3D
>=3B >=3BM3_Cwb5VA_= > >maxL=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_CCuODf_op=3D3D0x1d72c08= > >) at =3D
>=3B >=3B../src/formatter/Formatter.m3:708<=3B/div>=3B&= > >lt=3Bdiv>=3B#10 0x00e3cfc9 in =3D
>=3B >=3BFormatter__PrintTop (M3= > >_B5Nhtj_self=3D3D0x1d71608) at =3D
>=3B >=3B../src/formatter/Formatt= > >er.m3:615<=3B/div>=3B<=3Bdiv>=3B#11 0x0101f243 in =3D
>=3B >= > >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c221e0) at =3D
>=3B &= > >gt=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>= > >=3B#12 0x0101ef74 in =3D
>=3B >=3BThreadPThread__ThreadBase (M3_AJWx= > >b1_param=3D3D0x1c221e0) at =3D
>=3B >=3B../src/thread/PTHREAD/Thread= > >PThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#13 0x96373155 in =3D
>= > >=3B >=3B_pthread_start ()<=3B/div>=3B<=3Bdiv>=3B#14 0x96373012 in= > > thread_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr= > >>=3B<=3B/div>=3B<=3Bdiv>=3BThread 6 (process 96727 thread =3D
= > >>=3B >=3B0x2603):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x9634= > >22ce in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B&l= > >t=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div= > >>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pth= > >read_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189= > > =3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d729bc= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d728b4=2C M3_Bl0jv4_c=3D3D0x1d72= > >9a0=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../src/thre= > >ad/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=3D3D0x= > >1d728b4=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1d729a0) at =3D
>=3B = > >>=3B../src/thread/PTHREAD/ThreadPThread.m3:266<=3B/div>=3B<=3Bdiv&g= > >t=3B#5 &=3Bnbsp=3B0x0073de32 =3D
>=3B >=3Bin WorkerPool__ClericAp= > >ply (M3_BSwVRC_self=3D3D0x1d729b0) at =3D
>=3B >=3B../src/WorkerPool= > >.m3:152<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D >>>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c28e10) at =3D<= > >br>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B&= > >lt=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThr= > >ead__ThreadBase (M3_AJWxb1_param=3D3D0x1c28e10) at =3D
>=3B >=3B../s= > >rc/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &am= > >p=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>= > >=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>=3B= > > >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<= > >=3Bdiv>=3BThread 5 (process 96727 thread =3D
>=3B >=3B0x2313):<= > >=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963916fa in select$DARWIN_EX= > >TSN =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0= > >x01023503 in Unix__select (nfds=3D3D4=2C =3D
>=3B >=3Breadfds=3D3D0x= > >1d74014=2C writefds=3D3D0x1d74024=2C exceptfds=3D3D0x1d74034=2C =3D
>= > >=3B >=3Btimeout=3D3D0xb0206b20) at ../src/unix/Common/UnixC.c:301<=3B/d= > >iv>=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x01020970 in T= > >hreadPThread__XIOWait__CallSelect.762 =3D
>=3B >=3B(M3_Cwb5VA_nfd=3D= > >3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_A4bqCj_timeout=3D3D0xb0206b20)= > > =3D
>=3B >=3Bat ../src/thread/PTHREAD/ThreadPThread.m3:787<=3B/di= > >v>=3B<=3Bdiv>=3B#3 =3D
>=3B >=3B&=3Bnbsp=3B0x010206a8 in Th= > >readPThread__XIOWait (M3_BXP32l_self=3D3D0x1d585bc=2C =3D
>=3B >=3BM= > >3_Cwb5VA_fd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_AicXUJ_read=3D3D= > >1 '\001'=2C =3D
>=3B >=3BM3_CtKayy_interval=3D3D1.7976931348623157e+= > >308=2C M3_AicXUJ_alertable=3D3D1 =3D
>=3B >=3B'\001') at ../src/thre= > >ad/PTHREAD/ThreadPThread.m3:823<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x010202e7 in SchedulerPosix__IOAlertWait =3D
&g= > >t=3B >=3B(M3_Cwb5VA_fd=3D3D&=3Blt=3Bunknown type&=3Bgt=3B=2C M3_Aic= > >XUJ_read=3D3D1 '\001'=2C =3D
>=3B >=3BM3_CtKayy_timeoutInterval=3D3D= > >-1) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:742<=3B= > >/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00dd3cc2 =3D
>=3B >=3Bin= > > TCPMisc__Accept=3D46rom (M3_AahksS_c=3D3D0x1d58594=2C =3D
>=3B >=3B= > >M3_DoBjMZ_peer=3D3D0xb0206cb4) at ../src/POSIX/TCP.m3:458<=3B/div>=3B&l= > >t=3Bdiv>=3B#6 =3D
>=3B >=3B&=3Bnbsp=3B0x00dd3da8 in TCP__Accept= > > (M3_AahksS_c=3D3D0x1d58594) at =3D
>=3B >=3B../src/POSIX/TCP.m3:234= > ><=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x006dbc6b in =3D
>=3B= > > >=3BLocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=3D3D0x1d585b0) at =3D<= > >br>>=3B >=3B../src/LocalObjectSpace.m3:307<=3B/div>=3B<=3Bdiv>= > >=3B#8 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunThr= > >ead (M3_BeUkBA_me=3D3D0x1c28d60) at =3D
>=3B >=3B../src/thread/PTHRE= > >AD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x01= > >01ef74 =3D
>=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D= > >3D0x1c28d60) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:= > >522<=3B/div>=3B<=3Bdiv>=3B#10 0x96373155 in =3D
>=3B >=3B_pt= > >hread_start ()<=3B/div>=3B<=3Bdiv>=3B#11 0x96373012 in thread_start= > > =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/= > >div>=3B<=3Bdiv>=3BThread 4 (process 96727 thread =3D
>=3B >=3B= > >0x2003):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x9634946e in __sem= > >wait_signal =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3B= > >nbsp=3B0x963492ef in nanosleep$UNIX2003 ()<=3B/div>=3B<=3Bdiv>=3B#2= > > =3D
>=3B >=3B&=3Bnbsp=3B0x01022cc4 in ThreadPThread__Nanosleep (= > >req=3D3D0xb0184dd0=2C =3D
>=3B >=3Brem=3D3D0xb0184dd8) at =3D
>= > >=3B >=3B../src/thread/PTHREAD/ThreadPThreadC.c:318<=3B/div>=3B<=3Bd= > >iv>=3B#3 &=3Bnbsp=3B0x0101fd7c =3D
>=3B >=3Bin ThreadPThread__X= > >Pause (M3_BXP32l_self=3D3D0x1d0ba08=2C M3_CtKayy_n=3D3D1=2C =3D
>=3B &= > >gt=3BM3_AicXUJ_alertable=3D3D0 '\0') at =3D
>=3B >=3B../src/thread/P= > >THREAD/ThreadPThread.m3:668<=3B/div>=3B<=3Bdiv>=3B#4 &=3Bnbsp=3B= > >0x0101fef3 =3D
>=3B >=3Bin Thread__Pause (M3_CtKayy_n=3D3D1) at =3D<= > >br>>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:685<=3B/div>=3B&= > >lt=3Bdiv>=3B#5 &=3Bnbsp=3B0x00a11d53 =3D
>=3B >=3Bin FileBrowse= > >rVBT__Watcher (M3_EMTrVz_cl=3D3D0x1d0ba00) at =3D
>=3B >=3B../src/le= > >go/FileBrowserVBT.m3:259<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0= > >101f243 in =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me=3D3D0= > >x1c21830) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:546= > ><=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B &g= > >t=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21830) at =3D
= > >>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>=3B<= > >=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthread_sta= > >rt ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in thread_s= > >tart =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<= > >=3B/div>=3B<=3Bdiv>=3BThread 3 (process 96727 thread =3D
>=3B &g= > >t=3B0x1f03):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in s= > >emaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv&g= > >t=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>=3B<= > >=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthread_cond= > >_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
&= > >gt=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d090d4=2C =3D >>>=3B >=3BM3_AYIbX3_m=3D3D0x1d090b0=2C M3_Bl0jv4_c=3D3D0x1d090bc=2C M3_= > >AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread/PTHREAD/T= > >hreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&a= > >mp=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d090b0=2C =3D >>>=3B >=3BM3_Bl0jv4_c=3D3D0x1d090bc) at =3D
>=3B >=3B../src/thre= > >ad/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbs= > >p=3B0x00a839e2 =3D
>=3B >=3Bin VTView__VFontCleanUpThread (M3_EMTrVz= > >_cl=3D3D0x1d090cc) at =3D
>=3B >=3B../src/vtext/VTView.m3:111<=3B/= > >div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x0101f243 in =3D
>=3B >=3B= > >ThreadPThread__RunThread (M3_BeUkBA_me=3D3D0x1c21310) at =3D
>=3B >= > >=3B../src/thread/PTHREAD/ThreadPThread.m3:546<=3B/div>=3B<=3Bdiv>= > >=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>=3B >=3Bin ThreadPThread__Thread= > >Base (M3_AJWxb1_param=3D3D0x1c21310) at =3D
>=3B >=3B../src/thread/P= > >THREAD/ThreadPThread.m3:522<=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B= > >0x96373155 =3D
>=3B >=3Bin _pthread_start ()<=3B/div>=3B<=3Bdi= > >v>=3B#9 &=3Bnbsp=3B0x96373012 in thread_start =3D
>=3B >=3B()&l= > >t=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3Bdiv>=3BT= > >hread 2 (process 96727 thread =3D
>=3B >=3B0xd07):<=3B/div>=3B&l= > >t=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce in semaphore_wait_signal_trap =3D<= > >br>>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B#1 &=3Bnbsp=3B0x963742c= > >6 in _pthread_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#2 =3D
>=3B &= > >gt=3B&=3Bnbsp=3B0x963b9539 in pthread_cond_wait ()<=3B/div>=3B<=3B= > >div>=3B#3 &=3Bnbsp=3B0x0101d189 =3D
>=3B >=3Bin ThreadPThread__= > >XWait (M3_BXP32l_self=3D3D0x1d006c8=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D= > >0x1d00688=2C M3_Bl0jv4_c=3D3D0x1d00694=2C M3_AicXUJ_alertable=3D3D0 =3D
= > >>=3B >=3B'\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226<=3B/div&= > >gt=3B<=3Bdiv>=3B#4 =3D
>=3B >=3B&=3Bnbsp=3B0x0101d823 in Thre= > >ad__Wait (M3_AYIbX3_m=3D3D0x1d00688=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D= > >0x1d00694) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:27= > >7<=3B/div>=3B<=3Bdiv>=3B#5 &=3Bnbsp=3B0x00bf33d2 =3D
>=3B &= > >gt=3Bin VBTRep__MeterMaid (M3_EMTrVz_self=3D3D0x1d006bc) at =3D
>=3B &= > >gt=3B../src/vbt/VBTRep.m3:439<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp= > >=3B0x0101f243 in =3D
>=3B >=3BThreadPThread__RunThread (M3_BeUkBA_me= > >=3D3D0x1c21390) at =3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.= > >m3:546<=3B/div>=3B<=3Bdiv>=3B#7 &=3Bnbsp=3B0x0101ef74 =3D
>= > >=3B >=3Bin ThreadPThread__ThreadBase (M3_AJWxb1_param=3D3D0x1c21390) at = > >=3D
>=3B >=3B../src/thread/PTHREAD/ThreadPThread.m3:522<=3B/div>= > >=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x96373155 =3D
>=3B >=3Bin _pthre= > >ad_start ()<=3B/div>=3B<=3Bdiv>=3B#9 &=3Bnbsp=3B0x96373012 in th= > >read_start =3D
>=3B >=3B()<=3B/div>=3B<=3Bdiv>=3B<=3Bbr>= > >=3B<=3B/div>=3B<=3Bdiv>=3BThread 1 (process 96727 thread =3D
>= > >=3B >=3B0x10b):<=3B/div>=3B<=3Bdiv>=3B#0 &=3Bnbsp=3B0x963422ce= > > in semaphore_wait_signal_trap =3D
>=3B >=3B()<=3B/div>=3B<=3B= > >div>=3B#1 &=3Bnbsp=3B0x963742c6 in _pthread_cond_wait ()<=3B/div>= > >=3B<=3Bdiv>=3B#2 =3D
>=3B >=3B&=3Bnbsp=3B0x963b9539 in pthrea= > >d_cond_wait ()<=3B/div>=3B<=3Bdiv>=3B#3 &=3Bnbsp=3B0x0101d189 = > >=3D
>=3B >=3Bin ThreadPThread__XWait (M3_BXP32l_self=3D3D0x1d0000c= > >=2C =3D
>=3B >=3BM3_AYIbX3_m=3D3D0x1d00500=2C M3_Bl0jv4_c=3D3D0x1df3= > >114=2C M3_AicXUJ_alertable=3D3D0 =3D
>=3B >=3B'\0') at ../src/thread= > >/PTHREAD/ThreadPThread.m3:226<=3B/div>=3B<=3Bdiv>=3B#4 =3D
>= > >=3B >=3B&=3Bnbsp=3B0x0101d823 in Thread__Wait (M3_AYIbX3_m=3D3D0x1d005= > >00=2C =3D
>=3B >=3BM3_Bl0jv4_c=3D3D0x1df3114) at =3D
>=3B >= > >=3B../src/thread/PTHREAD/ThreadPThread.m3:277<=3B/div>=3B<=3Bdiv>= > >=3B#5 &=3Bnbsp=3B0x00c40602 =3D
>=3B >=3Bin Trestle__AwaitDelete = > >(M3_BFdKo9_v=3D3D0x1e3a204) at =3D
>=3B >=3B../src/trestle/Trestle.m= > >3:884<=3B/div>=3B<=3Bdiv>=3B#6 &=3Bnbsp=3B0x007c09eb in =3D
&= > >gt=3B >=3BZeusPanel__Interact (M3_Bd56fi_title=3D3D0x290db0=2C =3D
>= > >=3B >=3BM3_DYb95R_path=3D3D0x1d498c0) at ../src/ZeusPanel.m3:477<=3B/di= > >v>=3B<=3Bdiv>=3B#7 =3D
>=3B >=3B&=3Bnbsp=3B0x001b0ede in Ma= > >in_M3 (M3_AcxOUs_mode=3D3D1) at =3D
>=3B >=3B../src/Main.m3:165<= > >=3B/div>=3B<=3Bdiv>=3B#8 &=3Bnbsp=3B0x0100eb1f in =3D
>=3B &g= > >t=3BRTLinker__RunMainBody (M3_DjPxE3_m=3D3D0x1d6060) at =3D
>=3B >= > >=3B../src/runtime/common/RTLinker.m3:399<=3B/div>=3B<=3Bdiv>=3B#9 &= > >amp=3Bnbsp=3B0x00002578 in =3D
>=3B >=3Bmain (argc=3D3D1=2C argv=3D3= > >D0xbfffedb8=2C envp=3D3D0xbfffedc0) at =3D
>=3B >=3B_m3main.mc:6<= > >=3B/div>=3B<=3Bdiv>=3B<=3Bbr>=3B<=3B/div>=3B<=3B/div>=3B&= > >lt=3Bdiv>=3B<=3Bbr>=3B<=3Bdiv>=3B <=3Bspan =3D
>=3B >=3B= > >class=3D3D"Apple-style-span" style=3D3D"font-size: 12px=3B ">=3B<=3Bdiv= > > =3D
>=3B >=3Bstyle=3D3D"word-wrap: break-word=3B -webkit-nbsp-mode:= > > space=3B =3D
>=3B >=3B-webkit-line-break: after-white-space=3B ">= > >=3B<=3Bspan class=3D3D"Apple-style-span" =3D
>=3B >=3Bstyle=3D3D"b= > >order-collapse: separate=3B -webkit-border-horizontal-spacing: =3D
>= > >=3B >=3B0px=3B -webkit-border-vertical-spacing: 0px=3B color: rgb(0=2C 0= > >=2C 0)=3B =3D
>=3B >=3Bfont-family: Helvetica=3B font-size: 12px=3B = > >font-style: normal=3B =3D
>=3B >=3Bfont-variant: normal=3B font-weig= > >ht: normal=3B letter-spacing: normal=3B =3D
>=3B >=3Bline-height: no= > >rmal=3B -webkit-text-decorations-in-effect: none=3B =3D
>=3B >=3Btex= > >t-indent: 0px=3B -webkit-text-size-adjust: auto=3B text-transform: none=3B = > >=3D
>=3B >=3Borphans: 2=3B white-space: normal=3B widows: 2=3B word-= > >spacing: 0px=3B ">=3B<=3Bdiv =3D
>=3B >=3Bstyle=3D3D"word-wrap: = > >break-word=3B -webkit-nbsp-mode: space=3B =3D
>=3B >=3B-webkit-line-= > >break: after-white-space=3B ">=3B<=3Bspan class=3D3D"Apple-style-span" = > >=3D
>=3B >=3Bstyle=3D3D"border-collapse: separate=3B -webkit-border-= > >horizontal-spacing: =3D
>=3B >=3B0px=3B -webkit-border-vertical-spac= > >ing: 0px=3B color: rgb(0=2C 0=2C 0)=3B =3D
>=3B >=3Bfont-family: Hel= > >vetica=3B font-size: 12px=3B font-style: normal=3B =3D
>=3B >=3Bfont= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B =3D >>>=3B >=3Bline-height: normal=3B -webkit-text-decorations-in-effect: no= > >ne=3B =3D
>=3B >=3Btext-indent: 0px=3B -webkit-text-size-adjust: aut= > >o=3B text-transform: none=3B =3D
>=3B >=3Borphans: 2=3B white-space:= > > normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
>= > >=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separate= > >=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webkit-b= > >order-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-sp= > >an" style=3D3D"border-collapse: separate=3B =3D
>=3B >=3B-webkit-bor= > >der-horizontal-spacing: 0px=3B -webkit-border-vertical-spacing: =3D
>= > >=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-= > >size: 12px=3B =3D
>=3B >=3Bfont-style: normal=3B font-variant: norma= > >l=3B font-weight: normal=3B =3D
>=3B >=3Bletter-spacing: normal=3B l= > >ine-height: normal=3B =3D
>=3B >=3B-webkit-text-decorations-in-effec= > >t: none=3B text-indent: 0px=3B =3D
>=3B >=3B-webkit-text-size-adjust= > >: auto=3B text-transform: none=3B orphans: 2=3B =3D
>=3B >=3Bwhite-s= > >pace: normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
= > >>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separ= > >ate=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webki= > >t-border-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont= > >-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-sp= > >an" style=3D3D"border-collapse: separate=3B =3D
>=3B >=3B-webkit-bor= > >der-horizontal-spacing: 0px=3B -webkit-border-vertical-spacing: =3D
>= > >=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-= > >size: 12px=3B =3D
>=3B >=3Bfont-style: normal=3B font-variant: norma= > >l=3B font-weight: normal=3B =3D
>=3B >=3Bletter-spacing: normal=3B l= > >ine-height: normal=3B =3D
>=3B >=3B-webkit-text-decorations-in-effec= > >t: none=3B text-indent: 0px=3B =3D
>=3B >=3B-webkit-text-size-adjust= > >: auto=3B text-transform: none=3B orphans: 2=3B =3D
>=3B >=3Bwhite-s= > >pace: normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
= > >>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separ= > >ate=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webki= > >t-border-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont= > >-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-sp= > >an" style=3D3D"border-collapse: separate=3B =3D
>=3B >=3B-webkit-bor= > >der-horizontal-spacing: 0px=3B -webkit-border-vertical-spacing: =3D
>= > >=3B >=3B0px=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-= > >size: 12px=3B =3D
>=3B >=3Bfont-style: normal=3B font-variant: norma= > >l=3B font-weight: normal=3B =3D
>=3B >=3Bletter-spacing: normal=3B l= > >ine-height: normal=3B =3D
>=3B >=3B-webkit-text-decorations-in-effec= > >t: none=3B text-indent: 0px=3B =3D
>=3B >=3B-webkit-text-size-adjust= > >: auto=3B text-transform: none=3B orphans: 2=3B =3D
>=3B >=3Bwhite-s= > >pace: normal=3B widows: 2=3B word-spacing: 0px=3B ">=3B<=3Bspan =3D
= > >>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"border-collapse: separ= > >ate=3B =3D
>=3B >=3B-webkit-border-horizontal-spacing: 0px=3B -webki= > >t-border-vertical-spacing: =3D
>=3B >=3B0px=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: 12px=3B =3D
>=3B >=3Bfont= > >-style: normal=3B font-variant: normal=3B font-weight: normal=3B =3D
>= > >=3B >=3Bletter-spacing: normal=3B line-height: normal=3B =3D
>=3B &g= > >t=3B-webkit-text-decorations-in-effect: none=3B text-indent: 0px=3B =3D
= > >>=3B >=3B-webkit-text-size-adjust: auto=3B text-transform: none=3B orph= > >ans: 2=3B =3D
>=3B >=3Bwhite-space: normal=3B widows: 2=3B word-spac= > >ing: 0px=3B ">=3B<=3Bdiv>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D= > >"Apple-style-span" color=3D3D"#0000FF">=3B<=3Bfont =3D
>=3B >=3B= > >class=3D3D"Apple-style-span" face=3D3D"Gill Sans">=3B<=3Bspan =3D
&g= > >t=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255= > >)=3B font-family: =3D
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan clas= > >s=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C =3D
>=3B >=3B0= > >=2C 255)=3B font-family: 'Gill Sans'=3B ">=3BAntony =3D
>=3B >=3BH= > >osking<=3B/span>=3B<=3B/span>=3B<=3B/font>=3B<=3B/font>=3B&= > >lt=3Bfont class=3D3D"Apple-style-span" =3D
>=3B >=3Bface=3D3D"Gill S= > >ans">=3B<=3Bspan class=3D3D"Apple-style-span" style=3D3D"font-family: = > >=3D
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan class=3D3D"Apple-style= > >-span" style=3D3D"font-family: =3D
>=3B >=3B'Gill Sans'=3B ">=3B&l= > >t=3Bspan class=3D3D"Apple-converted-space">=3B&=3Bnbsp=3B<=3B/span&g= > >t=3B|<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-converted-space">=3B= > >&=3Bnbsp=3B<=3B/span>=3B<=3B/span>=3B<=3B/span>=3B<=3Bspan= > > =3D
>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"font-family: '= > >Gill Sans'=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style-= > >span" style=3D3D"font-family: 'Gill Sans'=3B =3D
>=3B >=3B">=3BAss= > >ociate Professor<=3B/span>=3B<=3B/span>=3B<=3Bspan class=3D3D"App= > >le-style-span" =3D
>=3B >=3Bstyle=3D3D"font-family: 'Gill Sans'=3B "= > >>=3B<=3Bspan class=3D3D"Apple-style-span" =3D
>=3B >=3Bstyle=3D3= > >D"font-family: 'Gill Sans'=3B ">=3B&=3Bnbsp=3B| Computer Science | Pur= > >due =3D
>=3B >=3BUniversity<=3B/span>=3B<=3B/span>=3B<=3B/= > >font>=3B<=3B/div>=3B<=3Bdiv>=3B<=3Bfont class=3D3D"Apple-style-= > >span"=3D
>=3B >=3B face=3D3D"GillSans-Light">=3B<=3Bspan class= > >=3D3D"Apple-style-span" =3D
>=3B >=3Bstyle=3D3D"font-family: GillSan= > >s-Light=3B ">=3B305 N. University Street | West =3D
>=3B >=3BLafay= > >ette | IN 47907 | USA<=3B/span>=3B<=3B/font>=3B<=3B/div>=3B<= > >=3Bdiv>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" col= > >or=3D3D"#0000FF" face=3D3D"Gill Sans">=3B<=3Bspan =3D
>=3B >=3Bc= > >lass=3D3D"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B font-fa= > >mily: =3D
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan class=3D3D"Apple= > >-style-span" style=3D3D"color: rgb(0=2C =3D
>=3B >=3B0=2C 255)=3B fo= > >nt-family: 'Gill Sans'=3B ">=3BOffice<=3B/span>=3B<=3B/span>=3B&l= > >t=3B/font>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" = > >face=3D3D"GillSans-Light">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Ap= > >ple-style-span" style=3D3D"font-family: GillSans-Light=3B ">=3B<=3Bspan= > > =3D
>=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"font-family: G= > >illSans-Light=3B =3D
>=3B >=3B">=3B&=3Bnbsp=3B+1 765 494 6001 |= > ><=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-converted-space">=3B&= > >=3Bnbsp=3B<=3B/span>=3B<=3B/span>=3B<=3B/span>=3B<=3B/font>= > >=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" color=3D3D"#= > >0000FF" face=3D3D"Gill Sans">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D= > >"Apple-style-span" style=3D3D"color: rgb(0=2C 0=2C 255)=3B font-family: =3D= > >
>=3B >=3B'Gill Sans'=3B ">=3B<=3Bspan class=3D3D"Apple-style-sp= > >an" style=3D3D"color: rgb(0=2C =3D
>=3B >=3B0=2C 255)=3B font-family= > >: 'Gill Sans'=3B ">=3BMobile<=3B/span>=3B<=3B/span>=3B<=3B/font= > >>=3B<=3Bfont =3D
>=3B >=3Bclass=3D3D"Apple-style-span" face=3D3D= > >"GillSans-Light">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-style= > >-span" style=3D3D"font-family: GillSans-Light=3B ">=3B<=3Bspan =3D
&= > >gt=3B >=3Bclass=3D3D"Apple-style-span" style=3D3D"font-family: GillSans-L= > >ight=3B ">=3B<=3Bspan =3D
>=3B >=3Bclass=3D3D"Apple-converted-sp= > >ace">=3B&=3Bnbsp=3B<=3B/span>=3B+1 765 427 =3D
>=3B >=3B548= > >4<=3B/span>=3B<=3B/span>=3B<=3B/font>=3B<=3B/div>=3B<=3Bd= > >iv>=3B<=3Bfont class=3D3D"Apple-style-span" =3D
>=3B >=3Bface=3D= > >3D"GillSans-Light">=3B<=3Bbr =3D
>=3B >=3Bclass=3D3D"khtml-block= > >-placeholder">=3B<=3B/font>=3B<=3B/div>=3B<=3B/span>=3B<=3B= > >/span>=3B<=3B/span>=3B<=3B/span=3D
>=3B >=3B>=3B<=3B/spa= > >n>=3B<=3B/span>=3B<=3B/span>=3B<=3Bbr =3D
>=3B >=3Bclass= > >=3D3D"Apple-interchange-newline">=3B<=3B/span>=3B<=3B/div>=3B<= > >=3B/span>=3B<=3B/div>=3B<=3B/span>=3B<=3Bbr =3D
>=3B >= > >=3Bclass=3D3D"Apple-interchange-newline">=3B <=3B/div>=3B<=3Bbr>= > >=3B<=3Bdiv>=3B<=3Bdiv>=3BOn 6 Sep 2009=2C =3D
>=3B >=3Bat 23= > >:18=2C Jay K wrote:<=3B/div>=3B<=3Bbr =3D
>=3B >=3Bclass=3D3D"= > >Apple-interchange-newline">=3B<=3Bblockquote =3D
>=3B >=3Btype= > >=3D3D"cite">=3B<=3Bdiv>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B&= > >lt=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3B= > >br>=3B[was truncated =3D
>=3B >=3Bagain!]<=3Bbr>=3B<=3Bbr>= > >=3BPPC_DARWIN 5.2.6 Juno on x86 sometimes hangs=2C sometimes =3D
>=3B = > >>=3Bruns out of stack<=3B/div>=3B<=3B/blockquote>=3B<=3B/div>= > >=3B<=3Bbr>=3B<=3B/div>=3B<=3B/body>=3B<=3B/html>=3B=3D
&= > >gt=3B >=3B
>=3B >=3B--Apple-Mail-13--794937978--
> >= > > > >--_d2a2b05c-dd99-4149-b3de-8867976ffb79_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 13:17:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 11:17:48 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: Can a semaphore be reasonably synthesized from working pthreads constructs? At least to try eliminating this variable? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 10:07:16 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) > What is different about Darwin? > Well obviously the same world suspend works. Can we use the portable way instead?? sem_init returns ENOSYS on Darwin, so no. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 08:16:41 +0000 Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 16:09:25 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 10:09:25 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote: > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 16:44:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 10:44:23 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: <07AC4F22-8D60-4A08-AF4B-5B058B1FE72B@cs.purdue.edu> On 8 Sep 2009, at 04:50, Jay K wrote: > Hm. > - Making SameHost FALSE on Linux didn't induce hang. > - I'm seeing Juno often "hang" for a few seconds without displaying > anything, but I wait, and then it comes up fine. And then the next > run works ok. I see both behaviors often. This is with the stack > size code removed from ThreadPThreadC.c. I'll try restoring it too. > > What is different about Darwin? > Well obviously the same world suspend works. Can we use the portable > way instead?? > I realize the portable way probably isn't as good? This is not a problem with the stop-the-world mechanisms. They work fine. I've stress-tested them heavily and not seen a problem in a long time. My recent changes just made it clearer what was going on (and fixed the bug I introduced last week that you ended up backing out). If you look at the stack traces, no thread is in stop-the-world code. I have a sneaking recollection of needing to configure some property of my X server on Darwin, way back when. I've tried searching the old mail logs to see if I can dig up a reference but the Zope archives are no longer on Elegosoft.com. What to do? > > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other > problems) > Date: Tue, 8 Sep 2009 08:16:41 +0000 > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 16:47:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 10:47:18 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: It is not a problem with the thread stop-the-world suspension code. No thread is in that path at the time of the hang. They are all quietly waiting for something to happen. Clearly they've missed something. I have one thread that looks suspicious sitting inside a call to Formatter__Flush. Clearly the consumer hasn't responded so it is quietly waiting. More investigation needed. On 8 Sep 2009, at 07:17, Jay K wrote: > Can a semaphore be reasonably synthesized from working pthreads > constructs? > At least to try eliminating this variable? > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 8 Sep 2009 10:07:16 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > > What is different about Darwin? > > Well obviously the same world suspend works. Can we use the > portable way instead?? > > sem_init returns ENOSYS on Darwin, so no. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other > problems) > Date: Tue, 8 Sep 2009 08:16:41 +0000 > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 17:51:36 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Tue, 8 Sep 2009 08:51:36 -0700 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> Message-ID: <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/ XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: > What did you change? I wonder... > > To get things to work on Darwin I used to have to do "xhosts +" and > set "DISPLAY=:0.0". Is this no longer the case? > > On 8 Sep 2009, at 04:16, Jay K wrote: > >> Here is a wild wild guess: >> One thing unusual to Trestle on Darwin, I think, is that it always >> appears that X client and X server are different machines. >> Well, er, um, that is how I changed it to be when it was otherwise >> always going to fail. >> How did it work previously? However it did work, if those >> conditions are still present, it still has a chance of working. >> >> Coincidentally or not, the formsedit crashes I have reported are >> all/mostly with a separate X client and server. >> >> I'll see if I can induce a hang in the otherwise working LINUXLIBC6 >> by twiddling with this. >> >> The specific change I made in Darwin was in the IsSameHost code. >> Where it would previously hit an unhandled exception, I have it >> return FALSE. >> I'm pretty sure that using XSharedMemory is "just" an optimization, >> albeit a very good one. >> >> I looked at little at what the Juno threads are doing..and it >> doesn't really have to do with gui code. >> libm3/"formatter" is a usual producer/consumer thingy, signal when >> queue is empty or nonempty. >> We /might/ be able to demonstrate this hang without any of Trestle >> in the picture. Might. >> >> I haven't looked at Mentor but it looks more complicated below. >> I'll also see if the Juno NT crashes are gone. >> And I'll raise the stack but stack overflow is just another wild >> guess, right? >> >> On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack >> overflow. >> I raised the stack piecemeal up to 32meg, still overflow. At 64meg >> it ran out of memory. >> >> - Jay >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 8 Sep 2009 02:09:28 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other >> problems) >> >> Here's the hang backtrace for mentor. Again, all appears normal, >> except that all the threads are paused or waiting, which is >> suspicious. I'm stumped for now. >> >> Thread 21 (process 96727 thread 0x7403): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, >> rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:668 >> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:685 >> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) >> at ../src/xvbt/XClientF.m3:105 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 20 (process 96727 thread 0x7103): >> #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:319 >> #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, >> M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') >> at ../src/thread/PTHREAD/ThreadPThread.m3:669 >> #2 0x01020024 in Thread__AlertPause >> (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:699 >> #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, >> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) >> at ../src/Animate.m3:71 >> #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, >> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >> #5 0x008921f9 in GraphVBT__AnimateGraph >> (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../ >> src/GraphVBT.m3:656 >> #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, >> M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) >> at ../src/bresenham/ViewError.m3:548 >> #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, >> M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 >> #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ >> src/Zeus.m3:331 >> #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #10 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #11 0x96373155 in _pthread_start () >> #12 0x96373012 in thread_start () >> >> Thread 19 (process 96727 thread 0x5d07): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, >> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >> M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, >> M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ >> src/Zeus.m3:328 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 18 (process 96727 thread 0x700b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, >> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >> M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, >> M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 >> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ >> src/Zeus.m3:328 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 17 (process 96727 thread 0x6e03): >> #0 0x963493dc in _pthread_testcancel () >> #1 0x96349275 in nanosleep$UNIX2003 () >> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, >> rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, >> M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >> PTHREAD/ThreadPThread.m3:668 >> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:685 >> #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ >> src/vtext/VTCaret.m3:149 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 16 (process 96727 thread 0x435b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, >> M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, >> M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) >> at ../src/ZeusPanel.m3:1425 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 15 (process 96727 thread 0x420b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) >> at ../src/View.m3:74 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 14 (process 96727 thread 0x4103): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) >> at ../src/View.m3:74 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 13 (process 96727 thread 0x4003): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) >> at ../src/View.m3:74 >> #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #8 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #9 0x96373155 in _pthread_start () >> #10 0x96373012 in thread_start () >> >> Thread 12 (process 96727 thread 0x2e03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, >> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >> M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) >> at ../src/xvbt/XMessenger.m3:69 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 11 (process 96727 thread 0x2b07): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, >> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >> M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) >> at ../src/xvbt/XInput.m3:102 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 10 (process 96727 thread 0x2a23): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, >> writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/ >> unix/Common/UnixC.c:301 >> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ >> thread/PTHREAD/ThreadPThread.m3:787 >> #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >> M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >> PTHREAD/ThreadPThread.m3:826 >> #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=> type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ >> src/thread/PTHREAD/ThreadPThread.m3:729 >> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) >> at ../src/xvbt/XInput.m3:63 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 9 (process 96727 thread 0x29f3): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, >> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, >> M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, >> M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 >> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, >> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 >> #7 0x000149a7 in BresenhamIE__ShowPixel >> (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, >> M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 >> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, >> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >> at ../src/bresenham/AlgBresenham.m3:55 >> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ >> src/bresenham/AlgBresenham.m3:86 >> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) >> at ../src/ZeusPanel.m3:1534 >> #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #12 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 8 (process 96727 thread 0x2803): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, >> M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, >> M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >> src/formatter/Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, >> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >> formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) >> at ../src/formatter/Formatter.m3:615 >> #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #12 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 7 (process 96727 thread 0x2703): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, >> M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, >> M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, >> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >> src/formatter/Formatter.m3:440 >> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, >> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, >> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, >> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >> formatter/Formatter.m3:708 >> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) >> at ../src/formatter/Formatter.m3:615 >> #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #12 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #13 0x96373155 in _pthread_start () >> #14 0x96373012 in thread_start () >> >> Thread 6 (process 96727 thread 0x2603): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, >> M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, >> M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >> #5 0x0073de32 in WorkerPool__ClericApply >> (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 5 (process 96727 thread 0x2313): >> #0 0x963916fa in select$DARWIN_EXTSN () >> #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, >> writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ >> src/unix/Common/UnixC.c:301 >> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ >> src/thread/PTHREAD/ThreadPThread.m3:787 >> #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, >> M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >> M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 >> '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 >> #4 0x010202e7 in SchedulerPosix__IOAlertWait >> (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >> M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:742 >> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, >> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ >> POSIX/TCP.m3:234 >> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >> (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 >> #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #9 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #10 0x96373155 in _pthread_start () >> #11 0x96373012 in thread_start () >> >> Thread 4 (process 96727 thread 0x2003): >> #0 0x9634946e in __semwait_signal () >> #1 0x963492ef in nanosleep$UNIX2003 () >> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, >> rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, >> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >> ThreadPThread.m3:668 >> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >> PTHREAD/ThreadPThread.m3:685 >> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) >> at ../src/lego/FileBrowserVBT.m3:259 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 3 (process 96727 thread 0x1f03): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, >> M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, >> M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00a839e2 in VTView__VFontCleanUpThread >> (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 2 (process 96727 thread 0xd07): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, >> M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, >> M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) >> at ../src/vbt/VBTRep.m3:439 >> #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) >> at ../src/thread/PTHREAD/ThreadPThread.m3:546 >> #7 0x0101ef74 in ThreadPThread__ThreadBase >> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >> ThreadPThread.m3:522 >> #8 0x96373155 in _pthread_start () >> #9 0x96373012 in thread_start () >> >> Thread 1 (process 96727 thread 0x10b): >> #0 0x963422ce in semaphore_wait_signal_trap () >> #1 0x963742c6 in _pthread_cond_wait () >> #2 0x963b9539 in pthread_cond_wait () >> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, >> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 >> '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 >> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >> M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) >> at ../src/trestle/Trestle.m3:884 >> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >> M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 >> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >> #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) >> at ../src/runtime/common/RTLinker.m3:399 >> #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) >> at _m3main.mc:6 >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 6 Sep 2009, at 23:18, Jay K wrote: >> >> >> >> >> >> >> >> >> >> >> [was truncated again!] >> >> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of >> stack >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 18:03:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 12:03:05 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> Message-ID: <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote: > That works? $Display gets set to something random looking by > default, an actual file, I don't change it. If what you do works my > change probably does not affect. See the function SameHost in m3-ui/ > ui/xvbt/XSharedMemory.i3. I added the code to predict if the network > stuff will succeed or fail since for me it always failed and was > fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. > > - Jay (phone) > > On Sep 8, 2009, at 7:09 AM, Tony Hosking > wrote: > >> What did you change? I wonder... >> >> To get things to work on Darwin I used to have to do "xhosts +" and >> set "DISPLAY=:0.0". Is this no longer the case? >> >> On 8 Sep 2009, at 04:16, Jay K wrote: >> >>> Here is a wild wild guess: >>> One thing unusual to Trestle on Darwin, I think, is that it >>> always appears that X client and X server are different machines. >>> Well, er, um, that is how I changed it to be when it was >>> otherwise always going to fail. >>> How did it work previously? However it did work, if those >>> conditions are still present, it still has a chance of working. >>> >>> Coincidentally or not, the formsedit crashes I have reported are >>> all/mostly with a separate X client and server. >>> >>> I'll see if I can induce a hang in the otherwise working >>> LINUXLIBC6 by twiddling with this. >>> >>> The specific change I made in Darwin was in the IsSameHost code. >>> Where it would previously hit an unhandled exception, I have it >>> return FALSE. >>> I'm pretty sure that using XSharedMemory is "just" an >>> optimization, albeit a very good one. >>> >>> I looked at little at what the Juno threads are doing..and it >>> doesn't really have to do with gui code. >>> libm3/"formatter" is a usual producer/consumer thingy, signal when >>> queue is empty or nonempty. >>> We /might/ be able to demonstrate this hang without any of Trestle >>> in the picture. Might. >>> >>> I haven't looked at Mentor but it looks more complicated below. >>> I'll also see if the Juno NT crashes are gone. >>> And I'll raise the stack but stack overflow is just another wild >>> guess, right? >>> >>> On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack >>> overflow. >>> I raised the stack piecemeal up to 32meg, still overflow. At 64meg >>> it ran out of memory. >>> >>> - Jay >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Tue, 8 Sep 2009 02:09:28 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other >>> problems) >>> >>> Here's the hang backtrace for mentor. Again, all appears normal, >>> except that all the threads are paused or waiting, which is >>> suspicious. I'm stumped for now. >>> >>> Thread 21 (process 96727 thread 0x7403): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, >>> rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:668 >>> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:685 >>> #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) >>> at ../src/xvbt/XClientF.m3:105 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 20 (process 96727 thread 0x7103): >>> #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:319 >>> #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, >>> M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') >>> at ../src/thread/PTHREAD/ThreadPThread.m3:669 >>> #2 0x01020024 in Thread__AlertPause >>> (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:699 >>> #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, >>> M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) >>> at ../src/Animate.m3:71 >>> #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, >>> M3_BUucNs_duration=1) at ../src/MGV.m3:313 >>> #5 0x008921f9 in GraphVBT__AnimateGraph >>> (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../ >>> src/GraphVBT.m3:656 >>> #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, >>> M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) >>> at ../src/bresenham/ViewError.m3:548 >>> #7 0x0001529a in BresenhamIE__OEDispatcher >>> (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/ >>> BresenhamIE.m3:101 >>> #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) >>> at ../src/Zeus.m3:331 >>> #9 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #10 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #11 0x96373155 in _pthread_start () >>> #12 0x96373012 in thread_start () >>> >>> Thread 19 (process 96727 thread 0x5d07): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, >>> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >>> M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep >>> (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/ >>> Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) >>> at ../src/Zeus.m3:328 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 18 (process 96727 thread 0x700b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, >>> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, >>> M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x007ab7f2 in Zeus__WakeZeusAndSleep >>> (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/ >>> Zeus.m3:361 >>> #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) >>> at ../src/Zeus.m3:328 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 17 (process 96727 thread 0x6e03): >>> #0 0x963493dc in _pthread_testcancel () >>> #1 0x96349275 in nanosleep$UNIX2003 () >>> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, >>> rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, >>> M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:668 >>> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:685 >>> #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ >>> src/vtext/VTCaret.m3:149 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 16 (process 96727 thread 0x435b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, >>> M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, >>> M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) >>> at ../src/ZeusPanel.m3:1425 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 15 (process 96727 thread 0x420b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) >>> at ../src/View.m3:74 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 14 (process 96727 thread 0x4103): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) >>> at ../src/View.m3:74 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 13 (process 96727 thread 0x4003): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) >>> at ../src/View.m3:74 >>> #7 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #8 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #9 0x96373155 in _pthread_start () >>> #10 0x96373012 in thread_start () >>> >>> Thread 12 (process 96727 thread 0x2e03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, >>> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >>> M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) >>> at ../src/xvbt/XMessenger.m3:69 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 11 (process 96727 thread 0x2b07): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, >>> M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, >>> M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) >>> at ../src/xvbt/XInput.m3:102 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 10 (process 96727 thread 0x2a23): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, >>> writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/ >>> unix/Common/UnixC.c:301 >>> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ >>> thread/PTHREAD/ThreadPThread.m3:787 >>> #3 0x010206cc in ThreadPThread__XIOWait >>> (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:826 >>> #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=>> type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) >>> at ../src/thread/PTHREAD/ThreadPThread.m3:729 >>> #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) >>> at ../src/xvbt/XInput.m3:63 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 9 (process 96727 thread 0x29f3): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, >>> M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, >>> M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, >>> M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 >>> #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, >>> M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, >>> M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, >>> M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 >>> #7 0x000149a7 in BresenhamIE__ShowPixel >>> (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, >>> M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/ >>> BresenhamIE.m3:227 >>> #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, >>> M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) >>> at ../src/bresenham/AlgBresenham.m3:55 >>> #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) >>> at ../src/bresenham/AlgBresenham.m3:86 >>> #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) >>> at ../src/ZeusPanel.m3:1534 >>> #11 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #12 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 8 (process 96727 thread 0x2803): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, >>> M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, >>> M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >>> src/formatter/Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, >>> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >>> formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #12 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 7 (process 96727 thread 0x2703): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, >>> M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, >>> M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, >>> M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../ >>> src/formatter/Formatter.m3:440 >>> #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 >>> #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 >>> #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, >>> M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 >>> #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, >>> M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, >>> M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ >>> formatter/Formatter.m3:708 >>> #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) >>> at ../src/formatter/Formatter.m3:615 >>> #11 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #12 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #13 0x96373155 in _pthread_start () >>> #14 0x96373012 in thread_start () >>> >>> Thread 6 (process 96727 thread 0x2603): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, >>> M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, >>> M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, >>> M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 >>> #5 0x0073de32 in WorkerPool__ClericApply >>> (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 5 (process 96727 thread 0x2313): >>> #0 0x963916fa in select$DARWIN_EXTSN () >>> #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, >>> writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ >>> src/unix/Common/UnixC.c:301 >>> #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 >>> (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ >>> src/thread/PTHREAD/ThreadPThread.m3:787 >>> #3 0x010206a8 in ThreadPThread__XIOWait >>> (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, >>> M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e >>> +308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:823 >>> #4 0x010202e7 in SchedulerPosix__IOAlertWait >>> (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', >>> M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:742 >>> #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, >>> M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 >>> #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ >>> POSIX/TCP.m3:234 >>> #7 0x006dbc6b in LocalObjectSpace__SpaceAccept >>> (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 >>> #8 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #9 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #10 0x96373155 in _pthread_start () >>> #11 0x96373012 in thread_start () >>> >>> Thread 4 (process 96727 thread 0x2003): >>> #0 0x9634946e in __semwait_signal () >>> #1 0x963492ef in nanosleep$UNIX2003 () >>> #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, >>> rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 >>> #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, >>> M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:668 >>> #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ >>> PTHREAD/ThreadPThread.m3:685 >>> #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) >>> at ../src/lego/FileBrowserVBT.m3:259 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 3 (process 96727 thread 0x1f03): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, >>> M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, >>> M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00a839e2 in VTView__VFontCleanUpThread >>> (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 2 (process 96727 thread 0xd07): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, >>> M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, >>> M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) >>> at ../src/vbt/VBTRep.m3:439 >>> #6 0x0101f243 in ThreadPThread__RunThread >>> (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:546 >>> #7 0x0101ef74 in ThreadPThread__ThreadBase >>> (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:522 >>> #8 0x96373155 in _pthread_start () >>> #9 0x96373012 in thread_start () >>> >>> Thread 1 (process 96727 thread 0x10b): >>> #0 0x963422ce in semaphore_wait_signal_trap () >>> #1 0x963742c6 in _pthread_cond_wait () >>> #2 0x963b9539 in pthread_cond_wait () >>> #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, >>> M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, >>> M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ >>> ThreadPThread.m3:226 >>> #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, >>> M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 >>> #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) >>> at ../src/trestle/Trestle.m3:884 >>> #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, >>> M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 >>> #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 >>> #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) >>> at ../src/runtime/common/RTLinker.m3:399 >>> #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) >>> at _m3main.mc:6 >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 6 Sep 2009, at 23:18, Jay K wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [was truncated again!] >>> >>> PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out >>> of stack >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 18:05:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 16:05:48 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: Ok I tried Display=:0.0 and xhost +, it works, same hang. You don't actually have to do that though, at least on 10.5. DISPLAY is set to some magic and X is started up on-demand as needed. Except for that SameHost problem.. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 12:03:05 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote:That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote:Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 18:09:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 16:09:21 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO self.waitCond should be c or self.waitingOn maybe?? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 16:05:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Ok I tried Display=:0.0 and xhost +, it works, same hang. You don't actually have to do that though, at least on 10.5. DISPLAY is set to some magic and X is started up on-demand as needed. Except for that SameHost problem.. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 12:03:05 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote:That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote:Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 18:11:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 12:11:23 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: Nope. I think we need to be more careful about the mutex. Considering the options right now... On 8 Sep 2009, at 12:09, Jay K wrote: > WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO > > > self.waitCond should be c or self.waitingOn maybe?? > > - Jay > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 8 Sep 2009 16:05:48 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Ok I tried Display=:0.0 and xhost +, it works, same hang. > You don't actually have to do that though, at least on 10.5. > DISPLAY is set to some magic and X is started up on-demand as needed. > Except for that SameHost problem.. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 12:03:05 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote: > > That works? $Display gets set to something random looking by > default, an actual file, I don't change it. If what you do works my > change probably does not affect. See the function SameHost in m3-ui/ > ui/xvbt/XSharedMemory.i3. I added the code to predict if the network > stuff will succeed or fail since for me it always failed and was > fatal. > > Yes, it works for me. > > PS I think I have found the problem: a thread not waking from a call > to wait, even though its condition has been signalled. A > longstanding bug inside XWait I think... Sigh. > > > - Jay (phone) > > On Sep 8, 2009, at 7:09 AM, Tony Hosking > wrote: > > What did you change? I wonder... > > To get things to work on Darwin I used to have to do "xhosts +" and > set "DISPLAY=:0.0". Is this no longer the case? > > On 8 Sep 2009, at 04:16, Jay K wrote: > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 8 18:13:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 8 Sep 2009 16:13:36 +0000 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: er..I don't get the waitCond vs. waitingOn. Have to study it more or just wait for your fix. Maybe they are meant to be the same??? I don't know. (To be clear, with this level of uncertainty, I'm certainly not changing it.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other problems) Date: Tue, 8 Sep 2009 16:09:21 +0000 WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO self.waitCond should be c or self.waitingOn maybe?? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 8 Sep 2009 16:05:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Ok I tried Display=:0.0 and xhost +, it works, same hang. You don't actually have to do that though, at least on 10.5. DISPLAY is set to some magic and X is started up on-demand as needed. Except for that SameHost problem.. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 12:03:05 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote:That works? $Display gets set to something random looking by default, an actual file, I don't change it. If what you do works my change probably does not affect. See the function SameHost in m3-ui/ui/xvbt/XSharedMemory.i3. I added the code to predict if the network stuff will succeed or fail since for me it always failed and was fatal. Yes, it works for me. PS I think I have found the problem: a thread not waking from a call to wait, even though its condition has been signalled. A longstanding bug inside XWait I think... Sigh. - Jay (phone) On Sep 8, 2009, at 7:09 AM, Tony Hosking wrote: What did you change? I wonder... To get things to work on Darwin I used to have to do "xhosts +" and set "DISPLAY=:0.0". Is this no longer the case? On 8 Sep 2009, at 04:16, Jay K wrote:Here is a wild wild guess: One thing unusual to Trestle on Darwin, I think, is that it always appears that X client and X server are different machines. Well, er, um, that is how I changed it to be when it was otherwise always going to fail. How did it work previously? However it did work, if those conditions are still present, it still has a chance of working. Coincidentally or not, the formsedit crashes I have reported are all/mostly with a separate X client and server. I'll see if I can induce a hang in the otherwise working LINUXLIBC6 by twiddling with this. The specific change I made in Darwin was in the IsSameHost code. Where it would previously hit an unhandled exception, I have it return FALSE. I'm pretty sure that using XSharedMemory is "just" an optimization, albeit a very good one. I looked at little at what the Juno threads are doing..and it doesn't really have to do with gui code. libm3/"formatter" is a usual producer/consumer thingy, signal when queue is empty or nonempty. We /might/ be able to demonstrate this hang without any of Trestle in the picture. Might. I haven't looked at Mentor but it looks more complicated below. I'll also see if the Juno NT crashes are gone. And I'll raise the stack but stack overflow is just another wild guess, right? On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack overflow. I raised the stack piecemeal up to 32meg, still overflow. At 64meg it ran out of memory. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 8 Sep 2009 02:09:28 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other problems) Here's the hang backtrace for mentor. Again, all appears normal, except that all the threads are paused or waiting, which is suspicious. I'm stumped for now. Thread 21 (process 96727 thread 0x7403):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../src/xvbt/XClientF.m3:105#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 20 (process 96727 thread 0x7103):#0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/thread/PTHREAD/ThreadPThread.m3:319#1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:669#2 0x01020024 in Thread__AlertPause (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ThreadPThread.m3:699#3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/Animate.m3:71#4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../src/MGV.m3:313#5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656#6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../src/bresenham/ViewError.m3:548#7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101#8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../src/Zeus.m3:331#9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#10 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#11 0x96373155 in _pthread_start ()#12 0x96373012 in thread_start () Thread 19 (process 96727 thread 0x5d07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 18 (process 96727 thread 0x700b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361#6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../src/Zeus.m3:328#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 17 (process 96727 thread 0x6e03):#0 0x963493dc in _pthread_testcancel ()#1 0x96349275 in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../src/vtext/VTCaret.m3:149#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 16 (process 96727 thread 0x435b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) at ../src/ZeusPanel.m3:1425#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 15 (process 96727 thread 0x420b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 14 (process 96727 thread 0x4103):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 13 (process 96727 thread 0x4003):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../src/trestle/Trestle.m3:884#6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) at ../src/View.m3:74#7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:546#8 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ThreadPThread.m3:522#9 0x96373155 in _pthread_start ()#10 0x96373012 in thread_start () Thread 12 (process 96727 thread 0x2e03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) at ../src/xvbt/XMessenger.m3:69#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 11 (process 96727 thread 0x2b07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) at ../src/xvbt/XInput.m3:102#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 10 (process 96727 thread 0x2a23):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:826#4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:729#5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) at ../src/xvbt/XInput.m3:63#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 9 (process 96727 thread 0x29f3):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306#6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246#7 0x000149a7 in BresenhamIE__ShowPixel (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227#8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) at ../src/bresenham/AlgBresenham.m3:55#9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../src/bresenham/AlgBresenham.m3:86#10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) at ../src/ZeusPanel.m3:1534#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 8 (process 96727 thread 0x2803):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 7 (process 96727 thread 0x2703):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/formatter/Formatter.m3:440#6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542#7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592#8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577#9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/formatter/Formatter.m3:708#10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) at ../src/formatter/Formatter.m3:615#11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:546#12 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ThreadPThread.m3:522#13 0x96373155 in _pthread_start ()#14 0x96373012 in thread_start () Thread 6 (process 96727 thread 0x2603):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266#5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) at ../src/WorkerPool.m3:152#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 5 (process 96727 thread 0x2313):#0 0x963916fa in select$DARWIN_EXTSN ()#1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../src/unix/Common/UnixC.c:301#2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../src/thread/PTHREAD/ThreadPThread.m3:787#3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823#4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:742#5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458#6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/POSIX/TCP.m3:234#7 0x006dbc6b in LocalObjectSpace__SpaceAccept (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307#8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:546#9 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ThreadPThread.m3:522#10 0x96373155 in _pthread_start ()#11 0x96373012 in thread_start () Thread 4 (process 96727 thread 0x2003):#0 0x9634946e in __semwait_signal ()#1 0x963492ef in nanosleep$UNIX2003 ()#2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318#3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:668#4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/PTHREAD/ThreadPThread.m3:685#5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) at ../src/lego/FileBrowserVBT.m3:259#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 3 (process 96727 thread 0x1f03):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00a839e2 in VTView__VFontCleanUpThread (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 2 (process 96727 thread 0xd07):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../src/vbt/VBTRep.m3:439#6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:546#7 0x0101ef74 in ThreadPThread__ThreadBase (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ThreadPThread.m3:522#8 0x96373155 in _pthread_start ()#9 0x96373012 in thread_start () Thread 1 (process 96727 thread 0x10b):#0 0x963422ce in semaphore_wait_signal_trap ()#1 0x963742c6 in _pthread_cond_wait ()#2 0x963b9539 in pthread_cond_wait ()#3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226#4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277#5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../src/trestle/Trestle.m3:884#6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477#7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165#8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../src/runtime/common/RTLinker.m3:399#9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at _m3main.mc:6 Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 6 Sep 2009, at 23:18, Jay K wrote: [was truncated again!] PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of stack -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 8 18:23:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 8 Sep 2009 12:23:56 -0400 Subject: [M3devel] FW: Juno on NT (presumably canary for other problems) In-Reply-To: References: <30D99490-EA4A-44A0-8AB1-7BC093F9DCC1@cs.purdue.edu> <1EB93207-7541-47F7-A279-23F274B442C9@hotmail.com> <0F1E65B1-3AF1-434D-8BF4-C4EDCF3E2FF3@cs.purdue.edu> Message-ID: <034E072F-DFA2-43D5-A925-A60FABF60169@cs.purdue.edu> Every thread has a waitCond, which is where we park it when it waits on a condition variable. To alert a thread we can simply signal its waitCond. This avoids having to broadcast on all of the threads waiting on a condition just to get the alerted one to notice. waitingOn is the M3 CV that it is waiting on, which is where the condition wait queue resides. On 8 Sep 2009, at 12:13, Jay K wrote: > er..I don't get the waitCond vs. waitingOn. Have to study it more or > just wait for your fix. > Maybe they are meant to be the same??? I don't know. > (To be clear, with this level of uncertainty, I'm certainly not > changing it.) > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] FW: Juno on NT (presumably canary for other > problems) > Date: Tue, 8 Sep 2009 16:09:21 +0000 > > WITH r = pthread_cond_wait(self.waitCond, m.mutex) DO > > > self.waitCond should be c or self.waitingOn maybe?? > > - Jay > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 8 Sep 2009 16:05:48 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Ok I tried Display=:0.0 and xhost +, it works, same hang. > You don't actually have to do that though, at least on 10.5. > DISPLAY is set to some magic and X is started up on-demand as needed. > Except for that SameHost problem.. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 12:03:05 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > On 8 Sep 2009, at 11:51, jay.krell at cornell.edu wrote: > > That works? $Display gets set to something random looking by > default, an actual file, I don't change it. If what you do works my > change probably does not affect. See the function SameHost in m3-ui/ > ui/xvbt/XSharedMemory.i3. I added the code to predict if the network > stuff will succeed or fail since for me it always failed and was > fatal. > > Yes, it works for me. > > PS I think I have found the problem: a thread not waking from a call > to wait, even though its condition has been signalled. A > longstanding bug inside XWait I think... Sigh. > > > - Jay (phone) > > On Sep 8, 2009, at 7:09 AM, Tony Hosking > wrote: > > What did you change? I wonder... > > To get things to work on Darwin I used to have to do "xhosts +" and > set "DISPLAY=:0.0". Is this no longer the case? > > On 8 Sep 2009, at 04:16, Jay K wrote: > > Here is a wild wild guess: > One thing unusual to Trestle on Darwin, I think, is that it always > appears that X client and X server are different machines. > Well, er, um, that is how I changed it to be when it was otherwise > always going to fail. > How did it work previously? However it did work, if those > conditions are still present, it still has a chance of working. > > Coincidentally or not, the formsedit crashes I have reported are all/ > mostly with a separate X client and server. > > I'll see if I can induce a hang in the otherwise working LINUXLIBC6 > by twiddling with this. > > The specific change I made in Darwin was in the IsSameHost code. > Where it would previously hit an unhandled exception, I have it > return FALSE. > I'm pretty sure that using XSharedMemory is "just" an optimization, > albeit a very good one. > > I looked at little at what the Juno threads are doing..and it > doesn't really have to do with gui code. > libm3/"formatter" is a usual producer/consumer thingy, signal when > queue is empty or nonempty. > We /might/ be able to demonstrate this hang without any of Trestle > in the picture. Might. > > I haven't looked at Mentor but it looks more complicated below. > I'll also see if the Juno NT crashes are gone. > And I'll raise the stack but stack overflow is just another wild > guess, right? > > On PPC_DARWIN 5.2.6 running on Intel 10.5, Juno often claims stack > overflow. > I raised the stack piecemeal up to 32meg, still overflow. At 64meg > it ran out of memory. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 8 Sep 2009 02:09:28 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] FW: Juno on NT (presumably canary for other > problems) > > Here's the hang backtrace for mentor. Again, all appears normal, > except that all the threads are paused or waiting, which is > suspicious. I'm stumped for now. > > Thread 21 (process 96727 thread 0x7403): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb15d4db0, > rem=0xb15d4db8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1f3f880, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00bc9cf4 in XClientF__MeterMaid (M3_AS2y1X_cl=0x1f3f870) at ../ > src/xvbt/XClientF.m3:105 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c441d0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c441d0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 20 (process 96727 thread 0x7103): > #0 ThreadPThread__XTestAlert (M3_BXP32l_self=0x1e5c134) at ../src/ > thread/PTHREAD/ThreadPThread.m3:319 > #1 0x0101fd9b in ThreadPThread__XPause (M3_BXP32l_self=0x1e5c134, > M3_CtKayy_n=0.0056863520294427872, M3_AicXUJ_alertable=1 '\001') > at ../src/thread/PTHREAD/ThreadPThread.m3:669 > #2 0x01020024 in Thread__AlertPause > (M3_CtKayy_n=0.0056863520294427872) at ../src/thread/PTHREAD/ > ThreadPThread.m3:699 > #3 0x008f9ea1 in Animate__Do (M3_CCfZY3_t=0x1e7e3fc, > M3_DsL7Zz_mg=0x0, M3_AdEaVQ_v=0x1e5e0f8, M3_BUucNs_duration=1) at ../ > src/Animate.m3:71 > #4 0x00909610 in MGV__Animation (M3_AdEaVQ_v=0x1e5e0f8, > M3_BUucNs_duration=1) at ../src/MGV.m3:313 > #5 0x008921f9 in GraphVBT__AnimateGraph (M3_Cj00zi_graph=0x1e5e00c, > M3_BUucNs_t0=0, M3_BUucNs_t1=1) at ../src/GraphVBT.m3:656 > #6 0x00019be8 in ViewError__ShowPixel (M3_AoJTjZ_view=0x1ed3060, > M3_AcxOUs_x=3, M3_AcxOUs_y=2, M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../ > src/bresenham/ViewError.m3:548 > #7 0x0001529a in BresenhamIE__OEDispatcher (M3_Ao6Rbg_v=0x1ed3060, > M3_Af40ku_evt=0x1e08014) at ../I386_DARWIN/BresenhamIE.m3:101 > #8 0x007abb9b in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c128) at ../ > src/Zeus.m3:331 > #9 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fd80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #10 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fd80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #11 0x96373155 in _pthread_start () > #12 0x96373012 in thread_start () > > Thread 19 (process 96727 thread 0x5d07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c0bc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1edf34c, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1edf34c) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1edf25c) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c0b0) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fc80) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fc80) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 18 (process 96727 thread 0x700b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e5c044, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1ee3bac, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1ee3bac) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x007ab7f2 in Zeus__WakeZeusAndSleep (M3_CQpoHd_zeus=0x1e3ccfc, > M3_B74vJ1_view=0x1ee3b00) at ../src/Zeus.m3:361 > #6 0x007abaa2 in Zeus__ViewThread (M3_BH3Tll_self=0x1e5c038) at ../ > src/Zeus.m3:328 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3fa90) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3fa90) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 17 (process 96727 thread 0x6e03): > #0 0x963493dc in _pthread_testcancel () > #1 0x96349275 in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb134add0, > rem=0xb134add8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1e54388, > M3_CtKayy_n=0.5, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=0.5) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a6f0c0 in VTCaret__Blinker (M3_Axogco_arg=0x1e5437c) at ../ > src/vtext/VTCaret.m3:149 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c3f9c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c3f9c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 16 (process 96727 thread 0x435b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1df30c8, > M3_AYIbX3_m=0x1e3bb94, M3_Bl0jv4_c=0x1e3bbb0, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3bb94, > M3_Bl0jv4_c=0x1e3bbb0) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007baaa1 in ZeusPanel__PanelThread (M3_CvdnuP_pc=0x1df30b8) > at ../src/ZeusPanel.m3:1425 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c39830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c39830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 15 (process 96727 thread 0x420b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d67e68, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1d22688, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1d22688) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ee3b00) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1d67e5c) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c305c0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c305c0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 14 (process 96727 thread 0x4103): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ee32e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1edf3c4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1edf3c4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1edf25c) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1ee32d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38bf0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38bf0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 13 (process 96727 thread 0x4003): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1edb2e4, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1ed532c, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1ed532c) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1ed3060) at ../ > src/trestle/Trestle.m3:884 > #6 0x007a98b1 in View__WaiterThread (M3_C7vPGX_waiter=0x1edb2d8) > at ../src/View.m3:74 > #7 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38780) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #8 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38780) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #9 0x96373155 in _pthread_start () > #10 0x96373012 in thread_start () > > Thread 12 (process 96727 thread 0x2e03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed52a4, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed35f4, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed35f4) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bb7962 in XMessenger__Messenger (M3_EVlqQO_self=0x1ed5294) > at ../src/xvbt/XMessenger.m3:69 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38420) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38420) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 11 (process 96727 thread 0x2b07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1ed5254, > M3_AYIbX3_m=0x1ed327c, M3_Bl0jv4_c=0x1ed3614, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1ed327c, > M3_Bl0jv4_c=0x1ed3614) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bbdbc2 in XInput__FilterXInput (M3_DSd60P_self=0x1ed5244) > at ../src/xvbt/XInput.m3:102 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38320) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38320) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 10 (process 96727 thread 0x2a23): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=7, readfds=0x2813d54, > writefds=0x2813d64, exceptfds=0x2813d74, timeout=0x0) at ../src/unix/ > Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0x0) at ../src/ > thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206cc in ThreadPThread__XIOWait (M3_BXP32l_self=0x1ed5204, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=-1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/ > PTHREAD/ThreadPThread.m3:826 > #4 0x010201b4 in SchedulerPosix__IOWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:729 > #5 0x00bbf20b in XInput__WaitForXInput (M3_Bkyxhg_self=0x1ed51f4) > at ../src/xvbt/XInput.m3:63 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c38250) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c38250) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 9 (process 96727 thread 0x29f3): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1e3fafc, > M3_AYIbX3_m=0x1e3f9bc, M3_Bl0jv4_c=0x1e3f9c8, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1e3f9bc, > M3_Bl0jv4_c=0x1e3f9c8) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x007ab312 in Zeus__AlgToViews (M3_CQpoHd_zeus=0x1e3ccfc, > M3_Ao6Rbg_initiator=0x1ecd9cc, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:306 > #6 0x007ac1f0 in Zeus__Dispatch (M3_Ao6Rbg_initiator=0x1ecd9cc, > M3_DsvzJ6_style=0 '\0', M3_AcxOUs_priority=1, > M3_Bd56fi_eventName=0x1d9d60, M3_BMhQCx_dispatchProc=0x150e0, > M3_Af40ku_evtArgs=0x1e08014) at ../src/Zeus.m3:246 > #7 0x000149a7 in BresenhamIE__ShowPixel > (M3_CfiRBL_initiator=0x1ecd9cc, M3_AcxOUs_x=3, M3_AcxOUs_y=2, > M3_AcxOUs_p1=6, M3_AcxOUs_p2=-2) at ../I386_DARWIN/BresenhamIE.m3:227 > #8 0x000175b7 in AlgBresenham__DrawLine (M3_ECecEc_alg=0x1ecd9cc, > M3_AcxOUs_x1=0, M3_AcxOUs_y1=0, M3_AcxOUs_x2=10, M3_AcxOUs_y2=6) > at ../src/bresenham/AlgBresenham.m3:55 > #9 0x0001788f in AlgBresenham__Run (M3_ECecEc_alg=0x1ecd9cc) at ../ > src/bresenham/AlgBresenham.m3:86 > #10 0x007bb729 in ZeusPanel__AlgThread (M3_Dijbki_ac=0x1e3fae8) > at ../src/ZeusPanel.m3:1534 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29fd0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29fd0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 8 (process 96727 thread 0x2803): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d8e01c, > M3_AYIbX3_m=0x1d71fdc, M3_Bl0jv4_c=0x1d71fe8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d71fdc, > M3_Bl0jv4_c=0x1d71fe8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d71680, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d71680, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d71680, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb038ce90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d8e00c) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c29140) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c29140) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 7 (process 96727 thread 0x2703): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d71618, > M3_AYIbX3_m=0x1d715ec, M3_Bl0jv4_c=0x1d715f8, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d715ec, > M3_Bl0jv4_c=0x1d715f8) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x00e3bdf2 in Formatter__Allocate (M3_ACp9GL_t=0x1d70c90, > M3_DBiloZ_this=1 '\001', M3_Cwb5VA_minSize=) at ../src/ > formatter/Formatter.m3:440 > #6 0x00e3bf0a in Formatter__Probe (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:542 > #7 0x00e3c2b8 in Formatter__Peek (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:592 > #8 0x00e3c2ff in Formatter__PeekOp (M3_ACp9GL_t=0x1d70c90, > M3_Cwb5VA_i=) at ../src/formatter/Formatter.m3:577 > #9 0x00e3cb25 in Formatter__PrintUntil (M3_ACp9GL_t=0x1d70c90, > M3_DOUxXw_mode=1 '\001', M3_ElBLGV_pos=0xb030ae90, > M3_Cwb5VA_maxL=, M3_CCuODf_op=0x1d72c08) at ../src/ > formatter/Formatter.m3:708 > #10 0x00e3cfc9 in Formatter__PrintTop (M3_B5Nhtj_self=0x1d71608) > at ../src/formatter/Formatter.m3:615 > #11 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c221e0) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #12 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c221e0) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #13 0x96373155 in _pthread_start () > #14 0x96373012 in thread_start () > > Thread 6 (process 96727 thread 0x2603): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d729bc, > M3_AYIbX3_m=0x1d728b4, M3_Bl0jv4_c=0x1d729a0, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d7a6 in Thread__AlertWait (M3_AYIbX3_m=0x1d728b4, > M3_Bl0jv4_c=0x1d729a0) at ../src/thread/PTHREAD/ThreadPThread.m3:266 > #5 0x0073de32 in WorkerPool__ClericApply (M3_BSwVRC_self=0x1d729b0) > at ../src/WorkerPool.m3:152 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28e10) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28e10) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 5 (process 96727 thread 0x2313): > #0 0x963916fa in select$DARWIN_EXTSN () > #1 0x01023503 in Unix__select (nfds=4, readfds=0x1d74014, > writefds=0x1d74024, exceptfds=0x1d74034, timeout=0xb0206b20) at ../ > src/unix/Common/UnixC.c:301 > #2 0x01020970 in ThreadPThread__XIOWait__CallSelect.762 > (M3_Cwb5VA_nfd=, M3_A4bqCj_timeout=0xb0206b20) at ../ > src/thread/PTHREAD/ThreadPThread.m3:787 > #3 0x010206a8 in ThreadPThread__XIOWait (M3_BXP32l_self=0x1d585bc, > M3_Cwb5VA_fd=, M3_AicXUJ_read=1 '\001', > M3_CtKayy_interval=1.7976931348623157e+308, M3_AicXUJ_alertable=1 > '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:823 > #4 0x010202e7 in SchedulerPosix__IOAlertWait (M3_Cwb5VA_fd= type>, M3_AicXUJ_read=1 '\001', M3_CtKayy_timeoutInterval=-1) at ../ > src/thread/PTHREAD/ThreadPThread.m3:742 > #5 0x00dd3cc2 in TCPMisc__AcceptFrom (M3_AahksS_c=0x1d58594, > M3_DoBjMZ_peer=0xb0206cb4) at ../src/POSIX/TCP.m3:458 > #6 0x00dd3da8 in TCP__Accept (M3_AahksS_c=0x1d58594) at ../src/ > POSIX/TCP.m3:234 > #7 0x006dbc6b in LocalObjectSpace__SpaceAccept > (M3_Dbz8GV_self=0x1d585b0) at ../src/LocalObjectSpace.m3:307 > #8 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c28d60) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #9 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c28d60) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #10 0x96373155 in _pthread_start () > #11 0x96373012 in thread_start () > > Thread 4 (process 96727 thread 0x2003): > #0 0x9634946e in __semwait_signal () > #1 0x963492ef in nanosleep$UNIX2003 () > #2 0x01022cc4 in ThreadPThread__Nanosleep (req=0xb0184dd0, > rem=0xb0184dd8) at ../src/thread/PTHREAD/ThreadPThreadC.c:318 > #3 0x0101fd7c in ThreadPThread__XPause (M3_BXP32l_self=0x1d0ba08, > M3_CtKayy_n=1, M3_AicXUJ_alertable=0 '\0') at ../src/thread/PTHREAD/ > ThreadPThread.m3:668 > #4 0x0101fef3 in Thread__Pause (M3_CtKayy_n=1) at ../src/thread/ > PTHREAD/ThreadPThread.m3:685 > #5 0x00a11d53 in FileBrowserVBT__Watcher (M3_EMTrVz_cl=0x1d0ba00) > at ../src/lego/FileBrowserVBT.m3:259 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21830) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21830) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 3 (process 96727 thread 0x1f03): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d090d4, > M3_AYIbX3_m=0x1d090b0, M3_Bl0jv4_c=0x1d090bc, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d090b0, > M3_Bl0jv4_c=0x1d090bc) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00a839e2 in VTView__VFontCleanUpThread > (M3_EMTrVz_cl=0x1d090cc) at ../src/vtext/VTView.m3:111 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21310) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21310) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 2 (process 96727 thread 0xd07): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d006c8, > M3_AYIbX3_m=0x1d00688, M3_Bl0jv4_c=0x1d00694, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00688, > M3_Bl0jv4_c=0x1d00694) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00bf33d2 in VBTRep__MeterMaid (M3_EMTrVz_self=0x1d006bc) at ../ > src/vbt/VBTRep.m3:439 > #6 0x0101f243 in ThreadPThread__RunThread (M3_BeUkBA_me=0x1c21390) > at ../src/thread/PTHREAD/ThreadPThread.m3:546 > #7 0x0101ef74 in ThreadPThread__ThreadBase > (M3_AJWxb1_param=0x1c21390) at ../src/thread/PTHREAD/ > ThreadPThread.m3:522 > #8 0x96373155 in _pthread_start () > #9 0x96373012 in thread_start () > > Thread 1 (process 96727 thread 0x10b): > #0 0x963422ce in semaphore_wait_signal_trap () > #1 0x963742c6 in _pthread_cond_wait () > #2 0x963b9539 in pthread_cond_wait () > #3 0x0101d189 in ThreadPThread__XWait (M3_BXP32l_self=0x1d0000c, > M3_AYIbX3_m=0x1d00500, M3_Bl0jv4_c=0x1df3114, M3_AicXUJ_alertable=0 > '\0') at ../src/thread/PTHREAD/ThreadPThread.m3:226 > #4 0x0101d823 in Thread__Wait (M3_AYIbX3_m=0x1d00500, > M3_Bl0jv4_c=0x1df3114) at ../src/thread/PTHREAD/ThreadPThread.m3:277 > #5 0x00c40602 in Trestle__AwaitDelete (M3_BFdKo9_v=0x1e3a204) at ../ > src/trestle/Trestle.m3:884 > #6 0x007c09eb in ZeusPanel__Interact (M3_Bd56fi_title=0x290db0, > M3_DYb95R_path=0x1d498c0) at ../src/ZeusPanel.m3:477 > #7 0x001b0ede in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:165 > #8 0x0100eb1f in RTLinker__RunMainBody (M3_DjPxE3_m=0x1d6060) at ../ > src/runtime/common/RTLinker.m3:399 > #9 0x00002578 in main (argc=1, argv=0xbfffedb8, envp=0xbfffedc0) at > _m3main.mc:6 > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 6 Sep 2009, at 23:18, Jay K wrote: > > > > > > > > > > > [was truncated again!] > > PPC_DARWIN 5.2.6 Juno on x86 sometimes hangs, sometimes runs out of > stack > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Wed Sep 9 22:12:57 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 09 Sep 2009 15:12:57 -0500 Subject: [M3devel] Modula-3 page that's actually up to date Message-ID: <4AA80C49.4040006@esoteriq.org> I just found this website: http://www.eiserloh.org/~peter/modula3/ and was amazed to see it's up to date. Nice little collection of links there. From mbishop at esoteriq.org Wed Sep 9 22:19:32 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 09 Sep 2009 15:19:32 -0500 Subject: [M3devel] Quake problem installing packages Message-ID: <4AA80DD4.3060209@esoteriq.org> Installing some of the packages (Math, some of m3devtools and devlib so far) result in this error: quake runtime error: undefined variable: symbolic_link_file Always the same problem, "undefined variable: symbolic_link_file" in .M3SHIP From mbishop at esoteriq.org Wed Sep 9 22:39:40 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 09 Sep 2009 15:39:40 -0500 Subject: [M3devel] Quake problem installing packages In-Reply-To: <4AA80DD4.3060209@esoteriq.org> References: <4AA80DD4.3060209@esoteriq.org> Message-ID: <4AA8128C.1040403@esoteriq.org> Sorry, diregard this, somehow my system is still using an old CM3 instead of 5.8. Sorry. Martin Bishop wrote: > Installing some of the packages (Math, some of m3devtools and devlib > so far) result in > this error: > > > quake runtime error: undefined variable: symbolic_link_file > > > Always the same problem, "undefined variable: symbolic_link_file" in > .M3SHIP > > From hosking at cs.purdue.edu Fri Sep 11 15:45:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Message-ID: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 16:24:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 14:24:06 +0000 Subject: [M3devel] RC merge In-Reply-To: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Fri Sep 11 18:14:07 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 11 Sep 2009 18:14:07 +0200 Subject: [M3devel] elego Maintenance 12.09 Message-ID: <20090911181407.vk17th56tc4c4k4s@mail.elego.de> Hello, On Saturday, Sept. 12 from 10 AM to 4 PM CEST, we will be performing maintenance at our Gustav-Meyer-Allee site. Among other planned procedures, a UPS battery replacement will require taking the following servers completely off line for approximately one hour: -new.elego.de -old.elego.de -fedora.elego.de -bdc1.elego.de -willow.elego.de -pine.elego.de The ESXi server madrona and its hosts will not be affected by this. The elego lan will be unreachable during the battery replacement and subsequent disruptions of some services should be expected until maintenance procedures are completed in the late afternoon. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Sep 11 18:46:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 12:46:19 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote: > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 22:05:52 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 20:05:52 +0000 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 11 22:43:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 16:43:29 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: <49A3CCD1-581E-46F9-B6EF-0F3FE2B581EC@cs.purdue.edu> On 11 Sep 2009, at 16:05, Jay K wrote: > Tony I'll double check if I see the hang. NT386 still crashes. That's ThreadWin32 right? > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 11 22:51:11 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 16:51:11 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote: > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 11 23:05:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 17:05:57 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4AAA8078.1E75.00D7.1@scires.com> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> Message-ID: <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:28:43 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:28:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> Message-ID: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:30:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:30:22 +0000 Subject: [M3devel] RC merge In-Reply-To: <49A3CCD1-581E-46F9-B6EF-0F3FE2B581EC@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <49A3CCD1-581E-46F9-B6EF-0F3FE2B581EC@cs.purdue.edu> Message-ID: Correct ThreadWin32 not ThreadPThread or ThreadPosix. I narrowed the problem down to a 30 minute window in Februrary (see older mail). I'll try again with recent changes (esp. if they are in common code, which I don't think they are) - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:43:29 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge On 11 Sep 2009, at 16:05, Jay K wrote:Tony I'll double check if I see the hang. NT386 still crashes. That's ThreadWin32 right? http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:33:32 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:33:32 +0000 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: ps: I think there's another funny thing here: I think you can have: INTERFACE FooInterface; PROCEDURE SafeFunction(); PROCEDURE UnsafeFunction()=ADDRESS; END FooInterface. Despite being in a safe interface, UnsafeFunction either can't be called from safe code, or at least its return value can't be used? Or at least can't be done anything with but compare to NIL? I think. Therefore this interface could be said to be "partially unsafe". Perhaps not a useful middle ground though. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] RC merge Date: Fri, 11 Sep 2009 21:26:00 +0000 Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be. I propose a few options: 1 - asis, probably not 2 - rename/merge ThreadUnsafe to ThreadInternal 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too 2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal 3 maybe gratuitously breaks folks but is a clean result 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:51:11 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote:Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 11 23:26:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Sep 2009 21:26:00 +0000 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be. I propose a few options: 1 - asis, probably not 2 - rename/merge ThreadUnsafe to ThreadInternal 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too 2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal 3 maybe gratuitously breaks folks but is a clean result 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:51:11 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote:Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote:But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Sat Sep 12 02:58:04 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 11 Sep 2009 19:58:04 -0500 Subject: [M3devel] Dual Pivot Quicksort problem Message-ID: <4AAAF21C.5030209@esoteriq.org> I saw a post on reddit about a Dual Pivot Quicksort, and I translated the code from Java to Modula-3. I have it all translated, and it builds, but I am having boundary issues. Somewhere on the second pass, the variable m2 is getting the value -2. Here's the code: MODULE DualPivot; IMPORT Insertion, Fmt; PROCEDURE Sort(VAR arr: ARRAY OF INTEGER) = BEGIN SortFromTo(arr, 0, NUMBER(arr)); END Sort; PROCEDURE SortFromTo(VAR arr: ARRAY OF INTEGER; from, to: INTEGER) = BEGIN RangeCheck(NUMBER(arr), from, to); DualPivotSort(arr, from, to - 1, 3); END SortFromTo; PROCEDURE RangeCheck(len, from, to: INTEGER) RAISES {BadArgument, IndexOutOfRange} = BEGIN IF from > to THEN RAISE BadArgument(Fmt.Int(from) & " > " & Fmt.Int(to) & "\n"); END; IF from < 0 THEN RAISE IndexOutOfRange("from"); END; IF to > len THEN RAISE IndexOutOfRange("to"); END; END RangeCheck; PROCEDURE Swap(VAR arr: ARRAY OF INTEGER; i, j: INTEGER) = VAR temp := arr[i]; BEGIN arr[i] := arr[j]; arr[j] := temp; END Swap; PROCEDURE DualPivotSort(VAR arr: ARRAY OF INTEGER; left, right, div: INTEGER) = VAR len := left - right; third := len DIV div; m1 := left + third; m2 := right - third; piv1: INTEGER; piv2: INTEGER; less := left + 1; great := right - 1; dist: INTEGER; BEGIN IF len < 27 THEN Insertion.Sort(arr); END; IF m1 <= left THEN m1 := left + 1; END; IF m2 >= right THEN m2 := right - 1; END; IF arr[m1] < arr[m2] THEN Swap(arr, m1, left); Swap(arr, m2, right); ELSE Swap(arr, m1, right); Swap(arr, m2, left); END; piv1 := arr[left]; piv2 := arr[right]; FOR k := less TO great DO IF arr[k] < piv1 THEN Swap(arr, k, less + 1); ELSIF arr[k] > piv2 THEN WHILE (k < great) AND (arr[great] > piv2) DO DEC(great); END; Swap(arr, k, great - 1); IF arr[k] < piv1 THEN Swap(arr, k, less + 1); END; END; END; dist := great - less; IF dist < 13 THEN INC(div); END; Swap(arr, less - 1, left); Swap(arr, great + 1, right); DualPivotSort(arr, left, less - 2, div); DualPivotSort(arr, great + 2, right, div); IF (dist > len - 13) AND (piv1 # piv2) THEN FOR k := less TO great DO IF arr[k] = piv1 THEN Swap(arr, k, less + 1); ELSIF arr[k] = piv2 THEN Swap(arr, k, great - 1); IF arr[k] = piv1 THEN Swap(arr, k, less + 1); END; END; END; END; IF piv1 < piv2 THEN DualPivotSort(arr, less, great, div); END; END DualPivotSort; BEGIN END DualPivot. Right now when I try to run I get: *** *** runtime error: *** An array subscript was out of range. *** file "../DualPivot.m3", line 61 *** Line 61 is: IF arr[m1] < arr[m2] THEN Anyone see what is happening? It's probably off by 1 (or more) errors, but I don't see them. From hosking at cs.purdue.edu Sat Sep 12 04:19:49 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 22:19:49 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> Yes, that was exactly my intention. I wasn't quite sure what your problem was with the code I had returning ADDRESS, but was willing to accede. It is "safe", but you can't use the result unless in UNSAFE code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 17:33, Jay K wrote: > ps: I think there's another funny thing here: > I think you can have: > > INTERFACE FooInterface; > > PROCEDURE SafeFunction(); > PROCEDURE UnsafeFunction()=ADDRESS; > > END FooInterface. > > Despite being in a safe interface, UnsafeFunction either can't be > called > from safe code, or at least its return value can't be used? Or at > least > can't be done anything with but compare to NIL? > I think. > Therefore this interface could be said to be "partially unsafe". > > Perhaps not a useful middle ground though. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC merge > Date: Fri, 11 Sep 2009 21:26:00 +0000 > > Yes and no. I agree I made a small mess. I'm not sure you have quite > described how it should be. > > I propose a few options: > 1 - asis, probably not > 2 - rename/merge ThreadUnsafe to ThreadInternal > 3 - move the part that external folks use, probably just MyId, to > Thread, and then move ThreadUnsafe back to ThreadF, maybe > ThreadInternal to ThreadF too > > 2 at least removes one interface that I added, reducing the three > similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF > and ThreadInternal > > 3 maybe gratuitously breaks folks but is a clean result > > 4 - like you said, make all ThreadF users unsafe; but IF it is just > MyId, and I'm not sure it is, which seems harmless, right? seems > wrong to make them unsafe. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 16:51:11 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Sorry, it looks like my commit failed last night because of need to > merge with your ThreadUnsafe stuff. > > FYI, we really should think about making ThreadF UNSAFE since anyone > invoking on it is exposed to dangerous parts of the run-time > system. Is there any need for it really to be safe? > > On 11 Sep 2009, at 16:05, Jay K wrote: > > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 04:20:57 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 22:20:57 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> Message-ID: I propose leave ThreadF safe, and revert back to MyHeapState:ADDRESS in ThreadF. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 17:26, Jay K wrote: > Yes and no. I agree I made a small mess. I'm not sure you have quite > described how it should be. > > I propose a few options: > 1 - asis, probably not > 2 - rename/merge ThreadUnsafe to ThreadInternal > 3 - move the part that external folks use, probably just MyId, to > Thread, and then move ThreadUnsafe back to ThreadF, maybe > ThreadInternal to ThreadF too > > 2 at least removes one interface that I added, reducing the three > similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF > and ThreadInternal > > 3 maybe gratuitously breaks folks but is a clean result > > 4 - like you said, make all ThreadF users unsafe; but IF it is just > MyId, and I'm not sure it is, which seems harmless, right? seems > wrong to make them unsafe. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 16:51:11 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Sorry, it looks like my commit failed last night because of need to > merge with your ThreadUnsafe stuff. > > FYI, we really should think about making ThreadF UNSAFE since anyone > invoking on it is exposed to dangerous parts of the run-time > system. Is there any need for it really to be safe? > > On 11 Sep 2009, at 16:05, Jay K wrote: > > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 04:21:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 11 Sep 2009 22:21:44 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> Message-ID: <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: > They aren't really in Trestle or ThreadWin32. > Well, right, often they are in ThreadWin32. > But not always. > I think it is, like, classic heap/stack corruption, via non-classic > "locking not working" and gc moving stuff when it shouldn't. > I don't have good evidence, but it usually NOT a hang/deadlock or > assertion failure, it is usually an access violation (aka SEGSIGV) > which as I understand must be the result of bugs in unsafe code. > > I did narrow it down a 30 minute window. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Fri, 11 Sep 2009 17:05:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I have my suspicions that ThreadWin32 may have similar latent bugs > in synchronization similar to those I have recently shaken out of > the pthreads implementation. The good thing is that my > implementation there is based in part on ThreadWin32, so it can't be > too far off. It is inevitable with concurrent code that you will > get different behavior at each run. The easiest things to debug are > thread lockups, which can usually be diagnosed by staring at dumps > of all the thread state. Harder is actual crashes like you are > observing. If assertions can be used to monitor program invariants > then it usually can be narrowed down. Unfortunately, I am not in a > position to debug the ThreadWin32 code. Any help would be > appreciated. The question is whether the crashes you see are in > Trestle or ThreadWin32. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 12 05:37:44 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Fri, 11 Sep 2009 20:37:44 -0700 Subject: [M3devel] RC merge In-Reply-To: <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> Message-ID: <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> I don't like the caller to have to cast. - Jay (phone) On Sep 11, 2009, at 7:19 PM, Tony Hosking wrote: > Yes, that was exactly my intention. I wasn't quite sure what your > problem was with the code I had returning ADDRESS, but was willing > to accede. It is "safe", but you can't use the result unless in > UNSAFE code. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 17:33, Jay K wrote: > >> ps: I think there's another funny thing here: >> I think you can have: >> >> INTERFACE FooInterface; >> >> PROCEDURE SafeFunction(); >> PROCEDURE UnsafeFunction()=ADDRESS; >> >> END FooInterface. >> >> Despite being in a safe interface, UnsafeFunction either can't be >> called >> from safe code, or at least its return value can't be used? Or at >> least >> can't be done anything with but compare to NIL? >> I think. >> Therefore this interface could be said to be "partially unsafe". >> >> Perhaps not a useful middle ground though. >> >> - Jay >> >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] RC merge >> Date: Fri, 11 Sep 2009 21:26:00 +0000 >> >> Yes and no. I agree I made a small mess. I'm not sure you have >> quite described how it should be. >> >> I propose a few options: >> 1 - asis, probably not >> 2 - rename/merge ThreadUnsafe to ThreadInternal >> 3 - move the part that external folks use, probably just MyId, to >> Thread, and then move ThreadUnsafe back to ThreadF, maybe >> ThreadInternal to ThreadF too >> >> 2 at least removes one interface that I added, reducing the three >> similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF >> and ThreadInternal >> >> 3 maybe gratuitously breaks folks but is a clean result >> >> 4 - like you said, make all ThreadF users unsafe; but IF it is >> just MyId, and I'm not sure it is, which seems harmless, right? >> seems wrong to make them unsafe. >> >> - Jay >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Fri, 11 Sep 2009 16:51:11 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] RC merge >> >> Sorry, it looks like my commit failed last night because of need to >> merge with your ThreadUnsafe stuff. >> >> FYI, we really should think about making ThreadF UNSAFE since >> anyone invoking on it is exposed to dangerous parts of the run-time >> system. Is there any need for it really to be safe? >> >> On 11 Sep 2009, at 16:05, Jay K wrote: >> >> Tony I'll double check if I see the hang. NT386 still crashes. >> >> http://www.modula3.com/cm3/ChangeLog-2009 >> >> " >> 2009-09-08 05:54 hosking >> >> * m3-libs/m3core/src/: convert/CConvert.m3, >> runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, >> runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, >> runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, >> runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, >> runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, >> runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, >> thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, >> thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, >> thread/WIN32/ThreadWin32.m3: >> >> Tidy up use of thread.inCritical to only occur in allocation >> sequences and in >> thread stoppage. This simplifies reasoning. Refactored use of >> heap lock >> in the process. This may be better implemented on PTHREAD >> targets using a >> recursive pthread mutex instead of one we roll ourselves from a >> non-recursive >> mutex. >> >> Still witnessing random hangs in Juno and mentor on I386_DARWIN. >> Strange, I thought this was working previously. >> I wonder if there is some sort of race in the GUI code somewhere? >> " >> >> ?? >> - Jay >> >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Fri, 11 Sep 2009 12:46:19 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] RC merge >> >> No, the hangs in Juno and mentor are no longer there. I cannot >> reproduce them on I386_DARWIN. >> >> On 11 Sep 2009, at 10:24, Jay K wrote: >> >> But the hangs are still present, right? Worth merging without that >> fixed? >> >> How does one do it easily? >> I wish we used Perforce. :( >> >> - Jay >> >> >> From: hosking at cs.purdue.edu >> To: m3devel at elegosoft.com >> Date: Fri, 11 Sep 2009 09:45:23 -0400 >> Subject: [M3devel] RC merge >> >> Can someone merge my recent deep fixes to pthreads threading over >> to the release branch? I won't get a chance to do so until next >> Monday at the earliest. >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Sat Sep 12 06:01:05 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 11 Sep 2009 23:01:05 -0500 Subject: [M3devel] Dual Pivot Quicksort problem In-Reply-To: <4AAAF21C.5030209@esoteriq.org> References: <4AAAF21C.5030209@esoteriq.org> Message-ID: <4AAB1D01.3020403@esoteriq.org> Edited it some more, lots of silly mistakes in that old code. Now it almost works...it sorts the array sometimes, but other times gives me a bounds error. Any idea now? MODULE DualPivot; IMPORT Insertion, Fmt, IO; PROCEDURE Sort(VAR arr: ARRAY OF INTEGER) = BEGIN SortFromTo(arr, 0, NUMBER(arr)); END Sort; PROCEDURE SortFromTo(VAR arr: ARRAY OF INTEGER; from, to: INTEGER) = BEGIN RangeCheck(NUMBER(arr), from, to); DualPivotSort(arr, from, to - 1, 3); END SortFromTo; PROCEDURE RangeCheck(len, from, to: INTEGER) RAISES {BadArgument, IndexOutOfRange} = BEGIN IF from > to THEN RAISE BadArgument(Fmt.Int(from) & " > " & Fmt.Int(to) & "\n"); END; IF from < 0 THEN RAISE IndexOutOfRange("from"); END; IF to > len THEN RAISE IndexOutOfRange("to"); END; END RangeCheck; PROCEDURE Swap(VAR arr: ARRAY OF INTEGER; i, j: INTEGER) = VAR temp := arr[i]; BEGIN arr[i] := arr[j]; arr[j] := temp; END Swap; PROCEDURE DualPivotSort(VAR arr: ARRAY OF INTEGER; left, right, div: INTEGER) = VAR len := right - left; third := len DIV div; m1 := left + third; m2 := right - third; piv1: INTEGER; piv2: INTEGER; less := left + 1; great := right - 1; dist: INTEGER; BEGIN IF len < 27 THEN Insertion.Sort(arr); RETURN; END; IF m1 <= left THEN m1 := left + 1; END; IF m2 >= right THEN m2 := right - 1; END; IO.Put("DEBUG: m1 = " & Fmt.Int(m1) & " m2 = " & Fmt.Int(m2) & " left = " & Fmt.Int(left) & " right = " & Fmt.Int(right) & "\n"); IO.Put("DEBUG: len = " & Fmt.Int(len) & " third = " & Fmt.Int(third) & "\n"); IO.Put("***\n"); IF arr[m1] < arr[m2] THEN Swap(arr, m1, left); Swap(arr, m2, right); ELSE Swap(arr, m1, right); Swap(arr, m2, left); END; piv1 := arr[left]; piv2 := arr[right]; FOR k := less TO great DO IF arr[k] < piv1 THEN Swap(arr, k, less); INC(less); ELSIF arr[k] > piv2 THEN WHILE (k < great) AND (arr[great] > piv2) DO DEC(great); END; Swap(arr, k, great); DEC(great); IF arr[k] < piv1 THEN Swap(arr, k, less); INC(less); END; END; END; dist := great - less; IF dist < 13 THEN INC(div); END; Swap(arr, less - 1, left); Swap(arr, great + 1, right); DualPivotSort(arr, left, less - 2, div); DualPivotSort(arr, great + 2, right, div); IF (dist > len - 13) AND (piv1 # piv2) THEN FOR k := less TO great DO IF arr[k] = piv1 THEN Swap(arr, k, less); INC(less); ELSIF arr[k] = piv2 THEN Swap(arr, k, great); DEC(great); IF arr[k] = piv1 THEN Swap(arr, k, less); INC(less); END; END; END; END; IF piv1 < piv2 THEN DualPivotSort(arr, less, great, div); END; END DualPivotSort; BEGIN END DualPivot. Martin Bishop wrote: > I saw a post on reddit about a Dual Pivot Quicksort, and I translated > the code from Java to Modula-3. I have it all translated, and it > builds, but I am having boundary issues. Somewhere on the second > pass, the variable m2 is getting the value -2. Here's the code: > > ... > Right now when I try to run I get: > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../DualPivot.m3", line 61 > *** > > Line 61 is: IF arr[m1] < arr[m2] THEN > > Anyone see what is happening? It's probably off by 1 (or more) errors, > but I don't see them. > > From mbishop at esoteriq.org Sat Sep 12 06:12:17 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 11 Sep 2009 23:12:17 -0500 Subject: [M3devel] Dual Pivot Quicksort problem (FIXED) In-Reply-To: <4AAB1D01.3020403@esoteriq.org> References: <4AAAF21C.5030209@esoteriq.org> <4AAB1D01.3020403@esoteriq.org> Message-ID: <4AAB1FA1.6060202@esoteriq.org> Sorry to keep posting, but I just wanted to say I fixed the problem (it isn't even in this code, it was in the insertion sort module.) Martin Bishop wrote: > Edited it some more, lots of silly mistakes in that old code. Now it > almost works...it sorts the array sometimes, but other times gives me > a bounds error. Any idea now? > > MODULE DualPivot; > > IMPORT Insertion, Fmt, IO; > > PROCEDURE Sort(VAR arr: ARRAY OF INTEGER) = > BEGIN > SortFromTo(arr, 0, NUMBER(arr)); > END Sort; > > PROCEDURE SortFromTo(VAR arr: ARRAY OF INTEGER; from, to: INTEGER) = > BEGIN > RangeCheck(NUMBER(arr), from, to); > DualPivotSort(arr, from, to - 1, 3); > END SortFromTo; > > PROCEDURE RangeCheck(len, from, to: INTEGER) RAISES {BadArgument, > IndexOutOfRange} = > BEGIN > IF from > to THEN > RAISE BadArgument(Fmt.Int(from) & " > " & Fmt.Int(to) & "\n"); > END; > IF from < 0 THEN > RAISE IndexOutOfRange("from"); > END; > IF to > len THEN > RAISE IndexOutOfRange("to"); > END; > END RangeCheck; > > PROCEDURE Swap(VAR arr: ARRAY OF INTEGER; i, j: INTEGER) = > VAR temp := arr[i]; > BEGIN > arr[i] := arr[j]; > arr[j] := temp; > END Swap; > > PROCEDURE DualPivotSort(VAR arr: ARRAY OF INTEGER; left, right, div: > INTEGER) = > VAR > len := right - left; > third := len DIV div; > m1 := left + third; > m2 := right - third; > piv1: INTEGER; > piv2: INTEGER; > less := left + 1; > great := right - 1; > dist: INTEGER; > > BEGIN > IF len < 27 THEN > Insertion.Sort(arr); > RETURN; > END; > > IF m1 <= left THEN > m1 := left + 1; > END; > > IF m2 >= right THEN > m2 := right - 1; > END; > > IO.Put("DEBUG: m1 = " & Fmt.Int(m1) & " m2 = " & Fmt.Int(m2) & > " left = " & Fmt.Int(left) & " right = " & Fmt.Int(right) & "\n"); > IO.Put("DEBUG: len = " & Fmt.Int(len) & " third = " & > Fmt.Int(third) & "\n"); > IO.Put("***\n"); > > IF arr[m1] < arr[m2] THEN > Swap(arr, m1, left); > Swap(arr, m2, right); > ELSE > Swap(arr, m1, right); > Swap(arr, m2, left); > END; > > piv1 := arr[left]; > piv2 := arr[right]; > FOR k := less TO great DO > IF arr[k] < piv1 THEN > Swap(arr, k, less); > INC(less); > ELSIF arr[k] > piv2 THEN > WHILE (k < great) AND (arr[great] > piv2) DO > DEC(great); > END; > Swap(arr, k, great); > DEC(great); > IF arr[k] < piv1 THEN > Swap(arr, k, less); > INC(less); > END; > END; > END; > > dist := great - less; > > IF dist < 13 THEN > INC(div); > END; > > Swap(arr, less - 1, left); > Swap(arr, great + 1, right); > DualPivotSort(arr, left, less - 2, div); > DualPivotSort(arr, great + 2, right, div); > IF (dist > len - 13) AND (piv1 # piv2) THEN > FOR k := less TO great DO > IF arr[k] = piv1 THEN > Swap(arr, k, less); > INC(less); > ELSIF arr[k] = piv2 THEN > Swap(arr, k, great); > DEC(great); > IF arr[k] = piv1 THEN > Swap(arr, k, less); > INC(less); > END; > END; > END; > END; > > IF piv1 < piv2 THEN > DualPivotSort(arr, less, great, div); > END; > END DualPivotSort; > > BEGIN > END DualPivot. > > Martin Bishop wrote: >> I saw a post on reddit about a Dual Pivot Quicksort, and I translated >> the code from Java to Modula-3. I have it all translated, and it >> builds, but I am having boundary issues. Somewhere on the second >> pass, the variable m2 is getting the value -2. Here's the code: >> >> ... > >> Right now when I try to run I get: >> >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "../DualPivot.m3", line 61 >> *** >> >> Line 61 is: IF arr[m1] < arr[m2] THEN >> >> Anyone see what is happening? It's probably off by 1 (or more) >> errors, but I don't see them. >> >> > > From jay.krell at cornell.edu Sat Sep 12 10:53:01 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Sep 2009 08:53:01 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30: 2009-02-16 02:30 hosking * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, RTProcessPosixC.i3: Tidy up. 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 2009-02-16 02:02 hosking * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: Expose DoWalkRef. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 22:21:44 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 12 11:26:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Sep 2009 09:26:51 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: Tony, - You didn't like how I factored InitMutex and InitCondition via InitMutexHelper? - XWait doesn't have to initialize the mutex, because it must already be locked, and therefore initialized? Or is that a "safety hole"? Unsafe module trusting safe caller to have adhered to its interface but it might not have to so unsafe code has to do extra work to preserve safety? Reasonable to ASSERT instead? Or are asserts allowed to be removed and can't be used to guarantee safety? (I put them in C code used by Modula-3, but I can perhaps make the rules there.) - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Sat, 12 Sep 2009 08:53:01 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30: 2009-02-16 02:30 hosking * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, RTProcessPosixC.i3: Tidy up. 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 2009-02-16 02:02 hosking * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: Expose DoWalkRef. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 22:21:44 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 13:38:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Sep 2009 07:38:43 -0400 Subject: [M3devel] RC merge In-Reply-To: <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> Message-ID: <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> But in this case the caller is highly privileged code that is already UNSAFE, so who cares? On 11 Sep 2009, at 23:37, jay.krell at cornell.edu wrote: > I don't like the caller to have to cast. > > - Jay (phone) > > On Sep 11, 2009, at 7:19 PM, Tony Hosking > wrote: > >> Yes, that was exactly my intention. I wasn't quite sure what your >> problem was with the code I had returning ADDRESS, but was willing >> to accede. It is "safe", but you can't use the result unless in >> UNSAFE code. >> >> Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 11 Sep 2009, at 17:33, Jay K wrote: >> >>> ps: I think there's another funny thing here: >>> I think you can have: >>> >>> INTERFACE FooInterface; >>> >>> PROCEDURE SafeFunction(); >>> PROCEDURE UnsafeFunction()=ADDRESS; >>> >>> END FooInterface. >>> >>> Despite being in a safe interface, UnsafeFunction either can't be >>> called >>> from safe code, or at least its return value can't be used? Or at >>> least >>> can't be done anything with but compare to NIL? >>> I think. >>> Therefore this interface could be said to be "partially unsafe". >>> >>> Perhaps not a useful middle ground though. >>> >>> - Jay >>> >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] RC merge >>> Date: Fri, 11 Sep 2009 21:26:00 +0000 >>> >>> Yes and no. I agree I made a small mess. I'm not sure you have >>> quite described how it should be. >>> >>> I propose a few options: >>> 1 - asis, probably not >>> 2 - rename/merge ThreadUnsafe to ThreadInternal >>> 3 - move the part that external folks use, probably just MyId, to >>> Thread, and then move ThreadUnsafe back to ThreadF, maybe >>> ThreadInternal to ThreadF too >>> >>> 2 at least removes one interface that I added, reducing the three >>> similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, >>> ThreadF and ThreadInternal >>> >>> 3 maybe gratuitously breaks folks but is a clean result >>> >>> 4 - like you said, make all ThreadF users unsafe; but IF it is >>> just MyId, and I'm not sure it is, which seems harmless, right? >>> seems wrong to make them unsafe. >>> >>> - Jay >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Fri, 11 Sep 2009 16:51:11 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] RC merge >>> >>> Sorry, it looks like my commit failed last night because of need >>> to merge with your ThreadUnsafe stuff. >>> >>> FYI, we really should think about making ThreadF UNSAFE since >>> anyone invoking on it is exposed to dangerous parts of the run- >>> time system. Is there any need for it really to be safe? >>> >>> On 11 Sep 2009, at 16:05, Jay K wrote: >>> >>> Tony I'll double check if I see the hang. NT386 still crashes. >>> >>> http://www.modula3.com/cm3/ChangeLog-2009 >>> >>> " >>> 2009-09-08 05:54 hosking >>> >>> * m3-libs/m3core/src/: convert/CConvert.m3, >>> runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, >>> runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, >>> runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, >>> runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, >>> runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, >>> runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, >>> thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, >>> thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, >>> thread/WIN32/ThreadWin32.m3: >>> >>> Tidy up use of thread.inCritical to only occur in allocation >>> sequences and in >>> thread stoppage. This simplifies reasoning. Refactored use of >>> heap lock >>> in the process. This may be better implemented on PTHREAD >>> targets using a >>> recursive pthread mutex instead of one we roll ourselves from a >>> non-recursive >>> mutex. >>> >>> Still witnessing random hangs in Juno and mentor on I386_DARWIN. >>> Strange, I thought this was working previously. >>> I wonder if there is some sort of race in the GUI code somewhere? >>> " >>> >>> ?? >>> - Jay >>> >>> >>> From: hosking at cs.purdue.edu >>> To: jay.krell at cornell.edu >>> Date: Fri, 11 Sep 2009 12:46:19 -0400 >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] RC merge >>> >>> No, the hangs in Juno and mentor are no longer there. I cannot >>> reproduce them on I386_DARWIN. >>> >>> On 11 Sep 2009, at 10:24, Jay K wrote: >>> >>> But the hangs are still present, right? Worth merging without that >>> fixed? >>> >>> How does one do it easily? >>> I wish we used Perforce. :( >>> >>> - Jay >>> >>> >>> From: hosking at cs.purdue.edu >>> To: m3devel at elegosoft.com >>> Date: Fri, 11 Sep 2009 09:45:23 -0400 >>> Subject: [M3devel] RC merge >>> >>> Can someone merge my recent deep fixes to pthreads threading over >>> to the release branch? I won't get a chance to do so until next >>> Monday at the earliest. >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue >>> University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 14:22:51 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Sep 2009 08:22:51 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: <1BBBFA10-B502-4985-9F3D-24E33D5927E6@cs.purdue.edu> On 12 Sep 2009, at 05:26, Jay K wrote: > Tony, > - You didn't like how I factored InitMutex and InitCondition via > InitMutexHelper? Please keep them separate in case implementation of Condition and Mutex diverge. I've been playing with these some lately and may yet make further changes. Having shared code makes it a real pain to change one and not the other. > - XWait doesn't have to initialize the mutex, because it must already > be locked, and therefore initialized? Or is that a "safety hole"? Just in case a client invokes Wait without holding the mutex. Perhaps better to check and die. I will adjust. > Unsafe module trusting safe caller to have adhered to its interface > but it might not have to so unsafe code has to do extra work to > preserve safety? > Reasonable to ASSERT instead? Or are asserts allowed to be removed ASSERTs can be removed by compiling without assertions for performance. > and can't be used to guarantee safety? Right. > (I put them in C code used by Modula-3, but I can perhaps make > the rules there.) C coded asserts cannot be turned off by the Modula-3 compiler. Only C compiler. > > - Jay > > > > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sat, 12 Sep 2009 08:53:01 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I believe it was this 30 minute window, 2009-02-16 02:00 - > 2009-02-16 02:30: > > 2009-02-16 02:30 hosking > > * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, > RTProcessPosixC.i3: > > Tidy up. > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > 2009-02-16 02:02 hosking > > * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: > > Expose DoWalkRef. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 22:21:44 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Hmmm. Not sure. Do you have the code diffs? > > On 11 Sep 2009, at 17:28, Jay K wrote: > > They aren't really in Trestle or ThreadWin32. > Well, right, often they are in ThreadWin32. > But not always. > I think it is, like, classic heap/stack corruption, via non-classic > "locking not working" and gc moving stuff when it shouldn't. > I don't have good evidence, but it usually NOT a hang/deadlock or > assertion failure, it is usually an access violation (aka SEGSIGV) > which as I understand must be the result of bugs in unsafe code. > > I did narrow it down a 30 minute window. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Fri, 11 Sep 2009 17:05:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I have my suspicions that ThreadWin32 may have similar latent bugs > in synchronization similar to those I have recently shaken out of > the pthreads implementation. The good thing is that my > implementation there is based in part on ThreadWin32, so it can't be > too far off. It is inevitable with concurrent code that you will > get different behavior at each run. The easiest things to debug are > thread lockups, which can usually be diagnosed by staring at dumps > of all the thread state. Harder is actual crashes like you are > observing. If assertions can be used to monitor program invariants > then it usually can be narrowed down. Unfortunately, I am not in a > position to debug the ThreadWin32 code. Any help would be > appreciated. The question is whether the crashes you see are in > Trestle or ThreadWin32. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 12 14:24:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 12 Sep 2009 08:24:48 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> Message-ID: <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> Interesting. My suspicions are that I missed something in the ThreadWin32 conversion to implement LockHeap, WaitHeap sanely. I can't debug Windows threads easily, but I strongly suggest Windows threads are in need of a rewrite to improve concurrency by making use of mutex/CVs now that Win32 supports CVs. On 12 Sep 2009, at 04:53, Jay K wrote: > I believe it was this 30 minute window, 2009-02-16 02:00 - > 2009-02-16 02:30: > > 2009-02-16 02:30 hosking > > * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, > RTProcessPosixC.i3: > > Tidy up. > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > 2009-02-16 02:02 hosking > > * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: > > Expose DoWalkRef. > > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 22:21:44 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Hmmm. Not sure. Do you have the code diffs? > > On 11 Sep 2009, at 17:28, Jay K wrote: > > They aren't really in Trestle or ThreadWin32. > Well, right, often they are in ThreadWin32. > But not always. > I think it is, like, classic heap/stack corruption, via non-classic > "locking not working" and gc moving stuff when it shouldn't. > I don't have good evidence, but it usually NOT a hang/deadlock or > assertion failure, it is usually an access violation (aka SEGSIGV) > which as I understand must be the result of bugs in unsafe code. > > I did narrow it down a 30 minute window. > > - Jay > > > From: hosking at cs.purdue.edu > To: rcoleburn at scires.com > Date: Fri, 11 Sep 2009 17:05:57 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > I have my suspicions that ThreadWin32 may have similar latent bugs > in synchronization similar to those I have recently shaken out of > the pthreads implementation. The good thing is that my > implementation there is based in part on ThreadWin32, so it can't be > too far off. It is inevitable with concurrent code that you will > get different behavior at each run. The easiest things to debug are > thread lockups, which can usually be diagnosed by staring at dumps > of all the thread state. Harder is actual crashes like you are > observing. If assertions can be used to monitor program invariants > then it usually can be narrowed down. Unfortunately, I am not in a > position to debug the ThreadWin32 code. Any help would be > appreciated. The question is whether the crashes you see are in > Trestle or ThreadWin32. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 16:54, Randy Coleburn wrote: > > Tony: > > Will any of this make any difference on Windows platform? > > I tried a couple of days ago to update all sources and rebuild. > Both Juno and Mentor still crash on both XP and Vista. If you run > multiple times, you get different crash results. (So much for > deterministic behavior.) Let me know if there is anything I can do > to help debug/test. > > Regards, > Randy > > >>> Antony Hosking 9/11/2009 10:48 PM >>> > CVSROOT:/usr/cvs > Changes by:hosking at birch.09/09/11 22:48:37 > > Modified files: > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 > > Log message: > Mentor and Juno finally work on I386_DARWIN. > ***Significant overhaul of thread alerting.*** > Invariant now is that all waiting is done on the thread's own > condition > variable. This cleanly permits signals and alerts from any other > thread. > > Need to set DISPLAY=:0.0 and xhost+ to get around problems with > DISPLAY=/tmp/launch-XXXXXX/:0. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 12 15:18:03 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Sep 2009 13:18:03 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> Message-ID: If you do that, can you make it decide at runtime to chose between a pre-Vista and Vista or newer implementation? If you want, I can create ThreadWin6.m3 that is actually identical to ThreadWin32.m3 and a runtime switch between them, and then you or maybe I can start changing ThreadWin6.m3. I'm going to try to "study" ThreadPThread.m3 to inform me on how to write both ThreadWinNoCV.m3 (fix) and ThreadWinCV.m3 (making up more names). Thanks, - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Sat, 12 Sep 2009 08:24:48 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Interesting. My suspicions are that I missed something in the ThreadWin32 conversion to implement LockHeap, WaitHeap sanely. I can't debug Windows threads easily, but I strongly suggest Windows threads are in need of a rewrite to improve concurrency by making use of mutex/CVs now that Win32 supports CVs. On 12 Sep 2009, at 04:53, Jay K wrote: I believe it was this 30 minute window, 2009-02-16 02:00 - 2009-02-16 02:30: 2009-02-16 02:30 hosking * m3-libs/m3core/src/runtime/POSIX/: RTProcessPosixC.c, RTProcessPosixC.i3: Tidy up. 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. 2009-02-16 02:02 hosking * m3-libs/m3core/src/runtime/common/RTHeapMap.i3: Expose DoWalkRef. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 22:21:44 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Hmmm. Not sure. Do you have the code diffs? On 11 Sep 2009, at 17:28, Jay K wrote: They aren't really in Trestle or ThreadWin32. Well, right, often they are in ThreadWin32. But not always. I think it is, like, classic heap/stack corruption, via non-classic "locking not working" and gc moving stuff when it shouldn't. I don't have good evidence, but it usually NOT a hang/deadlock or assertion failure, it is usually an access violation (aka SEGSIGV) which as I understand must be the result of bugs in unsafe code. I did narrow it down a 30 minute window. - Jay From: hosking at cs.purdue.edu To: rcoleburn at scires.com Date: Fri, 11 Sep 2009 17:05:57 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I have my suspicions that ThreadWin32 may have similar latent bugs in synchronization similar to those I have recently shaken out of the pthreads implementation. The good thing is that my implementation there is based in part on ThreadWin32, so it can't be too far off. It is inevitable with concurrent code that you will get different behavior at each run. The easiest things to debug are thread lockups, which can usually be diagnosed by staring at dumps of all the thread state. Harder is actual crashes like you are observing. If assertions can be used to monitor program invariants then it usually can be narrowed down. Unfortunately, I am not in a position to debug the ThreadWin32 code. Any help would be appreciated. The question is whether the crashes you see are in Trestle or ThreadWin32. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 16:54, Randy Coleburn wrote: Tony: Will any of this make any difference on Windows platform? I tried a couple of days ago to update all sources and rebuild. Both Juno and Mentor still crash on both XP and Vista. If you run multiple times, you get different crash results. (So much for deterministic behavior.) Let me know if there is anything I can do to help debug/test. Regards, Randy >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 02:16:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 00:16:00 +0000 Subject: [M3devel] AllocTraced? Message-ID: Tony, - I can confirm Darwin no longer hangs. - I'm manually merging head to release. - We have two similar functions called AllocTraced now. Any chance of renaming one or combining them into one? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 07:53:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 05:53:18 +0000 Subject: [M3devel] RC merge In-Reply-To: <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> Message-ID: Imagine you are a somewhat prolific fairly happy C or C++ programmer. The whole world is unsafe, but recieves a fair amount of static checking and is therefore largely correct and perhaps doesn't even suffer much from the lack of safety. void* GetFoo(void); void* GetBar(void); or Foo_t* GetFoo(void); Bar_t* GetBar(void); ? Definitely the second. Perhaps perhaps perhaps perhaps a function should be able to be declared to return an UNTRACED REF Foo.Something, without actually importing Foo or defining Something? Clearly the safety of an /interface/ is more subtle than a boolean. Some functions may be safe and others unsafe. Even some uses of functions. Imagine for example: PROCEDURE GetFoo(): UNTRACED REF Foo.Something; Perhas a safe function could call this function, as long as it only compares the return value to NIL? Actually storing it in a variable would require IMPORT Foo, and if FOO is declared UNSAFE, then that would pollute the caller. Or maybe merely declaring a variable of UNTRACED is enough to wreck safety? Either way, I do grant, that it probably isn't worth deciding or making any language changes whatsoever. It should suffice for programmers to partition any given bunch of code conceptual interface Foo into SAFE INTERFACE Foo and UNSAFE INTERFACE FooF or FooInternal or FooUnsafe. I think I shall rename ThreadUnsafe to ThreadInternal amd merge the two ThreadInternals into one, as long as the contents of each exist in all of them, even though, granted, there aren't callers of all of them. "Unsafe" is shorter but "Internal" seems maybe better. ThreadF will remain safe and very small. We could move its resulting lone function into Thread, but I think it isn't worth breaking any callers outside m3core. Furthermore I'll endeavor to remove ADDRESS as a return type in ThreadInternal, replacing it with actual types, in order to remove casts, and make the unsafe code get just a little bit more static safety/checking. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Sat, 12 Sep 2009 07:38:43 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge But in this case the caller is highly privileged code that is already UNSAFE, so who cares? On 11 Sep 2009, at 23:37, jay.krell at cornell.edu wrote: I don't like the caller to have to cast. - Jay (phone) On Sep 11, 2009, at 7:19 PM, Tony Hosking wrote: Yes, that was exactly my intention. I wasn't quite sure what your problem was with the code I had returning ADDRESS, but was willing to accede. It is "safe", but you can't use the result unless in UNSAFE code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Sep 2009, at 17:33, Jay K wrote: ps: I think there's another funny thing here: I think you can have: INTERFACE FooInterface; PROCEDURE SafeFunction(); PROCEDURE UnsafeFunction()=ADDRESS; END FooInterface. Despite being in a safe interface, UnsafeFunction either can't be called from safe code, or at least its return value can't be used? Or at least can't be done anything with but compare to NIL? I think. Therefore this interface could be said to be "partially unsafe". Perhaps not a useful middle ground though. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] RC merge Date: Fri, 11 Sep 2009 21:26:00 +0000 Yes and no. I agree I made a small mess. I'm not sure you have quite described how it should be. I propose a few options: 1 - asis, probably not 2 - rename/merge ThreadUnsafe to ThreadInternal 3 - move the part that external folks use, probably just MyId, to Thread, and then move ThreadUnsafe back to ThreadF, maybe ThreadInternal to ThreadF too 2 at least removes one interface that I added, reducing the three similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF and ThreadInternal 3 maybe gratuitously breaks folks but is a clean result 4 - like you said, make all ThreadF users unsafe; but IF it is just MyId, and I'm not sure it is, which seems harmless, right? seems wrong to make them unsafe. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 16:51:11 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Sorry, it looks like my commit failed last night because of need to merge with your ThreadUnsafe stuff. FYI, we really should think about making ThreadF UNSAFE since anyone invoking on it is exposed to dangerous parts of the run-time system. Is there any need for it really to be safe? On 11 Sep 2009, at 16:05, Jay K wrote: Tony I'll double check if I see the hang. NT386 still crashes. http://www.modula3.com/cm3/ChangeLog-2009 " 2009-09-08 05:54 hosking * m3-libs/m3core/src/: convert/CConvert.m3, runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, thread/WIN32/ThreadWin32.m3: Tidy up use of thread.inCritical to only occur in allocation sequences and in thread stoppage. This simplifies reasoning. Refactored use of heap lock in the process. This may be better implemented on PTHREAD targets using a recursive pthread mutex instead of one we roll ourselves from a non-recursive mutex. Still witnessing random hangs in Juno and mentor on I386_DARWIN. Strange, I thought this was working previously. I wonder if there is some sort of race in the GUI code somewhere? " ??- Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 11 Sep 2009 12:46:19 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] RC merge No, the hangs in Juno and mentor are no longer there. I cannot reproduce them on I386_DARWIN. On 11 Sep 2009, at 10:24, Jay K wrote: But the hangs are still present, right? Worth merging without that fixed? How does one do it easily? I wish we used Perforce. :( - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Fri, 11 Sep 2009 09:45:23 -0400 Subject: [M3devel] RC merge Can someone merge my recent deep fixes to pthreads threading over to the release branch? I won't get a chance to do so until next Monday at the earliest. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbishop at esoteriq.org Sun Sep 13 08:06:31 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Sun, 13 Sep 2009 01:06:31 -0500 Subject: [M3devel] Generic Dual Pivot Quicksort Message-ID: <4AAC8BE7.4010906@esoteriq.org> I wrote a generic version of Vladimir Yaroslavskiy's Dual Pivot Quicksort (http://permalink.gmane.org/gmane.comp.java.openjdk.core-libs.devel/2628) There's no known errors, but let me know if you find any. http://mbishop.esoteriq.org/code/Modula-3/GenericDualPivot/ From jay.krell at cornell.edu Sun Sep 13 15:51:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 13:51:02 +0000 Subject: [M3devel] RC merge In-Reply-To: <20090913094450.31FEA1A207D@async.async.caltech.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> Message-ID: The functions are meant to be unsafe either way. ThreadF.i3 clearly had a safety hole before, but not due to the functions "in question". Good point about passing in ADDRESSes..but I'm not entirely sure I understand/agree. Can safe code ("directly") generate any ADDRESSes at all? Or only get them from unsafe code in the first place? ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? I'll check. IF safe code CAN generate ADDRESSes, then this was a hole: PROCEDURE SetCurrentHandlers(h: ADDRESS); and perhaps these: PROCEDURE SuspendOthers (); (* Suspend all threads except the caller's *) PROCEDURE ResumeOthers (); Though probably not the second, since safe code can trivially hang/deadlock on its own. The public safe ThreadF.i3 now just: (*-------------------------------------------------- showthreads support ---*) TYPE State = { alive (* can run *), waiting (* waiting for a condition via Wait *), locking (* waiting for a mutex to be unlocked *), pausing (* waiting until some time is arrived *), blocking (* waiting for some IO *), dying (* done, but not yet joined *), dead (* done and joined *) }; (*-------------------------------------------------------------- identity ---*) TYPE Id = INTEGER; PROCEDURE MyId(): Id RAISES {}; (* return Id of caller *) Everything else I moved to the non-public ThreadInternal.i3. > But in Modula-3 whether an interface is unsafe or not *is* a boolean. Understood, but I still think even in unsafe code, LOOPHOLE should be minimized. C and C++ programmers are often taught to minimize casts, esp. reinterpret_cast. I think that guidance carries over to Modula's LOOPHOLE, even if you are already unsafe for other reasons. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > Date: Sun, 13 Sep 2009 02:44:50 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: > ... > > > >Imagine you are a somewhat prolific fairly happy C or C++ programmer. The w= > >hole world is unsafe=2C but recieves a fair amount of static checking and i= > >s therefore largely correct and perhaps doesn't even suffer much from the l= > >ack of safety. > > > >=20 > > > > void* GetFoo(void)=3B=20 > > > > void* GetBar(void)=3B=20 > > > >=20 > > > >or > > > >=20 > > > > Foo_t* GetFoo(void)=3B=20 > > > > Bar_t* GetBar(void)=3B=20 > > > >=20 > > > >? > > > >=20 > > > >Definitely the second. > > > >=20 > > > >Perhaps perhaps perhaps perhaps a function should be able to be declared to= > > return an UNTRACED REF Foo.Something=2C without actually importing Foo or = > >defining Something? > > > >=20 > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > >Some functions may be safe and others unsafe. > > > >Even some uses of functions. > > > >Imagine for example: > > > >=20 > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > >=20 > > > >Perhas a safe function could call this function=2C as long as it only compa= > >res the return value to NIL? > > > >Actually storing it in a variable would require IMPORT Foo=2C and if FOO is= > > declared UNSAFE=2C then that would > > > >pollute the caller. Or maybe merely declaring a variable of UNTRACED is eno= > >ugh to wreck safety? > > But in Modula-3 whether an interface is unsafe or not *is* a boolean. > It's very clearly defined what it means in the Green Book. > > If you don't declare your GetFoo as UNSAFE you can write > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > in safe code. > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > it's safer, if there's a safety problem with manipulating the fields. > > An interface can hardly assume that it is the only one injecting objects > of type ADDRESS into the "safe world" so if you're allowing the safe world > to pass these objects back in your interface you have to sanity-check > them anyhow. You do not, however, need to worry about the fields having > been changed by the safe code. > > If you need some more subtle properties than that you probably ought > to be writing UNSAFE code in the first place. Or is there some trickery > you can do along the lines of what we came up with for small integers > in pointers? > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 19:11:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 17:11:59 +0000 Subject: [M3devel] RC merge In-Reply-To: <20090913161207.2AB3B1A207D@async.async.caltech.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <20090913161207.2AB3B1A207D@async.async.caltech.edu> Message-ID: Good point, previously I could say SetCurrentHandlers(MyFPState()) in safe code. Now you can't. There's still ADDRESS used in ThreadInternal.i3 requiring LOOPHOLE but it doesn't appear easy to fix. > Arguably, hanging other threads (with which one does not share mutexes etc) Mutexes aren't the entire story there I think. Imagine some homegrown spinlock that is exported?? In either case, these functions are moved to an unsafe interface, at least until/unless some safe code needs them. Thanks, - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > Date: Sun, 13 Sep 2009 09:12:07 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: > >--_11d51f7d-f47a-4693-89d2-6f3429314a09_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > ... > >Good point about passing in ADDRESSes..but I'm not entirely sure I understa= > >nd/agree. > >Can safe code ("directly") generate any ADDRESSes at all? Or only get them = > >from > >unsafe code in the first place? > >ADDRESS only comes from ADR=2C right? And ADR isn't allowed in safe? I'll c= > >heck. > > > >IF safe code CAN generate ADDRESSes=2C then this was a hole: > >PROCEDURE SetCurrentHandlers(h: ADDRESS)=3B > > > No safe code can't generate ADDRESSes without help. But certainly > safe code can import TWO of these "quasi-unsafe" interfaces, and mix > up which address came whence... so your example is probably still > unsafe. > > > > >and perhaps these: > >PROCEDURE SuspendOthers ()=3B > >(* Suspend all threads except the caller's *) > > > >PROCEDURE ResumeOthers ()=3B > > > >Though probably not the second=2C since safe code can trivially hang/deadlo= > >ck on its own. > > Yes hanging is not a safety violation by the Modula-3 definition. > Arguably, hanging other threads (with which one does not share mutexes etc) > perhaps should be a safety violation, but can it be guaranteed? > > ... > > > >> But in Modula-3 whether an interface is unsafe or not *is* a boolean. > > > >Understood=2C but I still think even in unsafe code=2C LOOPHOLE should be m= > >inimized. > >C and C++ programmers are often taught to minimize casts=2C esp. reinterpre= > >t_cast. > >I think that guidance carries over to Modula's LOOPHOLE=2C even if you are = > >already unsafe > >for other reasons. > > Agreed! > > Mika > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 13 19:39:39 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 13:39:39 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> Message-ID: ThreadF has always been a non-standard, internal, "unpublished", non- standard interface. At one point it wasn't even shipped (interface not Interface). Anyway, my argument was that as such we could freely leave it as it was. I would argue that ordinary programmers should never even use it (it contains some very nasty low-level code like the GC suspend routines). On 13 Sep 2009, at 01:53, Jay K wrote: > Imagine you are a somewhat prolific fairly happy C or C++ > programmer. The whole world is unsafe, but recieves a fair amount of > static checking and is therefore largely correct and perhaps doesn't > even suffer much from the lack of safety. > > void* GetFoo(void); > void* GetBar(void); > > or > > Foo_t* GetFoo(void); > Bar_t* GetBar(void); > > ? > > Definitely the second. > > Perhaps perhaps perhaps perhaps a function should be able to be > declared to return an UNTRACED REF Foo.Something, without actually > importing Foo or defining Something? > > Clearly the safety of an /interface/ is more subtle than a boolean. > Some functions may be safe and others unsafe. > Even some uses of functions. > Imagine for example: > > PROCEDURE GetFoo(): UNTRACED REF Foo.Something; > > Perhas a safe function could call this function, as long as it only > compares the return value to NIL? > Actually storing it in a variable would require IMPORT Foo, and if > FOO is declared UNSAFE, then that would > pollute the caller. Or maybe merely declaring a variable of UNTRACED > is enough to wreck safety? > > Either way, I do grant, that it probably isn't worth deciding or > making any language changes whatsoever. > > It should suffice for programmers to partition any given bunch of > code conceptual interface Foo > > into SAFE INTERFACE Foo and UNSAFE INTERFACE FooF or FooInternal or > FooUnsafe. > > I think I shall rename ThreadUnsafe to ThreadInternal amd merge the > two ThreadInternals into one, > as long as the contents of each exist in all of them, even though, > granted, there > aren't callers of all of them. > "Unsafe" is shorter but "Internal" seems maybe better. > > ThreadF will remain safe and very small. > We could move its resulting lone function into Thread, but I think > it isn't worth breaking > any callers outside m3core. > > Furthermore I'll endeavor to remove ADDRESS as a return type in > ThreadInternal, replacing > it with actual types, in order to remove casts, and make the unsafe > code get just a little > bit more static safety/checking. > > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sat, 12 Sep 2009 07:38:43 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > But in this case the caller is highly privileged code that is > already UNSAFE, so who cares? > > On 11 Sep 2009, at 23:37, jay.krell at cornell.edu wrote: > > I don't like the caller to have to cast. > > - Jay (phone) > > On Sep 11, 2009, at 7:19 PM, Tony Hosking > wrote: > > Yes, that was exactly my intention. I wasn't quite sure what your > problem was with the code I had returning ADDRESS, but was willing > to accede. It is "safe", but you can't use the result unless in > UNSAFE code. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 11 Sep 2009, at 17:33, Jay K wrote: > > ps: I think there's another funny thing here: > I think you can have: > > INTERFACE FooInterface; > > PROCEDURE SafeFunction(); > PROCEDURE UnsafeFunction()=ADDRESS; > > END FooInterface. > > Despite being in a safe interface, UnsafeFunction either can't be > called > from safe code, or at least its return value can't be used? Or at > least > can't be done anything with but compare to NIL? > I think. > Therefore this interface could be said to be "partially unsafe". > > Perhaps not a useful middle ground though. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] RC merge > Date: Fri, 11 Sep 2009 21:26:00 +0000 > > Yes and no. I agree I made a small mess. I'm not sure you have quite > described how it should be. > > I propose a few options: > 1 - asis, probably not > 2 - rename/merge ThreadUnsafe to ThreadInternal > 3 - move the part that external folks use, probably just MyId, to > Thread, and then move ThreadUnsafe back to ThreadF, maybe > ThreadInternal to ThreadF too > > 2 at least removes one interface that I added, reducing the three > similar ThreadF, ThreadUnsafe, ThreadInternal, to just two, ThreadF > and ThreadInternal > > 3 maybe gratuitously breaks folks but is a clean result > > 4 - like you said, make all ThreadF users unsafe; but IF it is just > MyId, and I'm not sure it is, which seems harmless, right? seems > wrong to make them unsafe. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 16:51:11 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Sorry, it looks like my commit failed last night because of need to > merge with your ThreadUnsafe stuff. > > FYI, we really should think about making ThreadF UNSAFE since anyone > invoking on it is exposed to dangerous parts of the run-time > system. Is there any need for it really to be safe? > > On 11 Sep 2009, at 16:05, Jay K wrote: > > Tony I'll double check if I see the hang. NT386 still crashes. > > http://www.modula3.com/cm3/ChangeLog-2009 > > " > 2009-09-08 05:54 hosking > > * m3-libs/m3core/src/: convert/CConvert.m3, > runtime/common/RTAllocator.m3, runtime/common/RTCollector.m3, > runtime/common/RTCollectorSRC.i3, runtime/common/RTHeapInfo.m3, > runtime/common/RTHeapRep.i3, runtime/common/RTHeapRep.m3, > runtime/common/RTHeapStats.m3, runtime/common/RTLinker.m3, > runtime/common/RTOS.i3, runtime/ex_frame/RTExFrame.m3, > runtime/ex_stack/RTExStack.m3, thread/POSIX/ThreadF.i3, > thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, > thread/PTHREAD/ThreadPThread.m3, thread/WIN32/ThreadF.i3, > thread/WIN32/ThreadWin32.m3: > > Tidy up use of thread.inCritical to only occur in allocation > sequences and in > thread stoppage. This simplifies reasoning. Refactored use of > heap lock > in the process. This may be better implemented on PTHREAD targets > using a > recursive pthread mutex instead of one we roll ourselves from a > non-recursive > mutex. > > Still witnessing random hangs in Juno and mentor on I386_DARWIN. > Strange, I thought this was working previously. > I wonder if there is some sort of race in the GUI code somewhere? > " > > ?? > - Jay > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Fri, 11 Sep 2009 12:46:19 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > No, the hangs in Juno and mentor are no longer there. I cannot > reproduce them on I386_DARWIN. > > On 11 Sep 2009, at 10:24, Jay K wrote: > > But the hangs are still present, right? Worth merging without that > fixed? > > How does one do it easily? > I wish we used Perforce. :( > > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Fri, 11 Sep 2009 09:45:23 -0400 > Subject: [M3devel] RC merge > > Can someone merge my recent deep fixes to pthreads threading over to > the release branch? I won't get a chance to do so until next Monday > at the earliest. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 13 19:43:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 13:43:48 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> Message-ID: <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> Safe code can't do anything with a value of type ADDRESS except pass it around. It must use unsafe operations (NARROW) to turn it into something usable. I think you misunderstood ThreadF in the first place. It has always been logically unsafe, if not UNSAFE. I don't want ThreadF ever to come to be something that people outside the runtime system rely on. The Id type and MyId function is simply a convenience, but not and never has been part of the standard interfaces. Can we please just revert back to the way it has always been? On 13 Sep 2009, at 09:51, Jay K wrote: > The functions are meant to be unsafe either way. > ThreadF.i3 clearly had a safety hole before, but not due to the > functions "in question". > > Good point about passing in ADDRESSes..but I'm not entirely sure I > understand/agree. > Can safe code ("directly") generate any ADDRESSes at all? Or only > get them from > unsafe code in the first place? > ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? > I'll check. > > IF safe code CAN generate ADDRESSes, then this was a hole: > PROCEDURE SetCurrentHandlers(h: ADDRESS); > > and perhaps these: > PROCEDURE SuspendOthers (); > (* Suspend all threads except the caller's *) > > PROCEDURE ResumeOthers (); > > Though probably not the second, since safe code can trivially hang/ > deadlock on its own. > > The public safe ThreadF.i3 now just: > > (*-------------------------------------------------- showthreads > support ---*) > > TYPE > State = { > alive (* can run *), > waiting (* waiting for a condition via Wait *), > locking (* waiting for a mutex to be unlocked *), > pausing (* waiting until some time is arrived *), > blocking (* waiting for some IO *), > dying (* done, but not yet joined *), > dead (* done and joined *) > }; > > (*-------------------------------------------------------------- > identity ---*) > > TYPE > Id = INTEGER; > > PROCEDURE MyId(): Id RAISES {}; > (* return Id of caller *) > > > Everything else I moved to the non-public ThreadInternal.i3. > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > Understood, but I still think even in unsafe code, LOOPHOLE should > be minimized. > C and C++ programmers are often taught to minimize casts, esp. > reinterpret_cast. > I think that guidance carries over to Modula's LOOPHOLE, even if you > are already unsafe > for other reasons. > > - Jay > > > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] RC merge > > Date: Sun, 13 Sep 2009 02:44:50 -0700 > > From: mika at async.async.caltech.edu > > > > Jay K writes: > > ... > > > > > >Imagine you are a somewhat prolific fairly happy C or C++ > programmer. The w= > > >hole world is unsafe=2C but recieves a fair amount of static > checking and i= > > >s therefore largely correct and perhaps doesn't even suffer much > from the l= > > >ack of safety. > > > > > >=20 > > > > > > void* GetFoo(void)=3B=20 > > > > > > void* GetBar(void)=3B=20 > > > > > >=20 > > > > > >or > > > > > >=20 > > > > > > Foo_t* GetFoo(void)=3B=20 > > > > > > Bar_t* GetBar(void)=3B=20 > > > > > >=20 > > > > > >? > > > > > >=20 > > > > > >Definitely the second. > > > > > >=20 > > > > > >Perhaps perhaps perhaps perhaps a function should be able to be > declared to= > > > return an UNTRACED REF Foo.Something=2C without actually > importing Foo or = > > >defining Something? > > > > > >=20 > > > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > > > >Some functions may be safe and others unsafe. > > > > > >Even some uses of functions. > > > > > >Imagine for example: > > > > > >=20 > > > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > > > >=20 > > > > > >Perhas a safe function could call this function=2C as long as it > only compa= > > >res the return value to NIL? > > > > > >Actually storing it in a variable would require IMPORT Foo=2C and > if FOO is= > > > declared UNSAFE=2C then that would > > > > > >pollute the caller. Or maybe merely declaring a variable of > UNTRACED is eno= > > >ugh to wreck safety? > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > It's very clearly defined what it means in the Green Book. > > > > If you don't declare your GetFoo as UNSAFE you can write > > > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > > > in safe code. > > > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > > it's safer, if there's a safety problem with manipulating the > fields. > > > > An interface can hardly assume that it is the only one injecting > objects > > of type ADDRESS into the "safe world" so if you're allowing the > safe world > > to pass these objects back in your interface you have to sanity- > check > > them anyhow. You do not, however, need to worry about the fields > having > > been changed by the safe code. > > > > If you need some more subtle properties than that you probably ought > > to be writing UNSAFE code in the first place. Or is there some > trickery > > you can do along the lines of what we came up with for small > integers > > in pointers? > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 13 20:02:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 13 Sep 2009 18:02:24 +0000 Subject: [M3devel] RC merge In-Reply-To: <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> Message-ID: > The Id type and MyId function is simply a convenience But what do we do about it? It is out there and being used. It ought not have been, but it was and is. The safety hole SetCurrentHandlers(WhateverState()) was also out there as I understand. Should break the existing users? And/or move MyId to Thread.i3? Or ThreadFSafe.i3? I really don't think the way it was is the best choice. At the very least, ThreadF should either be interface instead of Interface and/or UNSAFE. But those options have the collateral damage of breaking users of ThreadF.MyId. I chose a route that doesn't have that damage and contains any churn to within m3core. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Sun, 13 Sep 2009 13:43:48 -0400 CC: mika at async.async.caltech.edu; m3devel at elegosoft.com Subject: Re: [M3devel] RC merge Safe code can't do anything with a value of type ADDRESS except pass it around. It must use unsafe operations (NARROW) to turn it into something usable. I think you misunderstood ThreadF in the first place. It has always been logically unsafe, if not UNSAFE. I don't want ThreadF ever to come to be something that people outside the runtime system rely on. The Id type and MyId function is simply a convenience, but not and never has been part of the standard interfaces. Can we please just revert back to the way it has always been? On 13 Sep 2009, at 09:51, Jay K wrote:The functions are meant to be unsafe either way. ThreadF.i3 clearly had a safety hole before, but not due to the functions "in question". Good point about passing in ADDRESSes..but I'm not entirely sure I understand/agree. Can safe code ("directly") generate any ADDRESSes at all? Or only get them from unsafe code in the first place? ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? I'll check. IF safe code CAN generate ADDRESSes, then this was a hole: PROCEDURE SetCurrentHandlers(h: ADDRESS); and perhaps these: PROCEDURE SuspendOthers (); (* Suspend all threads except the caller's *) PROCEDURE ResumeOthers (); Though probably not the second, since safe code can trivially hang/deadlock on its own. The public safe ThreadF.i3 now just: (*-------------------------------------------------- showthreads support ---*) TYPE State = { alive (* can run *), waiting (* waiting for a condition via Wait *), locking (* waiting for a mutex to be unlocked *), pausing (* waiting until some time is arrived *), blocking (* waiting for some IO *), dying (* done, but not yet joined *), dead (* done and joined *) }; (*-------------------------------------------------------------- identity ---*) TYPE Id = INTEGER; PROCEDURE MyId(): Id RAISES {}; (* return Id of caller *) Everything else I moved to the non-public ThreadInternal.i3. > But in Modula-3 whether an interface is unsafe or not *is* a boolean. Understood, but I still think even in unsafe code, LOOPHOLE should be minimized. C and C++ programmers are often taught to minimize casts, esp. reinterpret_cast. I think that guidance carries over to Modula's LOOPHOLE, even if you are already unsafe for other reasons. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > Date: Sun, 13 Sep 2009 02:44:50 -0700 > From: mika at async.async.caltech.edu > > Jay K writes: > ... > > > >Imagine you are a somewhat prolific fairly happy C or C++ programmer. The w= > >hole world is unsafe=2C but recieves a fair amount of static checking and i= > >s therefore largely correct and perhaps doesn't even suffer much from the l= > >ack of safety. > > > >=20 > > > > void* GetFoo(void)=3B=20 > > > > void* GetBar(void)=3B=20 > > > >=20 > > > >or > > > >=20 > > > > Foo_t* GetFoo(void)=3B=20 > > > > Bar_t* GetBar(void)=3B=20 > > > >=20 > > > >? > > > >=20 > > > >Definitely the second. > > > >=20 > > > >Perhaps perhaps perhaps perhaps a function should be able to be declared to= > > return an UNTRACED REF Foo.Something=2C without actually importing Foo or = > >defining Something? > > > >=20 > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > >Some functions may be safe and others unsafe. > > > >Even some uses of functions. > > > >Imagine for example: > > > >=20 > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > >=20 > > > >Perhas a safe function could call this function=2C as long as it only compa= > >res the return value to NIL? > > > >Actually storing it in a variable would require IMPORT Foo=2C and if FOO is= > > declared UNSAFE=2C then that would > > > >pollute the caller. Or maybe merely declaring a variable of UNTRACED is eno= > >ugh to wreck safety? > > But in Modula-3 whether an interface is unsafe or not *is* a boolean. > It's very clearly defined what it means in the Green Book. > > If you don't declare your GetFoo as UNSAFE you can write > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > in safe code. > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > it's safer, if there's a safety problem with manipulating the fields. > > An interface can hardly assume that it is the only one injecting objects > of type ADDRESS into the "safe world" so if you're allowing the safe world > to pass these objects back in your interface you have to sanity-check > them anyhow. You do not, however, need to worry about the fields having > been changed by the safe code. > > If you need some more subtle properties than that you probably ought > to be writing UNSAFE code in the first place. Or is there some trickery > you can do along the lines of what we came up with for small integers > in pointers? > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 13 20:34:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 14:34:36 -0400 Subject: [M3devel] RC merge In-Reply-To: References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> Message-ID: <78CFFD41-8D5D-4E4C-9A9D-A7DD29DB95A9@cs.purdue.edu> I'm happy with what you have done (small safe ThreadF, internal unsafe ThreadInternal). Thanks. On 13 Sep 2009, at 14:02, Jay K wrote: > > The Id type and MyId function is simply a convenience > > But what do we do about it? > It is out there and being used. > It ought not have been, but it was and is. > > The safety hole SetCurrentHandlers(WhateverState()) was also out > there as I understand. > > Should break the existing users? > And/or move MyId to Thread.i3? > Or ThreadFSafe.i3? > > I really don't think the way it was is the best choice. > At the very least, ThreadF should either be interface instead of > Interface and/or UNSAFE. > But those options have the collateral damage of breaking users of > ThreadF.MyId. > I chose a route that doesn't have that damage and contains any churn > to within m3core. > > - Jay > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Sun, 13 Sep 2009 13:43:48 -0400 > CC: mika at async.async.caltech.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] RC merge > > Safe code can't do anything with a value of type ADDRESS except pass > it around. It must use unsafe operations (NARROW) to turn it into > something usable. > > I think you misunderstood ThreadF in the first place. It has always > been logically unsafe, if not UNSAFE. I don't want ThreadF ever to > come to be something that people outside the runtime system rely > on. The Id type and MyId function is simply a convenience, but not > and never has been part of the standard interfaces. > > Can we please just revert back to the way it has always been? > > On 13 Sep 2009, at 09:51, Jay K wrote: > > The functions are meant to be unsafe either way. > ThreadF.i3 clearly had a safety hole before, but not due to the > functions "in question". > > Good point about passing in ADDRESSes..but I'm not entirely sure I > understand/agree. > Can safe code ("directly") generate any ADDRESSes at all? Or only > get them from > unsafe code in the first place? > ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? > I'll check. > > IF safe code CAN generate ADDRESSes, then this was a hole: > PROCEDURE SetCurrentHandlers(h: ADDRESS); > > and perhaps these: > PROCEDURE SuspendOthers (); > (* Suspend all threads except the caller's *) > > PROCEDURE ResumeOthers (); > > Though probably not the second, since safe code can trivially hang/ > deadlock on its own. > > The public safe ThreadF.i3 now just: > > (*-------------------------------------------------- showthreads > support ---*) > > TYPE > State = { > alive (* can run *), > waiting (* waiting for a condition via Wait *), > locking (* waiting for a mutex to be unlocked *), > pausing (* waiting until some time is arrived *), > blocking (* waiting for some IO *), > dying (* done, but not yet joined *), > dead (* done and joined *) > }; > > (*-------------------------------------------------------------- > identity ---*) > > TYPE > Id = INTEGER; > > PROCEDURE MyId(): Id RAISES {}; > (* return Id of caller *) > > > Everything else I moved to the non-public ThreadInternal.i3. > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > Understood, but I still think even in unsafe code, LOOPHOLE should > be minimized. > C and C++ programmers are often taught to minimize casts, esp. > reinterpret_cast. > I think that guidance carries over to Modula's LOOPHOLE, even if you > are already unsafe > for other reasons. > > - Jay > > > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] RC merge > > Date: Sun, 13 Sep 2009 02:44:50 -0700 > > From: mika at async.async.caltech.edu > > > > Jay K writes: > > ... > > > > > >Imagine you are a somewhat prolific fairly happy C or C++ > programmer. The w= > > >hole world is unsafe=2C but recieves a fair amount of static > checking and i= > > >s therefore largely correct and perhaps doesn't even suffer much > from the l= > > >ack of safety. > > > > > >=20 > > > > > > void* GetFoo(void)=3B=20 > > > > > > void* GetBar(void)=3B=20 > > > > > >=20 > > > > > >or > > > > > >=20 > > > > > > Foo_t* GetFoo(void)=3B=20 > > > > > > Bar_t* GetBar(void)=3B=20 > > > > > >=20 > > > > > >? > > > > > >=20 > > > > > >Definitely the second. > > > > > >=20 > > > > > >Perhaps perhaps perhaps perhaps a function should be able to be > declared to= > > > return an UNTRACED REF Foo.Something=2C without actually > importing Foo or = > > >defining Something? > > > > > >=20 > > > > > >Clearly the safety of an /interface/ is more subtle than a boolean. > > > > > >Some functions may be safe and others unsafe. > > > > > >Even some uses of functions. > > > > > >Imagine for example: > > > > > >=20 > > > > > >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B > > > > > >=20 > > > > > >Perhas a safe function could call this function=2C as long as it > only compa= > > >res the return value to NIL? > > > > > >Actually storing it in a variable would require IMPORT Foo=2C and > if FOO is= > > > declared UNSAFE=2C then that would > > > > > >pollute the caller. Or maybe merely declaring a variable of > UNTRACED is eno= > > >ugh to wreck safety? > > > > But in Modula-3 whether an interface is unsafe or not *is* a > boolean. > > It's very clearly defined what it means in the Green Book. > > > > If you don't declare your GetFoo as UNSAFE you can write > > > > VAR x := GetFoo; BEGIN (* manipulate fields of x *) END > > > > in safe code. > > > > Declaring GetFoo to return ADDRESS won't let you do that. Hence, > > it's safer, if there's a safety problem with manipulating the > fields. > > > > An interface can hardly assume that it is the only one injecting > objects > > of type ADDRESS into the "safe world" so if you're allowing the > safe world > > to pass these objects back in your interface you have to sanity- > check > > them anyhow. You do not, however, need to worry about the fields > having > > been changed by the safe code. > > > > If you need some more subtle properties than that you probably ought > > to be writing UNSAFE code in the first place. Or is there some > trickery > > you can do along the lines of what we came up with for small > integers > > in pointers? > > > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 14 00:07:05 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 13 Sep 2009 18:07:05 -0400 Subject: [M3devel] RC merge In-Reply-To: <20090913203005.67D011A2079@async.async.caltech.edu> References: <0241AAC4-5234-4B3D-A4F2-0C717F923959@cs.purdue.edu> <43B056F1-48AE-4F06-B692-E551695F357B@cs.purdue.edu> <5C287F1D-ECB9-47CA-817D-2D8F2CB47705@hotmail.com> <6D8D5191-BC36-4B04-ACBA-F322BA41509A@cs.purdue.edu> <20090913094450.31FEA1A207D@async.async.caltech.edu> <97231273-F4E2-4BB2-8B88-7AFA20F2CDCD@cs.purdue.edu> <20090913203005.67D011A2079@async.async.caltech.edu> Message-ID: <0B34162D-0E83-4163-ADF3-405FC0571731@cs.purdue.edu> It will stay in ThreadF. On 13 Sep 2009, at 16:30, Mika Nystrom wrote: > > ThreadF.MyId is something I have used in otherwise perfectly safe > code, > hope it doesn't go away! It's very nice to be able to distinguish > threads from each other without extra effort from the programmer. Is > this something that is sometimes hard to provide? > > Mika > > > Tony Hosking writes: >> >> --Apple-Mail-18--321278784 >> Content-Type: text/plain; >> charset=US-ASCII; >> format=flowed; >> delsp=yes >> Content-Transfer-Encoding: 7bit >> >> Safe code can't do anything with a value of type ADDRESS except pass >> it around. It must use unsafe operations (NARROW) to turn it into >> something usable. >> >> I think you misunderstood ThreadF in the first place. It has always >> been logically unsafe, if not UNSAFE. I don't want ThreadF ever to >> come to be something that people outside the runtime system rely on. >> The Id type and MyId function is simply a convenience, but not and >> never has been part of the standard interfaces. >> >> Can we please just revert back to the way it has always been? >> >> On 13 Sep 2009, at 09:51, Jay K wrote: >> >>> The functions are meant to be unsafe either way. >>> ThreadF.i3 clearly had a safety hole before, but not due to the >>> functions "in question". >>> >>> Good point about passing in ADDRESSes..but I'm not entirely sure I >>> understand/agree. >>> Can safe code ("directly") generate any ADDRESSes at all? Or only >>> get them from >>> unsafe code in the first place? >>> ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? >>> I'll check. >>> >>> IF safe code CAN generate ADDRESSes, then this was a hole: >>> PROCEDURE SetCurrentHandlers(h: ADDRESS); >>> >>> and perhaps these: >>> PROCEDURE SuspendOthers (); >>> (* Suspend all threads except the caller's *) >>> >>> PROCEDURE ResumeOthers (); >>> >>> Though probably not the second, since safe code can trivially hang/ >>> deadlock on its own. >>> >>> The public safe ThreadF.i3 now just: >>> >>> (*-------------------------------------------------- showthreads >>> support ---*) >>> >>> TYPE >>> State = { >>> alive (* can run *), >>> waiting (* waiting for a condition via Wait *), >>> locking (* waiting for a mutex to be unlocked *), >>> pausing (* waiting until some time is arrived *), >>> blocking (* waiting for some IO *), >>> dying (* done, but not yet joined *), >>> dead (* done and joined *) >>> }; >>> >>> (*-------------------------------------------------------------- >>> identity ---*) >>> >>> TYPE >>> Id = INTEGER; >>> >>> PROCEDURE MyId(): Id RAISES {}; >>> (* return Id of caller *) >>> >>> >>> Everything else I moved to the non-public ThreadInternal.i3. >>> >>> >>>> But in Modula-3 whether an interface is unsafe or not *is* a >>> boolean. >>> >>> Understood, but I still think even in unsafe code, LOOPHOLE should >>> be minimized. >>> C and C++ programmers are often taught to minimize casts, esp. >>> reinterpret_cast. >>> I think that guidance carries over to Modula's LOOPHOLE, even if you >>> are already unsafe >>> for other reasons. >>> >>> - Jay >>> >>> >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] RC merge >>>> Date: Sun, 13 Sep 2009 02:44:50 -0700 >>>> From: mika at async.async.caltech.edu >>>> >>>> Jay K writes: >>>> ... >>>>> >>>>> Imagine you are a somewhat prolific fairly happy C or C++ >>> programmer. The w= >>>>> hole world is unsafe=2C but recieves a fair amount of static >>> checking and i= >>>>> s therefore largely correct and perhaps doesn't even suffer much >>> from the l= >>>>> ack of safety. >>>>> >>>>> =20 >>>>> >>>>> void* GetFoo(void)=3B=20 >>>>> >>>>> void* GetBar(void)=3B=20 >>>>> >>>>> =20 >>>>> >>>>> or >>>>> >>>>> =20 >>>>> >>>>> Foo_t* GetFoo(void)=3B=20 >>>>> >>>>> Bar_t* GetBar(void)=3B=20 >>>>> >>>>> =20 >>>>> >>>>> ? >>>>> >>>>> =20 >>>>> >>>>> Definitely the second. >>>>> >>>>> =20 >>>>> >>>>> Perhaps perhaps perhaps perhaps a function should be able to be >>> declared to= >>>>> return an UNTRACED REF Foo.Something=2C without actually >>> importing Foo or = >>>>> defining Something? >>>>> >>>>> =20 >>>>> >>>>> Clearly the safety of an /interface/ is more subtle than a >>>>> boolean. >>>>> >>>>> Some functions may be safe and others unsafe. >>>>> >>>>> Even some uses of functions. >>>>> >>>>> Imagine for example: >>>>> >>>>> =20 >>>>> >>>>> PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B >>>>> >>>>> =20 >>>>> >>>>> Perhas a safe function could call this function=2C as long as it >>> only compa= >>>>> res the return value to NIL? >>>>> >>>>> Actually storing it in a variable would require IMPORT Foo=2C and >>> if FOO is= >>>>> declared UNSAFE=2C then that would >>>>> >>>>> pollute the caller. Or maybe merely declaring a variable of >>> UNTRACED is eno= >>>>> ugh to wreck safety? >>>> >>>> But in Modula-3 whether an interface is unsafe or not *is* a >>> boolean. >>>> It's very clearly defined what it means in the Green Book. >>>> >>>> If you don't declare your GetFoo as UNSAFE you can write >>>> >>>> VAR x := GetFoo; BEGIN (* manipulate fields of x *) END >>>> >>>> in safe code. >>>> >>>> Declaring GetFoo to return ADDRESS won't let you do that. Hence, >>>> it's safer, if there's a safety problem with manipulating the >>> fields. >>>> >>>> An interface can hardly assume that it is the only one injecting >>> objects >>>> of type ADDRESS into the "safe world" so if you're allowing the >>> safe world >>>> to pass these objects back in your interface you have to sanity- >>> check >>>> them anyhow. You do not, however, need to worry about the fields >>> having >>>> been changed by the safe code. >>>> >>>> If you need some more subtle properties than that you probably >>>> ought >>>> to be writing UNSAFE code in the first place. Or is there some >>> trickery >>>> you can do along the lines of what we came up with for small >>> integers >>>> in pointers? >>>> >>>> Mika >> >> >> --Apple-Mail-18--321278784 >> Content-Type: text/html; >> charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable >> >> > space; = >> -webkit-line-break: after-white-space; ">
> apple-content-edited=3D"true">> style=3D"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; ">
> break-word; -webkit-nbsp-mode: space; -webkit-line-break: = >> after-white-space; ">> style=3D"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; >> ">
> style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = >> -webkit-line-break: after-white-space; ">> span" = >> style=3D"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; >> ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">> class=3D"Apple-style-span" style=3D"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; ">
> class=3D"Apple-style-span" style=3D"font-size: medium;">> class=3D"Apple-style-span" color=3D"#0000FF" face=3D"'Gill >> Sans'">Safe = >> code can't do anything with a value of type ADDRESS except pass it = >> around.  It must use unsafe operations (NARROW) to turn it >> into = >> something usable.
> style-span"= >> color=3D"#0000FF" face=3D"'Gill Sans'">> span" = >> style=3D"font-size: medium;">
> class=3D"Apple-style-span" color=3D"#0000FF" face=3D"'Gill >> Sans'">> class=3D"Apple-style-span" style=3D"font-size: medium;">I think you = >> misunderstood ThreadF in the first place.  It has always been = >> logically unsafe, if not UNSAFE.  I don't want ThreadF ever to >> come = >> to be something that people outside the runtime system rely on. = >>  The Id type and MyId function is simply a convenience, but >> not and = >> never has been part of the standard = >> interfaces.
> span" = >> color=3D"#0000FF" face=3D"'Gill Sans'">> span" = >> style=3D"font-size: medium;">
> class=3D"Apple-style-span" color=3D"#0000FF" face=3D"'Gill >> Sans'">> class=3D"Apple-style-span" style=3D"font-size: medium;">Can we >> please = >> just revert back to the way it has always = >> been?
> span>
= >>

On 13 Sep >> 2009, at = >> 09:51, Jay K wrote:

> class=3D"Apple-interchange-newline">
> class=3D"Apple-style-span" style=3D"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; ">
> style=3D"font-size: 10pt; font-family: Verdana; ">The functions are = >> meant to be unsafe either way.
ThreadF.i3 clearly had a safety >> hole = >> before, but not due to the functions "in question".

Good >> point = >> about passing in ADDRESSes..but I'm not entirely sure I = >> understand/agree.
Can safe code ("directly") generate any >> ADDRESSes = >> at all? Or only get them from
unsafe code in the first = >> place?
ADDRESS only comes from ADR, right? And ADR isn't allowed >> in = >> safe? I'll check.

IF safe code CAN generate ADDRESSes, then >> this = >> was a hole:
PROCEDURE SetCurrentHandlers(h: ADDRESS);

and = >> perhaps these:
PROCEDURE SuspendOthers ();
(* Suspend all >> threads = >> except the caller's *)

PROCEDURE ResumeOthers >> ();

Though = >> probably not the second, since safe code can trivially hang/ >> deadlock on = >> its own.

The public safe ThreadF.i3 now = >> just:

(*-------------------------------------------------- = >> showthreads support ---*)

TYPE
  State =3D = >> {
        >> alive    = >> (* can run *),
        = >> waiting  (* waiting for a condition via Wait = >> *),
        locking  (* = >> waiting for a mutex to be unlocked = >> *),
        pausing  (* = >> waiting until some time is arrived = >> *),
        blocking (* >> waiting = >> for some IO *),
        = >> dying    (* done, but not yet joined = >> *),
        = >> dead     (* done and joined >> *)
    = >> };< >> br >> > >>
(*--------------------------------------------------------------= >> identity ---*)

TYPE
  Id =3D >> INTEGER;

PROCEDURE = >> MyId(): Id RAISES {};
(* return Id of caller >> *)


Everything = >> else I moved to the non-public ThreadInternal.i3.


> >> But in = >> Modula-3 whether an interface is unsafe or not *is* a = >> boolean.

Understood, but I still think even in unsafe code, = >> LOOPHOLE should be minimized.
C and C++ programmers are often >> taught = >> to minimize casts, esp. reinterpret_cast.
I think that guidance = >> carries over to Modula's LOOPHOLE, even if you are already >> unsafe
for = >> other reasons.

 - Jay


> To:> class=3D"Apple-converted-space"> > href=3D"mailto:jay.krell at cornell.edu">jay.krell at cornell.edu> a>
> = >> CC: 
> href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com> a>
> = >> Subject: Re: [M3devel] RC merge> class=3D"Apple-converted-space"> 
> Date: Sun, 13 >> Sep = >> 2009 02:44:50 -0700
> From:> class=3D"Apple-converted-space"> 
> href=3D"mailto:mika at async.async.caltech.edu">mika at async.async.caltech.edu >> <= >> /a>
> > span>
> = >> Jay K writes:
> ...
> >
> >Imagine you are >> a = >> somewhat prolific fairly happy C or C++ programmer. The >> w=3D
> = >> >hole world is unsafe=3D2C but recieves a fair amount of static = >> checking and i=3D
> >s therefore largely correct and >> perhaps = >> doesn't even suffer much from the l=3D
> >ack of = >> safety.
> >
> >=3D20
> >
> > >> void* = >> GetFoo(void)=3D3B=3D20
> >
> > void* = >> GetBar(void)=3D3B=3D20
> >
> >=3D20
> = >> >
> >or
> >
> >=3D20
> >> >
> = >> > Foo_t* GetFoo(void)=3D3B=3D20
> >
> > Bar_t* = >> GetBar(void)=3D3B=3D20
> >
> >=3D20
> = >> >
> >?
> >
> >=3D20
> >> >
> = >> >Definitely the second.
> >
> >=3D20
> = >> >
> >Perhaps perhaps perhaps perhaps a function should >> be = >> able to be declared to=3D
> > return an UNTRACED REF = >> Foo.Something=3D2C without actually importing Foo or =3D
> = >> >defining Something?
> >
> >=3D20
> = >> >
> >Clearly the safety of an /interface/ is more >> subtle = >> than a boolean.
> >
> >Some functions may be safe >> and = >> others unsafe.
> >
> >Even some uses of = >> functions.
> >
> >Imagine for example:
> = >> >
> >=3D20
> >
> >PROCEDURE GetFoo(): = >> UNTRACED REF Foo.Something=3D3B
> >
> >> >=3D20
> = >> >
> >Perhas a safe function could call this >> function=3D2C as = >> long as it only compa=3D
> >res the return value to = >> NIL?
> >
> >Actually storing it in a variable >> would = >> require IMPORT Foo=3D2C and if FOO is=3D
> > declared >> UNSAFE=3D2C= >> then that would
> >
> >pollute the caller. Or >> maybe = >> merely declaring a variable of UNTRACED is eno=3D
> >ugh >> to = >> wreck safety?
>> class=3D"Apple-converted-space"> 
> But in >> Modula-3 = >> whether an interface is unsafe or not *is* a boolean.
> It's >> very = >> clearly defined what it means in the Green Book.
>> class=3D"Apple-converted-space"> 
> If you don't = >> declare your GetFoo as UNSAFE you can write
>> class=3D"Apple-converted-space"> 
> VAR x :=3D >> GetFoo; = >> BEGIN (* manipulate fields of x *) END
>> class=3D"Apple-converted-space"> 
> in safe = >> code.
> > span>
> = >> Declaring GetFoo to return ADDRESS won't let you do that. >> Hence,
> = >> it's safer, if there's a safety problem with manipulating the = >> fields.
> > span>
>= >> An interface can hardly assume that it is the only one injecting = >> objects
> of type ADDRESS into the "safe world" so if you're = >> allowing the safe world
> to pass these objects back in your = >> interface you have to sanity-check
> them anyhow. You do not, = >> however, need to worry about the fields having
> been changed >> by = >> the safe code.
>> class=3D"Apple-converted-space"> 
> If you need >> some = >> more subtle properties than that you probably ought
> to be = >> writing UNSAFE code in the first place. Or is there some = >> trickery
> you can do along the lines of what we came up with >> for = >> small integers
> in pointers?
>> class=3D"Apple-converted-space"> 
> = >> Mika

= >> >> --Apple-Mail-18--321278784-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 16:17:23 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 14:17:23 +0000 Subject: [M3devel] $DISPLAY on Darwin In-Reply-To: References: <20090911204841.582E12474002@birch.elegosoft.com> <4AAA8078.1E75.00D7.1@scires.com> <8D294564-8805-4EF1-A83E-9E38FA7AAD49@cs.purdue.edu> <8DAAF2A9-2AD8-4265-8AD2-09CF2DC75F82@cs.purdue.edu> <8CFDE091-F45C-4800-92E9-D82705A6BB8A@cs.purdue.edu> Message-ID: For the record, I don't think this statement about DISPLAY is true. I leave it at the default, which does resemble the wierd form shown. With older cm3 that does cause a problem and it probably/might cause some slow down (not using shared memory where it might otherwise be possible), but it seems to work ok. (I have made many errors in checkin comments, not always noted.) - Jay >>> Antony Hosking 9/11/2009 10:48 PM >>> CVSROOT:/usr/cvs Changes by:hosking at birch.09/09/11 22:48:37 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: Mentor and Juno finally work on I386_DARWIN. ***Significant overhaul of thread alerting.*** Invariant now is that all waiting is done on the thread's own condition variable. This cleanly permits signals and alerts from any other thread. Need to set DISPLAY=:0.0 and xhost+ to get around problems with DISPLAY=/tmp/launch-XXXXXX/:0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 16:39:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 14:39:11 +0000 Subject: [M3devel] CVS problems (and no checking mail) Message-ID: cvs commit: warning: editor session failed /usr/cvs/cm3/m3-ui/ui/src/xvbt/XSharedMem.m3,v <-- xvbt/XSharedMem.m3 new revision: 1.5; previous revision: 1.4 Can't locate Carp.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line 20. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/Data/Dumper.pm line 20. Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. Can't locate bytes.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. BEGIN failed--compilation aborted at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 16:43:16 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 14:43:16 +0000 Subject: [M3devel] CVS problems (and no checking mail) In-Reply-To: References: Message-ID: I see this "anywhere" (just checked two places): jbook2:src jay$ cvs -z3 commit -f -m "testing CVS triggers, no diff" m3makefile /usr/cvs/cm3/m3-libs/m3core/src/m3makefile,v <-- m3makefile new revision: 1.13; previous revision: 1.12 Can't locate Carp.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line 20. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/Data/Dumper.pm line 20. Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. Can't locate bytes.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. BEGIN failed--compilation aborted at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. - Jay From: jay.krell at cornell.edu To: m3-support at elego.de; m3devel at elegosoft.com Date: Wed, 16 Sep 2009 14:39:11 +0000 Subject: [M3devel] CVS problems (and no checking mail) cvs commit: warning: editor session failed /usr/cvs/cm3/m3-ui/ui/src/xvbt/XSharedMem.m3,v <-- xvbt/XSharedMem.m3 new revision: 1.5; previous revision: 1.4 Can't locate Carp.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line 20. BEGIN failed--compilation aborted at /usr/lib/perl/5.8/Data/Dumper.pm line 20. Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. Can't locate bytes.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. BEGIN failed--compilation aborted at /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 16 17:18:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Sep 2009 15:18:54 +0000 Subject: [M3devel] formsedit crash Message-ID: The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. I will confirm and further narrow this down over the next few days. I've been building various dates/versions and seeing how they act. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Wed Sep 16 20:14:01 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Wed, 16 Sep 2009 20:14:01 +0200 Subject: [M3devel] CVS problems (and no checking mail) In-Reply-To: References: Message-ID: <20090916201401.84slxeeg0kowgcgo@mail.elego.de> Hi Jay, This will be fixed shortly, sorry about that. Mike > > I see this "anywhere" (just checked two places): > > book2:src jay$ cvs -z3 commit -f -m "testing CVS triggers, no diff" > m3makefile > /usr/cvs/cm3/m3-libs/m3core/src/m3makefile,v <-- m3makefile > new revision: 1.13; previous revision: 1.12 > Can't locate Carp.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line > 20. > BEGIN failed--compilation aborted at > /usr/lib/perl/5.8/Data/Dumper.pm line 20. > Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. > Can't locate bytes.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. > Can't locate strict.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > BEGIN failed--compilation aborted at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > > > - Jay > > > > From: jay.krell at cornell.edu > To: m3-support at elego.de; m3devel at elegosoft.com > Date: Wed, 16 Sep 2009 14:39:11 +0000 > Subject: [M3devel] CVS problems (and no checking mail) > > > > > > > > > cvs commit: warning: editor session failed > /usr/cvs/cm3/m3-ui/ui/src/xvbt/XSharedMem.m3,v <-- xvbt/XSharedMem.m3 > new revision: 1.5; previous revision: 1.4 > Can't locate Carp.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Data/Dumper.pm line > 20. > BEGIN failed--compilation aborted at > /usr/lib/perl/5.8/Data/Dumper.pm line 20. > Compilation failed in require at /usr/cvs/CVSROOT/log_accum line 331. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/log_accum line 331. > Can't locate bytes.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at /usr/cvs/CVSROOT/dolog.pl line 41. > BEGIN failed--compilation aborted at /usr/cvs/CVSROOT/dolog.pl line 41. > Can't locate strict.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 > /usr/local/lib/site_perl .) at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > BEGIN failed--compilation aborted at > /usr/local/tinderbox/bonsai/handleCheckinMail.pl line 24. > > > > > > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Sep 18 07:19:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 05:19:25 +0000 Subject: [M3devel] the so_linger inconsistency between Posix and Windows Message-ID: I've been reading up on SO_LINGER. Search the web.. There are two or three options, depending on how you view it. onoff=0 time=ignored onoff=1 time=non-zero onoff=1 time=0 You could view this as an example of the previous. The behavior is governed by additional bits. - does the socket of buffered unset data? - is the socket blocking? Some options result in the socket being "immediately" closed and unsent buffered data not being sent, and I think possibly the other side getting an error. Some options have close return immediately but send the buffered data in the "background". This I believe is the default. Some options have close block waiting for send to finish. This has pluses/minuses. The minus is -- what timeout to use? A plus and minus is, I believe, there is an opportunity for close to timeout and fail, letting the caller know that there was a failure to deliver data. It is good to know about failure, though you'd want to know if the code was ready to somehow handle the failure. onoff=0 seems "best". onoff=1, time=0 seems "bad". onoff=1, time="large" seems "ok", depending on how large. I think onoff=0 is the default. I will verify that with some getsockopt runs. If it is the default, I think we should just remove the setsockopt(so_linger) code. One might also imagine that 1 second is not a short time, so even the Windows code isn't far off from the Posix code. The only big change would be setting 1,0 or removing setting of 1,0. What I wish we had but don't know if we have, is some major Modula-3 user of sockets on both Posix and Windows, so that the change can be tested. I think there is a basic problem in networking code, of unreliability and inconsistent timing. You don't know how long to wait for something to occur, when to give up waiting and deciding it failed. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 18 09:49:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 07:49:18 +0000 Subject: [M3devel] formsedit crash Message-ID: I have it further narrowed down to the last two weeks of 1/2007. Which is just a few changes. I fear it is the switch from user threads to pthreads on 1/23/2007. I'll narrow it down further though, and then try user threads on Solaris (which will probably require repairing initialization order to make them work again anyway). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: formsedit crash Date: Wed, 16 Sep 2009 15:18:54 +0000 The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. I will confirm and further narrow this down over the next few days. I've been building various dates/versions and seeing how they act. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Sep 18 11:37:48 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 18 Sep 2009 11:37:48 +0200 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: <1253266668.2779.27.camel@faramir.m3w.org> I've had some funny race/thread-order conditions when I was switching to pthreads.... Someone lazy got too grooved in with fixed order of execution implied by how user threads work. It was in pp package and also somewhere I can't remember right now... Will look a bit through hm3 svn (dead in house spinoff of pm3 from times when all mainstream m3 had was user threads). On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > I have it further narrowed down to the last two weeks of 1/2007. > Which is just a few changes. > I fear it is the switch from user threads to pthreads on 1/23/2007. > I'll narrow it down further though, and then try user threads on > Solaris > (which will probably require repairing initialization order to make > them work > again anyway). > > - Jay > > > > ______________________________________________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: formsedit crash > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > The formsedit crash appears to have started between 12/1/2006 and > 3/1/2007. > I will confirm and further narrow this down over the next few days. > I've been building various dates/versions and seeing how they act. > > - Jay > > > > -- Dragi?a Duri? From jay.krell at cornell.edu Fri Sep 18 12:12:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 10:12:18 +0000 Subject: [M3devel] formsedit crash In-Reply-To: <1253266668.2779.27.camel@faramir.m3w.org> References: Message-ID: I thought about this a little..but..don't Modula-3 user threads preempt at arbitrary points? - Jay > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Fri, 18 Sep 2009 11:37:48 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] formsedit crash > > I've had some funny race/thread-order conditions when I was switching to > pthreads.... Someone lazy got too grooved in with fixed order of > execution implied by how user threads work. It was in pp package and > also somewhere I can't remember right now... Will look a bit through hm3 > svn (dead in house spinoff of pm3 from times when all mainstream m3 had > was user threads). > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > > I have it further narrowed down to the last two weeks of 1/2007. > > Which is just a few changes. > > I fear it is the switch from user threads to pthreads on 1/23/2007. > > I'll narrow it down further though, and then try user threads on > > Solaris > > (which will probably require repairing initialization order to make > > them work > > again anyway). > > > > - Jay > > > > > > > > ______________________________________________________________________ > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: formsedit crash > > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > > > The formsedit crash appears to have started between 12/1/2006 and > > 3/1/2007. > > I will confirm and further narrow this down over the next few days. > > I've been building various dates/versions and seeing how they act. > > > > - Jay > > > > > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 18 14:45:18 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Sep 2009 08:45:18 -0400 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: Jay, formsedit now works for me on I386_DARWIN. Not sure what you are trying to track down now. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 03:49, Jay K wrote: > I have it further narrowed down to the last two weeks of 1/2007. > Which is just a few changes. > I fear it is the switch from user threads to pthreads on 1/23/2007. > I'll narrow it down further though, and then try user threads on > Solaris > (which will probably require repairing initialization order to make > them work > again anyway). > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: formsedit crash > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > The formsedit crash appears to have started between 12/1/2006 and > 3/1/2007. > I will confirm and further narrow this down over the next few days. > I've been building various dates/versions and seeing how they act. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 18 14:47:44 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Sep 2009 08:47:44 -0400 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: Not exactly. The inCritical counter means there are lots of places that serialize. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 06:12, Jay K wrote: > I thought about this a little..but..don't Modula-3 user threads > preempt at arbitrary points? > > - Jay > > > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Fri, 18 Sep 2009 11:37:48 +0200 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] formsedit crash > > > > I've had some funny race/thread-order conditions when I was > switching to > > pthreads.... Someone lazy got too grooved in with fixed order of > > execution implied by how user threads work. It was in pp package and > > also somewhere I can't remember right now... Will look a bit > through hm3 > > svn (dead in house spinoff of pm3 from times when all mainstream > m3 had > > was user threads). > > > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > > > I have it further narrowed down to the last two weeks of 1/2007. > > > Which is just a few changes. > > > I fear it is the switch from user threads to pthreads on > 1/23/2007. > > > I'll narrow it down further though, and then try user threads on > > > Solaris > > > (which will probably require repairing initialization order to > make > > > them work > > > again anyway). > > > > > > - Jay > > > > > > > > > > > > > ______________________________________________________________________ > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Subject: formsedit crash > > > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > > > > > The formsedit crash appears to have started between 12/1/2006 and > > > 3/1/2007. > > > I will confirm and further narrow this down over the next few > days. > > > I've been building various dates/versions and seeing how they act. > > > > > > - Jay > > > > > > > > > > > > > > -- > > Dragi?a Duri? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Sep 18 14:47:43 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 18 Sep 2009 08:47:43 -0400 Subject: [M3devel] formsedit crash In-Reply-To: <1253266668.2779.27.camel@faramir.m3w.org> References: <1253266668.2779.27.camel@faramir.m3w.org> Message-ID: Indeed, I fixed one of these races sometime back when switching to pthreads. Should be in the logs. AFAIK formsedit now works. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 05:37, Dragi?a Duri? wrote: > I've had some funny race/thread-order conditions when I was > switching to > pthreads.... Someone lazy got too grooved in with fixed order of > execution implied by how user threads work. It was in pp package and > also somewhere I can't remember right now... Will look a bit through > hm3 > svn (dead in house spinoff of pm3 from times when all mainstream m3 > had > was user threads). > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: >> I have it further narrowed down to the last two weeks of 1/2007. >> Which is just a few changes. >> I fear it is the switch from user threads to pthreads on 1/23/2007. >> I'll narrow it down further though, and then try user threads on >> Solaris >> (which will probably require repairing initialization order to make >> them work >> again anyway). >> >> - Jay >> >> >> >> ______________________________________________________________________ >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: formsedit crash >> Date: Wed, 16 Sep 2009 15:18:54 +0000 >> >> The formsedit crash appears to have started between 12/1/2006 and >> 3/1/2007. >> I will confirm and further narrow this down over the next few days. >> I've been building various dates/versions and seeing how they act. >> >> - Jay >> >> >> >> > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 18 19:50:33 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 17:50:33 +0000 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: formsedit on SOLgnu very often fails. With current source. -bash-3.00$ ./formsedit *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/lego/POSIX/ScrollerVBTClass.m3", line 325 ** I added the assert. It is that a pointer is not NIL, on the line before it is dereferenced. I've also seen this on PPC_something (Darwin?) but haven't tried recently. I might say it fails less often now, but it does still fail. The range is now narrowed down to between Jan 20 and Feb 1 2007. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 18 Sep 2009 08:45:18 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] formsedit crash Jay, formsedit now works for me on I386_DARWIN. Not sure what you are trying to track down now. Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On 18 Sep 2009, at 03:49, Jay K wrote:I have it further narrowed down to the last two weeks of 1/2007. Which is just a few changes. I fear it is the switch from user threads to pthreads on 1/23/2007. I'll narrow it down further though, and then try user threads on Solaris (which will probably require repairing initialization order to make them work again anyway). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: formsedit crash Date: Wed, 16 Sep 2009 15:18:54 +0000 The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. I will confirm and further narrow this down over the next few days. I've been building various dates/versions and seeing how they act. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 18 20:07:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 18 Sep 2009 18:07:38 +0000 Subject: [M3devel] formsedit crash In-Reply-To: <20090918175906.8C4991A2094@async.async.caltech.edu> References: Message-ID: There was a problem around the RC2 timeframe where garbage collection was turned off entirely. It wasn't that way for a long time, but indeed it was a very bad thing. Segfault could be due to out of memory. I think what I've been seeing is different. I've built many versions of the source tree now, including current. And the below is my finding -- SOLgnu formsedit works for very many timestamps on or prior to Jan 20 2007 and fails for very many timestamps on or after Feb 1 2007, including current. (dates are US Pacific time, don't /quite/ match up to the ChangeLog, behind about 9 hours.) Whether or not PPC_DARWIN is broken on current, not yet determined. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] formsedit crash > Date: Fri, 18 Sep 2009 10:59:06 -0700 > From: mika at async.async.caltech.edu > > > I just wanted to add that I was having enormous problems with a Trestle > application on PPC_DARWIN using sources of about six weeks ago. It was > going catatonic and leaking memory at an alarming rate (and worked > perfectly on FreeBSD/i386 using an old PM3, didn't get around to trying > with new sources). Also the occasional segfault. > > Of course I thought it was my fault, but after reviewing my code carefully > I couldn't find anything wrong, and I updated CM3 today and it looks great---no more crashing or hanging. > > Mika > > Jay K writes: > > > > > >MIME-Version: 1.0 > > > >--_20828071-d627-4e2e-af04-2e79c7e91e22_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >formsedit on SOLgnu very often fails. With current source. > > > >-bash-3.00$ ./formsedit=20 > > > > > >*** > >*** runtime error: > >*** <*ASSERT*> failed. > >*** file "../src/lego/POSIX/ScrollerVBTClass.m3"=2C line 325 > >** > > > >I added the assert. It is that a pointer is not NIL=2C on the line > >before it is dereferenced. > > > >I've also seen this on PPC_something (Darwin?) but haven't tried recently. > >I might say it fails less often now=2C but it does still fail. > > > >The range is now narrowed down to between Jan 20 and Feb 1 2007. > > > > - Jay > > > >From: hosking at cs.purdue.edu > >To: jay.krell at cornell.edu > >Date: Fri=2C 18 Sep 2009 08:45:18 -0400 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] formsedit crash > > > >Jay=2C formsedit now works for me on I386_DARWIN. Not sure what you are tr= > >ying to track down now. > > Antony Hosking | Associate Professor | Computer Science | Purdue Universit= > >y305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 49= > >4 6001 | Mobile +1 765 427 5484=20 > >On 18 Sep 2009=2C at 03:49=2C Jay K wrote:I have it further narrowed down t= > >o the last two weeks of 1/2007. > >Which is just a few changes. > >I fear it is the switch from user threads to pthreads on 1/23/2007. > >I'll narrow it down further though=2C and then try user threads on Solaris > >(which will probably require repairing initialization order to make them wo= > >rk > >again anyway). > > > > - Jay > > > > > >From: jay.krell at cornell.edu > >To: m3devel at elegosoft.com > >Subject: formsedit crash > >Date: Wed=2C 16 Sep 2009 15:18:54 +0000 > > > >The formsedit crash appears to have started between 12/1/2006 and 3/1/2007. > >I will confirm and further narrow this down over the next few days. > >I've been building various dates/versions and seeing how they act. > > > > - Jay > > > > > > > > > > > > = > > > >--_20828071-d627-4e2e-af04-2e79c7e91e22_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >formsedit on SOLgnu very often fails. With current source.

-bash-3.0= > >0$ ./formsedit


***
*** runtime error:
*** =3B =3B= > > =3B <=3B*ASSERT*>=3B failed.
*** =3B =3B =3B file "= > >../src/lego/POSIX/ScrollerVBTClass.m3"=2C line 325
**

I added the= > > assert. It is that a pointer is not NIL=2C on the line
before it is der= > >eferenced.

I've also seen this on PPC_something (Darwin?) but haven'= > >t tried recently.
I might say it fails less often now=2C but it does sti= > >ll fail.

The range is now narrowed down to between Jan 20 and Feb 1 = > >2007.

 =3B - Jay


From: hosking at cs= > >.purdue.edu
To: jay.krell at cornell.edu
Date: Fri=2C 18 Sep 2009 08:45:= > >18 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] formsedit c= > >rash

Jay=2C formsedit now works for me on I386_DARWIN.  =3BNot s= > >ure what you are trying to track down now.

>Apple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0= > >=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B">
>d=3B"> >e=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px= > >=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B le= > >tter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tra= > >nsform: none=3B white-space: normal=3B word-spacing: 0px=3B">
>word-wrap: break-word=3B"> >er-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica= > >=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-w= > >eight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-inde= > >nt: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px= > >=3B"> >=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B= > > font-style: normal=3B font-variant: normal=3B font-weight: normal=3B lette= > >r-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transf= > >orm: none=3B white-space: normal=3B word-spacing: 0px=3B"> >xApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0= > >=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= > >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= > >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= > >e-space: normal=3B word-spacing: 0px=3B"> >" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= > >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= > >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= > >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= > >d-spacing: 0px=3B"> >apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= > >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= > >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= > >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B"> >pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= > >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= > >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= > >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= > >ne=3B white-space: normal=3B word-spacing: 0px=3B"> >style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= > >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= > >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= > >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= > >ormal=3B word-spacing: 0px=3B"> >"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helve= > >tica=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B fo= > >nt-weight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-= > >indent: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing:= > > 0px=3B">
>lass=3D"ecxApple-style-span" face=3D"Gill Sans"> >le-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B"= > >> >font-family: 'Gill Sans'=3B">Antony Hosking >t class=3D"ecxApple-style-span" face=3D"Gill Sans"> >style-span" style=3D"font-family: 'Gill Sans'=3B"> >tyle-span" style=3D"font-family: 'Gill Sans'=3B"> >nverted-space"> =3B|&nb= > >sp=3B >-family: 'Gill Sans'=3B"> >family: 'Gill Sans'=3B">Associate Professor >Apple-style-span" style=3D"font-family: 'Gill Sans'=3B"> >pple-style-span" style=3D"font-family: 'Gill Sans'=3B"> =3B| Computer S= > >cience | Purdue University
>xApple-style-span" face=3D"GillSans-Light"> >an" style=3D"font-family: GillSans-Light=3B">305 N. University Street | Wes= > >t Lafayette | IN 47907 | USA
>e-style-span" color=3D"#0000ff" face=3D"Gill Sans"> >style-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'= > >=3B"> >=3B font-family: 'Gill Sans'=3B">Office >ecxApple-style-span" face=3D"GillSans-Light"> >span" style=3D"font-family: GillSans-Light=3B"> >e-span" style=3D"font-family: GillSans-Light=3B"> =3B+1 765 494 6001 |<= > >span class=3D"ecxApple-converted-space"> =3B >><= > >span class=3D"ecxApple-style-span" style=3D"color: rgb(0=2C 0=2C 255)=3B fo= > >nt-family: 'Gill Sans'=3B"> >or: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">Mobile= > > >ass=3D"ecxApple-style-span" style=3D"font-family: GillSans-Light=3B"> >class=3D"ecxApple-style-span" style=3D"font-family: GillSans-Light=3B"> >n class=3D"ecxApple-converted-space"> =3B+1 765 427 5484<= > >/span>
>s-Light">
>n>

>ine">

>line">

On 18 Sep 2009=2C at 03:49=2C Jay K wrote:
= > >
>ple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C = > >0)=3B font-family: Helvetica=3B font-size: medium=3B font-style: normal=3B = > >font-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B li= > >ne-height: normal=3B text-indent: 0px=3B text-transform: none=3B white-spac= > >e: normal=3B word-spacing: 0px=3B">
>t-size: 10pt=3B font-family: Verdana=3B">I have it further narrowed down to= > > the last two weeks of 1/2007.
Which is just a few changes.
I fear it= > > is the switch from user threads to pthreads on 1/23/2007.
I'll narrow i= > >t down further though=2C and then try user threads on Solaris
(which wil= > >l probably require repairing initialization order to make them work
agai= > >n anyway).

 =3B- Jay



From:= > > =3B
>ay.krell at cornell.edu">jay.krell at cornell.edu
To: >le-converted-space"> =3B >>m3devel at elegosoft.com
Subject: formsedit crash
Date: Wed=2C 16 S= > >ep 2009 15:18:54 +0000

The formsedit crash appears to have started b= > >etween 12/1/2006 and 3/1/2007.
I will confirm and further narrow this do= > >wn over the next few days.
I've been building various dates/versions and= > > seeing how they act.

 =3B- Jay




= > >

> >= > > > >--_20828071-d627-4e2e-af04-2e79c7e91e22_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Sep 19 00:40:15 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 19 Sep 2009 00:40:15 +0200 Subject: [M3devel] formsedit crash In-Reply-To: References: Message-ID: <1253313616.6910.2.camel@faramir.m3w.org> Not only inCritical, user space threads are in circular list and scheduler runs (in circles :) ) through it. Meaning, if B comes after A and before C, it's always executed before C after A's timeslice- if ready. On Fri, 2009-09-18 at 08:47 -0400, Tony Hosking wrote: > Not exactly. The inCritical counter means there are lots of places > that serialize. > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > On 18 Sep 2009, at 06:12, Jay K wrote: > > > I thought about this a little..but..don't Modula-3 user threads > > preempt at arbitrary points? > > > > - Jay > > > > > > > From: dragisha at m3w.org > > > To: jay.krell at cornell.edu > > > Date: Fri, 18 Sep 2009 11:37:48 +0200 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] formsedit crash > > > > > > I've had some funny race/thread-order conditions when I was > > switching to > > > pthreads.... Someone lazy got too grooved in with fixed order of > > > execution implied by how user threads work. It was in pp package > > and > > > also somewhere I can't remember right now... Will look a bit > > through hm3 > > > svn (dead in house spinoff of pm3 from times when all mainstream > > m3 had > > > was user threads). > > > > > > On Fri, 2009-09-18 at 07:49 +0000, Jay K wrote: > > > > I have it further narrowed down to the last two weeks of 1/2007. > > > > Which is just a few changes. > > > > I fear it is the switch from user threads to pthreads on > > 1/23/2007. > > > > I'll narrow it down further though, and then try user threads on > > > > Solaris > > > > (which will probably require repairing initialization order to > > make > > > > them work > > > > again anyway). > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > From: jay.krell at cornell.edu > > > > To: m3devel at elegosoft.com > > > > Subject: formsedit crash > > > > Date: Wed, 16 Sep 2009 15:18:54 +0000 > > > > > > > > The formsedit crash appears to have started between 12/1/2006 > > and > > > > 3/1/2007. > > > > I will confirm and further narrow this down over the next few > > days. > > > > I've been building various dates/versions and seeing how they > > act. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > -- > > > Dragi?a Duri? > > > > > > -- Dragi?a Duri? From mbishop at esoteriq.org Sat Sep 19 01:22:06 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Fri, 18 Sep 2009 18:22:06 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? Message-ID: <4AB4161E.6050900@esoteriq.org> Why does everything install into /usr/local/cm3/* ? I tried editing my PATH variable to get the cm3 binary in there, but I still have to 'source /etc/profile' with every shell. And if I symlink it, it causes problems. Is there a reason to not just install to normal positions like /usr/bin and /usr/lib, etc? Is it possible to tell cminstall where to install other the default /usr/local/cm3 ? From jay.krell at cornell.edu Sun Sep 20 01:31:18 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Sep 2009 23:31:18 +0000 Subject: [M3devel] Utime.struct_tm Message-ID: struct_tm = RECORD tm_sec: int; tm_min: int; tm_hour: int; tm_mday: int; tm_mon: int; tm_year: int; tm_wday: int; tm_yday: int; tm_isdst: int; (* here *) tm_gmtoff:INTEGER; tm_zone: char_star; END; ? The fields after tm_isdst are not always present, and perhaps not always in that order. Portable code, Modula-3, C, or otherwise, cannot refer to those last two fields. C can do it with #ifdefs or autoconf-assisted and with some alternative if they are not present. ? What to do? Generally the vast majority of platform-dependency should and has been removed from the system, for much easier (and therefore generally more correct) porting. ? Today we declare struct_tm per-target. Most targets do declare the fields, but: Cygwin, Irix, HP-UX, Interix, Solaris do not. "Most" therefore leaves at least Linux, *BSD, Darwin. I do hope to bring up a few more targets, which may contribute to one set or the other. ? And I just checked that Solaris really doesn't provide the fields in C, so we can claim that mainstream platforms are part of the "problem". ? There are a few options: - leave it as system-dependent; my least favorite - define it to have the common prefix and provide copying C wrappers This allows for some portable uses. You can't just define the common prefix and allow direct calls, as that would corrupt the stack where it is an output. This would not allow for embedding the struct in any target-defined structs, but that probably never occurs. - remove it from m3core and all functions that traffic in it -- localtime, mktime, etc. This is my favorite. ok? Anyone that needs this functionality can chose from using interface Date, or writing portable C. I'm going to go ahead and do this. ok? ? And in any case, rewrite m3-libs\m3core\src\time in #ifdef'ed C, at least wherever struct_tm is used. I'm going to go ahead and do this. ok? ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 20 03:23:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 01:23:06 +0000 Subject: [M3devel] porting documentation? Message-ID: Hey, I've started writing up some new porting instructions. Can I get someone to try testing them out? By actually porting to a new platform? While I haven't really looked into this, I'm betting that I386_DFLYBSD or AMD64_DFLYBSD might be a good first choice? (DragonFly BSD, suggested platform names welcome) I would suggest you - install it in a virtual machine - work from a system with fast fork (ie: anything other than Cygwin) Anyone who has ported CM3 in the past is barred from this invitation. :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 20 05:24:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 03:24:58 +0000 Subject: [M3devel] Juno/win32threads Message-ID: Tony, the behavior still seems the same. (a74.f50): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c edi=00200000 eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 m3core!Thread__Join+0x14b: 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds:0023:001ffffc=???????? 0:000> 0:000> r edi edi=00200000 Can you maybe debug this on birch? I can e.g. put debuggers at \bin\x86\cdb (just install them locally which involves some GUI, then tar/gz them up and untar/gz..you don't need the installer to run, can just copy them around) and then you can like: ssh hudson at birch.elegosoft.com ssh elego at localhost2 /cygdrive/c/bin/x86/cdb ./Juno.exe Just be sure not to run Juno outside of a debugger..not sure what will happen, but you won't be able to see it. Or, feel free to commit some version that uses RTIO a bunch and I can send you the output. Slow turnaround that way. Clearly nobody is using any of this stuff.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 00:28:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 22:28:21 +0000 Subject: [M3devel] time.h reentrancy? Message-ID: Does anyone understand how the time.h *_r functions are supposed to behave wrt the char* tm_zone field in struct tm? This interface seems broken. Posix doesn't include the tm_zone field, so it is self-consistent. I think therefore even though DateBsd.m3 uses the _r functions, it should serialize. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 00:54:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Sep 2009 22:54:09 +0000 Subject: [M3devel] time.h reentrancy? In-Reply-To: References: Message-ID: My plan here is roughly: copy Utime.i3 to UtimeInternal.i3. Keeping only functions that traffic in struct_tm. In Utime.i3 define a struct_tm that doesn't have tm_zone and tm_gmtoff. UtimeInternal.i3 define a struct_tm that does include tm_zone and tm_gmtoff. Provide UtimeInternal.i3 only on platforms that use DateBsd.m3. Utime.i3 will therefore be portable. Both of them will be implemented via copying wrappers though, since the order of the fields, and the exact size of the struct, is not portable. Probably as well only the *_r functions should be provided? Not clear, since the non *_r functions have optional extra side affects such as setting tznzme. Probably keep the non *_r functions but callers must know to (maybe) serialize them. As DatePosix.m3/DateBsd.m3 do. I think most libc implementations use thread locals here, so the need to serialize is nearly zero. However there are user threads and timezone/daylight/tzname to worry about, not sure they are thread locals, or only the "direct result buffers". This area is really a mess. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 20 Sep 2009 22:28:21 +0000 Subject: [M3devel] time.h reentrancy? Does anyone understand how the time.h *_r functions are supposed to behave wrt the char* tm_zone field in struct tm? This interface seems broken. Posix doesn't include the tm_zone field, so it is self-consistent. I think therefore even though DateBsd.m3 uses the _r functions, it should serialize. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 21 04:04:20 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 20 Sep 2009 22:04:20 -0400 Subject: [M3devel] Juno/win32threads In-Reply-To: References: Message-ID: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> I don't think anything I changed affects Windows. On 19 Sep 2009, at 23:24, Jay K wrote: > Tony, the behavior still seems the same. > > (a74.f50): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c > edi=00200000 > eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl zr > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010246 > m3core!Thread__Join+0x14b: > 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: > 0023:001ffffc=???????? > 0:000> > 0:000> r edi > edi=00200000 > > > Can you maybe debug this on birch? > > I can e.g. put debuggers at \bin\x86\cdb > (just install them locally which involves some GUI, then tar/gz > them up and untar/gz..you don't need the installer to run, can just > copy them around) > and then you can like: > > ssh hudson at birch.elegosoft.com > ssh elego at localhost2 > /cygdrive/c/bin/x86/cdb ./Juno.exe > > Just be sure not to run Juno outside of a debugger..not sure what > will happen, but you won't be able to see it. > > Or, feel free to commit some version that uses RTIO a bunch and I > can send you the output. > Slow turnaround that way. > Clearly nobody is using any of this stuff.. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 06:14:32 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 20 Sep 2009 21:14:32 -0700 Subject: [M3devel] Juno/win32threads In-Reply-To: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> Message-ID: <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> Eh? Tony, the thread changes from around feb 20 that you recently 'unmerged'? These crashes seem to date from around Feb, more precise info in my other mails.. - Jay (phone) On Sep 20, 2009, at 7:04 PM, Tony Hosking wrote: > I don't think anything I changed affects Windows. > > On 19 Sep 2009, at 23:24, Jay K wrote: > >> Tony, the behavior still seems the same. >> >> (a74.f50): Access violation - code c0000005 (first chance) >> First chance exceptions are reported before any exception handling. >> This exception may be expected and handled. >> eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c >> edi=00200000 >> eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl >> zr na pe nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00010246 >> m3core!Thread__Join+0x14b: >> 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: >> 0023:001ffffc=???????? >> 0:000> >> 0:000> r edi >> edi=00200000 >> >> >> Can you maybe debug this on birch? >> >> I can e.g. put debuggers at \bin\x86\cdb >> (just install them locally which involves some GUI, then tar/gz >> them up and untar/gz..you don't need the installer to run, can just >> copy them around) >> and then you can like: >> >> ssh hudson at birch.elegosoft.com >> ssh elego at localhost2 >> /cygdrive/c/bin/x86/cdb ./Juno.exe >> >> Just be sure not to run Juno outside of a debugger..not sure what >> will happen, but you won't be able to see it. >> >> Or, feel free to commit some version that uses RTIO a bunch and I >> can send you the output. >> Slow turnaround that way. >> Clearly nobody is using any of this stuff.. >> >> - Jay >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 21 15:53:56 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Sep 2009 09:53:56 -0400 Subject: [M3devel] Juno/win32threads In-Reply-To: <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> Message-ID: <562F0E0F-C56D-4A8F-B845-2F9E86599C37@cs.purdue.edu> OK, I've lost track, since we've been discussing two different things: the problems with pthreads which I just fixed, and the Windows threading problem. What is the time-frame that I should be looking at for that problem? On 21 Sep 2009, at 00:14, jay.krell at cornell.edu wrote: > Eh? Tony, the thread changes from around feb 20 that you recently > 'unmerged'? These crashes seem to date from around Feb, more precise > info in my other mails.. > > - Jay (phone) > > On Sep 20, 2009, at 7:04 PM, Tony Hosking > wrote: > >> I don't think anything I changed affects Windows. >> >> On 19 Sep 2009, at 23:24, Jay K wrote: >> >>> Tony, the behavior still seems the same. >>> >>> (a74.f50): Access violation - code c0000005 (first chance) >>> First chance exceptions are reported before any exception handling. >>> This exception may be expected and handled. >>> eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c >>> edi=00200000 >>> eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl >>> zr na pe nc >>> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >>> efl=00010246 >>> m3core!Thread__Join+0x14b: >>> 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: >>> 0023:001ffffc=???????? >>> 0:000> >>> 0:000> r edi >>> edi=00200000 >>> >>> >>> Can you maybe debug this on birch? >>> >>> I can e.g. put debuggers at \bin\x86\cdb >>> (just install them locally which involves some GUI, then tar/gz >>> them up and untar/gz..you don't need the installer to run, can >>> just copy them around) >>> and then you can like: >>> >>> ssh hudson at birch.elegosoft.com >>> ssh elego at localhost2 >>> /cygdrive/c/bin/x86/cdb ./Juno.exe >>> >>> Just be sure not to run Juno outside of a debugger..not sure what >>> will happen, but you won't be able to see it. >>> >>> Or, feel free to commit some version that uses RTIO a bunch and I >>> can send you the output. >>> Slow turnaround that way. >>> Clearly nobody is using any of this stuff.. >>> >>> - Jay >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 21 16:03:32 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 21 Sep 2009 10:03:32 -0400 Subject: [M3devel] Juno/win32threads In-Reply-To: <562F0E0F-C56D-4A8F-B845-2F9E86599C37@cs.purdue.edu> References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> <419F9B28-3642-41C7-AD71-530B6E4F48E3@hotmail.com> <562F0E0F-C56D-4A8F-B845-2F9E86599C37@cs.purdue.edu> Message-ID: P.S. I did commit back some changes to ThreadWin32.m3 which backed out some of 1.30. Did you try those? On 21 Sep 2009, at 09:53, Tony Hosking wrote: > OK, I've lost track, since we've been discussing two different > things: the problems with pthreads which I just fixed, and the > Windows threading problem. What is the time-frame that I should be > looking at for that problem? > > On 21 Sep 2009, at 00:14, jay.krell at cornell.edu wrote: > >> Eh? Tony, the thread changes from around feb 20 that you recently >> 'unmerged'? These crashes seem to date from around Feb, more >> precise info in my other mails.. >> >> - Jay (phone) >> >> On Sep 20, 2009, at 7:04 PM, Tony Hosking >> wrote: >> >>> I don't think anything I changed affects Windows. >>> >>> On 19 Sep 2009, at 23:24, Jay K wrote: >>> >>>> Tony, the behavior still seems the same. >>>> >>>> (a74.f50): Access violation - code c0000005 (first chance) >>>> First chance exceptions are reported before any exception handling. >>>> This exception may be expected and handled. >>>> eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c >>>> edi=00200000 >>>> eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl >>>> zr na pe nc >>>> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >>>> efl=00010246 >>>> m3core!Thread__Join+0x14b: >>>> 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds: >>>> 0023:001ffffc=???????? >>>> 0:000> >>>> 0:000> r edi >>>> edi=00200000 >>>> >>>> >>>> Can you maybe debug this on birch? >>>> >>>> I can e.g. put debuggers at \bin\x86\cdb >>>> (just install them locally which involves some GUI, then tar/gz >>>> them up and untar/gz..you don't need the installer to run, can >>>> just copy them around) >>>> and then you can like: >>>> >>>> ssh hudson at birch.elegosoft.com >>>> ssh elego at localhost2 >>>> /cygdrive/c/bin/x86/cdb ./Juno.exe >>>> >>>> Just be sure not to run Juno outside of a debugger..not sure what >>>> will happen, but you won't be able to see it. >>>> >>>> Or, feel free to commit some version that uses RTIO a bunch and I >>>> can send you the output. >>>> Slow turnaround that way. >>>> Clearly nobody is using any of this stuff.. >>>> >>>> - Jay >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Sep 21 16:25:12 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 21 Sep 2009 16:25:12 +0200 Subject: [M3devel] back again -- cm3 status worse? Message-ID: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> Hi all, I'm back again from my trip to France. Though there seems to have been lots of activity during my absence, the current status is worse than when I left: o tinderbox status is comletely red o Hudson builds fail due to syntax errors o no tickets have been closed or even changed Does anybody care to fix? It would be nice if we could at least backup to the status of when I left... A summary about the activities/changes would be welcome. I'll need some days to read all the mails. So long, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Sep 21 22:13:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Sep 2009 20:13:21 +0000 Subject: [M3devel] Juno/win32threads In-Reply-To: References: <554E110B-82BD-436A-B394-D2202DCCFFE9@cs.purdue.edu> Message-ID: Yes that's what I was referring to. You were already looking at the right timeframe, around Feb 20 2009. Earlier mail has a 30 minute window identified. -Jay From: hosking at cs.purdue.edu To: hosking at cs.purdue.edu Date: Mon, 21 Sep 2009 10:03:32 -0400 CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] Juno/win32threads P.S. I did commit back some changes to ThreadWin32.m3 which backed out some of 1.30. Did you try those? On 21 Sep 2009, at 09:53, Tony Hosking wrote: OK, I've lost track, since we've been discussing two different things: the problems with pthreads which I just fixed, and the Windows threading problem. What is the time-frame that I should be looking at for that problem? On 21 Sep 2009, at 00:14, jay.krell at cornell.edu wrote: Eh? Tony, the thread changes from around feb 20 that you recently 'unmerged'? These crashes seem to date from around Feb, more precise info in my other mails.. - Jay (phone) On Sep 20, 2009, at 7:04 PM, Tony Hosking wrote: I don't think anything I changed affects Windows. On 19 Sep 2009, at 23:24, Jay K wrote: Tony, the behavior still seems the same. (a74.f50): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=7ffdf000 edx=00e29620 esi=0128872c edi=00200000 eip=005eb75d esp=0012f940 ebp=0012f95c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 m3core!Thread__Join+0x14b: 005eb75d 8b5ffc mov ebx,dword ptr [edi-4] ds:0023:001ffffc=???????? 0:000> 0:000> r edi edi=00200000 Can you maybe debug this on birch? I can e.g. put debuggers at \bin\x86\cdb (just install them locally which involves some GUI, then tar/gz them up and untar/gz..you don't need the installer to run, can just copy them around) and then you can like: ssh hudson at birch.elegosoft.com ssh elego at localhost2 /cygdrive/c/bin/x86/cdb ./Juno.exe Just be sure not to run Juno outside of a debugger..not sure what will happen, but you won't be able to see it. Or, feel free to commit some version that uses RTIO a bunch and I can send you the output. Slow turnaround that way. Clearly nobody is using any of this stuff.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 21 22:16:22 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 21 Sep 2009 20:16:22 +0000 Subject: [M3devel] back again -- cm3 status worse? In-Reply-To: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> Message-ID: Welcome back! Things are definitely a bit better, even if the high level status looks worse. But there are still imho two severe problems needing fixing for this release. - longstanding pthread problem fixed by Tony -- Darwin hangs fixed fix ported to release (head has further diverged) - Win32 threading/gui still has a problem (Juno crashing, worse than its usual assertion failure due to incomplete Trestle) date the problem started identified (around Feb 20 2009, but more precise information is known) - approx date the Solaris formsedit problem started identified unfortunately it was the switch from userthreads to pthreads (approx Jan 20 2007, probably 23) Tony looking at it. - Solaris tests or hudson were hung somewhere, I couldn't figure out what was running (seemingly nothing), rebooted the machine - Solaris not liking date +%s in pkgmap.sh I checked in a fix but messed up, that's the red in Tinderbox, testing now - I commited .msi building on release, I think it'll work, based on the console output, but waiting for an RC4 download to test. still should do .deb building - Usysdep reduction, only in head, not for this release - Jay > Date: Mon, 21 Sep 2009 16:25:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] back again -- cm3 status worse? > > Hi all, > > I'm back again from my trip to France. Though there seems to have been > lots of activity during my absence, the current status is worse > than when I left: > > o tinderbox status is comletely red > o Hudson builds fail due to syntax errors > o no tickets have been closed or even changed > > Does anybody care to fix? It would be nice if we could at least backup > to the status of when I left... > > A summary about the activities/changes would be welcome. I'll need > some days to read all the mails. > > So long, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 13:21:46 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 13:21:46 +0200 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Hi Randy, Tony, Jay and all others, thanks for your updates. Things already look better in Hudson and Tinderbox; there may still be some script failures which need manual intervention. As this mail is relevant for all M3 committers, I've CC'ed it to m3devel, too. I understand that a major bug (race condition in pthreads) has been fixed, but there are still some problems in Windows' threads and Solaris' formsedit which are currently investigated. I'll try to add some information of your summaries to the Trac roadmap soon. I think the main problem currently for release engineering is in procedure: we all need to agree to use the same tools and rules for proper collaboration. I know that I may have introduced a bit much in this respect for the small M3 community, but the m3devel list really proved inadequate at least for me to accomplish the tasks related to release engineering for 5.8. So I suggest we use all the available tools (Tinderbox, Hudson, Trac) at least for this release (and may improve the tools and procedures later). Very likely I haven't provided enough information regarding the tool use and intended procedure though, so I'll try to sum up some important points for everybody (again?): o Release engineering is performed on the cm3_branch_release_5_8. This should decouple (stabilizing) bug fixes from potentially destabilizing other commits. CVS is still used for version control; the steps needed to perform merges to the release branch are 'cvs update -j rev' (two point merge) or 'cvs update -j rev -j rev' (three point merge, general case). All merges in CVS are performed in a local workspace and need to be committed explicitly (after local testing, at least proper compilation). o The continuous integration in Hudson I tried to set up during the recent months is currently tracking the release branch and should be used as an indicator for the release quality. o After every commit to the release branch the developer involved should observe the results in the Hudson CI. The lastok-build and release-build jobs on all platforms should succeed (color blue); some tests may be expected to fail (color yellow). None of the main jobs should be read at any time (network communication problems may lead to failures though, usually indicated by `failed to join the process' in the console log). In case of any regression (build failures, more test failures), the problem should either be fixed or the changes reverted (until something better is available). o Anybody logged-in to Hudson can also start jobs manually with the build button. This should be used with case though. In general, jobs should be triggered by CVS checkins. o Trac is used to manage the procedural aspects of the release engineering process, i.e. define milestones and create, change and close tickets for issues related to bugs and other tasks. It also contains a WiKi for project documentation and is integrated with CVS and Hudson. It should be easy to use, but the current setup still has some problems (manual administration needed). Everybody who participates in source changes should also have access to trac and update related tickets at the same time. Indeed, for release engineering there should be no commit at all without an associated ticket. o The release engineer's role I'm trying to perform for the current release does mainly include janitorial services like merging fixes, writing scripts for package builds and tests, performing builds and installation and other tests. This is more than enough work for one person; others are expected to analyze failures and collaborate by providing the changes and information needed via the established tools and procedures. I think the current setup, though still a bit fragile, should be a quite good base for building and documenting a usable CM3 release. I'm not able to perform the required tasks just based on the commit and m3devel mails (I'm often even unable to read them all, and doubt others will do better there). So please use all the installed tools as best as you can. As concrete steps to continue with the 5.8 release I suggest these: (1) Review of all open tickets and appropriate updates and comments. See https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+Release+5.8+RC3 and https://projects.elego.de/cm3/query?status=resolved&status=reopened&status=assigned&status=analyzed&status=new&status=accepted&group=status&milestone=CM3+release+5.8 (links from the roadmap page of trac) (2) Create missing tickets for problems not yet described. Add complete information (error messages, stack traces etc.). Jay's list suggest a couple of new tickets I think. (3) Abandon the RC3 pacakges and retarget everything to RC4 in two or three weeks. (4) Retarget the final release to the end of October (at least). Does this sound reasonable? All help and cooperations is greatly appreciated as usual. Especially anybody to help creating and updating tickets for everything reported on m3devel and m3commit would be welcome. Olaf Quoting Tony Hosking : > I am confident that pthread-based threading is now better than it has > ever been (there was a nasty race that has been thoroughly fixed, and > the logic is now much simpler to understand). It runs all the X11 > apps (juno, mentor, formsedit) without problems. In sum, I think > pthread threading is ready for prime-time. I have never made more > than trivial changes to the WIN32 threads implementation. I don't > know the current state of things there, but hope that our Windows > enthusiasts can test things thoroughly. > > On 21 Sep 2009, at 10:46, Randy Coleburn wrote: > >> Olaf: >> >> I ran a build last night on both XP and Vista. I have not noticed >> any new problems on these platforms. I note that Jay has added >> more commits since last night, so I haven't tried these yet. (I >> am pulling from the head branch for these builds.) >> >> Also, I note that Jay says he is going to rewrite some of the Date >> stuff into C--again I would like to ask why, but I don't want to >> be seen as causing problems. Perhaps he should say why he feels >> it necessary to recode in C versus fixing whatever problem exists >> in Modula-3. I would be willing to work on any Modula-3 coding >> problem if given the chance. >> >> I am concerned about all the message traffic of late about >> suspected problems with the threading. I use threads a lot and if >> they aren't working correctly this is going to be a real problem. >> I ran a quick test using one of my multithreaded programs, but >> didn't see any problem. Unfortunately, this program requires >> connection to some specialized hardware that I don't have access >> to in order to give it a real workout. >> >> Regards, >> Randy >> >>>>> Olaf Wagner 9/21/2009 10:25 AM >>> >> Hi all, >> >> I'm back again from my trip to France. Though there seems to have been >> lots of activity during my absence, the current status is worse >> than when I left: >> >> o tinderbox status is comletely red >> o Hudson builds fail due to syntax errors >> o no tickets have been closed or even changed >> >> Does anybody care to fix? It would be nice if we could at least backup >> to the status of when I left... >> >> A summary about the activities/changes would be welcome. I'll need >> some days to read all the mails. >> >> So long, >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 22 13:55:36 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 11:55:36 +0000 Subject: [M3devel] web page messed up Message-ID: Olaf, this page: http://www.modula3.com/cm3/index.html has a glaring problem right at the start. I checked in a fix weeks ago. How does one get the update to appear? I'm referring to the nested frames. Surely that was a typo. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 14:16:25 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 12:16:25 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 15:21:16 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 15:21:16 +0200 Subject: [M3devel] web page messed up In-Reply-To: References: Message-ID: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> Quoting Jay K : > Olaf, this page: > > http://www.modula3.com/cm3/index.html > > has a glaring problem right at the start. It displays OK for me using Firefox and Opera. What's the problem? I won't say it looks good, but it displays its info ;-) > I checked in a fix weeks ago. > How does one get the update to appear? Copy the file to the web servers root on birch. However, only do this if you are really sure (locally tested etc.). It's the same procedure as for the releng packages, only the path is shorter. > I'm referring to the nested frames. > > Surely that was a typo. > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Tue Sep 22 15:40:12 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 09:40:12 -0400 Subject: [M3devel] web page messed up In-Reply-To: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> References: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> Message-ID: <4AB89AD2.1E75.00D7.1@scires.com> In IE, I see a box on the home page with horizontal and vertical scroll bars. Inside the box it has News items. This box doesn't appear to be resizable, so it is much smaller than the rest of the window when the window is maximized. Not sure if this is the desired behavior, but I don't like it. I also don't like the sea-sick green color scheme. IMO it is harder to read the text. I liked the prior "yellow and white" scheme better than this one. But, you won't please everybody no matter what you do. To me the most important thing now is content, so you haven't heard me complaining about the colors (at least not until now, sorry). On Firefox on Vista, the News box has same behavior as in IE. --Randy >>> Olaf Wagner 9/22/2009 9:21 AM >>> Quoting Jay K : > Olaf, this page: > > http://www.modula3.com/cm3/index.html > > has a glaring problem right at the start. It displays OK for me using Firefox and Opera. What's the problem? I won't say it looks good, but it displays its info ;-) > I checked in a fix weeks ago. > How does one get the update to appear? Copy the file to the web servers root on birch. However, only do this if you are really sure (locally tested etc.). It's the same procedure as for the releng packages, only the path is shorter. > I'm referring to the nested frames. > > Surely that was a typo. > > - Jay -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 15:38:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 13:38:19 +0000 Subject: [M3devel] web page messed up In-Reply-To: <20090922152116.sarokgogogsk8k0o@mail.elegosoft.com> References: Message-ID: It is bad for me in Firefox. The frames are nested. See: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/www/start.html.diff?r1=1.3.2.2;r2=1.3.2.3;f=u - Jay > Date: Tue, 22 Sep 2009 15:21:16 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: web page messed up > > Quoting Jay K : > > > Olaf, this page: > > > > http://www.modula3.com/cm3/index.html > > > > has a glaring problem right at the start. > > It displays OK for me using Firefox and Opera. What's the problem? > I won't say it looks good, but it displays its info ;-) > > > I checked in a fix weeks ago. > > How does one get the update to appear? > > Copy the file to the web servers root on birch. However, only do this > if you are really sure (locally tested etc.). It's the same procedure > as for the releng packages, only the path is shorter. > > > I'm referring to the nested frames. > > > > Surely that was a typo. > > > > - Jay > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 15:45:55 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 15:45:55 +0200 Subject: [M3devel] Fwd: Re: CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Message-ID: <20090922154555.d98ygvj34kwosogo@mail.elegosoft.com> Forward to list as it may be of interest for others: ----- Forwarded message from wagner at elegosoft.com ----- Date: Tue, 22 Sep 2009 15:44:05 +0200 From: Olaf Wagner Reply-To: Olaf Wagner Subject: Re: [M3devel] CM3 5.8 Release Engineering,was Re: back again -- cm3 status worse? To: Randy Coleburn Quoting Randy Coleburn : > Olaf: > > You stated the following about CVS: > >>>> Olaf Wagner wagner at elegosoft.com> 9/22/2009 7:21 AM >> ( >>>> mailto:wagner at elegosoft.com> ) > ... > o Release engineering is performed on the cm3_branch_release_5_8. > This should decouple (stabilizing) bug fixes from potentially > destabilizing other commits. CVS is still used for version control; > the steps needed to perform merges to the release branch are > 'cvs update -j rev' (two point merge) or 'cvs update -j rev -j rev' > (three point merge, general case). All merges in CVS are performed > in a local workspace and need to be committed explicitly (after > local testing, at least proper compilation). > ... > > I'm sorry, but I'm not fully up-to-speed on all these various CVS > options, particularly with branching and merging. I've tried to > better understand it by reading some of the TortoiseCVS > documentation, but alas, it leaves much to be desired. No problem, I'll try to explain it in more detail. > Am I to understand that we should continue to commit changes to the > repository as before (I suppose this is the HEAD branch), then for > those changes that pertain to the release, we have to merge the > changes from the head to the release branch using one of the options > you mention? Both options are possible: (a) fix on the main trunk, then merge into release branch (b) fix directly on the release branch, back merge after the release (or just later) Anyway the merge takes place in the local workspace and should be tested locally before commit. I'll care for (b) sometime after the release. > Not sure what 2-point and 3-point merges are all about. The general case when merging looks like this: a -> b -> c -> d -> e -> f (trunk head) \->p -> q -> r -> s (branch tip) Suppose you want to merge the changes from d to e into the branch. (1) You update your workspace to the branch: cvs up -r (2) You merge in the changes (`join'): cvs up -j d -j e (3) compile and test (4) Commit to the branch (thereby creating version t): cvs commit -m 'merge changes from d to e from the main trunk' This is called a three-point-merge because you explicitly specify the start, end, and target versions. If you leave out one of the -j options above, CVS implicitly assumes the common ancestor of the versions involved as the third point (in this case b). So `cvs up -j e' would merge the changes from b to e into the workspace. Two more examples (same scenario): o To merge the changes from c to f just specify these versions: cvs up -j c -j f o To revert the change committed as q use cvs up -j q -j p which applies the inverse delta to the workspace (note the order). Does this explain it more clearly? If anybody is unsure how to merge, I'm happy if he (or she) sends me two tags or file versions for inclusion into the release branch. Two simple rules: o It is always a good idea to tag any commit with a unique tag (label). o If more than one file is involved, tags are more or less mandatory (as lists of pairs of versions for every file are very tedious to handle). I'm afraid I don't know offhand how to merge in TurtoiseCVS :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 22 15:47:35 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 13:47:35 +0000 Subject: [M3devel] m3 cvs web site slightly regressed? Message-ID: Browing CVS on the web, http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/#dirlist et. al.: - icons are x's - colors are missing in dir listing -- perhaps an improvement - preferred diff format doesn't have the coloring so can't really see it but unified view works ok. Problems seen on IE/XP and Firefox/Mac10.5. Not a big deal. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Sep 22 16:00:05 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 10:00:05 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: <4AB89F7B.1E75.00D7.1@scires.com> Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 22 16:02:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 22 Sep 2009 16:02:36 +0200 Subject: [M3devel] the so_linger inconsistency between Posix and Windows In-Reply-To: References: Message-ID: <20090922160236.mnz8m23fusk4cokc@mail.elegosoft.com> Quoting Jay K : > What I wish we had but don't know if we have, is some major Modula-3 > user of sockets on both Posix and Windows, so that the change can be > tested. All stuff based on network objects. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 22 20:52:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 18:52:37 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4AB89F7B.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 20:57:27 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 18:57:27 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4AB89F7B.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? and new content: I don't like to speculate if there are problems, and if only one person sees them (even if it is me), that is close to speculation. It is good to get independent verification. You shouldn't need to test your specific code. Just run Juno under a debugger a few times and see if it access violates. Assertion failures I think are ok, unless they are asserting e.g. foo != NIL on the line before derefencing foo (as formsedit now does). - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Tue, 22 Sep 2009 18:52:37 +0000 > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Sep 22 23:06:20 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 17:06:20 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: <4AB90405.1E75.00D7.1@scires.com> Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy >>> Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? and new content: I don't like to speculate if there are problems, and if only one person sees them (even if it is me), that is close to speculation. It is good to get independent verification. You shouldn't need to test your specific code. Just run Juno under a debugger a few times and see if it access violates. Assertion failures I think are ok, unless they are asserting e.g. foo != NIL on the line before derefencing foo (as formsedit now does). - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Tue, 22 Sep 2009 18:52:37 +0000 > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 22 23:39:53 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 21:39:53 +0000 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB90405.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy >>> Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV. formsedit crashes usually on Solaris. Maybe other platforms. I still have to retry PPC_DARWIN. (and others?) It seems to date to right around 1/23/2007, changing from userthreads to pthreads. Again I checked out and built the tree at various dates, I got it to within a very small window, like 1/20/2007 - 1/25/2007. I haven't tried toggling pthreads on/off in head..well..I did for other reasons. userthreads I think are broken, initialization order. Can anyone confirm these problems exist? and new content: I don't like to speculate if there are problems, and if only one person sees them (even if it is me), that is close to speculation. It is good to get independent verification. You shouldn't need to test your specific code. Just run Juno under a debugger a few times and see if it access violates. Assertion failures I think are ok, unless they are asserting e.g. foo != NIL on the line before derefencing foo (as formsedit now does). - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Tue, 22 Sep 2009 18:52:37 +0000 > specifically referencing a particular set of Modula-3 code that was done poorly Correct, and it can't be fixed in Modula-3. Specifically m3-libs/m3core/src/unix/*.i3, and some other code like it (potentially X, OpenGL, Win32). Specifically *.i3 files that duplicate C *.h files, esp. hard to read platform-specific *.h files. The goal is not to rewrite everything in C. The goal is where we call into C, that we did not write, to have a C layer that we control and can easily read. At least where the underlying C is #ifdefed into unreadability or platform-specific. You should be able to read the m3core source without access to /usr/include of every system and have some confidence of its correctness. Previously you needed access to every target platform's /usr/include to verify it. I don't know if the problem is with the garbage collector or threads or Juno or gui stuff. I did look at the thread stuff some. They were seemingly small changes. I also tried going back just one version to before redoing part of the change. That also crashed. I looked at the gc changes, I don't understand them all. Some, but not all. I'm going to back to the Feb 20 version and see if I can tease apart some of it and find out when it starts failing. And confirm that source before/after that time succeeds/fails. - Jay Date: Tue, 22 Sep 2009 10:00:05 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Jay your message seems truncated again. Threads have always worked for me in the past on Windows. Do we have some sort of tests we can run to prove correctness of threading? Seems to me that Juno is the only thing that isn't working right, supposedly wrt threading. Perhaps the problem lies in Juno and not threads. Maybe Juno is misusing threads in some way or there is a bug in something Juno uses that exhibits itself as a thread problem. Granted, the last time I did heavy checks on my multithreaded code on Windows was before the date you say a problem was introduced, so maybe it is broken now. In any event, I think some standard regression type tests would be in order here. If we don't have them, perhaps Tony could offer some suggestions. I would be glad to write some of these tests if given some general ideas on what to check for. I don't want to get into a big argument with you (or anyone else), but I do take exception with your statements about Modula-3 being "tedious, error prone, unsafe, not portable, target-specific." Perhaps I am misinterpreting you here and you are specifically referencing a particular set of Modula-3 code that was done poorly. If so, then perhaps if you could explain what is wrong with the Modula-3 code in question, one of us can step up to the plate and make some corrections. If the SPIN folks could write an OS in Modula-3, surely we can write the compiler and library code in Modula-3. IMO, writing such code in Modula-3 should give us the benefits of Modula-3 instead of the deficiencies of C. After all, this mail list is for Modula-3 enthusiasts. We wouldn't be spending time if we didn't think this language was great. Regards, Randy >>> Jay K 9/22/2009 8:16 AM >>> The problem with the Modula-3 code is the same as usual. It is tedious, error prone, unsafe, not portable, target-specific. Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. The other -- TimePosix.m3, probably ok. Not tremendously so in this case, just a little. The idea is to drive Usysdep.i3 to empty, but the last bits might not be worth it. The C layer is also tedious and error-prone, and maybe unsafe, but it is portable and target-independent, which reduces but tedium and error-proneness. Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) and the result is that the safety guaranteeds are broken. C code wouldn't have this problem. It would #include and fail to compile. Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'll have to reconfirm that I guess. I had checked out and built the CVS tree at many dates/times, doing roughly binary search, and narrowed it down to this. Though Tony has undone this change. I admit 1) I haven't really looked at the diffs either way and 2) I don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code very well. ???It might be worthwhile to try to rewrite ThreadWin32.m3 from scratch, following ThreadPThread.m3 line for line and coming up with analogs? Along with the unscalable replacement for condition variables -- taking one global lock around certain things to get atomiticy? (Search the web for how to implement condition variables on Win32, you start to get an idea, though Modula-3 doesn't take anyone else's approach..you see all the literature is very concerned with the atomicity of certain runs of operations, that you can get on NT4 and newer at the cost of kernel transitions (SignalObjectAndWait?) but that Modula-3 gets by using a "giant lock" in some places, which might be better, might be worse). It also might be worthwhile reimplementing for Vista or newer, verify it at least works, even if the pre-Vista code remains supported for pre-Vista. (Vista adds condition variables.) You know, if that succeeds, it pins the blame on ThreadWin32.m3. If it also fails, it leaves it ambiguous as to if both "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is elsewhere. It /seems/ that Juno's pixmaps are getting copied over other data. This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 22 23:46:21 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 17:46:21 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: > > Again, what I see is that many versions before around Feb 20 2007 > consistently fail with that same assertion failure. > > I have tested many versions now, recently. > > But versions after Feb 20 2007 usually access violate on the address > 0x20000 or so, sometimes other addresses, sometimes various > assertion failures. I believe this is much worse than merely always > failing the same assertion. > > > > - Jay > > > > Date: Tue, 22 Sep 2009 17:06:20 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] more info on juno on windows > > > > > Do we know whether or not Juno ever worked on Windows ? > > I don't recall ever testing it on Windows. I still have a vd5.7.0 > cm3 that I used for the project I finished up last year (August > 2008). If I run Juno on this system (Windows XP SP3), Juno crashes > with an ASSERT failure at line 165 in winvbt/WinContext.m3. The > date on the juno.exe is 8/19/2008. > > Regards, > Randy > >>>> Jay K 9/22/2009 2:57 PM >>> > Here is the truncated part from the previous: > > This change, I think, causes Juno to access violate whereas before > it "only" failed assertions. > I believe it is considered fairly ok for a safe system to terminate > with an assertion failure, > that might not be a bug at all, but considered far worse to hit a > SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue Sep 22 23:58:52 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 22 Sep 2009 17:58:52 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> Message-ID: <4AB91054.1E75.00D7.1@scires.com> Tony: I just tried these options. Here are results: recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line 1706, while nogc gets assert in WinContext.m3 line 165. I note that the juno window begins drawing before the crash on nogc whereas it does not on paranoidgc. recent cm3 on Vista, same results as above except that it appears to reference an illegal memory location before hitting the assert in the RTCollector when using paranoidgc. old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to abort the repeating error message. Not sure if anything else happens first because it scrolls too far. For nogc, we get same behavoir as the other tests above. Regards, Randy >>> Tony Hosking 9/22/2009 5:46 PM >>> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 00:11:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Sep 2009 22:11:26 +0000 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB91054.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: current: nogc "works" -- always the WinContext/PushPixmap assertion failure paranoidgc is broken the same as default -- variety of assertion failures and access violations Including but NOT limited to: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 1708 *** which is in RefSanityCheck, doesn't look useful. still many access violations at 00200000-4. I think 00200000 just happens to be some pixmap data from the splash screen that clobbered some other data but I don't know. I posted a big hex dump the other week to see if anyone could confirm it looks like pixmaps. - Jay Date: Tue, 22 Sep 2009 17:58:52 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] more info on juno on windows Tony: I just tried these options. Here are results: recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line 1706, while nogc gets assert in WinContext.m3 line 165. I note that the juno window begins drawing before the crash on nogc whereas it does not on paranoidgc. recent cm3 on Vista, same results as above except that it appears to reference an illegal memory location before hitting the assert in the RTCollector when using paranoidgc. old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to abort the repeating error message. Not sure if anything else happens first because it scrolls too far. For nogc, we get same behavoir as the other tests above. Regards, Randy >>> Tony Hosking 9/22/2009 5:46 PM >>> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 03:34:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:34:06 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB91054.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> <180767A0-109C-4941-B3E7-B6B3FEFE5382@cs.purdue.edu> <4AB91054.1E75.00D7.1@scires.com> Message-ID: PS Running with nogc at least makes sure that you don't get the garbage collector moving things around, so it should be easier to diagnose who is doing the clobbering. Can you debug with h/w watchpoints to see who overwrites the heap. You'd need to watch the location from which the bogus reference (00200000) gets loaded, which means figuring out where the load occurred. On 22 Sep 2009, at 17:58, Randy Coleburn wrote: > Tony: > > I just tried these options. Here are results: > > recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line > 1706, while nogc gets assert in WinContext.m3 line 165. I note that > the juno window begins drawing before the crash on nogc whereas it > does not on paranoidgc. > > recent cm3 on Vista, same results as above except that it appears to > reference an illegal memory location before hitting the assert in > the RTCollector when using paranoidgc. > > old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating > assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to > abort the repeating error message. Not sure if anything else > happens first because it scrolls too far. For nogc, we get same > behavoir as the other tests above. > > Regards, > Randy > > >>> Tony Hosking 9/22/2009 5:46 PM >>> > Have you tried running with @M3nogc? And @M3paranoidgc? > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Sep 2009, at 17:39, Jay K wrote: > >> >> Again, what I see is that many versions before around Feb 20 2007 >> consistently fail with that same assertion failure. >> >> I have tested many versions now, recently. >> >> But versions after Feb 20 2007 usually access violate on the >> address 0x20000 or so, sometimes other addresses, sometimes various >> assertion failures. I believe this is much worse than merely always >> failing the same assertion. >> >> >> >> - Jay >> >> >> >> Date: Tue, 22 Sep 2009 17:06:20 -0400 >> From: rcoleburn at scires.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] more info on juno on windows >> >> >> >> >> Do we know whether or not Juno ever worked on Windows ? >> >> I don't recall ever testing it on Windows. I still have a vd5.7.0 >> cm3 that I used for the project I finished up last year (August >> 2008). If I run Juno on this system (Windows XP SP3), Juno crashes >> with an ASSERT failure at line 165 in winvbt/WinContext.m3. The >> date on the juno.exe is 8/19/2008. >> >> Regards, >> Randy >> >>>>> Jay K 9/22/2009 2:57 PM >>> >> Here is the truncated part from the previous: >> >> This change, I think, causes Juno to access violate whereas before >> it "only" failed assertions. >> I believe it is considered fairly ok for a safe system to terminate >> with an assertion failure, >> that might not be a bug at all, but considered far worse to hit a >> SIGSEGV > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 03:37:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:37:58 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4AB89F7B.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> <4AB89F7B.1E75.00D7.1@scires.com> Message-ID: On 22 Sep 2009, at 10:00, Randy Coleburn wrote: > Jay your message seems truncated again. > > Threads have always worked for me in the past on Windows. Do we > have some sort of tests we can run to prove correctness of > threading? Seems to me that Juno is the only thing that isn't > working right, supposedly wrt threading. Perhaps the problem lies > in Juno and not threads. Maybe Juno is misusing threads in some way > or there is a bug in something Juno uses that exhibits itself as a > thread problem. Granted, the last time I did heavy checks on my > multithreaded code on Windows was before the date you say a problem > was introduced, so maybe it is broken now. In any event, I think > some standard regression type tests would be in order here. If we > don't have them, perhaps Tony could offer some suggestions. I would > be glad to write some of these tests if given some general ideas on > what to check for. I'm not so convinced it is the threading code per se. Could be that we just tripped over it with some random change. The fact that we see problems arising with @M3nogc suggests that the clobber is outside the GC and threading code. Something deeper in the Windows VBT stuff perhaps? > I don't want to get into a big argument with you (or anyone else), > but I do take exception with your statements about Modula-3 being > "tedious, error prone, unsafe, not portable, target-specific." > Perhaps I am misinterpreting you here and you are specifically > referencing a particular set of Modula-3 code that was done poorly. > If so, then perhaps if you could explain what is wrong with the > Modula-3 code in question, one of us can step up to the plate and > make some corrections. If the SPIN folks could write an OS in > Modula-3, surely we can write the compiler and library code in > Modula-3. IMO, writing such code in Modula-3 should give us the > benefits of Modula-3 instead of the deficiencies of C. After all, > this mail list is for Modula-3 enthusiasts. We wouldn't be spending > time if we didn't think this language was great. PS Randy, in this case I think Jay is making the point that all of the Unix interfaces clones from C header files have no guarantees that they match the original C code. Jay's changes should result in a much cleaner, easier to port system, since problems in the bridging code from M3 to C will be caught by the C compiler. > > Regards, > Randy > > >>> Jay K 9/22/2009 8:16 AM >>> > > The problem with the Modula-3 code is the same as usual. > It is tedious, error prone, unsafe, not portable, target-specific. > Specifically Utime.i3/Usysdep.i3/DateBsd.m3/DatePosix.m3. > The other -- TimePosix.m3, probably ok. > > Not tremendously so in this case, just a little. > > The idea is to drive Usysdep.i3 to empty, but the last bits might > not be worth it. > > > > > The C layer is also tedious and error-prone, and maybe unsafe, > but it is portable and target-independent, which reduces > but tedium and error-proneness. > > > > > Look at the Utime.i3 cloning/extension in the Modula-3 web browsers. > They actually get it wrong on some systems (Cygwin, Solaris, HP-UX) > and > the result is that the safety guaranteeds are broken. > > > > > C code wouldn't have this problem. It would #include and > fail to compile. > > > > > > Yes there is fairly definitely a problem on Windows and it dates, I > think, to this change: > > > > > > 2009-02-16 02:20 hosking > > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > > > > > I'll have to reconfirm that I guess. > I had checked out and built the CVS tree at many dates/times, doing > roughly > binary search, and narrowed it down to this. > > Though Tony has undone this change. > > I admit 1) I haven't really looked at the diffs either way and 2) I > don't really understand the ThreadPThread.m3 and ThreadWin32.m3 code > very well. > > > > ???It might be worthwhile to try to rewrite ThreadWin32.m3 from > scratch, following ThreadPThread.m3 line for line and coming up with > analogs? Along with the unscalable replacement for condition > variables -- taking one global lock around certain things to get > atomiticy? (Search the web for how to implement condition variables > on Win32, you start to get an idea, though Modula-3 doesn't take > anyone else's approach..you see all the literature is very concerned > with the atomicity of certain runs of operations, that you can get > on NT4 and newer at the cost of kernel transitions > (SignalObjectAndWait?) but that Modula-3 gets by using a "giant > lock" in some places, which might be better, might be worse). > > It also might be worthwhile reimplementing for Vista or newer, > verify it at least works, even if the pre-Vista code remains > supported for pre-Vista. (Vista adds condition variables.) > > You know, if that succeeds, it pins the blame on ThreadWin32.m3. > > If it also fails, it leaves it ambiguous as to if both > "ThreadWin32CV.m3" (not yet existant) are bad, or if the problem is > elsewhere. > > > > > It /seems/ that Juno's pixmaps are getting copied over other data. > > > > > This change, I think, causes Juno to access violate whereas before > it "only" failed assertions. > > I believe it is considered fairly ok for a safe system to terminate > with an assertion failure, > that might not be a bug at all, but considered far worse to hit a > SIGSEGV From hosking at cs.purdue.edu Wed Sep 23 03:40:27 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:40:27 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: <0BD93883-9F03-442C-940F-8729D3D9D2AE@cs.purdue.edu> On 22 Sep 2009, at 08:16, Jay K wrote: > Yes there is fairly definitely a problem on Windows and it dates, I > think, to this change: > > > 2009-02-16 02:20 hosking > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. I'm not convinced that this change itself broke things, but perhaps instead exposed the brokenness. In any case, debugging this in the head will probably be easiest. If we have an example that deterministically breaks then I think we have a place to start. My suggestion for now, since it appears to trigger the problem, is to use @M3nogc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 03:43:17 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 21:43:17 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> <20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com> Message-ID: <3337B3AE-0503-4C26-8C9E-D34376786FAF@cs.purdue.edu> On 22 Sep 2009, at 07:21, Olaf Wagner wrote: > Hi Randy, Tony, Jay and all others, > > thanks for your updates. Things already look better in Hudson and > Tinderbox; there may still be some script failures which need manual > intervention. > > As this mail is relevant for all M3 committers, I've CC'ed it to > m3devel, too. > > I understand that a major bug (race condition in pthreads) has been > fixed, but there are still some problems in Windows' threads and I've not seen anything to confirm that there are problems in Window's threads. It sounds more like an issue in the Windows VBT code. I am not skilled sufficiently to debug Window's builds (...yet. Though with time I might get there if it becomes necessary). > Solaris' formsedit which are currently investigated. I'll try to add > some information of your summaries to the Trac roadmap soon. I'll look into this. From jay.krell at cornell.edu Wed Sep 23 03:51:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 01:51:05 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <0BD93883-9F03-442C-940F-8729D3D9D2AE@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: Tony there is something a bit gray that you are missing. The behavior with @M3nogc we don't necessarily consider bad/wrong/buggy. It is a consistent assertion failure. Not an access violation. It could just be Trestle not being fully supported on Windows. Olaf says Trestle was never fully ported. I'm not sure anyone knows what is missing, and if Juno really demonstrates that or not. However, versions before Feb 20 consistently act like current versions act with @M3nogc. Before Feb 20 without @M3nogc. Current with @M3nogc. What I'd like to see is current without @M3nogc to act just as bad but no worse than before Feb 20. I think the current behavior without @M3nogc is worse. It's just "fail vs. no fail". Now, that is apples and oranges. For example, I relatively recently changed the default initial allocation size and maybe incremental allocation sizes. In particular..I forget the exact details but I think changed from malloc to VirtualAlloc, and VirtualAlloc allocates in 64K chunks. I guess I should review that..but that was more recent I think, after Feb 20. I have to check. The code was a bit flawed somehow and I improved it somehow. I forget. Almost everything is subject to rerererereview when there is a bug, granted. I agree as well that Feb 20 might have just uncovered a preexisting problem. But much is unclear and figuring this out I don't think will be easy. :( - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 22 Sep 2009 21:40:27 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? On 22 Sep 2009, at 08:16, Jay K wrote: Yes there is fairly definitely a problem on Windows and it dates, I think, to this change: 2009-02-16 02:20 hosking * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c, Csupport/little-endian/dtoa.c, convert/CConvert.i3, convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, thread/WIN32/ThreadWin32.m3: Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics. This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held. RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not. I'm not convinced that this change itself broke things, but perhaps instead exposed the brokenness. In any case, debugging this in the head will probably be easiest. If we have an example that deterministically breaks then I think we have a place to start. My suggestion for now, since it appears to trigger the problem, is to use @M3nogc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 04:25:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 22:25:55 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: <52E6F992-DD37-415B-AA77-7BF305E8CC11@cs.purdue.edu> On 22 Sep 2009, at 21:51, Jay K wrote: > Tony there is something a bit gray that you are missing. Yes, clearly I am missing something. > The behavior with @M3nogc we don't necessarily consider bad/wrong/ > buggy. Right, it just takes GC out of the equation for what might be wrong. > It is a consistent assertion failure. Not an access violation. Good. We can debug that. > It could just be Trestle not being fully supported on Windows. > Olaf says Trestle was never fully ported. I don't know enough about this to say either way. > I'm not sure anyone knows what is missing, and if Juno really > demonstrates that or not. > > However, versions before Feb 20 consistently act like current > versions act with @M3nogc. > Before Feb 20 without @M3nogc. > Current with @M3nogc. What does this mean? That pre-2009-02 is just the same as post-2009-02? How does that narrow anything down to that specific time-frame? > What I'd like to see is current without @M3nogc to act just as bad > but no worse than before Feb 20. I think the current behavior > without @M3nogc is worse. It's just "fail vs. no fail". I still don't understand what this says about that particular time- frame. > Now, that is apples and oranges. For example, I relatively recently > changed the default initial allocation size and maybe incremental > allocation sizes. In particular..I forget the exact details but I > think changed from malloc to VirtualAlloc, and VirtualAlloc > allocates in 64K chunks. I guess I should review that..but that was > more recent I think, after Feb 20. I have to check. > The code was a bit flawed somehow and I improved it somehow. I > forget. Almost everything is subject to rerererereview when there is > a bug, granted. > > > I agree as well that Feb 20 might have just uncovered a preexisting > problem. > > > But much is unclear and figuring this out I don't think will be > easy. :( If we have a deterministic failure then it should be easy enough to track down. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 22 Sep 2009 21:40:27 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > again -- cm3 status worse? > > > On 22 Sep 2009, at 08:16, Jay K wrote: > > Yes there is fairly definitely a problem on Windows and it dates, I > think, to this change: > > > 2009-02-16 02:20 hosking > * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > dtoa.c, > Csupport/little-endian/dtoa.c, convert/CConvert.i3, > convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3, > thread/WIN32/ThreadWin32.m3: > Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > match underlying pthread semantics. > This means that RTOS.WaitHeap must be called while RTOS.LockHeap > is held. > RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > not. > > I'm not convinced that this change itself broke things, but perhaps > instead exposed the brokenness. In any case, debugging this in the > head will probably be easiest. If we have an example that > deterministically breaks then I think we have a place to start. My > suggestion for now, since it appears to trigger the problem, is to > use @M3nogc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 04:46:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 22 Sep 2009 22:46:30 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <52E6F992-DD37-415B-AA77-7BF305E8CC11@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> <52E6F992-DD37-415B-AA77-7BF305E8CC11@cs.purdue.edu> Message-ID: <4B9C8CCF-897C-478D-95D7-A9030AB33B92@cs.purdue.edu> What about these? They appear to be Trestle and icon-related... 2009-02-18 11:14 jkrell * m3-libs/m3core/src/win32/WinUser.i3, m3-libs/m3core/src/win32/WinUserC.c, m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ WinTrestle.m3: workaround gcc backend bug that names <*EXTERNAL WindowFromPoint:WINAPI*> PROCEDURE WindowFromPoint (Point: POINT): HWND; WindowFromPoint at 4 instead of WindowFromPoint at 8 by adding <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) { return WindowFromPoint(*Point); } This lets I386_MINGW (NT386MINGNU) get further. 2009-02-18 10:51 jkrell * m3-sys/windowsResources/src/winRes.tmpl: adapt to MinGW which has windres instead of rc with different command line usage; detect MinGW by checking if backend mode is integrated backend or not, not great..it should really be informed by a variable in the toplevel configuration -- CONFIG_HAS_RC and CONFIG_HAS_WINDRES? On 22 Sep 2009, at 22:25, Tony Hosking wrote: > On 22 Sep 2009, at 21:51, Jay K wrote: > >> Tony there is something a bit gray that you are missing. > > Yes, clearly I am missing something. > >> The behavior with @M3nogc we don't necessarily consider bad/wrong/ >> buggy. > > Right, it just takes GC out of the equation for what might be wrong. > >> It is a consistent assertion failure. Not an access violation. > > Good. We can debug that. > >> It could just be Trestle not being fully supported on Windows. >> Olaf says Trestle was never fully ported. > > I don't know enough about this to say either way. > >> I'm not sure anyone knows what is missing, and if Juno really >> demonstrates that or not. >> >> However, versions before Feb 20 consistently act like current >> versions act with @M3nogc. >> Before Feb 20 without @M3nogc. >> Current with @M3nogc. > > What does this mean? That pre-2009-02 is just the same as > post-2009-02? How does that narrow anything down to that specific > time-frame? > >> What I'd like to see is current without @M3nogc to act just as bad >> but no worse than before Feb 20. I think the current behavior >> without @M3nogc is worse. It's just "fail vs. no fail". > > I still don't understand what this says about that particular time- > frame. > >> Now, that is apples and oranges. For example, I relatively >> recently changed the default initial allocation size and maybe >> incremental allocation sizes. In particular..I forget the exact >> details but I think changed from malloc to VirtualAlloc, and >> VirtualAlloc allocates in 64K chunks. I guess I should review >> that..but that was more recent I think, after Feb 20. I have to >> check. >> The code was a bit flawed somehow and I improved it somehow. I >> forget. Almost everything is subject to rerererereview when there >> is a bug, granted. >> >> >> I agree as well that Feb 20 might have just uncovered a preexisting >> problem. >> >> >> But much is unclear and figuring this out I don't think will be >> easy. :( > > If we have a deterministic failure then it should be easy enough to > track down. > >> >> >> - Jay >> >> >> >> From: hosking at cs.purdue.edu >> To: jay.krell at cornell.edu >> Date: Tue, 22 Sep 2009 21:40:27 -0400 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back >> again -- cm3 status worse? >> >> >> On 22 Sep 2009, at 08:16, Jay K wrote: >> >> Yes there is fairly definitely a problem on Windows and it dates, I >> think, to this change: >> >> >> 2009-02-16 02:20 hosking >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ >> dtoa.c, >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ >> ThreadPThreadC.i3, >> thread/WIN32/ThreadWin32.m3: >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better >> match underlying pthread semantics. >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap >> is held. >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or >> not. >> >> I'm not convinced that this change itself broke things, but perhaps >> instead exposed the brokenness. In any case, debugging this in the >> head will probably be easiest. If we have an example that >> deterministically breaks then I think we have a place to start. My >> suggestion for now, since it appears to trigger the problem, is to >> use @M3nogc. >> >> > From jay.krell at cornell.edu Wed Sep 23 05:48:59 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 03:48:59 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4B9C8CCF-897C-478D-95D7-A9030AB33B92@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: I'm "certain" these are ok but I can try without them. 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. 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). You still aren't understanding me. We have a consistent failure before Feb 20, but it is deemed maybe ok. It was maybe always that way. It is maybe unfinished code. Not heap corruption. Though we don't know 100% and it does merit some investigation. After Feb 20 without @M3nogc we have a "more severe" and actually fairly consistent but not completely consistent failure -- heap corruption. After Feb 20 with @M3nogc acts the same as before Feb 20 without @M3nogc. - Jay > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 22 Sep 2009 22:46:30 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? > > What about these? > They appear to be Trestle and icon-related... > 2009-02-18 11:14 jkrell > > * m3-libs/m3core/src/win32/WinUser.i3, > m3-libs/m3core/src/win32/WinUserC.c, > m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ > WinTrestle.m3: > > workaround gcc backend bug that names > > <*EXTERNAL WindowFromPoint:WINAPI*> > PROCEDURE WindowFromPoint (Point: POINT): HWND; > > WindowFromPoint at 4 instead of WindowFromPoint at 8 > > by adding > > <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> > PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; > > HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) > { > return WindowFromPoint(*Point); > } > > This lets I386_MINGW (NT386MINGNU) get further. > > 2009-02-18 10:51 jkrell > > * m3-sys/windowsResources/src/winRes.tmpl: > > adapt to MinGW which has windres instead of rc with different > command line usage; detect MinGW by checking if backend mode is > integrated backend or not, not great..it should really be informed by > a variable in the toplevel configuration -- CONFIG_HAS_RC and > CONFIG_HAS_WINDRES? > > > On 22 Sep 2009, at 22:25, Tony Hosking wrote: > > > On 22 Sep 2009, at 21:51, Jay K wrote: > > > >> Tony there is something a bit gray that you are missing. > > > > Yes, clearly I am missing something. > > > >> The behavior with @M3nogc we don't necessarily consider bad/wrong/ > >> buggy. > > > > Right, it just takes GC out of the equation for what might be wrong. > > > >> It is a consistent assertion failure. Not an access violation. > > > > Good. We can debug that. > > > >> It could just be Trestle not being fully supported on Windows. > >> Olaf says Trestle was never fully ported. > > > > I don't know enough about this to say either way. > > > >> I'm not sure anyone knows what is missing, and if Juno really > >> demonstrates that or not. > >> > >> However, versions before Feb 20 consistently act like current > >> versions act with @M3nogc. > >> Before Feb 20 without @M3nogc. > >> Current with @M3nogc. > > > > What does this mean? That pre-2009-02 is just the same as > > post-2009-02? How does that narrow anything down to that specific > > time-frame? > > > >> What I'd like to see is current without @M3nogc to act just as bad > >> but no worse than before Feb 20. I think the current behavior > >> without @M3nogc is worse. It's just "fail vs. no fail". > > > > I still don't understand what this says about that particular time- > > frame. > > > >> Now, that is apples and oranges. For example, I relatively > >> recently changed the default initial allocation size and maybe > >> incremental allocation sizes. In particular..I forget the exact > >> details but I think changed from malloc to VirtualAlloc, and > >> VirtualAlloc allocates in 64K chunks. I guess I should review > >> that..but that was more recent I think, after Feb 20. I have to > >> check. > >> The code was a bit flawed somehow and I improved it somehow. I > >> forget. Almost everything is subject to rerererereview when there > >> is a bug, granted. > >> > >> > >> I agree as well that Feb 20 might have just uncovered a preexisting > >> problem. > >> > >> > >> But much is unclear and figuring this out I don't think will be > >> easy. :( > > > > If we have a deterministic failure then it should be easy enough to > > track down. > > > >> > >> > >> - Jay > >> > >> > >> > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Date: Tue, 22 Sep 2009 21:40:27 -0400 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > >> again -- cm3 status worse? > >> > >> > >> On 22 Sep 2009, at 08:16, Jay K wrote: > >> > >> Yes there is fairly definitely a problem on Windows and it dates, I > >> think, to this change: > >> > >> > >> 2009-02-16 02:20 hosking > >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > >> dtoa.c, > >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, > >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ > >> ThreadPThreadC.i3, > >> thread/WIN32/ThreadWin32.m3: > >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > >> match underlying pthread semantics. > >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap > >> is held. > >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > >> not. > >> > >> I'm not convinced that this change itself broke things, but perhaps > >> instead exposed the brokenness. In any case, debugging this in the > >> head will probably be easiest. If we have an example that > >> deterministically breaks then I think we have a place to start. My > >> suggestion for now, since it appears to trigger the problem, is to > >> use @M3nogc. > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 05:51:58 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 03:51:58 +0000 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: <4B9C8CCF-897C-478D-95D7-A9030AB33B92@cs.purdue.edu> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: Plus I think I narrowed the problem down to a 30 minute window, not just a day. I build like 2:00 and 2:30 on the day of the heap/lock change. But granted it might only be revealing some other problem, that was always there or recently introduced or long ago introduced... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? Date: Wed, 23 Sep 2009 03:48:59 +0000 I'm "certain" these are ok but I can try without them. 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. 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). You still aren't understanding me. We have a consistent failure before Feb 20, but it is deemed maybe ok. It was maybe always that way. It is maybe unfinished code. Not heap corruption. Though we don't know 100% and it does merit some investigation. After Feb 20 without @M3nogc we have a "more severe" and actually fairly consistent but not completely consistent failure -- heap corruption. After Feb 20 with @M3nogc acts the same as before Feb 20 without @M3nogc. - Jay > From: hosking at cs.purdue.edu > To: hosking at cs.purdue.edu > Date: Tue, 22 Sep 2009 22:46:30 -0400 > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? > > What about these? > They appear to be Trestle and icon-related... > 2009-02-18 11:14 jkrell > > * m3-libs/m3core/src/win32/WinUser.i3, > m3-libs/m3core/src/win32/WinUserC.c, > m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ > WinTrestle.m3: > > workaround gcc backend bug that names > > <*EXTERNAL WindowFromPoint:WINAPI*> > PROCEDURE WindowFromPoint (Point: POINT): HWND; > > WindowFromPoint at 4 instead of WindowFromPoint at 8 > > by adding > > <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> > PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; > > HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) > { > return WindowFromPoint(*Point); > } > > This lets I386_MINGW (NT386MINGNU) get further. > > 2009-02-18 10:51 jkrell > > * m3-sys/windowsResources/src/winRes.tmpl: > > adapt to MinGW which has windres instead of rc with different > command line usage; detect MinGW by checking if backend mode is > integrated backend or not, not great..it should really be informed by > a variable in the toplevel configuration -- CONFIG_HAS_RC and > CONFIG_HAS_WINDRES? > > > On 22 Sep 2009, at 22:25, Tony Hosking wrote: > > > On 22 Sep 2009, at 21:51, Jay K wrote: > > > >> Tony there is something a bit gray that you are missing. > > > > Yes, clearly I am missing something. > > > >> The behavior with @M3nogc we don't necessarily consider bad/wrong/ > >> buggy. > > > > Right, it just takes GC out of the equation for what might be wrong. > > > >> It is a consistent assertion failure. Not an access violation. > > > > Good. We can debug that. > > > >> It could just be Trestle not being fully supported on Windows. > >> Olaf says Trestle was never fully ported. > > > > I don't know enough about this to say either way. > > > >> I'm not sure anyone knows what is missing, and if Juno really > >> demonstrates that or not. > >> > >> However, versions before Feb 20 consistently act like current > >> versions act with @M3nogc. > >> Before Feb 20 without @M3nogc. > >> Current with @M3nogc. > > > > What does this mean? That pre-2009-02 is just the same as > > post-2009-02? How does that narrow anything down to that specific > > time-frame? > > > >> What I'd like to see is current without @M3nogc to act just as bad > >> but no worse than before Feb 20. I think the current behavior > >> without @M3nogc is worse. It's just "fail vs. no fail". > > > > I still don't understand what this says about that particular time- > > frame. > > > >> Now, that is apples and oranges. For example, I relatively > >> recently changed the default initial allocation size and maybe > >> incremental allocation sizes. In particular..I forget the exact > >> details but I think changed from malloc to VirtualAlloc, and > >> VirtualAlloc allocates in 64K chunks. I guess I should review > >> that..but that was more recent I think, after Feb 20. I have to > >> check. > >> The code was a bit flawed somehow and I improved it somehow. I > >> forget. Almost everything is subject to rerererereview when there > >> is a bug, granted. > >> > >> > >> I agree as well that Feb 20 might have just uncovered a preexisting > >> problem. > >> > >> > >> But much is unclear and figuring this out I don't think will be > >> easy. :( > > > > If we have a deterministic failure then it should be easy enough to > > track down. > > > >> > >> > >> - Jay > >> > >> > >> > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Date: Tue, 22 Sep 2009 21:40:27 -0400 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > >> again -- cm3 status worse? > >> > >> > >> On 22 Sep 2009, at 08:16, Jay K wrote: > >> > >> Yes there is fairly definitely a problem on Windows and it dates, I > >> think, to this change: > >> > >> > >> 2009-02-16 02:20 hosking > >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > >> dtoa.c, > >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, > >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ > >> ThreadPThreadC.i3, > >> thread/WIN32/ThreadWin32.m3: > >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > >> match underlying pthread semantics. > >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap > >> is held. > >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > >> not. > >> > >> I'm not convinced that this change itself broke things, but perhaps > >> instead exposed the brokenness. In any case, debugging this in the > >> head will probably be easiest. If we have an example that > >> deterministically breaks then I think we have a place to start. My > >> suggestion for now, since it appears to trigger the problem, is to > >> use @M3nogc. > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 06:03:22 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Sep 2009 00:03:22 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: On 22 Sep 2009, at 23:48, Jay K wrote: > I'm "certain" these are ok but I can try without them. > 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. > > > 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). > > > You still aren't understanding me. > > We have a consistent failure before Feb 20, but it is deemed maybe ok. > It was maybe always that way. It is maybe unfinished code. Not > heap corruption. > Though we don't know 100% and it does merit some investigation. > > After Feb 20 without @M3nogc we have a "more severe" and actually > fairly consistent but not completely consistent failure -- heap > corruption. OK, now I think I begin to understand. What happens with @M3paranoidgc on the post-2009-02 code is what you sent earlier, right? Sounds like something is being collected when it should not, resulting in a dangling reference to memory that gets reused for something else. I don't think I changed anything that would affect that. I'll take another look. The M3paranoidgc flag should catch any dangling reference. Can you try with @M3noincremental and/or @M3nogenerational? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 23 06:32:30 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 23 Sep 2009 00:32:30 -0400 Subject: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse? In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com> Message-ID: 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? On 22 Sep 2009, at 23:51, Jay K wrote: > Plus I think I narrowed the problem down to a 30 minute window, not > just a day. > I build like 2:00 and 2:30 on the day of the heap/lock change. > But granted it might only be revealing some other problem, that was > always there or recently introduced or long ago introduced... > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] CM3 5.8 Release Engineering, was Re: back > again -- cm3 status worse? > Date: Wed, 23 Sep 2009 03:48:59 +0000 > > I'm "certain" these are ok but I can try without them. > 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. > > > 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). > > > You still aren't understanding me. > > We have a consistent failure before Feb 20, but it is deemed maybe ok. > It was maybe always that way. It is maybe unfinished code. Not > heap corruption. > Though we don't know 100% and it does merit some investigation. > > After Feb 20 without @M3nogc we have a "more severe" and actually > fairly consistent but not completely consistent failure -- heap > corruption. > > After Feb 20 with @M3nogc acts the same as before Feb 20 without > @M3nogc. > > > - Jay > > > From: hosking at cs.purdue.edu > > To: hosking at cs.purdue.edu > > Date: Tue, 22 Sep 2009 22:46:30 -0400 > > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > > Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > again -- cm3 status worse? > > > > What about these? > > They appear to be Trestle and icon-related... > > 2009-02-18 11:14 jkrell > > > > * m3-libs/m3core/src/win32/WinUser.i3, > > m3-libs/m3core/src/win32/WinUserC.c, > > m3-libs/m3core/src/win32/m3makefile, m3-ui/ui/src/winvbt/ > > WinTrestle.m3: > > > > workaround gcc backend bug that names > > > > <*EXTERNAL WindowFromPoint:WINAPI*> > > PROCEDURE WindowFromPoint (Point: POINT): HWND; > > > > WindowFromPoint at 4 instead of WindowFromPoint at 8 > > > > by adding > > > > <*EXTERNAL WinUser__WindowFromPointWorkaround:WINAPI*> > > PROCEDURE WindowFromPointWorkaround (VAR Point: POINT): HWND; > > > > HWND __stdcall WinUser__WindowFromPointWorkaround (POINT* Point) > > { > > return WindowFromPoint(*Point); > > } > > > > This lets I386_MINGW (NT386MINGNU) get further. > > > > 2009-02-18 10:51 jkrell > > > > * m3-sys/windowsResources/src/winRes.tmpl: > > > > adapt to MinGW which has windres instead of rc with different > > command line usage; detect MinGW by checking if backend mode is > > integrated backend or not, not great..it should really be informed > by > > a variable in the toplevel configuration -- CONFIG_HAS_RC and > > CONFIG_HAS_WINDRES? > > > > > > On 22 Sep 2009, at 22:25, Tony Hosking wrote: > > > > > On 22 Sep 2009, at 21:51, Jay K wrote: > > > > > >> Tony there is something a bit gray that you are missing. > > > > > > Yes, clearly I am missing something. > > > > > >> The behavior with @M3nogc we don't necessarily consider bad/ > wrong/ > > >> buggy. > > > > > > Right, it just takes GC out of the equation for what might be > wrong. > > > > > >> It is a consistent assertion failure. Not an access violation. > > > > > > Good. We can debug that. > > > > > >> It could just be Trestle not being fully supported on Windows. > > >> Olaf says Trestle was never fully ported. > > > > > > I don't know enough about this to say either way. > > > > > >> I'm not sure anyone knows what is missing, and if Juno really > > >> demonstrates that or not. > > >> > > >> However, versions before Feb 20 consistently act like current > > >> versions act with @M3nogc. > > >> Before Feb 20 without @M3nogc. > > >> Current with @M3nogc. > > > > > > What does this mean? That pre-2009-02 is just the same as > > > post-2009-02? How does that narrow anything down to that specific > > > time-frame? > > > > > >> What I'd like to see is current without @M3nogc to act just as > bad > > >> but no worse than before Feb 20. I think the current behavior > > >> without @M3nogc is worse. It's just "fail vs. no fail". > > > > > > I still don't understand what this says about that particular > time- > > > frame. > > > > > >> Now, that is apples and oranges. For example, I relatively > > >> recently changed the default initial allocation size and maybe > > >> incremental allocation sizes. In particular..I forget the exact > > >> details but I think changed from malloc to VirtualAlloc, and > > >> VirtualAlloc allocates in 64K chunks. I guess I should review > > >> that..but that was more recent I think, after Feb 20. I have to > > >> check. > > >> The code was a bit flawed somehow and I improved it somehow. I > > >> forget. Almost everything is subject to rerererereview when there > > >> is a bug, granted. > > >> > > >> > > >> I agree as well that Feb 20 might have just uncovered a > preexisting > > >> problem. > > >> > > >> > > >> But much is unclear and figuring this out I don't think will be > > >> easy. :( > > > > > > If we have a deterministic failure then it should be easy enough > to > > > track down. > > > > > >> > > >> > > >> - Jay > > >> > > >> > > >> > > >> From: hosking at cs.purdue.edu > > >> To: jay.krell at cornell.edu > > >> Date: Tue, 22 Sep 2009 21:40:27 -0400 > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back > > >> again -- cm3 status worse? > > >> > > >> > > >> On 22 Sep 2009, at 08:16, Jay K wrote: > > >> > > >> Yes there is fairly definitely a problem on Windows and it > dates, I > > >> think, to this change: > > >> > > >> > > >> 2009-02-16 02:20 hosking > > >> * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/ > > >> dtoa.c, > > >> Csupport/little-endian/dtoa.c, convert/CConvert.i3, > > >> convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3, > > >> runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3, > > >> runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3, > > >> thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3, > > >> thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ > > >> ThreadPThreadC.i3, > > >> thread/WIN32/ThreadWin32.m3: > > >> Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better > > >> match underlying pthread semantics. > > >> This means that RTOS.WaitHeap must be called while RTOS.LockHeap > > >> is held. > > >> RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or > > >> not. > > >> > > >> I'm not convinced that this change itself broke things, but > perhaps > > >> instead exposed the brokenness. In any case, debugging this in > the > > >> head will probably be easiest. If we have an example that > > >> deterministically breaks then I think we have a place to start. > My > > >> suggestion for now, since it appears to trigger the problem, is > to > > >> use @M3nogc. > > >> > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 23 09:30:22 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 09:30:22 +0200 Subject: [M3devel] package tests regression Message-ID: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> I noticed yesterday that several package build jobs failed because of wrong timestamps (probably some changed dependency). But even after cleaning everything before compilation AMD64_LINUX and FreeBSD (which should run without any errors) show some regression: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests Perhaps some missing overrides again? Or something else? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Sep 23 09:39:18 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 09:39:18 +0200 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> Quoting Olaf Wagner : > I noticed yesterday that several package build jobs failed because > of wrong timestamps (probably some changed dependency). But even after > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > run without any errors) show some regression: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests Tests seem to be completely messed up for Solaris (no results at all): http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run for 11 and 23 days respectively, probably due to unavailability of the build machines. I've started those now manually. xdarwin is offline currently though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 23 09:42:38 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 07:42:38 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: I thought I386_OPENBSD had been up pretty well. I check it every so often. There was maybe over a week of no checkins to release actually so maybe no tests then? :) I386_DARWIN I'll leave on, and AMD64_FREEBSD.. I agree about Solaris. And I was trying to fix the date/expr stuff on Solaris. - Jay > Date: Wed, 23 Sep 2009 09:39:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Olaf Wagner : > > > I noticed yesterday that several package build jobs failed because > > of wrong timestamps (probably some changed dependency). But even after > > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > > run without any errors) show some regression: > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests > > Tests seem to be completely messed up for Solaris (no results at all): > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console > > Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run > for 11 and 23 days respectively, probably due to unavailability of the > build machines. I've started those now manually. xdarwin is offline > currently though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 09:44:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 07:44:46 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: I see the problem. My fix for Solaris is quite bad. It doesn't account for the cwd changing during pkgmap. Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; export PATH and then run m3date. Or maybe you can do an awk one liner there?? I figured C was easy enough. Or just remove the date %+s altogether? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] more package tests regression Date: Wed, 23 Sep 2009 07:42:38 +0000 I thought I386_OPENBSD had been up pretty well. I check it every so often. There was maybe over a week of no checkins to release actually so maybe no tests then? :) I386_DARWIN I'll leave on, and AMD64_FREEBSD.. I agree about Solaris. And I was trying to fix the date/expr stuff on Solaris. - Jay > Date: Wed, 23 Sep 2009 09:39:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Olaf Wagner : > > > I noticed yesterday that several package build jobs failed because > > of wrong timestamps (probably some changed dependency). But even after > > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > > run without any errors) show some regression: > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests > > Tests seem to be completely messed up for Solaris (no results at all): > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console > > Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run > for 11 and 23 days respectively, probably due to unavailability of the > build machines. I've started those now manually. xdarwin is offline > currently though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 23 09:48:17 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 07:48:17 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923093918.bl3tgf95c84kwkg4@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: PPC_LINUX should also have good availability..I'll double check in a bit... (All of xlin (Linux/x86), plin (Linux/ppc), slin (Linux/sparc), ssol (Solaris/sparc), xobsd (OpenBSD/x86) should have good availability a while now; "jbook2" (Mac/amd64/x86) and its vms (afbsd (FreeBSD/AMD64)) yeah they've been off and on, I'll leave them on; there are yet other machines...). - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] more package tests regression Date: Wed, 23 Sep 2009 07:44:46 +0000 I see the problem. My fix for Solaris is quite bad. It doesn't account for the cwd changing during pkgmap. Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; export PATH and then run m3date. Or maybe you can do an awk one liner there?? I figured C was easy enough. Or just remove the date %+s altogether? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] more package tests regression Date: Wed, 23 Sep 2009 07:42:38 +0000 I thought I386_OPENBSD had been up pretty well. I check it every so often. There was maybe over a week of no checkins to release actually so maybe no tests then? :) I386_DARWIN I'll leave on, and AMD64_FREEBSD.. I agree about Solaris. And I was trying to fix the date/expr stuff on Solaris. - Jay > Date: Wed, 23 Sep 2009 09:39:18 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Olaf Wagner : > > > I noticed yesterday that several package build jobs failed because > > of wrong timestamps (probably some changed dependency). But even after > > cleaning everything before compilation AMD64_LINUX and FreeBSD (which should > > run without any errors) show some regression: > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_patternmatching_tests > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/lastBuild/testReport/(root)/CM3%20package%20tests%20status/m3_libs_arithmetic_tests > > Tests seem to be completely messed up for Solaris (no results at all): > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/44/console > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/34/console > > Builds and tests for I386_DARWIN, I386_OPENBSD and PPC_LINUX haben't run > for 11 and 23 days respectively, probably due to unavailability of the > build machines. I've started those now manually. xdarwin is offline > currently though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 23 11:18:41 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 11:18:41 +0200 Subject: [M3devel] Reasoning for /usr/local/cm3 ? Message-ID: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Quoting Martin Bishop : > Why does everything install into /usr/local/cm3/* ? I tried editing my > PATH variable to get the cm3 binary in there, but I still have to > 'source /etc/profile' with every shell. And if I symlink it, it causes > problems. The paths are different on different systems. /usr/local/cm3 is just the system-specifics-ignoring default of a generic cm3 installation. System-specific packages are currently being prepared by some people, but not yet finished as far as I know. There should be mails in the archives about download locations. > Is there a reason to not just install to normal positions like /usr/bin > and /usr/lib, etc? Is it possible to tell cminstall where to install > other the default /usr/local/cm3 ? Sure. Just give cminstall the target directory as argument. It will always install a complete tree though (bin, lib, pkg, doc, www, ...). If that doesn't suffice, you may also be able to use symlinks for the main binaries in one of your PATH directories. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 23 13:23:20 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 11:23:20 +0000 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > problems. > Symlink should work. Symlink /usr/bin/cm3 to /usr/local/cm3/bin? Hardlinks would not likely work. /usr/local/cm3/bin is used instead of /usr/bin, because it makes it clear what goes/came together and uninstall is just a recursive delete. "uninstall is just a recursive delete" is something a lot of people like, and sometimes it is available, sometimes not. What about that PATH=/usr/local/cm3/bin:$PATH tidbits left behind in ~/.bashrc that user put in manually... Some people would use the shorter /opt/cm3. Personally I use /cm3, possibly symlinked to ~jay/cm3. (Note: symlinks not necessarily available!) I like that /opt is shorter, but there is much inertia/momentum behind /usr/local -- the default for autoconf, but granted, not /usr/local/pkg. Some folks use /opt/pkg1 /opt/pkg2 and then blow up $PATH with lots of entries. Others use symlinks into the shared /usr/bin and whatnot. Maybe others just use full paths. There is no perfect answer here. Every approach has (large, glarying) advantages and disadvantages. It is quite unfortunate but I really just try to ignore it. I believe you could spend, uh, infinite time discussing and implementing package management and as I said, you'd still have large glarying disadvantages. Of course there are various package managers that let you put everything "intermixed" in /usr and they keep track of what came from what and allow uninstall that isn't just a recursive delete. Some people use a userid per package. One more thing before I shut up ... we produce package manager indepent packages. So not much of an installer/uninstaller, no package database. I do have code to produce .deb files checked in. I should enable that soon. I'm inclined to just produce one large cm3-linux-x86.deb, cm3-linux-amd64.deb, cm3-linux-sparc.deb, etc. Not all the broken out packages that Olaf did. No dependencies. Not ubuntuv1, debianv4, etc., just claim that are fairly portable and see what happens. They could even be easily installed on non-Debian systems -- a .deb file is a very simple format esp. if you ignore the metadata file. It is as I recall an ar file with a metadata file and a nested .tar.gz or .tar.bz2 or .tar.lzma -- and due to the .tar.lzma option, much smaller than others. (And heck, we could make .debs for Darwin and Solaris; it really just takes like two lines of .sh to install them...) - Jay > Date: Wed, 23 Sep 2009 11:18:41 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ? > > Quoting Martin Bishop : > > > Why does everything install into /usr/local/cm3/* ? I tried editing my > > PATH variable to get the cm3 binary in there, but I still have to > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > problems. > > The paths are different on different systems. /usr/local/cm3 is just > the system-specifics-ignoring default of a generic cm3 installation. > System-specific packages are currently being prepared by some > people, but not yet finished as far as I know. There should be > mails in the archives about download locations. > > > Is there a reason to not just install to normal positions like /usr/bin > > and /usr/lib, etc? Is it possible to tell cminstall where to install > > other the default /usr/local/cm3 ? > > Sure. Just give cminstall the target directory as argument. > It will always install a complete tree though (bin, lib, pkg, doc, www, ...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 23 13:48:36 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Sep 2009 13:48:36 +0200 Subject: [M3devel] more package tests regression In-Reply-To: References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: <20090923134836.9axwal8pgk4k0gcc@mail.elegosoft.com> Quoting Jay K : > > I see the problem. My fix for Solaris is quite bad. > > It doesn't account for the cwd changing during pkgmap. > > Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; > export PATH and then run m3date. > > Or maybe you can do an awk one liner there?? > > I figured C was easy enough. > > Or just remove the date %+s altogether? Tests on NT386 now show === package m3-sys/libdump === /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: line 388: ./m3date: No such file or directory /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: line 391: ./m3date: No such file or directory expr: non-numeric argument (standard_in) 1: parse error for all packages :-( Perhaps you could just comment-out the date stuff for the time being (if we don't really need it)? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Sep 23 14:11:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 12:11:24 +0000 Subject: [M3devel] more package tests regression In-Reply-To: <20090923134836.9axwal8pgk4k0gcc@mail.elegosoft.com> References: <20090923093022.ntpndh9tc8c4gc4o@mail.elegosoft.com> Message-ID: I just fixed "my part". It is to get "your part" to work -- date +%s on Solaris. If your part isn't needed, definltely delete it and mine. If you want yours though, give mine another change please, thanks. Or if it is optional, maybe just enable it on non-Solaris systems (`uname` = "SunOS")? - Jay > Date: Wed, 23 Sep 2009 13:48:36 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more package tests regression > > Quoting Jay K : > > > > > I see the problem. My fix for Solaris is quite bad. > > > > It doesn't account for the cwd changing during pkgmap. > > > > Instead of running ./m3date, we should maybe PATH=`pwd`:$PATH; > > export PATH and then run m3date. > > > > Or maybe you can do an awk one liner there?? > > > > I figured C was easy enough. > > > > Or just remove the date %+s altogether? > > Tests on NT386 now show > > === package m3-sys/libdump === > > /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: > line 388: ./m3date: No such file or directory > > /home/elego/workspace/cm3-test-all-pkgs-NT386/cm3/scripts/pkgmap.sh: > line 391: ./m3date: No such file or directory > > expr: non-numeric argument > > (standard_in) 1: parse error > > for all packages :-( > > Perhaps you could just comment-out the date stuff for the time being > (if we don't really need it)? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Sep 23 16:16:49 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 23 Sep 2009 10:16:49 -0400 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: <20090923141648.GA26316@topoi.pooq.com> On Wed, Sep 23, 2009 at 11:23:20AM +0000, Jay K wrote: > > > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > > problems. > > > > > > Symlink should work. > > Symlink /usr/bin/cm3 to /usr/local/cm3/bin? There's a program called stow (http://www.gnu.org/software/stow/) to make these soft links and keep track of them. -- hendrik From mbishop at esoteriq.org Wed Sep 23 18:32:21 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 23 Sep 2009 11:32:21 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: <4ABA4D95.3060100@esoteriq.org> Jay K wrote: > > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > > problems. > > > > Symlink should work. > Symlink /usr/bin/cm3 to /usr/local/cm3/bin? > Hardlinks would not likely work. > > > /usr/local/cm3/bin is used instead of /usr/bin, because it makes it > clear what goes/came together and uninstall is just a recursive delete. > "uninstall is just a recursive delete" is something a lot of people > like, and sometimes it is available, sometimes not. What about that > PATH=/usr/local/cm3/bin:$PATH tidbits left behind in ~/.bashrc that > user put in manually... > > > Some people would use the shorter /opt/cm3. > > Personally I use /cm3, possibly symlinked to ~jay/cm3. > (Note: symlinks not necessarily available!) > > I like that /opt is shorter, but there is much inertia/momentum behind > /usr/local -- the default for autoconf, but granted, not /usr/local/pkg. > > Some folks use > /opt/pkg1 > /opt/pkg2 > > and then blow up $PATH with lots of entries. Others use symlinks into > the shared /usr/bin and whatnot. > Maybe others just use full paths. > > There is no perfect answer here. Every approach has (large, glarying) > advantages and disadvantages. > It is quite unfortunate but I really just try to ignore it. I believe > you could spend, uh, infinite time discussing and implementing package > management and as I said, you'd still have large glarying disadvantages. > > Of course there are various package managers that let you put > everything "intermixed" in /usr and they keep track of what came from > what and allow uninstall that isn't just a recursive delete. > > Some people use a userid per package. > > One more thing before I shut up ... we produce package manager > indepent packages. > So not much of an installer/uninstaller, no package database. > Thanks, I guess there really isn't a simple answer... > I do have code to produce .deb files checked in. I should enable that > soon. > I'm inclined to just produce one large cm3-linux-x86.deb, > cm3-linux-amd64.deb, cm3-linux-sparc.deb, etc. Not all the broken out > packages that Olaf did. No dependencies. Not ubuntuv1, debianv4, etc., > just claim that are fairly portable and see what happens. They could > even be easily installed on non-Debian systems -- a .deb file is a > very simple format esp. if you ignore the metadata file. It is as I > recall an ar file with a metadata file and a nested .tar.gz or > .tar.bz2 or .tar.lzma -- and due to the .tar.lzma option, much smaller > than others. (And heck, we could make .debs for Darwin and Solaris; it > really just takes like two lines of .sh to install them...) > You should definitely provide debs for the stable release. Will help get more people to try it out. > > - Jay > > > > > Date: Wed, 23 Sep 2009 11:18:41 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ? > > > > Quoting Martin Bishop : > > > > > Why does everything install into /usr/local/cm3/* ? I tried editing my > > > PATH variable to get the cm3 binary in there, but I still have to > > > 'source /etc/profile' with every shell. And if I symlink it, it causes > > > problems. > > > > The paths are different on different systems. /usr/local/cm3 is just > > the system-specifics-ignoring default of a generic cm3 installation. > > System-specific packages are currently being prepared by some > > people, but not yet finished as far as I know. There should be > > mails in the archives about download locations. > > > > > Is there a reason to not just install to normal positions like > /usr/bin > > > and /usr/lib, etc? Is it possible to tell cminstall where to install > > > other the default /usr/local/cm3 ? > > > > Sure. Just give cminstall the target directory as argument. > > It will always install a complete tree though (bin, lib, pkg, doc, > www, ...) From mbishop at esoteriq.org Wed Sep 23 18:34:18 2009 From: mbishop at esoteriq.org (Martin Bishop) Date: Wed, 23 Sep 2009 11:34:18 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> Message-ID: <4ABA4E0A.3080202@esoteriq.org> Olaf Wagner wrote: > Quoting Martin Bishop : > >> Why does everything install into /usr/local/cm3/* ? I tried editing my >> PATH variable to get the cm3 binary in there, but I still have to >> 'source /etc/profile' with every shell. And if I symlink it, it causes >> problems. > > The paths are different on different systems. /usr/local/cm3 is just > the system-specifics-ignoring default of a generic cm3 installation. > System-specific packages are currently being prepared by some > people, but not yet finished as far as I know. There should be > mails in the archives about download locations. > >> Is there a reason to not just install to normal positions like /usr/bin >> and /usr/lib, etc? Is it possible to tell cminstall where to install >> other the default /usr/local/cm3 ? > > Sure. Just give cminstall the target directory as argument. > It will always install a complete tree though (bin, lib, pkg, doc, > www, ...) Oh! Didn't know that. Thanks From jay.krell at cornell.edu Wed Sep 23 20:23:08 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Wed, 23 Sep 2009 11:23:08 -0700 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <4ABA4D95.3060100@esoteriq.org> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> <4ABA4D95.3060100@esoteriq.org> Message-ID: Upon further thought symlink might not work. We can make it work on some systems e.g. Mac and cygwin. Problem I see is, how does one find the executable's fullpath? If the symlink source is in argv[0] then no posix portable way. I was looking at this for finding cm3.cfg. -jay/phone From rodney.m.bates at cox.net Wed Sep 23 20:53:49 2009 From: rodney.m.bates at cox.net (Rodney M. Bates) Date: Wed, 23 Sep 2009 13:53:49 -0500 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> <4ABA4D95.3060100@esoteriq.org> Message-ID: <4ABA6EBD.7050301@cox.net> I've had this around for a while. Don't know how portable it is. It's mainly a main executable wrapper for, and delegates the real work to, FS.GetAbsolutePathname, which, if not fully portable, ought to be fixed so it is. It works on LINUXLIBC6 and AMD64_LINUX. It also changes backslashes to forward slashes. Maybe better for general script use if it returned a return code if things go awry. jay.krell at cornell.edu wrote: > Upon further thought symlink might not work. We can make it work on > some systems e.g. Mac and cygwin. Problem I see is, how does one find > the executable's fullpath? If the symlink source is in argv[0] then no > posix portable way. I was looking at this for finding cm3.cfg. > > -jay/phone > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: AbsPath.m3 URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m3makefile URL: From jay.krell at cornell.edu Thu Sep 24 01:25:09 2009 From: jay.krell at cornell.edu (Jay K) Date: Wed, 23 Sep 2009 23:25:09 +0000 Subject: [M3devel] Reasoning for /usr/local/cm3 ? In-Reply-To: <4ABA6EBD.7050301@cox.net> References: <20090923111841.2yvka06ssog80wg4@mail.elegosoft.com> <4ABA4D95.3060100@esoteriq.org> Message-ID: I don't believe that FS.GetAbsolutePathname(RTArgs.Get(1)) is correct. mkdir /path /cwd PATH=/path cp /usr/bin/ls /path cp /usr/bin/ls /cwd cd /cwd ls You will return /cwd/ instead of the correct /path/lsh. The code I have seen to handle this is roundabout. You have to first check for dots and/or slashes. If they are present, you use GetAbsolutePathname like you do. Else you split up $PATH on the appropriate character, appending argv[0] to each element and see if it exists and/or is executable. On Windows that isn't right probably, due to "extensions", however on Windows there is a very simple way, just GetModuleFileName(NULL). I expect there is a simple way on Mac too. There might be a way to fish out the dynamic linker parameters on other systems. But I don't think Posix provides a correct simple way. - Jay > Date: Wed, 23 Sep 2009 13:53:49 -0500 > From: rodney.m.bates at cox.net > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Reasoning for /usr/local/cm3 ? > > I've had this around for a while. Don't know how portable it is. > It's mainly a main executable wrapper for, and > delegates the real work to, FS.GetAbsolutePathname, > which, if not fully portable, ought to be fixed so it is. > > It works on LINUXLIBC6 and AMD64_LINUX. > > It also changes backslashes to forward slashes. > Maybe better for general script use if it returned > a return code if things go awry. > > jay.krell at cornell.edu wrote: > > Upon further thought symlink might not work. We can make it work on > > some systems e.g. Mac and cygwin. Problem I see is, how does one find > > the executable's fullpath? If the symlink source is in argv[0] then no > > posix portable way. I was looking at this for finding cm3.cfg. > > > > -jay/phone > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Sep 24 16:24:21 2009 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Sep 2009 14:24:21 +0000 Subject: [M3devel] more info on juno on windows In-Reply-To: <4AB91054.1E75.00D7.1@scires.com> References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: @M3noincremental about the same crashing @M3nogenerational about the same crashing @M3noincremental @M3nogenerational about the same crashing - Jay From: jay.krell at cornell.edu To: rcoleburn at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] more info on juno on windows Date: Tue, 22 Sep 2009 22:11:26 +0000 current: nogc "works" -- always the WinContext/PushPixmap assertion failure paranoidgc is broken the same as default -- variety of assertion failures and access violations Including but NOT limited to: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\runtime\common\RTCollector.m3", line 1708 *** which is in RefSanityCheck, doesn't look useful. still many access violations at 00200000-4. I think 00200000 just happens to be some pixmap data from the splash screen that clobbered some other data but I don't know. I posted a big hex dump the other week to see if anyone could confirm it looks like pixmaps. - Jay Date: Tue, 22 Sep 2009 17:58:52 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: Re: [M3devel] more info on juno on windows Tony: I just tried these options. Here are results: recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line 1706, while nogc gets assert in WinContext.m3 line 165. I note that the juno window begins drawing before the crash on nogc whereas it does not on paranoidgc. recent cm3 on Vista, same results as above except that it appears to reference an illegal memory location before hitting the assert in the RTCollector when using paranoidgc. old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to abort the repeating error message. Not sure if anything else happens first because it scrolls too far. For nogc, we get same behavoir as the other tests above. Regards, Randy >>> Tony Hosking 9/22/2009 5:46 PM >>> Have you tried running with @M3nogc? And @M3paranoidgc? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Sep 2009, at 17:39, Jay K wrote: Again, what I see is that many versions before around Feb 20 2007 consistently fail with that same assertion failure. I have tested many versions now, recently. But versions after Feb 20 2007 usually access violate on the address 0x20000 or so, sometimes other addresses, sometimes various assertion failures. I believe this is much worse than merely always failing the same assertion. - Jay Date: Tue, 22 Sep 2009 17:06:20 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] more info on juno on windows Do we know whether or not Juno ever worked on Windows ? I don't recall ever testing it on Windows. I still have a vd5.7.0 cm3 that I used for the project I finished up last year (August 2008). If I run Juno on this system (Windows XP SP3), Juno crashes with an ASSERT failure at line 165 in winvbt/WinContext.m3. The date on the juno.exe is 8/19/2008. Regards, Randy Jay K 9/22/2009 2:57 PM >>> Here is the truncated part from the previous: This change, I think, causes Juno to access violate whereas before it "only" failed assertions. I believe it is considered fairly ok for a safe system to terminate with an assertion failure, that might not be a bug at all, but considered far worse to hit a SIGSEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Sep 24 16:33:23 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 24 Sep 2009 10:33:23 -0400 Subject: [M3devel] more info on juno on windows In-Reply-To: References: <20090921162512.yz2ywm3xwc0sg8cs@mail.elegosoft.com> <4AB758FE.1E75.00D7.1@scires.com><20090922132146.hzgikt3mecks0cwk@mail.elegosoft.com><4AB89F7B.1E75.00D7.1@scires.com> Message-ID: <354148C0-DBA4-438C-963B-80350725E453@cs.purdue.edu> Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 24 Sep 2009, at 10:24, Jay K wrote: > @M3noincremental about the same crashing > @M3nogenerational about the same crashing > @M3noincremental @M3nogenerational about the same crashing > > - Jay > > > From: jay.krell at cornell.edu > To: rcoleburn at scires.com; m3devel at elegosoft.com > Subject: RE: [M3devel] more info on juno on windows > Date: Tue, 22 Sep 2009 22:11:26 +0000 > > current: > > nogc "works" -- always the WinContext/PushPixmap assertion failure I think this is indicative of a heap clobber that you are seeing. > > paranoidgc is broken the same as default -- variety of assertion > failures and access violations > Including but NOT limited to: > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\runtime\common\RTCollector.m3", line 1708 > *** > > > which is in RefSanityCheck, doesn't look useful. > > still many access violations at 00200000-4. > I think 00200000 just happens to be some pixmap data from the splash > screen that clobbered some other data but I don't know. > I posted a big hex dump the other week to see if anyone could > confirm it looks like pixmaps. > > - Jay > > > Date: Tue, 22 Sep 2009 17:58:52 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] more info on juno on windows > > Tony: > > I just tried these options. Here are results: > > recent cm3 on XP: paranoidgc yeilds assert in RTCollector.m3 line > 1706, while nogc gets assert in WinContext.m3 line 165. I note that > the juno window begins drawing before the crash on nogc whereas it > does not on paranoidgc. > > recent cm3 on Vista, same results as above except that it appears to > reference an illegal memory location before hitting the assert in > the RTCollector when using paranoidgc. > > old d5.7.0 circa August 2008 on XP: paranoidgc gets a repeating > assert at line 845 in ThreadWin32.m3. You have to hit Ctrl-C to > abort the repeating error message. Not sure if anything else > happens first because it scrolls too far. For nogc, we get same > behavoir as the other tests above. > > Regards, > Randy > > >>> Tony Hosking 9/22/2009 5:46 PM >>> > Have you tried running with @M3nogc? And @M3paranoidgc? > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Sep 2009, at 17:39, Jay K wrote: > > > Again, what I see is that many versions before around Feb 20 2007 > consistently fail with that same assertion failure. > > I have tested many versions now, recently. > > But versions after Feb 20 2007 usually access violate on the address > 0x20000 or so, sometimes other addresses, sometimes various > assertion failures. I believe this is much worse than merely always > failing the same assertion. > > > > - Jay > > > > Date: Tue, 22 Sep 2009 17:06:20 -0400 > From: rcoleburn at scires.com > To: m3devel at elegosoft.com > Subject: [M3devel] more info on juno on windows > > > > > Do we know whether or not Juno ever worked on Windows ? > > I don't recall ever testing it on Windows. I still have a vd5.7.0 > cm3 that I used for the project I finished up last year (August > 2008). If I run Juno on this system (Windows XP SP3), Juno crashes > with an ASSERT failure at line 165 in winvbt/WinContext.m3. The > date on the juno.exe is 8/19/2008. > > Regards, > Randy > > Jay K 9/22/2009 2:57 PM >>> > Here is the truncated part from the previous: > > This change, I think, causes Juno to access violate whereas before > it "only" failed assertions. > I believe it is considered fairly ok for a safe system to terminate > with an assertion failure, > that might not be a bug at all, but considered far worse to hit a > SIGSEGV > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 01:28:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Fri, 25 Sep 2009 23:28:05 +0000 Subject: [M3devel] formsedit Message-ID: I can confirm that formsedit fails on PPC_DARWIN too. The same as on Solaris/sparc32. Juno and Cube work fine. Current source. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Sep 26 02:06:07 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 25 Sep 2009 20:06:07 -0400 Subject: [M3devel] formsedit In-Reply-To: References: Message-ID: OK, thanks. I think we can track this down easily. Perhaps an endianness issue? Both are big-endian whereas Intel are little. I'm not sure what other big-endian platforms M3 has ever run on, so perhaps this is a dark and dusty corner... On 25 Sep 2009, at 19:28, Jay K wrote: > I can confirm that formsedit fails on PPC_DARWIN too. The same as on > Solaris/sparc32. > Juno and Cube work fine. > Current source. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 05:19:54 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 03:19:54 +0000 Subject: [M3devel] formsedit In-Reply-To: References: Message-ID: I forgot to mention: This was on an actual PPC machine. I /assume/ it can be reproed under emulation on x86 but I didn't try. > big endian I could try out my HP-UX/hppa machine again. :) Seriously it was working. I also had Linux/hppa running, but not Modula-3. I have some bids on eBay for some Mac/68K machines. :) I don't think I have seen on this Linux/sparc or Linux/ppc, but I will definitely try those. I don't remember if I tried. They are up and running well, even in Hudson. I can give you ssh access to all/several of these, send me your ssh public key. Could do OPEN/NETFREE/BSD/sparc/ppc too, with a little more time. (FreeBSD/ppc is a pain to install -- no partitioner -- and I haven't succeeded, but Net/Open are easy.) - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 25 Sep 2009 20:06:07 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] formsedit OK, thanks. I think we can track this down easily. Perhaps an endianness issue? Both are big-endian whereas Intel are little. I'm not sure what other big-endian platforms M3 has ever run on, so perhaps this is a dark and dusty corner... On 25 Sep 2009, at 19:28, Jay K wrote: I can confirm that formsedit fails on PPC_DARWIN too. The same as on Solaris/sparc32. Juno and Cube work fine. Current source. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 11:44:46 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 09:44:46 +0000 Subject: [M3devel] birch is out of diskspace Message-ID: birch is out of diskspace I'll free up some, but probably not much. I /might/ download some older archives locally. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.anderson at elego.de Sat Sep 26 11:49:15 2009 From: michael.anderson at elego.de (Michael Anderson) Date: Sat, 26 Sep 2009 11:49:15 +0200 Subject: [M3devel] birch is out of diskspace In-Reply-To: References: Message-ID: <20090926114915.0457c6tx1c0ogssc@mail.elego.de> Quoting Jay K : > > birch is out of diskspace > I'm on it. -Mike > I'll free up some, but probably not much. > I /might/ download some older archives locally. > > - Jay > -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Sat Sep 26 12:04:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 10:04:06 +0000 Subject: [M3devel] birch is out of diskspace In-Reply-To: <20090926114915.0457c6tx1c0ogssc@mail.elego.de> References: Message-ID: Thanks. It looks like I was maybe using ~7gig and I'm down to ~1gig and still cleaning up. - Jay > Date: Sat, 26 Sep 2009 11:49:15 +0200 > From: michael.anderson at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] birch is out of diskspace > > Quoting Jay K : > > > > > birch is out of diskspace > > > > I'm on it. > > -Mike > > > I'll free up some, but probably not much. > > I /might/ download some older archives locally. > > > > - Jay > > > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Sep 26 19:01:48 2009 From: jay.krell at cornell.edu (Jay K) Date: Sat, 26 Sep 2009 17:01:48 +0000 Subject: [M3devel] formsedit In-Reply-To: References: Message-ID: No problem on Linux/sparc or Linux/powerpc. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] formsedit Date: Sat, 26 Sep 2009 03:19:54 +0000 I forgot to mention: This was on an actual PPC machine. I /assume/ it can be reproed under emulation on x86 but I didn't try. > big endian I could try out my HP-UX/hppa machine again. :) Seriously it was working. I also had Linux/hppa running, but not Modula-3. I have some bids on eBay for some Mac/68K machines. :) I don't think I have seen on this Linux/sparc or Linux/ppc, but I will definitely try those. I don't remember if I tried. They are up and running well, even in Hudson. I can give you ssh access to all/several of these, send me your ssh public key. Could do OPEN/NETFREE/BSD/sparc/ppc too, with a little more time. (FreeBSD/ppc is a pain to install -- no partitioner -- and I haven't succeeded, but Net/Open are easy.) - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Fri, 25 Sep 2009 20:06:07 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] formsedit OK, thanks. I think we can track this down easily. Perhaps an endianness issue? Both are big-endian whereas Intel are little. I'm not sure what other big-endian platforms M3 has ever run on, so perhaps this is a dark and dusty corner... On 25 Sep 2009, at 19:28, Jay K wrote: I can confirm that formsedit fails on PPC_DARWIN too. The same as on Solaris/sparc32. Juno and Cube work fine. Current source. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Sep 26 21:11:02 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 26 Sep 2009 21:11:02 +0200 Subject: [M3devel] LONGINT, looks urgent... Message-ID: <1253992263.13608.17.camel@faramir.m3w.org> Spent a piece of day with pdv := osnovica * 17L DIV 100L; varying osnovica from 1, over 1791, 1793... and many more. It looks like LONGINT arithmetic in anything except simplest expressions is broken. When turned to: WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO pdv := step2; END; it works... I have no much time ATM (doing various M3+Gtk+ tasks right now, tight on delivery schedule) to check it more. My version is a bit rusty but not much. If nobody makes more research, I'll - few weeks is most earliest I can expect any free time. -- Dragi?a Duri? From dragisha at m3w.org Sun Sep 27 00:19:54 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 27 Sep 2009 00:19:54 +0200 Subject: [M3devel] Just thinking.... runtime creation of types Message-ID: <1254003594.13608.21.camel@faramir.m3w.org> What steps are needed to create modula-3 type at runtime? Obviously, it can be fully used only from some scripting engine (and I have one, already using type found on start/after plugin load)... But integration with other types will simplify things. Also - new objects can be handled where supertypes can. IMO, very useful. -- Dragi?a Duri? From hosking at cs.purdue.edu Sun Sep 27 02:26:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 26 Sep 2009 20:26:55 -0400 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <1253992263.13608.17.camel@faramir.m3w.org> References: <1253992263.13608.17.camel@faramir.m3w.org> Message-ID: <585FE8AF-3874-41B7-9663-148E923415C7@cs.purdue.edu> What platform? On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > Spent a piece of day with > > pdv := osnovica * 17L DIV 100L; > > varying osnovica from 1, over 1791, 1793... and many more. It looks > like > LONGINT arithmetic in anything except simplest expressions is broken. > When turned to: > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > pdv := step2; > END; > > it works... > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > tight on > delivery schedule) to check it more. My version is a bit rusty but not > much. If nobody makes more research, I'll - few weeks is most > earliest I > can expect any free time. > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Sep 27 07:54:03 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 27 Sep 2009 07:54:03 +0200 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <585FE8AF-3874-41B7-9663-148E923415C7@cs.purdue.edu> References: <1253992263.13608.17.camel@faramir.m3w.org> <585FE8AF-3874-41B7-9663-148E923415C7@cs.purdue.edu> Message-ID: <1254030843.13608.24.camel@faramir.m3w.org> LINUXLIBC6, sorry for missing that. On Sat, 2009-09-26 at 20:26 -0400, Tony Hosking wrote: > What platform? > > On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > > > Spent a piece of day with > > > > pdv := osnovica * 17L DIV 100L; > > > > varying osnovica from 1, over 1791, 1793... and many more. It looks > > like > > LONGINT arithmetic in anything except simplest expressions is > > broken. > > When turned to: > > > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > > pdv := step2; > > END; > > > > it works... > > > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > > tight on > > delivery schedule) to check it more. My version is a bit rusty but > > not > > much. If nobody makes more research, I'll - few weeks is most > > earliest I > > can expect any free time. > > -- > > Dragi?a Duri? > > > -- Dragi?a Duri? From dragisha at m3w.org Sun Sep 27 13:34:23 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 27 Sep 2009 13:34:23 +0200 Subject: [M3devel] Sorry if FAQ, but there's no one...? :) Message-ID: <1254051264.13608.28.camel@faramir.m3w.org> I would like to send a program binary to friend for review, with Modula-3 libraries linked statically so he does not need to install cm3. build_standalone() tries to link staticlaly Gtk+ libs I am using, and they have no .a files and I want them as .so's anyway. LINUXLIBC6 -- Dragi?a Duri? From jay.krell at cornell.edu Sun Sep 27 14:32:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Sep 2009 12:32:24 +0000 Subject: [M3devel] Sorry if FAQ, but there's no one...? :) In-Reply-To: <1254051264.13608.28.camel@faramir.m3w.org> References: <1254051264.13608.28.camel@faramir.m3w.org> Message-ID: build_standalone() should be the answer. Are your Gtk+ libraries in Modula-3 or not? If they are in Modula-3, then that makes sense. As a quick hack, how about delete or move away the .a files that are being used that you don't want used? And, your config file doesn't say -static, right? I've seen that in older ones. Can you add build_standalone() to src/m3makefile rm -rf LINUXLIBC cm3 -commands and look at it and/or show us? This area is a bit wierd and gray imho, but will probably remain exactly asis. (I'm not saying we won't solve your problem. I think the current system already does.) The full flexibility is not exposed.. That is, it isn't likely to let you pick and chose which lib is static and which is dynamic, unless the library itself is build_standalone(), in which case always static. - Jay > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sun, 27 Sep 2009 13:34:23 +0200 > Subject: [M3devel] Sorry if FAQ, but there's no one...? :) > > I would like to send a program binary to friend for review, with > Modula-3 libraries linked statically so he does not need to install cm3. > build_standalone() tries to link staticlaly Gtk+ libs I am using, and > they have no .a files and I want them as .so's anyway. > > LINUXLIBC6 > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Sep 27 14:35:30 2009 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 27 Sep 2009 08:35:30 -0400 Subject: [M3devel] Just thinking.... runtime creation of types In-Reply-To: <1254003594.13608.21.camel@faramir.m3w.org> References: <1254003594.13608.21.camel@faramir.m3w.org> Message-ID: <20090927123529.GB3719@topoi.pooq.com> On Sun, Sep 27, 2009 at 12:19:54AM +0200, Dragi?a Duri? wrote: > What steps are needed to create modula-3 type at runtime? > > Obviously, it can be fully used only from some scripting engine (and I > have one, already using type found on start/after plugin load)... But > integration with other types will simplify things. Also - new objects > can be handled where supertypes can. IMO, very useful. > -- > Dragi?a Duri? > It could also be used for code generated at run-time -- something I've wanted to do for a while now. -- hendrik From hosking at cs.purdue.edu Sun Sep 27 15:19:03 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 09:19:03 -0400 Subject: [M3devel] Sorry if FAQ, but there's no one...? :) In-Reply-To: <1254051264.13608.28.camel@faramir.m3w.org> References: <1254051264.13608.28.camel@faramir.m3w.org> Message-ID: <6493A410-33FF-4611-BD2B-4ED597C2FAFD@cs.purdue.edu> You could define the gtk+ libs as system libs in the config file, prefixed with dynamic linking directives. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Sep 2009, at 07:34, Dragi?a Duri? wrote: > I would like to send a program binary to friend for review, with > Modula-3 libraries linked statically so he does not need to install > cm3. > build_standalone() tries to link staticlaly Gtk+ libs I am using, and > they have no .a files and I want them as .so's anyway. > > LINUXLIBC6 > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sun Sep 27 19:49:03 2009 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 27 Sep 2009 13:49:03 -0400 Subject: [M3devel] cvs error Message-ID: <4ABF6D2D.1E75.00D7.1@scires.com> I am getting the following CVS errors when I update my sandbox: In C:\cm3\Sandbox: "C:\Program Files\CVSNT\cvs.exe" -q update -P -d CVSROOT=:ssh:rcoleburn at birch.elegosoft.com:/usr/cvs cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' Not sure why this is happening. I did not edit any of these files. Any ideas on how to resolve? Regards, Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 27 20:14:37 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Sep 2009 18:14:37 +0000 Subject: [M3devel] cvs error In-Reply-To: <4ABF6D2D.1E75.00D7.1@scires.com> References: <4ABF6D2D.1E75.00D7.1@scires.com> Message-ID: I don't know, but out of ignorance I often do heavy handed stuff to fix my local cvs. like cd m3-sys rm -rf m3cc # rd /q/s m3cc on NT cvs -z3 upd -dAP m3cc if I don't have any changes in m3cc. - Jay Date: Sun, 27 Sep 2009 13:49:03 -0400 From: rcoleburn at scires.com To: m3devel at elegosoft.com Subject: [M3devel] cvs error I am getting the following CVS errors when I update my sandbox: In C:\cm3\Sandbox: "C:\Program Files\CVSNT\cvs.exe" -q update -P -d CVSROOT=:ssh:rcoleburn at birch.elegosoft.com:/usr/cvs cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' Not sure why this is happening. I did not edit any of these files. Any ideas on how to resolve? Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Sep 27 20:19:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Sep 2009 18:19:26 +0000 Subject: [M3devel] m3tests hanging Message-ID: tests seemed hung on I386_DARWIN and I386_OPENBSD. I killed some processes to let them continue. OpenBSD I think we could blame on p007 that Tony fixed already? I copied from head. I haven't had good experience with having CVS do merges -- what changes to tell it? You just have to know? I often manually diff stuff and copy diffs. In this case I just copied the entire file. I wonder if we should apply for a Perforce open source license. It does branching very well, knowing what changes are where. Darwin I don't have an explanation for. So we'll have to just watch it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Sep 27 20:59:29 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 14:59:29 -0400 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <1253992263.13608.17.camel@faramir.m3w.org> References: <1253992263.13608.17.camel@faramir.m3w.org> Message-ID: <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> It works OK for me on I386_DARWIN running with the CVS head. This program produces identical output for both the INTEGER and LONGINT values. Main.m3: MODULE Main; IMPORT MainC; VAR a, i: INTEGER; aa: LONGINT; BEGIN i := 0; FOR ii := 1L TO 1793L DO INC(i); a := i * 17 DIV 100; MainC.PutInt(a); aa := ii * 17L DIV 100L; MainC.PutLong(aa); END; END Main. MainC.i3: INTERFACE MainC; <*EXTERNAL*> PROCEDURE PutLong (x: LONGINT); <*EXTERNAL*> PROCEDURE PutInt (x: INTEGER); END MainC. MainC.C: #include void PutLong (long long x) { printf("%d\n", x); } void PutInt (long x) { printf("%d\n", x); } On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > Spent a piece of day with > > pdv := osnovica * 17L DIV 100L; > > varying osnovica from 1, over 1791, 1793... and many more. It looks > like > LONGINT arithmetic in anything except simplest expressions is broken. > When turned to: > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > pdv := step2; > END; > > it works... > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > tight on > delivery schedule) to check it more. My version is a bit rusty but not > much. If nobody makes more research, I'll - few weeks is most > earliest I > can expect any free time. > -- > Dragi?a Duri? From hosking at cs.purdue.edu Sun Sep 27 21:32:35 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 15:32:35 -0400 Subject: [M3devel] Config file skeletons Message-ID: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> Where did all the config file skeletons go? How do I fix the SOLgnu installation to look for libz.so instead of libz.a. I thought I could simply add a "Z" entry to SYSTEM_LIBS, but I don't know where to do that anymore. That way my tinderbox builds should succeed for the cvsup packages which need libz, but which is not normally installed as a static library. From hosking at cs.purdue.edu Sun Sep 27 21:53:52 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 27 Sep 2009 15:53:52 -0400 Subject: [M3devel] Broken CVS head Message-ID: <60D3CE30-BF24-4972-ADF1-E49183533E6A@cs.purdue.edu> Jay, CVS head is broken right now because of your changes to m3core/ src/float/m3makefile and m3core/src/Csupport/m3makefile. I'm not sure if this is because I have an old config file or what, but it looks like the quake function "FileExists" is not defined anywhere. Just as a courtesy to others, please try to test commits before pushing them to the CVS head. At minimum, one should be able to build the head without errors. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Sep 28 02:19:01 2009 From: jay.krell at cornell.edu (jay.krell at cornell.edu) Date: Sun, 27 Sep 2009 17:19:01 -0700 Subject: [M3devel] Config file skeletons In-Reply-To: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> References: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> Message-ID: <793451C3-475A-446A-8E44-6B4319599704@hotmail.com> Find . | grep SOLgnu$ M3-sys/cminstall/src/config-no-install - Jay (phone) On Sep 27, 2009, at 12:32 PM, Tony Hosking wrote: > Where did all the config file skeletons go? How do I fix the > SOLgnu installation to look for libz.so instead of libz.a. I > thought I could simply add a "Z" entry to SYSTEM_LIBS, but I don't > know where to do that anymore. That way my tinderbox builds should > succeed for the cvsup packages which need libz, but which is not > normally installed as a static library. > > From wagner at elegosoft.com Mon Sep 28 10:32:58 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 10:32:58 +0200 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> References: <1253992263.13608.17.camel@faramir.m3w.org> <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> Message-ID: <20090928103258.tlrry9cuocg88ss8@mail.elegosoft.com> Quoting Tony Hosking : > It works OK for me on I386_DARWIN running with the CVS head. This > program produces identical output for both the INTEGER and LONGINT > values. > > Main.m3: > > MODULE Main; > IMPORT MainC; > > VAR > a, i: INTEGER; > aa: LONGINT; > BEGIN > i := 0; > FOR ii := 1L TO 1793L DO > INC(i); > a := i * 17 DIV 100; > MainC.PutInt(a); > aa := ii * 17L DIV 100L; > MainC.PutLong(aa); > END; > END Main. > > MainC.i3: > > INTERFACE MainC; > > <*EXTERNAL*> PROCEDURE PutLong (x: LONGINT); > <*EXTERNAL*> PROCEDURE PutInt (x: INTEGER); > > END MainC. > > MainC.C: > > #include > > void PutLong (long long x) { > printf("%d\n", x); > } > > void PutInt (long x) { > printf("%d\n", x); > } > > > On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > >> Spent a piece of day with >> >> pdv := osnovica * 17L DIV 100L; >> >> varying osnovica from 1, over 1791, 1793... and many more. It looks like >> LONGINT arithmetic in anything except simplest expressions is broken. >> When turned to: >> >> WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO >> pdv := step2; >> END; >> >> it works... >> >> I have no much time ATM (doing various M3+Gtk+ tasks right now, tight on >> delivery schedule) to check it more. My version is a bit rusty but not >> much. If nobody makes more research, I'll - few weeks is most earliest I >> can expect any free time. I know that everybody else is busy, too, but we should o open a ticket for this issue in trac o add the test program to m3-sys/m3tests so that it is run on all regression test platforms automatically Any volunteers? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Sep 28 11:13:27 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 11:13:27 +0200 Subject: [M3devel] cvs error In-Reply-To: <4ABF6D2D.1E75.00D7.1@scires.com> References: <4ABF6D2D.1E75.00D7.1@scires.com> Message-ID: <20090928111327.ivuoyshlsgsc4sg4@mail.elegosoft.com> Quoting Randy Coleburn : > I am getting the following CVS errors when I update my sandbox: > > In C:\cm3\Sandbox: "C:\Program Files\CVSNT\cvs.exe" -q update -P -d > CVSROOT=:ssh:rcoleburn at birch.elegosoft.com:/usr/cvs > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for > `m3-sys/m3cc/gcc/fixincludes' > Not sure why this is happening. I did not edit any of these files. > > Any ideas on how to resolve? This is no error. CVS just thinks that the mentioned files should be under version control but aren't. Indeed they are probably generated by some make target, so I think it should be OK. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Sep 28 11:18:21 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 11:18:21 +0200 Subject: [M3devel] m3tests hanging In-Reply-To: References: Message-ID: <20090928111821.ii777ufy5cook4ko@mail.elegosoft.com> Quoting Jay K : > > tests seemed hung on I386_DARWIN and I386_OPENBSD. > I killed some processes to let them continue. > > OpenBSD I think we could blame on p007 that Tony fixed already? I > copied from head. > I haven't had good experience with having CVS do merges -- what > changes to tell it? You just have to know? I often manually diff > stuff and copy diffs. I posted a description on cvs merges some days ago, or didn't it show up on the list? > In this case I just copied the entire file. I wonder if we should > apply for a Perforce > open source license. It does branching very well, knowing what > changes are where. Not now. If everybody agrees (which I don't think, as others will prefer subversion or git or mercurial or ...) _and_ we do much branching, Perforce might be a good idea. But until now branching was only used for infrequent release branches, which CVS should be able to handle, too. > Darwin I don't have an explanation for. > So we'll have to just watch it. So p007 should now terminate on any platform with Tony's fixes? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Sep 28 11:31:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 28 Sep 2009 09:31:02 +0000 Subject: [M3devel] m3tests hanging In-Reply-To: <20090928111821.ii777ufy5cook4ko@mail.elegosoft.com> References: Message-ID: > I posted a description on cvs merges some days ago, or didn't it show > up on the list? It seems to require me to know every change in the system and what branch it is in. I do that to some extent, and when I can't, I diff my two trees. With perforce you just tell it the two branches and it knows which changes are in which branch, basically. At least it seems to keep a high water mark. > > In this case I just copied the entire file. I wonder if we should > > apply for a Perforce > > open source license. It does branching very well, knowing what > > changes are where. > > Not now. If everybody agrees (which I don't think, as others will > prefer subversion or git or mercurial or ...) _and_ we do much branching, I've done some research here sort of, at least read stuff, guaged popular opinion. I have a lot of experience with Perforce and highly recommend it. But it isn't free beer for any project and source isn't available. It isn't just merging/branching that it does well. It does basically everything well, except it isn't distributed. It has a good command line interface, a good gui, pretty good platform support. I'm not sure of its perf over slow network. Otherwise git and mercurial seem to the most popular, but git is seen as perhaps too hard to use. I might shortly have to use/learn mercurial for a small project (said project considered git as well, but chose mercurial). Subversion is better than CVS and has atomic multi-file changesets. Historically its branching support is terrible, again you have to know which changes are in which branch. They might have fixed that by now. Monotone sounds good, but git and mercurial seem more popular. Conversion from cvs seems supported well enough. Some of the systems support on-going bidirectional conversion, including accepting CVS commits. Some support read only CVS mirrors. > So p007 should now terminate on any platform with Tony's fixes? That is my hope/expectation. I haven't tested it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Sep 28 12:24:44 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 28 Sep 2009 12:24:44 +0200 Subject: [M3devel] Config file skeletons In-Reply-To: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> References: <4E044CF5-F788-4393-84E1-16846136171B@cs.purdue.edu> Message-ID: <20090928122444.73xexhn69wcs8k0w@mail.elegosoft.com> Quoting Tony Hosking : > Where did all the config file skeletons go? How do I fix the SOLgnu > installation to look for libz.so instead of libz.a. I thought I could > simply add a "Z" entry to SYSTEM_LIBS, but I don't know where to do > that anymore. That way my tinderbox builds should succeed for the > cvsup packages which need libz, but which is not normally installed as > a static library. Wasn't the problem that libz is not yet contained in SYSTEM_LIBS, but looked up with some local quake magic? At least there's a ticket in trac related to this failure: https://projects.elego.de/cm3/ticket/1048 I don't know why it isn't fixed yet, doesn't look too difficult. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Sep 28 12:55:19 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 28 Sep 2009 10:55:19 +0000 Subject: [M3devel] Juno on Windows, some inconclusive investigation.. Message-ID: 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: From dragisha at m3w.org Mon Sep 28 13:17:34 2009 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 28 Sep 2009 13:17:34 +0200 Subject: [M3devel] LONGINT, looks urgent... In-Reply-To: <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> References: <1253992263.13608.17.camel@faramir.m3w.org> <38C3B420-867D-4691-A69E-B09655075A73@cs.purdue.edu> Message-ID: <1254136654.13608.558.camel@faramir.m3w.org> Mea culpa... Test code alone works well on LINUXLIBC6, it's obviously something higher up. I've used Fmt.LongInt, but addedd to this code, it also works well. I'll check it more, for now - sorry for false alarm. On Sun, 2009-09-27 at 14:59 -0400, Tony Hosking wrote: > It works OK for me on I386_DARWIN running with the CVS head. This > program produces identical output for both the INTEGER and LONGINT > values. > > Main.m3: > > MODULE Main; > IMPORT MainC; > > VAR > a, i: INTEGER; > aa: LONGINT; > BEGIN > i := 0; > FOR ii := 1L TO 1793L DO > INC(i); > a := i * 17 DIV 100; > MainC.PutInt(a); > aa := ii * 17L DIV 100L; > MainC.PutLong(aa); > END; > END Main. > > MainC.i3: > > INTERFACE MainC; > > <*EXTERNAL*> PROCEDURE PutLong (x: LONGINT); > <*EXTERNAL*> PROCEDURE PutInt (x: INTEGER); > > END MainC. > > MainC.C: > > #include > > void PutLong (long long x) { > printf("%d\n", x); > } > > void PutInt (long x) { > printf("%d\n", x); > } > > > On 26 Sep 2009, at 15:11, Dragi?a Duri? wrote: > > > Spent a piece of day with > > > > pdv := osnovica * 17L DIV 100L; > > > > varying osnovica from 1, over 1791, 1793... and many more. It looks > > like > > LONGINT arithmetic in anything except simplest expressions is broken. > > When turned to: > > > > WITH step1 = osnovica * 17L, step2 = step1 DIV 100L DO > > pdv := step2; > > END; > > > > it works... > > > > I have no much time ATM (doing various M3+Gtk+ tasks right now, > > tight on > > delivery schedule) to check it more. My version is a bit rusty but not > > much. If nobody makes more research, I'll - few weeks is most > > earliest I > > can expect any free time. > > -- > > Dragi?a Duri? > -- Dragi?a Duri? From jay.krell at cornell.edu Mon Sep 28 15:11:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Mon, 28 Sep 2009 13:11:28 +0000 Subject: [M3devel] help debugging Juno..sanity check? Message-ID: So, I know that ThreadWin32.T instances are prone to being overwritten. So I did this: T = BRANDED "Thread.T Win32-1.0" OBJECT > pad1: ARRAY [0..16_1000] OF CHAR; > protect: ARRAY [0..16_1] OF CHAR; > pad2: ARRAY [0..16_1000] OF CHAR; And then there are two occurences of NEW(T): next_self := NEW(T); > Protect(next_self); PROCEDURE CreateT (act: Activation): T = (* LL = 0, because allocating a traced reference may cause the allocator to start a collection which will call "SuspendOthers" which will try to acquire "activeMu". *) VAR t := NEW(T, act := act); BEGIN > Protect(t); PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); END Protect; This should catch any writes to these fields. Now, a thread can be garbage collected and reused. And I'd want to unprotect this memory. Or prevent the garbage collector from deciding any thread is garbage. Second option seems easier and suffices. So: VAR threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) threadCount: INTEGER; and more completely: PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); RTIO.PutInt(threadCount); RTIO.PutText(" "); RTIO.PutAddr(ADR(threads)); RTIO.PutText(" "); RTIO.PutAddr(ADR(t.protect)); RTIO.PutText("\n"); threads[threadCount] := t; INC(threadCount); END Protect; And just in case, I emptied out the FreeSlot function. But yet I get: 0 0xe2abe0 0x1141021 1 0xe2abe0 0x114b429 2 0xe2abe0 0x11a2311 3 0xe2abe0 0x11a48b1 4 0xe2abe0 0x11ab499 5 0xe2abe0 0x12e9f11 6 0xe2abe0 0x12d211d 7 0xe2abe0 0x11bd691 8 0xe2abe0 0x11d1011 9 0xe2abe0 0x11d3e2d 10 0xe2abe0 0x11d6759 11 0xe2abe0 0x11d8bd1 12 0xe2abe0 0x12089f1 13 0xe2abe0 0x1211455 14 0xe2abe0 0x12138cd 15 0xe2abe0 0x1215ecd 16 0xe2abe0 0x12184cd 17 0xe2abe0 0x121bcd5 18 0xe2abe0 0x121e35d Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: 23% (b60.9d4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 edi=011bd000 eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 MSVCR90!fastzero_I+0x20: 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds:0023:011bd000=0000000 0000000000000000000000000 0:003> k ChildEBP RetAddr 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db 0:003> r edi edi=011bd000 0:003> What am I confused about? Why does it seem that even if I store some pointers in globals, they are getting garbage collected and reused? I should debug BuildGlobalMap?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Sep 28 16:04:55 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 28 Sep 2009 10:04:55 -0400 Subject: [M3devel] help debugging Juno..sanity check? In-Reply-To: References: Message-ID: <4297E27D-B5E9-48D2-BA1D-1CAE6332899D@cs.purdue.edu> Huh? I don't understand the point of all of this. Threads can be moved by the GC, even if referenced from globals. The only way to prevent a thread moving is to keep a reference to it on some thread stack. (I still don't know what you are trying to achieve -- why not use a hardware breakpoint in the debugger?). That's how I found the race in ScrollerVBTClass.m3. On 28 Sep 2009, at 09:11, Jay K wrote: > So, I know that ThreadWin32.T instances are prone to being > overwritten. > > So I did this: > > > T = BRANDED "Thread.T Win32-1.0" OBJECT > > pad1: ARRAY [0..16_1000] OF CHAR; > > protect: ARRAY [0..16_1] OF CHAR; > > pad2: ARRAY [0..16_1000] OF CHAR; > > And then there are two occurences of NEW(T): > > > next_self := NEW(T); > > Protect(next_self); > > > PROCEDURE CreateT (act: Activation): T = > (* LL = 0, because allocating a traced reference may cause > the allocator to start a collection which will call > "SuspendOthers" > which will try to acquire "activeMu". *) > VAR t := NEW(T, act := act); > BEGIN > > Protect(t); > > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > END Protect; > > > This should catch any writes to these fields. > > > Now, a thread can be garbage collected and reused. > And I'd want to unprotect this memory. > Or prevent the garbage collector from deciding any thread is garbage. > Second option seems easier and suffices. > > > So: > > > VAR > threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) > threadCount: INTEGER; > > > and more completely: > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > RTIO.PutInt(threadCount); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(threads)); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(t.protect)); > RTIO.PutText("\n"); > threads[threadCount] := t; > INC(threadCount); > END Protect; > > > And just in case, I emptied out the FreeSlot function. > > > But yet I get: > > 0 0xe2abe0 0x1141021 > 1 0xe2abe0 0x114b429 > 2 0xe2abe0 0x11a2311 > 3 0xe2abe0 0x11a48b1 > 4 0xe2abe0 0x11ab499 > 5 0xe2abe0 0x12e9f11 > 6 0xe2abe0 0x12d211d > 7 0xe2abe0 0x11bd691 > 8 0xe2abe0 0x11d1011 > 9 0xe2abe0 0x11d3e2d > 10 0xe2abe0 0x11d6759 > 11 0xe2abe0 0x11d8bd1 > 12 0xe2abe0 0x12089f1 > 13 0xe2abe0 0x1211455 > 14 0xe2abe0 0x12138cd > 15 0xe2abe0 0x1215ecd > 16 0xe2abe0 0x12184cd > 17 0xe2abe0 0x121bcd5 > 18 0xe2abe0 0x121e35d > Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: > 23% > (b60.9d4): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 > edi=011bd000 > eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > MSVCR90!fastzero_I+0x20: > 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds: > 0023:011bd000=0000000 > 0000000000000000000000000 > 0:003> k > ChildEBP RetAddr > 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 > 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 > 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f > 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 > 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec > 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c > 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 > 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e > 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e > 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b > 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 > 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f > 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 > 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 > 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 > 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 > 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf > 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db > 0:003> r edi > edi=011bd000 > 0:003> > > > What am I confused about? > > Why does it seem that even if I store some pointers in globals, they > are getting garbage collected and reused? > > I should debug BuildGlobalMap?? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 07:39:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 05:39:24 +0000 Subject: [M3devel] help debugging Juno..sanity check? In-Reply-To: <4297E27D-B5E9-48D2-BA1D-1CAE6332899D@cs.purdue.edu> References: Message-ID: oops, thanks, I forgot gc is compacting. I don't see how to use a hardware breakpoint, the corruption seems to always move around. This is an attempt to set a hardware breakpoint programmatically based on what the runtime addresses happen to be. I do know these bytes are getting overwritten. If I assert they are zero in Join, inevitably the assert fails. I think I might try to vary the Juno pixmaps, see if the altered data appears in the corruption, try to prove, as it appears, that the corruption is pixmap data. Thanks, - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Mon, 28 Sep 2009 10:04:55 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] help debugging Juno..sanity check? Huh? I don't understand the point of all of this. Threads can be moved by the GC, even if referenced from globals. The only way to prevent a thread moving is to keep a reference to it on some thread stack. (I still don't know what you are trying to achieve -- why not use a hardware breakpoint in the debugger?). That's how I found the race in ScrollerVBTClass.m3. On 28 Sep 2009, at 09:11, Jay K wrote: So, I know that ThreadWin32.T instances are prone to being overwritten. So I did this: T = BRANDED "Thread.T Win32-1.0" OBJECT > pad1: ARRAY [0..16_1000] OF CHAR; > protect: ARRAY [0..16_1] OF CHAR; > pad2: ARRAY [0..16_1000] OF CHAR; And then there are two occurences of NEW(T): next_self := NEW(T); > Protect(next_self); PROCEDURE CreateT (act: Activation): T = (* LL = 0, because allocating a traced reference may cause the allocator to start a collection which will call "SuspendOthers" which will try to acquire "activeMu". *) VAR t := NEW(T, act := act); BEGIN > Protect(t); PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); END Protect; This should catch any writes to these fields. Now, a thread can be garbage collected and reused. And I'd want to unprotect this memory. Or prevent the garbage collector from deciding any thread is garbage. Second option seems easier and suffices. So: VAR threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) threadCount: INTEGER; and more completely: PROCEDURE Protect(t: T)= VAR old: WinDef.DWORD; BEGIN EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, PAGE_READONLY, ADR(old)); RTIO.PutInt(threadCount); RTIO.PutText(" "); RTIO.PutAddr(ADR(threads)); RTIO.PutText(" "); RTIO.PutAddr(ADR(t.protect)); RTIO.PutText("\n"); threads[threadCount] := t; INC(threadCount); END Protect; And just in case, I emptied out the FreeSlot function. But yet I get: 0 0xe2abe0 0x1141021 1 0xe2abe0 0x114b429 2 0xe2abe0 0x11a2311 3 0xe2abe0 0x11a48b1 4 0xe2abe0 0x11ab499 5 0xe2abe0 0x12e9f11 6 0xe2abe0 0x12d211d 7 0xe2abe0 0x11bd691 8 0xe2abe0 0x11d1011 9 0xe2abe0 0x11d3e2d 10 0xe2abe0 0x11d6759 11 0xe2abe0 0x11d8bd1 12 0xe2abe0 0x12089f1 13 0xe2abe0 0x1211455 14 0xe2abe0 0x12138cd 15 0xe2abe0 0x1215ecd 16 0xe2abe0 0x12184cd 17 0xe2abe0 0x121bcd5 18 0xe2abe0 0x121e35d Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: 23% (b60.9d4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 edi=011bd000 eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 MSVCR90!fastzero_I+0x20: 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds:0023:011bd000=0000000 0000000000000000000000000 0:003> k ChildEBP RetAddr 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db 0:003> r edi edi=011bd000 0:003> What am I confused about? Why does it seem that even if I store some pointers in globals, they are getting garbage collected and reused? I should debug BuildGlobalMap?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 09:47:15 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 07:47:15 +0000 Subject: [M3devel] why Thread.Wait immediately after Thread.Fork? Message-ID: What is the point of Thread.Wait(Thread.Fork(NEW(ClosureType....)); vs. just: NEW(ClosureType....).apply(); ? The only reason I can think of is to ensure more stack the ClosureType().apply() than might be present on the current thread. OR maybe an assertion on the author's part that the work could/should be performed without waiting, but he hasn't made it so yet? OR maybe so user can interrupt long running operation with control-c? But that works the same on the original thread, right? OR maybe to stress test the threading library and ensure that thread creation is cheap?? These do seem like wasted threads. I have found a few examples. Here is one: m3-ui\formsvbt\src\FormsVBT.m3 PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T RAISES {Error} = BEGIN TYPECASE Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000, description := description, fv := t, state := state))) OF | TEXT (msg) => RAISE Error (msg) | VBT.T (ch) => RETURN ch ELSE <* ASSERT FALSE *> END END Parse; why not: PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T RAISES {Error} = BEGIN TYPECASE NEW (ParseClosure, stackSize := 10000, description := description, fv := t, state := state).apply() OF | TEXT (msg) => RAISE Error (msg) | VBT.T (ch) => RETURN ch ELSE <* ASSERT FALSE *> END END Parse; If the point is to ensure enough stack, perhaps a mechanism to report how much stack is left would be reasonable?? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 29 10:08:56 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Sep 2009 10:08:56 +0200 Subject: [M3devel] why Thread.Wait immediately after Thread.Fork? In-Reply-To: References: Message-ID: <20090929100856.j46qpa66m8k4c84w@mail.elegosoft.com> My guess would be it is the stacksize. The parser will probably be a simple LL implementation, and the default size for thread stacks was (is?) notorious small in M3. What are the current defaults? Olaf Quoting Jay K : > What is the point of > > Thread.Wait(Thread.Fork(NEW(ClosureType....)); > > vs. just: > > NEW(ClosureType....).apply(); > > ? > > The only reason I can think of is to ensure more stack the > ClosureType().apply() than might be present on the current thread. > > OR maybe an assertion on the author's part that the work > could/should be performed without waiting, but he hasn't made it so > yet? > > > OR maybe so user can interrupt long running operation with > control-c? But that works the same on the original thread, right? > > > > OR maybe to stress test the threading library and ensure that thread > creation is cheap?? > > These do seem like wasted threads. > > > > I have found a few examples. Here is one: > > > > > m3-ui\formsvbt\src\FormsVBT.m3 > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > RAISES {Error} = > BEGIN > TYPECASE > Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000, > description := description, fv := t, > state := state))) OF > | TEXT (msg) => RAISE Error (msg) > | VBT.T (ch) => RETURN ch > ELSE <* ASSERT FALSE *> > END > END Parse; > > > > > why not: > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > RAISES {Error} = > BEGIN > TYPECASE > NEW (ParseClosure, stackSize := 10000, > description := description, fv := t, > state := state).apply() OF > | TEXT (msg) => RAISE Error (msg) > | VBT.T (ch) => RETURN ch > ELSE <* ASSERT FALSE *> > END > END Parse; > > > > > > If the point is to ensure enough stack, perhaps a mechanism to > report how much stack is left would be reasonable?? > > > > > - Jay > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Sep 29 10:13:51 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 08:13:51 +0000 Subject: [M3devel] Juno/Win32 possibly somewhat understood Message-ID: So..in order to simplify debugging, I started removing and simplifying code, as long as the failures were similar. Sometimes I'd get an array overflow as a result -- like if I removed code that initialized stuff. I focused on: removing maybe unnecessary threads -- like the FileBrowserVBT.Watcher, the font cleanupt thread I changed uses of Wait(Fork(NEW(T)) to just NEW(T).apply() I did also remove a bunch of Trestle redraw code that was often on the stack. Eventually, while almost nothing got drawn, Juno seemed to crash less often and more consistently. So I undid/redid stuff. It seems the main thing I had altered was using fewer threads. So, a quick look at ThreadWin32.m3. It maintains some idle threads. If I remove that, Juno seems to stop crashing. I'm going to double check stuff. Like undo all my other changes. Maybe even try setting the idle thread count to 0 instead of removing the code. See if my findings repeat themselves. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 10:18:05 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 08:18:05 +0000 Subject: [M3devel] why Thread.Wait immediately after Thread.Fork? In-Reply-To: <20090929100856.j46qpa66m8k4c84w@mail.elegosoft.com> References: Message-ID: The defaults are still small. C:\dev2\cm3.2\m3-libs\m3core\src\thread\POSIX\ThreadPosix.m3(196): defaultStackSize := 3000; C:\dev2\cm3.2\m3-libs\m3core\src\thread\PTHREAD\ThreadPThread.m3(819):VAR defaultStackSize := 4096; I did some experimentation, and I was HOPING to find something like: Among all supported platforms, the smallest actual creatable stack is 64K, therefore set our minimum to 64K. Or even 16K. However I didn't find that to be true. I think I found I could create stacks as small as 4K, maybe even less. On the other hand, I'm sure a number of platforms cannot create such small stacks. Also I believe the Linux default stack is a whopping 8MB, so you sometimes find code that fails with smaller than that. NT defaults tend to either be 1MB or 256K, maybe doubled for 64bit. - Jay > Date: Tue, 29 Sep 2009 10:08:56 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] why Thread.Wait immediately after Thread.Fork? > > My guess would be it is the stacksize. The parser will probably > be a simple LL implementation, and the default size for thread > stacks was (is?) notorious small in M3. > > What are the current defaults? > > Olaf > > Quoting Jay K : > > > What is the point of > > > > Thread.Wait(Thread.Fork(NEW(ClosureType....)); > > > > vs. just: > > > > NEW(ClosureType....).apply(); > > > > ? > > > > The only reason I can think of is to ensure more stack the > > ClosureType().apply() than might be present on the current thread. > > > > OR maybe an assertion on the author's part that the work > > could/should be performed without waiting, but he hasn't made it so > > yet? > > > > > > OR maybe so user can interrupt long running operation with > > control-c? But that works the same on the original thread, right? > > > > > > > > OR maybe to stress test the threading library and ensure that thread > > creation is cheap?? > > > > These do seem like wasted threads. > > > > > > > > I have found a few examples. Here is one: > > > > > > > > > > m3-ui\formsvbt\src\FormsVBT.m3 > > > > > > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > > RAISES {Error} = > > BEGIN > > TYPECASE > > Thread.Join (Thread.Fork (NEW (ParseClosure, stackSize := 10000, > > description := description, fv := t, > > state := state))) OF > > | TEXT (msg) => RAISE Error (msg) > > | VBT.T (ch) => RETURN ch > > ELSE <* ASSERT FALSE *> > > END > > END Parse; > > > > > > > > > > why not: > > > > > > > > > > PROCEDURE Parse (t: T; description: Sx.T; READONLY state: State): VBT.T > > RAISES {Error} = > > BEGIN > > TYPECASE > > NEW (ParseClosure, stackSize := 10000, > > description := description, fv := t, > > state := state).apply() OF > > | TEXT (msg) => RAISE Error (msg) > > | VBT.T (ch) => RETURN ch > > ELSE <* ASSERT FALSE *> > > END > > END Parse; > > > > > > > > > > > > If the point is to ensure enough stack, perhaps a mechanism to > > report how much stack is left would be reasonable?? > > > > > > > > > > - Jay > > > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 11:18:57 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 09:18:57 +0000 Subject: [M3devel] ThreadF.MyID? Message-ID: The algorithms for thread id assignment vary on the platforms. In posix user threads and Win32 threads, it appears to be a number that increments for every new thread. Not sure what happens after 2 or 4 billion. On pthreads, it appears to be, well, we maintain an array of threads. So it is a number between 0 and n where n is the maximum number of threads that have "ever" been running at the same time. With presumably aggressive reuse of ids. Ok? They should all use the same? It's just that I'm looking at the Win32 code, comparing it to the pthread code: Win32: LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); Pthread doesn't have this code. I don't believe self.closure needs a lock. And per above, pthreads doesn't need protection here for id, since it is handled elsewhere. I know this was just discussed in a sense -- MyId is for debugging/diagnostics only and its value can't be depended on for much. The are obvious advantages/disadvantages to the two schemes. Win32/Posix recycle "never", so debugging probably easier. Pthread doesn't waste time/space on the id. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 11:24:49 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 09:24:49 +0000 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: Probably on Win32 should just use GetCurrentThreadId(). And pthread could just use pthread_self(). - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 09:18:57 +0000 Subject: [M3devel] ThreadF.MyID? The algorithms for thread id assignment vary on the platforms. In posix user threads and Win32 threads, it appears to be a number that increments for every new thread. Not sure what happens after 2 or 4 billion. On pthreads, it appears to be, well, we maintain an array of threads. So it is a number between 0 and n where n is the maximum number of threads that have "ever" been running at the same time. With presumably aggressive reuse of ids. Ok? They should all use the same? It's just that I'm looking at the Win32 code, comparing it to the pthread code: Win32: LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); Pthread doesn't have this code. I don't believe self.closure needs a lock. And per above, pthreads doesn't need protection here for id, since it is handled elsewhere. I know this was just discussed in a sense -- MyId is for debugging/diagnostics only and its value can't be depended on for much. The are obvious advantages/disadvantages to the two schemes. Win32/Posix recycle "never", so debugging probably easier. Pthread doesn't waste time/space on the id. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 13:19:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 11:19:06 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. Message-ID: Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. At least. The Enter/Leave mechanical replacement error. However even with that, the idle thread stuff seemed to cause problems. It was there forever, I realize. Also, I should have done this first, but anyway, later, I tried merging back in your changes from Feb 16. Somewhat they are moot (lock vs. LockMutex). Somewhat they are already there (WaitHeap, heapCond => condition). Somewhat they are trivial (fixing error messages). That leaves, in my analysis, the BroadcastHeap change. With this change however, /sometimes/ Juno hangs. Is this, like, somehow equivalent to the Posix hang? Is the current code the "best"? Oh darn..it hangs either way. Just not often. Could that be "similar" to the pthread problem? Any chance you can look at it? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 15:49:19 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 09:49:19 -0400 Subject: [M3devel] help debugging Juno..sanity check? In-Reply-To: References: Message-ID: OK, remind me again what happens with @M3nogc. That will prevent movement, and should allow you to protect state as you originally intended, without worrying about it being GC'd or moved.. From what you are saying though, it appears that even with @M3nogc the corruption is not deterministic. Which does make it tricky to nail down where it occurs. On 29 Sep 2009, at 01:39, Jay K wrote: > oops, thanks, I forgot gc is compacting. > > I don't see how to use a hardware breakpoint, > the corruption seems to always move around. > > This is an attempt to set a hardware breakpoint programmatically based > on what the runtime addresses happen to be. > > I do know these bytes are getting overwritten. > If I assert they are zero in Join, inevitably the assert fails. > > I think I might try to vary the Juno pixmaps, see if the altered > data appears in the corruption, try to prove, as it appears, > that the corruption is pixmap data. > > Thanks, > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 28 Sep 2009 10:04:55 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] help debugging Juno..sanity check? > > Huh? I don't understand the point of all of this. Threads can be > moved by the GC, even if referenced from globals. The only way to > prevent a thread moving is to keep a reference to it on some thread > stack. (I still don't know what you are trying to achieve -- why > not use a hardware breakpoint in the debugger?). That's how I found > the race in ScrollerVBTClass.m3. > > On 28 Sep 2009, at 09:11, Jay K wrote: > > So, I know that ThreadWin32.T instances are prone to being > overwritten. > > So I did this: > > > T = BRANDED "Thread.T Win32-1.0" OBJECT > > pad1: ARRAY [0..16_1000] OF CHAR; > > protect: ARRAY [0..16_1] OF CHAR; > > pad2: ARRAY [0..16_1000] OF CHAR; > > And then there are two occurences of NEW(T): > > > next_self := NEW(T); > > Protect(next_self); > > > PROCEDURE CreateT (act: Activation): T = > (* LL = 0, because allocating a traced reference may cause > the allocator to start a collection which will call > "SuspendOthers" > which will try to acquire "activeMu". *) > VAR t := NEW(T, act := act); > BEGIN > > Protect(t); > > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > END Protect; > > > This should catch any writes to these fields. > > > Now, a thread can be garbage collected and reused. > And I'd want to unprotect this memory. > Or prevent the garbage collector from deciding any thread is garbage. > Second option seems easier and suffices. > > > So: > > > VAR > threads: ARRAY[0..2000] OF T; (* big enough for our purposes *) > threadCount: INTEGER; > > > and more completely: > > PROCEDURE Protect(t: T)= > VAR old: WinDef.DWORD; > BEGIN > EVAL WinBase.VirtualProtect(LOOPHOLE(ADR(t.protect), SIZE_T), 1, > PAGE_READONLY, ADR(old)); > RTIO.PutInt(threadCount); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(threads)); > RTIO.PutText(" "); > RTIO.PutAddr(ADR(t.protect)); > RTIO.PutText("\n"); > threads[threadCount] := t; > INC(threadCount); > END Protect; > > > And just in case, I emptied out the FreeSlot function. > > > But yet I get: > > 0 0xe2abe0 0x1141021 > 1 0xe2abe0 0x114b429 > 2 0xe2abe0 0x11a2311 > 3 0xe2abe0 0x11a48b1 > 4 0xe2abe0 0x11ab499 > 5 0xe2abe0 0x12e9f11 > 6 0xe2abe0 0x12d211d > 7 0xe2abe0 0x11bd691 > 8 0xe2abe0 0x11d1011 > 9 0xe2abe0 0x11d3e2d > 10 0xe2abe0 0x11d6759 > 11 0xe2abe0 0x11d8bd1 > 12 0xe2abe0 0x12089f1 > 13 0xe2abe0 0x1211455 > 14 0xe2abe0 0x12138cd > 15 0xe2abe0 0x1215ecd > 16 0xe2abe0 0x12184cd > 17 0xe2abe0 0x121bcd5 > 18 0xe2abe0 0x121e35d > Grow (0x210000) => 0x2120000 total: 4.1M span: 17.9M density: > 23% > (b60.9d4): Access violation - code c0000005 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=011b0000 ebx=00010000 ecx=00000060 edx=00000000 esi=011b0000 > edi=011bd000 > eip=78545e37 esp=01cae5ec ebp=01cae5f0 iopl=0 nv up ei pl nz > na pe nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010206 > MSVCR90!fastzero_I+0x20: > 78545e37 660f7f07 movdqa xmmword ptr [edi],xmm0 ds: > 0023:011bd000=0000000 > 0000000000000000000000000 > 0:003> k > ChildEBP RetAddr > 01cae5f0 78545ea9 MSVCR90!fastzero_I+0x20 > 01cae610 005dad48 MSVCR90!_VEC_memzero+0x36 > 01cae634 005d1f34 m3core!RTMisc__Zero+0x1f > 01cae68c 005c8191 m3core!RTHeapRep__LongAlloc+0xf3 > 01cae6d8 005c7793 m3core!RTAllocator__AllocTraced+0xec > 01cae70c 005c728d m3core!RTAllocator__GetTracedObj+0x8c > 01cae730 005d07d9 m3core!RTHooks__AllocateTracedObj+0x15 > 01cae784 005d033f m3core!RTCollector__CollectSomeInStateZero+0x45e > 01cae798 005cffd6 m3core!RTCollector__CollectSome+0x6e > 01cae7dc 005c817c m3core!RTHeapRep__CollectEnough+0x9b > 01cae81c 005c7d06 m3core!RTAllocator__AllocTraced+0xd7 > 01cae858 005c7348 m3core!RTAllocator__GetOpenArray+0x97 > 01cae880 00f9f50d m3core!RTHooks__AllocateOpenArray+0x19 > 01cae930 00f9f201 m3ui!WinScrnPixmap__PixmapFromRaw__ConvertColor+0x8f > 01cae958 00f9e22f m3ui!WinScrnPixmap__PixmapFromRaw+0x71 > 01cae9ac 00eb4121 m3ui!WinScrnPixmap__Load+0x320 > 01caeee4 00eb298d m3vbtkit!Image__ScaleRaw+0xb30 > 01caef44 00fb2b72 m3vbtkit!Image__ApplyScaled1+0x166 > 01caef70 00fc0af8 m3ui!VBTRep__PixmapApply+0xbf > 01caefcc 00fa6766 m3ui!Palette__ResolvePixmap+0x7db > 0:003> r edi > edi=011bd000 > 0:003> > > > What am I confused about? > > Why does it seem that even if I store some pointers in globals, they > are getting garbage collected and reused? > > I should debug BuildGlobalMap?? > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 15:58:45 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 09:58:45 -0400 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: <317FC510-CCDE-414D-AEC2-1D9FBEE67B6D@cs.purdue.edu> MyId is not a standard interface so it can do what it likes. Also, I was trying to match thread Ids to those of the OS (as reported by gdb) which recycles them. No guarantees though. I don't think they should necessarily all be the same from one thread implementation to another. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 29 Sep 2009, at 05:18, Jay K wrote: > The algorithms for thread id assignment vary on the platforms. > > In posix user threads and Win32 threads, it appears to be a number > that increments for every new thread. > Not sure what happens after 2 or 4 billion. > > On pthreads, it appears to be, well, we maintain an array of threads. > So it is a number between 0 and n where n is the maximum number of > threads that have > "ever" been running at the same time. With presumably aggressive > reuse of ids. > > Ok? > > They should all use the same? > > It's just that I'm looking at the Win32 code, comparing it to the > pthread code: > > Win32: > LockMutex(threadMu); > cl := self.closure; > self.id := nextId; INC (nextId); > UnlockMutex(threadMu); > > Pthread doesn't have this code. > I don't believe self.closure needs a lock. > And per above, pthreads doesn't need protection here for id, since > it is handled elsewhere. > > I know this was just discussed in a sense -- MyId is for debugging/ > diagnostics only and its value can't be depended on for much. > > The are obvious advantages/disadvantages to the two schemes. > Win32/Posix recycle "never", so debugging probably easier. > Pthread doesn't waste time/space on the id. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 15:59:15 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 09:59:15 -0400 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: On 29 Sep 2009, at 05:24, Jay K wrote: > Probably on Win32 should just use GetCurrentThreadId(). > And pthread could just use pthread_self(). Yeah, but the type of pthread_self is indeterminate. > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 29 Sep 2009 09:18:57 +0000 > Subject: [M3devel] ThreadF.MyID? > > The algorithms for thread id assignment vary on the platforms. > > In posix user threads and Win32 threads, it appears to be a number > that increments for every new thread. > Not sure what happens after 2 or 4 billion. > > On pthreads, it appears to be, well, we maintain an array of threads. > So it is a number between 0 and n where n is the maximum number of > threads that have > "ever" been running at the same time. With presumably aggressive > reuse of ids. > > Ok? > > They should all use the same? > > It's just that I'm looking at the Win32 code, comparing it to the > pthread code: > > Win32: > LockMutex(threadMu); > cl := self.closure; > self.id := nextId; INC (nextId); > UnlockMutex(threadMu); > > Pthread doesn't have this code. > I don't believe self.closure needs a lock. > And per above, pthreads doesn't need protection here for id, since > it is handled elsewhere. > > I know this was just discussed in a sense -- MyId is for debugging/ > diagnostics only and its value can't be depended on for much. > > The are obvious advantages/disadvantages to the two schemes. > Win32/Posix recycle "never", so debugging probably easier. > Pthread doesn't waste time/space on the id. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 16:01:16 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 10:01:16 -0400 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: None of what you say rings any bells. I don't think any of this is in the BroadcastHeap stuff. It *may* be similar to the POSIX hang that I fixed. I'll need to look more closely at the ThreadWin32 code. But you are getting corruption, not a hang, right? On 29 Sep 2009, at 07:19, Jay K wrote: > Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. > At least. The Enter/Leave mechanical replacement error. > > However even with that, the idle thread stuff seemed to cause > problems. > It was there forever, I realize. > > Also, I should have done this first, but anyway, later, I tried > merging back in your changes from Feb 16. > Somewhat they are moot (lock vs. LockMutex). > Somewhat they are already there (WaitHeap, heapCond => condition). > Somewhat they are trivial (fixing error messages). > > That leaves, in my analysis, the BroadcastHeap change. > > With this change however, /sometimes/ Juno hangs. > Is this, like, somehow equivalent to the Posix hang? > Is the current code the "best"? > > Oh darn..it hangs either way. Just not often. > Could that be "similar" to the pthread problem? > Any chance you can look at it? > > Thanks, > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:06:28 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:06:28 +0000 Subject: [M3devel] ThreadF.MyID? In-Reply-To: References: Message-ID: Fyi, I made us dependent on pthread_self fitting in an INTEGER, though it can be smaller. There are assertions that this is ok. I kind of just trolling..looking at pthreads for inspiration how to fix win32 threads..noticing the differences. We're much better now, but it still definitely hangs sometimes. :( - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: [M3devel] ThreadF.MyID? Date: Tue, 29 Sep 2009 09:59:15 -0400 On 29 Sep 2009, at 05:24, Jay K wrote: Probably on Win32 should just use GetCurrentThreadId(). And pthread could just use pthread_self(). Yeah, but the type of pthread_self is indeterminate. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 09:18:57 +0000 Subject: [M3devel] ThreadF.MyID? The algorithms for thread id assignment vary on the platforms. In posix user threads and Win32 threads, it appears to be a number that increments for every new thread. Not sure what happens after 2 or 4 billion. On pthreads, it appears to be, well, we maintain an array of threads. So it is a number between 0 and n where n is the maximum number of threads that have "ever" been running at the same time. With presumably aggressive reuse of ids. Ok? They should all use the same? It's just that I'm looking at the Win32 code, comparing it to the pthread code: Win32: LockMutex(threadMu); cl := self.closure; self.id := nextId; INC (nextId); UnlockMutex(threadMu); Pthread doesn't have this code. I don't believe self.closure needs a lock. And per above, pthreads doesn't need protection here for id, since it is handled elsewhere. I know this was just discussed in a sense -- MyId is for debugging/diagnostics only and its value can't be depended on for much. The are obvious advantages/disadvantages to the two schemes. Win32/Posix recycle "never", so debugging probably easier. Pthread doesn't waste time/space on the id. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:12:06 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:12:06 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: The corruption is gone now. The combination of fixing Enter vs. Leave, and disabling/removing the idle threads solved the corruption. Neither alone seemed to work. The Enter/Leave problem was obvious, my fault. The idle threads I didn't dig into. Maybe you didn't realize waitSema was dual purpose???? Or maybe it was just the Enter/Leave? If anyone wants, certainly retest it with each change independently. Whenever I look, the Juno hang is on "untilDone" condition variable in Juno. RTIO shows it usually signals it in Misc: C:\dev2\cm3.2\m3-ui\juno-2\juno-app\src\Juno.m3(806): Thread.Signal(w.untilDone) but it doesn't seem to always, either when it hangs or sometimes when it doesn't hang. This /could/ be a bug in Juno or Trestle..except, and this isn't conclusive: I ran Juno @M3no-trestle-await-delete in a loop on Mac and it seemed to go forever. I'll leave it a few hours when I'm not home to see the screen flashing. Of course that switch merits review and/or implementation in a different place. Very useful for testing, very dubious otherwise. We need some sort of stress or fault-injection or variation-injection tests. Run threads deterministically in every combination of order, for example. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Subject: Re: win32 threads...now Juno sometimes hangs.. Date: Tue, 29 Sep 2009 10:01:16 -0400 None of what you say rings any bells. I don't think any of this is in the BroadcastHeap stuff. It *may* be similar to the POSIX hang that I fixed. I'll need to look more closely at the ThreadWin32 code. But you are getting corruption, not a hang, right? On 29 Sep 2009, at 07:19, Jay K wrote: Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. At least. The Enter/Leave mechanical replacement error. However even with that, the idle thread stuff seemed to cause problems. It was there forever, I realize. Also, I should have done this first, but anyway, later, I tried merging back in your changes from Feb 16. Somewhat they are moot (lock vs. LockMutex). Somewhat they are already there (WaitHeap, heapCond => condition). Somewhat they are trivial (fixing error messages). That leaves, in my analysis, the BroadcastHeap change. With this change however, /sometimes/ Juno hangs. Is this, like, somehow equivalent to the Posix hang? Is the current code the "best"? Oh darn..it hangs either way. Just not often. Could that be "similar" to the pthread problem? Any chance you can look at it? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:14:02 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:14:02 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: I could have easily flubbed it but the one time I tried to debug your Broadcast change, I had a deadlock due to one thread having the cm/giant lock and waiting for cs/heap, and another thread vice versa. It's pretty easy to see in the debugger. Given the presence of cm/giant on Win32 and not on pthreads, that doesn't seem too surprising. ? And/or I could easily have mismerged. - Jay From: hosking at cs.purdue.edu To: jay.krell at cornell.edu Date: Tue, 29 Sep 2009 10:01:16 -0400 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. None of what you say rings any bells. I don't think any of this is in the BroadcastHeap stuff. It *may* be similar to the POSIX hang that I fixed. I'll need to look more closely at the ThreadWin32 code. But you are getting corruption, not a hang, right? On 29 Sep 2009, at 07:19, Jay K wrote: Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. At least. The Enter/Leave mechanical replacement error. However even with that, the idle thread stuff seemed to cause problems. It was there forever, I realize. Also, I should have done this first, but anyway, later, I tried merging back in your changes from Feb 16. Somewhat they are moot (lock vs. LockMutex). Somewhat they are already there (WaitHeap, heapCond => condition). Somewhat they are trivial (fixing error messages). That leaves, in my analysis, the BroadcastHeap change. With this change however, /sometimes/ Juno hangs. Is this, like, somehow equivalent to the Posix hang? Is the current code the "best"? Oh darn..it hangs either way. Just not often. Could that be "similar" to the pthread problem? Any chance you can look at it? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:16:11 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:16:11 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:23:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:23:07 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: ps: while I consider the whole stacksize thing broken anyway, notice that using an idle thread (which you had no choice about) got you an indeterminate stack size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:16:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 16:48:24 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 14:48:24 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: Tony..this semaphore with a maximum value of 1, that is a strange thing, isn't it? It could just be an event, right? I tried that..it took 50 runs to hang Juno.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] win32 threads...now Juno sometimes hangs.. Date: Tue, 29 Sep 2009 14:23:07 +0000 ps: while I consider the whole stacksize thing broken anyway, notice that using an idle thread (which you had no choice about) got you an indeterminate stack size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:16:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 17:09:10 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 15:09:10 +0000 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: ah, well now I've got 68 runs with an event amd /slight/ expansion of the giant lock -- in InnerWait I .release before Leave(giant). Given that release almost immediates enter giant anyway, that doesn't seem a bad move. It didn't hang at 68, it did: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x207fef8 0xfb62a5 Redisplay + 0x3ae in ..\src\vbt\VBTRep.m3 0x207ff24 0xfb5e34 UncoverRedisplay + 0xdd in ..\src\vbt\VBTRep.m3 0x207ff4c 0xfb5ec5 RdApply + 0x8c in ..\src\vbt\VBTRep.m3 0x207ff8c 0x5eacb9 RunThread + 0x184 in ..\src\thread\WIN32\ThreadWin32.m3 0x207ffb4 0x5eaaea ThreadBase + 0x33 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... C:\dev2\cm3.2\m3-libs\m3core>echo 69 && \cm3\bin\Juno.exe @M3no-trestle-await- delete 69 C:\dev2\cm3.2\m3-libs\m3core>echo 70 && \cm3\bin\Juno.exe @M3no-trestle-await- delete 70 I'll try again having put back the semaphore.. I rather suspect I have it fixed though and have uncovered some other problem. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:48:24 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. Tony..this semaphore with a maximum value of 1, that is a strange thing, isn't it? It could just be an event, right? I tried that..it took 50 runs to hang Juno.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] win32 threads...now Juno sometimes hangs.. Date: Tue, 29 Sep 2009 14:23:07 +0000 ps: while I consider the whole stacksize thing broken anyway, notice that using an idle thread (which you had no choice about) got you an indeterminate stack size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Tue, 29 Sep 2009 14:16:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. small email truncation: >> We need some sort of stress or fault-injection or variation-injection tests. >> Run threads deterministically in every combination of order, for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 17:25:06 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 11:25:06 -0400 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: <0951DB0C-7A75-403E-AB56-90AAE1A22C83@cs.purdue.edu> Ah, yes, interesting. On 29 Sep 2009, at 10:23, Jay K wrote: > ps: while I consider the whole stacksize thing broken anyway, notice > that using an idle thread (which you had no choice about) got you an > indeterminate stack size. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 29 Sep 2009 14:16:11 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. > > small email truncation: > > >> We need some sort of stress or fault-injection or variation- > injection tests. > >> Run threads deterministically in every combination of order, for > example. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 17:25:58 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 11:25:58 -0400 Subject: [M3devel] win32 threads...now Juno sometimes hangs.. In-Reply-To: References: Message-ID: Hmm. Possibly. I'll look more closely. On 29 Sep 2009, at 10:14, Jay K wrote: > I could have easily flubbed it but the one time I tried to debug > your Broadcast change, I had a deadlock due to one thread having the > cm/giant lock and waiting for cs/heap, and another thread vice > versa. It's pretty easy to see in the debugger. > Given the presence of cm/giant on Win32 and not on pthreads, that > doesn't seem too surprising. > ? > And/or I could easily have mismerged. > > > - Jay > > > > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Tue, 29 Sep 2009 10:01:16 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] win32 threads...now Juno sometimes hangs.. > > None of what you say rings any bells. I don't think any of this is > in the BroadcastHeap stuff. It *may* be similar to the POSIX hang > that I fixed. I'll need to look more closely at the ThreadWin32 > code. But you are getting corruption, not a hang, right? > > On 29 Sep 2009, at 07:19, Jay K wrote: > > Hi Tony. Sorry, I had made one large error in ThreadWin32.m3. > At least. The Enter/Leave mechanical replacement error. > > However even with that, the idle thread stuff seemed to cause > problems. > It was there forever, I realize. > > Also, I should have done this first, but anyway, later, I tried > merging back in your changes from Feb 16. > Somewhat they are moot (lock vs. LockMutex). > Somewhat they are already there (WaitHeap, heapCond => condition). > Somewhat they are trivial (fixing error messages). > > That leaves, in my analysis, the BroadcastHeap change. > > With this change however, /sometimes/ Juno hangs. > Is this, like, somehow equivalent to the Posix hang? > Is the current code the "best"? > > Oh darn..it hangs either way. Just not often. > Could that be "similar" to the pthread problem? > Any chance you can look at it? > > Thanks, > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 17:43:26 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 15:43:26 +0000 Subject: [M3devel] array out of bounds in VBTRep.Redisplay? Message-ID: Anyone ever seen: *** *** runtime error: *** An array subscript was out of range. *** file "..\src\vbt\VBTRep.m3", line 644 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x1fffef8 0xfb62a5 Redisplay + 0x3ae in ..\src\vbt\VBTRep.m3 0x1ffff24 0xfb5e34 UncoverRedisplay + 0xdd in ..\src\vbt\VBTRep.m3 0x1ffff4c 0xfb5ec5 RdApply + 0x8c in ..\src\vbt\VBTRep.m3 0x1ffff8c 0x5eacd7 RunThread + 0x184 in ..\src\thread\WIN32\ThreadWin32.m3 0x1ffffb4 0x5eab08 ThreadBase + 0x33 in ..\src\thread\WIN32\ThreadWin32.m3 ......... ......... ... more frames ... line is apparently: v[dcount[list[i].depth - 1].n] := list[i].v; This is admittedly Juno on Win32. Maybe someone can study the function for bugs? I'll leave Juno looping for hours on a non-Win32 today or so. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 18:27:09 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 12:27:09 -0400 Subject: [M3devel] array out of bounds in VBTRep.Redisplay? In-Reply-To: References: Message-ID: <2CF5EA91-AD04-43C0-8632-CB27E4CB429F@cs.purdue.edu> Never seen it. Probably a race. I think Windows threads must still be broken somehow. On 29 Sep 2009, at 11:43, Jay K wrote: > Anyone ever seen: > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\src\vbt\VBTRep.m3", line 644 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x1fffef8 0xfb62a5 Redisplay + 0x3ae in ..\src\vbt\VBTRep.m3 > 0x1ffff24 0xfb5e34 UncoverRedisplay + 0xdd in ..\src\vbt\VBTRep.m3 > 0x1ffff4c 0xfb5ec5 RdApply + 0x8c in ..\src\vbt\VBTRep.m3 > 0x1ffff8c 0x5eacd7 RunThread + 0x184 in ..\src\thread > \WIN32\ThreadWin32.m3 > 0x1ffffb4 0x5eab08 ThreadBase + 0x33 in ..\src\thread > \WIN32\ThreadWin32.m3 > ......... ......... ... more frames ... > > line is apparently: > v[dcount[list[i].depth - 1].n] := list[i].v; > > > This is admittedly Juno on Win32. > Maybe someone can study the function for bugs? > I'll leave Juno looping for hours on a non-Win32 today or so. > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 29 19:54:48 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 13:54:48 -0400 Subject: [M3devel] Win32 threads Message-ID: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> I believe that the hangs we are seeing are because of the race present in AlertWait, which permit a thread to miss seeing an alert before waiting on the condition. We want the thread only to wait if there has been no alert. Unfortunately, the alert is only protected by the global mutex, which must be release before waiting. Currently, we release the mutex, then wait, with the resulting race. This requires a more complicated handshake than currently implemented. Perhaps using SignalObjectAndWait instead as well as a Win32 mutex on each thread. Similarly to ThreadPThread.m3. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.illig at gmx.de Tue Sep 29 20:13:04 2009 From: roland.illig at gmx.de (Roland Illig) Date: Tue, 29 Sep 2009 20:13:04 +0200 Subject: [M3devel] Mailing list archive Message-ID: <4AC24E30.5030304@gmx.de> Hi, I would like to fix a bug I found in 2005, but the bug's details are not in trac, but only in a mailing list archive, which isn't available anymore. https://projects.elego.de/cm3/ticket/640 Can anyone provide me with the details? Roland From jay.krell at cornell.edu Tue Sep 29 22:12:00 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 20:12:00 +0000 Subject: [M3devel] Win32 threads In-Reply-To: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> References: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> Message-ID: SignalObjectAndWait is widely mentioned as important to implementing condition variables on Win32, however it is documented as not being atomic. Search the web: http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx "Note that the "signal" and "wait" are not guaranteed to be performed as an atomic operation. Threads executing on other processors can observe the signaled state of the first object before the thread calling SignalObjectAndWait begins its wait on the second object." So it isn't useful, right? Thanks, - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 13:54:48 -0400 Subject: [M3devel] Win32 threads I believe that the hangs we are seeing are because of the race present in AlertWait, which permit a thread to miss seeing an alert before waiting on the condition. We want the thread only to wait if there has been no alert. Unfortunately, the alert is only protected by the global mutex, which must be release before waiting. Currently, we release the mutex, then wait, with the resulting race. This requires a more complicated handshake than currently implemented. Perhaps using SignalObjectAndWait instead as well as a Win32 mutex on each thread. Similarly to ThreadPThread.m3. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 29 22:26:07 2009 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Sep 2009 20:26:07 +0000 Subject: [M3devel] Win32 threads In-Reply-To: References: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> Message-ID: 1) Would it be useful to use native alertability? 2) Or to make alerted an event, and use WaitForMultipleObjects? - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Tue, 29 Sep 2009 20:12:00 +0000 Subject: Re: [M3devel] Win32 threads SignalObjectAndWait is widely mentioned as important to implementing condition variables on Win32, however it is documented as not being atomic. Search the web: http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx "Note that the "signal" and "wait" are not guaranteed to be performed as an atomic operation. Threads executing on other processors can observe the signaled state of the first object before the thread calling SignalObjectAndWait begins its wait on the second object." So it isn't useful, right? Thanks, - Jay From: hosking at cs.purdue.edu To: m3devel at elegosoft.com Date: Tue, 29 Sep 2009 13:54:48 -0400 Subject: [M3devel] Win32 threads I believe that the hangs we are seeing are because of the race present in AlertWait, which permit a thread to miss seeing an alert before waiting on the condition. We want the thread only to wait if there has been no alert. Unfortunately, the alert is only protected by the global mutex, which must be release before waiting. Currently, we release the mutex, then wait, with the resulting race. This requires a more complicated handshake than currently implemented. Perhaps using SignalObjectAndWait instead as well as a Win32 mutex on each thread. Similarly to ThreadPThread.m3. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 29 23:26:59 2009 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 29 Sep 2009 23:26:59 +0200 Subject: [M3devel] Mailing list archive In-Reply-To: <4AC24E30.5030304@gmx.de> References: <4AC24E30.5030304@gmx.de> Message-ID: <20090929232659.xvsqww0leccswck0@mail.elegosoft.com> Quoting Roland Illig : > Hi, > > I would like to fix a bug I found in 2005, but the bug's details are > not in trac, but only in a mailing list archive, which isn't available > anymore. > > https://projects.elego.de/cm3/ticket/640 > > Can anyone provide me with the details? Here is a copy of your old mail: X-Authenticated: #530625 Date: Tue, 11 Oct 2005 10:57:29 +0200 From: Roland Illig To: m3devel at elegosoft.com Subject: quake bug: local variable disappears X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavis (elego Software Solutions GmbH) X-List-Check-m3devel-pint-elegosoft-com: approved X-Virus-Scanned: by amavis (elego Software Solutions GmbH) X-Copy: forwarded from wagner at elego.de X-Virus-Scanned: by amavis (elego Software Solutions GmbH) X-Keywords: X-UID: 12885 proc first_of(arr) is foreach e in arr if not empty(e) return e end end return "cc" end proc compile_c(source, object, includes, o_flag, d_flag) is local cmd = [] local cc = first_of([$CC, "cc"]) cmd += [cc] return try_exec(cmd) end c_source("main") c_program("test") Critical Mass Modula-3 version d5.2.7 last updated: 2004-10-31 --- building in NetBSD2_i386 --- new source -> compiling main.c "/home/roland/proj/m3/c-test/src/m3makefile", line 14: quake runtime error: undefined variable: cmd The bug only shows because of: - the order of the two "local" statements in compile_c - a procedure is called - a "foreach" loop appears in the procedure - the "return" from inside the "foreach" loop is executed Roland -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Tue Sep 29 23:31:36 2009 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 29 Sep 2009 17:31:36 -0400 Subject: [M3devel] Win32 threads In-Reply-To: References: <63E829E8-6375-4082-8B08-A88F7A528D1A@cs.purdue.edu> Message-ID: If the documentation is true then it is essentially useless in general. Typical MS. On the other hand, several MS sources on the Web claim that it *is* atomic. Perhaps they should figure out what they really mean. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 29 Sep 2009, at 16:12, Jay K wrote: > SignalObjectAndWait is widely mentioned as important to implementing > condition variables on Win32, however it is documented as not being > atomic. > Search the web: > http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx > > "Note that the "signal" and "wait" are not guaranteed to be > performed as an atomic operation. Threads executing on other > processors can observe the signaled state of the first object before > the thread calling SignalObjectAndWait begins its wait on the second > object." > > So it isn't useful, right? > > Thanks, > - Jay > > > From: hosking at cs.purdue.edu > To: m3devel at elegosoft.com > Date: Tue, 29 Sep 2009 13:54:48 -0400 > Subject: [M3devel] Win32 threads > > I believe that the hangs we are seeing are because of the race > present in AlertWait, which permit a thread to miss seeing an alert > before waiting on the condition. We want the thread only to wait if > there has been no alert. Unfortunately, the alert is only protected > by the global mutex, which must be release before waiting. > Currently, we release the mutex, then wait, with the resulting > race. This requires a more complicated handshake than currently > implemented. Perhaps using SignalObjectAndWait instead as well as a > Win32 mutex on each thread. Similarly to ThreadPThread.m3. > > > Antony Hosking | Associate Professor | Computer Science | Purdue > University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: