[Libreoffice-bugs] [Bug 134106] Binary URP bridge disposed during call to ServiceManager.createInstanceWithContext

Fri Jun 26 11:19:34 UTC 2020

https://bugs.documentfoundation.org/show_bug.cgi?id=134106

--- Comment #5 from Jan-Marek Glogowski <glogow at fbihome.de> ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200626/c98736f3/attachment-0001.htm>