User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727) Build Identifier: firefox-184.108.40.206-source.tar.bz2 Due to a floating point simulation problem on our ARM system the subroutines in js/src/jsdtoa.c and nsprpub/pr/src/misc/prdtoa.c were supplied with extreme double values during startup. As a result the index to the local freelist array in these source files was bigger than the array and resulted in a (delayed) crash. Reproducible: Always Steps to Reproduce: 1. 2. 3. I don't know whether this state can also happen under normal conditions. However, I prefer an assert() test for a too big index, which helps to save debugging time, since the floating point emulation software is not bug-free on various hardware architectures.
unfortunately asserts are typically debug only, and your build environment (certainly mine) is not equivalent to the hardware on which this stuff actually runs. configure won't find the problem since it's not running on the real hardware....
There was a bug in dtoa that would crash on any platform, and in fact many product's implementations of dtoa which all derived from the same source. Unfortunately without a testcase this bug remained UNCONFIRMED, and misfiled in the "Build Config" component went unnoticed. I bet it's fixed now though, two years later.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 516396
You need to log in before you can comment on or make changes to this bug.