Bug#433417: openoffice hangs, takes all CPU when port 631 (CUPS) is in use

Package: openoffice.org-common
Version: 2.0.4.dfsg.2-7etch1
Severity: normal

On occasion, nfs.mountd is able to bind to the CUPS port
(631/tcp),
which causes openoffice to think that CUPS is available on
the system.
It repeatedly tries to talk to it, hangs and takes all CPU.

I think this is the same bug identified here but affecting
WINE:
http://www.winehq.org/pipermail/wine-bugs/2005-May
/013175.html

This is trivially reproducible by starting netcat (nc -l -p
631) and
trying to save a document or manage printers in openoffice.
Adding 
"export SAL_DISABLE_CUPS=1" to
/etc/openoffice/openoffice.conf makes
no difference.

Typical strace output for openoffice:
[pid 30785] sendto(5, "POST /
HTTP/1.1rnContent-Length:"..., 134, 0, NULL, 0) =
134
[pid 30785] sendto(5, "11211G22attributes-charset5"...,
350, 0, NULL, 0) = 350
[pid 30785] select(6, [5], NULL, NULL, {1, 0}) = 1 (in [5],
left {1, 0})
[pid 30785] recvfrom(5, "", 2048, 0, NULL, NULL) =
0
[pid 30785] close(5)                    = 0
[pid 30785] socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
[pid 30785] setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4)
= 0
[pid 30785] setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 30785] fcntl(5, F_SETFD, FD_CLOEXEC) = 0
[pid 30785] connect(5, {sa_family=AF_INET,
sin_port=htons(631),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
[pid 30785] sendto(5, "POST /
HTTP/1.1rnContent-Length:"..., 134, 0, NULL, 0) =
134
[pid 30785] sendto(5, "11211G22attributes-charset5"...,
350, 0, NULL, 0) = 350
[pid 30785] select(6, [5], NULL, NULL, {1, 0}) = 1 (in [5],
left {1, 0})
[pid 30785] recvfrom(5, "", 2048, 0, NULL, NULL) =
0
[pid 30785] close(5)                    = 0
[pid 30785] socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
[pid 30785] setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4)
= 0
[pid 30785] setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 30785] fcntl(5, F_SETFD, FD_CLOEXEC) = 0
....


Stack trace:
#0  0x00002abdd759f0f5 in pthread_join () from
/lib/libpthread.so.0
#1  0x00002abdd68c0ca2 in osl_joinWithThread ()
   from /usr/lib/openoffice/program/libuno_sal.so.3
#2  0x00002abdd898f7ef in
psp::CUPSManager::checkPrintersChanged ()
   from /usr/lib/openoffice/program/libpsp680lx.so
#3  0x00002abdda21e6f5 in
X11SalInstance::GetPrinterQueueInfo ()
   from /usr/lib/openoffice/program/libvclplug_gen680lx.so
#4  0x00002abdd521c5b7 in Printer::GetDefaultPrinterName ()
   from /usr/lib/openoffice/program/libvcl680lx.so
#5  0x00002abdd521efaf in Printer::Printer ()
   from /usr/lib/openoffice/program/libvcl680lx.so
#6  0x00002aaaaddc12ce in SfxPrinter::SfxPrinter ()
   from /usr/lib/openoffice/program/libsfx680lx.so
#7  0x00002aaab24cf822 in ScDocument::GetFilterEntriesArea
()
   from /usr/lib/openoffice/program/libsc680lx.so
#8  0x00002aaaaddc660d in SfxViewShell::Print ()
   from /usr/lib/openoffice/program/libsfx680lx.so
#9  0x00002aaaaddf3eff in SfxDispatcher::Execute ()
   from /usr/lib/openoffice/program/libsfx680lx.so
#10 0x00002aaaaddf4651 in SfxDispatcher::_Execute ()
   from /usr/lib/openoffice/program/libsfx680lx.so
#11 0x00002aaaade2002a in non-virtual thunk to
SvxSearchItem::~SvxSearchItem() ()
   from /usr/lib/openoffice/program/libsfx680lx.so
#12 0x00002abdd5331958 in Window::~Window ()
   from /usr/lib/openoffice/program/libvcl680lx.so
#13 0x00002abdda230d45 in SalDisplay:ispatchI
nternalEvent ()
   from /usr/lib/openoffice/program/libvclplug_gen680lx.so
#14 0x00002abdda230d6e in SalX11Display::Yield ()
   from /usr/lib/openoffice/program/libvclplug_gen680lx.so
#15 0x00002abdda230b57 in SalDisplay::registerFrame ()
   from /usr/lib/openoffice/program/libvclplug_gen680lx.so
#16 0x00002abdda228c3f in SalXLib::Yield ()
   from /usr/lib/openoffice/program/libvclplug_gen680lx.so
#17 0x00002abdd5169330 in Application::Yield ()
   from /usr/lib/openoffice/program/libvcl680lx.so
#18 0x00002abdd51693c7 in Application::Execute ()
   from /usr/lib/openoffice/program/libvcl680lx.so
---Type <return> to continue, or q <return> to
quit--- 
#19 0x0000000000428fb0 in desktop:esktop::
Main ()
#20 0x00002abdd516ecc4 in InitVCL () from
/usr/lib/openoffice/program/libvcl680lx.so
#21 0x00002abdd516edb5 in SVMain () from
/usr/lib/openoffice/program/libvcl680lx.so
#22 0x000000000041bfba in sal_main ()
#23 0x00002abdd7d364ca in __libc_start_main () from
/lib/libc.so.6
#24 0x000000000041beea in _start ()


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
(charmap=UTF-8)

Versions of packages openoffice.org-common depends on:
ii  dictionaries-common [openoffi 0.70.10    Common
utilities for spelling dict

openoffice.org-common recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-openoffice-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

Hi Rene,

| And why is this a OOo bug? Of course OOo should not hang
here, but
| IMHO it's a bug in your system. 631 is IPP.

This was actually my first evaluation too. However, OOo
makes the big 
assumption that if something is listening on port 631 then
you must have
a CUPS enabled system, which is wrong. The correct detection
should be 
smarter IMHO: Since CUPS follows an HTTP type protocol, the
library doing
this work should look for an actual application response
according to the 
CUPS protocol. What if your CUPS daemon is hung? You won't
be able to save
your documents.

I looked at the library dependencies in OOo, and it seems
like it is using
its own libraries rather than using libcups2. So I filed
this bug against OOo 
itself.

In addition, the detection process should be done
asynchronously. Assuming 
mountd can be configured/patched to not use this particular
port, some other
application may. OOo should not hang completely, only the
printing function
should be affected. Hopefully it will simply say 'printing
system not working'
or similar.

I think that for the typical user this type of situation is
hard to detect
and troubleshoot. It seemed better to take care of it in OOo
itself once and 
for all, rather than look for and fix each and every daemon
that may 
potentially bind to 631/tcp inadvertedly.

| > "export SAL_DISABLE_CUPS=1" to
/etc/openoffice/openoffice.conf makes
| > no difference.
| 
| That would mean I'd break my cups...

The point here is that this config was supposed to disable
CUPS altogether
for OOo. It didn't work in my case.

What do you think? I haven't filed a bug against rpc.mountd
but can do.

thanks,
Kostas


-- 
To UNSUBSCRIBE, email to debian-openoffice-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

[ NO NEED TO CC ME, I GET MAILS TO NNNBUGS SINCE THEY GO TO
-OPENOFFICE ]

HI,

KOSTAS EVANGELINOS WROTE:
> | AND WHY IS THIS A OOO BUG? OF COURSE OOO SHOULD NOT
HANG HERE, BUT
> | IMHO IT'S A BUG IN YOUR SYSTEM. 631 IS IPP.
> 
> THIS WAS ACTUALLY MY FIRST EVALUATION TOO. HOWEVER, OOO
MAKES THE BIG 
> ASSUMPTION THAT IF SOMETHING IS LISTENING ON PORT 631
THEN YOU MUST HAVE
> A CUPS ENABLED SYSTEM, WHICH IS WRONG. THE CORRECT
DETECTION SHOULD BE 

NO, IMHO THAT'S COMPLETELY RIGHT. 631 IS IPP AND NOTHING
ELSE. POINT.
IF YOU HAVE SOMETHIG ELSE THERE -> YOUR SYSTEM IS
BROKEN.

> I LOOKED AT THE LIBRARY DEPENDENCIES IN OOO, AND IT
SEEMS LIKE IT IS USING
> ITS OWN LIBRARIES RATHER THAN USING LIBCUPS2. SO I
FILED THIS BUG AGAINST OOO 
> ITSELF.

WTRONG. IT DLOPEN()S LIBCUPS IF IT'S THERE.

> IN ADDITION, THE DETECTION PROCESS SHOULD BE DONE
ASYNCHRONOUSLY. ASSUMING 
> MOUNTD CAN BE CONFIGURED/PATCHED TO NOT USE THIS
PARTICULAR PORT, SOME OTHER
> APPLICATION MAY. [...]

WHCIH THEN STRILL IS A BIG IN THAT APPS. WOULSDN'T YOU ALSO
FIND IT
WEIRD IF SOMETHING ELSE ATTACHED ITSELF TO 80 AND YOU GET
WEIRD STUFF
INSTEAD OF AN HTTP SERVER? OR THE SAME FOR FRP OR SSH OR
WHATEVER?

> SHOULD BE AFFECTED. HOPEFULLY IT WILL SIMPLY SAY
'PRINTING SYSTEM NOT WORKING'
> OR SIMILAR.
> 
> I THINK THAT FOR THE TYPICAL USER THIS TYPE OF
SITUATION IS HARD TO DETECT
> AND TROUBLESHOOT. IT SEEMED BETTER TO TAKE CARE OF IT
IN OOO ITSELF ONCE AND 
> FOR ALL, RATHER THAN LOOK FOR AND FIX EACH AND EVERY
DAEMON THAT MAY 
> POTENTIALLY BIND TO 631/TCP INADVERTEDLY.
> 
> | > "EXPORT SAL_DISABLE_CUPS=1" TO
/ETC/OPENOFFICE/OPENOFFICE.CONF MAKES
> | > NO DIFFERENCE.
> | 
> | THAT WOULD MEAN I'D BREAK MY CUPS...
> 
> THE POINT HERE IS THAT THIS CONFIG WAS SUPPOSED TO
DISABLE CUPS ALTOGETHER
> FOR OOO. IT DIDN'T WORK IN MY CASE.

NO, YOU SAID I SHOULD TRY IT, WHICH PROBABLY WOULD NEED TO
BRAK MY CUPS
BY PUTTING SOMETING ELSE ON ITS PORT..

> WHAT DO YOU THINK? I HAVEN'T FILED A BUG AGAINST
RPC.MOUNTD BUT CAN DO.

PLEASE DO. AND MAYBE ALSO LIBCUPSYS2? (SEE ABOVE). YOU CAN
REASSIGN
THIS, TOO.

GR?E/REGARDS,

REN?
-- 
 .''`.  REN?ENGELHARD -- DEBIAN GNU/LINUX DEVELOPER
 : :' : HTTP://WWW.DEBIAN.ORG |
HTTP://PEOPLE.DEBIAN.ORG/~RENE/
 `. `'  RENEDEBIAN.ORG | GNUPG-KEY ID: 248AEB73
   `-   FINGERPRINT: 41FA F208 28D4 7CA5 19BB  7AD9 F859
90B0 248A EB73