Re: following thunderbird upgrade to 102, it takes over 1h of 100% CPU to start
On 28/08/2022 18.25, Eyal Lebedinsky wrote:
f36, just updated and received
thunderbird-librnp-rnp-102.2.0-1.fc36.x86_64
from thunderbird-91.12.0-1.fc36.x86_64
tb brings up the expected display but no input is accepted. The process is shown as
running with 100% CPU
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
72149 eyal 20 0 4075036 772700 223612 R 100.3 2.4 5:26.57 thunderbird
It will not refresh(*) the panel and will start responding after about 1h.
[later] I see the panel was refreshed after 50m
but input was still not accepted and the display will not refresh. It resolved after
70m.
After this is seems to be OK, I can read mail etc.
To be sure, I made a copy of the profile where I deleted all the .msf files and observed
the same thing.
I tried this a few times.
It is not just a one-off post-upgrade process. After it recovers and works, if I shut tb
down and launch it
then it repeats the problem.
There are not too many emails here, maybe a few tens of thousand totaling just over 1GB
(a few mailing lists).
My main mail client is on another machine, still running tb 91, and not showing this
problem.
Searching the 'net I did not find a relevant report, where should I look?
BTW, after reading the release notes, seeing the structural changes, I wonder if it is at
all possible
to downgrade to v91?
TIA
(*) "not refreshed" means the panel is not painted after minimize/restore,
showing only a border.
A progress update.
After trying a few solutions (unsuccessfully) I compared an empty profile (working,
created as a test)
to the bad one (hanging) and started moving some control files (file in the root of the
profile) across.
The last thing I did was replace the calendar-data with the one from the empty profile and
this solved
the problem. I was not using the calendar for a few years so completely forgot it is
there. It had
drwxr-xr-x 2 eyal eyal 4096 Sep 18 2021 backup
-rw-r--r-- 1 eyal eyal 2359296 Jan 27 2020 cache.sqlite
-rw-r--r-- 1 eyal eyal 524288 May 30 2020 deleted.sqlite
-rw-r--r-- 1 eyal eyal 66256896 Jul 7 10:56 local.sqlite
Notice the largish (66MB) database. It is now (copied from the empty profile)
-rwx------ 1 eyal eyal 819200 Aug 29 09:33 local.sqlite
I wonder if it is only the cache file that was the cause or the whole directory.
[later] No, copying in a fresh cache file did not help, I needed to copy in a fresh
local.sqlite
As I see it, there is an issue with the upgrade process where the (v91) calendar is
somehow incompatible
with the new version. I can understand a once-off long conversion of the database but not
a permanent
(every startup) process. Luckily I did not need to keep the calendar data.
BTW, I do not know if the calendar-data/backup is something I created or tb created during
an update,
but the last file there is named
local.v22.sqlite
with a date matching the update to v91. There is no backup file from the recent v102
update.
Next I need to update my main mail machine which has much more data, and I am still
hesitant...
--
Eyal Lebedinsky (fedora(a)eyal.emu.id.au)