Issue #340 resolved
Buck Evan created an issue

This reproduces when using the ubuntu 2.7 from precise forward.

ERROR: test_subprocess_with_pth_files (tests.test_process.ProcessStartupTest)
Traceback (most recent call last):
  File "/home/buck/trees/mine/", line 673, in test_subprocess_with_pth_files
    self.assertEqual(data.summary()[''], 2)
KeyError: ''

You can reproduce the scenario with:

mkdir $VIRTUALENV/local
ln -s $VIRTUALENV/lib $VIRTUALENV/local/lib

The essential cause is that is seeing and executing twice because of the symlink, first for local/lib/ then for lib/.

MAKEPATH: ('/home/buck/venv/',)
ADDPACKAGE: subcover.pth
MAKEPATH: ('/home/buck/venv/',)
ADDPACKAGE: subcover.pth

I don't quite follow the part in between, but the result is that only the data from the first trace persists, meaning we don't get the data we want. Presumably the trace of is written first, then the earlier trace data written on top of it.

The essential problem is that if a single process calls process_startup() twice, data is lost. Worse, data generated by the second call is clobbered by data from the first.

I believe the fix would be to make coverage process_startup() idempotent. Failing that, ensuring a last-one-wins behavior would also produce desirable behavior in this case.

@ned: How would you go about solving this problem?

(Most of this information copied from an older ticket centered on another topic: issue #337)

Comments (8)

  1. Buck Evan reporter

    I've said this elsewhere, but not noted it here:

    This problem stems from a hackitty virtualenv workaround to a poorly-written ubuntu patchset.

    The problematic bit of the ubuntu patch is gone in the newest ubuntu (trusty), but the venv workaround remains, causing this issue.

  2. Buck Evan reporter

    I've repeatedly run into this on ubuntu systems when using the stock python. It's quite annoying and extremely confusing. The workaround is always rm -rf $VIRTUAL_ENV/local.

    The idempotency/last-wins fixes proposed above would work, and might be simple enough to implement. I haven't looked. I think the best fix would be to change virtualenv to fix their bug 118 a different way, not creating this local/ symlink.

  3. Ned Batchelder repo owner

    @bukzor Is this still happening for you? BTW, issue #353 also causes the "unexpected third case" assert, but for a different reason, if you want to chime in on what should happen there.

  4. Log in to comment