Hi all,
just another case of completely mad wndproc management, I guess.
LabView 4.01 16 bit does this:
Call GDI.70: ENUMFONTS(0x0e8c,0x00000000 #0000,0x026f32aa,0xffff0001) ret=026f:09c5
ds=0277
CallTo16(func=026f:32aa,ds=0277,0x009f,0x05dc,0x009f,0x058c,0x0001,0xffff,0x0001)
ss:sp=0277:4938
^^^^^^^^^ 1 2 3 4 5 6 7
CallTo16() ss:sp=0277:4938 retval=0x00000001
CallTo16(func=026f:32aa,ds=0277,0x009f,0x05dc,0x009f,0x058c,0x0001,0xffff,0x0001)
ss:sp=0277:4938
CallTo16() ss:sp=0277:4938 retval=0x00000001
.
.
.
Ret GDI.70: ENUMFONTS() retval=0x0001 ret=026f:09c5 ds=0277
And many lines later:
Call USER.118: REGISTERWINDOWMESSAGE(0x02d70000 "commdlg_FileNameOK") ret=026f:09c5
ds=0277
Ret USER.118: REGISTERWINDOWMESSAGE() retval=0xc023 ret=026f:09c5 ds=0277
Call WPROCS.149: INT_INT31HANDLER() ret=026f:33f0 ds=0277
AX=0007 BX=02d7 CX=416b DX=50e0 SI=17d9 DI=0001 ES=0277 EFL=00000212
Ret WPROCS.149: INT_INT31HANDLER() retval=none ret=026f:33f0 ds=0277
AX=0007 BX=02d7 CX=416b DX=50e0 SI=17d9 DI=0001 ES=0277 EFL=00000212
Call WPROCS.149: INT_INT31HANDLER() ret=026f:33f0 ds=0277
AX=0007 BX=02df CX=4130 DX=bd30 SI=17e2 DI=0002 ES=0277 EFL=00000297
Ret WPROCS.149: INT_INT31HANDLER() retval=none ret=026f:33f0 ds=0277
AX=0007 BX=02df CX=4130 DX=bd30 SI=17e2 DI=0002 ES=0277 EFL=00000296
Call KERNEL.95: LOADLIBRARY(0x02771230 "commdlg.dll") ret=026f:4a59 ds=0277
trace:relay:PE_InitDLL CallTo32(entryproc=0x4007d290,module=41700000,type=1,res=(nil))
Ret KERNEL.95: LOADLIBRARY() retval=0x0797 ret=026f:4a59 ds=0277
Call KERNEL.50: GETPROCADDRESS(0x0797,0277:48dc "GetOpenFileName") ret=026f:4a82
ds=0277
Ret KERNEL.50: GETPROCADDRESS() retval=0x078f00a0 ret=026f:4a82 ds=0277
Call COMMDLG.1: GETOPENFILENAME(0x02df0000) ret=026f:09c5 ds=0277
.
.
.
trace:relay:WINPROC_CallWndProc
(wndproc=FileOpenDlgProc16,hwnd=000004ac,msg=WM_SETTEXT,wp=00000000,lp=4105a834)
CallTo16(func=026f:32aa,ds=0277,0x04ac,0x000c,0x0000,0x009f,0x05b0) ss:sp=0277:48f2
^^^^^^^^^ 1 2 3 4 5
The parameter counts of wndproc 0x026f:0x32aa are different at the two places
where it gets invoked !!
EnumFonts callback: 7 WORDs.
FileOpenDlgProc16.WM_SETTEXT: 5 WORDs.
Guess what it does ?
It crashes !
But the strange thing is that it doesn't crash the first time the wndproc
gets invoked. It works many times.
Only when executing this part of FILEDLG_WMCommand() does it crash:
if (FILEDLG_HookCallChk(lpofn))
{
#if INSERTED_BY_ANDI
lRet= (BOOL16)FILEDLG_CallWindowProc(lpofn,
hWnd, RegisterWindowMessageA( FILEOKSTRING ), 0, lParam );
if (lRet)
{
*lpofn=ofn2; /* restore old state */
#if 0
ShowWindow16(hWnd, SW_SHOW); /* only if above (%%%) SW_HIDE
used */
#endif
break;
}
#endif
}
(already disabled that code here, of course !)
And it crashes like that:
CallTo16(func=026f:32aa,ds=0277,0x04ac,0xc023,0x0000,0x0002,0x08d4) ss:sp=0277:48f2
AX=0277 BX=0000 CX=0000 DX=0000 SI=0000 DI=0000 BP=491c ES=0277 FS=0000
Unhandled exception: priviledged instruction in 16-bit code (02b7:8df9d).
Loading symbols: /usr/local/src/wine/wine
In 32 bit mode.
Register dump:
CS:02b7 SS:02c7 DS:02bf ES:02bf FS:0002 GS:02bf
EIP:0008df9d ESP:0000a134 EBP:0000a684 EFLAGS:00010206( R- 00 I - -P1 )
EAX:000008d4 EBX:0008dc24 ECX:000048e2 EDX:00000002
ESI:00000000 EDI:000008d4
Stack dump:
0x02c7:0x0000a134: 00000001 00000002 00000000 00300528
0x02c7:0x0000a144: 0000a158 00258a7b 002c43c4 00312b40
0x02c7:0x0000a154: 00000000 0000a164 0023d2bf 00312b40
0x02c7:0x0000a164: 0000abcc 000c973c 00312b40 00000000
0x02c7:0x0000a174: 00000000 00000000 00000000 00000000
0x02c7:0x0000a184: 00000000 00000000 00000000 00000000
0x02c7:0x0000a194:
Backtrace:
=>0 0x02b7:0x0008df9d (ebp=0000a684)
Bad stack frame 0xf184
0x02b7:0x0008df9d: movl %fs:0x18(%eax),%eax
Wine-dbg>q
Note that EAX points to the last parameter (0x8d4) of the wndproc call instead
of a valid value !
This again seems to be in relay code:
Wine-dbg>disas 0x2b7:0x8df80
0x02b7:0x0008df80: subl 0x0(%eax),%eax
0x02b7:0x0008df82: jnz 0x0008e149 (+0x8dd57 [XF86VMode.c])
0x02b7:0x0008df88: xorl %esi,%esi
0x02b7:0x0008df8a: movl %edi,%eax
0x02b7:0x0008df8c: movl %eax,%edx
0x02b7:0x0008df8e: shrl $0x10,%edx
0x02b7:0x0008df91: andl $0xffff,%eax
0x02b7:0x0008df96: mov %dx,%fs
0x02b7:0x0008df98: movl %edx,0xffffffec(%ebp)
0x02b7:0x0008df9b: movl %eax,%edi
0x02b7:0x0008df9d: movl %fs:0x18(%eax),%eax
0x02b7:0x0008dfa1: movl %eax,%edx
0x02b7:0x0008dfa3: shrl $0x10,%edx
0x02b7:0x0008dfa6: andl $0xffff,%eax
0x02b7:0x0008dfab: mov %dx,%fs
0x02b7:0x0008dfad: movl %eax,%edx
0x02b7:0x0008dfaf: leal 0xfffffed0(%ebp),%eax
0x02b7:0x0008dfb5: movb %fs:0x0(%edx),%bl
0x02b7:0x0008dfb8: movb %bl,0x0(%eax)
0x02b7:0x0008dfba: incl %edx
0x02b7:0x0008dfbb: incl %eax
0x02b7:0x0008dfbc: testb %bl,%bl
0x02b7:0x0008dfbe: jnz 0x0008dfb5 (+0x8dbc3 [XF86VMode.c])
0x02b7:0x0008dfc0: mov 0xffffffec(%ebp),%fs
0x02b7:0x0008dfc3: movl %fs:0x2c(%edi),%eax
0x02b7:0x0008dfc7: movl %eax,%edx
0x02b7:0x0008dfc9: shrl $0x10,%edx
0x02b7:0x0008dfcc: andl $0xffff,%eax
0x02b7:0x0008dfd1: mov %dx,%fs
0x02b7:0x0008dfd3: movl %eax,%edx
(this looks familiar to me, so I guess that it is relay code)
So the whole thing seems to be evidence of broken parameter counts, no ?
Note that LabView itself calls
REGISTERWINDOWMESSAGE("commdlg_FileNameOK"/FILEOKSTRING);, too.
I don't think that that is related, though.
The question would be:
What to do about that problem ?
We need to secure our wndproc calls against such happenings, no ?
(I'm afraid this is exactly the Win16 counterpart of what I already
experienced with AIM)
Don't you just hate it...
--
Andreas Mohr Tel.: +49 7159 800604 private (preferred)
Stauferstr. 6 927883 main line (family)
D-71272 Renningen http://home.germany.net/100-30936/
Germany languages: german, english, french
