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

Issue 646191 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Unit test "Credentials.DropFileSystemAccessPreservesTLS" prints an EXPECT_EQ failure, but passes

Project Member Reported by jamieliu@google.com, Sep 12 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce the problem:
./sandbox_linux_unittests -gtest_filter=Credentials.DropFileSystemAccessPreservesTLS

What is the expected behavior?
The test passes without complaint.

What went wrong?
[ RUN      ] Credentials.DropFileSystemAccessPreservesTLS
../../sandbox/linux/services/credentials_unittest.cc:257: Failure
Value of: pthread_getattr_np(pthread_self(), &attr)
  Actual: 2
Expected: 0
[       OK ] Credentials.DropFileSystemAccessPreservesTLS (1 ms)

Did this work before? N/A 

Chrome version: 52.0.2743.116  Channel: n/a
OS Version: 
Flash Version: Shockwave Flash 22.0 r0

Errno 2 is ENOENT. pthread_getattr_np(3)'s man page says:

"In addition, if thread refers to the main thread, then pthread_getattr_np() can fail because of errors from various underlying calls: fopen(3), if /proc/self/maps can't be opened; ..."

The test chroot(2)s to /proc/self/fdinfo by calling Credentials::DropFileSystemAccess() before calling pthread_getattr_np(), so I believe this "failure" is expected.
 
Cc: sriramsr@chromium.org
Components: Internals>Sandbox
Owner: rickyz@chromium.org
Status: Available (was: Unconfirmed)
Project Member

Comment 2 by sheriffbot@chromium.org, Sep 13 2016

Labels: Hotlist-Google
Project Member

Comment 3 by bugdroid1@chromium.org, Nov 2 2016

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

commit 0473e4c06b11eaeb02301cdee5e2d466c5ed8055
Author: rickyz <rickyz@chromium.org>
Date: Wed Nov 02 19:43:41 2016

Test cached PID using getpid instead of pthread_getattr_np.

Previously, we tested that glibc's cached PID was correct by relying on
an assert inside of pthread_getattr_np. This relies on a fairly
implementation-specific detail of pthread_getattr_np and is also
problematic, as glibc's pthread_getattr_np relies on reading
/proc/self/maps when called from the main thread (but the test chroots).

This change inspects the cached PID more directly using getpid instead.

BUG= 646191 

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

[modify] https://crrev.com/0473e4c06b11eaeb02301cdee5e2d466c5ed8055/sandbox/linux/services/credentials_unittest.cc

Status: Fixed (was: Available)
Apologies for the slow response - that change should fix it by testing the same thing with getpid() instead - thanks for the detailed report!

Sign in to add a comment