On Tuesday 15 October 2002 10:53 am, Ove Kaaven wrote:
On Mon, 14 Oct 2002, Greg Turner wrote:
well, that sounds about right, but how to detect such a thing...? I guess I need to learn how to create 'on change some ram' breakpoints,
That's called "watchpoints". In gdb, you can set such a watchpoint with: watch *(int*)0xaddress
not to mention track down these datastructures in memory (or perhaps learn how to get debug symbols for w32-native-compiled stuff generated).
Well you can just use the pointer given to NdrClientCall2, right?
yes, but by then it's too late; besides, by the time we're in NdrClientCall2, I no longer trust anything I see. To pursue this, I need to snag it as early as possible. I was able to produce a .pdb file using the compiler. Winedbg loads it but still no dice. I'd almost rather just get to the raw data than worry about debug symbols in this case. I can put some magic numbers in there and grep the various allocated memory places, to generate some nice re-usable offsets. Anyhow, if it's a calling convention problem as discussed below, then presumably I would find no memory corruption, so I will look into that first.
Serveral differences worth noting:
o Many more dlls loaded in the winelib version (why?)
Perhaps you have lots of unneeded import statements in your Winelib app's .spec file.
that sounds right. winemaker seemed to generate a lot of superflous deps (and failed to generate the rpcrt4 one).
My theories:
o it's the try/except macros; they're causing stack corruption or something (they occur right before the NdrClientCall2) o it's MIDL_user_allocate somehow (nah) o it's a problem with dll loading (lets hope not)
o it's a calling convention problem (stdcall/cdecl, argument count, return value). This theory is substantiated by the difference in the pFormat argument. Perhaps gcc wants to return the CLIENT_CALL_RETURN structure in a way that isn't compatible with what Microsoft compilers expect (wants stack space reserved for it by the caller or something?)... I think we've had issues with gcc and returning structures before. If this is it, rpcrt4 probably need to return it as just LONG_PTR in the code, not CLIENT_CALL_RETURN?
I like this theory, it has recently occured to me too. I will try compiling the sample using stdcall and see if that has an effect, after work. Also, in the winelib version, I changed main() to stdcall from cdecl (!) which I took to mean that winelib framework didn't want that calling convention.
As for fixing it... this may be a bit beyond me; but I'll look into what you reccomend. If gcc and msvc use incompatible cdecl conventions then that's a pretty serious problem, right, not just for rpcrt4? Looks like to fix I will need to read some machine code.
If there's a fundamental problem here, I guess this would mean we'd have to install gcc<->msvc cdecl thunks somewhere to properly fix the problem? Well, perhaps not, just thinking out loud. I'll look into this tonight; I bet you are on to something here.