[Users] Claws 3.9.2 - two _really_ annoying issues...

[Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)]

Hello Kardan,

On Sat, 10 Aug 2013 14:30:13 +0200
kardan <kardan at riseup.net> wrote:

> > If the "Receive" operation I start manually last longer than this
> > account retrieve interval, and that this account is configured for
> > automatic retrieval, I end up with _two_ retrieve operations at the
> > same time. I can see by the "progress counters" at the bottom right
> > of the Claws window alternating their counts of messages, for example:
> > 10/46 then 30/46 then 10/46 again, and so on.
> > When that happens, I kill Claws to avoid more mess...
> I use IMAP also with sub-DSL speed (fortunately not as slow as GPRS)
> and increased the check interval lately. 15 min works fine for me as
> claws is less busy now.

Well, my last painful POP3 session lasted 4hrs and 30 minutes. I had
received 20MB of emails I fetched using that GPRS link... So, that's
something that may become visible with these unusual conditions.
 
> > This "Send" action results in all the emails received so far
> > for the secondary account (POP still in progress) to be placed in the
> > folder associated with the main account (the one used for the Send).
> This sounds like an ugly bug. Please consider to file a report in [1]. I
> will test if this is the same for IMAP and append if so.
Hmmm.... I _hate_ web interfaces, much more than this bug... which is why
I reported it by mail...So, I'll first try to see if I can find some hints,
and regarding what you posted below, I think you have helped me a lot ;)

> My impression: The session pointer for the receive task is overwritten
> by the send task. As you see below pop3_session_new does not check if
> there are running sessions, nor is the session stored account specific.
That sounds very much possible !
 
> inc.c:512:      session->session = pop3_session_new(account);
> static IncSession *inc_session_new(PrefsAccount *account)
> {
>         IncSession *session;
>         cm_return_val_if_fail(account != NULL, NULL);
>         if (account->protocol != A_POP3)
>                 return NULL;
>         if (!account->recv_server || !account->userid)
>                 return NULL;
> 
>         session = g_new0(IncSession, 1);
>         session->session = pop3_session_new(account);
>         session->session->data = session;
>         POP3_SESSION(session->session)->drop_message = inc_drop_message;
>         session_set_recv_message_notify(session->session,
>                                         inc_recv_message, session);
>         session_set_recv_data_progressive_notify(session->session,
>                                                  inc_recv_data_progressive,
>                                                  session);
>         session_set_recv_data_notify(session->session,
>                                      inc_recv_data_finished, session);
>         return session;
> }
> 
> pop.c:516:Session *pop3_session_new(PrefsAccount *account)
> Session *pop3_session_new(PrefsAccount *account)
> { 
>         Pop3Session *session;
>         cm_return_val_if_fail(account != NULL, NULL);
>         session = g_new0(Pop3Session, 1);
>         session_init(SESSION(session), account, FALSE);
>         SESSION(session)->type = SESSION_POP3;
>         SESSION(session)->recv_msg = pop3_session_recv_msg;
>         SESSION(session)->recv_data_finished =
>         pop3_session_recv_data_finished;
>         SESSION(session)->send_data_finished = NULL;
>         SESSION(session)->destroy = pop3_session_destroy;
>         session->state = POP3_READY;
>         session->ac_prefs = account;
>         session->pop_before_smtp = FALSE;
>         pop3_get_uidl_table(account, session);
>         session->current_time = time(NULL);
>         session->error_val = PS_SUCCESS;
>         session->error_msg = NULL;
>         return SESSION(session);
> }
> Please anyone tell me if I am wrong.
I'll try to add some debug code to see if sometimes a pointer is
"overwritten"... 
 
> > Hope this will inspire someone... and I'm ready (and willing) to try
> > any patch you may cook ;)
> Thanks for reporting this. I rather not write a patch as I don't want
> to be the one who is responsible to mix up your mails any further. :)
Well, I'm ready to accept testing, so if you have more ideas, feel free to
send them. I've some days off so I may try to cook up something, at least
to try to validate your ideas !

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20130810/6a3fccfb/attachment.sig>