A mystery crash (when using TextArray)

My tester (and I) both have gotten this kind of error message. The link to the image is: https://drive.google.com/file/d/0B5fbkRqVCqoMQTBFdkVOaHBoS00/view?usp=sharing

There is no additional traceback available to indicate where in my source the error originated.

I have had this occur only in /CHECKMATE.

[u:fce85e230b]Correction: My tester confirms this occurred with the RELEASE version as well.[/u:fce85e230b]

If I change the stack/heap sizes, I can get this problem to 'move', meaning it will disappear from one spot only to show up (maybe) some time later in a spot that had been thoroughly tested clean before.

Sometimes, simply removing a line of code (that really needs to be there eventually) will cause the error to disappear; sometimes, not.

I am using TextArray extensively; perhaps that is a clue or hint. But, the TextArray window does not show when this error occurs. It is sometime before the window is shown. Without a decent traceback, I am at a loss to determine what I am doing that changing stack/heap sizes causes thing to work or not.

This failure in TextArrayAW looks like one that has been posted elsewhere on this forum.

Is it possible to send me the program so that I can trace the fault at source? If it can be shortened even better but in this case I could use the whole of the source code if it can be released to me.

Paul, I'd be happy to share the entirety of the code with you, but it's about 36K executable lines long. I can send you, as a ZIPped file, the code and the GNUMAKE build. The issue might be tracking down through the menus created with TextArray in order to cause the problem. If this will be in anyway helpful to you, I'm happy to comply!

As of this writing, my tester informs me that the problem has gone away. Unfortunately, I was never able to replicate the error he saw, and as we are changing code due to actual bugs/deficiencies, I did not save the version(s) that cause him to fail. He's not a professional tester, and did not let me know the date/time of the builds that caused the problems either. My mistake as well to not archive each version created/shipped to him. Which I am correcting by saving versions of what I send him from now on!

With that said, on a version that I simply relinked with the following change, the problem disappeared (or possibly moved somewhere else). By changing the heap and stack allocation in SLINK from the default to /heap:3145728,3145728 /stack:157286400,157286400, the problem has gone away disappeared.

Let me know what would be most helpful, and I'll do it!

I wonder if I should re-work the code so that the Text Array window remains open, rather than close and re-open a new window each time the user says 'Yeah, go ahead and process this'.

I'm still unsure about how to handle the asynchronous events (keyboard and mouse) in a logical way, but it might prevent the problem from occurring randomly/sporadically.

Are there downsides to leaving such a window open for the duration of the task? Anything in ClearWin+ that cannot happen while the window is open?

I'm thinking probably not, but wanted to ask the question.

I think that will probably solve the problem. I had not realised that the window was temporary.

The failure might well arise because ClearWin+ is trying to use a window that has already been closed. It is all to do with timing and message queues.

I have added code to ClearWin+ in this context in order to make it more robust and hopefully to avoid problems of this kind.

More often than not this kind of problem arises from the programmer's code because a %lw control variable (for example) has gone out of scope (i.e. it may need to have the SAVE attribute or its equivalent).

Paul, thanks for the comments here. I'd not though of a collision, but should have.

When doing some WINAPI programming in the past, I ran into timing/queue issues (lots of time when closing a window but DESTROY had already been called (asynchronously) to the desired close event. Sigh.

My tester told me just yesterday that, following the close of the window, the desired task had been completed, then this fatal error occurred. So it was either as a result of data being changed, or a new window being drawn (the buffers are always common). Sometimes the amount of time before the close of the window until it is re-opened with new data is quite short (sometimes just a few milliseconds). It is possible that a resource used by the previous window is being re-used by the new window, and this is causing a fatal 'collision'.

I am working on the more permanent fix/workaround and will post the results here once we have a lot of testing to confirm success (or failure!).

I'm thinking I need some guidance.

I'm using TextArray to simulate a previous data entry system. Other than this crash, the system is working very well. However, my first attempts to eliminate the successive open window/destroy window/open window/... sequencing as the user transitions from one menu to another have run into a snag.

I have used %lw to allow the program to run while the TextArray window has been created.

I have my regular keyboard monitor attached to the window. I get to the point where the user is to enter data. At this point, the window is open, presented, and is filled. In the older scheme, I was able to just wait on the window being closed to know that the user was done with entry. Now, it's not clear how to wait effectively and still have Windows and ClearWin+ lightly coexist, waiting for keyboard input. I have tried sleep1@ wait loops, but the CPU usage is still at max (just like it is in a hard loop) waiting on a semaphore variable to become 'set' signalling that the input phase is over.

Or, should I revert, removing the callback keyboard monitor function, and resort to waiting on the user to enter data and use get_wkey@()?

I am trying different approaches, but the experience that one of you might have in leaving a window open and processing keyboard and mouse inputs would be most helpful.

Bill

UPDATE: I reworked the code to keep the TextArray window up at all times, and use semaphores to control its behavior. The performance (i.e. no crashing) has improved to the point where it has not crashed in the last two weeks since implementing the changes.

I am using the SLEEP@ call to delay for a moment then sample the keyboard buffer and process any mouse actions. The processor usage (on a single core) runs at 100%, but all the other processes run just fine, so the release of the processor is certainly working as advertised. On my 4 core processor, one core runs at 100% , but again, there is no discernible effect on overall system responsiveness.

The biggest deal is: The lack of crashing at random places on different machines (or not at all) has disappeared.

Side benefit: To the user, it looks a lot like the previous DOS implementation where a TTY emulator (ANSI.SYS) screen would clear and new data is presented. This is good; visually more pleasing with no disappearing windows, and I don't have to keep track of where the user has put the window after each screen of data is completed!

I was able to finally get the CPU load down below 100% by implementing the following code in the loop that waits to be told the user has completed their inputs:

	  call temporary_yield@()
	  CALL SLEEP1@(20./182.) ! about two ticks

Before, when I had used SLEEP1@ alone the program was unresponsive, so I switched to SLEEP@. This is a much more elegant solution.

CPU load for the single CPU running under Win2K is now <<5%.