1. RE: Need help w/ call_back
Brian Broker wrote:
> So I'm working with a dll and I'm trying to wrap a function that
> requires a call_back() pointer. No problem here... when I trace my test
>
> program, I see that my callback function is being called and the
Brian:
Be sure that you are not assuming that some structure or
pointer value that the DLL is returning is remaining
in the same memory location and not being over written.
Remember that DLL's can be moved arounding in memory
by the operating system if they are written that way.
You may have to immediately have make a copy of any data
that is being returned before using it.
This may be what is causing the ramdom failure of the callback.
Bernie
2. RE: Need help w/ call_back
Bernie,
Thanks for the tip but I don't think that's my problem. At this point,
all I'm doing with my callback is printing the C_POINTER and C_INT's
being passed to it and I've verified that the input recieved is valid.
And when I'm tracing my program, I'm simply returning from the callback.
I just don't understand why returning from a callback would cause an
access violation. Any other idea's or suggestions are still very much
welcome.
Thanks,
- Brian
Bernie Ryan wrote:
>
> Brian Broker wrote:
> > So I'm working with a dll and I'm trying to wrap a function that
> > requires a call_back() pointer. No problem here... when I trace my test
> >
> >
> > program, I see that my callback function is being called and the
>
> Brian:
> Be sure that you are not assuming that some structure or
> pointer value that the DLL is returning is remaining
> in the same memory location and not being over written.
> Remember that DLL's can be moved arounding in memory
> by the operating system if they are written that way.
> You may have to immediately have make a copy of any data
> that is being returned before using it.
> This may be what is causing the ramdom failure of the callback.
>
> Bernie
>
>
3. RE: Need help w/ call_back
Brian Broker wrote:
> So I'm working with a dll and I'm trying to wrap a function that
> requires a call_back() pointer. No problem here... when I trace my
> test program, I see that my callback function is being called and
> the parameters being passed to it look OK but I'm getting an access
> violation (C0000005) when I return from the function. When I try a
> debug version of the dll, I can get through several iterations of
> my callback function before I start getting bad parameters and a
> crash.
>
> The dll shouldn't care what I return from the callback because it's
> a void function (it's actually a callback procedure...) Also, if I
> define my callback function with no input parameters, I don't get a
> crash (but this doesn't help me because I need the input parameters
> to do anything useful).
>
> Does anybody have any further suggestions to help me figure out
> what might be the problem? I've checked and double checked the
> obvious (declarations, etc.) and working with callback functions is
> not new to me. It's just that this particular one has got me
> stumped.
This sounds like the DLL is making a cdecl call, rather than stdcall. I
believe that in a cdecl call, the caller cleans up the stack, and the
callee cleans it up for stdcall. So by not looking at any arguments, Eu
allowed the dll to clean the stack, and all was good. When Eu cleans
the stack, the stack gets corrupted.
All may not be lost, however. I figured out how to call an Eu func from
ASM (all stdcall). It should be possible to change the ASM to accept a
cdecl call. Parameters are passed in memory to Eu.
If you take out lines #1C and #1E, you should be able to work with
cdecl.
-- Start code
constant
func_asm = {
#55, -- 0: push ebp
#89,#E5, -- 1: mov ebp, esp
#51, -- 3: push ecx
#B9,#00,#00,#00,#00, -- 4: mov ecx, argnum (5)
#89,#E6, -- 9: mov esi, esp
#83,#C6,#0C, -- B: add esi, 12
#BF,#00,#00,#00,#00, -- E: mov edi, myargs (15)
#F3,#A5, -- 13: rep movsd; next we call the proc
#FF,#15,#00,#00,#00,#00,-- 15: call dword ptr [pfunc] (#17)
#59, -- 1B: pop ecx
#89,#EC, -- 1C: mov esp, ebp
#5D, -- 1E: pop ebp
#C2,#00,#00,#00,#00} -- 1F: ret [argnum] (#20)
constant offset = length( func_asm )
global function new_pfunc( atom callback, integer args )
atom func_addr, func_retval, func_pfunc, func_args
func_addr = allocate( length(func_asm) + 4 * 12 )
poke( func_addr, func_asm )
func_retval = func_addr + offset
func_pfunc = func_retval + 4
func_args = func_pfunc + 4
poke4( func_addr + #05, args )
poke4( func_addr + #0F, func_args )
poke4( func_addr + #17, func_pfunc )
poke4( func_addr + #20, ( args + 0 ) * 4 )
poke4( func_pfunc, callback )
return { func_addr, func_args }
end function
-- End code
function my_callback( atom arg1, atom arg2 )
...
end function
constant my_callback_callback = call_back( routine_id("my_callback"))
becomes:
atom args_ptr, my_callback_callback
sequence pfunc
function my_callback()
atom arg1, arg2
arg1 = peek4s( args_ptr )
arg2 = peek4s( args_ptr + 4 )
...
end function
pfunc = new_pfunc( call_back(routine_id("my_callback")), 2 )
my_callback_callback = pfunc[1]
args_ptr = pfunc[2]
Then pass my_callback_callback to the dll to call the Eu func via ASM.
You might have to play around with the ASM, but I think what I proposed
should work. You can also use this method to have a call_back with more
args than are allowed (8 in 2.2, 9 in 2.3).
Matt Lewis
4. RE: Need help w/ call_back
Holy cow... what a pain in the butt! I'll give it a go but if anybody
knows of a less complicated solution, please tell me before I'm knee
deep...
Thanks Matt,
-- Brian
Matthew Lewis wrote:
> This sounds like the DLL is making a cdecl call, rather than stdcall. I
>
> believe that in a cdecl call, the caller cleans up the stack, and the
> callee cleans it up for stdcall. So by not looking at any arguments, Eu
>
> allowed the dll to clean the stack, and all was good. When Eu cleans
> the stack, the stack gets corrupted.
>
> All may not be lost, however. I figured out how to call an Eu func from
>
> ASM (all stdcall). It should be possible to change the ASM to accept a
> cdecl call. Parameters are passed in memory to Eu.
>
> If you take out lines #1C and #1E, you should be able to work with
> cdecl.
>
> -- Start code
> <snip>
