Debian's python produces a different finalizers.png

Bug #686731 reported by Stefano Rivera on 2010-12-07
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
objgraph
Fix Released
Low
Unassigned

Bug Description

Was just updating the Debian package when I ran into this:
======================================================================
FAIL: Doctest: uncollectable.txt
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/doctest.py", line 2163, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for uncollectable.txt
  File "uncollectable.txt", line 0

----------------------------------------------------------------------
File "uncollectable.txt", line 22, in uncollectable.txt
Failed example:
    objgraph.show_backrefs(objgraph.by_type('Nondestructible'),
                           filename='finalizers.png')
Expected:
    Graph written to ....dot (3 nodes)
    Image generated as finalizers.png
Got:
    Graph written to /tmp/tmpX5xY0v.dot (8 nodes)
    Image generated as finalizers.png

----------------------------------------------------------------------
Ran 9 tests in 1.154s

FAILED (failures=1)

This happens with python2.5 and 2.6 on squeeze. It's fine on Ubuntu. Not entirely sure why.

Related branches

Stefano Rivera (stefanor) wrote :
Stefano Rivera (stefanor) wrote :

Fine on sid too (repeatably)

Changed in objgraph:
importance: Undecided → Low
Marius Gedminas (mgedmin) wrote :

And I was wondering recently why I *didn't* see the gc.garbage list in the finalizers.png graph on my machine (Ubuntu, various Python versions).

I've got a Debian box here (don't even remember the version), I'll turn it on and try to reproduce.

This is not a serious issue; perhaps the test should be fixed to accept either number of nodes (using an ellipsis instead of the number).

Marius Gedminas (mgedmin) wrote :

I can't reproduce this with Python 2.5 on Debian lenny.

Hi Marius (2010.12.08_15:31:06_+0200)
> I've got a Debian box here (don't even remember the version), I'll turn
> it on and try to reproduce.

I can't replicate it in a clean chroot with the same packages installed
or another machine. I can't see what's causing this difference and why.
(I'm not about to read Python's garbage collector :P )

> This is not a serious issue; perhaps the test should be fixed to accept
> either number of nodes (using an ellipsis instead of the number).

That sounds sensible enough.

BTW, the test doesn't fail (return non-zero) if it fails, can you please
use the TestResult you get back from TextTestRunner to exit()
appropriately?

SR

--
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127

Marius Gedminas (mgedmin) wrote :

'make test' *should* return non-zero if this happens, and I'm pretty sure it does.

'make images' didn't bother, because it's main purpose is to regenerate the images that accompany the documentation, and it's intended to be run by the maintainer (i.e. myself) manually, with careful manual inspection of the images to see that they make sense. On second thought, a command like 'make clean images docs' should abort if a syntax error or whatnot prevents the images from being generated at all, so I've change the build-images in setup.py to sys.exit(1) if the doctests fail.

I don't know what to do about the main issue, though. I'd love to be able to reproduce it; I was going to try schroot, but now that you say you can't reproduce it in a chroot, I'm not sure anymore. I tried to get Ubuntu's python to put the uncollectable object into gc.garbage, without success.

I'll try a different approach.

Marius Gedminas (mgedmin) wrote :

I managed to convince Python to put this object into gc.garbage on my machine, with all Python versions. Not sure why my attempt to do the same failed earlier; I used the same approach again...

Changed in objgraph:
status: New → Fix Committed
Stefano Rivera (stefanor) wrote :

> 'make test' *should* return non-zero if this happens, and I'm pretty
> sure it does.

Aah, right it does. I'd ignored that because I was running make images,
anyway.

> On second thought, a command like 'make clean images docs' should
> abort if a syntax error or whatnot prevents the images from being
> generated at all, so I've change the build-images in setup.py to
> sys.exit(1) if the doctests fail.

Thanks, it's nice for me to have the build fail if anything goes wrong.

Marius Gedminas (mgedmin) wrote :

FWIW I don't think you should be running 'make images' during a build. The images in the released tarball (or the bazaar branch revision tagged as a release) will be up-to-date.

I'm generally against committing generated files into a source repository, but in this case the images are documenting expected output, as an aid for manual testing, so I want known good versions of them to be present in the repo.

If you want to generate HTML docs for /usr/share/doc/, 'make clean html' will suffice -- it'll copy the png images into _build/html/.

Changed in objgraph:
status: Fix Committed → Fix Released
Marius Gedminas (mgedmin) wrote :

I've just released 1.5.1 with this fix.

Stefano Rivera (stefanor) wrote :

> FWIW I don't think you should be running 'make images' during a build.

General Debian policy is to rebuild all generated files from source
during build. This is partially to show that it can be done.

I'm happy enough not to, if you are concerned about it.

> If you want to generate HTML docs for /usr/share/doc/, 'make clean html'
> will suffice -- it'll copy the png images into _build/html/.

Yes, I'm using make docs:

http://svn.debian.org/viewsvn/python-modules/packages/objgraph/trunk/debian/rules?revision=15047&view=markup

Marius Gedminas (mgedmin) wrote :

I'm -0 for rebuilding them: this would result in the figures in /usr/share being different from the ones on the project website for the same version. 'make test' is sufficient to show the generation will work -- it performs the same thing as 'make images', but in a temporary directory that's cleaned up at the end.

I'd change my opinion to +1 if the images didn't change after every rebuild. This seems non-trivial; I'd probably need a registry of custom functions to replace repr() in order to avoid memory addresses of things like DocTestRunner instances appearing in the rendered image. Or I could hardcode them all with a series of ifs in my short_repr, but I already feel like I have enough special saces there. Hm. This bears more thinking about.

(I assume you're familiar with the numerical expressions of approval used in the Python community: -0 means neutrality, with a slight bias against the change; +1 means agreement.)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments