WAIT and file handling

Discussions related to database technologies, file handling, directories and storage
KenDown
Posts: 327
Joined: Wed 04 Apr 2018, 06:36

WAIT and file handling

Post by KenDown »

In my diary program the days are held in an array and obviously today's entry is blank. When, at the end of the day, I enter my activities the entire array is saved to disk and then read back in again and displayed.

Unfortunately, ten or fifteen seconds - or sometimes immediately - after doing the above, the program just vanishes. Whether using the compiled version or running it straight from the editor, the program halts, the editor closes, no chance to debug or anything. It's just gone - yet curiously, the entry is saved.

After tearing my hair out over this for the last year or more and trying all sorts of things, as a bit of debugging I introduced a WAIT 50 after saving and before reading - and lo and behold, the problem is solved! Why it is solved, I could not tell you. Perhaps writing, closing and then opening and reading a file happens too fast for the hard drive to cope?
RichardRussell

Re: WAIT and file handling

Post by RichardRussell »

KenDown wrote: Sat 11 Apr 2020, 05:58I introduced a WAIT 50 after saving and before reading - and lo and behold, the problem is solved!
I'm sure it's not "solved" at all! The window 'disappearing' in the way you describe is usually caused by a Segmentation Fault, i.e. your program attempting to access a region of memory that it has no rights to (or indeed that does not even exist). The apparent 'cure' will somehow have changed the circumstances enough to (for example) move the memory access to a legitimate region.
Perhaps writing, closing and then opening and reading a file happens too fast for the hard drive to cope?
Not a chance. Of course it's conceivable (but unlikely) that your PC has a hardware fault which might result in a similar symptom.

If I were to guess, I'd say that a delay having an effect might suggest a multi-threading issue (since it will change the relative times at which different threads do things). That would make me suspicious of the misuse of a library that creates one or more new threads, for example one of the WINLIBx libraries.

You won't like this suggestion, probably, but you should ignore the fact that the added WAIT has apparently made things more stable, remove it, and then debug the fault properly! If you are struggling to find the fault, prune the code down until it has the bare minimum of functionality for the crash still to occur, whilst still being a self-contained program, and post it here.
KenDown
Posts: 327
Joined: Wed 04 Apr 2018, 06:36

Re: WAIT and file handling

Post by KenDown »

Thanks for the advice. I'll re-examine the code to see if the program is accessing memory that it shouldn't - the only thing I can think of off-hand is that the diary entries are held as a string array and naturally the array is empty to begin with. I am pretty sure that no entry exceeds the very generous string-length limits, but …?

As for debugging, it's jolly difficult to do so when the program vanishes, leaving not a wrack behind. No variables to check, no indication of which line causes the crash, nothing.
RichardRussell

Re: WAIT and file handling

Post by RichardRussell »

KenDown wrote: Sun 19 Apr 2020, 20:57As for debugging, it's jolly difficult to do so when the program vanishes, leaving not a wrack behind. No variables to check, no indication of which line causes the crash, nothing.
The 'binary chop' technique will generally find the line at which it is crashing quite easily. In your position I might be tempted to use a different IDE (bbcide.bbc or SDLIDE.bbc) because then the IDE won't be taken down by the crash - which it is in BB4W because it's all one process. This should speed up debugging.

But I still don't think it's as simple as that: if your program uses no indirection or CALL, SYS or USR functions (and doesn't install libraries which use them) then it's virtually impossible to get the sort of crash you are experiencing because the interpreter simply won't let it happen. That's one of the advantages of a language like BASIC.

So my assumption remains that it's something more 'subtle' than that, possibly a multi-threading issue. Does your program create one or more additional threads (e.g. via one of the WINLIBx libraries)? If so that's where I would concentrate my attention.

As I said before, if you are struggling to find the fault yourself distill the program down to the bare minimum amount of code that still crashes, whilst being self-contained, and post it here.