New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Jun 2016
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug-Regression

Sign in to add a comment

Issue 621926: Em-DOSBox fails in 32-bit Chrome 51, 52 and 53, but works in 50 and 64-bit

Reported by, Jun 21 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0

Steps to reproduce the problem:
1. Navigate to or in 32-bit Chrome 51, 52 or 53.
2. Press round power button in middle of game screenshot to start game
3. Observe game behaviour

What is the expected behavior?
Game should start running and displaying its graphics.

What went wrong?
These and other DOS games from crash on startup. Prince of Persia gets a stack overflow and Wolfenstein 3D gets abnormal program termination. You see this text output to the DOS console window.

This happens in 32-bit Chrome 51.0.2704.84 from and following current versions downloaded normally Google: 51.0.2704.103 m, 52.0.2743.41 beta-m and 53.0.2767.4 dev-m. They work in corresponding 64-bit versions, and Chrome 50.0.2661.75 and earlier versions.

Did this work before? Yes Works in

Chrome version: 51.0.2704.84  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 22.0 r0

These DOS games are using my Emscripten port of DOSBox, at . I realize that saying "this big Emscripten compiled JavaScript application behaves wrong" probably isn't very helpful, but it's probably better to report the bug anyways. This certainly seems like a Chrome bug because it has worked in a bunch of Chrome versions up to and including 50 and still works in other browsers and 64-bit Chrome.

Comment 1 by, Jun 21 2016

Labels: Needs-Bisect

Comment 2 by, Jun 22 2016 causes an "Aw, Snap!" tab crash in Chrome. It also uses Em-DOSBox. After the URL loads, you need to click where it says "Click or tap here to start", and then wait. It will say "Time warping to DOS", and after that, when the DOS prompt appears the tab crashes. For me it crashes 51.0.2704.84 32-bit but works in 50.0.2661.75 32-bit and 51.0.2704.84 64-bit. All are in 64-bit Windows 10 build 14367. 

That means it behaves like the other problems, and the same bug may be causing the crash and emulator misbehaviour. JavaScript should not crash browser processes. It might even have security implications, if specially crafted JavaScript could use the bug to access things JavaScript shouldn't be able to access.

Comment 3 by, Jun 22 2016

Components: Internals>GPU
Labels: -Type-Bug -Pri-2 -Needs-Bisect M-52 Pri-1 Type-Bug-Regression
Status: Assigned (was: Unconfirmed)

Good Build:

51.0.2696.0      Base Position: 384437

Bad Build:

51.0.2697.0      Base Position: 384752


Able to repro this issue on Windows 7 for the Google Chrome Stable Version - 51.0.2704.103

This is a regression issue broken in M51, below mentioned is the bisect info:


Suspecting Commit: 342bfc25de5b0452b1551bf9db4bf45eac7718b2

Review URL:

@bsalomon: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

Note: Issue is not observed on MAC (10.11.5) & Linux (Ubuntu Trusty [14.04]) OS.

Comment 4 by, Jun 22 2016

Project Member
Labels: -M-52 M-53 MovedFrom-52
Moving this nonessential bug to the next milestone.

For more details visit - Your friendly Sheriffbot

Comment 5 by, Jun 22 2016

Labels: Stability-Crash
Are there any entries in chrome://crashes that correspond to the times that the emulator failed to load? If so, please provide crash IDs here as well.

Comment 6 by, Jun 22 2016

Components: Blink>JavaScript
Yes, please provide crash IDs. At this point not many of the Chrome developers are running the 32-bit browser.

Comment 7 by, Jun 22 2016

Labels: Needs-Feedback

Comment 8 by, Jun 22 2016


Comment 9 by, Jun 22 2016

Here are 3 crashes that just happened on after clicking "Click or tap here to start" and waiting a bit for unreal.exe to start running in the emulator. That causes a crash every single time for me. This is 32-bit Chrome 51.0.2704.103 m with a clean profile, and only the extensions Google bundles.

Crash ID 8a4196e600000000 (8106e889-e7db-4ff2-854a-27164b969c0b)
Crash ID 56d196e600000000 (6bfbd26d-0421-464e-9bb2-6125829226f1)
Crash ID fe0896e600000000 (b24676b2-8c59-49f4-8a00-929842a17dda)

Comment 10 by, Jun 22 2016

I've manually bisected this down to this v8 roll:

ed221ce Update V8 to version 5.1.247. by v8-autoroll ยท 3 months ago

and specifically this V8 change in that roll:
[ia32] Byte and word memory operands in ia32 cmp/test.

Comment 11 by, Jun 23 2016

Components: -Blink

Comment 12 by, Jun 23 2016

The smallest misbehaving DOS program I could find was the QEMU test.
The source is in:
Found it via this page:

Seems like "adc dx, bp" at offset 0x24 is causing the problem. I stripped down to an even smaller .com file which still triggers the problem, and am attaching it here. Open pi10frag.html. Since it needs other files there, either do this via a web server like python -m SimpleHTTPServer or start Chrome with the --allow-file-access-from-files command line option.

When the program works, it ought to output 0 to the DOS window and finish, returning to the C:\> prompt. In Chrome 51.0.2704.103 m it also outputs a single character and finishes, but outputs various characters. Reloading the page often but not always changes the character.

I wonder why the character is changing? Is it reading from wrong memory locations? Is it reading outside of what JavaScript should be able to read from?

The CPU interpreter is a loop which calls various functions based on the opcode. This should have narrowed it down to a fairly small number of functions. It is possible to build Em-DOSBox with different Emscripten parameters which result in more readable JavaScript code. Let me know if assistance is needed with that.
1.0 MB Download

Comment 13 by, Jun 23 2016

I realized that the Skia read pixels call is grabbing a large chunk of stack space (64K) and the crash from the reports is in _chkstk. Tomorrow morning I'll try removing that allocation and and see if it crashes. It could be that the V8 change is not directly related but just nudged us over the edge of available stack space.

Comment 14 by, Jun 23 2016

Removing that stack allocation doesn't allow the Prince of Persia game to load successfully. I'm doing a debug build and will run in the debugger to see what I can find.

Comment 15 by, Jun 23 2016

I ran a debug build and didn't get a crash or notice any different logging with or without the v8 change. Kicking this back over to v8. I'll still remove that stack allocation from Skia but I don't think it is related to the failure to load the DosBox games at

Comment 16 by, Jun 23 2016

I'm skeptical about the bisect which found "Simplify GrDrawBatch uploads and token uage."
Graphical stuff could only be causing games to fail to work like that if it was causing memory corruption for JavaScript. Also, a crash involving that might be due to memory corruption caused by JavaScript.

If memory corruption is occurring, changes elsewhere in Chrome might cause a crash to not happen, causing misleading bisect results. Bisecting based on games working or not working would be more certain.

For all I know, maybe there are two issues here: the crash on that one game and other games not working. I merely suspect that it's the same issue because in both cases it works in 32-bit version 50 and in 64-bit version 51.

The JavaScript change found by bisecting seems far more probable: "[ia32] Byte and word memory operands in ia32 cmp/test."
If wrong x86 instructions are being generated and executed, that could explain everything.

Comment 17 by, Jun 23 2016

I'm on it. I can observe the 'aw snap' at in 32bit Chromium on Linux too.

Comment 18 by, Jun 28 2016

Enrico, did you find anything more here?

Comment 19 by, Jun 28 2016

Labels: -Arch-x86_64 Arch-x86
Yes, I horribly swapped two opcodes when adding cmpw to This was causing the order of the operands in a cmpw to be reversed (hence recursions that don't terminate and such). 

There's a fix ( I'm trying to figure out why the v8_mac_rel_ng_triggered is failing, so that I can submit it.

Comment 20 by, Jun 28 2016

Labels: OS-Linux
Status: Fixed (was: Assigned) is now in. I was able to play through the first level of Prince of Persia, Wolfenstein 3D starts too and so does

When it's verified I can merge the change in stable and dev too.

Comment 21 by, Jun 29 2016

Thank you! Everything seems fine in the latest 32-bit binaries from

Comment 22 by, Jun 29 2016

Labels: Merge-Request-52 Merge-Request-51

Comment 23 by, Jun 30 2016

Labels: -Merge-Request-51 Merge-Review-51 Hotlist-Merge-Review
[Automated comment] Request affecting a post-stable build (M51), manual review required.

Comment 24 by, Jun 30 2016

Labels: -Merge-Request-52 Merge-Approved-52 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M52 (branch: 2743)

Comment 25 by, Jun 30 2016

Labels: -Merge-Request-51 Merge-Review-51 Hotlist-Merge-Review
[Automated comment] Request affecting a post-stable build (M51), manual review required.

Comment 26 by, Jul 1 2016

Rechecked this on chrome version 53.0.2785.0 (32 Bit) Version on Windows 7 OS. Still able to reproduce it. Attached screenshot for the same.

@epertoso: Request you to please take a look into it.

Comment 27 by, Jul 1 2016

22.0 KB View Download

Comment 29 by, Jul 4 2016

Project Member
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit - Your friendly Sheriffbot

Comment 30 by, Jul 7 2016

This was merged in 5.2 with

Comment 31 by, Jul 7 2016

Project Member
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit - Your friendly Sheriffbot

Comment 32 by, Jul 11 2016

Labels: -Merge-Approved-52 -Merge-Review-51 backport-review merge-merged-52

Comment 33 by, Jul 11 2016

epertoso@ does this also needs merging to 5.3?

Comment 34 by, Aug 11 2016

Labels: -backport-review backport-done

Comment 35 by, Sep 1 2016

epertoso@, could you please reply to 33?

Comment 36 by, Sep 2 2016

Labels: Merge-Request-53
I though this was done, but actually it seems it didn't make it to 5.3.

Comment 37 by, Sep 2 2016

This should be a safe merge: CL doesn't depend on other CLs and the files it touches aren't updated that often.

Comment 38 by, Sep 2 2016

Labels: -Merge-Request-53 Merge-Approved-53
Approving merge to M53 branch 2785 based on comment #37. Please merge latest by Monday, 09/05 5:00 PM PT. Thank you.

If M54 merge is needed, please request a merge.

Comment 39 by, Sep 5 2016

Merged in

M54 does not need a cherry-pick.

Comment 40 by, Sep 5 2016

Labels: -Merge-Approved-53
Thank you  epertoso@.
This is already merged to M53 branch at #39. So removing "Merge-Approved-53" label.

Comment 41 by, Sep 28 2016

Labels: -Backport-Done NodeJS-Backport-Done

Comment 42 Deleted

Sign in to add a comment