Bug 1172

The following errors appear in my xsession log when I run KMail and seem likely to be related:

TQObject::connect: Incompatible sender/receiver arguments
        KMFolderMgr::msgRemoved(KMFolder*,TQ_UINT32) --> KMMsgIndex::slotRemoveMessage(TQ_UINT32)
TQObject::connect: Incompatible sender/receiver arguments
        KMFolderMgr::msgAdded(KMFolder*,TQ_UINT32) --> KMMsgIndex::slotAddMessage(TQ_UINT32)
TQObject::connect: Incompatible sender/receiver arguments
        KMFolderMgr::msgRemoved(KMFolder*,TQ_UINT32) --> KMMsgIndex::slotRemoveMessage(TQ_UINT32)
TQObject::connect: Incompatible sender/receiver arguments
        KMFolderMgr::msgAdded(KMFolder*,TQ_UINT32) --> KMMsgIndex::slotAddMessage(TQ_UINT32)

I use it on imap folders and I can confirm that 3.5.12 and 3.5.13 works well. Older than 3.5.12 I did not use.

(Odpověď na komentář #1)
> The following errors appear in my xsession log when I run KMail and seem likely
> to be related:
> 

These reports are filed as bug 1087 - are also in 3.5.13, so probably not associated with this error.

(In reply to comment #1)
> The following errors appear in my xsession log when I run KMail and seem likely
> to be related:
> 
> TQObject::connect: Incompatible sender/receiver arguments
>         KMFolderMgr::msgRemoved(KMFolder*,TQ_UINT32) -->
> KMMsgIndex::slotRemoveMessage(TQ_UINT32)
> TQObject::connect: Incompatible sender/receiver arguments
>         KMFolderMgr::msgAdded(KMFolder*,TQ_UINT32) -->
> KMMsgIndex::slotAddMessage(TQ_UINT32)
> TQObject::connect: Incompatible sender/receiver arguments
>         KMFolderMgr::msgRemoved(KMFolder*,TQ_UINT32) -->
> KMMsgIndex::slotRemoveMessage(TQ_UINT32)
> TQObject::connect: Incompatible sender/receiver arguments
>         KMFolderMgr::msgAdded(KMFolder*,TQ_UINT32) -->
> KMMsgIndex::slotAddMessage(TQ_UINT32)

Those errors are related to the indexing feature, and were introduced years ago by this commit: http://www.archivum.info/kde-commits@kde.org/2007-03/02805/KDE-kdepim-kmail.html

They are now fixed in GIT hash acecca8, however this commit does not address any issues related to this bug report.

Are there any other disconnected signal/slot errors in xsession_errors related to kmail?

> Are there any other disconnected signal/slot errors in xsession_errors
> related to kmail?

I haven't seen any --- only those generated by amarok (bug report 1088).

With the patch the signal/slot errors no longer appear. Thanks.

I have to wait a few days before I will be able to notice whether those particular errors are related to the expiration deletion failures. Fortunately I do have some mails in some folders that will expire this weekend, thus we won't have to wait long. :-)

Update: The expire bug remains despite applying the recent patch.

Slavek,

In Comment 2, are you saying automated expiration works in 3.5.13? Have you tested in R14?

(Odpověď na komentář #8)
> Slavek,
> 
> In Comment 2, are you saying automated expiration works in 3.5.13? Have you
> tested in R14?

Yes, in 3.5.12 and 3.5.13.1 it works.
R14 unfortunately I do not have installed.

I would like to know what changed. This is an irritating regression. :-(

One thing I would suspect would be any gcc 4.7 changes, as the logic may have been accidentally broken when attempting to eliminate compilation errors.

I'm using KMail on Slackware 13.1, which uses gcc 4.4.4. I have not tried using KMail on a 4.7.x system.

(In reply to comment #12)
> I'm using KMail on Slackware 13.1, which uses gcc 4.4.4. I have not tried using
> KMail on a 4.7.x system.

I understand, however my concern was that the patches that were committed to GIT for the purpose of fixing gcc 4.7 compilation may have broken the underlying logic for all compilers.

Tim

I see only two tdepim commits related to gcc 4.7:

2012-04-27:

6a168ff9
c94de3af

I don't see anything obvious in those patches.

Yes, only this two commits, and both are also a part of v3.5.13.1 where it works.

Strange.  Do you still experience this problem when you create a new TDE profile?

(In reply to comment #16)
> Strange.  Do you still experience this problem when you create a new TDE
> profile?

I just thought of something: when kmail works, does it work on Qt3?  Has anyone tried it and had it work on TQt3?

> I just thought of something: when kmail works, does it work on Qt3?

I never got that far:

http://bugs.pearsoncomputing.net/show_bug.cgi?id=1050

I don't see any error/warning messages in the xsession log or when running kmail in konsole.

I haven't tried with a fresh profile because setting up kmail is a pain.

Aside from a bug that I found where an expiry of zero days is ignored (fixed in GIT hash a4c62fb), expiration seems to work perfectly fine in my tests on R14.  At this point I suspect that your kmailrc file might have invalid key(s), you could look through it to see.

If you want to debug this, uncomment the "#define DEBUG_SCHEDULER" line in kmail/jobscheduler.h and recompile/reinstall kmail.  Then enable debugging of area 5006 with kdebugdialog and watch the spew--if everything works, you will see expiry job messages pop up from time to time as the timed job queue is run.

One thing I did notice is that the expiry job for folder refuses to autorun if the folder is currently open.  I don't know if this is desirable or not, but the code strongly suggests that it was designed to work this way.

I rebuilt tdepim as instructed and enabled 5006 in kdebugdialog.

Not a single "ExpireJob:...." message in the output spew.

That would seem to indicate why the emails are not being deleted automatically. That is, seems the code to do that is not being executed, otherwise I presume I'd see the new "ExpireJob:...." debug messages.

(In reply to comment #20)
> I rebuilt tdepim as instructed and enabled 5006 in kdebugdialog.
> 
> Not a single "ExpireJob:...." message in the output spew.
> 
> That would seem to indicate why the emails are not being deleted automatically.
> That is, seems the code to do that is not being executed, otherwise I presume
> I'd see the new "ExpireJob:...." debug messages.

Did you see any messages indicating the job scheduler was running at all (slotRunNextJob)?  If so, was "isOpened=false" present in any of the debug output?

I still suspect this is a kmailrc issue or similar configuration problem.

Tim

I see no slotRunNextJob or isOpened strings in the output.

I'm using backups to repeatedly test and restore files and mails. After lengthy usability tinkering (no code changes) I had some success with expirations, seeing ExpireJob messages and seeing messages delete. Yet after the repeated tinkering I simply don't know what triggers the automated expirations or what could be corrupt.

I kept checking the backup kmailrc to the current version and although there are nominal differences with each change, I don't know which entries might be the culprit, if at all. The only thing I know is something blocks the expirations checks from occurring until something in my tinkering seems to remove that blockage.

All kmail related files are migrated from 3.5.10. I never had this problem in 3.5.10 but something is different that TDE does not like. I don't know whether my experience is an oddball corner case or will affect other users who migrate a 3.5.10 kmail setup to TDE. If I knew where to focus perhaps we could add some error trap code to ensure nobody experiences this problem.

I don't know how this is supposed to work. From what I have seen, the expirations do not happen automatically whenever kmail is started. The expirations seem to occur only when a mail folder changes?

I went several days with no incoming mail. When I finally received an incoming mail, I then noticed the folders were updated, including the trash. Yet each day until then no folders would update.

I'm now reasonably convinced that expiration updates are performed only when there is any kind of incoming email. Merely starting kmail does not trigger expirations, which to me, seems incorrectly designed.

I don't remember when expirations occurred in 3.5.10. Perhaps the trigger was the same, perhaps not.

I don't believe the behavior is the same as 3.5.10. Seems in 3.5.10 expired emails were removed just by opening kmail. In Trinity expired emails are removed only upon the receipt of an incoming email. I don't believe this is a correct behavior. I believe expired emails should be removed any time kmail is opened. In other words, the trigger for removing expired emails should be the mere opening of kmail.

I'm willing to do some testing but need help as to where to find and move the triggering event in the code.

Another note so this report is not closed prematurely.

Although the behavior seems different from 3.5.10 and expirations only occur now when receiving an incoming mail, I can't say this behavior is repeatable. Mail folders sometimes update and just as often don't. Eventually they do update and expired mails are deleted, but I can't determine the logic of when that happens.

Part of the challenge is I don't receive a high volume of mail to act as a trigger. (I use a webmail address for Trinity related mails.) Regardless, I don't think this bug is resolved.

In KMail I have several IMAP accounts. It seems to me that the removal of expired messages starts in each of the accounts after KMail first comes "into contact" with an appropriate folder - for example, in trash after the first move message into the trash in appropriate account. And since then removing runs with some regularity.

Yes, some regularity --- that was my point. :) The automatic deletions do not seem to always happen.

Today I noticed my trash folder was many days overdue for cleaning, despite having received mails during the week. I have seen trash automatically delete messages but just as often I don't. Possibly no messages in my regular account folders had expired, which means nothing was moved automatically into the trash folder, which means the trash folder does not update.

I just don't recall this behavior at all in 3.5.10. Seems to me that expirations occurred any time I started kmail. At least, every time I looked in folders they were always correctly updated. I don't recall my trash folder ever accumulating mails past my 10 day target. Now that happens often.

Even if that was not the behavior in 3.5.10, that should be the behavior. There should not be a need for an incoming message in a folder to trigger expiration checks. They should happen every time kmail is started. The trigger associated with an incoming message should be used only for those people who keep apps open 24/7. Yet even then there should be a built-in timer to trigger expiration checks.

The only significant change I recall to kmail from 3.5.10 is the indexing scheme. Does indexing play a role in how folders are updated with expirations?

As a number of threading-related problems have been noted and resolved recently (e.g. Amarok, KGet), I wonder if KMail's expiration feature might similarly abuse the threading classes of TQt3.  If true, then the expiration feature would have ceased to function properly when we switched Qt3/TQt3 to use the glib main loop.

I don't know. Makes sense. I don't remember when the transition was made. I would not be able to correlate that period to when I noticed the bug.

I can confirm that automatic deletions still don't always work.

Possibly one way to debug would be to build TQt3 without -glibmainloop and then watch whether deletions function correctly.

There was no difference while I tested TQt3 without glibmainloop. I still have stale mails. The odd thing is occasionally the expired mails do get deleted. I have not been able to determine the connection.

This *might* have been fixed in GIT hashes 56999a2 (qt3) and eeaba43 (tqt3) from Bug 1703.  Can you test?

Thanks!

>Can you test?
Of course. Might need several days for expirations to bubble up.

Can't say for sure long term, but expired mails are gone after rebuilding. The caveat is I have seen the expired mails delete during the past bug period, I don't know why.

I have two mailboxes that have mails to expire in two days. We'll see whether they automatically expire.

Why would the Qt3/TQt3 patches fix the problem when the problem did not exist last year when I filed the report?

The recent TQt3 patches may have fixed a bug that was even older than the initial TQt3 -glibmainloop support.  Time will tell. ;-)

The recent patches have not resolved this problem. I have some mail boxes with mails that should have been automatically deleted but they are still in the box.

I will not say this problem is resolved, but since I started monitoring the dev mail list with kmail, mails have been correctly expiring. I believe this validates my previous observation that expirations occur only with incoming mails (comment 25). I suspect that is why nobody else saw the problem. That is, any reasonably active kmail session would regularly trigger expirations.

Thus I believe the bug still exists, but to test requires a quiet kmail user who does not receive daily mails through kmail. My original report still stands: expirations should always occur regardless of any incoming mail.

For regular kmail users, to test this bug likely requires a separate user account with one email address. Set the trash bin expiration to 1 or 2 days, send a few test mails, send the emails to the trash bin, and then monitor the expirations.