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? > 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. > o lots of IMallocSpy activity in the winelib version > (perhaps just part of the ole32 initialization?) I suppose. > o pFormat argument to RPCRT4_NdrClientCall2 is different in the winelib version (!?) Hmm, not good. > 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?
