Note that should be $'foo\337bar' above (with a dollar sign and two apostrophes around it), seems like the wizard messed this up?

Would you mind providing a sample testcase for the ease of finding regression. 

What makes you think it is a regression?

See above for a way to reproduce it consistently (but manually).

As for automated tests: I have no idea how those work in Chromium or how trivial it is to automate this (as it might also depend on what the GTK file dialog does).

I won't be able to do this anytime soon (if at all), I'm afraid.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Looks like the browser is deliberately killing the renderer. Relevant part from the backtrace:

Thread 1 (Thread 0x7ffff7efca80 (LWP 3361)):
#0  0x00007fffed8faa10 in raise () at /usr/lib/libc.so.6
#1  0x00007fffed8fc13a in abort () at /usr/lib/libc.so.6
#2  0x0000555557b6dbf4 in base::debug::BreakDebugger() () at ../../base/debug/debugger_posix.cc:251
#3  0x0000555557b89625 in logging::LogMessage::~LogMessage() () at ../../base/logging.cc:759
#4  0x0000555556840603 in content::RenderProcessHostImpl::ShutdownForBadMessage(content::RenderProcessHost::CrashReportMode) () at ../../content/browser/renderer_host/render_process_host_impl.cc:1533
#5  0x00005555566bedc1 in base::DispatchToMethodImpl<content::RenderFrameHostImpl*, void (content::RenderFrameHostImpl::*)(content::PageState const&), std::tuple<content::PageState> const&, 0ul>(content::RenderFrameHostImpl* const&, void (content::RenderFrameHostImpl::*)(content::PageState const&), std::tuple<content::PageState> const&, base::IndexSequence<0ul>) () at ../../base/tuple.h:91
#6  0x00005555566bedc1 in base::DispatchToMethod<content::RenderFrameHostImpl*, void (content::RenderFrameHostImpl::*)(content::PageState const&), std::tuple<content::PageState> const&>(content::RenderFrameHostImpl* const&, void (content::RenderFrameHostImpl::*)(content::PageState const&), std::tuple<content::PageState> const&) () at ../../base/tuple.h:98
#7  0x00005555566bedc1 in IPC::DispatchToMethod<content::RenderFrameHostImpl, void (content::RenderFrameHostImpl::*)(content::PageState const&), void, std::tuple<content::PageState> >(content::RenderFrameHostImpl*, void (content::RenderFrameHostImpl::*)(content::PageState const&), void*, std::tuple<content::PageState> const&) () at ../../ipc/ipc_message_templates.h:26
#8  0x00005555566bedc1 in IPC::MessageT<FrameHostMsg_UpdateState_Meta, std::tuple<content::PageState>, void>::Dispatch<content::RenderFrameHostImpl, content::RenderFrameHostImpl, void, void (content::RenderFrameHostImpl::*)(content::PageState const&)>(IPC::Message const*, content::RenderFrameHostImpl*, content::RenderFrameHostImpl*, void*, void (content::RenderFrameHostImpl::*)(content::PageState const&)) () at ../../ipc/ipc_message_templates.h:121
#9  0x00005555566bedc1 in content::RenderFrameHostImpl::OnMessageReceived(IPC::Message const&) () at ../../content/browser/frame_host/render_frame_host_impl.cc:691
#10 0x000055555684df79 in content::RenderProcessHostImpl::OnMessageReceived(IPC::Message const&) () at ../../content/browser/renderer_host/render_process_host_impl.cc:2081
#11 0x00005555581184e2 in IPC::ChannelProxy::Context::OnDispatchMessage(IPC::Message const&) () at ../../ipc/ipc_channel_proxy.cc:329
#12 0x0000555557c0e171 in base::internal::RunMixin<base::Callback<void (), (base::internal::CopyMode)0, (base::internal::RepeatMode)0> >::Run() && () at ../../base/callback.h:68
#13 0x0000555557c0e171 in base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) () at ../../base/debug/task_annotator.cc:59
#14 0x0000555557b925d0 in base::MessageLoop::RunTask(base::PendingTask*) () at ../../base/message_loop/message_loop.cc:423
#15 0x0000555557b944ad in base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) () at ../../base/message_loop/message_loop.cc:434
#16 0x0000555557b949b8 in base::MessageLoop::DoWork() () at ../../base/message_loop/message_loop.cc:527
#17 0x0000555557b95e4c in base::MessagePumpGlib::HandleDispatch() () at ../../base/message_loop/message_pump_glib.cc:267
#18 0x0000555557b95e9c in WorkSourceDispatch() () at ../../base/message_loop/message_pump_glib.cc:109
#19 0x00007ffff6e3c5a7 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#20 0x00007ffff6e3c810 in  () at /usr/lib/libglib-2.0.so.0
#21 0x00007ffff6e3c8bc in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#22 0x0000555557b95b6a in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) () at ../../base/message_loop/message_pump_glib.cc:309
#23 0x0000555557b91501 in base::MessageLoop::RunHandler() () at ../../base/message_loop/message_loop.cc:387
#24 0x0000555557bbb3f4 in base::RunLoop::Run() () at ../../base/run_loop.cc:37
#25 0x0000555557a2c95c in ChromeBrowserMainParts::MainMessageLoopRun(int*) () at ../../chrome/browser/chrome_browser_main.cc:2001
#26 0x000055555659cc19 in content::BrowserMainLoop::RunMainMessageLoopParts() () at ../../content/browser/browser_main_loop.cc:1183
#27 0x00005555565a0f30 in content::BrowserMainRunnerImpl::Run() () at ../../content/browser/browser_main_runner.cc:140
#28 0x0000555556598141 in content::BrowserMain(content::MainFunctionParams const&) () at ../../content/browser/browser_main.cc:46
#29 0x0000555557756a33 in content::ContentMainRunnerImpl::Run() () at ../../content/app/content_main_runner.cc:836
#30 0x0000555557755781 in content::ContentMain(content::ContentMainParams const&) () at ../../content/app/content_main.cc:20
#31 0x0000555556069973 in ChromeMain() () at ../../chrome/app/chrome_main.cc:121
#32 0x00007fffed8e7511 in __libc_start_main () at /usr/lib/libc.so.6
#33 0x00005555560697ea in _start ()

sadrul mentioned in the IRC channel that they can't reproduce this. Some more info which might be relevant:

- I'm on GTK 3.22.10
- My LANG is set to en_US.utf8, but setting LANG=de_CH.UTF-8 doesn't make a difference either.

From code search, looks like the possible suspect is - https://chromium.googlesource.com/chromium/src/+/f050c89a2ba1799844b3615884000d5fa7a03e11

Ken, would you mind taking a look at this issue.

me@ Would you mind providing us with a crash id from chrome://crashes, with the help of magic stack we can identify the crash impact on various chrome versions and expedite the fixing.

I am adding an RBS label for tracking purpose.

Thanks.

chrome://crashes only tells me "Crash reporting is not available in Chromium." (I'm using Archlinux' Chromium package).

Re comment #1: The CL you point to is just carrying out a bad IPC report on some other code's behalf.

To address this issue we need to determine who is incorrectly reporting a bad IPC in this case. This means we would need a reliable repro or some crash reports from users.

Re #12: If there's any way you could get one of the official Chrome deb/rpm packages running to repro this, that would be most helpful. Not sure how feasible that is on ArchLinux but it might be worth a shot.

Also +dcheng@ on the off chance that he might have a good idea of where to look for this.

So you can't reproduce this with the steps in #1 either? Either way, reproduced in Chrome 59.0.3043.0, crash dump ID aee1fb40a0000000.

Passing to creis@ to have a look since they are likely familiar with this policy.

Gentle ping for an update on this , as it is marked as stable blocker.

Thanks!

ligimole@: This renderer kill was added years ago, so I'm not sure why this is marked as a ReleaseBlock-Stable.  Is there a reason for that urgency?

At any rate, I'll try to take a look today to see if I can repro.

This looks similar to -issue: 620261. Charlie, please dupe if it the same.

Removing RBS since the crash exists in previous milestones.

Thanks-- I agree that this is a dupe of issue 620261, but I'm curious about the repro steps here (which aren't working for me either).  I'll leave it open for the moment while we figure out steps we're missing.

There's a known repro for the crash involving out-of-process iframes (OOPIFs), involving closing and re-opening a tab that has a file selected inside an OOPIF.  Here's modified repro steps from issue 620261:
0) Start Chrome with --site-per-process (to force OOPIFs on cross-site iframes).
1) Visit http://csreis.github.io/tests/cross-site-iframe.html
2) In DevTools, enter: navFrame("https://csreis.github.io/tests/form-post.html")
3) Click Choose File and select a file.
4) Close the tab.
5) Reopen the tab with Ctrl+Shift+T.

However, the steps described in this bug seem quite different-- presumably there's no subframe process in the task manager?  Do you have any extensions installed?  Any flags passed on the command line or set in about:flags?  I'm not seeing the crash when selecting the foo?bar file I created on Linux using the touch $'foo\337bar' command from comment 1.  Same if I close and reopen the tab.

me@, can you try again from a clean profile and see if we're missing some step?  Thanks for your feedback here!

This was with a clean profile (with a dev channel Chrome installation I've never used before, and which didn't pick up my stable Chromium profile, as expected).

chrome://extensions list the Google Docs extensions, which I presome are shipped with Chrome.

I indeed don't see a separate process for the frame, and I can also reproduce it with http://html.com/input-type-file/ which doesn't seem to involve frames.

Maybe it's something dependent on the GTK version, i.e. on whatever the file dialog returns when such a file is selected?

I've just tried to reproduce this on another Archlinux machine with KDE (which uses KDE's file dialog), and there it seems to work fine. So this seems indeed related to the GTK file dialog somehow. 

And again on a Linux Mint machine with a GTK2 file dialog, no luck there either. Seems like this is specific to the GTK3 file dialog.

Thanks for narrowing it down!  Indeed, I can confirm it on GTK3.  I'll look at it in a debugger.

It looks like this is a problem with converting the file path to/from a WebString.

On GTK3, the browser process sends down a base::FilePath that contains the invalid character (foo\337bar).  We call FilePathToWebString on that path from RenderFrameImpl::OnFileChooserResponse, and that calls WebString::fromUTF8(path.value()).  This returns an empty WebString.  (In contrast, the KDE file chooser returns a path where the invalid character shows up as a box instead of \337, and that survives the round-trip through UTF8.)

That explains the kill.  The browser process has granted the renderer process access to the foo\337bar file path, but the renderer process ends up treating the selected file as "".  When that empty path gets reported back to the browser in UpdateState, the browser process notices that we haven't granted access to it, and so we kill the renderer process.

We really shouldn't be treating this path as a successfully selected file in the first place, if we know that Blink can't handle it.  Either it should be ignored (as if the user selected no file), or we should get Blink to handle it.

There's a lot of confusing code around the platform-specific UTF8 conversions for file paths, so I'm not entirely sure the right way to check for this.  I suppose we could just check if the output string is empty and the input string isn't, and not treat it as a selected file.  I'm open to input from other file / UTF8 experts (e.g., brettw?).

+gtk3 master

Note: I have a fix in progress for this at https://codereview.chromium.org/2811533002/, but it's proving difficult to test on other platforms.  I'm trying to investigate whether there are similar bugs possible on ChromeOS and Mac, since it's unclear from the tests.

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

commit e30abe9ad8527585fc6783d8abd24842b07f67b6
Author: creis <creis@chromium.org>
Date: Thu Apr 20 20:45:26 2017

Exclude files from FileSelectChooser if they can't convert to WebStrings.

BUG= 703303 
TEST=See bug for repro steps.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

[modify] https://crrev.com/e30abe9ad8527585fc6783d8abd24842b07f67b6/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/e30abe9ad8527585fc6783d8abd24842b07f67b6/content/browser/frame_host/render_frame_host_manager_browsertest.cc
[modify] https://crrev.com/e30abe9ad8527585fc6783d8abd24842b07f67b6/content/renderer/render_frame_impl.cc

Should be fixed in tomorrow's canary.  Once we let it bake, I'll see about merging it to M59.  It doesn't seem urgent enough for M58, though.

No need to merge to M58 as GTK3 is not enabled.  Please merge to M59, however.

Will do, but I want to verify the fix on Canary first and make sure it isn't introducing new problems.  I'll add the label back tomorrow.

60.0.3077.0 is only out for Mac so far, but the behavior seems ok there so far-- no issues with selecting files, and no new obvious crashes due to this.

The only place we could actually repro the bug is Linux GTK3 which doesn't have a canary, and I don't think we need to wait for Dev since I confirmed it in a local build already.  Should be safe to request a merge now.

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please merge your change to M59 branch #3071 latest before 4:00 PM PT, Monday (04/24) so we can take it for next week last M59 dev release. Thank you.

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

commit efe398655991dba5d5496af739257ff9811faa6e
Author: Charles Reis <creis@chromium.org>
Date: Fri Apr 21 22:47:20 2017

Exclude files from FileSelectChooser if they can't convert to WebStrings.

BUG= 703303 
TEST=See bug for repro steps.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2811533002
Cr-Commit-Position: refs/heads/master@{#466118}
(cherry picked from commit e30abe9ad8527585fc6783d8abd24842b07f67b6)

Review-Url: https://codereview.chromium.org/2832313002 .
Cr-Commit-Position: refs/branch-heads/3071@{#134}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/efe398655991dba5d5496af739257ff9811faa6e/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/efe398655991dba5d5496af739257ff9811faa6e/content/browser/frame_host/render_frame_host_manager_browsertest.cc
[modify] https://crrev.com/efe398655991dba5d5496af739257ff9811faa6e/content/renderer/render_frame_impl.cc