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

Issue 457448 link

Starred by 23 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Chromebook hangs when trying to abort an operation on File.app

Project Member Reported by rookrishna@chromium.org, Feb 10 2015

Issue description

Google Chrome	42.0.2296.0 (Official Build) canary (64-bit)
Revision	b630c8ec8572e65d39f5b83495345f2b003af5c5
Platform	6778.0.0 (Official Build) canary-channel squawks


Please specify Cr-* of the system to which this bug/feature applies (add
the label below).

Steps To Reproduce:
1.  Open a zip file from USB and try copying the file to downloads
2.
3.


 Result: Notification pops up see attached pic 
"An operation is taking longer than expected .Do you want to abort it"

Click on "Abort" - Device hangs . Only way to come out is to reboot the system.  Even after the reboot the abort Notification pops up 


Expected Result: When clicked on the Abort button the system should not hang 

How frequently does this problem reproduce? (Always, sometimes, hard to
reproduce?)
Always when clicked on the Abort button

What is the impact to the user, and is there a workaround? If so, what is
it?

Please provide any additional information below. Attach a screen shot or
log if possible.
Will attach the logs

 
Screenshot 2015-02-10 at 2.37.22 PM.png
78.2 KB View Download

Comment 2 by Deleted ...@, Feb 16 2015

YES I HAVE THE SAME PROBLEM! Can't even (insert expletive) restart the file app!
Mergedinto: 454310
Status: Duplicate
@rookrishna: This is already fixed already on the latest canary. Could you try newer version?

@iexperiment080: The fix should be available in the next beta release.

Comment 4 by Deleted ...@, Mar 25 2015

same problem on my system
Version 42.0.2311.50 beta (64-bit)
Platform 6812.42.0 (Official Build) beta-channel quawks
Firmware Google_Quawks.5216.204.6
@ray: Does it always reproduce? Can you provide steps to reproduce the issue?

Comment 6 by Deleted ...@, Jun 3 2015

Hi the same exact thing is happening to me. Wondering if it is a virus as I can't open my files folder as well. Started happen just before the last update and then didn't go away once I updated my system. System info:

Version 44.0.2403.25 beta
Platform 7077.21.0 (Official Build) beta-channel daisy_freon
Firmware Google_Snow.2695.117.0
@foleysfolly88: Does the problem happen with all ZIP files, or only with that single one?

Comment 8 by Deleted ...@, Jun 6 2015

@Mtomasz: Thanks for the quick reply. Unfortunately I wasn't able to recreate the issue. I hadn't opened up a zip file in a couple of weeks but that box just kind of randomly popped up and stay there. With that said, the latest update (Version 44.0.2403.33 beta
Platform 7077.27.0 (Official Build) beta-channel daisy_freon
Firmware Google_Snow.2695.117.0) seems to have fixed the issue for the time being. 

Thanks again for the help and I'll report back if it happens again.

Comment 9 by ke...@mac-works.com, Aug 30 2015

I'm having an identical issue with the current build (as of August 30) with "An operation is taking longer ... " about Dropbox.  Rebooting does not make it stop - nor does clicking abort.  It's been going on for over 24 hours and the thing is, I haven't added anything to my dropbox in at least a week
This seems to have come back.  Seeing this multiple times today on 60.0.3112.114 (Official Build) (64-bit)

Cc: weifangsun@chromium.org yawano@chromium.org
Labels: -ReleaseBlock-Stable -M-42 M-60
Status: Unconfirmed (was: Duplicate)
Owner: mkarkada@chromium.org
Status: Assigned (was: Unconfirmed)
mkarkada@ - Would you be able to assist and see if you're able to reproduce this issue?
Hi weifangsun, I couldn't repro this issue on M63 build (10032.4.0/ 63.0.3239.7). 
Steps I followed:
Opened a zip file from USB and tried copying a file from zip folder to Downloads. File got copied successfully. Didn't see any abort notification.
Try mounting a zip file (eg an album from Google photos in the Downloaded folder), selecting all files in it, dragging them onto a dirctory on a USB stick.  Usually hangs 2nd or third time.
Could be that you are testing on the wrong version.  I was using 60, which I think is 'stable'.
Labels: M-63
I could repro this issue with .zip file (around 200MB size, 85 items) as well as .tar.gz file (around 850+ items). I could see abort notification. I couldn't cancel the copy operation (clicking on close button in the progress center didn't help).

Feedback report for zip file:
https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=M-63&lReport=76739743381

Feedback report for .tar.gz file:
https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=M-63&lReport=76739926574

With every click on abort notification, copy operation progressed as observed with .tar.gz file. But this didn't happen with .zip file
Attaching the screenshots.
Abort notification with targz file.png
1.6 MB View Download
Abort notification with zip file.png
128 KB View Download
Cc: -bengold@chromium.org mkarkada@chromium.org
Owner: fukino@chromium.org
It turned out that libarchive's archive_read_data() sometimes does not return.
ZIP Unpacker calls it at https://chromium.googlesource.com/apps/unpacker/+/master/unpacker/cpp/volume_archive_libarchive.cc#273.
Since it does not return, ZIP Unpacker's NaCl module does not respond on READ_FILE request.

I'll check if updating libarchive fixes the issue or not. 
As we are fixing the issue in ZIP Unpacker, we are not bound to the Chrome's release schedule.
Once the issue is fixed, we can deliver the updated ZIP Unpacker via Chrome Web Store.
Cc: oka@chromium.org
+oka@ is investigating possible issue in our usage of archive_read_data().

Comment 22 by oka@chromium.org, Oct 23 2017

With printf debug, we found in the error case
the second archive_read_data call in VolumeArchiveLibarchive::DecompressData doesn't return.

https://chromium.googlesource.com/apps/unpacker/+/e4901d7475b6531c5740ee8952cf61be73cd9fcc/unpacker/cpp/volume_archive_libarchive.cc#264
Cc: yamaguchi@chromium.org

Comment 24 by oka@chromium.org, Oct 23 2017

CustomArchiveRead doesn't return.

Comment 25 by oka@chromium.org, Oct 23 2017

NaCL stuck on the line
pthread_cond_wait(&available_data_cond_, &shared_state_lock_);
in VolumeReaderJavaScriptStream::Read.
https://chromium.googlesource.com/apps/unpacker/+/e4901d7475b6531c5740ee8952cf61be73cd9fcc/unpacker/cpp/volume_reader_javascript_stream.cc#134
The method called from CustomArchiveRead, the callback for archive_read_data, called from DecompressData.


Comment 26 by oka@chromium.org, Oct 23 2017

On erroneous case, 
reader_request_id_ is somehow empty on a ReadChunkDone call, and the then-statement of the if-clause

  if (request_id == reader_request_id_) {
    static_cast<VolumeReaderJavaScriptStream*>(volume_archive_->reader())->
        SetBufferAndSignal(array_buffer, read_offset);
  }

is not exercised.
That's why the pthread_cond_wait in #25 waits forever.

As I investigated, CloseFileCallback is what clears reader_request_id_ too early (before the last ReadChunkDone call for that file).

Comment 27 by oka@chromium.org, Oct 24 2017

Uploaded
https://chromium-review.googlesource.com/c/apps/unpacker/+/735361
to fix the hang explained in #26.
But Fukino-san found there's other scenario causing a hang.
Good news! The root cause was identified.
The issue occurs in following steps:

0) Assume that the content of file A starts from offset 100 and its length is 100 in zip file, and file B starts offset 200.
1) READ_FILE for A is requested.
2) VolumeReaderJavaScriptStream requests READ_CHUNK for [100, 200).
https://chromium.googlesource.com/apps/unpacker/+/master/unpacker/cpp/volume_reader_javascript_stream.cc#124
3) READ_CHUNK is done. It restarts the Read method and fills the buffer for libarchive.
https://chromium.googlesource.com/apps/unpacker/+/master/unpacker/cpp/volume.cc#266
4) VolumeReaderJavaScriptStream requests READ_CHUNK for [200, 300) to read ahead. <= trigger!
https://chromium.googlesource.com/apps/unpacker/+/master/unpacker/cpp/volume_reader_javascript_stream.cc#179
5) READ_FILE for A is done.
6) CLOSE_FILE for A is requested.
7) CLOSE_FILE for A is done. |reader_request_id_| is cleard in Volume.
https://chromium.googlesource.com/apps/unpacker/+/master/unpacker/cpp/volume.cc#409
8) READ_CHUNK from step 4 is done, but it is ignored since there is no active |reader_request_id_|.
https://chromium.googlesource.com/apps/unpacker/+/master/unpacker/cpp/volume.cc#264
9) READ_FILE for B is requested.
10) VolumeReaderJavaScriptStream::Read() skips to request READ_CHUNK, expecting that it was already requested in previous READ() call (in step 4).
https://chromium.googlesource.com/apps/unpacker/+/master/unpacker/cpp/volume_reader_javascript_stream.cc#123
11) VolumeReaderJavaScriptStream waits the buffer to be filled (and signaled), but it won't be happen since READ_CHUNK callback was ignored in step 8.
It waits the condition here eternally.
https://chromium.googlesource.com/apps/unpacker/+/master/unpacker/cpp/volume_reader_javascript_stream.cc#134

The problem here is that the READ_CHUNK request is tied to |reader_request_id_| but READ_CHUNK is also used to read ahead the adjacent data.
In theory, there is no related |reader_request_id_| when reading ahead.
I guess we can always fill the buffer when READ_CHUNK is done and signal the VolumeReaderJavaScriptStream.

As far as I tested, the issue has gone by a simple patch.
https://chromium-review.googlesource.com/c/apps/unpacker/+/734929
We need some time to look into the side effect carefully.
TL;DR:
We have a patch to fix the issue.
We can deliver the fixed version ZIP Unpacker via Chrome Web Store. No need to wait M63 etc...
We need to review and test the patch, but we should be able to start delivering the fix to Canary users in a few days.
If we don't have a serious issue on the new version, we can push the fix to Stable users in a week or two, I guess.
Project Member

Comment 30 by bugdroid1@chromium.org, Oct 27 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/apps/unpacker/+/f92d858537346a95e9665251c8cc0f4ee060fe51

commit f92d858537346a95e9665251c8cc0f4ee060fe51
Author: Naoki Fukino <fukino@chromium.org>
Date: Thu Oct 26 04:25:57 2017

Always update buffer and send signal when ReadChunk is done.

There is a chance that VolumeReaderJavaScriptStream::Read() waits a response of
ReadChunk forever.
The problematic scenario is illustrated in
https://bugs.chromium.org/p/chromium/issues/detail?id=457448#c28

VolumeReaderJavaScriptStream can request ReadChunk without a client's request to
read ahead.
It expects a response through VolumeReaderJavaScriptStream::SetBufferAndSignal,
but a response can be ignored in Volume::Volume::ReadChunkDone() if the file for
previous Read request is already closed. This can cause Read() to be hanged.

Considering the case of reading ahead (without explicit Read requests from
client), I think we should always set buffer and signal
VolumeReaderJavaScriptStream when ReadChunk is done.

BUG= chromium:457448 
TEST=Open a zip file which contains 1000 photos, and browse photos by
scrolling randomly.
Change-Id: I4850b89ee6d5f8e808e0c94f76aabb4a3eda35b7

[modify] https://crrev.com/f92d858537346a95e9665251c8cc0f4ee060fe51/unpacker/manifest.json
[modify] https://crrev.com/f92d858537346a95e9665251c8cc0f4ee060fe51/unpacker/cpp/volume.cc

Cc: fukino@chromium.org ajha@chromium.org krajshree@chromium.org klemenko@google.com brajkumar@chromium.org
 Issue 762887  has been merged into this issue.
Cc: jkardatzke@chromium.org
 Issue 748320  has been merged into this issue.
Issue 732886 has been merged into this issue.
Status: Fixed (was: Assigned)
The fix (in comment #30) was pushed to everyone via CWS.
Project Member

Comment 35 by bugdroid1@chromium.org, Nov 22 2017

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

commit 84162268bd9f64ea587a5666a15182dcff8a7502
Author: Naoki Fukino <fukino@chromium.org>
Date: Wed Nov 22 09:07:35 2017

Always update buffer and send signal when ReadChunk is done.

There is a chance that VolumeReaderJavaScriptStream::Read() waits a response of
ReadChunk forever.
The problematic scenario is illustrated in
https://bugs.chromium.org/p/chromium/issues/detail?id=457448#c28

VolumeReaderJavaScriptStream can request ReadChunk without a client's request to
read ahead.
It expects a response through VolumeReaderJavaScriptStream::SetBufferAndSignal,
but a response can be ignored in Volume::Volume::ReadChunkDone() if the file for
previous Read request is already closed. This can cause Read() to be hanged.

Considering the case of reading ahead (without explicit Read requests from
client), I think we should always set buffer and signal
VolumeReaderJavaScriptStream when ReadChunk is done.

scrolling randomly.

Bug:  457448 
Test: Open a zip file which contains 1000 photos, and browse photos by
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Iade702bf06042d9687f0a5793833d2486a3d761a
Reviewed-on: https://chromium-review.googlesource.com/784692
Reviewed-by: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Reviewed-by: Tomasz Mikolajewski <mtomasz@chromium.org>
Commit-Queue: Naoki Fukino <fukino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518576}
[modify] https://crrev.com/84162268bd9f64ea587a5666a15182dcff8a7502/chrome/browser/resources/chromeos/zip_archiver/cpp/volume.cc

 Issue 477738  has been merged into this issue.
Cc: rookrishna@chromium.org abod...@chromium.org sdantul...@chromium.org
 Issue 658465  has been merged into this issue.

Sign in to add a comment