Win64 bridge backport - #492
Open
leginee wants to merge 2 commits into
Open
Conversation
uno2cpp.cxx converts each simple by-value argument into an 8-byte alloca
temp and stores the pointer in pCppArgs[nPos]:
uno_copyAndConvertData( pCppArgs[nPos] = alloca( 8 ), ... );
Copying the value into the outgoing slot therefore has to dereference that
pointer. The marshalling switch used &pCppArgs[nPos] instead, which reads
the pCppArgs array slot itself, i.e. the temp's address -- so every HYPER,
LONG, ENUM, SHORT, CHAR, BOOLEAN, BYTE, FLOAT and DOUBLE parameter reached
the callee as a stack address (or its low 16/32 bits) rather than a value.
The same expression is correct in the complex/ref branch, where the pointer
IS the argument; written there as (sal_uInt64)pCppArgs[nPos] to make the
difference between the two branches obvious.
This only affects calls that cross between the uno and cpp environments, so
a pure-C++ session never trips it; it surfaces via pyuno and the invocation
adapters.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…buffer The Win64 call stack is "ret addr, this, [ret *], params", so a method with a hidden return pointer finds it at pCallStack[2] -- cpp2uno_call() reads pCppReturn from [2], and the queryInterface shortcut in cpp_mediate() reads its Type argument from [3] accordingly. That shortcut nevertheless built the returned Any at pCallStack[1] and returned [1] in the register slot. [1] is `this`, so it constructed a 24-byte Any over the proxy object and never wrote the caller's own return buffer. The caller then read and destructed an uninitialised Any, faulting in uno_any_destruct() on a stale stack value used as a typelib_TypeDescription*. The x86 bridge has always used pCallStack[2] here; the Win64 port carried over the x86 index, where the layout puts the hidden pointer before `this`. Reproducer: any queryInterface on a raw uno_Interface proxy -- e.g. pyuno's Adapter::getOutIndexes() inspecting an InvocationAdapterFactory adapter, which crashed on every use of the Python macro organiser. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Contributor
Author
|
probably the AI never cherry picked, rather copied the solution. I guess because i started off on the wrong foot. |
Contributor
|
Please hold on for a few days, I've rebased (what's left of) my windows-amd64 branch to the latest trunk, and plan to merge it soon, with my version of those uno2cpp.cxx fixes. |
Contributor
Author
|
sure, then i withdraw this one, and wait for your rebase and merge? |
Contributor
I am only referring to uno2cpp.cxx, your patch for cpp2uno.cxx will still be necessary. |
Contributor
Author
|
Ahh ok. I will then fix this and merge. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes issues with the python script provider. It did not work on 64 bit. The following patches fixes that.
now it should work on x64 and x84 version on windows.