GNU bug report logs - #29220
26.0.90; eieio-persistent-read fail to restore saved object.

Previous Next

Full log

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#29220: 26.0.90;
 eieio-persistent-read fail to restore saved object.
Date: Fri, 17 Nov 2017 20:39:44 -0800

Noam Postavsky <npostavs <at> users.sourceforge.net> writes:

> Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
>
>> When I set a breakpoint in eieio-persistent-read, the object being seems
>> correct.  If I evaluate (pcache-get ret 'foo) in edebug, I get 44, as
>> expected.  But somehow the object which gets returned from
>> (pcache-repository :object-name #1="pcache-test/tmp2") doesn't have
>> anything in its hash table.
>
> Okay, I found where the problem is, it's failing pcache-validate-repo
> (what's the idea behind throwing an error which is caught and ignored
> anyway?):
>
>     (cl-defmethod make-instance ((cache (subclass pcache-repository)) &rest args)
>       ...
>                  (condition-case nil
>                      (let* ((obj (eieio-persistent-read path 'pcache-repository)))
>                        (and (or (pcache-validate-repo obj)
>                                 (error "wrong version")) ...
>                    (error nil)))

(Are you guys looking at a different version of the pcache repo? The one
on Github uses `constructor', not `make-instance'.)

> Specifically, this part:
>
>     (defun pcache-validate-repo (cache)
>        ...
>        (cl-every
>         (lambda (entry)
>           (and (object-of-class-p entry (slot-value cache 'entry-cls))
>                ...
>         (pcache-hash-table-values (slot-value cache 'entries)))))
>
> I can't really tell what this function is supposed to be checking.

The call to `eieio-persistent-read' does basic slot value validation,
but this function is additionally checking that all of the entries in
the hash table are of the proper class, that specified in the
`entry-cls' slot.

But I still think the problem isn't in reading, it's in writing: the
entries in the hash table are being written incorrectly, and so this
validation step is exploding.

I sure don't know why setting `print-circle' to t would have solved it,
though...

Eric

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.