91935 - bus error before anything is displayed

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[kstailey]

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

[Phil Schwartau]

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(!ie4)
  {
    if((navigator.appName == "Netscape") &&
                          (parseInt(navigator.appVersion.substring(0, 1)) >= 4))
      doc_els=document.layers
    else
      return
    }

  else
    doc_els=document.all


              etc. 
              etc. 

         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

[Phil Schwartau]

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

[e-mail]: 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 ... ? 

Comment 3

[Phil Schwartau]

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)
Netscape

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))
      doc_els=document.layers



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

[Phil Schwartau]

> 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 ... ?


[e-mail] 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

[Phil Schwartau]

Further info from [e-mail]:

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

sigh.  

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.

Ken



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

[kstailey]

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
boundary.

Comment 7

[Phil Schwartau]

cc'ing cls for his expertise - 

Comment 8

[Phil Schwartau]

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

Comment 9

[cls]

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

Comment 10

[kstailey]

http://www.mozilla.org/releases/

<< 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

[kstailey]

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

Comment 12

[Phil Schwartau]

[e-mail]: have you seen this problem on any other builds
you may have downloaded previously? I'm wondering if it's a recent
regression...

Comment 13

[Jim Dunn]

This works fine on hp-ux.

Rich Burridge, can you look at this?

Comment 14

[kstailey]

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

I'm going to try a current nightly.

Comment 15

[kstailey]

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

[Phil Schwartau]

OK, resolving this as WORKSFORME.

[e-mail]: thank you for this report! Please reopen this bug
should the problem reoccur -