DSM

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
  • bad ZCatalog behavior

    8 answers - 2095 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    Hi there,
    There seems to be a problem with my ZCatalog, and it seems to be getting worse
    as time goes by. When my CatalogPathAware objects unindex themselves,
    sometimes I get an attribute error like:
    AttributeError: 'str' object has no attribute 'append'
    Traceback (innermost last):
    Module ZPublisher.Publish, line 101, in publish
    Module ZPublisher.mapply, line 88, in mapply
    Module ZPublisher.Publish, line 39, in call_object
    Module , line 104, in __call__
    Module Shared.DC.Scripts.Bindings, line 306, in __call__
    Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec
    Module , line 160, in _exec
    Module None, line 33, in tab_status_approve
    - <FSPythonScript
    at / used
    for />
    - Line 33
    Module Products.Silva.Versioning, line 125, in approve_version
    Module Products.Silva.Versioning, line 512, in _update_publication_status
    Module , line 334, in _unindex_version
    Module Products.Silva.Version, line 191, in unindex_object
    Module Products.ZCatalog.ZCatalog, line 558, in uncatalog_object
    Module Products.ZCatalog.Catalog, line 411, in
    Module , line 181, in unindex_object
    Module Products.ZCTextIIndex, line 68, in unindex_doc
    Module Products.ZCTextIndex.BaseIndex, line 176, in unindex_doc
    Module Products.ZCTextIndex.BaseIndex, line 303, in _del_wordinfo
    Module ZDB.Connection, line 562, in setstate
    Module ZDB.Connection, line 601, in _set_ghost_state
    AttributeError: 'str' object has no attribute 'append'
    In the logfile, the last line of code is shown in the traceback:
    File "/", line 601, in
    _set_ghost_state
    state = unpickler.load()
    Perhaps this is a ZE issue. I'm using Zope-2.7.2-0 with ZE Both the zeo
    server and the client are on the same box. The zeo logfile reports no errors
    when this occurs.
    Any ideas why this may be happening?
    Zope maillist - Zope (AT) zope (DOT) org
    ** No cross posts or HTML encoding! **
    (Related lists -
    )
  • No.1 | | 3428 bytes | |

    follow-up from my post earlier today:

    I ran fsrecover.py on a copy of my Data.fs. It found no errors, but then when
    it attempted to pack the file, it raised an unpickleable error, with this
    traceback:

    Traceback (most recent call last):
    File "fsrecover.py", line 374, in ?
    main()
    File "fsrecover.py", line 243, in main
    recover(inp, outp, verbose, partial, force, pack)
    File "fsrecover.py", line 369, in recover
    ofs.pack(pack, referencesf)
    File "/", line 1582,
    in pack
    opos = p.pack()
    File "/", line 700, in
    pack
    self.gc.findReachable()
    File "/", line 456, in
    findReachable
    self.findReachableAtPacktime([z64])
    File "/", line 531, in
    findReachableAtPacktime
    todo.extend(self.findrefs(pos))
    File "/", line 604, in
    findrefs
    return referencesf(self._file.read(dh.plen))
    File "/", line 38, in
    referencesf
    raise ValueError, 'Error unpickling, %s' % p
    ValueError: Error unpickling, and the rest is presumably the pickle.

    I receive this same error when trying to pack using the ZMI. Any idea what's
    going on?

    Thanks for the help,
    Andy

    Monday 08 August 2005 08:15 am, Andy Altepeter wrote:
    Hi there,

    There seems to be a problem with my ZCatalog, and it seems to be getting
    worse as time goes by. When my CatalogPathAware objects unindex
    themselves, sometimes I get an attribute error like:

    AttributeError: 'str' object has no attribute 'append'

    Traceback (innermost last):
    Module ZPublisher.Publish, line 101, in publish
    Module ZPublisher.mapply, line 88, in mapply
    Module ZPublisher.Publish, line 39, in call_object
    Module , line 104, in __call__
    Module Shared.DC.Scripts.Bindings, line 306, in __call__
    Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec
    Module , line 160, in _exec
    Module None, line 33, in tab_status_approve
    - <FSPythonScript
    at / used
    for />
    - Line 33
    Module Products.Silva.Versioning, line 125, in approve_version
    Module Products.Silva.Versioning, line 512, in _update_publication_status
    Module , line 334, in _unindex_version
    Module Products.Silva.Version, line 191, in unindex_object
    Module Products.ZCatalog.ZCatalog, line 558, in uncatalog_object
    Module Products.ZCatalog.Catalog, line 411, in
    Module , line 181, in unindex_object
    Module Products.ZCTextIIndex, line 68, in unindex_doc
    Module Products.ZCTextIndex.BaseIndex, line 176, in unindex_doc
    Module Products.ZCTextIndex.BaseIndex, line 303, in _del_wordinfo
    Module ZDB.Connection, line 562, in setstate
    Module ZDB.Connection, line 601, in _set_ghost_state
    AttributeError: 'str' object has no attribute 'append'

    In the logfile, the last line of code is shown in the traceback:
    File "/", line 601, in
    _set_ghost_state
    state = unpickler.load()

    Perhaps this is a ZE issue. I'm using Zope-2.7.2-0 with ZE Both the
    zeo server and the client are on the same box. The zeo logfile reports no
    errors when this occurs.

    Any ideas why this may be happening?

    Zope maillist - Zope (AT) zope (DOT) org

    ** No cross posts or HTML encoding! **
    (Related lists -
    )

    Zope maillist - Zope (AT) zope (DOT) org

    ** No cross posts or HTML encoding! **
    (Related lists -

    )
  • No.2 | | 1522 bytes | |

    [Andy Altepeter]
    I ran fsrecover.py on a copy of my Data.fs. It found no errors, but then when
    it attempted to pack the file, it raised an unpickleable error, with this
    traceback:

    File "/", line 38, in
    referencesf
    raise ValueError, 'Error unpickling, %s' % p
    ValueError: Error unpickling, and the rest is presumably the pickle.

    I receive this same error when trying to pack using the ZMI. Any idea what's
    going on?

    It suggests data corruption in your Data.fs file (assuming you're
    using FileStorage). Please read this for background info:

    Because fsrecover.py completed without error, best guess is that
    fstest.py (described in the link above) would also complete without
    error. However, neither of those can detect "higher-level" corruption
    inside serialized object state (see the link for more words). Running
    fsrefs.py (see the link again) can identify most such corruption. So
    run it and see what it says. There is no wholly safe and automatic
    way to recover from frsrefs.py-level corruption (short of reverting to
    a good backup), so don't expect this to go easily.

    Note that better versions of these tools exist in more recent versions
    of ZDB (IIRC, you said you were running Zope-2.7.2, which corresponds
    to ZDB 3.2.3 -- ZDB 3.2.9 is the current production 3.2 release).

    Zope maillist - Zope (AT) zope (DOT) org

    ** No cross posts or HTML encoding! **
    (Related lists -

    )
  • No.3 | | 2420 bytes | |

    Hi Tim,

    Thank you for your response. fsrefs.py raised the same error I reported
    earlier about unpickling. I ended up:
    1) Creating a new instance_home using zope-2.5.0-final
    2) using zopectl debug connected to the bad database, I exported all my
    objects. For folders that couldn't be exported, I started 'drilling down'
    until I found the object that was causing problems. There were about 5 such
    objects in my database.
    - Some objects (folderish) could be exported, but then would raise a PSKey
    error upon import, so I drilled down in those folders as well.
    3) I imported each .zexp into the new database.

    This process was time consuming, but it appears to have recreated the ZDB in
    a sane state. I think it's time to look into using repozo for backups ;-)

    Andy

    Monday 08 August 2005 05:45 pm, Tim Peters wrote:
    [Andy Altepeter]

    I ran fsrecover.py on a copy of my Data.fs. It found no errors, but then
    when it attempted to pack the file, it raised an unpickleable error, with
    this traceback:

    File "/", line
    38, in referencesf
    raise ValueError, 'Error unpickling, %s' % p
    ValueError: Error unpickling, and the rest is presumably the pickle.

    I receive this same error when trying to pack using the ZMI. Any idea
    what's going on?

    It suggests data corruption in your Data.fs file (assuming you're
    using FileStorage). Please read this for background info:

    Because fsrecover.py completed without error, best guess is that
    fstest.py (described in the link above) would also complete without
    error. However, neither of those can detect "higher-level" corruption
    inside serialized object state (see the link for more words). Running
    fsrefs.py (see the link again) can identify most such corruption. So
    run it and see what it says. There is no wholly safe and automatic
    way to recover from frsrefs.py-level corruption (short of reverting to
    a good backup), so don't expect this to go easily.

    Note that better versions of these tools exist in more recent versions
    of ZDB (IIRC, you said you were running Zope-2.7.2, which corresponds
    to ZDB 3.2.3 -- ZDB 3.2.9 is the current production 3.2 release).

    Zope maillist - Zope (AT) zope (DOT) org

    ** No cross posts or HTML encoding! **
    (Related lists -

    )
  • No.4 | | 503 bytes | |

    Andy Altepeter wrote at 2005-8-8 08:15 -0500:
    >There seems to be a problem with my ZCatalog, and it seems to be getting worse
    >as time goes by.


    Module ZDB.Connection, line 562, in setstate
    Module ZDB.Connection, line 601, in _set_ghost_state
    >AttributeError: 'str' object has no attribute 'append'


    In fact, this looks like a broken pickle in your ZDB storage (and
    not like a ZCatalog problem).
  • No.5 | | 811 bytes | |

    David Pratt wrote at 2005-8-8 11:11 -0300:
    >I just began receiving this error this morning in one of my event logs
    >on start up. It looks serious.
    >
    >2005-08-08T08:49:26 WARNING ZDB.FileStorage Failed to load database
    >index: exceptions.AttributeError: type object 'BTrees._fsBTree.fsBTree'
    >has no attribute '__basicnew__'
    >
    >Can someone advise a course of action and what may have happened to
    >generate such an error. I use CMFBTreeFolders extensively in CMF. Many
    >thanks.


    Mysterious:

    "BTrees._fsBTree.fsBTree" should have a '__basicnew__'
    attribute (like all 'ExtensionClass'es).

    Try to import "fsBTree" in an interactive Python interpreter
    and check it.
  • No.6 | | 814 bytes | |

    Wednesday 10 August 2005 04:32 pm, Dieter Maurer wrote:
    Andy Altepeter wrote at 2005-8-8 08:15 -0500:
    >There seems to be a problem with my ZCatalog, and it seems to be getting

    worse as time goes by.

    Module ZDB.Connection, line 562, in setstate
    Module ZDB.Connection, line 601, in _set_ghost_state
    >AttributeError: 'str' object has no attribute 'append'
    >

    In fact, this looks like a broken pickle in your ZDB storage (and
    not like a ZCatalog problem).

    I think I've fixed this issue, but for future reference, is there any way to
    remove a broken pickle?

    Zope maillist - Zope (AT) zope (DOT) org

    ** No cross posts or HTML encoding! **
    (Related lists -

    )
  • No.7 | | 445 bytes | |

    Andy Altepeter wrote at 2005-8-11 07:22 -0500:

    >In fact, this looks like a broken pickle in your ZDB storage (and
    >not like a ZCatalog problem).
    >
    >I think I've fixed this issue, but for future reference, is there any way to
    >remove a broken pickle?


    No, because there should be no broken pickle in the first place
    and because the problem did not yet occured often enough
  • No.8 | | 1539 bytes | |

    David Pratt wrote at 2005-8-10 22:07 -0300:
    >Hi Dieter. It is rather strange for sure. The warning has appeared
    >over the past couple of days. First day I removed what I thought might
    >be a bad CMFBTree folder since it was last thing I remember working
    >with from previous night to do with BTrees. Then it appeared again -
    >first restart of the day - it never appeared again that day even after
    >a number of restarts. Received the error again this morning - first
    >restart of day. This time cleared the Data.fs.index and restarted.
    >Again it did not appear again all day after a number of restarts. It
    >almost makes me wonder if it is somehow related to automated backup
    >since it appears consistently on the first restart of the day. Can this
    >make any sense?


    No, it does not
    But nevertheless, you see what you see?

    "__basicnew__" is a class method. It must be there independent
    on the concrete object.

    If it were not there, then whether or not you see the error
    may depend on whether or not the index file is present (you
    should not see it when there is no index file; you may, if there is).

    But, it should be there. If not, then the shared object
    "BTrees/_fsBTree.{so,pyd}" must have been badly executed
    (maybe because it is corrupt) -- but it would be surprising
    that this shows up in such a harmless way (one would instead
    expect a memory violation or bad opcode or something really nasty).

Re: bad ZCatalog behavior


max 4000 letters.
Your nickname that display:
In order to stop the spam: 5 + 4 =
QUESTION ON "DSM"

EMSDN.COM