137787 - Crash before starting GUI - segmentation fault - gettimeofday()

Status: VERIFIED INVALID

(SeaMonkey :: Build Config, defect)

Description

[Jarkko Hakala]

Mozilla I've been trying is 0.9.9-6, both - readily built and locally built
(by means of apt-get --compile source)
My system(based on Debian):
Parisc-Linux kernel 2.4.18 
Local XFree86 is 4.1.0-15
libc6 2.2.5-4

The crash is "Segmentation fault" before anything appers to screen of X-server.
This happens for local x-server(8bit framebuffer) as well as remote(32bit).
It happens with plain command "mozilla" as well as "mozilla -mail".

I ran the following commands inside shell launched by "script" -command, so you 
can see some - hopefully usable information like:
ldd `which mozilla-bin`
ldd `which mozilla-bin`|awk '{print $3}'|xargs -i ls -l \{\}
ldd `which mozilla-bin`|awk '{print $3}'|xargs -i dpkg -S \{\}
ldd `which mozilla-bin`|awk '{print $3}'|xargs -i dpkg -S \{\}|cut -d ":" -f 
1|sort -u|xargs -i dpkg -s \{\}
strace -f mozilla 

The output is available on 
http://byterapers.com/~jhakala/moz_crash_typescript.txt

I am willing to give all info I am able to reach, do any tests which could be 
helpful etc., thou as the machine is really slow, it takes about 2 days to 
compile debug-version or test a patch against it, so for this I believe there 
are others with faster HP-hardware.

Yours,
Jarkko Hakala

Comment 1

[Jarkko Hakala]

Attachment: ldd and strace outputs

Content of the same file as the url mentioned - I didn't know about possibility
to send attachments until I've already clicked "submit bug" -button...

Comment 2

[Vadim Berezniker]

Just a note about the debian package of mozilla.
As far as I'm aware, debian applies patches to their version of mozilla. 
Patches that are not present the 'official' mozilla.

Comment 3

[Matthias Versen [:Matti]]

Reporter: Do you see this with a build from mozilla.org ?

Comment 4

[Jarkko Hakala]

I found out that vanilla mozilla tar.bz2 was not able to compile at all, due 
lack of support of hppa-linux in general. 
Plain "./configure ; make" recognizes the host/target/build system as "hppa1.1-
unknown-linux-gnu", and the outcome of make is:
In file included from /tmp/mozilla/dist/include/nspr/prtypes.h:55,
                 from /tmp/mozilla/dist/include/nspr/pratom.h:43,
                 from /tmp/mozilla/dist/include/nspr/nspr.h:38,
                 from ../../../pr/include/private/primpl.h:66,
                 from prfdcach.c:35:
/tmp/mozilla/dist/include/nspr/prcpucfg.h:419:2: #error "Unknown CPU 
architecture"

There already are definitions of byte-order etc. for HP hardware, but only if 
the target-host is HPUX, so some copy/paste in header files might be enough.

Comment 5

[Matthias Versen [:Matti]]

-> Build Config (comment #4)

Comment 6

[hacker formerly known as [e-mail]]

Ugh.  This is a big ball of mess.  First, I hope that you filed a bug report on
debian about the crash from their builds.  It's going to be hard for us to track
down a runtime problem in a build that we don't even have build support for.  
Second, file a separate report on adding hppa-linux support to the mozilla tree.
 Hopefully, debian will donate their patches.  

For now, I'm reassigning the bug to the reporter as I have no way of verifying
that even the basics work.  Things to look for:
1) make sure that the NSPR tests in nsprpub/pr/tests/runtests.sh actually pass.
You should file a separate bug if any of them do not.
2) since xptcall compiles, you should make sure that `./run-mozilla.sh
TestXPTCInvoke ` works. 

Comment 7

[Azrael AOD]

What's the status of this bug? Is anyone able to confirm it at all? Should it be
marked 'new' to get more eyes?

Comment 8

[Jarkko Hakala]

Well maybe this is kind of out-of-date now as 1.0 is out, so comments about
running that 1.0 on linux-hppa would be more interesting. This far, I have no
experiences of it at all.

Comment 9

[hacker formerly known as [e-mail]]

Azrael, I don't know who advised you to start "marking bugs as new to get more
eyes  looking at it" but please stop.  If you cannot duplicate the bug, *don't*
confirm it!

Comment 10

[Azrael AOD]

"Note that you do not necessarily have to be able to reproduce the bug in order
to confirm it." - http://mozilla.org/quality/help/unconfirmed.html

However if you want me to stop trying to reduce the unco's I'll comply.

Comment 11

[hacker formerly known as [e-mail]]

Yes, please stop.  Artificially reducing the number of unconfirmed bugs doesn't
help and is going to further dilute the meaning of the NEW state.

Comment 12

[Gervase Markham [:gerv]]

> "Note that you do not necessarily have to be able to reproduce the bug in order
> to confirm it." - http://mozilla.org/quality/help/unconfirmed.html

Chris is correct that this statement needs qualification. It should say
something like:

"If the bug is well-reported, against a recent build of software from
mozilla.org,  but requires conditions you know to be true of only a very few
test environments, which you and no-one you know can reproduce, then you may
judge it correct to confirm it without reproducing it".

Gerv

Comment 13

[Kai Lahmann (is there, where MNG is)]

somebody go to fill a bug for a Linux/HPPA port. THIS bug is invalid because
it's a debian-build.

Comment 14

[Jon Granrose]

verified