One z3c.rml test failure on Linux -- bug in ReportLab?
I'm not myself familiar with z3c.rml, but I was debugging a buildbot failure and found what I think is a bug in ReportLab 2.5. Try this: svn co svn://svn.zope.org/repos/main/z3c.rml/trunk z3c.rml cd z3c.rml python bootstrap.py bin/buildout bin/test I get one test failure in z3c.rml.tests.test_rml.tag-selectField If I run that test alone with bin/test -t selectField it passes. Here's a minimal test case to make it fail: bin/test -t textField -t selectField I've poked at this test failure a bit, and I suspect a bug in ReportLab. It appears that creating two documents that use PDF forms will clobber over a global object's -- reportlab.pdfbase.pdfform.GLOBALRESOURCES -- __InternalName__ attribute during the creation of the first document, and that will prevent anyone from using AcroForm.format() on any other document in that process. The next step would be to make a smaller reproducible example and submit it to the ReportLab folks for consideration. 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. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
On Monday, December 20, 2010, Marius Gedminas wrote:
ve poked at this test failure a bit, and I suspect a bug in ReportLab. It appears that creating two documents that use PDF forms will clobber over a global object's -- reportlab.pdfbase.pdfform.GLOBALRESOURCES -- __InternalName__ attribute during the creation of the first document, and that will prevent anyone from using AcroForm.format() on any other document in that process.
The next step would be to make a smaller reproducible example and submit it to the ReportLab folks for consideration.
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. This is the reason, Roger implemented running the renderer in a sub-process and all the tests are run twice. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
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
On Tuesday, December 21, 2010, Marius Gedminas wrote:
So you're saying this is a bug in z3c.rml after all? It ends up not using separate subprocesses for each test?
It runs all tests twice, once with and once without the subprocess version. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
participants (2)
-
Marius Gedminas -
Stephan Richter