Re: finally caught an error on crash

[Jack <ostroffjh users sourceforge net>]

Caught another crash with all my changes in g_debug made (prior to  
adding __line__) but I don't think it helps enough.

(balsa:6887): mbox-mbox-DEBUG: 13:28:27.345:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 27 of 32.
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.345:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 28 of 32.
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.345:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 29 of 32.
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.345:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 30 of 32.
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.345:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 31 of 32.
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.345:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 32 of 32.
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.431: libbalsa_mailbox_mbox_sync  
Inbox set size from tell 627475
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.486:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 21 of 32.
(balsa:6887): mailbox-DEBUG: 13:28:27.486: libbalsa_lock_mailbox: mbox  
Inbox
(balsa:6887): mailbox-DEBUG: 13:28:27.486: libbalsa_unlock_mailbox:  
mbox Inbox
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.486:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 21 of 31.
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.486:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 22 of 31.
(balsa:6887): mailbox-DEBUG: 13:28:27.487: libbalsa_lock_mailbox: mbox  
Inbox
(balsa:6887): mailbox-DEBUG: 13:28:27.487: libbalsa_unlock_mailbox:  
mbox Inbox
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.487:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 22 of 30.
(balsa:6887): mailbox-DEBUG: 13:28:27.487: libbalsa_lock_mailbox: mbox  
Inbox
(balsa:6887): mailbox-DEBUG: 13:28:27.487: libbalsa_unlock_mailbox:  
mbox Inbox
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.487:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 22 of 29.
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.487:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 23 of 29.
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.487:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 24 of 29.
(balsa:6887): mailbox-DEBUG: 13:28:27.487: libbalsa_lock_mailbox: mbox  
Inbox
(balsa:6887): mailbox-DEBUG: 13:28:27.487: libbalsa_unlock_mailbox:  
mbox Inbox
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.487:  
libbalsa_mailbox_mbox_sync: Inbox: msgno 24 of 28.
(balsa:6887): mailbox-DEBUG: 13:28:27.487: libbalsa_lock_mailbox: mbox  
Inbox
(balsa:6887): mailbox-DEBUG: 13:28:27.487: libbalsa_unlock_mailbox:  
mbox Inbox
(balsa:6887): mailbox-DEBUG: 13:28:27.487: libbalsa_lock_mailbox: mbox  
Inbox
(balsa:6887): mailbox-DEBUG: 13:28:27.487: libbalsa_unlock_mailbox:  
mbox Inbox
(balsa:6887): mbox-mbox-DEBUG: 13:28:27.487:  
libbalsa_mailbox_mbox_get_message_stream: Inbox: msgno 31 of 28.
**
mbox-mbox:ERROR:../balsa-git/libbalsa/mailbox_mbox.c:252:message_info_from_msgno:  
assertion failed: (msgno > 0 && msgno <= mbox->msgno_2_msg_info->len)
Bail out!  
mbox-mbox:ERROR:../balsa-git/libbalsa/mailbox_mbox.c:252:message_info_from_msgno:  
assertion failed: (msgno > 0 && msgno <= mbox->msgno_2_msg_info->len)

I'll try to rig up always running under a debugger - although I'm not  
convinced it will actually help if that 31 is being cached or not  
updated after expunging the deleted messages.  (I'm actually making the  
assumption that the expunge completes successfully, and then the crash  
happens when displaying the "current" message.  Thinking aloud, I also  
wonder if the issue is that I have selected a deleted message when  
hitting "Expunge" so after the expunge, it needs to select/display the  
"next" remaining message after the one which had previously been  
selected.

Jack

On 2020.05.05 16:01, Albrecht Dreß wrote:
> Am 04.05.20 23:01 schrieb(en) Jack via balsa-list:
> > This continues to happen at a low, but still annoying frequency.   
> > The line number in the error is now 247, having been 249 for a  
> > while, presumably just due to other edits to that file.  As I can  
> > remember, it happens after either deleting message(s) from the  
> > inbox, and/or moving message(s) to different mailboxes, in case that  
> > points to any possibilities.
>
> Hmmm, the error message (failed assertion msgno <=  
> mbox->msgno_2_msg_info->len) “smells” like a corrupted GPtrArray;  
> maybe caused by a race between two threads, when messages are moved  
> and/or deleted.  I'm not really familiar with the mailbox code  
> (Peter? Pawel? Are you?), so this is a wild guess, though.  The  
> failing function seems to be message_info_from_msgno() which is  
> called in several places; do you have a backtrace from a crash?
>
> > Given the recent changes (in the cleanup-logging branch) I'm  
> > wondering if I might just for my own use add some additional debug  
> > statements, either in the function where the g-assert fails, or else  
> > before the calls to that function.
>
> As running in gdb is not always feasible, this may actually be  
> helpful.  Just add g_debug() statements…
>
> > Any quick pointers (or even just a pointer to an example line or  
> > two) would be helpful, and also advice on which debug domain to use  
> > (or even to set for current testing) or how  to go about adding a  
> > new domain.
>
> If you use the new branch, the log domain is set to (line 50) to
>
> #define G_LOG_DOMAIN "mbox-mbox"
>
> so running balsa by calling
>
> G_MESSAGES_DEBUG=mbox-mbox /path/to/balsa
>
> would print /only/ messages from this domain.
>
> It might also be helpful (given that my assumption of a race  
> condition is true) to add debug messages to libbalsa/mailbox.c,  
> namely in libbalsa_lock_mailbox() and libbalsa_unlock_mailbox() (and  
> probably more), like
>
> g_debug("%s: mbox %s", __func__, libbalsa_mailbox_get_name(mailbox));
>
> That file didn't have its own log domain – which is bad, I just  
> pushed a tiny change to the branch setting it to
>
> #define G_LOG_DOMAIN "mailbox"
>
> The above call should now read
>
> G_MESSAGES_DEBUG="mailbox mbox-mbox" /path/to/balsa
>
> Finding the source of a race (which, again, is just a guess) is  
> always /very/ difficult, and adding debug messages may actually  
> change the internal timing of the application, effectively hiding the  
> bug…
>
> Hope this helps,
> Albrecht.