Closed
Bug 10412
Opened 25 years ago
Closed 25 years ago
[PP] opening Inbox crashes apprunner, can't receive or read mail
Categories
(SeaMonkey :: MailNews: Message Display, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M9
People
(Reporter: jay, Assigned: sspitzer)
Details
Trying to open Inbox causes crash (clicking on anything in your account folder).
Steps:
1. Launch messenger
2. Open account folder
3. Try to open your inbox by clicking on the icon...crash
Machine and Build: RH Linux build 1999072308
Note: clicking on anything in your account folder causes the crash.
Summary: opening Inbox crashes apprunner, can't receive or read mail → [blocker] [PP] opening Inbox crashes apprunner, can't receive or read mail
Target Milestone: M9
Assignee | ||
Comment 2•25 years ago
|
||
investigating right now.
was this a pop inbox or imap inbox?
I've also asked my group to give their findings in addition to Jay's findings.
You should get your answer shortly, I hope!
Reporter | ||
Comment 4•25 years ago
|
||
My Linux account it is a POP3 account...i have about 60 messages in my Inbox.
Jay - do you know how to generate a stack trace to get add'l info? If not, I'll
ask Fenella to show you.
Reporter | ||
Comment 6•25 years ago
|
||
i tried to run gdb, but am having problems...i need to learn how to use it, or
someone else can just get the stack trace
Assignee | ||
Comment 7•25 years ago
|
||
I'm not getting the crash.
I'll go find jay and help him with gdb.
Using 19990723 build on linux, I core dump too. I have 3 accounts 1 pop, 1 imap
and 1 news. Clicking on the inbox of either pop or imap or a newsgroup causes a
core dump. Acutally clicking on any folder that has messages causes the core
dump.
Assignee | ||
Comment 9•25 years ago
|
||
here's the stack. debugging now. looks like we are passing null
to strftime() which would cause the crash.
#0 0x4067e26c in strftime (s=0x0, maxsize=4294967295,
format=0x40c461c1 <Address 0x40c461c1 out of bounds>, tp=0xbfffae88)
at strftime.c:1155
strftime.c:1155: No such file or directory.
(gdb) where
#0 0x4067e26c in strftime (s=0x0, maxsize=4294967295,
format=0x40c461c1 <Address 0x40c461c1 out of bounds>, tp=0xbfffae88)
at strftime.c:1155
#1 0x4067ce82 in strftime (
s=0xbfffae14 "(óJ@\f[n@8®ÿ¿x\035J@À\020Q\b(óJ@ÿÿÿÿ\204\035J@\001",
maxsize=80, format=0xbfffadf4 "%c %I:%M:%S %p", tp=0xbfffae88)
at strftime.c:728
#2 0x40c613bd in nsDateTimeFormatUnix::FormatTMTime ()
#3 0x40c61709 in nsDateTimeFormatUnix::FormatPRExplodedTime ()
#4 0x40c61695 in nsDateTimeFormatUnix::FormatPRTime ()
#5 0x407e1404 in nsRDFContentUtils::GetTextForNode ()
#6 0x407ec083 in RDFGenericBuilderImpl::BuildContentFromTemplate ()
#7 0x407ed34b in RDFGenericBuilderImpl::CreateTemplateContents ()
#8 0x407e864d in RDFGenericBuilderImpl::CreateContents ()
#9 0x407ff2b8 in XULDocumentImpl::CreateContents ()
#10 0x407e67e1 in RDFElementImpl::EnsureContentsGenerated ()
#11 0x407e4855 in RDFElementImpl::ChildCount ()
#12 0x40acae1a in nsCSSFrameConstructor::ProcessChildren ()
#13 0x40acca6e in nsCSSFrameConstructor::ConstructTableCellFrameOnly ()
#14 0x40acc7ba in nsCSSFrameConstructor::ConstructTableCellFrame ()
#15 0x40aceef0 in nsCSSFrameConstructor::ConstructXULFrame ()
#16 0x40ad0370 in nsCSSFrameConstructor::ConstructFrame ()
#17 0x40acccce in nsCSSFrameConstructor::TableProcessChild ()
#18 0x40accc01 in nsCSSFrameConstructor::TableProcessChildren ()
#19 0x40acc474 in nsCSSFrameConstructor::ConstructTableRowFrameOnly ()
#20 0x40acc27e in nsCSSFrameConstructor::ConstructTableRowFrame ()
#21 0x40aceea8 in nsCSSFrameConstructor::ConstructXULFrame ()
#22 0x40ad0370 in nsCSSFrameConstructor::ConstructFrame ()
#23 0x40ad46c4 in nsCSSFrameConstructor::CreateTreeWidgetContent ()
#24 0x40b27716 in nsTreeRowGroupFrame::GetFirstFrameForReflow ()
#25 0x40b12713 in nsTableRowGroupFrame::ReflowMappedChildren ()
#26 0x40b1389a in nsTableRowGroupFrame::Reflow ()
#27 0x40a082b3 in nsContainerFrame::ReflowChild ()
#28 0x40b128c4 in nsTableRowGroupFrame::ReflowMappedChildren ()
#29 0x40b1389a in nsTableRowGroupFrame::Reflow ()
#30 0x40a082b3 in nsContainerFrame::ReflowChild ()
#31 0x40b0af6c in nsTableFrame::ReflowMappedChildren ()
#32 0x40b096c8 in nsTableFrame::ResizeReflowPass2 ()
#33 0x40b0907c in nsTableFrame::Reflow ()
#34 0x40b259db in nsTreeFrame::Reflow ()
#35 0x40a082b3 in nsContainerFrame::ReflowChild ()
#36 0x40b0f26c in nsTableOuterFrame::Reflow ()
#37 0x40a06125 in nsBlockReflowContext::ReflowBlock ()
#38 0x40a021a5 in nsBlockFrame::ReflowBlockFrame ()
#39 0x40a01601 in nsBlockFrame::ReflowLine ()
#40 0x40a011e6 in nsBlockFrame::ReflowDirtyLines ()
#41 0x40a007b9 in nsBlockFrame::Reflow ()
#42 0x40b1ea2e in nsBoxFrame::FlowChildAt ()
T #43 0x40b1df36 in nsBoxFrame::GetChildBoxInfo ()
#44 0x40b1f271 in nsBoxFrame::GetBoxInfo ()
#45 0x40b1e028 in nsBoxFrame::Reflow ()
#46 0x40a082b3 in nsContainerFrame::ReflowChild ()
#47 0x40a1075a in RootFrame::Reflow ()
#48 0x40a082b3 in nsContainerFrame::ReflowChild ()
#49 0x40a2e0ab in ViewportFrame::Reflow ()
#50 0x40a1162c in nsHTMLReflowCommand::Dispatch ()
#51 0x40a22ebe in PresShell::ProcessReflowCommands ()
#52 0x40a21d7a in PresShell::ExitReflowLock ()
#53 0x40a23b1c in PresShell::ContentAppended ()
#54 0x407fe50c in XULDocumentImpl::ContentAppended ()
#55 0x407e4cf5 in RDFElementImpl::AppendChildTo ()
#56 0x40805bda in XULSortServiceImpl::InsertContainerNode ()
#57 0x407ec206 in RDFGenericBuilderImpl::BuildContentFromTemplate ()
#58 0x407ec661 in RDFGenericBuilderImpl::CreateWidgetItem ()
#59 0x407e8b89 in RDFGenericBuilderImpl::OnAssert ()
#60 0x407d06a6 in CompositeDataSourceImpl::OnAssert ()
#61 0x4073a47a in nsMsgRDFDataSource::assertEnumFunc ()
#62 0x40155c0d in nsSupportsArray::EnumerateForwards ()
#63 0x4073a44d in nsMsgRDFDataSource::NotifyObservers ()
#64 0x4073b72d in nsMsgFolderDataSource::OnItemAdded ()
#65 0x407349dd in nsMsgMailSession::NotifyFolderItemAdded ()
#66 0x407659c3 in nsMsgFolder::NotifyItemAdded ()
#67 0x40766893 in nsMsgDBFolder::OnKeyAdded ()
#68 0x40dc57a1 in nsMsgDatabase::NotifyKeyAddedAll ()
#69 0x40dc892b in nsMsgDatabase::AddNewHdrToDB ()
#70 0x40cc5864 in nsMsgMailboxParser::PublishMsgHeader ()
#71 0x40cc59c8 in nsMsgMailboxParser::HandleLine ()
#72 0x407630ae in nsMsgLineBuffer::ConvertAndSendBuffer ()
#73 0x40762ff5 in nsMsgLineBuffer::BufferInput ()
#74 0x40cc55fb in nsMsgMailboxParser::ProcessMailboxInputStream ()
#75 0x40cc51e4 in nsMsgMailboxParser::OnDataAvailable ()
#76 0x40cc95e3 in nsMailboxProtocol::ReadFolderResponse ()
#77 0x40cc982a in nsMailboxProtocol::ProcessProtocolState ()
#78 0x4076b768 in nsMsgProtocol::OnDataAvailable ()
#79 0x400ea287 in nsStreamListenerProxy::OnDataAvailable ()
#80 0x400ede40 in XP_FindContextOfType ()
#81 0x40032540 in _init ()
#82 0x40032b6a in _init ()
#83 0x400cb153 in NET_ProcessNet ()
#84 0x400d0777 in NET_PollSockets ()
#85 0x400e9215 in nsNetlibService::NetPollSocketsCallback ()
#86 0x804db7e in main ()
#87 0x804de5c in nsTimerExpired ()
#88 0x4029a8c3 in g_main_set_poll_func ()
#89 0x40299e48 in g_get_current_time ()
#90 0x4029a2c3 in g_get_current_time ()
q¨È%T #91 0x4029a3dd in g_main_run ()
#92 0x4023e0b7 in gtk_main ()
#93 0x401f8be3 in nsAppShell::Run ()
#94 0x4010a4c6 in nsAppShellService::Run ()
#95 0x804d3d6 in main ()
Comment 10•25 years ago
|
||
Robert, this crash looks like it's in the code you turned on by adding i18n date
time formatting. Maybe until we have this fixed, we can turn this back to the
way it was? Seth, could you update this with what you've found.
Severity: blocker → critical
Summary: [blocker] [PP] opening Inbox crashes apprunner, can't receive or read mail → [PP] opening Inbox crashes apprunner, can't receive or read mail
Comment 11•25 years ago
|
||
I'm downgrading to a non-blocker since QA can at least proceed with testing
after Seth's temporary fix for us.
Assignee | ||
Comment 12•25 years ago
|
||
I've switched it back to the old way, and now dates appear in the thread pane on
all platforms.
but, they aren't localized.
next I'll try to find and fix the UNIX crasher soon, so we can do it the right
way.
Comment 13•25 years ago
|
||
Seth - do you want this bug assigned to you? Or should this bug be assigned to
someone else besides Phil?
Assignee | ||
Updated•25 years ago
|
Assignee: phil → sspitzer
Assignee | ||
Comment 14•25 years ago
|
||
re-assign to sspitzer.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 15•25 years ago
|
||
accept bug.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 16•25 years ago
|
||
I think I've fixed the problem. (I'll know for sure on monday, when
release builds are built.)
the problem was this:
we were calling strftime() with a partially garbage struct tm.
size_t strftime(char *s, size_t max, const char *format, const struct tm
*tm);
here's why we passed it partial garbage:
on the stack, we declare a struct tm. but we never initialize the
memory, and it got raw stack garbage.
them we fill in fields of the struct, all except for 3 fields. (I'm not
sure why we don't set those three, I'll talk to the author when he gets
back from vacation.)
I read in a post on dejanews that passing partial garbage in the tm
struct to
strftime can cause a SIGSEGV.
so, I just memset it to zero before setting the fields.
the reason it wasn't crashing for me, but it was for the QA people, was
I had a debug build, and the garbage on the stack and therefore in the tm struct
was different.
to test my fix, you need to add this to your prefs50.js file:
user_pref("test.10412.fix", true);
If you set this pref, and you can click on the inbox and it doesn't crash and
you see dates in the thread pane, I can take out some temporary code (to support
that pref) nsRDFContentUtils.cpp.
Comment 17•25 years ago
|
||
Using the Linux 7/26 afternoon build on Linux (1999-07-26-14 M9)
This problem has been fixed.
Comment 18•25 years ago
|
||
Seth, I use the following in my prefs50.js file
user_pref("test.10412.fix", true);
and it does not crash either. The build I use is dated July 26 16:45 on Linux
(1999-07-26-14)
Assignee | ||
Comment 19•25 years ago
|
||
excellent!
I'd like to get jay patel or esther to test this too, since they were crashing.
As soon as we can confirm, I'll get rid of that pref and the code to support it.
Assignee | ||
Comment 20•25 years ago
|
||
it turns out that fenella was seeing the same crash, as jay and esther on
friday, so she's as good as anyone to verify.
I'll take out the pref code. after the tree opens, that temporary pref will not
be required.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•