830059 - ASSERTION: not-null m_mime_delivery_state: 'm_mime_delivery_state != nullptr', file comm-central/mailnews/compose/src/nsMsgAttachmentHandler.cpp

Status: NEW

(Thunderbird :: General, defect)

Description

[ISHIKAWA, Chiaki]

Attachment: Excerpt of session log with symbolic stack trace.

While testing thunderbird (local debug build of comm-central source)
by running "make mozmill", I noticed many ASSERTION messages.  I think
they are more or less (if not all of them) are symptoms of bugs or bad
design (failure to consider corner cases, etc.)

One of them is the following.

###!!! ASSERTION: not-null m_mime_delivery_state: 'm_mime_delivery_state != nullptr', file /TB-NEW/TB-3HG/new-src/mailnews/compose/src/nsMsgAttachmentHandler.cpp, line 973

I am attaching excerpt from a session local log where the debug build
of TB is run under valgrind (memcheck) during "make mozmill" under
MOZ_OBJDIR.  
The stack trace following assertion has been transformed to report
symbolic addresses by using
comm-central/mozilla/tools/rb/fix-linux-stack.pl
a la 
    MOZ_OBJDIR=/TB-NEW/TB-3HG/objdir-tb3
    # comm-central
    MOZ_SRCDIR=/TB-NEW/TB-3HG/new-src

    cd ${MOZ_OBJDIR}/mozilla/dist/bin
    ${MOZ_SRCDIR}/mozilla/tools/rb/fix-linux-stack.pl $1  

It seems that the condition may be related to the failure of delivery
or sending(?) of mail with attachmnent: : both of which seem to be
valid events that are very likely to happen in the life of a mail
client.

I am raising the flag here because if this is not a bug that warrants
assertion, the assertion may be eliminated (reduce clutter in the
session log of mozmill run of debug build of TB).  
Of course, the condition leading to this need to be examined by people
in the know.

TIA

Comment 1

[ISHIKAWA, Chiaki]

I think I have seen flurry of the same messages again. Not sure if this is with the pristine C-C TB tree or due to local patch error/bug.

Comment 2

[:aceman]

I also see this.

[20881] ###!!! ASSERTION: not-null m_mime_delivery_state: 'm_mime_delivery_state != nullptr', file /var/SSD/TB-hg/mailnews/compose/src/nsMsgAttachmentHandler.cpp, line 1074
#01: nsMsgComposeAndSend::Abort() (TB-hg/mailnews/compose/src/nsMsgSend.cpp:4721)
#02: nsMsgComposeAndSend::Fail(nsresult, char16_t const*, nsresult*) (TB-hg/mailnews/compose/src/nsMsgSend.cpp:3519)
#03: nsMsgComposeAndSend::DoDeliveryExitProcessing(nsIURI*, nsresult, bool) (TB-hg/mailnews/compose/src/nsMsgSend.cpp:3575)
#04: nsMsgComposeAndSend::DeliverAsMailExit(nsIURI*, nsresult) (TB-hg/mailnews/compose/src/nsMsgSend.cpp:3620)
#05: nsMsgComposeAndSend::SendDeliveryCallback(nsIURI*, bool, nsresult) (TB-hg/mailnews/compose/src/nsMsgSend.cpp:3210)
#06: MsgDeliveryListener::OnStopRunningUrl(nsIURI*, nsresult) (TB-hg/mailnews/compose/src/nsMsgSend.cpp:255)
#07: nsMsgMailNewsUrl::SetUrlState(bool, nsresult) (TB-hg/tbird-bin/dist/include/nsCOMPtr.h:402)
#08: nsMsgProtocol::OnStopRequest(nsIRequest*, nsISupports*, nsresult) (TB-hg/tbird-bin/dist/include/nsCOMPtr.h:758)
#09: nsSmtpProtocol::OnStopRequest(nsIRequest*, nsISupports*, nsresult) (TB-hg/mailnews/compose/src/nsSmtpProtocol.cpp:558)
#10: nsInputStreamPump::OnStateStop() (TB-hg/mozilla/netwerk/base/nsInputStreamPump.cpp:716)
#11: nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (TB-hg/mozilla/netwerk/base/nsInputStreamPump.cpp:433)
#12: nsInputStreamReadyEvent::Run() (TB-hg/tbird-bin/dist/include/nsCOMPtr.h:374)
#13: nsThread::ProcessNextEvent(bool, bool*) (TB-hg/tbird-bin/dist/include/mozilla/Maybe.h:445)
#14: NS_InvokeByIndex (TB-hg/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:92)

jcranmer, could you look at this some time in the future?