Apache OpenOffice (AOO) Bugzilla – Issue 102568
assertion failed tpp.c __pthread_tpp_change_priority
Last modified: 2014-03-08 18:13:19 UTC
I'm using the DocumentConverter.py script to convert .sxw documents to PDFs. Occasionally I'll see this: python: tpp.c:63: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed. At other times I just get a core dump. (no backtrace worth much) I believe I have determined that this only happens on multi-processor machines, at least I have not been able to reproduce on a single-processor machine. I have also used 'taskset' to tie both the soffice daemon and the script to the same CPU, which have greatly reduced the number of occurrences. The problem is easily reproduced although it will take a few attempts. This issue was already reported to openSUSE, but I'm not sure if it's going anywhere: https://bugzilla.novell.com/show_bug.cgi?id=498789
I should have added: I'm running an soffice daemon like this: /usr/lib/ooo3/program/soffice.bin -headless -nologo -norestore -accept='socket,host=localhost,port=8100;urp;StarOffice.ServiceManager'
Can you reproduce with the vanilla OOo 3.1? If yes reopen this issue. If not you should refer to Suse.
Have installed vanilla OO 3.1, but I'm unable to get the soffice daemon to run, it just kept hanging waiting for a futex, never started listening on 8100. If I manage to get it to run, and reproduce the problem, I'll reopen.
I managed to get the daemon running by adding '-nofirststartwizard'. I have now switched to running vanilla OO 3.1, and the issue manifests itself a little differently. I still get a core dump, but so far I have not seen the assertion mentioned initially. The daemon I'm running is: /opt/openoffice.org3/program/soffice.bin -headless -nologo -norestore -accept='socket,host=localhost,port=8100;urp;StarOffice.ServiceManager' -nofirststartwizard My client is the following script: export PYTHONPATH=/opt/openoffice.org/basis3.1/program export LD_LIBRARY_PATH=/opt/openoffice.org/basis3.1/program/ export URE_BOOTSTRAP="vnd.sun.star.pathname:/opt/openoffice.org3/program/fundamentalrc" taskset 0x1 python /usr/share/ooo3/program/DocumentConverter.py sxwfile pdffile
@ sg: Please have a look.
sb: Please take over.
@pjessen: Which process is crashing, python or soffice.bin? Also, I assume you are using a system python, not the one included in OOo. In this case, setting LD_LIBRARY_PATH to OOo may cause problems for the system python (picking up OOo library versions instead of system ones). I do not know why you set LD_LIBRARY_PATH at all (at least with recent OOo snapshot releases like DEV300m56 it should not be necessary at all; I do not remember whether there was an issue in OOo 3.1 that required it). Please check whether the problem remains if you either (a) use system python and do not set LD_LIBRARY_PATH (if that works at all for you, see above), or (b) use OOo python (and set neither LD_LIBRARY_PATH nor URE_BOOTSTRAP).
1) it is python that is crashing. 2) I'm using the system python. 3) without the LD_LIBRARY_PATH set, I get the following: (flock -s 200; sxw2pdf aug2009.1.sxw aug2009.1.pdf) 200>/var/lock/sxw2pdf Traceback (most recent call last): File "/usr/share/ooo3/program/DocumentConverter.py", line 13, in <module> import uno File "/opt/openoffice.org/basis3.1/program/uno.py", line 33, in <module> import pyuno SystemError: dynamic module not initialized properly I switched to using the OOo python, assuming /opt/openoffice.org3/program/python is the correct one. Using that, I got a segfault on the second try.
@pjessen: Would you mind testing the last scenario (no LD_LIBRARY_PATH, no URE_BOOTSTRAP, just PYTHONPATH pointing at OOo installation's openoffice.org/basis3.x/program directory and using the python executable from the OOo installation's openoffice.org3/program directory) with a recent OOo snapshot build (the DEV300_m56 or later available at <http://download.openoffice.org/next/other.html>)? I tried with the DocumentConverter.py available at <http://www.artofsolving.com/files/DocumentConverter.py>, but could not reproduce your crash.
Okay, have installed DEV300_m56 on my test-setup. Have started soffice.bin like this: /opt/ooo-dev3/program/soffice.bin -headless -nologo -norestore -accept='socket,host=localhost,port=8100;urp;StarOffice.ServiceManager' -nofirststartwizard Then I ran the DocumentConverter script: PYTHON=/opt/ooo-dev3/program/python export PYTHONPATH=/opt/ooo-dev/basis3.2/program ulimit -c unlimited $PYTHON ./DocumentConverter.py $@ For each conversion, I got "ERROR! ErrorCodeIOException 19468". I'm going to run conversions continually and see what happens.
@pjessen: "For each conversion, I got 'ERROR! ErrorCodeIOException 19468'": Please use soffice in non-headless mode instead to find out what the problem is (I guess some error dialog will pop up instead of the console error message).
Sorry, looks like I didn't get the test script running properly. Will try the continuous conversions again.
1) I kept soffice.bin running headless, which gave me a number of good conversions but interspersed with "ERROR! ErrorCodeIOException 283". 2) I then ran soffice.bin with GUI, which produced a number of the following: terminate called after throwing an instance of 'std::bad_alloc' or ERROR! ErrorCodeIOException 283
@pjessen: Do you always convert the same document, or do you convert different documents? std::bad_alloc might indicate that some code has problems reading a specific input document, reading some false size information from it and subsequently trying to allocate extremely large amounts of memory, which will fail.
No, I have a suite of 15 test documents that I'm converting. I only saw two instance of "terminate called after throwing an instance of 'std::bad_alloc'" and they didn't come from the same conversion/document.
@pjessen: It is the soffice.bin process, not the python process, that reports "terminate called after throwing an instance of 'std::bad_alloc'" (and terminates), right?
No, the soffice-bin process is stable, the problems are reported by the python process. Wrt ErrorCodeIOException 283, it does appear to be caused by a particular document.
@pjessen: So, what I understand from this issue is the following. Using OOo DEV300m56 and OOo's python, the problem originally reported with this issue does not appear, but instead two other problems appear: 1 It happens that the python DocuemntConverter.py process terminates with std::bad_alloc. (This would appear to be a problem of the Python--UNO bridge.) 2 The python DocumentConverter.py process reports some ErrorCodeIOException for specific input documents. (This would appear to be a problem of the OOo code that does the conversion.) If this correctly summarizes the situation you experience, I suggest you close this issue as INVALID and instead for problem (1) file a new issue for Component "udk" and for problem (2) file a new issue for Component "framework."
Until this issue will be changed as suggested by SB the issue will be set to target OOo 3.x.
This Issue requires more information ('needmoreinfo'), but has not been updated within the last year. Please provide feedback as requested and re-test with the the latest version of OpenOffice - the problem(s) may already be addressed. You can download Apache OpenOffice 3.4.1 from http://www.openoffice.org/download Please report back the outcome of your testing, so this Issue may be closed or progressed as necessary - otherwise the issue may be Resolved as Invalid in the future.
Reset assignee on issues not touched by assignee in more than 1000 days.