ports/52068: portupgrade of openoffice.org-1.0.3 stalls running installer

[Andrew Reilly]

The following reply was made to PR ports/52068; it has been noted by GNATS.

From: Andrew Reilly <areilly at bigpond.net.au>
To: freebsd-gnats-submit at FreeBSD.org, areilly at bigpond.net.au
Cc:  
Subject: Re: ports/52068: portupgrade of openoffice.org-1.0.3 stalls running
 installer
Date: Thu, 29 May 2003 10:15:06 +1000

 Hi,
 
 I've just tried installing openoffice again, and it stalled again 
 (several times), and it has finally failed in the same way that I 
 described before.  I made certain that all traces of openoffice 
 had been removed from my system before starting the build process.
 
 The screen image that I attached to my previous report was what 
 happened when I tried to start openoffice after the installation 
 process finished.  However, the installation process did not get 
 to "finished" without intervention from me:
 
 In several places during the build, saxparser stalled, and I 
 killed that process and restarted the make (without first cleaning 
 everything up) and it continued.  saxparser had been busy building 
 what looked like i18n modules for languages/locales that I don't 
 care about, so I was not concerned if they were corrupted.
 
 At the end, when the make install process (i.e., top-level BSD 
 port make) said:
 ===>  Installing for openoffice-1.0.3_2
 
 Initializing installation program..........
 *** Error code 255 (ignored)
 ===>   Generating temporary packing list
 ===>  Add wrapper scripts
 ===>   Registering installation for openoffice-1.0.3_2
 ===>  SECURITY REPORT:
 
 That Error code 255 (ignored) was me killing the soffice.bin 
 executable, because it had been consuming 90+% of the CPU for the 
 whole night, and that seemed unreasonable.
 
 These problems (and the others that I'm experiencing with sawfish) 
 seem to me to be consistent with deadlock conditions in 
 multi-threaded applications that are making unwarrented 
 assumptions about the thread implementation, or perhaps bugs in 
 the thread implementation.
 
 I'm thinking of upgrading to 5.x, just to get kernel-based 
 threads, to be more like Linux and Solaris, where these 
 applications are presumably more tested.  Is that a reasonable 
 approach?
 
 -- 
 Andrew