C tracer: lookups fail in "should_trace_cache"

Issue #374 resolved
created an issue

The C tracer misuses the "should_trace_cache" to store two different things: Disposition objects and True/False, which makes later lookups fail with an AttributeError because True/False don't have a "trace" attribute. I attached a fix. Not sure if it's the correct one.

One thing I'm unsure about is whether the object returned from the cache lookup ("included") should be used as the new disposition object instead of the current one. But my guess is it shouldn't.

Comments (6)

  1. sbehnel reporter

    It currently makes Cython code tracing fail, but I don't have a self-contained example. My guess is that any plugin that uses the "dynamic_source_filename" feature would simply fail to work.

  2. Matthew Seal

    I have a fairly complicated Cython repository I work with, and I needed to generate coverage numbers for the repository. This patch saved me from digging into the tracer code depths. The condition manifested for me with all pure python functions and classes exploding inside pyx files when linetracing was turned on during a coverage run call. I would see messages of the form "AttributeError: 'bool' object has no attribute 'trace'" with a stacktrace to a pure python element. All the problems went away when I applied the patch to coverage.py. I can probably create a subset of the problems in a minimal cython repo (0.23dev) if it helps get this patch applied/merged.

  3. Ned Batchelder repo owner

    Fixed in 2c6a6b3a4488.

    The reason this happens with Cython and not other dynamic_source_filename uses is that you are returning the same the original filename from dynamic_source_filename. That is, dynamic_source_filename isn't returning a new name, it's just returning the same name we already had. I'm not sure this is what you want.

    And with this fix, I no longer see AttributeErrors when running the Cython coverage tests, but I still see test failures.

  4. Log in to comment