The original report in Feedback contained 2 issues.
- Cloud Backup doesn't start when an SD card is plugged in.
- When the SD card is unplugged, browser crashes.

The original report was sent from the URL https://photos.google.com/ .
Therefore it might be referring to an issue different component.
Since the report was from internal user, I will contact the person to get more details.


57.0.2951.0 (Official Build) unknown
9086.0.0 (Official Build) dev-channel samus test

Did not reproduce.
When an SD card with some files in /DCIM folder was plugged, new Files app window opened and started scan for Cloud Import.
Unplugged during the scan for Cloud Import, no browser window nor Files app window crashed.


However, I could see it sometimes took longer time (more than 3 seconds) before the Files app recognize the media removal.

This bug is likely to be relevant.
https://bugs.chromium.org/p/chromium/issues/detail?id=513943

As suggested by satorux@ offline, I tried this scenario and could sometimes reproduce crash (4 out of 6):
1. exFAT SD card with many (~60) large (4000px*3000px) jpeg files in it.
2. Open the folder in Files app
3. See Files app gradually shows thumbnails of image files.
4. Eject the SD card when ~10 thumbnails appeared. (must not too early or too late)

> [5401:5432:0119/005952.176874:FATAL:scoped_file.cc(45)] Check failed: 0 == ret. : Input/output error
This check fails.
https://cs.chromium.org/chromium/src/base/files/scoped_file.cc?q=file:scoped_file.cc&sq=package:chromium&dr&l=40

So far I did not see a crash with a fat32-formatted card on the same condition (0 out of 7 trials).

Can you get the stack trace of the crash to understand how the file was closed? 

Chrome shouldn't crash with unplugging of an SD card. We should allow close() error on these cases. 

I got a stack trace (with non-debug build).

[14889:14889:0119/131310.486273:WARNING:disk_mount_manager.cc(512)] Found disk /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host19/target19:0:0/19:0:0:0/block/sdb/sdb1
[14889:15093:0119/131312.326518:FATAL:scoped_file.cc(40)] Check failed: 0 == ret. : Input/output error
#0 0x7ff48edad196 base::debug::StackTrace::StackTrace()
#1 0x7ff48edc585e logging::LogMessage::~LogMessage()
#2 0x7ff48edc6cfe logging::ErrnoLogMessage::~ErrnoLogMessage()
#3 0x7ff48edc09c5 base::internal::ScopedFDCloseTraits::Free()
#4 0x7ff48edb8bc5 base::File::Close()
#5 0x7ff48eebfed9 net::FileStream::Context::CloseFileImpl()
#6 0x7ff48eec0122 _ZN4base8internal7InvokerINS0_9BindStateINS0_18IgnoreResultHelperIMN3net10FileStream7ContextEFNS6_8IOResultEvEEEJNS0_12OwnedWrapperIS6_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
#7 0x7ff48ee49afb base::debug::TaskAnnotator::RunTask()
#8 0x7ff48edcd8df base::MessageLoop::RunTask()
#9 0x7ff48edcdd6e base::MessageLoop::DeferOrRunPendingTask()
#10 0x7ff48edd0228 base::MessageLoop::DoWork()
#11 0x7ff48edd0789 base::MessagePumpLibevent::Run()
#12 0x7ff48edcd65a base::MessageLoop::RunHandler()
#13 0x7ff48edf429d base::RunLoop::Run()
#14 0x7ff48dd4df9c content::BrowserThreadImpl::FileThreadRun()
#15 0x7ff48dd4e79d content::BrowserThreadImpl::Run()
#16 0x7ff48ee1906b base::Thread::ThreadMain()
#17 0x7ff48ee14916 base::(anonymous namespace)::ThreadFunc()
#18 0x7ff48bc97578 <unknown>
#19 0x7ff48a9ef6dd clone

Oh I see. It's hard to see where the task was created from the stack trace itself. It seems that the file was opened with net::FileStream. Maybe you could add logging to net::FileStream to identify how files on the SD card are opened. base::debug::StackTrace() might be useful for the logging.

Thanks, I could get a stack trace at net::FileStream::Close and got one possible path the leads to a crash.

#1 0x7f1f857ae83b net::FileStream::Close()
#2 0x7f1f847e7318 content::RedirectToFileResourceHandler::~RedirectToFileResourceHandler()
#3 0x7f1f847e7381 content::RedirectToFileResourceHandler::~RedirectToFileResourceHandler()
#4 0x7f1f847ddd35 content::LayeredResourceHandler::~LayeredResourceHandler()
#5 0x7f1f847dd0ba content::InterceptingResourceHandler::~InterceptingResourceHandler()
#6 0x7f1f847dd151 content::InterceptingResourceHandler::~InterceptingResourceHandler()
#7 0x7f1f847ddd35 content::LayeredResourceHandler::~LayeredResourceHandler()
#8 0x7f1f84800ec1 content::ThrottlingResourceHandler::~ThrottlingResourceHandler()
#9 0x7f1f847ddd35 content::LayeredResourceHandler::~LayeredResourceHandler()
#10 0x7f1f847de2f1 content::MimeSniffingResourceHandler::~MimeSniffingResourceHandler()
#11 0x7f1f847ddd35 content::LayeredResourceHandler::~LayeredResourceHandler()
#12 0x7f1f84800ec1 content::ThrottlingResourceHandler::~ThrottlingResourceHandler()
#13 0x7f1f847f70df content::ResourceLoader::~ResourceLoader()
#14 0x7f1f847f71e1 content::ResourceLoader::~ResourceLoader()
#15 0x7f1f847f27b6 content::ResourceDispatcherHostImpl::RemovePendingLoader()
#16 0x7f1f847f283a content::ResourceDispatcherHostImpl::RemovePendingRequest()
#17 0x7f1f847f2b62 content::ResourceDispatcherHostImpl::DidFinishLoading()
#18 0x7f1f847f726b content::ResourceLoader::CallDidFinishLoading()
#19 0x7f1f847f8c88 content::ResourceLoader::ResponseCompleted()
#20 0x7f1f847f990a content::ResourceLoader::OnResponseStarted()
#21 0x7f1f86f59604 storage::FileSystemURLRequestJob::DidGetMetadata()
#22 0x7f1f86f10d38 storage::FileSystemOperationRunner::DidGetMetadata()
#23 0x7f1f86f4fc2f storage::(anonymous namespace)::GetFileInfoHelper::ReplyFileInfo()
#24 0x7f1f857037a9 base::(anonymous namespace)::PostTaskAndReplyRelay::RunReplyAndSelfDestruct()
...

Based on this, a better way to reproduce a crash would be:
1. add usleep() and logging code right after this line (CreateFileStreamReader() call):
https://cs.chromium.org/chromium/src/storage/browser/fileapi/file_system_url_request_job.cc?q=CreateFileStreamReader+file:file_system_url_request_job.cc&sq=package:chromium&l=224
2. In a folder in an SD card containing several large images, open one of the files in the Gallery app. (it always loads thumbnails from files after start.)
3. Eject the card as soon as the thumbnails in the ribbon starts to load (or by looking log message).

I could confirm that the essential cause of this issue here is:
- close() fails with errno=5 (EIO) when an exFAT disk was removed before executing it
- ScopedFDCloseTraits::Free() is made to crash when close() failed, because of a security reason:
https://cs.chromium.org/chromium/src/base/files/scoped_file.cc?q=file:src/base/files+scopedfdclosetraits&sq=package:chromium&l=24&dr=CSs

>  // It's important to crash here.
>  // There are security implications to not closing a file descriptor
>  // properly. As file descriptors are "capabilities", keeping them open
>  // would make the current process keep access to a resource. Much of
>  // Chrome relies on being able to "drop" such access.
>  // It's especially problematic on Linux with the setuid sandbox, where
>  // a single open directory would bypass the entire security model.

However, I also found this note in Linux manpage:
http://man7.org/linux/man-pages/man2/close.2.html
> Note, however, that a failure return should be used only for diagnostic purposes 
>  ...
> ... This can occur because the Linux kernel always releases
>       the file descriptor early in the close operation, freeing it for
>       reuse; 
There seems no way to recover from an error by close() call for a process.
Also, EIO (I/O error) indicates several types of errors like physical disk issues.
One idea I can imagine is to examine the device type after this kind of error and if it's a removable drive (of a one after removed), consider the disk was ejected. It's safe to continue because any user on the system should already have access to the physical detachable storage device.
Though I am not sure if this is 100% safe with the setuid sandbox.

+Brett, may I ask you correct me if I'm wrong?

yamaguchi: instead of touching base/files/scoped_file.cc, can we fix this in a higher level?

I saw a change lately that was to allow  errors from close() because errors like ENODEV are expected when you remove input devices (ex. mouse) are unplugged: https://codereview.chromium.org/2639043002/

I got that this is not specific bug to Files app or Gallery.

As the easiest way, I could reproduce this with the browser by opening an HTML file with many IMG elements pointing to large image files, like this:
<img src='001.jpg' width=100 height=80><br>
<img src='002.jpg' width=100 height=80><br>
<img src='003.jpg' width=100 height=80><br>
<img src='004.jpg' width=100 height=80><br>
and then ejecting the disk as soon as a part of the first image begins to appear.

I think it happens with Gallery and Files app frequently, as it uses many images in its UI. (including the loading of thumbnails)

I'll look into how this happens specifically with exFAT, and will file a separate bug.

With the HTML experiment, did the browser crash, or was it just a tab that got crashed?

The browser crashed, like the case of Files app.
The entire screen blacked out tentatively, and when the screen is back, a single plain browser window opens with a message that says Chromium did not exit normally.

Filed  Issue 683136 .

This is not a bug in the Files app.
Closing as Duplicate of  Issue 683136 .