Reassigning to Browser-General until we can get more information. This is not likely to be a bug in JS Engine. firstname.lastname@example.org: 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
QA Contact: pschwartau → doronr
Whiteboard: [SITE USES LAYERS]
> 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 ... ? email@example.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.
Further info from firstname.lastname@example.org: 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 -
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.
cc'ing cls for his expertise -
cc'ing more folks. Wondering if anyone can reproduce this crash and provide a stack trace; thanks -
Sorry, this is a bit out of my area. jdunn, any thoughts?
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?
Does this problem occur on other SPARC or HP PA-RISC builds?
email@example.com: have you seen this problem on any other builds you may have downloaded previously? I'm wondering if it's a recent regression...
This works fine on hp-ux. Rich Burridge, can you look at this?
Problem does not exist in Solaris 2.6 SPARC nightly build from 2001041022. I'm going to try a current nightly.
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.
OK, resolving this as WORKSFORME. firstname.lastname@example.org: thank you for this report! Please reopen this bug should the problem reoccur -
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.