Issue 102568 - assertion failed tpp.c __pthread_tpp_change_priority
Summary: assertion failed tpp.c __pthread_tpp_change_priority
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 3.1
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: needhelp, needmoreinfo
Depends on:
Reported: 2009-06-06 17:02 UTC by pjessen
Modified: 2014-03-08 18:13 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description pjessen 2009-06-06 17:02:11 UTC
I'm using the 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
Comment 1 pjessen 2009-06-06 17:15:39 UTC
I should have added:

I'm running an soffice daemon like this:

/usr/lib/ooo3/program/soffice.bin -headless -nologo -norestore

Comment 2 Olaf Felka 2009-06-08 07:02:02 UTC
Can you reproduce with the vanilla OOo 3.1? If yes reopen this issue. If not you
should refer to Suse.
Comment 3 pjessen 2009-06-08 11:27:49 UTC
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.
Comment 4 pjessen 2009-06-08 13:54:25 UTC
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

My client is the following script:

export PYTHONPATH=/opt/
export LD_LIBRARY_PATH=/opt/
taskset 0x1 python /usr/share/ooo3/program/ sxwfile pdffile

Comment 5 Olaf Felka 2009-06-08 14:36:54 UTC
@ sg: Please have a look.
Comment 6 kai.sommerfeld 2009-09-03 14:09:55 UTC
sb: Please take over.
Comment 7 Stephan Bergmann 2009-09-03 16:14:39 UTC
@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
Comment 8 pjessen 2009-09-03 17:38:45 UTC
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/", line 13, in <module>
    import uno
  File "/opt/", 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.
Comment 9 Stephan Bergmann 2009-09-04 08:00:52 UTC
@pjessen:  Would you mind testing the last scenario (no LD_LIBRARY_PATH, no
URE_BOOTSTRAP, just PYTHONPATH pointing at OOo installation's 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
<>)?  I tried with the available at
<>, but could not
reproduce your crash.
Comment 10 pjessen 2009-09-04 09:16:43 UTC
Okay, have installed DEV300_m56 on my test-setup.  Have started soffice.bin like

/opt/ooo-dev3/program/soffice.bin -headless -nologo -norestore

Then I ran the DocumentConverter script:

export PYTHONPATH=/opt/ooo-dev/basis3.2/program
ulimit -c unlimited
$PYTHON ./ $@

For each conversion, I got "ERROR! ErrorCodeIOException 19468". I'm going to run
conversions continually and see what happens.
Comment 11 Stephan Bergmann 2009-09-04 09:45:24 UTC
@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).
Comment 12 pjessen 2009-09-04 09:58:15 UTC
Sorry, looks like I didn't get the test script running properly. Will try the
continuous conversions again. 
Comment 13 pjessen 2009-09-04 10:02:48 UTC
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'


ERROR! ErrorCodeIOException 283
Comment 14 Stephan Bergmann 2009-09-04 10:56:46 UTC
@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.
Comment 15 pjessen 2009-09-04 11:31:54 UTC
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.
Comment 16 Stephan Bergmann 2009-09-04 12:30:50 UTC
@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?
Comment 17 pjessen 2009-09-04 13:06:50 UTC
No, the soffice-bin process is stable, the problems are reported by the python
Wrt ErrorCodeIOException 283, it does appear to be caused by a particular document. 
Comment 18 Stephan Bergmann 2009-09-04 13:44:10 UTC
@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 process terminates with
std::bad_alloc.  (This would appear to be a problem of the Python--UNO bridge.)

2  The python 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."
Comment 19 thorsten.ziehm 2009-11-06 08:41:10 UTC
Until this issue will be changed as suggested by SB the issue will be set to
target OOo 3.x.
Comment 20 Rob Weir 2013-02-02 02:56:16 UTC
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

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
Comment 21 Rob Weir 2013-07-30 02:36:44 UTC
Reset assignee on issues not touched by assignee in more than 1000 days.