Bug#246259: wmmail: foolishly keeps thinking there's mail

[Ian Zimmerman]

Package: wmmail
Version: 0.64-11.1
Severity: normal

wmmail quite frequently (about once a day) gets "stuck" displaying the full-mailbox
image. After killing it the new incarnation is normal (displays empty-mailbox,
no sound). I don't know what's up with that; I guess running it under strace is an
option, though I am afraid it will consume ungodly amounts of disk.

Here are relevant parts of GNUstep/Defaults/WMMail

{
DisableBeep = Yes;
DoubleClickTime = 250;
DisplayMessageCount = None;
DisplayColor = "#FFFFFF";
DisplayFont = "-*-helvetica-medium-r-*-*-10-*-*-*-*-*-*-*";
DisplayLocation = (0, 10);
ExecuteOnNew = "play /usr/share/GNUstep/Apps/WMMail.app/Sounds/doorbell.au";
Animations = {
Empty = {
Delay = 10;
Frames = (
"/usr/lib/GNUstep/Apps/WMMail.app/Anims/asmail/asmail-no.xpm"
);
};
Old = {
Delay = 10;
Frames = (
"/usr/lib/GNUstep/Apps/WMMail.app/Anims/asmail/asmail-old.xpm"
);
};
New = {
Delay = 10;
Frames = (
"/usr/lib/GNUstep/Apps/WMMail.app/Anims/asmail/asmail-new.xpm"
);
};
};
Mailboxes = (
{
Name = "Default";
Type = mbox;
UpdateInterval = 30;
Options = {
Path = "/var/mail/foobar";
};
}
);
}


-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.24-3custom2+lowlatency
Locale: LANG=C, LC_CTYPE=C

Versions of packages wmmail depends on:
ii base-files 3.0.14 Debian base system miscellaneous f
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an
ii xlibs 4.3.0-7 X Window System client libraries m

-- no debconf information

[Chris Waters]

Post by Ian Zimmerman
wmmail quite frequently (about once a day) gets "stuck" displaying
the full-mailbox image.

Hmm, I've also seen that behavior, but in my case, it's extremely rare.
So I don't have a lot to go on.

The next time it happens, can you try sending SIGUSR1 instead of
killing? My suspicion is that it thinks it's updated the display when
it hasn't, and if so, SIGUSR1 should force it to update. Let me know
what happens. I can't promise it'll help me fix the problem, but it
might provide a starting point.

thanks

[Ian Zimmerman]

Ian> wmmail quite frequently (about once a day) gets "stuck" displaying
Ian> the full-mailbox image.

Chris> The next time it happens, can you try sending SIGUSR1 instead of
Chris> killing? My suspicion is that it thinks it's updated the display
Chris> when it hasn't, and if so, SIGUSR1 should force it to update.

I'm sorry to report that SIGUSR1 does _not_ restore sanity ...

[Chris Waters]

Post by Ian Zimmerman
Chris> The next time it happens, can you try sending SIGUSR1 instead of
Chris> killing? My suspicion is that it thinks it's updated the display
Chris> when it hasn't, and if so, SIGUSR1 should force it to update.
I'm sorry to report that SIGUSR1 does _not_ restore sanity ...

Oops, I misfiled this response and just now found it.

Well, darn. Still, in retrospect, I should have expected that result.

I've temporarily edited my configuration to look much like yours.
It's been running since last night. If I can't reproduce the problem
within a day or so, I'll provide you with a debug build to try.

In the mean time, can I get you to try one more thing? When it stops
updating, can you hide the window somehow and then restore it? That
should let us know if the repaint code is still running. (I.e. is the
program completely locked up, or is it just in a confused state?)

thanks

[Ian Zimmerman]

Chris> In the mean time, can I get you to try one more thing? When it
Chris> stops updating, can you hide the window somehow and then restore
Chris> it? That should let us know if the repaint code is still
Chris> running. (I.e. is the program completely locked up, or is it
Chris> just in a confused state?)

Hello. Since we last connected, I changed my setup at home to split
into multiple mailboxes - and the bug has disappeared. So I'd suspect
it has to do with many messages being delivered to a single mailbox
in a rapid sequence.

Hmm. I wonder if the check wmmail does on the mailbox is atomic? If
not, does it do any form of locking? Otherwise a mail could be
delivered in the middle of its check, potentially confusing it.

By now I have seen it at work, too, and I am pretty sure it _does_
repaint normally when obscured and re-exposed.

[Chris Waters]

Post by Ian Zimmerman
Hello. Since we last connected, I changed my setup at home to split
into multiple mailboxes - and the bug has disappeared.

Does this mean that you can no longer reproduce it (semi-)
consistently? You mentioned seeing the same behavior at work? Can
you reproduce the behavior there?

Post by Ian Zimmerman
Hmm. I wonder if the check wmmail does on the mailbox is atomic? If
not, does it do any form of locking? Otherwise a mail could be
delivered in the middle of its check, potentially confusing it.

Not atomic (unless you use CheckTimeStampOnly), no locking, and it
messes about with atime/mtime as well. All examples of dubious
behavior, now that I look closely. On the other hand, it seems like
any confusion that occurs should only last till the next update,
whereas what you're describing sounds like more of a permanent thing.
On the gripping hand, it's possible (even likely) that the confusion
might trigger another bug.

I've just moved, and I'm kind of distracted by unpacking and such
right now, but I'll definitely take a closer look as soon as I can.
I've already uncovered a few potential trouble-spots in the code, so I
might be able to fix this without further help. Otherwise, I'll get
back to you with requests for more information fairly soon.

cheers, and thanks for following up