Bug 52068

Summary: portupgrade of editors/openoffice .org-1.0.3 stalls running installer
Product: Ports & Packages Reporter: areilly
Component: Individual Port(s)Assignee: freebsd-openoffice (Nobody) <openoffice>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
openoffice_install_error.png none

Description areilly 2003-05-11 10:00:35 UTC
	Portupgrade at openoffice.org gets as far as backing up
	the previous version, then hangs, executing what it says
	is the installer.  soffice.bin is spinning, using
	100-epsilon CPU.  I kill -QUIT'ed that process, and
	portupgrade /ignored/ the error, and proceeded with the
	installation.  I now have an openoffice installation
	that produces the attached popup window.  This is
	actually a retrograde step from the failure that
	happened at that point two weeks ago, because then it
	backed the new version out, and restored 1.0.2.

Fix: Don't know how to fix.  In fact, given the lack of noise
	on the mailing lists about this problem, the fault is
	almost certainly something to do with the setup of my
	system.  Hints about how to detect the fault would be
	appreciated.  I have both native java-1.3.1p8_1 and
	jdk-1.4.1p3_3 installed, if that makes any difference.

	Cheers,

	Andrew
How-To-Repeat: 	Have openoffice.org-1.0.2 installed, and use portupgrade
	to install current port version.
Comment 1 Tilman Keskinoz freebsd_committer freebsd_triage 2003-05-12 00:41:49 UTC
Responsible Changed
From-To: freebsd-ports-bugs->openoffice

Over to maintainers
Comment 2 Martin Blapp freebsd_committer freebsd_triage 2003-05-13 19:03:55 UTC
State Changed
From-To: open->analyzed

The problem is that our openoffice install assumes that 
no previous version is installed at the same location. If thats 
the case, it will just hang. 

So please move the old openoffice dir to a backup location, 
then try again and report your success.
Comment 3 areilly 2003-05-29 01:15:06 UTC
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
Comment 4 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: feedback->closed

If this is still a problem with the latest (3.23.58) one, please 
resubmit the problem. Most likely it was caused by the not running 
of ldconfig by the port. If it still occures, please add the output 
of "ldconfig -r" to the PR.
Comment 5 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

euhmm.. I'll redit this PR.
Comment 6 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open
Comment 7 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open
Comment 8 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses.
Comment 9 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 10 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 11 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 12 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 13 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 14 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 15 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 16 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix category
Comment 17 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopsesFix synopsesFix synopses
Comment 18 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 19 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 20 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 21 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: open->open

Fix synopses
Comment 22 Edwin Groothuis freebsd_committer freebsd_triage 2003-09-28 02:35:21 UTC
State Changed
From-To: analyzed->analyzed

Fix synopses
Comment 23 Florent Thoumie freebsd_committer freebsd_triage 2005-06-06 12:48:57 UTC
State Changed
From-To: analyzed->closed

ports/61760 describes the same issue, no need to keep both PRs.