|
Post by Robert on Jan 11, 2024 13:20:59 GMT -5
George, re. my wild guess of 3 days ago: "Mueh, you may have provided the missing link, which is the number of lines. Perhaps George allocated a fixed number of undo lines for this, assuming no one would need more than (say) 9999 of them, and then that fixed array was overrun? At least it's now a possible line of inquiry on it."
Oh boy, I'd say, time to reconsider any other "initial allocations" ...
R
|
|
|
Post by George on Jan 11, 2024 13:48:31 GMT -5
Robert: All tables in SPFLite were modified years ago to be expandable and prevent 'overflow' conditions.
The main data storage tables contain pointers to a pool of available text storage buffers. When these tables are expanded (in unison) there is still a requirement to update the pointers to the text storage pool, since expanding a text array moves it in memory.
The problem here was updating the pointer of a PROF line, which it shouldn't have done as they do not use the normal text pool, but instead point at static memory variables. This is so you can have multiple PROF displays visible at the same time and guarantee they all display the same thing, and don't have to be individually updated.
There's still something going on in UNDO, still looking for that one
George
|
|
|
Post by George on Jan 11, 2024 13:50:40 GMT -5
And seriously, why, all of a sudden, are you guys 'finding' all these obscure, weird, and impossible to find bugs?
Is this a conspiracy?
George
|
|
|
Post by George on Jan 12, 2024 11:57:29 GMT -5
MUEH: This crash will take a bit of careful study to fix. It basically happens when the UNDO checkpoint being restored was taken BEFORE the current tables went through an expansion. So the checkpoint tables do not match size-wise with the data tables they are storing back into.
The whole UNDO philosophy is to take backups of the memory tables en mass and restore them en mass. There is nothing done at an individual line level.
George
[UPDATE] Corrected. Turns out it was handled, but just not handled quite correctly, one of the loops was still using the incorrect table size.
[/UPDATE]
|
|
|
Post by mueh on Jan 13, 2024 1:54:48 GMT -5
Hi George ! Many Thanks for 24012 . Can't produce any UNDO crashes even doing repetive UNDO/REDO test's and PROF cmd's . Have no yet made test's by inserting/deleting lines at end of file and making UNDO/REDO with file data containing sequence nr .
However can reproduce Problem ( also in old version ) when using eundop file and following cmds in NEW file . COPY eundop DOWN MAX DOWN this results in crash
SPFLite V(3.0.24012) @ 2024-01-13 07:27 SPFLite has encountered an execution exception (C0000005)
Last Interactions were: K=RIGHT K=RIGHT K=RIGHT K=RIGHT K=RIGHT K=RIGHT K=RIGHT K=RIGHT K=RIGHT K=RIGHT K=INSERT K=DOWN K=DOWN K=LEFT K=ENTER P=COPY 'D:\eundop' K=ENTER P=DOWN m K=ENTER P=down Module Back Trace: 04 DISPSCREEN 03 POSTKEYBOARD 02 MAINDKEYPROCESS 01 MAINCDOKEYSTRING 00 REALPBMAIN
Many Thanks
|
|
|
Post by George on Jan 13, 2024 10:00:31 GMT -5
MUEH: You must lie awake at night dreaming up these test scenarios. What's your default Scroll amount? George [UPDATE] Yes, another boundary problem - fixed. Will you PLEASE stop playing with your 999996 line file? I don't need this 999996 bug-of-the-day assignment. [/UPDATE]
|
|