kmail dead in water, using tbird I hope

[Gene Heskett]

I've had several hard lockups over the last day, possibly related to a 
tickless kernel2.6.24.1 I could keep running long enough to recompile it 
with the usual kilohertz tick, so ATM I'm on one of the older 2.6.23 
kernels from the F8 repo's, and kde is 3.5.9

Anyway, kmail (and kontact but I don't use it) is now doing a nearly 
instant Signal 11.  The kmail.kcrash report sort of points a finger at 
libkmailprivate.so, but I've stopped X, had yum rip out kdepim and 
kdepim-libs, and then re-install them with no effect on the crash.

So here is the kmail.kcrash text:
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
[snip many lines oof this]
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208654128 (LWP 25523)]
(no debugging symbols found)
[snip many more lines]
(no debugging symbols found)
[KCrash handler]
#6  0x4f406736 in KMMsgDict::insert () from /usr/lib/libkmailprivate.so
#7  0x4f58414e in KMFolderIndex::fillMessageDict ()
    from /usr/lib/libkmailprivate.so
#8  0x4f40b74e in FolderStorage::invalidateFolder ()
    from /usr/lib/libkmailprivate.so
#9  0x4f4c5145 in KMFolderMaildir::createIndexFromContents ()
    from /usr/lib/libkmailprivate.so
#10 0x4f4c039c in KMFolderMaildir::open () from /usr/lib/libkmailprivate.so
#11 0x4f5840f2 in KMFolderIndex::fillMessageDict ()
    from /usr/lib/libkmailprivate.so
#12 0x4f40b74e in FolderStorage::invalidateFolder ()
    from /usr/lib/libkmailprivate.so
#13 0x4f40b7f5 in FolderStorage::readFolderIdsFile ()
    from /usr/lib/libkmailprivate.so
#14 0x4f40b821 in FolderStorage::registerWithMessageDict ()
    from /usr/lib/libkmailprivate.so
#15 0x4f3ea77b in KMFolder::KMFolder () from /usr/lib/libkmailprivate.so
#16 0x4f42b0e1 in KMFolderDir::reload () from /usr/lib/libkmailprivate.so
#17 0x4f42cb95 in KMFolderMgr::setBasePath () from 
/usr/lib/libkmailprivate.so
#18 0x4f42ce7f in KMFolderMgr::KMFolderMgr () from 
/usr/lib/libkmailprivate.so
#19 0x4f4d99ff in KMKernel::init () from /usr/lib/libkmailprivate.so
#20 0x0804a031 in QObject::checkConnectArgs ()
#21 0x00b22390 in __libc_start_main () from /lib/libc.so.6
#22 0x08049dd1 in QObject::checkConnectArgs ()

That's all folks.  Kontact gives a quite similar report.

Does anyone have a clue, I'm beginning to suffer email withdrawal here.

Thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
While you recently had your problems on the run, they've regrouped and
are making another attack.

[Gene Heskett]

On Monday 24 March 2008, Michael Schwendt wrote:
> On Mon, 24 Mar 2008 09:48:16 -0400, Gene Heskett wrote:
> > On Monday 24 March 2008, Michael Schwendt wrote: 
> > >Do you realise that it could be a segfault caused by
> corrupted input data
> > >and not by corrupted packages? Depending on what libkmailprivate does in
> > >this area of the code, it could be that it doesn't verify the input data
> > >enough as would be necessary to prevent it from crashing.
> >
> > Should I, when things settle, file a bugzilla against libkmailprivate.so? 
> > Or whatever it is that manages the .index files?
>
> In the KDE bug tracker, yes. It's an error condition that ought to be
> handled IMO. 
Update, sorry it wasn't quicker.  It was bad data, not kmail.  I had a totally 
bogus debian-lists.index that wasn't a file, an ls -l showed it as the name 
and everything else as ???? and it couldn't be deleted.  I did kill the rest 
of the debian-users folder and data, and that let kmail run again.  Then 
someone else said I should touch /forcefsck and reboot, and that fixed it 
right up.  Took 40 minutes and a lot of y's but fixed it.

At this point, I am very solidly convinced that the 2.6.24 kernel I had been 
running for a week or so, and which had crashed outright several times, or 
gone on vacation for 30 seconds or more at a time, sometimes killing x, or 
any number of other oddities, was the problem.  I managed to get another copy 
of it built but without the 'tickless' option in the .config, and the machine 
is a whole new machine, no hangs since.  I've also built 2.6.24.4 and that is 
also working well ATM.  I posted a message on lkml that I didn't think 
tickless was quite ready for prime time, at least on my hardware.

Thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Windows 95: Proof that P. T. Barnum was right.

[Michael Schwendt]

On Mon, 24 Mar 2008 09:48:16 -0400, Gene Heskett wrote:

>  On Monday 24 March 2008, Michael Schwendt wrote:
>  >On Mon, 24 Mar 2008 00:01:52 -0400, Gene Heskett wrote:
>  >> I've had several hard lockups over the last day, possibly related to a
>  >> tickless kernel2.6.24.1 I could keep running long enough to recompile it
>  >> with the usual kilohertz tick, so ATM I'm on one of the older 2.6.23
>  >> kernels from the F8 repo's, and kde is 3.5.9
>  >>
>  >> Anyway, kmail (and kontact but I don't use it) is now doing a nearly
>  >> instant Signal 11.  The kmail.kcrash report sort of points a finger at
>  >> libkmailprivate.so, but I've stopped X, had yum rip out kdepim and
>  >> kdepim-libs, and then re-install them with no effect on the crash.
>  >>
>  >> So here is the kmail.kcrash text:
>  >> Using host libthread_db library "/lib/libthread_db.so.1".
>  >> (no debugging symbols found)
>  >> [snip many lines oof this]
>  >> (no debugging symbols found)
>  >> [Thread debugging using libthread_db enabled]
>  >> [New Thread -1208654128 (LWP 25523)]
>  >> (no debugging symbols found)
>  >> [snip many more lines]
>  >> (no debugging symbols found)
>  >
>  >This means that you should install the corresponding -debuginfo rpms to
>  >fill in the missing details in the backtrace.
>  >
>  Where might those be found?, yum shows nothing. 
In the [fedora-debuginfo] repo, and you need not enable that one,
because there are tools to install them:

  $ rpm -qf $(which debuginfo-install)
  yum-utils-1.1.11-1.fc8

The Wiki has additional information about them and backtraces:
http://fedoraproject.org/wiki/StackTraces

>  How can I force an fsck on /dev/VolGroupVol00 on the next boot?
Add "forcefsck" to the command line.

>  >Do you realise that it could be a segfault caused by corrupted
> input data
>  >and not by corrupted packages? Depending on what libkmailprivate does in
>  >this area of the code, it could be that it doesn't verify the input data
>  >enough as would be necessary to prevent it from crashing.
>  
>  Should I, when things settle, file a bugzilla against libkmailprivate.so?  Or 
>  whatever it is that manages the .index files? 
In the KDE bug tracker, yes. It's an error condition that ought to be
handled IMO.

[Gene Heskett]

On Monday 24 March 2008, Michael Schwendt wrote:
> On Mon, 24 Mar 2008 00:01:52 -0400, Gene Heskett wrote:
> > I've had several hard lockups over the last day, possibly related to a
> > tickless kernel2.6.24.1 I could keep running long enough to recompile it
> > with the usual kilohertz tick, so ATM I'm on one of the older 2.6.23
> > kernels from the F8 repo's, and kde is 3.5.9
> >
> > Anyway, kmail (and kontact but I don't use it) is now doing a nearly
> > instant Signal 11.  The kmail.kcrash report sort of points a finger at
> > libkmailprivate.so, but I've stopped X, had yum rip out kdepim and
> > kdepim-libs, and then re-install them with no effect on the crash.
> >
> > So here is the kmail.kcrash text:
> > Using host libthread_db library "/lib/libthread_db.so.1".
> > (no debugging symbols found)
> > [snip many lines oof this]
> > (no debugging symbols found)
> > [Thread debugging using libthread_db enabled]
> > [New Thread -1208654128 (LWP 25523)]
> > (no debugging symbols found)
> > [snip many more lines]
> > (no debugging symbols found)
>
> This means that you should install the corresponding -debuginfo rpms to
> fill in the missing details in the backtrace.
>  
Where might those be found?, yum shows nothing.

I have found a bad set  of .index files for the debian-users mailing list 
folder, and it appears kmail crashed while regenerating it.  Now its a name 
only, not even an inode attached that I can find, and un-deletable. HOWEVER,
kmail is now running again after I manually deleted all other references to 
the debian-user folder except this non-existent .debian-user.index file.

I had tried to delete all the *.index files after kmail first crashed because 
that was the trigger 2 or 3 times before, so when I ram kmail this time, it 
was several minutes, showing as high as 50% cpu in an htop display, before it 
ever opened its operating screens.

I tried booting the Dec-2007 respin in rescue mode, but then cannot 
umount /mnt/sysimage so that I can safely run a session of e2fsck 
against /dev/sda1, but its busy and cannot be unmounted, so:

How can I force an fsck on /dev/VolGroupVol00 on the next boot?

In the meantime I have built, and rebooted to, a 2.6.24.1 kernel with 
that 'tickless' BS turned off, and while its a bit early to state it without 
reservation, the system does feel a heck of a lot more responsive, I was 
having pauses in the whole system for 30 seconds at a time like some IRQ 
wasn't being serviced in a timely manner.  I am purposely making this message 
longer to see if it hangs while I'm typing, and so far in this messages 
editing it has not hung once like it was before.

Now its off to go read up on tune2fs & see if it can set that check me flag 
on /dev/Vol* or /dev/sda1

Thanks for the reply, this has been an interesting trip indeed...

> Do you realise that it could be a segfault caused by corrupted input
> data
> and not by corrupted packages? Depending on what libkmailprivate does in
> this area of the code, it could be that it doesn't verify the input data
> enough as would be necessary to prevent it from crashing. 
Should I, when things settle, file a bugzilla against libkmailprivate.so?  Or 
whatever it is that manages the .index files?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
It has been said that man is a rational animal.  All my life I have
been searching for evidence which could support this.
		-- Bertrand Russell

[Michael Schwendt]

On Mon, 24 Mar 2008 00:01:52 -0400, Gene Heskett wrote:

>  I've had several hard lockups over the last day, possibly related
> to a 
>  tickless kernel2.6.24.1 I could keep running long enough to recompile it 
>  with the usual kilohertz tick, so ATM I'm on one of the older 2.6.23 
>  kernels from the F8 repo's, and kde is 3.5.9
>  
>  Anyway, kmail (and kontact but I don't use it) is now doing a nearly 
>  instant Signal 11.  The kmail.kcrash report sort of points a finger at 
>  libkmailprivate.so, but I've stopped X, had yum rip out kdepim and 
>  kdepim-libs, and then re-install them with no effect on the crash.
>  
>  So here is the kmail.kcrash text:
>  Using host libthread_db library "/lib/libthread_db.so.1".
>  (no debugging symbols found)
>  [snip many lines oof this]
>  (no debugging symbols found)
>  [Thread debugging using libthread_db enabled]
>  [New Thread -1208654128 (LWP 25523)]
>  (no debugging symbols found)
>  [snip many more lines]
>  (no debugging symbols found) 
This means that you should install the corresponding -debuginfo rpms to
fill in the missing details in the backtrace.

>  [KCrash handler]
>  #6  0x4f406736 in KMMsgDict::insert () from /usr/lib/libkmailprivate.so
>  #7  0x4f58414e in KMFolderIndex::fillMessageDict ()
>      from /usr/lib/libkmailprivate.so 
Do you realise that it could be a segfault caused by corrupted input data
and not by corrupted packages? Depending on what libkmailprivate does in
this area of the code, it could be that it doesn't verify the input data
enough as would be necessary to prevent it from crashing.