Also encountering this exact same issue, also only in v51. Works fine in v50.

Have founds lots of others also encountering this issue when looking around for a solution but haven't been able to find a workaround yet, so hoping it can be resolved soon.
Ref: https://github.com/angular/angular.js/issues/14188
http://stackoverflow.com/questions/36133715/google-chrome-failed-parsing-sourcemap-css-map-web-essential
https://github.com/madskristensen/WebEssentials2013/issues/1993

FYI, it fails 100% of the time for me, not 50%.

FYI, there are reports that this happens when sourcemap files are encoded using UTF8 with BOM.

And  it happens 100% of the time for me and not only for LARGE files... my map file is 12kb.

Same for me. It fails on all platforms in case of map files, if file is encoded with UTF8 with BOM. If files is encoded using UTF8 without BOM it works. This problem is only in case of map files. Other files like css, js, html etc. can be encoded with BOM and Chrome is possible to open them.

In my case UTF8 with BOM files are created by WebEssential Extension for Visual studio (Visual studio always generate UTF8 with BOM files there is no option to change this behavior).

FYI, still happening 100% of the time in ChromeOS Version 51.0.2704.42 beta (64-bit).

Same here. Version 51.0.2704.63 (64-bit). Before update everything was okay with Source maps. In other browsers there are no error.

Just updated to Version 51.0.2704.63 (64-bit), Same here when debugging a React Native project.

Has anyone come across any workarounds that successfully overcome this issue while we wait for a proper fix?

Workaround is to save map file as UTF-8 file without BOM. I answered question on http://stackoverflow.com/questions/36133715/google-chrome-failed-parsing-sourcemap-css-map-web-essential/36151078#36151078 with description how to do it in Visual Studio.

On Windows, We have Webpack generating sourceMaps in UTF-8, no BOM, and still have this problem. It consistently worked on 50, and doesn't on 51.

Possible workaround: inline source maps as data url, i.e. //# sourceMappingURL=data:application/json;base64,<base64_encoded_source_map_goes_here>

Worked for me in Chrome 51.0.2704.79 (64-bit), MacOS 10.11.5

It seems a few people commenting here are also observing this on the Mac, including my team working with React Native, so the OS tagging of this defect should really be broadened from just Linux I think.

For us on the Mac:

No problems in release build 50.0.2661.102 (64-bit)

Fails with the reported error in release build 51.0.2704.79 (64-bit) as well as canary build 53.0.2754.0 canary (64-bit) 

https://codereview.chromium.org/2032013003/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/72c30193f0804fff83ed73d92db7d5fc5df6b186

commit 72c30193f0804fff83ed73d92db7d5fc5df6b186
Author: kozyatinskiy <kozyatinskiy@chromium.org>
Date: Fri Jun 03 03:29:40 2016

[DevTools] Fix problem with loading source maps

Encode not utf8 chunk as base 64 and then decode it on frontend side.

BUG= 611328 
R=dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2032013003
Cr-Commit-Position: refs/heads/master@{#397618}

[modify] https://crrev.com/72c30193f0804fff83ed73d92db7d5fc5df6b186/chrome/browser/devtools/devtools_ui_bindings.cc
[modify] https://crrev.com/72c30193f0804fff83ed73d92db7d5fc5df6b186/third_party/WebKit/Source/devtools/front_end/devtools.js

can you confirm whether the CL is baked in canary and safe to merge?

Your change meets the bar and is auto-approved for M52 (branch: 2743)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ef323f099efc6246a16362f427cc52d9136de4ad

commit ef323f099efc6246a16362f427cc52d9136de4ad
Author: Alexey Kozyatinskiy <kozyatinskiy@chromium.org>
Date: Sat Jun 04 03:10:17 2016

[DevTools] Fix problem with loading source maps

Encode not utf8 chunk as base 64 and then decode it on frontend side.

BUG= 611328 
R=dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2032013003
Cr-Commit-Position: refs/heads/master@{#397618}
(cherry picked from commit 72c30193f0804fff83ed73d92db7d5fc5df6b186)

Review URL: https://codereview.chromium.org/2039013002 .

Cr-Commit-Position: refs/branch-heads/2743@{#227}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/ef323f099efc6246a16362f427cc52d9136de4ad/chrome/browser/devtools/devtools_ui_bindings.cc
[modify] https://crrev.com/ef323f099efc6246a16362f427cc52d9136de4ad/third_party/WebKit/Source/devtools/front_end/devtools.js

It is already fixed in Canary and will go to beta soon. We won't merge it to current stable. In stable this fix will be available around July 26th [1].
You can download Canary by following link:
https://www.google.com/chrome/browser/canary.html

[1] https://www.chromium.org/developers/calendar

Canary is not available for Linux and now both stable and beta have broken sourceMaps. Canary on OS X has broken rendering when changing tabs.

I don't have any choice but to use another browser at this point.

At least the copy of Opera I have installed is still Chrome/50.0.2661.102 with functioning sourceMaps.

I beg you to reconsider getting this fix into stable, it's incredibly frustrating trying to debug anything without sourceMap support.

Have you not tried Dev channel? 

It's not fixed on the Dev channel yet:

Version 53.0.2756.0 dev (64-bit)

Yes. please release to stable ASAP.  This is causing issue with our development.

thanks

bjorn@kkvesper.jp -- Could you please provide us the specific URL where the issue is seen which would help us triage the issue further.
Thanks in Advance.

What I mean is there has been no release of Dev yet so now the only version of Chrome that I can use with functioning sourceMaps is Opera.

I get it, it's not trivial to get fixes out, but you're asking web developers to live with broken sourceMaps in your stable product for 2 months.

I'm actually a little surprised there hasn't been more outcry from the developer community.

bjorn@kkvesper.jp -- Thank you for the quick update. The fix has already been landed. I have verified on some webpages and was not able to reproduce the issue.
If you please provide us the specific URL ni which sourcemaps are broken, we would be providing an update.
Thanks in Advance.

@bjorn, we can't merge fixes like this to stable.

https://download-chromium.appspot.com/ will give you a new build that has this fix.

Any idea when this fix will be pushed to beta channel for ChromeOS?

And I agree with comment #27 - this is a serious issue for developers and I'm also surprised more devs aren't being vocal about this, especially given it won't hit stable for another month+. This means for anyone I want to show our app, I will have to advise them not to use Chrome, which makes us look pretty bad, as if we can't even get our app working properly on Chrome.

I tried this with Canary 53.0.2762.0 (64-bit) on Mac OSX 10.11.15 and it worked as expected.

I've taken the plunge and updated to the dev channel on ChromeOS and now running Version 52.0.2743.32 dev (64-bit) but the issue still remains for me.
Is there a newer update coming to Dev channel for ChromeOS soon with this issue resolved?

It seems the dev team doesn't find out what's going wrong...

I hit the issue too.
As i my browser(51.0.2704.84 m), the sourcemap map into wrong files in some cases.
And according to my test, It mainly go wrong when the browser loads a really large sourcemap file like 10MB or so. Also, it comes up with error--'fail to parse sourcemap' in the console.

Hope it could help

Also, encountered this issue with version 51.0 
Upgraded to Chrome Version 52.0.2743.33 beta (64-bit) works.

https://www.google.com/chrome/browser/beta.html

A number of frontend developers who are using React are also having this problem:
https://github.com/davezuko/react-redux-starter-kit/issues/858#issuecomment-226216753

I can confirm that it is fixed in the Canary build for me (OS X Version 53.0.2768.0 canary (64-bit))

Resolved now for me on my Chromebook running Version 52.0.2743.32 dev (64-bit). Thanks

It works for me in the case of large source maps in Canary (but not stable) but not if I enable the webpack eval-based compilation (`devtool: '#eval-source-map'`) that's faster, see https://github.com/webpack/webpack/issues/2145.

Canary 53.0.2777.0.

And this is a real difference, the regular compilation takes about 3 seconds to recompile if I change a single file while in the eval-based compilation case it takes only half a second, often less.

For reference, here are the docs:
https://webpack.github.io/docs/configuration.html#devtool

"eval-source-map - Each module is executed with eval and a SourceMap is added as DataUrl to the eval."

Is Chrome expected to resolve mappings correctly in that case? It works for me with a small project but not with a large one.

Switching away from eval to regular compilation with inline source maps (a one-line change in the Webpack config) makes stack traces work again.

OK, it seems my issue is covered by https://bugs.chromium.org/p/chromium/issues/detail?id=459499