[Zope-dev] One z3c.rml test failure on Linux -- bug in ReportLab?

Marius Gedminas marius at gedmin.as
Tue Dec 21 20:39:30 EST 2010


On Mon, Dec 20, 2010 at 10:46:55PM -0500, Stephan Richter wrote:
> On Monday, December 20, 2010, Marius Gedminas wrote:
> > I'm not familiar with z3c.rml nor with ReportLab's form code, so I'd
> > appreciate if people who wrote the test could help with the smaller
> > reproducible example.
> 
> That's not a bug, but a well-known issue with ReportLab. Once you generated 
> one document with ReportLab, you are not guaranteed a clean state, since 
> ReportLab uses module-global variables to keep track of state.

That's ouch-y.  I'm relying on the ability to produce multiple documents
per process, and I've a system that does that in production.  My
documents do not use forms, though.

Incidentally, I'm almost certain this bug was introduced into reportlab
code in January 2010, by applying this patch:
http://two.pairlist.net/pipermail/reportlab-users/2010-January/009216.html

__InternalName__ is assigned only for objects that have __PDFObject__
set to True, and GLOBALRESOURCES is an instance of PDFPattern which
didn't have that attribute earlier.

I still intend to bring this up on the reportlab mailing list.

> This is the 
> reason, Roger implemented running the renderer in a sub-process and all the 
> tests are run twice.

So you're saying this is a bug in z3c.rml after all?  It ends up not
using separate subprocesses for each test?

Marius Gedminas
-- 
http://pov.lt/ -- Zope 3/BlueBream consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20101222/bb40ccdf/attachment.bin 


More information about the Zope-Dev mailing list