Created attachment 558 [details]
strace -f -v ./setup packed with bzip2

I was unaware at the first time that the setup.bin
produced a "Segmentation fault", so I don't know that
the problem is related to the above mentioned ones or not.
That's why attached the strace packed with bzip2.

Don't know that related or not:
all the setrlimit system calls fail as teir 1st arg
is invalid. (EINVAL)

(Other funny lines in the strace when the /dev/null
is attempted to open as a directory, or at the clean
up attempts to unlink . and .. )

Thanks

incze

It's duplicate.
Please have a look at
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=31879
There you'll find a workaround.

*** This issue has been marked as a duplicate of 863 ***

.

If it was an S3 issue how could the 638 and SO 5.2 install (the former
crashed on MS documents, the later is healthy and running)? /OTOH
I do not use the accelerated S3 but the standard XFree86-SVGA driver,
this card is not a Savage but a much less capable Trio3D card./
--------------------- the proposed workaround --------------------
[incze@senorg install]$ env | grep SAL
SAL_DO_NOT_USE_INVERT50=true
[incze@senorg install]$ ./setup
glibc version: 2.2.2
[incze@senorg install]$

Update. I've updated my configuration with the recent
patches from RedHat (means glibc-2.2.4-19). The 638c
crashes the same way as before.

I downloaded the Staroffice 6.0 beta to see (as I know
it is basically the same code base as 638c with some tweaks)
and experience the very same setup crash.

Build 633 worked for me well on an RH 6.2 system,
so just being courious downloaded it. And bang. It
installs and even works, doesn't bomb on the same MS
documents than 638. These 638 crashes on opening a
document seemed not to be a documnt parse error,
rather some nasty X-handling bug, the window came up,
and the everything has disappeared. So, it seems that
something in the X window handling is going on and
it is worse and worse (from 638 to 638c) on a category
of video drivers.

Hi Herbert,
may I hand this over to you? You are inverstigating in these problems
and maybe you have the right answers.

I have done a workaround for a bug that got into XFree 4.1.0.
Even for XFree 4.1.0 it shows up only for some graphics cards
and bit depths. Since here 4.1.0 is not involved the problem
is somewhere else:

From the strace provided above I can see that it seems the crash
happens in the initialization of libsmgr.so while doing something
in a /tmp/sv001.tmp directory. Hope this helps.

Well, /tmp/sv001.tmp seems to be just the directory where install files
are dployed and the installer is working from. I think the libsmgr.so
tip is a bad one. It seems to be a "service manager" not related at
all to any X window/video problem. So, things happen after the service
manager was loaded (and initialized?) but I don't think it would be
related to it. I woud test what was changed in the code that puts up
the initial splash panel: between 638 and 638c.

As I see things became wronger and wronger (at least on some video
model) from 633 to 638 and then from 638 to 638c. Seemingly, the code
base is in some optimization phase.

I have the Crash problem to!

But I see the setup - background - and then a dialog window is showing
up. Showing only the line above the buttons and then the "Next" button.

Machine is totally frozen

Red Hat 7.1 2.4.9-6
Pentium II 233MHz 384MB RAM
S3 Savage4 32MB

I'll try the Red Hat S3 fix - and then post any new info.

/Erling Damsgaard
famdam@tdcadsl.dk

I'm willing to provide any data I can to help getting this fixed 
(this really annoys me):


OOo 638C, and so6beta both english and german crash while trying to 
install. 
this is what the terminal says:

timon@superlinux:~/KDesktop >  so-6_0-beta-bin-linux-de.bin
glibc version: 2.2.2
timon@superlinux:~/KDesktop >

exact same thing fort the other versions I mentioned. Kevin B. 
Hendricks 
analysed a strace- output of the install-try, this is part of his 
answer:

1. the problem is caused by a segfault

2.  The problem seems to happen when dlopening (or simply loading) 
the 
following shared library: libsmgr.so

1184  open("./libsmgr.so", O_RDONLY)    = 7
1184  read(7, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000-\1\000"..., 
1024) = 
1024
1184  fstat64(7, {st_dev=makedev(3, 8), st_ino=180920, 
st_mode=S_IFREG|0755, st_nlink=1, st_uid=500, st_gid=100, 
st_blksize=4096, 
st_blocks=504, st_size=254715, st_atime=2001/10/04-01:09:41, 
st_mtime=2001/09/18-22:44:46, st_ctime=2001/10/04-01:09:35}) = 0
1184  getcwd("/tmp/sv001.tmp", 128)     = 15
1184  old_mmap(NULL, 199376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) 
= 
0x41a97000
1184  mprotect(0x41ac1000, 27344, PROT_NONE) = 0
1184  old_mmap(0x41ac1000, 28672, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED, 7, 0x29000) = 0x41ac1000
1184  close(7)                          = 0
1184  --- SIGSEGV (Segmentation fault) ---

I can't install 638C, so6beta en or de...

I'm using SuSE7.2, customized in some details but for the most part 
what came 
with the distribution.

I'll do anything I can to help you track this down- older OOo 
realeases 
worked, I want to se this one working, too!!!

---and:---

I upgraded to SuSE7.3. I tried XF4.1.0 with fbdev and even XF336 
which made no difference at all, at least not fpr the output to the 
terminal...

So this can't be related to XF4.1.0

btw: my video card is a gforce2mx from nvidia.

again: I'm willing to provide any data I can to help getting this 
fixed!

Hi Christof,
is this something you (we) know about?

*** Issue 1977 has been marked as a duplicate of this issue. ***

Some Matrox cards had difficulties to draw with
fill_style=FillStippled. In that case you can set the environment
variable SAL_DO_NOT_USE_INVERT50 to the value "true". 
The result of that bug was a freeze of the XServer. 
If SO crashes it will be a different story. Can we reproduce the bug
inhouse ? Any volunteer to debug that ? Come on, everybody with a
drivers licence can use a debugger :-)

Let me emphasis again: libsmgr.so seems to be innocent, it is some
service manager/registry (seemingly java JNI) library, not related at
all to any X window/video problem. It is just that it was the last
straced action before the crash.

The culprit is the X initialization. I guess that many things was
optimized in the screen handling between 633-638-638C. Some of the
optimizations made crashy the installed 638, further ones made crashy
the installation. Many linuxers (me, too) use 16 bit color model. It
caused to netscape some troubles in the past, maybe we have something
like that now, too. Other crashers use 16 bit, either?

incze

I tried 8bit, 16bit and 24bit colors, setup (638c) crashed the same 
way each time...

Hi Christof,

I followed your instructions here's the results:


I used install638C_linux_intel.tar.gz

unpacked to /home/timon/tmp

here is my first try:

timon@superlinux:~> cd tmp/install
timon@superlinux:~/tmp/install> gdb setup
GNU gdb 20010316
Copyright 2001 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-suse-linux"...
(gdb) break fork
Function "fork" not defined.
(gdb) run
Starting program: /home/timon/tmp/install/setup
[New Thread 1024 (LWP 1076)]
glibc version: 2.2.4

Program exited with code 01.
(gdb)

obviously something didn't work here, "fork" was not known, and the 
prog exited as it always did...

What am I to do?

Thanks for your mail Christof, here is the gdb output you asked for:

For everybody else I attached a file with the whole procedure so you 
can try to reproduce this...

(gdb) run
Starting program: /tmp/sv001.tmp/setup.bin
[New Thread 1024 (LWP 1045)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 1045)]
0x413c0008 in _STL::__node_alloc<true, 0>::allocate ()
    at ./cp/new.cc:41
41      ./cp/new.cc: No such file or directory.
        in ./cp/new.cc
Current language:  auto; currently c++
(gdb) where
#0  0x413c0008 in _STL::__node_alloc<true, 0>::allocate ()
    at ./cp/new.cc:41
#1  0x40245d0b in _STL::hashtable<_STL::pair<void *const, 
_STL::pair<unsigned long, unsigned char (*)> >, void *, hashModule, 
_STL::_Select1st<_STL::pair<void *const, _STL::pair<unsigned long, 
unsigned char (*)> > >, equalModule, _STL::allocator<_STL::pair<void 
*const, _STL::pair<unsigned long, unsigned char (*)> > > 
>::find_or_insert () from ./libsal.so.3
#2  0x4024136e in rtl_registerModuleForUnloading ()
   from ./libsal.so.3
#3  0x40124a7c in cppu::loadSharedLibComponentFactory ()
   from ./libcppuhelper3GCC.so
#4  0x40107c49 in cppu::bootstrapInitialSF ()
   from ./libcppuhelper3GCC.so
#5  0x4010c22d in cppu::defaultBootstrap_InitialComponentContext
    () from ./libcppuhelper3GCC.so
#6  0x08056474 in SetupApp::Main ()
#7  0x404c4389 in SVMain () from ./libvcl638li.so
#8  0x40609053 in main () from ./libvcl638li.so
#9  0x4148c7ee in __libc_start_main () from /lib/libc.so.6
(gdb)

Created attachment 622 [details]
gdb output for setup binary

goodness me, what could this be ?

I have exactly the same problem, interestingly I had installed
StarOffice60b on this system, recently it broke and started to give
Sig11, so I tried to reinstall it - now exactly the same symptoms and
similar straces as yours. OO638c gives the same error, 633 installed
OK. Tried upgrading/downgrading glibc from 2.2.2 to 2.2.4 and back -
no changes. Recently I have installed kernel 2.4.13 (kernel.org
sources) and ext3 patch, tried booting to previous (2.4.12, no ext3) -
still the same problem. 
My distro is Mandrake8.0, glibc 2.2.4 (from 8.1, but original 2.2.2
gives the same problem), kernel 2.4.13+ext3. 
Another clue - one more thing that stopped working on my system at
about the same time is Quake3a with sound (emu10k1). Strace of that
also shows an "old_mmap" call just before the crash. 
I suspect some kernel/libstdc++/glibc issue.

It must be a software Problem:

Just to try I tested this on a friends laptop with a freshly 
installed suse7.3 system and the same error occured. The machine has 
an s3 graphics device, so I tried the workaround but it made no 
difference, same error as on my machine on suse7.3 and 7.2

Considering how many linux users we have I wonder if anyone is 
running this under suse7.2 or 7.3- to me it seems to be a software 
problem, because on my machine it runs, too, if suse7.1 is 
installed...

Let's summarize, as we have many yes's and many no's.

1. It is NOT a (simple) glibc, kernel, etc. issue. We have MANY systems
   638c installed on them without problem the very same kernel/glibc
   configuration as system that fail. (E.g. on may desktop machine the
   638c install failed, while on my notebook the install was
   successful on a stock RedHat 7.1 and the software works OK.)

2. It is NOT a (simple) video card/chip issue. As I wrote before the
   Staroffice 5.2, the OpenOffice 633 installed and works well, the
   638 installed but didn't work, the 638c and StarOffice 6beta didn't
   install on my desktop system with the very same hardware and XFree
   configuration.
3. However, it seems that only some combination of video cards (S3
   Trio3D, S3 Savage, NVidia, ...) and the newer versions of
   kernel/glibc/XFree are affected. So seemingly during the
   evolvement of the software (remember that on my configuration, the
   638 build became crashy) a bug was introduced that reveals itself
   in this combination of the hardware/software. _Less_Likely_ that
   a bug would exist in the underlying glibc/kernel/XFree combination
   as these things are varying (I've upgrade-ed both the kernel and
   the glibc), altaugh it is possible.

4. We have many strace-es and a a debug session that suggests that
   this is not a timing/contingent bug but a simple algorithmic one.
   All the faileure seems to happen at the same place somewhere at the
   initialization code of these configuration.

5. It is possible that there is a factor in the initialization code
   that counts but was not mentioned bu the bug reportes, simply
   because everybody reports that thinks matters. It would be nice to
   know what are the important factors the setup initialization code
   branches on, so we would report other configuration elements, so
   we could be able to locate the faulty branch.

incze

>>>It would be nice to
   know what are the important factors the setup initialization code
   branches on, so we would report other configuration elements, so
   we could be able to locate the faulty branch.


I would report my complete hard and software config if I knew this 
would help to get rid of this, bug, which really anoys me...

Of course, if I'm the only one this won't help, but I guess there 
must be many more affected, seing how many on OOo use linux, how 
many nvidia cards are sold etc...

If you need any more info just ask!

maybe this helps:

i've exactly the same problem on a debian unstable system (kernel
2.4.12, xfree 4.1). it works if i start the setup on a vnc-server.
after installation i can start oo only with vnc. xfree causes abort at
start.

Great tip Rodja!

Using vncserver+client I can install and run both 638C and so6beta , 
too :-)

But nevertheless this needs to be fixed and I'm still going to do 
what I can to help fixing it.

The problem is, that we cannot reproduce this bug here.  We are not 
using that computer hardware configurations.  Moreover this seems to 
be a harder one, because it seems (from stack-trace), that memory 
management was corrupted which leads to the crash later.

ha! i have a workaround:

my xserver gets ttfonts form freetype. the fonts.dir is createt by
ttmkfdir. 

$ ttmkfdir
[....]
TT_Open_Face failed with 514 for file ./BLACKADD.ttf
[....]

if i remove BLACKADD.ttf and restart the x server, everything works great!

now look at this:

$ ls -l BLACKADD.ttf 
-rwxr-xr-x    1 sorsera  sorsera         0 26. Nov 19:00 BLACKADD.ttf
----------> its an empty file! this is the cause of the crash on my
system!!!

i hope it helps do get this bug fixed soon!

> ---- Additional Comments From Daniel Boelzle 2001-11-26 10:17 PST ---
> The problem is, that we cannot reproduce this bug here.  We are not 
> using that computer hardware configurations.  Moreover this seems to 
> be a harder one, because it seems (from stack-trace), that memory 
> management was corrupted which leads to the crash later.

No. Or not so simply. On the identical hardware I can install 638 and
not 638c.
The memory model of the application IS corrupted without doubt (anyway, we
get a segmentation fault). But there can be some property of the
hardware/software
scheme that seems to be only reveal something that can be wrong on other
platforms, too. E.g. (really just example) this hardware can contain
volatile
RAM where other hardware has non-volatile. This way other hardwares won't
bombe your software even when you access unallocated memory, etc. 

I've already expressed my guess: the history of the bug - as it became
worse and
worse from  SO 5.2 (OK),  OO 633 (OK), OO 638 (installs but, crashy),
OO638c/SO 6.0b (can't put up the splash screen on install and bombs)
 - and the fact that OpenOffice/StarOffice is in a prerelease heavy
optimization
phase together makes me suspect that something was optimized out that was
in on purpose.

Hi,

there were fonts on my system that ttmkfdir couldn't cope with too, 
but fixing this (pelase look at the text file attached below) didn't 
eliminate the bug on my system. Did I make a mistake somewhere?

Timon

Created attachment 723 [details]
my try no. 1 to eleinate the fonts problem.

hi,

if I run kde with the panel on the lefthand side, everything is as I 
described above, if I put it at the bottom or use a different window 
manager, I get what you see on the screenshot attached below. The 
dialoge box shows up when I try to close the window in the front, 
one button makes the prog exit, the other lets it continue doing 
nothing.

Created attachment 734 [details]
screenshot of what it looks like when this bug occurs.

> there were fonts on my system that ttmkfdir couldn't cope with too, 
> but fixing this (pelase look at the text file attached below) didn't 
> eliminate the bug on my system. Did I make a mistake somewhere?

what happens if you start x without ttf? 

Actually my install (it is the RH 7.1 stb. which started this thread)
now works. I wanted
to check the KDE panel observation on my system - I keep that panel on
the right of my
screen. Took the panel to the bottom, and tried to install OpenOffice.
It succeeded.
No hitch, no problem at all. I tried a word document that reliably
crashed the 638 
version: works.

Actually, I didn' want to think that I saw. So, deinstalled the
OpenOffice, put back the panel
to the right of the screen, and started the installation again. It
worked. So, I installed the
OpenOffice this way, too. It seems to me obvious, that in my case not
the panel was the
problem. (And I _think_, not the hardware and not the software).  IT
MAY BE (e.g. the
OpenOffice deinstall left something on my disk AFTER which the right
side panel installation
went smouthly), but I don't think so. I think, something happend in my
configuration
that counts. As far as I know, only two things happened that can be
important:

I use the jdk 1.4 beta3. And I installed lesstif-0.92.32-0.rh7x.1
because opera 6.0 beta
needed libXm.so.2. You guys who know the internals of the software can
guess what was
the crucial (if any) or something miracle happened. You guys, who are
struggling as
I did give a try (start with lesstiff - the java software Is a bit
heavy to dowload).

incze

Hate the half work. So I deinstalled OO and deinstalled lesstif and
changed  my default  java back to JDK1.3.1. And now the installation
works this way,  too. Really misterious. So, neither lesstiff, nor
the jdk in itself. I have checked what libraries was installed after
last time I experienced the install crash.

Libraries that came with mozilla, nothing else. One thing which makes me
suspecious on the JDK 1.3.1.  With that, the OO works now, but has
some nasty properties (e.g. application bars were are doubled
in dialog panels).

So. I don't have idea. If you think in wizards do what I did
previously. Don't  forget to take your kpanel to the bottom
(and then back if you want).

incze

Hi, got it!!!

Taking this Line out of X11 Config:

FontPath "/usr/X11R6/lib/X11/fonts/truetype"

AND

moving the KPanel from the lefthand side to the bottom solved the 
problem for me :-)))

Reprocuded bug here. After typing setup get glibc message and then it
bombs. Install works fine on another identical Debain system with a
Matrox card. 638c installed fine here too.

Using Debian testing
kernel 2.4.7
glibc version: 2.2.4
XFree 4.1.0.1 on a Gateway Solo
128 MB ram
ATI Mach64 3D Rage Pro

Here is the end of strace -F -f ./setup:
getdents64(0x6, 0x80e1f30, 0x1000, 0x15) = 0
chdir("/home/akennedy/tmp/install")     = 0
rmdir("/tmp/sv001.tmp")                 = 0
write(3, ".\0\2\0\4\0@\2<\0\2\0\5\0@\2<\0\2\0\0\0@\2+\0\1\0", 28) = 28
read(3, 0xbffff8cc, 32)                 = -1 EAGAIN (Resource
temporarily unavailable)
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "\1\2+\0\0\0\0\0\16\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
32) = 32
shutdown(3, 2 /* send and receive */)   = 0
close(3)                                = 0
munmap(0x40016000, 4096)                = 0
_exit(1)                                = ?

My experience:

1. Recommended install of Mandrake 8.1 on Dell Optiplex GX110 using 
glibc 2.2.4, XFree 4.1.0, kernel 2.4.8-26mdk, Intel i810 chipset, 
java 1.4.0b.  OpenOffice 641b works perfectly.

2. Expert install of Mandrake 8.1 updated using Mandrake Update on a 
ECS k7s5a mobo, Viper V770 TNT 32MB (Nvidia drivers included by 
Mandrake), glibc 2.2.4, XFree 4.1.0, Kernel 2.4.8-26mdk, Athlon 
1Ghz, java 1.3.1.  OpenOffice 638c & 641b will not load, SO6.0b will 
not load.  However, 638 (not c) works fine.

Nothing to add, just confirming.  I just built 641 from the 
source snapshot download, and experienced this exact problem 
while running ./setup (only see the glibc 2.2.4 message and 
get a prompt). After being really frustrated and 
reading these posts, I moved my Kpanel from the left side of 
the screen to the bottom, and ./setup started properly.  I 
immediatly closed setup, moved the Kpanel back, ./setup no 
longer works.  I move the Kpanel back to the bottom, ./setup 
works.

*** Issue 2435 has been marked as a duplicate of this issue. ***

On my SuSE 7.3 the font used in the screens on installation of OO641b
is obviously a Chinese font which is the first in
/usr/X11R6/lib/X11/fonts/truetype. When commenting this FontPath out
in /etc/X11/XF86Config everything works fine insofar. The same font is
used in OO641 throughout in all menus and messages.

@incze@openoffice.org:
Is this bug fixed by 641?  Was it the "kde-panel on right side thing"?
Does setup now work on your machine?  I was never able to reproduce it.

This issue tends to be a collective issue for common setup bugs...

I'm using 641c on SuSE7.3, it still has the KPanel issue, meaning it 
doesn't run with the panel on the lefthand side, only if it's at the 
bottom.

> This issue tends to be a collective issue for common setup bugs...

Right, because at the beginning it's hard to tell which bug it is 
that makes Setup fail... 

Regards,

Timon

This issue was assigned to me - prbably by accident. I don't have any
new indormation on this bug, once after I did that funny joy with the
kpanel (set it to the bottom, install OpenOffice, then reset it to the
right) I was not able to reproduce the error anymore - even if I tried
to set back to the starting situation. Meantime I upgraded to RH 7.2
and OpenOffice 641c (which has a diffferent install startup) and never
experienced the error.

I feel bad with all this as I think the bug is there just I can't
reproduce at the moment. So I reassign (if I can) the issue to the
module owner.

incze

Hi,

there are multiple bugs in this issue, at least the S3-Graphics-Card 
one, the KPanel bug and the TrueTypeFont bug.

The last two are 100% reproducable on my machine with SUSE7.3 and 
OOo 641c.

If you like, I can give you, or somebody else from the project, 
access to my machine: SSH, FTP, you name it. I have a Staic IP and 
high bandwidth, should be easy. Just send a mail and we'll figure 
out the details.

Regards,

Timon

The problem with the S3 Savage cards and XFree86 4 has been resolved.
See also issue 863 and Redhat bugzilla bug 31879.

You can work around it with setting an enviroment variable :

export SAL_DO_NOT_USE_INVERT50=true

Or upgrade to the latest version of the savage driver (1.1.20t), this
driver is also included in the latest RedHat XFree rpm (4.1.0.-15).
I can verify that upgrading XFree solves the Savage/XFree 4 problem.

So I think I should close this issue.

Fixed.