|
|
Post by George on May 1, 2021 14:35:21 GMT -5
Robert: Interesting. But I'm still at a loss why this being a CLIP session would have any effect. The UNDO files are created without any regard for the type of edit session, and in your case, they had been in use for some time.
So this does look like a memory corruption of some kind that clobbered the area where the UNDO filenames are kept. If that's the case, then this is not related to UNDO processing at all, UNDO is an innocent victim of a corruption occurring somewhere else.
And that means we're no closer to a fix till we can figure out what other editing actions were being performed and which might be the culprit.
George
|
|
|
|
Post by George on May 7, 2021 10:22:49 GMT -5
Robert: Still weird. I think I'll change the message to at least display what the corrupted name(s) looks like. Maybe that will give us a clue as to what's mucking it up. But it's odd that: - The UNDO filenames are created and the files themselves created when the new Tab is created. The files are allocated and the names saved in a table at this point. A this point, there is NO data loaded.
- Then the clipboard data is loaded.
- After you've done a few edits, the UNDO filenames will have been written to (probably with no error messages)
- The clipboard is not referenced again during edit, it will only be involved at END time, when the data is written back. During the edit, none of the edit commands know, or care about, where the lines in the edit came from.
- So when these messages occur later in the edit session, something OTHER than clipboard activity must be doing the damage, regardless of the coincidence of these happening during your CLIP editing.
I don't know what else can be done at this time.
George
|
|
|
|
Post by George on May 7, 2021 13:25:35 GMT -5
Robert: Between GLOBAL and Tab localized ones there's probably 50-60 odd tables running around in there. I'll try and check for ones that are not 'self-growing' as possible suspects.
Meanwhile, pick up the latest SPFLite25 version. I've altered the warning message to display the corrupted filename, maybe it will provide a clue. As well, this has been compiled with #DEBUG ON, which drags in code to verify array bounds at execution time. Production code has this OFF as it adds additional overhead (obviously).
George
|
|
|
|
Post by George on May 8, 2021 10:01:33 GMT -5
Robert: SPFLite makes very little use of STRINGZ, mainly they are used as temporary variables when being passed to Windows API calls, which invariably uses then for file/pathnames, and because the API is so C oriented.
And all the traffic to/from the clipboard uses the PB clipboard routines and is all done via simple dynamic STRING variables.
STRING is always used internally unless forced to use the other string types by the API or other external requirement. And why not, all the other types are a pain to work with, even with PB providing automatic conversion between them. PB STRING support is excellent.
I've done the review of SPFLite arrays, and just for 'in case' I've added the extra bit of code to grow then automatically if they need it. There were no 'mainline' arrays amongst them, mostly obscure and rarely used ones.
George
|
|
|
|
Post by mueh on May 8, 2021 15:44:00 GMT -5
George: Experimented with different SETUNDO value's to see if i could reproduce the problem .
Got now a test case to reproduce UNDO file name not valid msg .
In FM open New file with SETUNDO 3 for DEFAULT Profile .
Paste some Data in it and issue SAVEAS xx.macro with SETUNDO 10 for macro Profile and
you should get the msg on modifications of file .
I'm not shure if it solves Robert's Problem .
Made also a Dump with PROCDUMP64 -ma pidnr
and the 4x3 = 12 File name's are correct in dump . ( can only verify it by browsing dump since WINDBG can't do find string in Memory )
It would be nice if msg would display UndoCurr and varptr to Undo array in hex .
FYI: I never saw the problem before with SETUNDO 10 in all profiles .
|
|
|
|
Post by George on May 9, 2021 9:07:57 GMT -5
MUEH: I'll check it out right away. How did you ever catch on to that?
George
[UPDATE}
Yay! Add 1 source line and it's fixed.
Good detective work MUEH!
[\UPDATE]
===> Amazing! Could years of this lurking bug be fixed with one line? I will test this ASAP when you might a new beta release - R
->->-> Actually 2 lines, the same problem could have been triggered by a RENAME. |
|
|
|
Post by mueh on Jul 1, 2021 2:19:23 GMT -5
George: Robert sayed in his STATE Problem that he has seen the msg again . I'm aware of another condition that could cause the msg . PROF COPY with higher SETUNDO value causes following error msg which needs improvement to display Prf.UndoNumber UndoCurr UBOUND(Undo) and LUndo in hex or better VARPTR(Undo(1)) in hex . To realy takle this problem the msg with Hex address and a dump must be taken with procdump64 tool to see if we have an overlay or are just addressing beyond allocated Undo array storage .  As to the question how i found problem . Looked into source code and one condtion could be that Undocurr goes beyond UBOUND of Undo aray . Thanks |
|
|
|
Post by George on Jul 1, 2021 8:31:41 GMT -5
MUEH: I'll have a look at the PROF COPY, sounds like it could do with the UNDO re-allocation call as well.
George
[UPDATE]
Yes it needed a call to UNDOInit as well. Now added.
Again, good eyes!
[\UPDATE]
|
|
