Closed
Bug 270878
Opened 20 years ago
Closed 20 years ago
stack growth direction check gives wrong result
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 242518
People
(Reporter: sejo, Unassigned)
References
()
Details
Attachments
(1 file)
2.95 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Links (2.1pre15; Linux 2.6.9 ppc; 211x63) Build Identifier: 1.7.3 once the program starts i get a assert error. However with biesi's help i isolated the problem to be something weirder :-) by compiling js/src/jscpucfg.c on my system teh stackgrowt direction is -1 (thus all right) but somehow the mozilla compile does check it to 1 Reproducible: Always Steps to Reproduce: 1.emerge mozilla 2. 3. Architecture: PPC G4 powerbook GCC: 3.4.3
Updated•20 years ago
|
Assignee: p_ch → general
Component: Bookmarks → JavaScript Engine
QA Contact: seamonkey.bookmarks → pschwartau
Updated•20 years ago
|
Hardware: Other → Macintosh
Summary: crash on startup → stack growth direction check gives wrong result
Reporter | ||
Comment 1•20 years ago
|
||
addition url for my configure flags: http://dev.gentoo.org/~sejo/files/configure_moz
Comment 2•20 years ago
|
||
Hi, this bug has been reported in Debian against "Galeon" as well, and the submitter was kind enough to write a patch, please see: <http://bugs.debian.org/285404> and: <http://bugzilla.gnome.org/show_bug.cgi?id=164262> I'll attach his patch ASAP.
Comment 3•20 years ago
|
||
Comment 4•20 years ago
|
||
My patch is for another problem, see the gnome bugzilla entry for details. The short story: There's some broken pointer arithmetic in the jsarena code. When arena->avail is close to the upper memory boundary, some pointer additions overflow, that makes some pointer comparisions do unexpected things and causes a crash later on. My patch fixes this problem by doing subtractions instead of additions (e.g. "_p > _a->limit - _nb" instead of "_p + _nb > _a->limit). Note that this problem probably is only reproducable with 64-bit kernels running 32-bit userland code. In that situations the pool is very close to the upper 32-bit memory boundary (0xfffffxxx) and easily overflows to 0x0000xxx. I've seen the problem with ppc64 kernels and ppc32 mozilla. 32-bit mozilla versions on x86-64 are likely to have the same problem (unless running it with the PER_LINUX32_3GB personality).
Comment 5•20 years ago
|
||
Put the patch in a new bug -- this bug is a dup of bug 242518. /be *** This bug has been marked as a duplicate of 242518 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•