Lopping to Enterprise folks as well as the source owners from the log file.

//src/components/leveldb_proto/OWNERS
//src/content/browser/indexed_db/OWNERS

Tagging with RB for M55, please feel free to remove if needed.

Could it be an update in the levelDB lib that caused this?

cmumford@ - can you take a look?

At first glance this appears to be a duplicate of issue 647385 (sorry Google internal). The root cause of 647385 is the fact that file locking [fcntl(..., F_SETLK, ...)] isn't supported on network filesystems.

traverj: I'm slightly confused by your description. Are you saying that 49/50/51/52 all worked before September/October, but afterwards they stopped working? Or are you saying that this worked up through 52, but now does not?

Here is the stable release dates for the M51,52,53 and 54. May be broken during 53 time frame?

51.0.2704.106 - 06/22/2016
52.0.2743.118 - 08/18/2016
53.2785.143   - 09/29/2016
54.0.2840.99  -11/09/16 

Very minor changes in leveldb between M49 and M54:

  git diff 706b7f8..a7bff69

The leveldb environment changes are mostly related to backup files:

  git diff 92d77538a..1ae106dbab third_party/leveldatabase

there are more file changes (39 of them), but I don't see anything yet:

  git log 92d77538a..1ae106dbab base/files

**** Bulk edit -  please ignore if not applicable ****


A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure fix is ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16 (sooner the better).

@cmumford : Versions 49,50,51,52 were working properly until September/October, now only version 49 is working fine, the newer versions are showing the same bug. I am using 49.0.2623.110 as a working version, and versions listed in #7 as buggy ones (plus 50.0.2661.102).

To add more info, command line log is quite similiar either in working version or buggy ones:

* 49 *
[6961:7041:1113/090403:ERROR:leveldb_database.cc(405)] LevelDB write failed: IO error: /mnt/my_cifs_share/testgl/Default/IndexedDB/https_drive.google.com_0.indexeddb.leveldb: FILE_ERROR_FAILED (ChromeMethodBFE: 19::SyncParent::1)
[6961:7041:1113/090403:ERROR:indexed_db_backing_store.cc(4276)] IndexedDB Write Error: TRANSACTION_COMMIT_METHOD


* 54 *
[22056:22088:1114/090830:ERROR:leveldb_database.cc(421)] LevelDB write failed: IO error: /mnt/my_cifs_share/testgl/Default/IndexedDB/https_drive.google.com_0.indexeddb.leveldb: FILE_ERROR_FAILED (ChromeMethodBFE: 19::SyncParent::1)
[22056:22088:1114/090830:ERROR:indexed_db_backing_store.cc(4247)] IndexedDB Write Error: TRANSACTION_COMMIT_METHOD

Just FYI I tried to reproduce this issue with a CIFS mounted FS on Ubuntu 16.04 (in a VM I had lying around) and Chrome 54 runs just fine with a profile on the network mount. Maybe the exact OS also matters, or the mount options.

pastarmovj@: I tried to do the same with Ubuntu 16.10 in a VM and I wasn't able to achieve your results, although network share is mounted and it seems to be working fine. Default server with a shared resource and mounting it with default variables (also tried adding nobrl). Results with Chrome 54 is the unresponsive web page not loading fine.

Client mount options shown: 
//localhost/ubuntu on /mnt/own type cifs (rw,relatime,vers=1.0,cache=strict,username=ubuntu,domain=UBUNTU,uid=999,forceuid,gid=999,forcegid,addr=127.0.0.1,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1

Server options, besides default ones in ubuntu:
[ubuntu]
        path = /mnt/my_own_cifs
        read only = No
        valid users = ubuntu


Since I published this bug some days ago, I am having difficulties trying to succesfully repeat 100% of the times a valid test with version 49 because it is failing as in the other versions. I attach a couple of screenshots with versions 49 and 54 just to clarify what I'm getting (sorry, spanish language configured).

Under no circumstances have I been able to run latest Chrome version on a CIFs share. Please tell me If i could add any other test or log file in order to help.

Deleted: drive-chrome49.png 216 KB

	drive-chrome49.png 216 KB View Download

Deleted: drive-chrome54.png 59.5 KB

	drive-chrome54.png 59.5 KB View Download

traverj@ How did you create your share? If I create one with a Workstation version of Windows then Chrome fails to start due to a check in ProcessSingleton. Do I need Windows Server that supports file locking?

cmumford@ we offer those shared resources, at our university, with a Linux SAMBA server based on CentOS and then clients, either CentOS or Windows, mount it as a CIFS resource/shared resource. I have also tried Ubuntu and its SAMBA server, as per comments #12 and #13, with a similar configuration and the same results. Using Unix Extensions is the key to avoid this ProcessSingleton failure.

I am not familiar enough with Windows Server to offer shares that may include Unix Extensions compatibility (Services for Unix, I guess), so I can't tell the right way to set it up in Windows.

Thx traverj@. Unix Extensions was the hint I needed, and knowing you're using a Linux based Samba server is very helpful.

traverj@: The failure is caused by fdatasync/fsync returning -1 (errno set to EINVAL) when trying to sync the leveldb directory. This is not new to M49, and has been there for a long time (way before M41). I've bisected to M45, and All builds (M45..M54) fail with the error you describe in your description.

From my /etc/samba/smb.conf file:

[global]
   unix extensions = yes

...

[smbtest]
   comment = Test Samba share for debugging
   path = /path/to/share/dir
   browseable = yes
   read only = no
   guest ok = no

And I'm mounting it as so:

sudo mount --rw -t cifs -o credentials=$HOME/credentials,uid=$uid,cache=strict,posixpaths,serverino,acl //$hostname/smbtest $localdir

My Samba server *is* the same machine on which I'm mounting the shared folder, but $hostname isn't localhost, so I think this is the same as using a separate machine.

Do you see a configuration that I'm missing that should allow fsync to work?

Attaching simple test program to fsync the current directory. mount.cifs supports sync'ing files, but not the directory (based on my testing so far).

Deleted: dir-sync-test.cc 685 bytes

dir-sync-test.cc 685 bytes View Download

cmumford@: your configuration and client mount options look fine to me, being unix extensions the main key. Ours is nearly identical with few changes to better fit our needs but nothing related to fsync, as far as I know.

traverj@: When testing 49 vs. 50/51/etc. Are you testing on the same machine without remounting the drive?

cmumford@: As I said in #12, I haven't been able to deterministically reproduce it in 49 with a 100% success rate. Recently, only about 1 out of 10 is what I get now or even less. I haven't been able to get a single success in version 54.

I have tried with and without (re)mounting remote share each time and results are the same. Main tests are done in different machines (server/client) but I have also tried it in the same machine and the results are the same (either with or without remounting the volume), I haven't found any difference.

Had an offline chat with cmumford@,according to him this shouldn't be an Blocker since bug reporter( traverj@) isn't able to reproduce this successfully. 

But cmumford@ continue to work the bug to get the fix.

Removing "ReleaseBlock-Stable" label based on comment #22.

I completely agree on you, as this bug only affects a small part of users. Please, set the pace to solve this bug that better fits your work without blocking any release.

I would like to add, just to clarify my previous comments, that this bug is 100% reproducible in latest stable version at our different tested environments. 

I also use a similar solution with Samba 3.6.29 server (CentOS 6.5) on one side and on the client machines Ubuntu14.04, which is mounted user profiles "/ home / users" of the Samba server on the other side. When https://drive.google.com launch of Google Chrome or Chromium appears similar problem.
I confirm interest in promptly correcting this problem, too. This is a really important issue. Thank you.