Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

uno.RuntimeException: Binary URP bridge disposed during call #57

Open
petross opened this Issue · 13 comments

2 participants

@petross

Hi,

I installed editors/openoffice-3 from the FreeBSD ports (Apache OpenOffice 3.4), under a recent FreeBSD-9 (Stable).

The path for pyuno.so:
/usr/local/openoffice-3.4.0/openoffice.org/basis3.4/program/pyuno.so

unoconv does not work yet.

I tried the tarball for unoconv-0.4. First I had to add in the extrapath glob.glob('/usr/local/openoffice*/openoffice.org/basis*/program')

After that it comes up with

~/unoconv-0.4/unoconv -f pdf -o ~/test.pdf ~/test.odt
Traceback (most recent call last):
File "/root/unoconv-0.4/unoconv", line 68, in
os.environ['LD_LIBRARY_PATH'] = oolibpath + os.pathsep + os.environ['LD_LIBRARY_PATH']
File "/usr/local/lib/python2.7/UserDict.py", line 23, in getitem
raise KeyError(key)
KeyError: 'LD_LIBRARY_PATH'

LD_LIBRARY_PATH isn't set.

Anyway, I tried to use the latest version checked out via Subversion.

~/svn/unoconv/trunk]//unoconv -f pdf -o ~/test.pdf ~/test.odt
unoconv: Cannot find a suitable office installation on your system.
ERROR: Please locate your office installation and send your feedback to:
http://github.com/dagwieers/unoconv/issues

I wasn't successful with the extrapath addition as I did on unoconv-04. The error stays the same (Cannot find a suitable office..)

As a side node, I replaced "#!/usr/bin/python" with "#!/usr/bin/env python" (FreeBSD installs it under /usr/local/bin).

OpenOffice 3.4 and python 2.7 are compiled at the same time (same ports snapshot from last Friday, same gcc etc.) so python and pyuno.so should fit together.

Any ideas?

Regards
Peter

@petross

I've got some help on the unoconv-0.4 issue. (KeyError: 'LD_LIBRARY_PATH'). Fix was
os.environ.get('LD_LIBRARY_PATH', "")
in line 68, os.environ['LDLIBRARY_PATH'] = oolibpath + os.pathsep + os.environ['LD_LIBRARY_PATH']

(Sorry, I am a sysadmin without python experience).

I also added the name of a "modern" OpenOffice, as installed by the FreeBSD port, to the binaries
binaries = ( 'soffice.bin', 'soffice', 'soffice.exe' , 'openoffice-3.4.0')

Anyway, now it crashes with

~/unoconv-0.4/unoconv -f pdf -o ~/test.pdf ~petros/test.odt
Traceback (most recent call last):
File "/root/unoconv-0.4/unoconv", line 791, in
main()
File "/root/unoconv-0.4/unoconv", line 767, in main
convertor = Convertor()
File "/root/unoconv-0.4/unoconv", line 538, in init
self.desktop = unosvcmgr.createInstanceWithContext("com.sun.star.frame.Desktop", unocontext)
uno.RuntimeException: Binary URP bridge disposed during call

I also tried to start a headless OpenOffice before this (it runs on a server without X):

/usr/local/bin/openoffice-3.4.0 -headless -accept="socket,host=127.0.0.1,port=2002;urp;" -nofirststartwizard &

The result stays the same (uno.RuntimeException: Binary URP bridge disposed during call), and it seems to end the OpenOffice

[2]- Done /usr/local/bin/openoffice-3.4.0 -headless -accept="socket,host=127.0.0.1,port=2002;urp;" -nofirststartwizard

According to #22 it may be caused by ythe Office crashing?
"This is caused by OpenOffice/LibreOffice crashing."

Ouch.. So, it looks I've got unoconv-0.4 working but OpenOffice crashes? That would stay even if I get the latest unoconv working.

Can you confirm please? Or do I do something wrong when invoking OpenOffice in headless mode?

I will try with a latest LibreOffice instead then.

Regards
Peter

@petross

A short update: I made my former tests in a FreeBSD jail (a container) but moved to a "proper" FreeBSD system now. The only difference: the headless OpenOffice survives.

The error "uno.RuntimeException: Binary URP bridge disposed during call" still persists.

Peter

@dagwieers
Owner

Can you please try unoconv 0.5, and the version in the master branch ? Some of the things you have mentioned are fixed there. Testing with LibreOffice might help as well, although it could be unique issue on FreeBSD with certain builds.

Also please look at the troubleshooting section in the README. It can help us pinpoint the problem if you could verify each of the points there. In case OpenOffice or LibreOffice ship with their own python binary, please try with that one first.

@petross

Thanks for coming back:-) I will try more next week.

@dagwieers
Owner

Any luck ? I'd like to release v0.6 as soon as possible and want to know if your issue needs addressing or not...

@dagwieers dagwieers was assigned
@petross
@petross

No luck w=ith the lates unoconv from this git website,

starting with the OpenOffice location:

$./unoconv test.odt
unoconv: Cannot find a suitable office installation on your system.
ERROR: Please locate your office installation and send your feedback to:
http://github.com/dagwieers/unoconv/issues

Here they are:

$ find /usr/local -type f -name pyuno.so
/usr/local/openoffice-3.4.0/openoffice.org/basis3.4/program/pyuno.so
$ find /usr/local -type f -name soffice.bin
/usr/local/openoffice-3.4.0/openoffice.org3/program/soffice.bin
$ find /usr/local -type f -name python
/usr/local/bin/python

I tried a bit with extrapaths += but wasn't successful.

I wonder whether it is possible to define them as an environment variable, as a fallback.

I cannot imagine that you are ever be able to think about all ways where someone can install a package.

E.g.
export UNOCONV_PYUNO=/usr/local/openoffice-3.4.0/openoffice.org/basis3.4/program/pyuno.so
export UNOCONV_SOFFICE=/usr/local/openoffice-3.4.0/openoffice.org3/program/soffice.bin
export UNOCONV_PYTHON=/usr/local/bin/python

@dagwieers
Owner

Can you perform the steps in the troubleshooting section that is described in the README ?

It is likely that the reason why it does not work is because the python/pyuno.so are unworkable (even if you would provide them using environment variables on the command line). In my opinion it is better to have it working out of the box, rather than expect users to try out every permutation that he thinks should work on his system. Because I am not convinced you even have a workable setup :-/

@petross

As a sidenote, FreeBSD (and other BSDs, I think), put python, as other packages, under /usr/local.

#!/usr/bin/env python

Is more portable. Other systems, as Solaris, will profit from it as well, I think.

@dagwieers
Owner

@petross Make a pull-request for it, and I'll merge it. Thanks in advance !

@dagwieers
Owner

@petross Still no luck with the most recent version, I assume ? I would expect this to work:

UNO_PATH=/usr/local/openoffice-3.4.0/openoffice.org unoconv test.odt
@dagwieers dagwieers removed this from the Release 0.7 milestone
@dagwieers dagwieers closed this
@dagwieers dagwieers reopened this
@dagwieers
Owner

I am reopening this because more people are having this exact issue and there seems to be a common theme. An interesting read is this:
http://uucode.com/blog/2013/01/09/solved-createinstancewithcontext-binary-urp-bridge-disposed-during-call/

So maybe we can assume that on some platforms we may not be using the correct environment to make the python UNO bindings work correctly...

@dagwieers dagwieers changed the title from Problem with OpenOffice location (and others?) on FreeBSD to uno.RuntimeException: Binary URP bridge disposed during call
@dagwieers dagwieers added this to the Release 0.8 milestone
@dagwieers
Owner

Another interesting hint is in this post:
http://stackoverflow.com/questions/20554015/how-to-debug-crashing-openoffice-with-pyuno

Apparently, if something else (LogMeIn ?) is using port 2002, you get the exact same error.The easiest solution is to use another available port, eg. -p 12345 !

This is easy to test:

[dag@moria unoconv]$ cat /dev/null | nc -l 2002 &>/dev/null &
[1] 746
[dag@moria unoconv]$ /opt/libreoffice4.0/program/python unoconv --format html --export FilterOptions=UTF8 tests/test.txt
Traceback (most recent call last):
  File "unoconv", line 1272, in <module>
    main()
  File "unoconv", line 1186, in main
    convertor = Convertor()
  File "unoconv", line 742, in __init__
    unocontext = self.connect(resolver)
  File "unoconv", line 763, in connect
    unocontext = resolver.resolve("uno:%s" % op.connection)
uno.DisposedException: Binary URP bridge disposed during call

So yes, unfortunately this is a probable cause :-(

@dagwieers dagwieers added the FreeBSD label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.