Skip to content

Win64 bridge backport - #492

Open
leginee wants to merge 2 commits into
trunkfrom
win64-bridge-backport
Open

Win64 bridge backport#492
leginee wants to merge 2 commits into
trunkfrom
win64-bridge-backport

Conversation

@leginee

@leginee leginee commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

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.

leginee and others added 2 commits July 27, 2026 07:10
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>
@DamjanJovanovic

Copy link
Copy Markdown
Contributor

The uno2cpp.cxx changes were already made in commits 2bd0933 and ff15b20 of the windows-amd64 branch.

@leginee

leginee commented Jul 27, 2026

Copy link
Copy Markdown
Contributor Author

probably the AI never cherry picked, rather copied the solution. I guess because i started off on the wrong foot.

@DamjanJovanovic

Copy link
Copy Markdown
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.

@leginee

leginee commented Jul 28, 2026

Copy link
Copy Markdown
Contributor Author

sure, then i withdraw this one, and wait for your rebase and merge?

@DamjanJovanovic

Copy link
Copy Markdown
Contributor

sure, then i withdraw this one, and wait for your rebase and merge?

I am only referring to uno2cpp.cxx, your patch for cpp2uno.cxx will still be necessary.

@leginee

leginee commented Jul 28, 2026

Copy link
Copy Markdown
Contributor Author

Ahh ok. I will then fix this and merge.
I will hold other commits back until you are done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants