nupas status
Gabriel Diaz Lopez de la Llave
This week i've been debugging trying to identify some reference
problems. Also, while debugging, i started to hit some other problems
related to the nupas cache i need to identify.
I tried to build a reproducible test case on which nupas always fails
with no luck, but its completion is near i think.
I'm using now various records of the whole 9p activity to try to
identify the complete crash-path, but this is quite a pain. I've been
unable to reproduce the crash using local mailboxes.
Also i discovered some sync problems when opening the same mailbox
more than once, which makes nupas to crash when one message is deleted
in one instance of a mailbox and the client tries to read the same
message using other instance.
More debug for the coming week, i hope to fix these crashes soon.
thanks
gabi
quanstro
or was the same mailbox opened twice by the same instance
of fs?
as noted privately, i am testing a few bug fixes relating to the
former case, but they do not result in crashes, just delayed
recognition of deleted messages.
- erik
Gabriel Diaz Lopez de la Llave
Only one upas/fs was running, with instance i meant each open of the
same mailbox. Seems that the other mailboxes are not updated after a
deletion, and when you try to read a message already deleted, nupas
crashed.
What i did was:
echo 'open mbox one' > /mail/fs/ctl
echo 'open mbox two' > /mail/fs/ctl
echo 'open mbox three'>/mail/fs/ctl
The execute acme/Mail opening the three mailboxes
The delete one from one acme/Mail and try to read the same message
with other acme/Mail.
With the latest changes you sent me, nupas is not crashing, i can't
reproduce it now. As a side note, seems that acme/Mail is not aware of
the update (although nupas/fs is correctly updated) . After a deletion
acme/Mail can still see the headers (cached within Mail i guess, i
didn't read Mail sources, as /mail/fs/mbox/XX/ does not exists).
As a note, all this crashes are found during the debugging of the
checkmboxrefs() issue.
thanks
gabi