|
|
Post by mueh on Jan 8, 2024 1:33:51 GMT -5
Hi George ! Used FCLIP macro on large file and got crash in UNDOGET when UNDO is done to backout the COPY of a file . Found that independent of record size if nr of lines is 99996 or greater i get the crash . SPFLite V(3.0.24005) @ 2024-01-08 07:14
SPFLite has encountered an execution exception (C0000005)
Last Interactions were:
P=Down
K=ENTER
P=Down
K=ENTER
K=CLIPCLEAR
K=HOME
K=ERASEEOL
K=ENTER
P=CLIP
K=HOME
K=ENTER
P=COPY 'D:\eundo'
K=SAVECURSOR
K=HOME
K=ENTER
P=res cmd
K=ENTER
P=UNDO
K=ENTER
P=UNDO
Module Back Trace:
06 UNDOGET
05 PCMDUNDOREDO
04 CMDASSIGN
03 POSTKEYBOARD
02 MAINDKEYPROCESS
01 MAINCDOKEYSTRING
00 REALPBMAIN
Hope you can reproduce with the file data shown in screenshot . Occures in older releases too .  |
|
|
|
Post by Robert on Jan 8, 2024 12:08:35 GMT -5
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.
R
|
|
|
|
Post by George on Jan 8, 2024 12:13:46 GMT -5
MUEH: The error is really triggered by UNDOPUT.
To avoid delaying the main program while UNDO snapshots are taken, the actual writing of the data is done in a sub-thread.
But to allow the main line to continue, the sub-thread has to make its own copy of the data, so there is a semaphore between them which indicates the memory copy has been done and the mainline can continue. There is basically an endless DO LOOP until the semaphore is set. There also was a timed escape from this loop as a 'just in case'. For very large files, the memory copies seem to have taken long enough for the escape to trigger and allow the mainline to continue. It really shouldn't have. So I've removed the escape code.
I've now tried FCLIP on files right up to 1,500,000 lines. All worked fine.
Basically I'd say if you're manipulating huge files, turn UNDO off.
I wish I could handle UNDO another way, but the data storage structure used internally can only be handled by bulk snapshots. For normal size files, this works fine, but large ones, with UNDO turned on, it becomes unweildy.
George
|
|
|
|
Post by mueh on Jan 8, 2024 14:04:32 GMT -5
Hi George !
Installed 24008 but UNDO after FCLIP gives the same crash with 99996 lines .
Could you test it again ?
Thanks
|
|
|
|
Post by George on Jan 8, 2024 14:43:39 GMT -5
MUEH: OK, tried again. It loads my 1.5M Line files just fine, but in testing UNDO/REDO there IS something wrong.
Leave it with me.
George
|
|
|
|
Post by George on Jan 10, 2024 12:59:49 GMT -5
MUEH: I've found something, after a bit more testing I'll post a Beta. It's a long standing 'lurker' type bug. See more comments in the 'Latest Beta' thread.
George
|
|
|
|
Post by mueh on Jan 10, 2024 13:43:56 GMT -5
Hi George !
Installed 24010 but UNDO crash after FCLIP remains the same .
It is permanent reproducable with 99996 lines on my side .
Thanks
|
|
|
|
Post by George on Jan 10, 2024 16:05:44 GMT -5
MUEH: FCLIP works here with a 1.5M line file. Can you show what your Profile for CLIP sessions shows (CLIP or DEFAULT).
There must be some other combination triggering this.
Another thought, what's the Profile for the file being used vs the Profile for the CLIP session.
George
|
|
|
|
Post by Robert on Jan 10, 2024 16:27:32 GMT -5
George, you might benefit from doing a scan for GET$$ in your code, if you haven't done so already.
As for CLIP vs. a profile, if a COPY command is issued in a Clip edit session, do you apply the Profile SOURCE when deciding how to copy the data? Seems like you'd have to, because if the data was UTF-8 or UTF-16, you'd have to translate it to ANSI before the data was copied in.
R
|
|
|
|
Post by George on Jan 10, 2024 17:59:33 GMT -5
Robert: Exactly my thoughts. Say the CLIP profile has SETUNDO 10 and the copied file has SETUNDO 0 (or visa versa). And after the copy, does an UNDO snapshot get taken, or not, or under which SETUNDO criteria. It gets very confusing and hard to figure out when 'walking' through the code.
George
|
|
|
|
Post by Robert on Jan 10, 2024 18:27:32 GMT -5
It seems like the SETUNDO level of the *COPIED* file has no bearing on the file you are copying it INTO.
So, after the copy, does an UNDO snapshot for the CLIP Edit session get taken? Yes, it should.
R
|
|
|
|
Post by mueh on Jan 11, 2024 4:21:03 GMT -5
Hi George and Robert ! I aggree that we have a PROFILE override which destroyes the SETUNDO value after COPY . It can be also reproduced without FCLIP after fresh SPFLite start by opening a NEW file . If you now do a COPY of attached file with 99984 lines and enter PROF the Profile display shows up as corrupted . ( Additional PROF cmd shows okay values but CRASH occures after UNDO )  eundoP (390.56 KB) and UNDO results in crash SPFLite V(3.0.24010) @ 2024-01-11 10:32
SPFLite has encountered an execution exception (C0000005)
Last Interactions were:
P=CRETRIEV
K=ENTER
P=RETF
K=DOWN
K=DOWN
K=DOWN
K=LEFT
K=LEFT
K=LEFT
K=LEFT
K=LEFT
K=LEFT
K=LEFT
K=LEFT
K=ENTER
P=copy d:\eundop
K=ENTER
P=prof
K=ENTER
P=undo
Module Back Trace:
06 UNDOGET
05 PCMDUNDOREDO
04 CMDASSIGN
03 POSTKEYBOARD
02 MAINDKEYPROCESS
01 MAINCDOKEYSTRING
00 REALPBMAIN
This test was made with CFG file renamed and fresh SPFLite setup . Please make test exactly the same sequence . If you issue PROF before COPY you get other symtoms . Hope you can reproduce |
|
|
|
Post by George on Jan 11, 2024 9:59:02 GMT -5
MUEH: Many thanks. I can duplicate your results properly just using my latest test version and my normal CFG file.
Now to figure out what's going on in there.
George
|
|
|
|
Post by Robert on Jan 11, 2024 11:45:38 GMT -5
George, I think Mueh still has the old FCLIP macro that has (EraseEOF) instead of (EraseEOL). Not sure if that matters.
R
|
|
|
|
Post by George on Jan 11, 2024 13:12:42 GMT -5
MUEH: Well, another really old lurker type bug. The clue was the reqirement for your particular test file size, just under 100,000 lines.
And SPFLite's initial allocation of a text buffer is -- yes, 100,000 lines.
The Profiles themselves are not corrupted, but when you do a PEOF display, you need to insert the lines needed for the display.
When the insert request requires an extension (i.e. the PROF lines force the size past the 100,000 boundary, the tables themselves are extended properly.
But since the actual text tables have been re-allocated, the insert routine needs to update the text pointers to them. During this process the text pointers to the PROF lines were also updated when they shouldn't have been, they point at static data areas. So the pointers went to zeros (mostly) and the lines came out blank.
Another of those almost impossible to track bugs.
George
|
|
