Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[rt.cpan.org #84268] Win32::API: Bug/Exception in call_asm_x86_msvc.asm
35 views
Skip to first unread message
Daniel Dragan via RT
Mar 28, 2013, 3:58:58 PM3/28/13
to libw...@perl.org
Thu Mar 28 15:58:57 2013: Request 84268 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeu...@allgeier.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >
On Thu Mar 28 13:42:02 2013, rkeu...@allgeier.com wrote:
> I get an exception in call_asm_x86_msvc.asm, raised at bad_esp.
> ESP
> and EBP do not match.
Your prototype is wrong. Either the func in the DLL is actually __cdecl because it doesn't explicitly say __stdcall or WINAPI in each declaration and wasn't compiled with -Gz and the default in Win32::API is always __stdcall unless specified otherwise (this is the opposite of Visual C and GCC's defaults), or it is a __stdcall which takes a different amount of args than you specified in the prototype string.
>
> Using the C version works. Why is the ASM-
> Version the default for MSVC?
>
The inline assembly version was very inefficient compared to the ideal design, the inline assembly version copied the same data between memory and register 2-4 times redundantly before writing it to memory for the final time, also the call instruction appears 3 different times (but called only once) in the inline assembly version instead of once. The C version (still used with GCC) doesn't compare ESP to EBP to find wrong prototypes yet (not sure if the C version ever will).
> I compiled a fresh perl for
> testing and debugging this.
> The called DLL is also built with MSVC
> 16 and uses WINAPI calling convention.
Are you sure?
>
> The signature is:
> Win32::API->Import("svapi32_vc100.dll", 'ULONG
> svapi_connect(LPVOID hsv,LPSTR s1,LPSTR s2,LPSTR s3,LPSTR s4,LPSTR
> s5,LPSTR s6,LPSTR s7,LPSTR s8,LPSTR s9, LPSTR s10)');
The above is probably a __cdecl in the DLL since __stdcall isn't specified anywhere and -Gr and -Gz weren't used (-Gd wasn't used either, but it is on by default). I made a test function below to try your prototype.
_______________________________________________
API_TEST_API ULONG svapi_connect(LPVOID hsv,LPSTR s1,LPSTR s2,LPSTR s3,
LPSTR s4,LPSTR s5,LPSTR s6,LPSTR s7,LPSTR s8,LPSTR s9, LPSTR s10) {
if(hsv == 0x0
&& atoi(s1) == 1
&& atoi(s2) == 2
&& atoi(s3) == 3
&& atoi(s4) == 4
&& atoi(s5) == 5
&& atoi(s6) == 6
&& atoi(s7) == 7
&& atoi(s8) == 8
&& atoi(s9) == 9
&& atoi(s10) == 10)
return 2;
else{
DebugBreak();
return 0;
}
}
___________________________________________________
this is fine, notice I changed the 1st parameter from LPVOID to ULONG (LPVOID is a char * in Win32::API, not an opaque pointer as normally thought of LPVOID)
_______________________________________________
use Win32::API;
Win32::API->Import("api_test.dll", 'ULONG __cdecl svapi_connect(ULONG '
.'hsv,LPSTR s1,LPSTR s2,LPSTR s3,LPSTR s4,LPSTR s5,LPSTR s6,LPSTR s7,LPSTR s8,'
.'LPSTR s9, LPSTR s10)');
die "bad return" if svapi_connect(0..10) != 2;
_______________________________________________
This causes "Unhandled exception at 0x7c812afb in perl.exe: 0xC0000028: An invalid or unaligned stack was encountered during an unwind operation." with 0.76_01.
_______________________________________________
use Win32::API;
Win32::API->Import("api_test.dll", 'ULONG svapi_connect(ULONG '
.'hsv,LPSTR s1,LPSTR s2,LPSTR s3,LPSTR s4,LPSTR s5,LPSTR s6,LPSTR s7,LPSTR s8,'
.'LPSTR s9, LPSTR s10)');
die "bad return" if svapi_connect(0..10) != 2;
_______________________________________________
I plan to change the RaiseException to a Perl catchable croak based on the opinions in http://perlmonks.org/?node_id=1024423 in a future 0.76_02. Also I might switch the RaiseException to a DebugBreak since RaiseException uses alot of C autos and changes esp/ebp alot (but ebp sort of points to the incoming args to RaiseException from Call_asm). Do you have another opinion of what to do when there is a prototype mistake?
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeu...@allgeier.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >
On Thu Mar 28 13:42:02 2013, rkeu...@allgeier.com wrote:
> I get an exception in call_asm_x86_msvc.asm, raised at bad_esp.
> ESP
> and EBP do not match.
Your prototype is wrong. Either the func in the DLL is actually __cdecl because it doesn't explicitly say __stdcall or WINAPI in each declaration and wasn't compiled with -Gz and the default in Win32::API is always __stdcall unless specified otherwise (this is the opposite of Visual C and GCC's defaults), or it is a __stdcall which takes a different amount of args than you specified in the prototype string.
>
> Using the C version works. Why is the ASM-
> Version the default for MSVC?
>
The inline assembly version was very inefficient compared to the ideal design, the inline assembly version copied the same data between memory and register 2-4 times redundantly before writing it to memory for the final time, also the call instruction appears 3 different times (but called only once) in the inline assembly version instead of once. The C version (still used with GCC) doesn't compare ESP to EBP to find wrong prototypes yet (not sure if the C version ever will).
> I compiled a fresh perl for
> testing and debugging this.
> The called DLL is also built with MSVC
> 16 and uses WINAPI calling convention.
Are you sure?
>
> The signature is:
> Win32::API->Import("svapi32_vc100.dll", 'ULONG
> svapi_connect(LPVOID hsv,LPSTR s1,LPSTR s2,LPSTR s3,LPSTR s4,LPSTR
> s5,LPSTR s6,LPSTR s7,LPSTR s8,LPSTR s9, LPSTR s10)');
The above is probably a __cdecl in the DLL since __stdcall isn't specified anywhere and -Gr and -Gz weren't used (-Gd wasn't used either, but it is on by default). I made a test function below to try your prototype.
_______________________________________________
API_TEST_API ULONG svapi_connect(LPVOID hsv,LPSTR s1,LPSTR s2,LPSTR s3,
LPSTR s4,LPSTR s5,LPSTR s6,LPSTR s7,LPSTR s8,LPSTR s9, LPSTR s10) {
if(hsv == 0x0
&& atoi(s1) == 1
&& atoi(s2) == 2
&& atoi(s3) == 3
&& atoi(s4) == 4
&& atoi(s5) == 5
&& atoi(s6) == 6
&& atoi(s7) == 7
&& atoi(s8) == 8
&& atoi(s9) == 9
&& atoi(s10) == 10)
return 2;
else{
DebugBreak();
return 0;
}
}
___________________________________________________
this is fine, notice I changed the 1st parameter from LPVOID to ULONG (LPVOID is a char * in Win32::API, not an opaque pointer as normally thought of LPVOID)
_______________________________________________
use Win32::API;
Win32::API->Import("api_test.dll", 'ULONG __cdecl svapi_connect(ULONG '
.'hsv,LPSTR s1,LPSTR s2,LPSTR s3,LPSTR s4,LPSTR s5,LPSTR s6,LPSTR s7,LPSTR s8,'
.'LPSTR s9, LPSTR s10)');
die "bad return" if svapi_connect(0..10) != 2;
_______________________________________________
This causes "Unhandled exception at 0x7c812afb in perl.exe: 0xC0000028: An invalid or unaligned stack was encountered during an unwind operation." with 0.76_01.
_______________________________________________
use Win32::API;
Win32::API->Import("api_test.dll", 'ULONG svapi_connect(ULONG '
.'hsv,LPSTR s1,LPSTR s2,LPSTR s3,LPSTR s4,LPSTR s5,LPSTR s6,LPSTR s7,LPSTR s8,'
.'LPSTR s9, LPSTR s10)');
die "bad return" if svapi_connect(0..10) != 2;
_______________________________________________
I plan to change the RaiseException to a Perl catchable croak based on the opinions in http://perlmonks.org/?node_id=1024423 in a future 0.76_02. Also I might switch the RaiseException to a DebugBreak since RaiseException uses alot of C autos and changes esp/ebp alot (but ebp sort of points to the incoming args to RaiseException from Call_asm). Do you have another opinion of what to do when there is a prototype mistake?
Daniel Dragan via RT
Mar 28, 2013, 5:42:03 PM3/28/13
to libw...@perl.org
Thu Mar 28 17:42:02 2013: Request 84268 was acted upon.
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >
On Thu Mar 28 17:11:32 2013, rkeu...@allgeier.com wrote:
> It's really stdcall. Sorry, I should have checked this..
Then why does it crash for you if it really is stdcall?
>
> Maybe I
> was biased because it worked in my old 5.14 ActiveState-Perl, which
> probably used the C version of "call" or an old asm version.
Previous versions of Win32::API as far as I remember, didn't care if it was __cdecl or __stdcall, original esp from the XSUB is copied back in asm, "esp = *(void **)ebp; ebp = *(void **)esp; esp -= 4;" AKA "leave" or "mov esp, [ebp]; pop esp", so what the called C func left esp at was actually irrelevant (it can be esp == 0, and Call_asm didn't care).
>
> I
> recompiled Win32::API for getting WriteMemory(), which was missing
> in the AS build.
OT: "unpack('P'," can read any memory, but you can't write to random memory from core Perl. The undocumented RtlMoveMemory in kernel32.dll in old Win32::APIs (0.68 and older) had to be cludgingly used before. Internet grapevine says RtlMoveMemory exists for VB Classic programmers to use. So I added a WriteMemory so that foreign memory allocators can more easily be used (some C func wants a LocalAlloc memory block to take ownership of and free when it wants, not malloc or Newx (PV buffer)).
>
> And others also use the DLL from C# so I
> thought it would be stdcall..
>
>
> unsigned int __cdecl
> svapi_connect(...)
>
> push ebp
> mov ebp, esp
> push
> 0FFFFFFFEh
> push offset stru_1006F560
> push offset
> __except_handler4
> mov eax, large fs:0
> push eax
> add
> esp, 0FFFFFF68h
> mov eax, ___security_cookie
> xor
> [ebp+ms_exc.registration.ScopeTable], eax
> xor eax, ebp
> mov
> [ebp+var_24], eax
> push ebx
> push esi
> push edi
> push
> eax
> lea eax, [ebp+ms_exc.registration]
> mov large fs:0,
> eax
> mov [ebp+ms_exc.old_esp], esp
>
> ...
>
> mov ecx,
> [ebp+ms_exc.registration.Next]
> mov large fs:0, ecx
> pop
> ecx
> pop edi
> pop esi
> pop ebx
> mov ecx,
> [ebp+var_24]
> xor ecx, ebp ; cookie
> call
> @__security_check_cookie@4 ; __security_check_cookie(x)
> mov
> esp, ebp
> pop ebp
> retn
>
This is a __cdecl function, "retn" would have a number after it if was a __stdcall.
>
> > I plan to change the
> RaiseException to a Perl catchable croak based on the opinions in
> http://perlmonks.org/?node_id=1024423 in a future 0.76_02. Also >
> I might switch the RaiseException to a DebugBreak since
> RaiseException uses alot of C autos and changes esp/ebp alot (but
> ebp sort of points to the
> > incoming args to RaiseException from
> Call_asm).
>
> > Do you have another opinion of what to do when
> there is a prototype mistake?
>
> Yes, a DebugBreak() woud be nice
> to find the reg mismatch, but most people i.e. using an
> ActiveState-Build of Perl
> would not have debug syms.
You can sort-of, barely really, figure it out by just going to memory watch window, put "esp" as the address, set view to "4 byte integers" then do mental arthmitic (I think) to put back esp 4 bytes back (return address from DebugBreak()).
>
> Maybe do
> the DebugBreak() when IsDebuggerPresent() is true, else use croak.
> You could call IsDebuggerPresent() when api.dll is loaded.
> Thanks for your help and your work!
>
I like that idea, I forgot IsDebuggerPresent exists. Thanks for the idea.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeu...@allgeier.com
Status: open
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeu...@allgeier.com
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >
On Thu Mar 28 17:11:32 2013, rkeu...@allgeier.com wrote:
> It's really stdcall. Sorry, I should have checked this..
Then why does it crash for you if it really is stdcall?
>
> Maybe I
> was biased because it worked in my old 5.14 ActiveState-Perl, which
> probably used the C version of "call" or an old asm version.
Previous versions of Win32::API as far as I remember, didn't care if it was __cdecl or __stdcall, original esp from the XSUB is copied back in asm, "esp = *(void **)ebp; ebp = *(void **)esp; esp -= 4;" AKA "leave" or "mov esp, [ebp]; pop esp", so what the called C func left esp at was actually irrelevant (it can be esp == 0, and Call_asm didn't care).
>
> I
> recompiled Win32::API for getting WriteMemory(), which was missing
> in the AS build.
OT: "unpack('P'," can read any memory, but you can't write to random memory from core Perl. The undocumented RtlMoveMemory in kernel32.dll in old Win32::APIs (0.68 and older) had to be cludgingly used before. Internet grapevine says RtlMoveMemory exists for VB Classic programmers to use. So I added a WriteMemory so that foreign memory allocators can more easily be used (some C func wants a LocalAlloc memory block to take ownership of and free when it wants, not malloc or Newx (PV buffer)).
>
> And others also use the DLL from C# so I
> thought it would be stdcall..
>
>
> unsigned int __cdecl
> svapi_connect(...)
>
> push ebp
> mov ebp, esp
> push
> 0FFFFFFFEh
> push offset stru_1006F560
> push offset
> __except_handler4
> mov eax, large fs:0
> push eax
> add
> esp, 0FFFFFF68h
> mov eax, ___security_cookie
> xor
> [ebp+ms_exc.registration.ScopeTable], eax
> xor eax, ebp
> mov
> [ebp+var_24], eax
> push ebx
> push esi
> push edi
> push
> eax
> lea eax, [ebp+ms_exc.registration]
> mov large fs:0,
> eax
> mov [ebp+ms_exc.old_esp], esp
>
> ...
>
> mov ecx,
> [ebp+ms_exc.registration.Next]
> mov large fs:0, ecx
> pop
> ecx
> pop edi
> pop esi
> pop ebx
> mov ecx,
> [ebp+var_24]
> xor ecx, ebp ; cookie
> call
> @__security_check_cookie@4 ; __security_check_cookie(x)
> mov
> esp, ebp
> pop ebp
> retn
>
This is a __cdecl function, "retn" would have a number after it if was a __stdcall.
>
> > I plan to change the
> RaiseException to a Perl catchable croak based on the opinions in
> http://perlmonks.org/?node_id=1024423 in a future 0.76_02. Also >
> I might switch the RaiseException to a DebugBreak since
> RaiseException uses alot of C autos and changes esp/ebp alot (but
> ebp sort of points to the
> > incoming args to RaiseException from
> Call_asm).
>
> > Do you have another opinion of what to do when
> there is a prototype mistake?
>
> to find the reg mismatch, but most people i.e. using an
> ActiveState-Build of Perl
> would not have debug syms.
You can sort-of, barely really, figure it out by just going to memory watch window, put "esp" as the address, set view to "4 byte integers" then do mental arthmitic (I think) to put back esp 4 bytes back (return address from DebugBreak()).
>
> Maybe do
> the DebugBreak() when IsDebuggerPresent() is true, else use croak.
> You could call IsDebuggerPresent() when api.dll is loaded.
> Thanks for your help and your work!
>
I like that idea, I forgot IsDebuggerPresent exists. Thanks for the idea.
Daniel Dragan via RT
Mar 29, 2013, 12:35:43 AM3/29/13
to libw...@perl.org
Fri Mar 29 00:35:42 2013: Request 84268 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeu...@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >
On Thu Mar 28 17:11:32 2013, rkeu...@allgeier.com wrote:
> It's really stdcall. Sorry, I should have checked this..
>
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeu...@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >
On Thu Mar 28 17:11:32 2013, rkeu...@allgeier.com wrote:
> It's really stdcall. Sorry, I should have checked this..
>
> Maybe I
> was biased because it worked in my old 5.14 ActiveState-Perl, which
> probably used the C version of "call" or an old asm version.
>
> was biased because it worked in my old 5.14 ActiveState-Perl, which
> probably used the C version of "call" or an old asm version.
>
> I
> recompiled Win32::API for getting WriteMemory(), which was missing
> in the AS build.
If you are the same Rainer Keuchel as in http://tech.groups.yahoo.com/group/wince-devel/message/459 , could you provide/attach what was in http://www.rainer-keuchel.de/wince/perl-win32-api.tar.gz ? I'd like to integrate what was in there (ARM support) into the official Win32::API.
> recompiled Win32::API for getting WriteMemory(), which was missing
> in the AS build.
Daniel Dragan via RT
Apr 9, 2013, 1:09:14 AM4/9/13
to libw...@perl.org
Tue Apr 09 01:09:13 2013: Request 84268 was acted upon.
> Here is the old code.. Unfortunatly there is no assembly magic. It
> just calls several functions with different numbers of args from 1
> to 10.
>
Thank you for the ARM code. Are you still having x86/x64 Win32::API problems or can I close the ticket?
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeu...@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >
On Fri Mar 29 06:24:29 2013, keu...@rainer-keuchel.de wrote:
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeu...@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >
> Here is the old code.. Unfortunatly there is no assembly magic. It
> just calls several functions with different numbers of args from 1
> to 10.
>
Thank you for the ARM code. Are you still having x86/x64 Win32::API problems or can I close the ticket?
Daniel Dragan via RT
Apr 9, 2013, 10:28:45 PM4/9/13
to libw...@perl.org
Tue Apr 09 22:28:45 2013: Request 84268 was acted upon.
Transaction: Correspondence added by BULKDD
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeu...@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >
Closed.
Queue: Win32-API
Subject: Win32::API: Bug/Exception in call_asm_x86_msvc.asm
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: rkeu...@allgeier.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84268 >
0 new messages