Rick, When you get a chance could you take a look at this problem. I'm going to send you a zip file with some stack traces and a test program.
This is related to / similar to the problem we were discussing a week or so ago. Similar in that it has to do with the C++ API and using AttachThread() to be able to directly invoke Rexx methods from the window procedure function (RexxDlgProc) rather than using the 'message queue' as ooDialog was doing. There are several things going on here, so bear with me a bit. 1.) The behavior on 64-bit Windows and 32-bit Windows is markedly different. (The reason you couldn't get my other test program to produce what I saw. As soon as I ran that program on a 32-bit system - it worked fine for me too.) The test program I'm sending now demonstrates the problem on a 32-bit system. 2.) A key problem is that window procedures are re-entrant, something I knew but was not thinking about. What's happening is, a message comes into RexxDlgProc(), the thread context is used for various API calls, at some point when an API call has to wait to get the kernel access, or since there are are several threads going, the thread context activity needs wait its turn to run, we end up in the waitHandle() function in SysSemaphore.hpp running on the RexxDlgProc() thread. During PeekMessage(), the Windows kernel delivers non-queued messages to the windows belonging to the thread by directly invoking the window procedure. So, while the thread context is waiting, RexxDlgProc() gets invoked again, before the processing of the first RexxDlgProc() is finished, (it's at waitHandle().) What you see from the application side is that the dialog stops responding and the program is hung. However, ctrl-c breaks out of the running Rexx program. There is one stack trace, show.rick.64bit, that shows this very clearly if you go to the bottom of the stack and work to the top. I have some ideas about this, but I wanted you to take a look at it first, because ... 3.) When I use the debugger to attach to the process and break into it, the call stacks for the threads look corrupted to me. So, I'm wondering if there is a second problem here. The test program works with the current stuff committed to trunk. It has one control in a dialog, a date time control. When you click on the control and then click on a spot in the dialog, some call back fields in the control get updated. When you do that several times in a row, suddenly the date time field goes blank and at that point the dialog is hung. I've been just using the debugger at this point to attach to the program and look at things. I haven't been running the program under the debugger, but the couple times I did I saw the same thing. -- Mark Miesfeld ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
