bryman
Freshman Member
Posts: 22 
|
Post by bryman on Oct 20, 2014 17:14:19 GMT -5
Entering x9999 as a line command resulted in an execution exception followed immediately by an internal loop.
There were probably less than 9999 lines to the end of file.
SPFLiteCrash.txt provided the following information . . .
SPFLite has encountered an execution exception (C0000005)
Last Interactions were:
KB Primitive: ENTER
Line Cmnd: XX
Primary Cmnd: Down
Module Back Trace:
03 | LCTLTBLA
02 | LCTLPROCESS
01 | POSTKEYBOARD
00 | MAINDKEYPROCESS
SPFLite has detected an internal loop
Last Interactions were:
KB Primitive: ENTER
Line Cmnd: XX
Primary Cmnd: Down
Module Back Trace:
01 | POSTKEYBOARD
00 | MAINDKEYPROCESS
|
|
|
|
Post by George on Oct 30, 2014 13:26:33 GMT -5
bryman: First - apologies for not responding sooner, somehow I missed some of these posts in bug reports.
Second - anything more you can tell me about the state of things when this happened? I've been unable to repeat it. I've tried it on small files, large files (>99999 lines) etc., all without problems.
George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Nov 9, 2014 0:03:47 GMT -5
George, you should have had my reply by now but it seems to have gotten lost. I don't know where it went.
When I first saw your comments, I was able to repeat the error as I had kept a screenshot so knew what I had been doing. After several repeats with attempts to simplify everything to help with your diagnosis, the error can no longer be repeated. I suggest that we close this off until the next occurrence.
Just for the record, the Gedcom data file had 11387 lines and "x9999_" was entered at left of line 1106,
where "_" represents the position of the cursor.
Whoops! It has just happened again on the original file when I tried to repeat the action again.
I have many lines excluded already and lines in the vicinity looked like . . .
001027 0 @ind00029@ INDI
==CHG> 1 NAME Thomas Richard /Pinches/
------ -------------------------------------------------------- < 000077 >
x9999_ 0 @ind00030@ INDI
==CHG> 1 NAME Charles /Pinches/
------ -------------------------------------------------------- < 000032 >
The original exclusions and line indentations were perfomed by a simple macro immediately before the error exclusion was attempted . . .
' GED.macro
SPF_Cmd("C ALL '1' 1 ' 1'")
SPF_Cmd("C ALL '2' 1 ' 2'")
SPF_Cmd("C ALL '3' 1 ' 3'")
SPF_Cmd("C ALL '4' 1 ' 4'")
SPF_Cmd("C ALL '5' 1 ' 5'")
SPF_Cmd("EXCLUDE ALL")
SPF_Cmd("FIND ALL '0' 1")
SPF_Cmd("FIND ALL '1 NAME'")
Let me know if you need further information or the entire data file. Meanwhile, I will try again with something smaller.
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Nov 9, 2014 0:10:00 GMT -5
Extra blank characters seem to have been removed from the macro when my message was posted.
There should have been 2 blanks in ' 2', 3 blanks in ' 3', etc.
|
|
|
|
Post by George on Nov 9, 2014 11:13:43 GMT -5
Robert: Bryman
When entering code type stuff, use the Insert Code button (C inside a Box Icon)
George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Nov 15, 2014 5:12:52 GMT -5
I am not sure if this is progress or not.
I am only able to reproduce the crash on the original data file!!!
I have set up alternative data files with sizes of 100 lines up to 12,000 lines and failed to get the crash.
However, when I return to the original file, I can crash at will, without running the macro first.
I enter x9999 against line 1106 to exclude that number of lines from the display.
I then enter x9999 on the same line and bingo!
In fact, I have just reproduced the crash with x9999 on line 1 followed by the same thing again on line 1!
However, if I use x999 on line 1 followed by x9999 and then x9999 I get the crash too.
Where would you like me to send the data file or does this info enable you to reproduce?
|
|
|
|
Post by George on Nov 15, 2014 12:30:21 GMT -5
Bryman: I'll try with this new data, don't send anything (yet). Info sounds promising.
George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Nov 20, 2014 16:34:06 GMT -5
A little extra information . . .
If I exclude all lines (via "x all" on cmd line) as my first action after loading the file and then enter "x9999" as a line cmd on that excluded line then the crash occurs immediately.
This crash occurs with several different data files so I did a little more investigation.
I tried it with a file that was about 2000 lines and the crash did NOT occur when processing "x9999".
I doubled the size via line cmd of "r" and the crash did NOT occur.
I doubled the size again to 8000 lines and the crash DID occur.
I just thought that might help to identify where the problem lies.
|
|
|
|
Post by George on Nov 22, 2014 13:00:10 GMT -5
bryman: OK, you uncovered a really old, longstanding bug. Surprising it never got spotted and reported before. But then, the circumstances are a bit unusual. Why would you (or anyone) issue an X ALL primary command, and then issue an X99999 line command on the newly created ------ exclude line? Regardless, it shouldn't have crashed. Corrected now. If you really want a fixed version, then download www.SPFLite.com/Files/SPFLite.V814326.ex_ from the web site. Rename to SPFLite.EXE and copy into the normal Install folder. George |
|
|
|
Post by George on Nov 22, 2014 13:37:37 GMT -5
The error wasn't caused by misunderstanding what should happen, it was just a plain old coding error.
Any line command where the 'nnnn' operand is not a repeat value but a line count value, must scan the MIN('nnnn', lastline) range to create the true end-line for the command. If excluded (------) lines are present in that range, all the excluded lines must be incorporated in the range, even though the ------ only counts as '1' line for the line count operand. The error was in calculating the search-continue line following the ------ line; it was incorrect and we just ran-off-the-end and crashed.
George
|
|
bryman
Freshman Member
Posts: 22
|
Post by bryman on Nov 23, 2014 4:47:05 GMT -5
George/Robert, thanks for sorting that out and telling me about the x/ command. It was not a massive inconvenience but I thought that you would want to know if things ever went that wrong. My knowledge of spf/ispf is from more than 20 years ago so I am just getting back into the way that I remember how things used to be.
I must read up on the new facilities provided by SPFLite but have so far just enjoyed using an editor that I used to love in mainframe development. I used to find the exclude command SO VERY useful on the 3270 and regret the loss of the PF keys (and their layout) at the right of the keyboard.
Thanks for recreating a wonderful tool.
|
|
|
|
Post by George on Nov 23, 2014 13:08:42 GMT -5
bryman:
You haven't lost those right-hand PF keys (which I also loved). Remember that KEYMAP will let you map just about ANY key to be a PF key, so the whole right-hand keypad, with the exception of NumLock, is available for you to define as PF keys.
Have a read of the HELP under "Keyboard customization", we've spent a lot of effort making the keyboard in SPFLite WAY more capable than ISPF ever could.
George
|
|
|
|
Post by George on Nov 24, 2014 11:33:55 GMT -5
Robert: When Numlock 'broke', I tried to get it back again. But when in debug mode with multiple windows open, chasing a bug in the keyboard trap is well nigh impossible. Every focus change as you look between various windows triggers messages related to losing/gaining focus, which triggers redraw into action, which triggers more windows messages, which .... makes for extreme hair tearing.
Correcting one lost programmable key just isn't worth the wear and tear on my brain cells. I haven't heard a single user even mildly complain about its loss. (Not counting you). I personally had it mapped, so I was affected. No big deal altering mapping a bit.
George
|
|
