stack growth direction check gives wrong result

RESOLVED DUPLICATE of bug 242518

Status

()

Core
JavaScript Engine
--
critical
RESOLVED DUPLICATE of bug 242518
13 years ago
13 years ago

People

(Reporter: Jochen Maes, Unassigned)

Tracking

Trunk
PowerPC
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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
Assignee: p_ch → general
Component: Bookmarks → JavaScript Engine
QA Contact: seamonkey.bookmarks → pschwartau
Hardware: Other → Macintosh
Summary: crash on startup → stack growth direction check gives wrong result
(Reporter)

Comment 1

13 years ago
addition url for my configure flags: http://dev.gentoo.org/~sejo/files/configure_moz

Comment 2

13 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

13 years ago
Created attachment 171756 [details] [diff] [review]
Juergen Kreileder JS Arena patch

Comment 4

13 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).
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
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.