Author |
Topic: *.exe does not exit cleanly. (Read 1162 times) |
|
admin
Administrator
member is offline
Posts: 1145
|
 |
Re: *.exe does not exit cleanly.
« Reply #15 on: Jan 4th, 2010, 09:33am » |
|
Quote:| does this look right or wrong? |
|
I wouldn't go as far as to say it's 'wrong', but I would prefer (unless there's some specific reason why it's not acceptable) the more straightforward:
Code:ON ERROR ON ERROR OFF : PROC_cleanup : QUIT
ON CLOSE PROC_cleanup : QUIT
:
:
WHILE (found% = TRUE)
PROC_IRQ_poll
ENDWHILE
PROC_cleanup
QUIT
The less code you execute after an error has occurred the better, as far as I'm concerned. In your original version you relied upon executing quite a lot of code (including the code which I presume exists between the two lines you've shown with a colon) before actually quitting. What's more, that code was executed in an ON ERROR OFF condition so should a second error occur it wouldn't be trapped.
Quote:| the only files in the "hung" BB4W sub-directories are LIB files. |
|
There's an element of ambiguity in the term 'LIB files'. Do you mean BASIC files loaded by INSTALL, or DLL (etc.) files loaded by SYS "LoadLibrary" (or both)?
Quote:| It is the entire sub-directory which is not deleted upon Exit. |
|
That's not particularly significant, because BB4W simply deletes the entire folder, not the individual files. However, as Michael says, you should certainly check that nowhere in your program are you writing to the variable @lib$ (or making it LOCAL, or a formal parameter, or anything like that). @lib$ must be treated by your program as a constant, but since BBC BASIC doesn't have true constants it can't detect you breaking the rule.
Quote:| It is so far only after they have been running for over a day (sometimes it is a week) that they fail during Exit. |
|
Whenever a problem seems to get worse the longer your program runs you should suspect a resource leak. If you've not already done so, monitor your program using Task Manager and check that none of the object counts (particularly Handles, USER Objects and GDI Objects) are gradually increasing.
Another thing I'd consider, when something fails only after some time, is the possible involvement of a virus scanner. Make sure there are no background scans taking place which could lock the files in your temporary directory.
Richard.
|
|
 Logged
|
|
|
|
19Grumpah42
Junior Member
member is offline
Gender: 
Posts: 57
|
|
Re: *.exe does not exit cleanly.
« Reply #16 on: Jan 5th, 2010, 01:46am » |
|
That's very instructional Michael, thanks.
I am not [yet!] creating files within a programme, so I note your ref. to @temp$ (new to me) for further use. The data files used by these programmes are all created elsewhere, they are just ASCII configuration files.
As I had mentioned earlier in the thread, the only files I am finding in the abandoned "temp" directories are BB4W *LIB.BBC files. Thus far I am using no .DLL files (don't really know how to, so I won't play with that!), so that is not the problem. Richard says that SYS "FreeLibrary" would not help for only .BBC libraries anyway, and he certainly knows.
I take firm note of your recommendation to use ON ERROR LOCAL. I wrote both these programmes over 2 months ago and because they have run (maybe not exit!) 24/7 ever since, I did not fuss with error trapping. Indeed my subsequent projects (what a grand word!) have blossomed with ON ERROR LOCALs (a sure testament to my poor programming skills ?) so I am appreciating their value in tricky situations. I will revisit both these app.s and take a closer look at the possibility of "silent errors". As a first stab, I need to ensure that not just PROC_IRQ_poll but all those called by it - as required by current flag(s) status - all have internal, customized ERROR trapping.
[I seem to be ending up with slightly more code to handle interrupts and errors than to actually do the job. Perhaps I just needed to get my head around that idea, start to design the interrupt and error trapping scheme *before* I design the working code].
This starts to sound like a productive approach, thanks. 
And I promise never to change @lib$ !
--Grahame
|
|
Logged
|
C-2-Q 3GB, C-2-Duo 2GB, both GeForce 9500 GT, WinXP sp3. Two Linux Ubuntu boxes (rock solid, lean and mean, but they won't run BB4W!).
|
|
|
|
