UserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0

Steps to reproduce the problem:
On a POSIX system, chromium will fail to run if the SingletonLock file already exists under ~/.config/chromium AND is not a symlink file, but a directory or a regular file, printing the following in the output:

may 13 10:25:48 localhost gnome-session[741]: [11231:11231:0513/102548:ERROR:process_singleton_posix.cc(268)] Failed to create /home/test/.config/chromium/SingletonLock: File exists

STEPS: 
1. With chromium NOT running, manually create a regular file or directory in ~/.config/chromium/SingletonLock
2. Try to run chromium now

What is the expected behavior?
Chromium realizes that ~/.config/chromium/SingletonLock is not a valid lock file and removes it before trying to create it for the first time on startup, resulting in the browser launching and running properly.

What went wrong?
Chromium does not remove the bogus lock file/directory on startup, this failing to launch since it can't create the symlink file at its intended destination. 

Did this work before? No 

Chrome version: master (development)  Channel: dev
OS Version: Fedora23
Flash Version: Shockwave Flash 11.2 r202

Granted, this is an unlikely situation to easily run into, but if you run into it for whatever reason then is pretty obscure to figure out what's going on unless you read process_singleton_posix.cc, that makes it clear that this case is not checked:

  // Extract the hostname and pid from the lock symlink.
  // Returns true if the lock existed.
  bool ParseLockPath(const base::FilePath& path,
                     std::string* hostname,
                     int* pid) {
    std::string real_path = ReadLink(path).value();
    if (real_path.empty())
      return false;

    [...]

    return true;
  }

The problem here is that ReadLink() will return an empty string if the file pointed by path is not a symlink, resulting in ParseLockPath indicating that "a lock does not exist" and, thus, Create() failing when calling SymlinkPath(), since it can't create a symlink named like a file that already exists.

So, I think it would be nice to have an extra check in ParseLockPath() (or elsewhere) to make sure that chromium does not ever run into this situation.