forums.silverfrost.com

[sparge]

The ability to run an exe that is /CHECKMATE where it counts, and not where it doesn't, is very welcome. It has already exposed a potential problem with my code that I was not aware of. I've been thinking hard about it, and have taken some steps to manage it, but I'm left feeling that more needs to be done on the Salford Software side.

The problem arises from use of the "delayed auto-recall" format code, in code that is run under control of SDBG. It was highlighted by a programming practice, that I have evolved in the last couple of years, of maintaining a rudimentary "call stack" - an allocatable array of routine names. Most routines in my code push their name onto this stack on entry and pops it off before returning (there are obvious exceptions, like the routines that do the pushing ang the popping). The idea is to be able to provide a basic traceback when a program error occurs, and has served me well.

I was using %dl in my code to fire off some routines at an interval of 5 minutes, but I had reduced this interval to 1 minute to stir things up, because some occasional, particularly incomprehensible and unreproducible errors had led me to suspect a problem with those routines. What I found was that %dl was not respecting modal dialogues or debugger breakpoints. With a modal dialogue posted, or with the code paused in the debugger, if %dl triggers, it goes right ahead and executes its payload.

The ultimate sign of deep trouble, which I have still not managed to understand properly, is that from time to time the debugger will halt execution, reporting "ALLOCATEable object has already been ALLOCATEd". The line in question is in push_name, the routine that pushes another routine name onto the call stack (I'm not using a linked list, so I have to allocate a call stack buffer, copy the old one to it, deallocate and reallocate the call stack and then deallocate the buffer). As far as I can see, the only way the error makes sense is if push_name is getting called a second time, as a result of %dl invoking its payload, before it finishes executing an earlier call.

According to the manual, "A call is made at idle time (e.g. awaiting input) and when yield_program_control@ is called". I would count both of the situations I am talking about as situations where the program is awaiting input - in that sense, %dl is doing "exactly what it says on the tin". But I would not count them as situations where it is legitimate for %dl to be doing its thing. The debugger case is more debatable, but the modal dialogue case seems to me to be black and white - there would be nothing to stop a program re-calling a routine that is already executing and awaiting input, and making arbitray changes behind the scenes. This surely has to be wrong, as I hope the following code snippet demonstrates:

program auto_tistic
use callbacks
count = 0
choosing = 0
iomain = winio@ ('%dl', 5.0d-1, loose_cannon)
end program auto_tistic

module callbacks
integer count, but1, but2, choosing
contains
integer function loose_cannon ()
loose_cannon = 2
count = count + 1
but1 = mod (count, 2)
but2 = mod (count + 1, 2)
call window_update@ (but1)
call window_update@ (but2)
if (choosing .eq. 1) return
iodial = winio@ ('Choose me quick!%2nl&')
iodial = winio@ ('%rb[Me?]%nl&', but1)
iodial = winio@ ('%rb[Or me?]&', but2)
iodial = winio@ ('%sc&', 'SET', choosing, 1)
iodial = winio@ ('%2nl%cn%bt[OK]')
loose_cannon = 0
return
end function loose_cannon
end module callbacks

[PaulLaidler]

Andy

I am not sure that I can help very much with these issues but here are one or two comments.

We do not claim that SDBG is an effective debugging tool for ClearWin+ programs.
The recommended way to debug ClearWin+ programs is to use PRINT statements to an output window or to use a dumb terminal or an equivalent auxilliary output window. Any debugging that you can do using SDBG is a free bonus.

%dl uses SetTimer and WM_TIMER messages in the Windows message queue. So the comments in the help file (about idle time and yield_program_control@) are not accurate. The %dl callback will be called in response to a WM_TIMER message. This will appear in the message queue at the appointed time and there is no requirement to wait for an idle state. Your program will process the message queue when you call yield_program_control@ or when ClearWin+ implicitly calls this routine for you. If your program is doing any serious number crunching, then you should call yield_program_control@ within this part of the code if you want to allow the message queue (and in particular WM_TIMER) to be processed.