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. -- gmt "It has been well said that really up-to-date liberals do not care what people do, as long as it is compulsory." -George F. Will