947945 - linux crash in dosprintf(SprintfStateStr*, unsigned short const*, __va_list_tag*) () via nsMsgDBView::FetchSize

Status: RESOLVED WORKSFORME

(MailNews Core :: Backend, defect)

Description

[Martin Mokrejs]

Attachment: gdb_stacktrace.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22 (Beta/Release)
Build ID: 20131110020049

Steps to reproduce:

For a few weeks I have seamonkey crashing, seems some recent upgrade. This is Gentoo Linux 64bit arch. It mostly crashes when I click on an Inbox in my mailer and a window should be redrawn with new emails listed. I do have mailer opened already. Maybe related to bug #720816 ?



Actual results:

(gdb) where
#0  0x00007f6b39e2555b in raise () from /lib64/libpthread.so.0
#1  0x00007f6b355f914a in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) () from /usr/lib64/seamonkey/libxul.so
#2  <signal handler called>
#3  0x00007f6b3659dafa in dosprintf(SprintfStateStr*, unsigned short const*, __va_list_tag*) () from /usr/lib64/seamonkey/libxul.so
#4  0x00007f6b3659e72d in nsTextFormatter::vssprintf(nsAString_internal&, unsigned short const*, __va_list_tag*) () from /usr/lib64/seamonkey/libxul.so
#5  0x00007f6b3659e7c7 in nsTextFormatter::ssprintf(nsAString_internal&, unsigned short const*, ...) () from /usr/lib64/seamonkey/libxul.so
#6  0x00007f6b36080b3c in FormatFileSize(unsigned long, bool, nsAString_internal&) () from /usr/lib64/seamonkey/libxul.so
#7  0x00007f6b360a1454 in nsMsgDBView::FetchSize(nsIMsgDBHdr*, nsAString_internal&) () from /usr/lib64/seamonkey/libxul.so
#8  0x00007f6b360ac0b5 in nsMsgDBView::CellTextForColumn(int, unsigned short const*, nsAString_internal&) () from /usr/lib64/seamonkey/libxul.so
#9  0x00007f6b360bc985 in nsMsgGroupView::CellTextForColumn(int, unsigned short const*, nsAString_internal&) () from /usr/lib64/seamonkey/libxul.so
#10 0x00007f6b360a27e1 in nsMsgDBView::GetCellText(int, nsITreeColumn*, nsAString_internal&) () from /usr/lib64/seamonkey/libxul.so
#11 0x00007f6b35d91efc in nsTreeBodyFrame::PaintText(int, nsTreeColumn*, nsRect const&, nsPresContext*, nsRenderingContext&, nsRect const&, int&, bool) () from /usr/lib64/seamonkey/libxul.so
#12 0x00007f6b35d96071 in nsTreeBodyFrame::PaintCell(int, nsTreeColumn*, nsRect const&, nsPresContext*, nsRenderingContext&, nsRect const&, int&, nsPoint) () from /usr/lib64/seamonkey/libxul.so
#13 0x00007f6b35d9691c in nsTreeBodyFrame::PaintRow(int, nsRect const&, nsPresContext*, nsRenderingContext&, nsRect const&, nsPoint) () from /usr/lib64/seamonkey/libxul.so
#14 0x00007f6b35d96c75 in nsTreeBodyFrame::PaintTreeBody(nsRenderingContext&, nsRect const&, nsPoint) () from /usr/lib64/seamonkey/libxul.so
#15 0x00007f6b35d96da1 in PaintTreeBody(nsIFrame*, nsRenderingContext*, nsRect const&, nsPoint) () from /usr/lib64/seamonkey/libxul.so
#16 0x00007f6b35855077 in nsDisplayGeneric::Paint(nsDisplayListBuilder*, nsRenderingContext*) () from /usr/lib64/seamonkey/libxul.so
#17 0x00007f6b357eb507 in mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*) () from /usr/lib64/seamonkey/libxul.so
#18 0x00007f6b36639186 in mozilla::layers::BasicThebesLayer::PaintBuffer(gfxContext*, nsIntRegion const&, nsIntRegion const&, nsIntRegion const&, bool, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*) ()
   from /usr/lib64/seamonkey/libxul.so
#19 0x00007f6b36639c9f in mozilla::layers::BasicThebesLayer::PaintThebes(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) ()
   from /usr/lib64/seamonkey/libxul.so
#20 0x00007f6b36637e56 in mozilla::layers::BasicLayerManager::PaintSelfOrChildren(mozilla::layers::PaintLayerContext&, gfxContext*) () from /usr/lib64/seamonkey/libxul.so
#21 0x00007f6b36638248 in mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) ()
   from /usr/lib64/seamonkey/libxul.so
#22 0x00007f6b36637ef5 in mozilla::layers::BasicLayerManager::PaintSelfOrChildren(mozilla::layers::PaintLayerContext&, gfxContext*) () from /usr/lib64/seamonkey/libxul.so
#23 0x00007f6b36638248 in mozilla::layers::BasicLayerManager::PaintLayer(gfxContext*, mozilla::layers::Layer*, void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::ReadbackProcessor*) ()
   from /usr/lib64/seamonkey/libxul.so
#24 0x00007f6b36638b7a in mozilla::layers::BasicLayerManager::EndTransactionInternal(void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) () from /usr/lib64/seamonkey/libxul.so
#25 0x00007f6b3581c6d3 in nsDisplayList::PaintForFrame(nsDisplayListBuilder*, nsRenderingContext*, nsIFrame*, unsigned int) const () from /usr/lib64/seamonkey/libxul.so
#26 0x00007f6b3581c933 in nsDisplayList::PaintRoot(nsDisplayListBuilder*, nsRenderingContext*, unsigned int) const () from /usr/lib64/seamonkey/libxul.so
#27 0x00007f6b3583189a in nsLayoutUtils::PaintFrame(nsRenderingContext*, nsIFrame*, nsRegion const&, unsigned int, unsigned int) () from /usr/lib64/seamonkey/libxul.so
#28 0x00007f6b35843446 in PresShell::Paint(nsView*, nsRegion const&, unsigned int) () from /usr/lib64/seamonkey/libxul.so
#29 0x00007f6b35bdbc29 in nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) () from /usr/lib64/seamonkey/libxul.so
#30 0x00007f6b3584df5c in nsRefreshDriver::Tick(long, mozilla::TimeStamp) () from /usr/lib64/seamonkey/libxul.so
#31 0x00007f6b3584e0e0 in mozilla::RefreshDriverTimer::Tick() () from /usr/lib64/seamonkey/libxul.so
#32 0x00007f6b365d1986 in nsTimerImpl::Fire() () from /usr/lib64/seamonkey/libxul.so
#33 0x00007f6b365d1a41 in nsTimerEvent::Run() () from /usr/lib64/seamonkey/libxul.so
#34 0x00007f6b365cf0b7 in nsThread::ProcessNextEvent(bool, bool*) () from /usr/lib64/seamonkey/libxul.so
#35 0x00007f6b365a28c3 in NS_ProcessNextEvent(nsIThread*, bool) () from /usr/lib64/seamonkey/libxul.so
#36 0x00007f6b3629be30 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /usr/lib64/seamonkey/libxul.so
#37 0x00007f6b365efb0d in MessageLoop::Run() () from /usr/lib64/seamonkey/libxul.so
#38 0x00007f6b36033995 in nsBaseAppShell::Run() () from /usr/lib64/seamonkey/libxul.so
#39 0x00007f6b35f03527 in nsAppStartup::Run() () from /usr/lib64/seamonkey/libxul.so
#40 0x00007f6b355f4486 in XREMain::XRE_mainRun() () from /usr/lib64/seamonkey/libxul.so
#41 0x00007f6b355f46df in XREMain::XRE_main(int, char**, nsXREAppData const*) () from /usr/lib64/seamonkey/libxul.so
#42 0x00007f6b355f4908 in XRE_main () from /usr/lib64/seamonkey/libxul.so
#43 0x0000000000404368 in main ()
(gdb)

Comment 1

[Martin Mokrejs]

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22
Build identifier: 20131110020049

Comment 2

[Wayne Mery (:wsmwk)]

Unclear if related to bug 720816, which I just closed incomplete without a testcase. 

Perhaps we can find a testcase in this bug, which seems to be mail related because all linux crashes have a stack of 
0	libxul.so	dosprintf	/build/buildd/thunderbird-26.0~b1+build1/mozilla/xpcom/glue/nsTextFormatter.cpp
1	libxul.so	nsTextFormatter::vssprintf	/build/buildd/thunderbird-26.0~b1+build1/mozilla/xpcom/glue/nsTextFormatter.cpp
2	libxul.so	nsTextFormatter::ssprintf	/build/buildd/thunderbird-26.0~b1+build1/mozilla/xpcom/glue/nsTextFormatter.cpp
3	libxul.so	FormatFileSize	/build/buildd/thunderbird-26.0~b1+build1/mailnews/base/util/nsMsgUtils.cpp
4	libxul.so	nsMsgDBView::FetchSize	/build/buildd/thunderbird-26.0~b1+build1/mailnews/base/src/nsMsgDBView.cpp
5	libxul.so	nsMsgDBView::CellTextForColumn	/build/buildd/thunderbird-26.0~b1+build1/mailnews/base/src/nsMsgDBView.cpp
6	libxul.so	nsMsgGroupView::CellTextForColumn	/build/buildd/thunderbird-26.0~b1+build1/mailnews/base/src/nsMsgGroupView.cpp

Comment 3

[Martin Mokrejs]

Attachment: seamonkey-2.23_stacktrace.txt

This one was not related to a new email being fetched via POP3. Or at least,
no new message was in local Inbox neither was any message to be fetched
via POP3 after I started seamonkey mailer again.

But, I was composing an email, actually I was just about to send it away
or close to finish the text. Per Sent folders I did not send it away (yet)
and also, logs on my SMTP server confirm I did not send the email away.

Isn't the problem just the dosprintf() accessing the string in a wrong way?
Isn't it accessing it behind an offset or so? Or a NULL terminated string issue?
Sorry, just guessing, I am not a C programmer. I just always thought the problem is just in this function call.

Comment 4

[Martin Mokrejs]

Attachment: seamonkey-2.24_stacktrace.txt

It happened again. I was reading my emails (fetched via POP3, stored locally, the Inbox file has 9243 message, size on disk 524MB, this is ext3 filesystem on Linux). Folder properties offer me to compress the folder so I conclude it is not compressed. Actually, I read it occasionally via less(1) and it works fine. ;)

I received 4 emails at once, small one, I read first, then skipped to the last (fourth), then pressed Delete button and pressed Up arrow to skip the third and move to the second one. The gray line selecting current email in the listing did not move up, mouse pointer locked, after a while 1.5GB core file was written on the disk. Please lee me know if you want me to execute some commands in the gdb session. Something cut&paste, please. ;) I am not that skilled with gdb, ANSI C, etc.

Comment 5

[Martin Mokrejs]

Attachment: seamonkey-2.24-gdb-stacktrace.txt (case 2)

This one crashed in background of me, both browser and mailer were started.

Comment 7

[Wayne Mery (:wsmwk)]

In Decemeber I had corresponded with Gary whose crash is bp-e23c2dfe-59c2-4ba8-8df0-eb4622131224 and has many dosprintf crashes since.

Other recent examples

bp-0739d562-2ffe-40b9-9da0-4a59f2140904 (bbranch)
" I was just clicking and scrolling through the main list of emails. This was just after the system was awakened from a sleep state. "

bp-918fa9eb-5dea-4b38-87e4-85d432140831 (stephane)
" one more crash... usually crashes on exit. Too often anyway. "

(doug) bp-7bacb911-7fa8-4427-bb86-5b2452140611 bp-8ffe453e-3733-41a1-b456-4cbfd2140717 bp-8ab20db6-a492-4138-8cc9-fe5152140904

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I had this crash today during startup of Thunderbird 31.4.0 on Ubuntu 14.10.

Crash report: bp-0c9ccded-deb6-4670-9f27-8d2852150127

Comment 9

[Martin Mokrejs]

Attachment: seamonkey-2.32.1_stacktrace.txt

I moved some email from Inbox to a local folder ...

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1
Build identifier: 20150225101806

Comment 10

[[:jberkus] Josh Berkus]

Wayne,

I'm getting this crash now, about once a day, see crash reports:
https://crash-stats.mozilla.com/report/index/c33e5143-61d1-4c20-8c58-44a1e2150402
https://crash-stats.mozilla.com/report/index/8c186a09-c9ac-46ec-826c-518332150330

This is 64-bit Ubuntu 14.04, TB 31.4. 

Since these are happening every day, I'm happy to hook up some stack trace tools if you remind me how.  Thanks.

Comment 11

[Wayne Mery (:wsmwk)]

I think the next step is to see if the crashes continue in version 38. Hopefully you will able to get the 38 beta on Monday at http://www.mozilla.org/en-US/thunderbird/channel/

Comment 12

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 13

[Wayne Mery (:wsmwk)]

Josh...

> I think the next step is to see if the crashes continue in version 38.
> Hopefully you will able to get the 38 beta on Monday at
> http://www.mozilla.org/en-US/thunderbird/channel/

Comment 14

[Wayne Mery (:wsmwk)]

Martin writes "I use seamonkey-2.39 at the moment. Can't comment on this bug, though. Why developers do not introduce few new ASSERTION lines in deemed upstream code? That should be much more helpful."

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #14)
> introduce few new ASSERTION lines in
> deemed upstream code? That should be much more helpful."

Magnus, can this help move the bug in a good direction?

(and FWIW noting here as well, I don't see how a crash could cause message loss like bug 1200724)

Comment 16

[Magnus Melin [:mkmelin]]

Well once would at least have to have an idea of what to look for there. All the crashes here are also so old so it's hard to get code links, and see if it's even relevant anymore.

Comment 17

[Wayne Mery (:wsmwk)]

On that note, so far this year there is no sign of TB45 linux crashes with this stack. I find only one crash that isn't version 38 - bp-45c345ce-1058-4f1e-9fb8-11e062160524 which is 40.0beta.

In the absence of Josh's or Martin's feedback saying they see this in TB45 or Seamonkey equivalent, this is headed to WFM.