Download it now!
Bug 134106 - Binary URP bridge disposed during call to ServiceManager.createInstanceWithContext
Summary: Binary URP bridge disposed during call to ServiceManager.createInstanceWithCo...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: x86-64 (AMD64) Linux (All)
: highest critical
Assignee: Stephan Bergmann
URL:
Whiteboard: target:7.1.0 target:7.0.0.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2020-06-18 12:08 UTC by Buovjaga
Modified: 2020-06-27 08:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Buovjaga 2020-06-18 12:08:19 UTC
Found in bug 127009

1. Run `soffice --impress --accept="socket,host=localhost,port=2002;urp;StarOffice.ServiceManager"`, and dismiss "Select a Template" window.
2. Execute attachment 153473 [details] with Python

Good result:
None

Bad result:
Traceback (most recent call last):
  File "test.py", line 13, in <module>
    desktop = connectToLO()
  File "test.py", line 11, in connectToLO
    return smgr.createInstanceWithContext( "com.sun.star.frame.Desktop", ctx)
__main__.RuntimeException: Binary URP bridge disposed during call

Bibisected with Linux 6.5 repo to
https://git.libreoffice.org/core/+/f0a50d230756fc0a60780d992b807f9eb82106c2%5E!/
tdf#127205 split Desktop::terminate process

Adding Cc: to Jan-Marek Glogowski
Comment 1 libre officer 2020-06-22 14:06:18 UTC
(In reply to Buovjaga from comment #0)
> Found in bug 127009
> 
> 1. Run `soffice --impress
> --accept="socket,host=localhost,port=2002;urp;StarOffice.ServiceManager"`,
> and dismiss "Select a Template" window.
> 2. Execute attachment 153473 [details] with Python
> 
> Good result:
> None
> 
> Bad result:
> Traceback (most recent call last):
>   File "test.py", line 13, in <module>
>     desktop = connectToLO()
>   File "test.py", line 11, in connectToLO
>     return smgr.createInstanceWithContext( "com.sun.star.frame.Desktop", ctx)
> __main__.RuntimeException: Binary URP bridge disposed during call
> 
> Bibisected with Linux 6.5 repo to
> https://git.libreoffice.org/core/+/
> f0a50d230756fc0a60780d992b807f9eb82106c2%5E!/
> tdf#127205 split Desktop::terminate process
> 
> Adding Cc: to Jan-Marek Glogowski

Unable to reproduce.
It show the good result `None`.

Tested with:
Version: 7.0.0.0.beta1 (x64)
Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c
CPU threads: 4; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win
Locale: fr-CH (fr_FR); UI: en-GB
Calc: threaded
Comment 2 Jan-Marek Glogowski 2020-06-25 17:46:39 UTC
So somehow my new internal / unpublished XDesktopInternal interface uncovered, what looks to me like a general UNO bug and breaks the (Py?)UNO interface backwards compatibility. I don't know for sure, this bug is Python only, but from my debugging I guess the LO side of the UNO bridge is broken. So my conclusion is, that change basically breaks every external / remote UNO user, so I think that is a critical bug.

AFAIK this error just happens, if you have an independent pyuno, like one from your distro and use the system python with that, because the LO python in instdir has access to the up-to-date introspection data, so it can use "cheaper" UNO calls and "somehow" work. Any you don't need "--impress".

The gist of my current logging is:

2020-06-25 17:28:36,899 [CALL,tid 20022]: try     py->uno[0x5576d145b500].createInstanceWithContext((string)"com.sun.star.frame.Desktop", (com.sun.star.uno.XInterface)0x5576d1453e88)
2020-06-25 17:28:36,900 [CALL,tid 20022]: success py->uno[0x5576d145b500].createInstanceWithContext()=(com.sun.star.uno.XInterface)0x7fdc64003ff8

debug:20022:20022: any2PyObject <Any: (com.sun.star.uno.XInterface) 0x7fdc64003ff8>
debug:20022:20022: PyUNO_new <Any: (com.sun.star.uno.XInterface) 0x7fdc64003ff8>
debug:20022:20022: createInstanceWithArguments in arglen: 1

debug:20022:20022: com.sun.star.uno.XInterface::queryInterface 0x7ffd60a16060
debug:20022:20022: com.sun.star.uno.XInterface::queryInterface 0x7ffd60a15cf0
debug:20022:20022: com.sun.star.lang.XTypeProvider::getTypes 0x7ffd60a15d80
debug:20022:20022: 5577084f1000;gcc3[0];1ed340439f4e468c91eaf8221bbbda4
debug:20022:20022: com.sun.star.lang.XTypeProvider::getTypes
2020-06-25 17:28:36,901 [CALL,tid 20022]: error  py->uno[0x5576d145b500].createInstanceWithContext = (com.sun.star.uno.RuntimeException){ (com.sun.star.uno.Exception){ Message = (string)"Binary URP bridge disposed during call", Context = (com.sun.star.uno.XInterface)0x5576d1442bd0 } }
debug:20022:20022: any2PyObject <Any: (com.sun.star.uno.RuntimeException) 0x5576d14545d0>
debug:20022:20022: createInstanceWithArguments in arglen: 1
Traceback (most recent call last):
  File "/tmp/test.py", line 14, in <module>
    desktop = connectToLO()
  File "/tmp/test.py", line 12, in connectToLO
    return smgr.createInstanceWithContext( "com.sun.star.frame.Desktop", ctx)
__main__.RuntimeException: Binary URP bridge disposed during call

I won't spend more time on this, because digging through all this already feels like a rabbit hole.

Or my conclusion is wrong, which based on my current level of understanding is quite possible...

BTW: the debugging info in pyuno/README is not up to date. There is also PYUNO_LOGLEVEL=ARGS.
Comment 3 Stephan Bergmann 2020-06-26 09:18:05 UTC
Yes, this only fails if the python side uses a sufficiently old LO installation (e.g., using python3-3.8.3-1.fc32.x86_64 and libreoffice-6.4.4.2-2.fc32.x86_64 on Fedora 32).

<https://git.libreoffice.org/core/+/f0a50d230756fc0a60780d992b807f9eb82106c2%5E!>
"tdf#127205 split Desktop::terminate process" introduced a new css.frame.XDesktopInternal UNOIDL interface type (which an "old python side" thus does not know) and made the C++ implementation of the css.frame.Desktop UNOIDL service (framework::Desktop in framework/inc/services/desktop.hxx) implement it.

PyUNO uses the UNO introspection framework to translate between Python and UNO, and what presumably happens is that the python side, to translate the Python code

  desktop.CurrentComponent

in test.py (attachment 153473 [details]) into UNO, asks the soffice side for a sequence of all UNOIDL interface types supported by that desktop UNO object.  It thus gets back, among others, a UNO TYPE value for css.frame.XDesktopInternal, but which it does not know, so it disposes the bridge and throws an exception.

This would appear to be a general, by-design issue when connecting an "old python side" to a "new soffice side".
Comment 4 Konstantin Kharlamov 2020-06-26 09:33:10 UTC
(In reply to Stephan Bergmann from comment #3)
> Yes, this only fails if the python side uses a sufficiently old LO
> installation (e.g., using python3-3.8.3-1.fc32.x86_64 and
> libreoffice-6.4.4.2-2.fc32.x86_64 on Fedora 32).
> 
> <https://git.libreoffice.org/core/+/
> f0a50d230756fc0a60780d992b807f9eb82106c2%5E!>
> "tdf#127205 split Desktop::terminate process" introduced a new
> css.frame.XDesktopInternal UNOIDL interface type (which an "old python side"
> thus does not know) and made the C++ implementation of the css.frame.Desktop
> UNOIDL service (framework::Desktop in framework/inc/services/desktop.hxx)
> implement it.
> 
> PyUNO uses the UNO introspection framework to translate between Python and
> UNO, and what presumably happens is that the python side, to translate the
> Python code
> 
>   desktop.CurrentComponent
> 
> in test.py (attachment 153473 [details]) into UNO, asks the soffice side for
> a sequence of all UNOIDL interface types supported by that desktop UNO
> object.  It thus gets back, among others, a UNO TYPE value for
> css.frame.XDesktopInternal, but which it does not know, so it disposes the
> bridge and throws an exception.
> 
> This would appear to be a general, by-design issue when connecting an "old
> python side" to a "new soffice side".

Thanks for explanation! Given pyuno is provided by libreoffice, this means whenever users update their libreoffice instance, they won't have such problem.

So, this kinda "not a bug"… But I wonder if it would make sense to make PyUNO print a warning whenever it detects that it connects to a different version of LibreOffice? Because it is pretty common for QA to ask a user to test their bug on a newer version of LibreOffice, and then if their bug is because of PyUNO, they for sure would test with the system version of PyUNO. And then they gonna get this or another similar problem.
Comment 5 Jan-Marek Glogowski 2020-06-26 11:19:34 UTC
Just to document todays IRC discussion, which from my POV leaves us with the position, that this is not fixable in the short term and the users fix is to update your PyUNO typeinfo to 7.0, if you want to control LO 7.0+. It's Python specific, because other users, like Java, have built-in type info and don't use introspection at all.

[11:55] <jmux> sberg: regarding your comment on tdf#134106, why you think (Py)UNO has to know of XDesktopInternal "in advance" (my intrpretation)?
[11:56] <sberg> jmux, because that's how URP and introspection (somewhat unfortunately) interact, by design
[11:56] <jmux> I thought the whole idea of UNO is, that everything can be "learned" via introspection, so it's no problem to introduce something new on the server side
[11:57] <jmux> sberg: so there is actually now way to fix this bug?
[11:57] <sberg> jmux, type information is never transported over bridges, so both sides need matching typeinfo to work
[11:58] <sberg> jmux, don't think there's a way to fix that, no  (going for a swim in the lake now, sometimes you get good ideas during such, but I doubt it'll happen this time)
[11:59] <jmux> sberg: ok - if type information of everything must be distributed in advance - then there is no way to fix it andit's not python specific
[12:01] <jmux> Maybe at least it is possible to ignore the unknown type / interface. 
[12:03] <jmux> Just "crashing" the caller, if it finds an unknown type via introspection is rather unfortunate.
[12:10] * jmux always assumed that the directly shared typeinfo is just an optimization for "local", fast communication
[12:12] <tml_> sberg: but can type information be fetched over bridges, even if it isn't transported automatically?
[12:12] <tml_> (asking just out of interest)
[12:13] <jmux> tml_: I assumed that would be something like an autmated fallback, but as I read sberg, there is no way to transport type info at all, at least via URB
[12:15] <tml_> There is css::Introspection etc things
[12:15] <tml_> css::beans::Introspection I mean
[12:17] <jmux> Yup - but AFAIK all of it depends on a shared "RDB" file. The actuall "crash" happens somewhere inside the Invocation_Impl.
[12:19] <tml_> OK, so calling introspection APIs from a remote LO instance won't work unless the client has the same RDB available? Weird
[12:21] <noelgrandin> probably python is the first remote end to make "routine" use of the introspection APIs
[12:21] <noelgrandin> most of the others don't do normally need or try to do any introspection
[12:22] <jmux> AFAIK all the casting of interfaces of services needs introspection, so I don't understand, why this should be python specific
[12:23] <noelgrandin> https://xkcd.com/2324/
[12:24] <jmux> From sbergs answer I seem to miss some step in the whole UNO RPC handling, as either "no typeinfo transport" is true, or "python specific" is true
[12:24] <noelgrandin> no, I dont think casting using introspection (at least not that part of it)
[12:25] <jmux> But then you need pre-shared typeinfo, otherwise how would you know what interfaces your service implements
[12:25] <jmux> Or I have an other defeinition of introspection then you
[12:26] <jmux> Currently I don't think the answers I got make sense in combination
[12:26] <noelgrandin> it is declared in the service interface what interface it implements. you can cast to other interfaces that you know about, but you don't need to ask it to enumerate all the interfaces it supports
[12:27] <noelgrandin> jmux, there are two kinds of "introspection" at work here. One is very very low level, and built into the lowest parts of the UNO code and used in casting. The other kind of introspection is an actual UNO service that is normally used by tjings like X-Ray
[12:28] <noelgrandin> python uses the second, which is a little unusual
[12:30] <jmux> But isn't then the "2nd" using the "1st", so why would that be a problem?
[12:31] <noelgrandin> jmux, it uses more than the normal casting infrastructure
[12:31] <jmux> That would mean it's just a "limit" of the implementation of the "Introspection" service and would be fixable, or not?
[12:34] <jmux> Still that would conflict with "no introspection data via URP" assesment.
[12:36] <jmux> Or it's just "no introspection data via Introspection service", which would be fixable by an extended introspection service, but I won't implement that to fix "my" bug.
[12:43] <sberg> jmux, it's just clients that call things like css.uno.XTypeProvider::getTypes (returning a sequence<type>) that get into trouble; e.g. a Java client wouldn't typically call that, it knows that the css.frame.Desktop service object implements XDesktop, does a queryInterface for that and calls methods on it; whereas PyUNO routinely calls it to learn about each object's types
[12:44] <sberg> (and no, the lake was a bit uninspiring today :)
[12:45] <sberg> we could cheat in that service impl's getTypes implementation, but that wouldn't solve the general issue
[12:47] <jmux> sberg: so why would Java know? Is it just a limit of the Introspection service, as I assume? And you would not need pre-shared RDB files?
[12:47] <sberg> jmux, Java doesn't see a need to call getTypes, that's all
[12:49] <jmux> But why? Were does it "magically" get the information, why the python stuff seem to be missing
[12:51] <sberg> jmux, in statically typed Java, it's in the source code, XDesktop x = ...; x.getCurrentComponent()
[12:52] <sberg> ...while in dynamically typed Python, the introspection stuff is used behind the scenes to "translate" x.CurrentComponent
[12:55] <jmux> So the Java code has the type info "build in" and doesn't use UNO introspection at all.
[12:57] <sberg> jmux, exactly
[12:59] <jmux> Oh well - so what to do about tdf#134106? I can't / won't rewrite PyUNO to use static introspection info.
[13:01] <jmux> And from your comment I assume that typeinfo transport via URB isn't possible at all (except by writing a IntrospectionTypeinfo" service
[13:01] <jmux> ) But obviously that wouldn't work with old python UNO implementation either.
[13:05] <jmux> Or "we" could revert the fix for tdf#127205. I don't like either. Or at least put some info into the release note.
[13:06] <jmux> Probably something for ESC to decide? 7.0 is around the corner.
[13:08] <sberg> jmux, I think it's effectively NOTABUG or WONTFIX; you just can't, in general, have two sides interacting that don't have a common understanding of UNO type info
[13:09] <sberg> jmux, as I wrote earlier, if one would really want to, one could probably cheat in that service's getTypes information, and leave the new type out, but that would be a bit ugly and wouldn't solve the general issue anyway
[13:10] <sberg> jmux, if I don't get an aha effect in the next few hours, I will comment on the bug accordingly
Comment 6 Konstantin Kharlamov 2020-06-26 11:26:40 UTC
@Jan-Marek Glogowski thank you. I imagine though just printing the warning should be a fix good enough. I don't expect this problem would be the last one of this kind.
Comment 7 Stephan Bergmann 2020-06-26 15:41:09 UTC
After some more thought, <https://gerrit.libreoffice.org/c/core/+/97241> "tdf#134106: Get rid of XDesktopInternal again" is my take how to chicken out here.
Comment 8 Commit Notification 2020-06-26 16:53:37 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a6862a26d6cd17f6b4e4f6577bcd778bf952e65b

tdf#134106: Get rid of XDesktopInternal again

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2020-06-26 17:41:00 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/2562df42f8a95f33f339405354b422e52cf42fbf

tdf#134106: Get rid of XDesktopInternal again

It will be available in 7.0.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Buovjaga 2020-06-27 08:27:56 UTC
Cheers, verified!

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: 076c95b27bf0e9be1fa1c077674cf974b22210fd
CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 27 June 2020