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

Open
petross opened this Issue May 23, 2012 · 21 comments

Comments

Projects
None yet
8 participants

petross commented May 23, 2012

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 commented May 23, 2012

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 commented May 24, 2012

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

Owner

dagwieers commented May 31, 2012

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 commented Jun 1, 2012

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

Owner

dagwieers commented Jul 19, 2012

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

@ghost ghost assigned dagwieers Jul 19, 2012

petross commented Jul 23, 2012

Hi Dag,

sorry for the delay - I did not have the time before my four weeks
holidays and just returned.

I have to finish something urgent this week and hope to deal with my
unoconv issue next week.

I don't want to delay your release.. please go ahead with it if you are
ready.

I am sys admin for a whole company with varying issues, and have a family,
so I cannot plan time for this as much as I wish. But I am really keen to
get it working, and to share it when done.

Thanks for your work
Peter

petross commented Aug 1, 2012

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

Owner

dagwieers commented Aug 1, 2012

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 commented Aug 2, 2012

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.

Owner

dagwieers commented Aug 2, 2012

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

Owner

dagwieers commented Sep 7, 2012

@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 Jul 5, 2015

@dagwieers dagwieers closed this Jul 5, 2015

@dagwieers dagwieers reopened this Jul 5, 2015

Owner

dagwieers commented Jul 5, 2015

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 Jul 5, 2015

@dagwieers dagwieers added this to the Release 0.8 milestone Jul 5, 2015

Owner

dagwieers commented Jul 5, 2015

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 Jul 5, 2015

jdgvt81 commented Sep 14, 2015

I'm running into the same problem as petross mentioned in his second comment, but running in Windows (x64 on Windows 8.1) with a 64-bit LibreOffice 5.0.1. Running from the command prompt, here's the output:

Traceback (most recent call last):
File "unoconv", line 1332, in
main()
File "unoconv", line 1246, in main
convertor = Convertor()
File "unoconv", line 776, in init
self.desktop = unosvcmgr.createInstanceWithContext("com.sun.star.frame.Desktop", unocontext)
uno.RuntimeException: Binary URP bridge disposed during call

I changed my port and still run into this issue... and the message is slightly different than in comments where the port was being blocked so I don't think that's the problem.

If there is anything else I can provide to help diagnose the error, please let me know.

EDIT: I'm running unoconv 0.7 and I already manually set Windows Environment variables as follows (just in case):

UNO_PATH: C:\Program Files\LibreOffice 5\program
URE_BOOTSTRAP: vnd.sun.star.pathname:C:\Program Files\LibreOffice 5\program\fundamental.ini
and I've included C:\Program Files\LibreOffice 5\program in my Windows PATH

Having the same issue as @jdgvt81 on 64 bit Centos 6.5 and LibreOffice 4.2.8.2

tkhyn commented Nov 8, 2015

Same problem here on Win7 64-bit and LibreOffice 5.0.3.2. Same setup and environment variables as @jdgvt81. Same error message.

The funny thing (which may give you some clues) ? It works perfectly on my other laptop on Win7 32-bit with LibreOffice 5.0.2.2. It also works on the same 32-bit laptop with LibreOffice 5.0.1.2 on OpenSUSE Tumbleweed.

I haven't installed OpenSUSE 64-bit on the 64bit laptop yet, but I'd expect unoconv to fail likewise. I'll know that in the next few days and keep you posted.

(and thanks heaps for your work, btw)

EDIT:

  • on OpenSUSE 64-bit, with UNO_PATH, PYTHONPATH correctly pointing to /usr/lib64/libreoffice/program, I get:
unoconv: Cannot find a suitable pyuno library and python binary combination in /usr/lib64/libreoffice
ERROR: dynamic module does not define init function (initpyuno)
[...]
  • on Win7 64-bit unoconv works provided it's used with OpenOffice (4.1.2, 32bit) or LibreOffice 32bit

@dagwieers
I was having the same problem and indeed it was the issue because of the port for me. The port was used by another process and when I kill the process manually It just works fine now. Thanks a lot :)

I've run cat /dev/null | nc -l 2002 &>/dev/null & and killed the process it returns, then I've run
unoconv -p 12345 -f pdf -o t.pdf test.emf but still get

unoconv: RuntimeException during export phase:
Office probably died. Binary URP bridge disposed during call
Traceback (most recent call last):
  File "/usr/bin/unoconv", line 1278, in <module>
    die(exitcode)
  File "/usr/bin/unoconv", line 1131, in die
    if convertor.desktop.getCurrentFrame():
uno.DisposedException: Binary URP bridge already disposed
Owner

dagwieers commented Sep 19, 2016

@alexcroox That command does not return the process using port 2002, it simply returns the process id (PID) of the command you just pushed in the background. So killing it is useless, not only because it is no longer running (it ends almost immediately), it is not the process using port 2002.

What you probably should be using is:

# lsof -iTCP:2002

That returns no results for me, so still no idea why it wouldn't work

colszowka added a commit to experimental-platform/platform-unoconv that referenced this issue Sep 29, 2016

Collaborator

regebro commented Oct 14, 2017

Is this still an issue?

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