Discussion:
DrRexx causing a comple system freeze in SMP mode...
(too old to reply)
Dariusz Piatkowski
2011-02-18 03:37:38 UTC
Permalink
I'm helping to debug an application where on my particular system the said
application completely freezes the whole machine if more then a single CPU (1 of
a total of 4) is enabled. The application in question is a Dr.Rexx based app,
and the freeze occurs as I attempt to open up a separate dialogue window.

The app produces a 'soft freeze' in a sense that I can still reboot using
CAD...however, the WPS, clock, etc all stop working immediately.

To help with the dubugging efforts I started using a utility called OS2TRACE,
which allows me to turn on tracing for any of the APIs the program itself uses,
or the DLLs which the program calls may use.

With this application I have been able to narrow down the freeze to the
following series of calls:

=====================
...
0089 0001 | Win32DefWindowProc Entry at 22:02:46.01, Return Address = 0x00015BBF
(DRREXX 0001:00005BBF)
| Parameter 1: HWND = 0x80000061
| Parameter 2: ULONG = 0x00000070 (WM_MOUSEMOVE)
| Parameter 3: MPARAM = 0x0016000D
| Parameter 4: MPARAM = 0x00000000

0089 0001 | Win32DefWindowProc Exit at 22:02:46.01
| Return code: MRESULT = 0x00000000

0089 0001 | Win32DispatchMsg Exit at 22:02:46.01
| Return code: MRESULT = 0x00000000

0089 0001 | Win32GetMsg Entry at 22:02:46.01, Return Address = 0x0001148F
(DRREXX 0001:0000148F)
| Parameter 1: HAB = 0x00890001
| Parameter 2: PQMSG = 0x000460E4
| Parameter 3: HWND = 0x00000000
| Parameter 4: ULONG = 0x00000000
| Parameter 5: ULONG = 0x00000000

0089 0001 | Win32QueryWindowPtr Entry at 22:02:46.01, Return Address =
0x0001A88A (DRREXX 0001:0000A88A)

...
=====================

In particular it appears that for some reason the last call to
Win32QueryWindowPtr (issued by DRREXX) fails...in fact, this immediately causes
a crash so much so that the OS2TRACE utility does not even get a chance to log
the parameters being passed to the function. An example of a successfull
invocating of this API follows (this is from the trace of this very same
program):

=====================
0089 0001 | Win32QueryWindowPtr Entry at 22:02:46.01, Return Address =
0x0001A88A (DRREXX 0001:0000A88A)
| Parameter 1: HWND = 0x8000005B
| Parameter 2: LONG = 0x00000000

0089 0001 | Win32QueryWindowPtr Exit at 22:02:46.01
PASS | Return code: PVOID = 0x036D0F14
=====================

My question at this point in time is: how reliable/SMP-safe is Dr.Rexx? Is this
a known issue? Trying to find anything on Google these days is an excercise in
futility...LOL...
Lars Erdmann
2011-02-19 14:22:44 UTC
Permalink
This can be about anything. But I don't think that WinQueryWindowPtr is really the problem
(unless Dr.Rexx is buggy as hell). The only problem that I could think of where WinQueryWindowPtr
might miserably fail is if you indexed into a window word location where there was not enough
memory allocated for the window words on the WinRegisterClass call (where the window class is registered).

If it is about SMP only:
the DosSetThreadAffinity/DosQueryThreadAffinity API seems to be completely unrealiable.
Don't ask me why Dr. Rexx would use these API calls. What they do is force the current thread
(from where DosSetThreadAffinity is called) to be only allowed to execute on the CPUs
that are specified/query on which CPUs that current thread can execute (DosQueryThreadAffinity).
In any case, you can run "exehdr.exe /V" against the failing executable and see if they are imported:

DosSetThreadAffinity: DOSCALLS.564
DosQueryThreadAffinity: DOCALLS.563


Look here for all imports:
http://home.clara.net/orac/os2xref.htm


Maybe you find other imports that are "suspicious".



Lars
Post by Dariusz Piatkowski
I'm helping to debug an application where on my particular system the said
application completely freezes the whole machine if more then a single CPU (1 of
a total of 4) is enabled. The application in question is a Dr.Rexx based app,
and the freeze occurs as I attempt to open up a separate dialogue window.
The app produces a 'soft freeze' in a sense that I can still reboot using
CAD...however, the WPS, clock, etc all stop working immediately.
To help with the dubugging efforts I started using a utility called OS2TRACE,
which allows me to turn on tracing for any of the APIs the program itself uses,
or the DLLs which the program calls may use.
With this application I have been able to narrow down the freeze to the
=====================
...
0089 0001 | Win32DefWindowProc Entry at 22:02:46.01, Return Address = 0x00015BBF
(DRREXX 0001:00005BBF)
| Parameter 1: HWND = 0x80000061
| Parameter 2: ULONG = 0x00000070 (WM_MOUSEMOVE)
| Parameter 3: MPARAM = 0x0016000D
| Parameter 4: MPARAM = 0x00000000
0089 0001 | Win32DefWindowProc Exit at 22:02:46.01
| Return code: MRESULT = 0x00000000
0089 0001 | Win32DispatchMsg Exit at 22:02:46.01
| Return code: MRESULT = 0x00000000
0089 0001 | Win32GetMsg Entry at 22:02:46.01, Return Address = 0x0001148F
(DRREXX 0001:0000148F)
| Parameter 1: HAB = 0x00890001
| Parameter 2: PQMSG = 0x000460E4
| Parameter 3: HWND = 0x00000000
| Parameter 4: ULONG = 0x00000000
| Parameter 5: ULONG = 0x00000000
0089 0001 | Win32QueryWindowPtr Entry at 22:02:46.01, Return Address =
0x0001A88A (DRREXX 0001:0000A88A)
...
=====================
In particular it appears that for some reason the last call to
Win32QueryWindowPtr (issued by DRREXX) fails...in fact, this immediately causes
a crash so much so that the OS2TRACE utility does not even get a chance to log
the parameters being passed to the function. An example of a successfull
invocating of this API follows (this is from the trace of this very same
=====================
0089 0001 | Win32QueryWindowPtr Entry at 22:02:46.01, Return Address =
0x0001A88A (DRREXX 0001:0000A88A)
| Parameter 1: HWND = 0x8000005B
| Parameter 2: LONG = 0x00000000
0089 0001 | Win32QueryWindowPtr Exit at 22:02:46.01
PASS | Return code: PVOID = 0x036D0F14
=====================
My question at this point in time is: how reliable/SMP-safe is Dr.Rexx? Is this
a known issue? Trying to find anything on Google these days is an excercise in
futility...LOL...
Loading...