Recompiled all Tedit files #2195
Conversation
|
I switched to this branch and so far I'm not noticing anything unusual on Linux Mint 22.1 Cinnamon. |
Previous master version didn't have all of the tests
|
Well, unfortunately, this fails the STRESSINSERT stress test, again showing the arrayblock crash.
I updated the TEDIT-STRESS file here to include the updated tests, but that's no part of the Tedit runtime.
You might try LOAD(TEDIT-STRESS.LCOM) and let (STRESSINSERT) run for awhile.
… On Jun 23, 2025, at 12:41 PM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2195)
<#2195 (comment)>
I switched to this branch and so far I'm not noticing anything unusual on Linux Mint 22.1 Cinnamon.
—
Reply to this email directly, view it on GitHub <#2195 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMLEM4WKJXF46CI7N33FBKALAVCNFSM6AAAAAB76HIEZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJXG4ZTKOJQGU>.
You are receiving this because you authored the thread.
|
|
I updated to commit 0f17d71 and ran the stress test but, since it didn't break, I interrupted it after about 10 minutes of runtime and over 14K iterations. Approximately how many iterations are needed for the test to fail? |
|
I see it at about 10, but it varies.
Are you running in the lispusers directory?
… On Jun 23, 2025, at 11:12 PM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2195)
<#2195 (comment)>
I updated to commit 0f17d71 <0f17d71> and ran the stress test but, since it didn't break, I interrupted it after about 10 minutes of runtime and over 14K iterations. Approximately how many iterations are needed for the test to fail?
—
Reply to this email directly, view it on GitHub <#2195 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJPMIZGJ62WXP44RNU33FDT5HAVCNFSM6AAAAAB76HIEZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJYHE2TIMRXGY>.
You are receiving this because you authored the thread.
|
|
No, I'm running in the default Medley directory. I'll try running from lispusers. |
|
I ran another test like this ( Since the test ran regularly for more than 6 minutes and over 220 iterations I stopped it. |
|
As was suggesed in the meeting, I modified the stress test so that it saves the virtual memory (either SAVEFM or SYSOUT) before each insertion. The hope is that we will catch the state of the virtual memory just before it crashes, and perhaps then run to watch more precisely where it goes bad. This strategy doesn't seem to help. When the pre-crash memory image is started up, it doesn't immediately crash as it expected. It just keeps on doing the insertions as if nothing had gone wrong. Is there any value in looking more carefully at the precrash image? Or does this suggest that the problem is not in the Lisp memory but in some Maiko state? |
|
(P.S. These are always arrayblock crashes, either bad passwords or header/trailer length mismatch). |
|
I've added code that looks over all the memory of a block it is about to free to see if there are any words that look like block headers/trailers within it -- I have not found any cases yet in many hours of running the code. I am running with ARRAYBLOCKCHECKING turned on (both from the Lisp side, and by forcing it on in Maiko directly), but am NOT running with TEdit calling CHECKARRAYS. If there is a problem, and not something caused by the timing of when CHECKARRAYS is called, then it should become visible from the Maiko checking. |
|
Are you suggesting that I stop the calls to CHECKARRAYS and see what happens? And that we may be out of the woods if the Maiko checks don't fail?
Is that code in the current maiko master?
… On Jun 26, 2025, at 10:15 PM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2195)
<#2195 (comment)>
I've added code that looks over all the memory of a block it is about to free to see if there are any words that look like block headers/trailers within it -- I have not found any cases yet in many hours of running the code. I am running with ARRAYBLOCKCHECKING turned on (both from the Lisp side, and by forcing it on in Maiko directly), but am NOT running with TEdit calling CHECKARRAYS. If there is a problem, and not something caused by the timing of when CHECKARRAYS is called, then it should become visible from the Maiko checking.
—
Reply to this email directly, view it on GitHub <#2195 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJIK5G2LQ6GBZ45P7VD3FTHNJAVCNFSM6AAAAAB76HIEZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJRG4YDAOBRGM>.
You are receiving this because you authored the thread.
|
|
It could be that CHECKARRAYS needs to be uninterruptable, but I think stopping calling it is a good test. Still set ARRAYBLOCKCHECKING to T though, since you won't have it otherwise forced on in the Maiko code. The extra checking/trap code is NOT in maiko master -- it's hacks to the code that makes it unusable in a release situation (it generates a dozen or so lines of output on stdout for every allocation/reclaim, and if it does find a potential problem (there are some false positives) you have to poke around in URaid and then continue. |
|
Compiling CHECKARRAYS with an UNINTERRUPTABLE around the PARSEARRAYSPACE doesn't make it behave better. |
|
So, there is no reason for the stress tests to continue calling CHECKARRAYS, just set ARRAYBLOCKCHECKING to T?
And, is there any value in saving the memory image before each event?
I.e., do the tests by setting ARRAYBLOCKCHECKING to T and just let it run?
… On Jun 26, 2025, at 11:01 PM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2195)
<#2195 (comment)>
It could be that CHECKARRAYS needs to be uninterruptable, but I think stopping calling it is a good test. Still set ARRAYBLOCKCHECKING to T though, since you won't have it otherwise forced on in the Maiko code.
The extra checking/trap code is NOT in maiko master -- it's hacks to the code that makes it unusable in a release situation (it generates a dozen or so lines of output on stdout for every allocation/reclaim, and if it does find a potential problem (there are some false positives) you have to poke around in URaid and then continue.
—
Reply to this email directly, view it on GitHub <#2195 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMAH44LVX7BWS5MMX33FTM5NAVCNFSM6AAAAAB76HIEZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJRG44DENRRG4>.
You are receiving this because you authored the thread.
|
|
The medley process scheduler isn't preemptive ... no other process will run until the current process does a (BLOCK), or there is an interrupt by timer (for SPY) or keystroke (an interrupt character). UNINTERRUPTABLE is only useful to let operations that really must be done in a single transaction lest the memory would be corrupted. It should never be wrapped around code that in the normal course of events would (BLOCK). |
For a baseline comparison with rmk88. A slight change to TEDIT-FNKEYS (constant dependency) that the recompiled revealed.