Bug 50682 - On MacOS X 10.7, 'import uno' crashes in the LibreOffice-provided Python
Summary: On MacOS X 10.7, 'import uno' crashes in the LibreOffice-provided Python
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard: target:3.7.0 target:3.6.0.0.beta3 tar...
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-04 07:35 UTC by Loic Nageleisen
Modified: 2012-06-25 06:48 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
crash report (29.27 KB, text/plain)
2012-06-04 07:59 UTC, Loic Nageleisen
Details
Skip setting DYLD_LIBRARY_PATH on Lion (628 bytes, patch)
2012-06-21 11:51 UTC, Loic Nageleisen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Loic Nageleisen 2012-06-04 07:35:24 UTC
Self-explanatory output from a Terminal session:

$ /Applications/LibreOffice.app/Contents/program/python
Python 2.6.1 (r261:67515, May 22 2012, 08:19:34) 
[GCC 4.0.1 (Apple Inc. build 5494)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import uno
Abort trap: 6
$ uname -a
Darwin sekhmet.local 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
Comment 1 Loic Nageleisen 2012-06-04 07:59:54 UTC
Created attachment 62516 [details]
crash report
Comment 2 Roman Eisele 2012-06-19 00:13:18 UTC
Hm ... for me, it seems to work.

I have installed LibreOffice 3.5.4.2 (Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18) on MacOS X 10.6.8 locally to my user profile, i.e. at
 ~/Applications/LibreOffice/LibreOffice.app
Therefore, the input and output of my Terminal session are:

$ ~/Applications/LibreOffice/LibreOffice.app/Contents/program/python
Python 2.6.1 (r261:67515, May 22 2012, 08:19:34) 
[GCC 4.0.1 (Apple Inc. build 5494)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import uno
>>> 

That's it: no abort. This is the output from "uname -a" on my machine:

Darwin <machine name>.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

This leads to the question: what is the (human readable) MacOS X version you use (probably 10.7.x)? Maybe this crash has something to do with the MacOS X version? (I don't know why, but I see no other important difference between your and my configuration; the LibreOffice-provided Python seems to be identical.)
Comment 3 Loic Nageleisen 2012-06-19 00:20:22 UTC
$ uname -a
Darwin sekhmet.local 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64

Yup it's 10.7.4.

It impacts unoconv (https://github.com/dagwieers/unoconv/issues/27) and reports over there corroborate that 'import uno' works on Snow Leopard but fails with an abort on Lion.
Comment 4 Roman Eisele 2012-06-19 02:07:04 UTC
(In reply to comment #3)
> It impacts unoconv (https://github.com/dagwieers/unoconv/issues/27) and
> reports over there corroborate that 'import uno' works on Snow Leopard
> but fails with an abort on Lion.

OK, IMHO the information in https://github.com/dagwieers/unoconv/issues/27 is sufficient to set this report's Status field to NEW (some comments in the quoted discussion talk explicitely about LibreOffice on MacOS X 10.7).

To sum it up: if I understand correctly, this is not a bug in unoconv (as the quoted discussion seems to suggest at the very (!) first glance; but then this would be NOTOURBUG), but it is a bug in LibreOffice itself which prevents the LibreOffice-provided Python from working together with Uno, and therefore also makes unoconv stop working. However, this issue seems to be present on MacOS X 10.7 (Lion) only.

@Loic Nageleisen:
is my summary halfway correct?
Comment 5 Loic Nageleisen 2012-06-19 03:07:42 UTC
> is my summary halfway correct?

Absolutely. unoconv only crashes insofar as it imports uno and the problem can readily be replicated with only LibreOffice and its bundled python. I have no Snow Leopard at hand but I can confirm the crash on three distinct Lion machines.
Comment 6 Roman Eisele 2012-06-19 03:16:57 UTC
@Stephan Bergmann,
@Thorsten Behrens:
You are our UNO and MacOS experts. I don't know who is our Python expert, so I insert (only) your addresses into the CC list. Please take a look at this issue. It breaks Python access to UNO completely on MacOS X 10.7 (and maybe elsewhere). Thank you very much!
Comment 7 Stephan Bergmann 2012-06-19 13:12:23 UTC
At least on Mac OS X 10.7.4, the dlopen of libpyuno.dylib from pyuno.so (pyuno/source/module/pyuno_dlopenwrapper.c) fails with a dlerror of

dlopen(/Users/stephan/Desktop/LOdev.app/Contents/MacOS/libpyuno.dylib, 10): Symbol not found: _sqlite3_wal_checkpoint
  Referenced from: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
  Expected in: /Users/stephan/Desktop/LOdev.app/Contents/MacOS/libsqlite3.dylib
 in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork

<http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc82cf021f76ea83ff7a4bcb2d7525f2e111f0cc> "Make PyUNO work --with-macox-version-min-required=10.6" on recent master towards LO 3.7 fixes this when *building* on Mac OS X 10.7.4, but not when *running* a stock build (based on the 10.4 SDK) on Mac OS X 10.7.4.

Whether it would be OK to adapt that fix to always build LO on Mac OS X against system libsqlite3.dylib instead of one from LO's nss module, I do not know.  I do not have a baseline Mac OS X 10.4 to check whether its system libsqlite3.dylib (if any) would be sufficient.
Comment 8 Loic Nageleisen 2012-06-19 15:01:39 UTC
According to a thread [0] that turn up on a google incantation, Tiger does have sqlite3 bundled.

> Tiger comes with sqlite3 pre-installed: /usr/lib/libsqlite3.dylib

>> Is sqlite3 installed on Tiger or just included with it?	
> It's installed. It is part of BaseSystem.pkg - i.e. it is on every Tiger machine.

Also, this StackOverflow thread [0] gives hints as to ways to link it from the SDK on build

> If you must link with Tiger's sqlite3, all you need to do is add this to your Other Linker Flags:
>    -l/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libsqlite3.dylib

From other threads [2] I could gather that it could be sqlite 3.1.3.

Finally, in Apple's open source browser one can find the sqlite source they used for e.g 10.4.11 [3]. The VERSION file confirms 3.1.3.

[0] http://hintsforums.macworld.com/showthread.php?t=63805
[1] http://stackoverflow.com/questions/1474176/how-to-link-tigers-sqlite3-library-in-xcode
[2] http://forums.pragprog.com/forums/66/topics/408
[3] http://opensource.apple.com/source/SQLite/SQLite-28/
Comment 9 Roman Eisele 2012-06-20 00:23:47 UTC
Just in case this is of interest: on MacOS X 10.6(.8), the preinstalled /usr/lib/libsqlite3.dylib seems to have version 3.6.12.
Comment 10 Stephan Bergmann 2012-06-20 02:39:28 UTC
also see mailing list thread started at <http://lists.freedesktop.org/archives/libreoffice/2012-June/033825.html> "Using system libsqlite3.dylib on Mac OS X? (fdo#50682)"
Comment 11 Loic Nageleisen 2012-06-21 11:45:25 UTC
Following a comment of someone able to hack hos way into making unoconv behave on Lion and combined with the fact that it comes from some dylib, I had some progress[0] made on making 'import uno' working.

I commented the following lines in /Applications/LibreOffice.app/Contents/MacOS/python:

DYLD_LIBRARY_PATH=$sd_prog:$sd_prog/../ure-link/lib${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH}
export DYLD_LIBRARY_PATH

import uno does work, and I tested a small number of scripts to validate it's really working (e.g Hello World from [1]).

So a possible workaround would be to negatively test like so before setting DYLD_LIBRARY_PATH.

if perl -e '`uname -s -r` =~ /Darwin 11\.\d+\.\d+/ and exit 1'; then
    DYLD_LIBRARY_PATH=$sd_prog:$sd_prog/../ure-link/lib${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH}
    export DYLD_LIBRARY_PATH
fi

[0] https://github.com/dagwieers/unoconv/issues/27#issuecomment-6490497
[1] http://www.openoffice.org/udk/python/python-bridge.html#tutorial
Comment 12 Loic Nageleisen 2012-06-21 11:51:34 UTC
Created attachment 63319 [details]
Skip setting DYLD_LIBRARY_PATH on Lion

Workaround. Appears to be working but requires further evaluation.
Comment 13 Stephan Bergmann 2012-06-22 00:11:43 UTC
(In reply to comment #11)
> I commented the following lines in
> /Applications/LibreOffice.app/Contents/MacOS/python:
> 
> DYLD_LIBRARY_PATH=$sd_prog:$sd_prog/../ure-link/lib${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH}
> export DYLD_LIBRARY_PATH
> 
> import uno does work, and I tested a small number of scripts to validate it's
> really working (e.g Hello World from [1]).

Ha, right, /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork picking up my LO's /Users/stephan/Desktop/LOdev.app/Contents/MacOS/libsqlite3.dylib instead of the system one as recorded with an installpath in CFNetwork is likely not due to some other LO lib in that process already having loaded LO's libsqlite3.dylib via installpath, but rather due to DYLD_LIBRARY_PATH overriding any recorded installpaths anyway.

That means the best fix might be to just replace all mention of DYLD_LIBRARY_PATH in the python script with DYLD_FALLBACK_LIBRARY_PATH (see man page for dyld(1)).  Can you try that?  (It was likely pure luck that your "small number of scripts" kept working after removing the DYLD_LIBRARY_PATH block completely.)
Comment 14 Not Assigned 2012-06-22 03:10:26 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a164d246f2ed941fbdef19ec5b47dac1bab25509

fdo#50682: Setting DYLD_LIBRARY_PATH in python script appears unnecessary
Comment 15 Not Assigned 2012-06-22 03:17:43 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b4ba164264de30735941bfbb87f36ec5ca81ea36&g=libreoffice-3-6

fdo#50682: Setting DYLD_LIBRARY_PATH in python script appears unnecessary


It will be available in LibreOffice 3.6.
Comment 16 Stephan Bergmann 2012-06-22 03:35:48 UTC
On closer inspection, setting DYLD_LIBRARY_PATH in LO's python wrapper script appears to be completely unnecessary after all.

I intend to get the above fix for master and libreoffice-3-6 (see comment 14 and comment 15) backported to libreoffice-3-5 and libreoffice-3-5-5 as well, see <http://lists.freedesktop.org/archives/libreoffice/2012-June/034010.html> "[REVIEW-3-5][REVIEW-3-5-5] Using system libsqlite3.dylib on Mac OS X? (fdo#50682)."
Comment 17 Not Assigned 2012-06-25 06:48:58 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cf5ac1ad17bd8d2e9c8b585254302ecc053a9547&g=libreoffice-3-5

fdo#50682: Setting DYLD_LIBRARY_PATH in python script appears unnecessary


It will be available in LibreOffice 3.5.6.