Comment 1 Mark Linimon 2004-12-14 09:49:24 UTC

Responsible Changed
From-To: freebsd-ports-bugs->openoffice

Over to maintainer.

Some followup info:

Everything else on this system is working well, except that "dd" writing to a 
floppy is terribly slow.

Ran openoffice on a Pentium II 350 system installed from the same CD - no 
problems.

Also ran openoffice on a 5.3-RC1 system - again, no problems.

Ran several passes of memtest86 on the K6-2, AND tried replacing memory chip.
Javaldx and soffice still crash.

Reassembled the machine to ensure all connections are secure and clean.

Rebuilt the kernel.

Tried to build openoffice from port:

[snip]
Making Module-Definitionfile : ../unxfbsd.pro/misc/sal.def
just a dummy for UNIX
cp 
-f /usr/ports/editors/openoffice-1.1/work/oo_1.1.2_src/solenv/src/default_description.xml ../unxfbsd.pro/misc/sal.xml
xml2cmp 
-func ../unxfbsd.pro/misc/sal_description.cxx ../unxfbsd.pro/misc/sal.xml
Segmentation fault (core dumped)
dmake:  Error code 139, while making '../unxfbsd.pro/misc/sal_description.cxx'
---* TG_SLO.MK *---

ERROR: Error 65280 occurred while 
making /usr/ports/editors/openoffice-1.1/work/oo_1.1.2_src/sal/util
dmake:  Error code 1, while making 'build_all'
---* TG_SLO.MK *---
*** Error code 255

Stop in /usr/ports/editors/openoffice-1.1.
<<<ROOT@sculpin>>> /usr/ports/editors/openoffice-1.1 47 #

Interestingly enough, the build process, like javaldx, crashed during a call 
to the pthread library:

(gdb) where
#0  0x2809f46c in pthread_setconcurrency () from /usr/lib/libpthread.so.1
#1  0x2809e9a6 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1
#2  0x2809f84f in pthread_setconcurrency () from /usr/lib/libpthread.so.1
#3  0x280a2e76 in pthread_testcancel () from /usr/lib/libpthread.so.1
#4  0x280a3fee in __error () from /usr/lib/libpthread.so.1
#5  0x2808b792 in ?? () from /usr/lib/libpthread.so.1
#6  0x2805ffc9 in find_symdef () from /usr/libexec/ld-elf.so.1
#7  0x2805ed73 in _rtld () from /usr/libexec/ld-elf.so.1
#8  0x2805e836 in .rtld_start () from /usr/libexec/ld-elf.so.1

Could there be a problem with pthread specific to the K6-2?

More followup info:

Same problem occurs with oo-1.1.2 and oo-1.1.3.

Rebuilt libpthread.so.1 with -g.  This pinpointed the seg fault to the exact 
source statement.  Unfortunately, it's inline assembly code, and I don't have 
a clue what the statement is supposed to do:

sculpin bacon ~ 208: openoffice-1.1.3                                           
Segmentation fault (core dumped)
Segmentation fault (core dumped)
sculpin bacon ~ 209: gdb /usr/local/OpenOffice.org1.1.3/program/javaldx 
javaldx.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols 
found)...
Core was generated by `javaldx'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/OpenOffice.org1.1.3/program/libsal.so.3...(no 
debugging symbols found)...done.
Loaded symbols for /usr/local/OpenOffice.org1.1.3/program/libsal.so.3
Reading symbols from /usr/local/OpenOffice.org1.1.3/program/libcppu.so.3...(no 
debugging symbols found)...done.
Loaded symbols for /usr/local/OpenOffice.org1.1.3/program/libcppu.so.3
Reading symbols 
from /usr/local/OpenOffice.org1.1.3/program/libjvmaccessgcc3.so.3...(no 
debugging symbols found)...done.
Loaded symbols 
for /usr/local/OpenOffice.org1.1.3/program/libjvmaccessgcc3.so.3
Reading symbols from /usr/lib/libpthread.so.1...done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /lib/libm.so.3...done.
Loaded symbols for /lib/libm.so.3
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols 
from /usr/local/OpenOffice.org1.1.3/program/libstlport_gcc.so...done.
Loaded symbols for /usr/local/OpenOffice.org1.1.3/program/libstlport_gcc.so
Reading symbols 
from /usr/local/OpenOffice.org1.1.3/program/libsalhelpergcc3.so.3...done.
Loaded symbols 
for /usr/local/OpenOffice.org1.1.3/program/libsalhelpergcc3.so.3
Reading symbols from /usr/libexec/ld-elf.so.1...done.
Loaded symbols for /usr/libexec/ld-elf.so.1
#0  _tcb_ctor (thread=0x0, initial=1)
    at /usr/src/lib/libpthread/arch/i386/i386/pthread_md.c:52
52                      __asm __volatile("movl %%gs:0, %0" : "=r" (oldtls));
(gdb)

FYI, I had a similar problem with bind causing crashes on a box that was 
upgraded from 5.2.1.  The problem was that the schg flag is set on 
/libexec/ld-elf.so.1, and a binary upgrade doesn't account for that.  If 
you check the timestamp of the ld-elf.so.1 file and it is older than 
November 2004, I bet this is the problem.  Run "chflags noschg 
/libexec/ld-elf.so.1", then copy over the correct binary version, or 
make obj/make/make install in /usr/src/libexec/rtld-elf to get a recent 
copy, and all affected applications should start working again.

Interesting...

I've actually never used an upgrade - as always, I reformatted everything 
except /usr, and there I dropped to single user mode and rm -rf'd 
everthing except home before installing.  I did this twice this time 
around, on the assumption that something may have gotten corrupted during 
the first install, so I was careful not to stray from standard procedures 
the second time around.

My original ld-elf:

<<<ROOT@sculpin>>> /home/bacon 372 # ls -lo /libexec/ld-elf.so.1
-r-xr-xr-x  1 root  wheel  - 141604 Nov  4 19:24 /libexec/ld-elf.so.1*

I ran chflags anyway, and it had no effect.

Interesting part is, rebuilding it did the trick.

<<<ROOT@sculpin>>> /usr/src/libexec/rtld-elf 386 # make obj
/usr/obj/usr/src/libexec/rtld-elf created for /usr/src/libexec/rtld-elf
<<<ROOT@sculpin>>> /usr/src/libexec/rtld-elf 387 # make
cc -O -pipe  -Wall -DFREEBSD_ELF -DIN_RTLD 
-I/usr/src/libexec/rtld-elf/i386 -I/u

[snip]

<<<ROOT@sculpin>>> /usr/src/libexec/rtld-elf 388 # make install
chflags noschg /usr/libexec/ld-elf.so.1
install -s -o root -g wheel -m 555  -fschg -C -b ld-elf.so.1 /libexec
install -o root -g wheel -m 444 rtld.1.gz  /usr/share/man/man1
/usr/share/man/man1/ld-elf.so.1.1.gz -> /usr/share/man/man1/rtld.1.gz
/usr/share/man/man1/ld.so.1.gz -> /usr/share/man/man1/rtld.1.gz
/usr/libexec/ld-elf.so.1 -> /libexec/ld-elf.so.1

Now openoffice-1.1.3 works, but I'm a bit confused, since it appears make 
install set schg:

<<<ROOT@sculpin>>> /usr/src/libexec/rtld-elf 393 # ls -lo /libexec/ld-elf.so.1
-r-xr-xr-x  1 root  wheel  schg 141604 Nov  4 19:24 /libexec/ld-elf.so.1*

A little experiment:

<<<ROOT@sculpin>>> /usr/src/libexec/rtld-elf 397 # chflags noschg /libexec/ld-elf.so.1
<<<ROOT@sculpin>>> /usr/src/libexec/rtld-elf 398 # ls -lo /libexec/ld-elf.so.1
-r-xr-xr-x  1 root  wheel  - 141604 Nov  4 19:24 /libexec/ld-elf.so.1*

OpenOffice still works!

<<<ROOT@sculpin>>> /usr/src/libexec/rtld-elf 399 # chflags schg /libexec/ld-elf.so.1
<<<ROOT@sculpin>>> /usr/src/libexec/rtld-elf 400 # ls -lo /libexec/ld-elf.so.1
-r-xr-xr-x  1 root  wheel  schg 141604 Nov  4 19:24 /libexec/ld-elf.so.1*

Still works!

So rebuilding ld-elf.so.1 did the trick, but not because of the schg flag.

Furthermore, the old ld-elf.so.1 and the alleged new one I just built are 
the same size so I ran a cmp (against one from another machine installed 
from the same iso image) - it verified that they're identical.  I doubt 
the binary was corrupted during install, since as I said, I did TWO 
pristine installations with the same results (the second was from a new CD 
as well).

The only other thing the install did was create a link in /usr/libexec, so 
I removed it and tried running OpenOffice again, but it just said

ELF interpreter /usr/libexec/ld-elf.so.1 not found

Well, it bugs me that I don't know why it's working, but it is, so thanks!

 	Jason


On Sat, 22 Jan 2005, Chris Bongaarts wrote:

> FYI, I had a similar problem with bind causing crashes on a box that was 
> upgraded from 5.2.1.  The problem was that the schg flag is set on 
> /libexec/ld-elf.so.1, and a binary upgrade doesn't account for that.  If you 
> check the timestamp of the ld-elf.so.1 file and it is older than November 
> 2004, I bet this is the problem.  Run "chflags noschg /libexec/ld-elf.so.1", 
> then copy over the correct binary version, or make obj/make/make install in 
> /usr/src/libexec/rtld-elf to get a recent copy, and all affected applications 
> should start working again.
>
>

Comment 6 Maho Nakata 2005-06-19 03:50:53 UTC

State Changed
From-To: open->closed

It seems that problem had already been fixed. 
Thank you very much for your report!