I cant reproduce on my imap setup.


Can you try with  ~/.thunderbird on local disks to check if the nfs setup is part of the problem ?

@Frank
"TB crashes if you attempt to switch to an IMAP Inbox with an unread message"
This is not too clear: 'attempt to switch to...' ?
"This shows up when TB starts if there is an unread message in Inbox"
This is clearer.

CC'ing Len who is a Thunderbird user, to see whether he can reproduce the fault.

CC: (none) => lewyssmith, tarazed25

@Lewis
Using IMAP at Google.mail.
Could not reproduce this on my setup.  Closed thunderbird with a few messages waiting to be read.  Restarted and there was no fault.  Tried switching between LocalFolders inbox and he main Inbox - no problems.

I had posted in dev, and followed up with another post saying the problem had stopped.  Then it started again, so I opened this bug.  Now it's not happening again, with or without the NFS ~/.thunderbird .  So I'll wait for further developments, but I didn't dream the stacktrace :-)

@Frank, have you checked upstream or other places report of this happening?

(I use "offline IMAP" with local storage, no problem here.)

CC: (none) => fri

@Morgan I googled using the "Fatal error" message and also using one of the function names in the backtrace (MorkStdioFile) but either got no hits or tons of unrelated hits.

@Lewis I originally started a shorter title but Bugzilla gave me a drop-down suggestion list with the current title as the first entry, so I took that.

@Len: thanks for the check.

(In reply to Frank Griffin from comment #6)
> @Lewis I originally started a shorter title but Bugzilla gave me a drop-down
> suggestion list with the current title as the first entry, so I took that.
Back to comment 2.
Which version best describes what is happening for you?
- The enigmatic "attempt to switch to an IMAP Inbox with an unread message",
which requires clarification; or
- "when TB starts if there is an unread message in Inbox",
which is clear enough. And which other users cannot reproduce.



(In reply to Frank Griffin from comment #4)
> Now it's not
> happening again, with or without the NFS ~/.thunderbird .  So I'll wait for
> further developments, but I didn't dream the stacktrace :-)
No-one doubts you Frank! As you know too well, bugs that only happen to the reporter and not other people are a pain. Finding out why...
Does your comment here mean that you *have* tried with a local, rather than networked, .thunderbird ? This would answer tmb's comment 1.

This is happening under various circumstances now.  To answer Lewis and Thomas, I have not seen it happen with a non-NFS ~/.thunderbird, but with one I have seen it happen with an unread message in the IMAP Inbox at startup whether or not I attempt to switch to the Inbox.  I have also seen it happen when a new IMAP message comes in, and even when nothing in the IMAP Inbox is unread.  I have even seen it happen when a previously read message in the IMAP Inbox is deleted.

I have been using this NFS arrangement successfully for more than a decade, as it allows me to centralize my POP account mail on a single machine while running TB on multiple laptops as an NFS client (one at a time, of course).  The problems only started when the latest glibc showed up, which seems pretty suspicious.  Was there anything in the glibc list of changes that could relate to this ?

Probably the only way to debug this is to breakpoint TB in one of the stacktrace functions and see what's being used as a file handle.  In the above trace, that would probably be the call to ftell().  As no one else can reproduce this, I may end up doing this and sending it upstream.

(In reply to Frank Griffin from comment #8)

 
> I have been using this NFS arrangement successfully for more than a decade,
> as it allows me to centralize my POP account mail on a single machine while
> running TB on multiple laptops as an NFS client (one at a time, of course). 
> The problems only started when the latest glibc showed up, which seems
> pretty suspicious.  Was there anything in the glibc list of changes that
> could relate to this ?
> 

Well, if you went from glibc 2.36-43 to 2.36-44, it only had one fix:
- string: strerror must not return NULL [BZ #30555]

if you want to test downgrading glibc to -43 again, I put it here:
http://ftp.free.fr/mirrors/mageia.org/people/tmb/Cauldron/bugs/30256/

Thanks for this offer, Thomas.
Frank to try.

I'll try the down-leveled glibc sometime today, but I've had a SEGFAULT with the cauldron version that also ends up with a stacktrace ending in morkStdioFile() and ftell(), but this happens moving a POP message to another POP folder:

(gdb) bt
#0  0x00007ffff7a9e3f8 in ftell () at /lib64/libc.so.6
#1  0x00007ffff1ba9be7 in morkStdioFile::Length(morkEnv*) const
    (this=0x7fffbeeb4970, ev=0x7fffac035b80)
    at /usr/src/debug/thunderbird-102.12.0-1.mga9.x86_64/comm/mailnews/db/mork/morkFile.cpp:454
#2  0x00007ffff1ba976f in (null) ()
    at /usr/src/debug/thunderbird-102.12.0-1.mga9.x86_64/comm/mailnews/db/mork/morkFile.h:197
#3  0x00007ffff1bb5ec4 in morkStore::DoPreferLargeOverCompressCommit(morkEnv*)
    (this=this@entry=0x7fffac4ad900, ev=ev@entry=0x7fffac035b80)
    at /usr/src/debug/thunderbird-102.12.0-1.mga9.x86_64/comm/mailnews/db/mork/morkEnv.h:190
#4  0x00007ffff1bb5f6b in morkStore::LargeCommit(nsIMdbEnv*, nsIMdbThumb**)
    (this=0x7fffac4ad900, mev=<optimized out>, acqThumb=0x7fffffffb1d0)
    at /usr/src/debug/thunderbird-102.12.0-1.mga9.x86_64/comm/mailnews/db/mork/morkStore.cpp:1900
#5  0x00007ffff1bcb5a1 in nsMsgDatabase::Commit(int)
    (this=0x7fffeaf3e830, commitType=<optimized out>)
    at /usr/src/debug/thunderbird-102.12.0-1.mga9.x86_64/objdir/dist/include/nsMsgDatabase.h:125
#6  0x00007ffff1cbc75a in nsMsgBrkMBoxStore::SetSummaryFileValid(nsIMsgFolder*, nsIMsgDatabase*, bool)
    (this=this@entry=0x7fffbefc0430, aFolder=0x7fffacb17110, aDB=0x7fffeaf3e830, aVa

It appears to be specific to the particular message and operation, because I've been doing this for days with no problem, but at least for now, the SEGFAULT happens reliably.

I think I've figured this out.

For a few months now, I've found that a Plasma GUI logon on the NFS server locks up after extended periods of inactivity.  Sometimes it's just the Panel that locks up (the clock widget is frozen at some past time), sometimes it's the entire desktop.  Logoff/logon, and it's back.  Plasma problem, right ?

However, I've noticed that when the TB problem starts to happen, the NFS server Plasma desktop is having problems.  Reboot that server, and the TB problems go away.  I've verified that today.

The odd thing is that the server doesn't go off the network.  ssh and pretty much every other network service continue to work, so unless I'm physically sitting at the server with a Plasma desktop in pain, I don't notice anything amiss.  

Something about the fact that the NFS export is owned by the ID running Plasma and Plasma is compromised is causing the NFS client to invalidate the file descriptor on the client machine or leave it in some kind of damaged state.  So the glibc message about an invalid stdio handle is apparently accurate.

I'm going to address this by not activating Plasma on the server at all, and see if the problem disappears.  It never occurred to me that an NFS export could fail when other network services were fine, much less communicate to an NFS client that handles related to a mount were to be invalidated.  At worst, I would expect references to the mount to hang on the client side.

Sorry for the noise, but this one threw me for a loop.

Resolution: (none) => INVALID
Status: NEW => RESOLVED