Zope2.7.0rc2 AttributeError: 'NoneType' object has no attribute 'setHeader'
Hi all, We're in the process of migrating our sites to 2.7, so to get the guys up to speed we picked a site at random today. Did the /usr/local/zope/bin/mkzopeinstance.py jig (works very well), copied the Data.fs, some external methods, a Zwiki product and were good to go. This is from a Zope-2.6.1 site. We found out that LocalFS needed updating, so found a 2.7 compatible version and installed that. http://www.my-zope.org/Members/kedai/LocalFS-1-1-0.tgz/file_view Now we have a very peculiar error, that I'm not posting to the Zope list as it's the RC2 version of Zope2.7 that we're using. We have an index_html (initially DTML document, then tried method) that can be created (located at /prototype/myporfolio/index_html), have it's security settings changed quite happily. Then when the object is called we get the error in the subject line. The system specs are; Zope Version (2.7.0rc2, python 2.3.3, sunos5) Python Version 2.3.3 (#3, Jan 23 2004, 13:36:43) [GCC 2.95.3 20010315 (release)] System Platform sunos5 SOFTWARE_HOME /usr/local/zope/lib/python ZOPE_HOME /usr/local/zope and the traceback is; Traceback (innermost last): Module ZPublisher.Publish, line 100, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 40, in call_object Module Shared.DC.Scripts.Bindings, line 306, in __call__ Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec Module App.special_dtml, line 175, in _exec Module Shared.DC.Scripts.Bindings, line 320, in __render_with_namespace__ Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec Module App.special_dtml, line 175, in _exec Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: RESPONSE Module <string>, line 0, in ? AttributeError: 'NoneType' object has no attribute 'setHeader' I have never seen anything like this from Zope before (been using it since 1.0.3 so I've seen it do quite a bit! :). I've looked through the zope-dev archives and can't find anything related (unless it's got something to do with manage_page_charset not being callable? The only thing I could find on the collector was issue 381, http://collector.zope.org/Zope/381 'HEAD request method broken' - but that doesn't seem relevant in this condition. *Any* thoughts would be gratefully received. To recap, we took a pretty plain 2.6.1 site, loaded it into 2.7.0rc2 and get the traceback above... cheers tone. -- Dr Tony McDonald, Asst Director, FMSC. 0191 245 4223 Project Manager, FDTL-4 ePortfolios http://www.eportfolios.ac.uk/
Tony McDonald wrote at 2004-2-5 12:43 +0000:
... We have an index_html (initially DTML document, then tried method) that can be created (located at /prototype/myporfolio/index_html), have it's security settings changed quite happily. Then when the object is called we get the error in the subject line. The system specs are; ... and the traceback is;
Traceback (innermost last): ... Module Shared.DC.Scripts.Bindings, line 320, in __render_with_namespace__ Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec Module App.special_dtml, line 175, in _exec Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: RESPONSE Module <string>, line 0, in ? AttributeError: 'NoneType' object has no attribute 'setHeader'
Looks like "RESPONSE" is "None". I do not see how this can happen... Probably, I would start debugging. -- Dieter
Thanks for the response Dieter, On 5 Feb 2004, at 18:51, Dieter Maurer wrote:
Tony McDonald wrote at 2004-2-5 12:43 +0000:
... We have an index_html (initially DTML document, then tried method) that can be created (located at /prototype/myporfolio/index_html), have it's security settings changed quite happily. Then when the object is called we get the error in the subject line. The system specs are; ... and the traceback is;
Traceback (innermost last): ... Module Shared.DC.Scripts.Bindings, line 320, in __render_with_namespace__ Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec Module App.special_dtml, line 175, in _exec Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: RESPONSE Module <string>, line 0, in ? AttributeError: 'NoneType' object has no attribute 'setHeader'
Looks like "RESPONSE" is "None".
I do not see how this can happen...
Exactly! - this is why I said I'd never seen this before. It's a 2.6.1 Data.fs that's been dropped into a stock 2.7.0rc2 release and I get this error. I have no idea why this is happening, so I was hoping that it was an artifact of the 2.7.0rc2 release itself.
Probably, I would start debugging.
Quite likely, but I have *no* idea where to start with this. All the modules mentioned in the trackback are Zope supplied ones, not third party ones, so I'd assumed it might be the core software.
-- Dieter
once again, thanks for the reply Dieter. tone. -- Dr Tony McDonald, Asst Director, FMSC. 0191 245 4223 Project Manager, FDTL-4 ePortfolios http://www.eportfolios.ac.uk/
Tony McDonald wrote at 2004-2-5 19:29 +0000:
...
Looks like "RESPONSE" is "None".
I do not see how this can happen...
Exactly! - this is why I said I'd never seen this before.
It's a 2.6.1 Data.fs that's been dropped into a stock 2.7.0rc2 release and I get this error.
Whether or not "RESPONSE" is "None" should not be dependent on the "Data.fs" ("RESPONSE" is recreated for each request and is independent of persistent objects).
I have no idea why this is happening, so I was hoping that it was an artifact of the 2.7.0rc2 release itself.
Probably, I would start debugging.
Quite likely, but I have *no* idea where to start with this. All the modules mentioned in the trackback are Zope supplied ones, not third party ones, so I'd assumed it might be the core software.
"REQUEST.RESPONSE" is set up in "ZServer.HTTPServer.zhttp_handler.continue_request". It should be impossible that is is "None". Maybe, we have a memory corruption. I have seen objects magically becoming "None" in Python versions with memory corruption problems (Python 2.1.1). -- Dieter
From: "Dieter Maurer" <dieter@handshake.de>
Maybe, we have a memory corruption. I have seen objects magically becoming "None" in Python versions with memory corruption problems (Python 2.1.1).
Also, loads of objects can become None when you do a refresh, because of some strange bug in the refresh support that has been there since it got integrated into the core and which nobody seems to understand. But I guess that's not the case here, because that problem would go away when you restart the server.
On Mon, Feb 09, 2004 at 11:04:21AM +0100, Lennart Regebro wrote:
From: "Dieter Maurer" <dieter@handshake.de>
Maybe, we have a memory corruption. I have seen objects magically becoming "None" in Python versions with memory corruption problems (Python 2.1.1).
Also, loads of objects can become None when you do a refresh, because of some strange bug in the refresh support that has been there since it got integrated into the core and which nobody seems to understand.
Ugh, yes, I got bit badly by that one with a product that was on auto-refresh. A restart would *sometimes* fix the problem for a day or a month or five minutes. Maddening. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's NANO DAEMON FUNGUS! (random hero from isometric.spaceninja.com)
Lennart Regebro wrote at 2004-2-9 11:04 +0100:
From: "Dieter Maurer" <dieter@handshake.de>
... objects turned into None ...
Also, loads of objects can become None when you do a refresh, because of some strange bug in the refresh support that has been there since it got integrated into the core and which nobody seems to understand.
I think I understand it. When Python delete a module it lets the objects in the module become None. Refresh works by deleting the product modules from "sys.modules" and then forcing the ZODB caches to be reset when a ZODB connection is opened the next time. This "turning into None" is not unintelligent. Without it, you could use an old and no longer current object without noticing it... -- Dieter
From: "Dieter Maurer" <dieter@handshake.de>
Lennart Regebro wrote at 2004-2-9 11:04 +0100:
From: "Dieter Maurer" <dieter@handshake.de>
... objects turned into None ...
Also, loads of objects can become None when you do a refresh, because of some strange bug in the refresh support that has been there since it got integrated into the core and which nobody seems to understand.
I think I understand it.
When Python delete a module it lets the objects in the module become None.
Refresh works by deleting the product modules from "sys.modules" and then forcing the ZODB caches to be reset when a ZODB connection is opened the next time.
Yes, but these objects are recreated when the module is reloaded. And if the module who import stuff from this module in turn is reloaded, it's imports to stuff in that module will be refreshed to point to the new objects. And this works *most* of the time. :-) I have yet still to figure out exactly when it doesn't.
Lennart Regebro wrote at 2004-2-10 11:08 +0100:
... refresh turns objects to None ... Yes, but these objects are recreated when the module is reloaded. And if the module who import stuff from this module in turn is reloaded, it's imports to stuff in that module will be refreshed to point to the new objects.
And this works *most* of the time. :-) I have yet still to figure out exactly when it doesn't.
It does not work when the module which import stuff from this module is not reloaded in turn. Then the imported stuff remains "None". -- Dieter
On Mon, 9 Feb 2004, Lennart Regebro wrote:
From: "Dieter Maurer" <dieter@handshake.de>
Maybe, we have a memory corruption. I have seen objects magically becoming "None" in Python versions with memory corruption problems (Python 2.1.1).
Also, loads of objects can become None when you do a refresh, because of some strange bug in the refresh support that has been there since it got integrated into the core and which nobody seems to understand.
It's actually a behavior of Python itself. When Zope's Refresh calls Python's reload() builtin, reload() twiddles the old functions and methods in such a way that all old globals are set to None. If you have the misfortune of calling an old function or method, it's likely to fail in the manner Dieter described. It is not memory corruption. It is the intended behavior. Therefore, reload() only works if you can reliably sever all references to functions or methods in the old module. Zapping the ZODB cache accomplishes most of that, but there are still cases that bite people. I think the only way to make Refresh work reliably is to create a special kind of module that's explicitly refreshable. The module would obey some special rules. Fortunately, that's just what Zope 3's persistent modules will do. For now, you just have to be aware that Refresh is designed only for simple products that do not create or use module-level registries. Shane
Thanks again for the reply Dieter, On 6 Feb 2004, at 21:14, Dieter Maurer wrote:
"REQUEST.RESPONSE" is set up in "ZServer.HTTPServer.zhttp_handler.continue_request". It should be impossible that is is "None".
Agreed.
Maybe, we have a memory corruption. I have seen objects magically becoming "None" in Python versions with memory corruption problems (Python 2.1.1).
-- Dieter
Could be memory perhaps, but this is python2.3.3.
Christian Heimes wrote: [...]
And the next one:
Python2.3.3/Zope2.70rc2/Plone2rc5.
Exception Type AttributeError Exception Value 'str' object has no attribute 'RESPONSE'
[...] Module Products.CMFPhoto.Photo, line 510, in clearCache AttributeError: 'str' object has no attribute 'RESPONSE'
The relevant code line is self.REQUEST.RESPONSE.setHeader(). The error occured at object creation.
Something really bad is going on!
Christian
The problem I'm having is that these are all stock Zope products from a Zope2.7.0rc2 release. The traceback is coming from the Zope core. Traceback (innermost last): ... Module Shared.DC.Scripts.Bindings, line 320, in __render_with_namespace__ Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec Module App.special_dtml, line 175, in _exec Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: RESPONSE Module <string>, line 0, in ? AttributeError: 'NoneType' object has no attribute 'setHeader' This also seems different from what Christian is reporting;
Christian Heimes wrote at 2004-2-6 23:01 +0100: And the next one:
Python2.3.3/Zope2.70rc2/Plone2rc5.
Exception Type AttributeError Exception Value 'str' object has no attribute 'RESPONSE'
[...] Module Products.CMFPhoto.Photo, line 510, in clearCache AttributeError: 'str' object has no attribute 'RESPONSE'
The relevant code line is self.REQUEST.RESPONSE.setHeader(). The error occured at object creation.
Something really bad is going on!
So, I'm still baffled by this. Many thanks to all those providing more data points. I *think* this is a 'Zope' thing and not a 'Tone' thing, but I've been wrong in that area before ;) cheers tone. -- Dr Tony McDonald, Asst Director, FMSC. 0191 245 4223 Project Manager, FDTL-4 ePortfolios http://www.eportfolios.ac.uk/
Hi all, You'll have seen my message earlier in the month about the above. Well, we figured it out. To cut a long story short, we had a role called 'SYS' in the folder. It was a real forehead slapping moment, with all the team looking around at each other with the unsaid thought of 'oops, that's *probably* not a good idea'. This was the same day that someone else in the team found out that using 'yield' as a variable is also not a good idea. So, we deleted the role, and Bob's your uncle. Lots of smiles all around. cheers for all the help, Tone. -- Dr Tony McDonald, Asst Director, FMSC. 0191 246 4543 Project Manager, FDTL-4 ePortfolios http://www.eportfolios.ac.uk/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dieter Maurer wrote: ~ > Looks like "RESPONSE" is "None". | | I do not see how this can happen... <aol /> but a CMFPhoto user reported a bug like this to me today. According to his traceback self.REQUEST had now attribute RESPONSE. That's really strange. :( Time 2004/02/05 07:16:58.953 US/Pacific User Name (User Id) admin (admin) Request URL http://www.stewardville.com/photos/createObject Exception Type AttributeError Exception Value RESPONSE Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Products.CMFFormController.FSControllerPythonScript, line 87, in __call__ Module Products.CMFFormController.Script, line 127, in __call__ Module Products.CMFCore.FSPythonScript, line 104, in __call__ Module Shared.DC.Scripts.Bindings, line 306, in __call__ Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec Module Products.CMFCore.FSPythonScript, line 160, in _exec Module None, line 16, in createObject <FSControllerPythonScript at /stewardville/createObject used for /stewardville/photos> Line 16 Module Products.CMFPlone.PloneFolder, line 373, in invokeFactory Module Products.CMFCore.TypesTool, line 709, in constructContent Module Products.CMFCore.TypesTool, line 398, in constructInstance Module Products.CMFPhoto.Photo, line 110, in addPhoto Module Products.CMFPhoto.Photo, line 174, in __init__ Module Products.CMFDefault.Image, line 147, in __init__ Module OFS.Image, line 124, in __init__ Module Products.CMFPhoto.Photo, line 400, in update_data Module Products.CMFPhoto.Photo, line 510, in clearCache AttributeError: RESPONSE Used versions: Zope 2.6.4, Python 2.1.3, CMF 1.4.2, PIL 1.1.4, Plone 2.0-RC3. Christian / Tiran -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAIwAe9aLWrfOU0PgRAsKmAJ9tJiInLW1lCV1X7f8giidCoydKOgCfUP8e ECBEAOJwkDuuTfBJx/xfsSM= =4jZP -----END PGP SIGNATURE-----
Christian Heimes wrote: [...] And the next one: Python2.3.3/Zope2.70rc2/Plone2rc5. Exception Type AttributeError Exception Value 'str' object has no attribute 'RESPONSE' [...] Module Products.CMFPhoto.Photo, line 510, in clearCache AttributeError: 'str' object has no attribute 'RESPONSE' The relevant code line is self.REQUEST.RESPONSE.setHeader(). The error occured at object creation. Something really bad is going on! Christian
Christian Heimes wrote at 2004-2-6 23:01 +0100:
And the next one:
Python2.3.3/Zope2.70rc2/Plone2rc5.
Exception Type AttributeError Exception Value 'str' object has no attribute 'RESPONSE'
[...] Module Products.CMFPhoto.Photo, line 510, in clearCache AttributeError: 'str' object has no attribute 'RESPONSE'
The relevant code line is self.REQUEST.RESPONSE.setHeader(). The error occured at object creation.
Something really bad is going on!
This may indeed be a memory corruption problem where the same object is released/freed twice. A long time ago, I used "purify" to analyse such problems. It may no longer be feasible as Python now uses its own memory management on top of the standard one. It may be possible to compile Python in a way that it checks for badly used memory management functions. -- Dieter
On Fri, 2004-02-06 at 20:01, Christian Heimes wrote:
Christian Heimes wrote: [...]
And the next one:
Python2.3.3/Zope2.70rc2/Plone2rc5.
Exception Type AttributeError Exception Value 'str' object has no attribute 'RESPONSE'
[...] Module Products.CMFPhoto.Photo, line 510, in clearCache AttributeError: 'str' object has no attribute 'RESPONSE'
METOO! I just got this error. I commented out line 510 and the code worked. I was about to uncomment the code again to try and debug it. It happened when I tried to upload a .jpg thru webdav (konqueror webdav support) to a CMFPhotoAlbum (0.4final) inside a plone2rc5 instance (Zope 2.6.4rc2, Python 2.3.3). I'm curious to at least know what kind of string 'self.REQUEST' is :-) Want to coordinate? I'm happy to be the guinnea pig for this bug. -- Leonardo Rochael Almeida <leo@hiper.com.br>
FWIW, this often happens when "self" isn't ultimately wrapped in a RequestContainer (as it always should be when dealing with TTW code or code that depends on REQUEST). The string is likely something like "<Special Object Used To Force Acqusition>", which is the string that represents something when it is declared as "Acquisition.Acquired" in a class definition. The trick is finding out where the thing loses its context. No clue in this case. On Sat, 2004-02-07 at 18:51, Leonardo Rochael Almeida wrote:
On Fri, 2004-02-06 at 20:01, Christian Heimes wrote:
Christian Heimes wrote: [...]
And the next one:
Python2.3.3/Zope2.70rc2/Plone2rc5.
Exception Type AttributeError Exception Value 'str' object has no attribute 'RESPONSE'
[...] Module Products.CMFPhoto.Photo, line 510, in clearCache AttributeError: 'str' object has no attribute 'RESPONSE'
METOO!
I just got this error. I commented out line 510 and the code worked.
I was about to uncomment the code again to try and debug it. It happened when I tried to upload a .jpg thru webdav (konqueror webdav support) to a CMFPhotoAlbum (0.4final) inside a plone2rc5 instance (Zope 2.6.4rc2, Python 2.3.3).
I'm curious to at least know what kind of string 'self.REQUEST' is :-)
Want to coordinate? I'm happy to be the guinnea pig for this bug.
Chris McDonough wrote:
FWIW, this often happens when "self" isn't ultimately wrapped in a RequestContainer (as it always should be when dealing with TTW code or code that depends on REQUEST). The string is likely something like "<Special Object Used To Force Acqusition>", which is the string that represents something when it is declared as "Acquisition.Acquired" in a class definition.
The trick is finding out where the thing loses its context. No clue in this case.
If it's "<Special Object Used To Force Acqusition>" then it's (maybe) partly my fault. type(self.REQUEST) is "<Special Object Used To Force Acqusition>" when the object hasn't a real acquisition context. That's for example when we are still in the __init__() part of object creation. I was pretty shure that upload_data is called in an acquisition context. It seems that it isn't called in a context under *every* circumstances. Chris - was tricked again - ti(r)an
On Sat, 2004-02-07 at 22:47, Christian Heimes wrote:
Chris McDonough wrote:
FWIW, this often happens when "self" isn't ultimately wrapped in a RequestContainer (as it always should be when dealing with TTW code or code that depends on REQUEST). The string is likely something like "<Special Object Used To Force Acqusition>", which is the string that represents something when it is declared as "Acquisition.Acquired" in a class definition.
The trick is finding out where the thing loses its context. No clue in this case.
If it's "<Special Object Used To Force Acqusition>" then it's (maybe) partly my fault.
That's it alright,
type(self.REQUEST) is "<Special Object Used To Force Acqusition>" when the object hasn't a real acquisition context. That's for example when we are still in the __init__() part of object creation.
That's it alright :-)
I was pretty shure that upload_data is called in an acquisition context. It seems that it isn't called in a context under *every* circumstances.
In this case it's being callet by Photo.__init__ -> OFS.Image.__init__ -> Photo.update_data Here's the traceback: Traceback (innermost last): File /opt/zope/sw/Zope-264rc2/lib/python/ZPublisher/Publish.py, line 98, in publish File /opt/zope/sw/Zope-264rc2/lib/python/ZPublisher/mapply.py, line 88, in mapply (Object: PUT) File /opt/zope/sw/Zope-264rc2/lib/python/ZPublisher/Publish.py, line 39, in call_object (Object: PUT) File /opt/zope/sw/Zope-264rc2/lib/python/webdav/NullResource.py, line 108, in PUT (Object: dcp_0996.jpg) File /home/leo/zopes/lra.com.br/Products/CMFPhotoAlbum/PhotoAlbum.py, line 69, in PUT_factory (Object: unisa-congresso-brooklin) File /home/leo/zopes/lra.com.br/Products/CMFCore/PortalFolder.py, line 361, in invokeFactory (Object: unisa-congresso-brooklin) File /home/leo/zopes/lra.com.br/Products/CMFCore/TypesTool.py, line 709, in constructContent (Object: portal_types) File /home/leo/zopes/lra.com.br/Products/CMFCore/TypesTool.py, line 398, in constructInstance (Object: Photo) File /home/leo/zopes/lra.com.br/Products/CMFPhoto/Photo.py, line 110, in addPhoto (Object: unisa-congresso-brooklin) File /home/leo/zopes/lra.com.br/Products/CMFPhoto/Photo.py, line 174, in __init__ (Object: dcp_0996.jpg) File /home/leo/zopes/lra.com.br/Products/CMFDefault/Image.py, line 147, in __init__ (Object: dcp_0996.jpg) File /opt/zope/sw/Zope-264rc2/lib/python/OFS/Image.py, line 124, in __init__ (Object: dcp_0996.jpg) File /home/leo/zopes/lra.com.br/Products/CMFPhoto/Photo.py, line 400, in update_data (Object: dcp_0996.jpg) File /home/leo/zopes/lra.com.br/Products/CMFPhoto/Photo.py, line 510, in clearCache (Object: dcp_0996.jpg) AttributeError: 'str' object has no attribute 'RESPONSE' Cheers, Leo
participants (8)
-
Chris McDonough -
Christian Heimes -
Dieter Maurer -
Lennart Regebro -
Leonardo Rochael Almeida -
Paul Winkler -
Shane Hathaway -
Tony McDonald