[hardy] no longer possible to use 'openoffice my-document.odp' in a terminal

[Brian Murray]

Binary package hint: openoffice.org

In Gutsy I used to be able to open openoffice documents via 'openoffice my-doc.odt' in a gnome-terminal session. However, when I try to do that now in Hardy I receive the following:

bdmurray@flash:~/Documents/gtd$ openoffice ~/mythtv.odp
Error forking '/usr/lib/openoffice/program//soffice': 'Failed to execute child process "/usr/lib/openoffice/program/soffice" (Bad address)'

This happens regardless of the file type I am opening. I have openoffice.org version 1:2.3.0-1ubuntu5.3 installed.

[Steve Langasek (vorlon)]

Reproducible here on amd64. Can be reproduced just by running "oowriter", or to bypass the wrapper script, "OOO_EXTRA_ARG=-writer /usr/lib/openoffice/program/ooqstart".

Here's a snippet from strace:

[pid 12231] execve("/usr/lib/openoffice/program/soffice", ["/usr/lib/openoffice/program/soffice", "-writer", "-splash-pipe=5", umovestr: Input/output error
0x71, "\360!a", "\360!a", umovestr: Input/output error
0x6f632f6465746567, umovestr: Input/output error
0x732f73747865746e, umovestr: Input/output error
0x7974746572756365, umovestr: Input/output error
0x73657079745f], [/* 39 vars */]) = -1 EFAULT (Bad address)

The use of clone() by ooqstart seems odd to me; I don't understand why it would clone twice using the same address for child_tidptr both times, perhaps that could account for the problem?

Oh, and oowriter starts successfully under valgrind, with the following indicative warning:

==13824== Syscall param execve(argv) points to uninitialised byte(s)
==13824== at 0x548DF27: execve (in /lib/libc-2.7.so)
==13824== by 0x4E91374: (within /usr/lib/libglib-2.0.so.0.1500.0)
==13824== by 0x4E91977: (within /usr/lib/libglib-2.0.so.0.1500.0)
==13824== by 0x4E91FB8: g_spawn_async_with_pipes (in /usr/lib/libglib-2.0.so.0.1500.0)
==13824== by 0x4E9209C: g_spawn_async (in /usr/lib/libglib-2.0.so.0.1500.0)
==13824== by 0x405A7C: main (in /usr/lib/openoffice/program/ooqstart)

All this seems to add up to ooqstart failing to null-terminate the argv[] array that it's passing when calling execve().

[Robbert (robbertkrebbers)]

I can confirm this problem too:

robbert@robbert:~$ oowriter
Error forking '/usr/lib/openoffice/program//soffice': 'Failed to execute child process "/usr/lib/openoffice/program/soffice" (Bad address)'
robbert@robbert:~$ openoffice -base
Error forking '/usr/lib/openoffice/program//soffice': 'Failed to execute child process "/usr/lib/openoffice/program/soffice" (Bad address)'
robbert@robbert:~$ openoffice bla
Error forking '/usr/lib/openoffice/program//soffice': 'Failed to execute child process "/usr/lib/openoffice/program/soffice" (Bad address)'
robbert@robbert:~$ openoffice test.ods
Error forking '/usr/lib/openoffice/program//soffice': 'Failed to execute child process "/usr/lib/openoffice/program/soffice" (Bad address)'
robbert@robbert:~$ openoffice

Running openoffice without any arguments works fine.

[der_vegi (m-may)]

Yup, here too, amd64 with all updates until today. Opening a file over nautilus etc. does not work, either.

[dutchcow (dutchcow)]

Confirmed on my install (hardy) too, all packages are up to date (14 jan 2008). Double clicking icons in the file manager or via menu don't work at all, no error messages, running any openoffice related command in the console gives same errors as stated above by others except for "openoffice" itself which starts fine as mentioned above too.

[Christian Schürer-Waldheim (quincunx)]

Problem doesn't occur anymore after the latest update of openoffice to version 2.3.1.

[Brian Murray (brian-murray)]

This has been fixed for me using OpenOffice package version 2.3.1-3ubuntu2 on Hardy.