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
(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
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.
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".
(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.
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
@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.
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.
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.
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.
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