|
|
Post by davecheckley on Sept 20, 2022 2:58:27 GMT -5
I've had a number of instances when SPFLite crashes when opening a file. The files are all .java filetypes, and the crashes occur whether I'm opening them from Windows File Explorer or the open dialog of SPFLite. I do get trace files, but they don't tell me very much:
SPFLite V(2.6.22194) @ 2022-09-20 09:49
SPFLite has encountered an execution exception (C0000005)
Last Interactions were:
Module Back Trace:
05 COPYAFILE
04 INITAFILE
03 TABADD
02 LOADTHETEXT
01 PCMDEDIT
00 REALPBMAIN
Is there anything else I can do to get better diagnostics?
Unfortunately I can't attach an offending file, as the data is confidential.
Thanks, Dave Checkley
PS These are straight ASCII files, with nothing special about them at all, as far as I can see.
|
|
|
|
Post by Stefan on Sept 20, 2022 4:26:10 GMT -5
Hi Dave,
I'm have seen the same issues when loading apparently benign .TXT file, or, when not on loading then on SAVE or at some apparently randon point later.
I'm still struggling to narrow down the scenario in order to locate the spanner amongst the works.
Does your crash occur every time on the same file, on all files of that type, or is it sporadic?
|
|
|
|
Post by davecheckley on Sept 20, 2022 7:21:49 GMT -5
Hi Stefan, It was repeatable, with particular files. Some of them were java, and some were assembler listings.
I've deleted and reinstalled SPFLite, and also deleted the SPFLite directory in my Documents folder. That seems to have cured the problem,
I've been having a lot of trouble getting my profile settings correct for EBCDIC data files, and I think I had something somewhere in a profile file which was causing problems.
Unless George or Robert want to dig into my deleted folder (unlikely :-) ) i will just forget about it.
Thanks, Dave
|
|
|
|
Post by Stefan on Sept 20, 2022 7:47:59 GMT -5
I've gone a similar route, but only deleted my SPFLITE.CFG file. This is the SQLite database where all the settings are stored, so any corruption there will cause crashes.
There are ways of saving most of your customisation settings via the CFGMaint utility before you delete that file.
When you restart SPFLite without a CFG file present, it will recreate a new CFG file and you can (carefully) restored the custom settings via CFGMaint. Useful for you as the database also houses all the profiles.
So far, it seems to be better but the jury is still out.
If it still keeps happening, I'll go back to the version before 22194 or even earlier.
|
|
|
|
Post by davecheckley on Sept 20, 2022 9:03:54 GMT -5
Hi Robert, One of my problems is that I couldn't find my profile(s). Are they all in the CFG file? The documentation says they're in .ini files but I couldn't find any.
I restored my old CFG file and found that my default profile was EBCDIC, which is probably a lot to do with my issues. I've attached some screenshots of my options and a couple of profiles. (Sigh, my file is too big - I'm going to have to break it up).
There's nothing unusual about the java files...
Thanks, Dave
Attachments:spflite-options-1.docx (737.41 KB)
|
|
|
|
Post by davecheckley on Sept 21, 2022 4:01:13 GMT -5
Hi Robert,
Yes, my default profilke got corrupted when I was trying to play with some ebcdic files. I deleted my SPFLite folder and started working with the default profiles, and everything seems to be working just fine. I think I just need to be careful with ebcdic file!
Thanks,
Dave
|
|
|
|
Post by Stefan on Sept 21, 2022 9:14:01 GMT -5
Dave,
Many moons ago, each profile (and a lot of other settings) were stored as .INI files. Then the lot was moved to a database - the SPFLIte.CFG file. I guess the documentation still needs to catch up in some places. FWIW, the DEFAULT profile is a bit 'special' in that I believe it is used, at least in part, as a starting point for SPFLite to create a new profile whenever a file comes along whose filetype SPFLite hasn't seen before. As SPFLite ships without knowledge of any file types, this will happen a lot after you 're-build' the CFG from scratch. At this time the DEFAULT profile is the only one it 'knows'.
Given that the DEFAULT profile has this special role, you may wish to protect it from inadvertent changes to important settings like SOURCE, COLLATE, EOL, etc. In my case, I used File Manager - Config to modify the DEFAULT profile. I set it to include the settings I like to have in all my profiles (MINLEN, HILITE FIND/AUTO, COLS ON, etc) and, most importantly, LOCK ON. The LOCK prevents inadvertent changes being saved to the profile and potentially thereby messing with other new filetypes that come along later.
You can easily take the LOCK OFF if you wish to modify the profile subsequently and put in back ON afterwards.
For backup/recovery, SPFLite includes the CFGMAINT utility - it's in the documentation too. The -EXPORT function will write all you SPFLite settings into a simple .TXT file, everything from colour scheme to Profiles, SET variable to Keyboard customisations, Recently used commands, the lot! As Robert explained, it is worth doing this periodically to create a backup. Of course, as with any backup, it will go stale over time, but it's better than nothing when disaster strikes. As it's a simple TXT file, you can view it in SPFLite, but I do not recommend you make changes!
Armed with such a file, albeit out of date, if you ever need to restart with a 'blank' SPFLITE.CFG file, you can recover important stuff using this approach. (1) Take an -EXPORT, this time of the 'blank' file (2) Load both the exported files into two tabs in SPFLITE (3) Use the DIFF command to compare them. (4) Cut what you need (e.g. all your profiles) from the backup file and Paste them into the 'blank' file (5) Close SPFLite (6) Use CFGMAINT -IMPORT to rebuild the CFG with the new data (e.g. the Profiles)
|
|
|
|
Post by George on Sept 21, 2022 10:03:27 GMT -5
Everyone's been busy. Thanks to Robert and Stefan for jumping in and assisting.
George
|
|
|
|
Post by Stefan on Sept 24, 2022 11:38:08 GMT -5
George,
As mentioned above, I've seen some intermittent and apparently random crashes.
Sometimes on file loading, sometime on SAVEing and sometimes just out of the blue.
I think it occurred mostly while I was working on a file containing character/bytes of unusually low HEX values. Hence my question...
Is there any reason why any of the following character values on the data should cause SPFLite of PowerBasic to trip up? There are ANSI in Hex: x'01' to x'07' inclusive x'10' to x'1F' inclusive
|
|
|
|
Post by George on Sept 24, 2022 12:09:50 GMT -5
Stefan: SPFLite cares nothing about the data as far as any loading or saving functions. All data is stored in normal PB STRINGS which handle all 256 characters, NO characters have any special significance. Thats why you can load an EXE file. Can't edit it, but you can Browse it.
George
|
|
|
|
Post by Stefan on Sept 26, 2022 9:43:16 GMT -5
R, File is ANSI just like a .TXT file, but contains 'box-graphic' characters to 'draw the frame' (see attached effect).
EOL is CRLF as usual. Only odd thing about the data is that the 'box-graphic' chars have a low hex code. The crashes were random but subjectively (!) tended to occur sometimes when I manipulated or had recently manipulated some of those chars. For instance, I might have typed in ------ or | | | | and then issue a CHANGE command like C ALL '-' x'0E' or C ALL '|' x'0F' etc.
Or I may have highlighted (MARK) a few of the special bytes and Copy/Pasted them elsewhere, or they may have moved along the line when I was inserting or deleting text.
When the frequency of crashes became intolerable, I built a new SPFLIte.CFG file and reloaded my settings from an CFGMAINT -EXPORTed file, but omitted the Command Retrieve section is it contained commands with these special chars. Again, subjectively(!), SPFlite felt more robust after that.
I was wondering if Dave might have tarshed the SOURCE and/or COLLATE entries in some of his profiles and the EBCDIC and ANSI settings had become blurred.
That could have led to him having data with 'odd' hex values in his files.
|
|
|
|
Post by davecheckley on Sept 28, 2022 3:54:27 GMT -5
Hi Stefan,
I'm pretty sure I did trash *something* in my profiles, although I'm not sure what.
I've also been having problems trying to process quite large EBCDIC data files, even with a default profile. I think SPFLite wants to interpret some data as control characters, and dies on some combinations. I will just use HexEd instead for these guys. (I'm not actually trying to edit them, just look at them, but even that fails.)
|
|
|
|
Post by George on Sept 28, 2022 9:01:05 GMT -5
Dave: Check the XTABS setting, better be 0. Otherwise any X'09' TAB character will get expanded and muck things up.
George
|
|
|
|
Post by Stefan on Sept 28, 2022 12:05:43 GMT -5
Dave,
DISCLAIMER: I haven't tried this and may be confusing SPFLite with another application from my history.
I'm sure George or Robert will correct me, but I think(!!!) that any UNLOCKED profile will change some of its values depending on the file you're loading with in. If this is nonsense, guys, please just remove this post - you're both Admins in this forum.
If you're loading files of different types, you really MUST give each one its own profile. Unless you LOCK a profile, I think it can change 'without warning' to the file format which you are loading. If LOCKED, the profile will still adapt to the file being loaded, but those adaptations wont be 'remembered' for the next time the profile is used.
Example:
My DEFAULT profile is set up for what are effectively ANSI encoded .TXT files, ie. Source and Collate both ANSI, EOL CRLF, RECFM U, LRECL 0, etc. I think if I go to load an EBCDIC FB 80 file and tell SPFLite to use my DEFAULT profile, the DEFAULT profile will change some(!) of its values to accomodate the PHYSICAL aspects it encounters when reading the incoming file. If I'm right, its means that my DEFAULT profile isn't the reliable 'standard' that SPFLite expects it to be and subsequent new profiles created based on the DEFAULT profile will be equally unreliable/unpredictable.
I think George recently put through a change so that when SPFLite creates a new profile from the DEFAULT profile, it will not use the 'current' settings in the DEFAULT profile, but instead base the new profile on the default values which SPFLite used to initially create the DEFAULT profile when the product was installed.
If that is how it works now, I'm disappointed. 
Yes, it avoids unpredictable settings in the DEFAULT profile, but I think it is clumsy.
There are many settings in my DEFAULT profile which differ from the SPFLite initial/installation settings.
I changed them deliberately BECAUSE I WANT them to be carried forward whenever new profiles are created.
Stuff like COLS ON, MINLEN, HILITE FIND/AUTO, MARK settings, TABS setting (always one in col 1), etc
It allows me to create new profiles which are 90+% right for the way I want my editor to work.
I believe that a better way to allow users to tailor the profile-creation process to their preferences AND protect the integrity of the DEFAULT profile is to LOCK the DEFAULT profile by (pardon the pun) default.
In any case, I strongly advise that users should use a unique profile for every file type with unique physical attributes (record format, length, encoding, etc). It's OK to load a .LOG file with the .TXT profile when both are just ANSI text, but not if, for example, the .LOG file is EBCDIC and the .TXT file is ANSI. I also believe that the best way to prevent unintended profile changes (by SPFLITE or by me doing something stupid) is to LOCK every profile once I have it set up the way I like it. It also avoids frustration if, for example I changed the BOUNDS when I edited a file 3 weeks ago. Today I edit another file using that profile and all the FIND commands fail! All because the one-off BOUNDS change was saved in the profile. Robert recently had similar issues with a one-off HEX use. Just LOCK the PROFILE and those changes are temporary. And having to UNLOCK the profile before a permanent change makes it more obvious later.
|
|
