bus error before anything is displayed



18 years ago
15 years ago


(Reporter: kstailey, Assigned: asa)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [SITE USES LAYERS], URL)



18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.2) Gecko/20010707
BuildID:    0000000000 - 0.9.2 release for Solaris 2.6 & 2.7

attempt to view page.  get core dump instead.

Reproducible: Always
Steps to Reproduce:
1. start mozilla
2. paste 
http://www.prn.org/prn_nb_cntnt/vol6/num2/grinspoon_sum.htm into location field
3. press [Enter] key

Actual Results:  Bus Error - core dumped

Page uses JavaScript to access Frames / No Frames version automatically.

Comment 1

18 years ago
Site uses layers. We see this error in the JavaScript Console:

Error: doc_els has no properties
Source File: http://www.prn.org/animate.js
Line: 105

Line 105 occurs in this function, when doc_els is accessed:

function dynAnimation(obj)
  animateElements = new Array()
  var ms = navigator.appVersion.indexOf("MSIE")
  ie4 = (ms>0) && (parseInt(navigator.appVersion.substring(ms+5, ms+6)) >= 4)

    if((navigator.appName == "Netscape") &&
                          (parseInt(navigator.appVersion.substring(0, 1)) >= 4))



         toward line 105

Because of this code, doc_els is either document.all (IE-only)
or document.layers (non-W3C, supported in NN4.x but not Mozilla/N6.

Comment 2

18 years ago
Reassigning to Browser-General until we can get more information.
This is not likely to be a bug in JS Engine. 

kstailey@yahoo.com: would you have access to a debug build or a 
Talkback-enabled build? We need to see a stack trace of the crash
to properly diagnose the problem. If you can get one (or the ID of
a Talkback report that you submit), please attach to this bug - thanks.

I have been unable to reproduce the crash on WinNT or Linux, 
using trunk and branch builds from 2001-07-13. 

Is this is a Solaris-specific issue ... ? 
Assignee: rogerl → asa
Component: Javascript Engine → Browser-General
Keywords: crash
QA Contact: pschwartau → doronr
Whiteboard: [SITE USES LAYERS]

Comment 3

18 years ago
To expand on my comments at 2001-07-23 14:00 above: if I key these
expressions into the Mozilla URL bar, this is what I get:

javascript: document.write(navigator.appName)

javascript: alert(navigator.appVersion)
5.0 (Windows; en-US)

Therefore the condition in dynAnimation() above evaluates to true: 

if((navigator.appName == "Netscape") &&
                          (parseInt(navigator.appVersion.substring(0, 1)) >= 4))

That's why we don't fall into the early return which follows this 
condition, and why we end up with doc_els=document.layers

Comment 4

18 years ago
> I have been unable to reproduce the crash on WinNT or Linux, 
> using trunk and branch builds from 2001-07-13. 
> Is this is a Solaris-specific issue ... ?

kstailey@yahoo.com replies:

Not a Solaris thing.  A SPARC thing.  CPU is not byte-aligned it is
word-aligned.  Accessing data a odd-numbered byte causes bus error (not
segmentation violation since address is inside valid region.)

HP-PA RISC will do this too.

Comment 5

18 years ago
Further info from kstailey@yahoo.com:

I only have Sol 2.6, WinNT 4, and FreeBSD 4.3 to test on. mozilla-bin:    
ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped


Why do they strip the binary when these are supposed to be test releases?
Someone should add this to the release notes so that contributors are reminded.
If it's there already it should be emphasized.


Asa, do you know if there are Talkback-enabled builds for Solaris
at http://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.2/ ? 

Thanks - 

Comment 6

18 years ago
SPARC and HP-PA RISC are word-aligned machines.  If you attempt to
do a word-sized access on a memory address that is not word-aligned, you
will get a trap and a bus error.  Odd numbered addresses do not fall on
word boundaries, hence the problem.

The i386 processor and its kin don't have the same restriction as the
SPARC. The access to non-aligned addresses isn't a problem for the ix86
processor, although there may be a performance penalty.

To fix the problem on the SPARC, you need to be careful how you access
data in your buffers. If you have an un-aligned buffer, you may have to
bcopy() or memcpy() its contents into an aligned buffer before you can
reference it as anything other than a string of bytes (i.e. cast it to
a short, or int, or long). You may also want to investigate the memalign(3)
function on Solaris/SPARC which returns buffers aligned to a specified

Comment 7

18 years ago
cc'ing cls for his expertise - 

Comment 8

18 years ago
cc'ing more folks. Wondering if anyone can reproduce this crash and
provide a stack trace; thanks -

Comment 9

18 years ago
Sorry, this is a bit out of my area.  jdunn, any thoughts?

Comment 10

18 years ago

<< tar.gz format for sparc Solaris 2.6 & 2.7 (12 MB) (requires gtk+-1.2.10 &
glib-1.2.10 or better ) >>

This is the release with the problem as seen on said web page.
Is there any way to find out who built this?

Comment 11

18 years ago
Does this problem occur on other SPARC or HP PA-RISC builds?

Comment 12

18 years ago
kstailey@yahoo.com: have you seen this problem on any other builds
you may have downloaded previously? I'm wondering if it's a recent

Comment 13

18 years ago
This works fine on hp-ux.

Rich Burridge, can you look at this?

Comment 14

18 years ago
Problem does not exist in Solaris 2.6 SPARC nightly build from 2001041022.

I'm going to try a current nightly.

Comment 15

18 years ago
Problem does not occur on 2001072422.

I guess nightlies are more stable than releases sometimes :)

You can close the ticket.  Sorry to have bothered you.

Comment 16

18 years ago
OK, resolving this as WORKSFORME.

kstailey@yahoo.com: thank you for this report! Please reopen this bug
should the problem reoccur - 
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.