1767268 - dtoa error: cmp called with a->x[a->wds-1] == 0

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase produces an error on mozilla-central revision 20220429-a3002a9b4204 (fuzzing-debug build, run with --fuzzing-safe --no-threads):

(a=W=>a(W**-W+W || 6+W ))` `

Error:

cmp called with a->x[a->wds-1] == 0

Apparently this is triggers a really old Bug() statement in dtoa code that does not even crash but just calls exit. I have no clue what this "assert" means, so I'm marking this s-s until investigated.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 3

[Jan de Mooij [:jandem]]

NI myself to see if this changed upstream. I also want to see if we can use the double-conversion library more - last time I tried this there were some perf issues.

Comment 4

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Unable to reproduce bug 1767268 using build mozilla-central 20220429094842-a3002a9b4204. Without a baseline, bugmon is unable to analyze this bug.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

:decoder, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Comment 6

[Christian Holler (:decoder)]

We don't know the regressor and can't bisect this right now.

Comment 7

[Jan de Mooij [:jandem]]

Reduced test case:

var v = 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111113.504938994813925e-1211;

This happens under js_strtod_harder.

Comment 8

[Jan de Mooij [:jandem]]

Python fixed a similar issue in https://bugs.python.org/issue7743 with a number of different code changes. The dtoa code has diverged so taking their changes isn't trivial...

I'm considering replacing the remaining uses of dtoa.c with the double-conversion library (bug 1691998). The dtoa code is often a bit faster in micro-benchmarks, I think part of that is because it doesn't support as many runtime options, but I also don't think string-to-double is super perf-critical.

Comment 9

[Daniel Veditz [:dveditz]]

I don't get a crash from either the original testcase or the comment 7 one (which looks completely unrelated?). Does this work on in some environments? I do get a "too much recursion" error on the web console from decoder's testcase.

Comment 10

[Daniel Veditz [:dveditz]]

Ah, when you say "error" you mean "assertion"? I was no using a debug build.

Comment 11

[Daniel Veditz [:dveditz]]

So is this a security bug or is it just returning bad output for this case (in Release builds)?

Comment 12

[Jan de Mooij [:jandem]]

(In reply to Daniel Veditz [:dveditz] from comment #10)

Ah, when you say "error" you mean "assertion"? I was no using a debug build.

"assertion" in the sense of debug-only printf + exit(1), yeah. That's why fuzzing didn't find this sooner as it doesn't look like a regular assertion/crash.

(In reply to Daniel Veditz [:dveditz] from comment #11)

So is this a security bug or is it just returning bad output for this case (in Release builds)?

I suspect it's not a real security bug, but this dtoa.c code is so obscure that it's hard to feel confident about this.

Comment 13

[Jan de Mooij [:jandem]]

This should be fixed now with bug 1770158. We can let that ride the trains.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

:jandem, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Comment 16

[Jan de Mooij [:jandem]]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #15)

:jandem, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?

It doesn't contain a bisection range. See also comment 6.

Comment 17

[Marco Castelluccio [:marco]]

Sorry, regression from a recent change in the bot...

Comment 18

[Giorgia Nichita, Release Desktop QA]

I was able to reproduce this issue on Ubuntu 22.04 following the STR from Comment 0, on an affected fuzzing-debug build from 2022-05-30, before it was fixed by Bug 1770158.
Verified as fixed on Firefox 103.0a1 (20220531152954 - fuzzing debug build), on Ubuntu 22.04 and Windows 10 x64.