Closed Bug 6878 Opened 26 years ago Closed 26 years ago

Crash in nsSocketTransport::GetURLInfo attempting to check for new messages

Categories

(MailNews Core :: Networking, defect, P2)

PowerPC
Mac System 8.5
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 6794

People

(Reporter: cyrus, Assigned: mscott)

Details

Perhaps this will go away when necko lands, but here goes anyway... PowerPC access exception at 175CB81C nsSocketTransport::GetURLInfo(nsIURL*, URL_Struct_**)+00 080 Address 175CB81C is in VM file-mapped logical memory space The address is in a CFM fragment “NETLIB_DLL” [non-write exec] It is 0006381C bytes from the start of the fragment PowerPC 740/750 Registers CR0 CR1 CR2 CR3 CR4 CR5 CR6 CR7 PC = 175CB81C CR 0100 1010 0000 0000 0000 1000 1000 1001 LR = 175CB7DC <>=O XEVO CTR = 16677794 MSR = 00000000 SOC Compare Count Int = 0 XER 001 00 0C R0 = 04B8AEAC R8 = 00000000 R16 = 04B8D940 R24 = 04C81C20 SP = 06C24F90 R9 = 06AE29E8 R17 = 04E689F8 R25 = 04E689F8 TOC = 06B08D30 R10 = 00000008 R18 = 04E689F8 R26 = 06D45474 R3 = EFEFEFEF R11 = 1662FFE1 R19 = 04E689F8 R27 = 00000009 R4 = 04E689F8 R12 = FFFFFFFF R20 = 04E689F8 R28 = 04E689F8 R5 = 06C24F78 R13 = 00000000 R21 = 04E689F8 R29 = 06C25018 R6 = 00000009 R14 = 0000004E R22 = 00000000 R30 = EFEFEFEF R7 = 00000009 R15 = 074A3710 R23 = 00000000 R31 = 04B8E204 Disassembling PowerPC code from 175CB7F4 nsSocketTransport::GetURLInfo(nsIURL*, URL_Struct_**) +00058 175CB7F4 lwz r0,0x0000(r29) | 801D0000 +0005C 175CB7F8 stw r0,0x0440(r31) | 901F0440 +00060 175CB7FC b nsSocketTransport::GetURLInfo(nsIURL*, URL_Struct_**)+0008C ; 0x175CB828 | 4800002C +00064 175CB800 lwz r3,0x0440(r31) | 807F0440 +00068 175CB804 lwz r30,0x009C(r3) | 83C3009C +0006C 175CB808 cmplwi r30,0x0000 | 281E0000 +00070 175CB80C beq nsSocketTransport::GetURLInfo(nsIURL*, URL_Struct_**)+0008C ; 0x175CB828 | 4182001C +00074 175CB810 mr r3,r30 | 7FC3F378 +00078 175CB814 mr r4,r28 | 7F84E378 +0007C 175CB818 lwz r12,0x0000(r3) | 81830000 +00080 175CB81C *lwz r12,0x0014(r12) | 818C0014 +00084 175CB820 bl $+0x3908 ; 0x175CF128 | 48003909 +00088 175CB824 lwz RTOC,0x0014(SP) | 80410014 +0008C 175CB828 li r3,0x0000 | 38600000 +00090 175CB82C lwz r0,0x0058(SP) | 80010058 +00094 175CB830 addi SP,SP,0x0050 | 38210050 +00098 175CB834 mtlr r0 ; LR = 0x0008 | 7C0803A6 +0009C 175CB838 lwz r31,-0x0004(SP) | 83E1FFFC +000A0 175CB83C lwz r30,-0x0008(SP) | 83C1FFF8 (CurStackBase does not seem to apply...dumping 4K.) Calling chain using A6/R1 links Back chain ISA Caller 06C25580 PPC 17774128 _PR_UserRunThread+000C4 06C25500 PPC 1664B468 nsImapProtocol::ImapThreadMain(void*)+002D8 06C25450 PPC 1664BAFC nsImapProtocol::ImapThreadMainLoop()+0007C 06C25410 PPC 1664BDAC nsImapProtocol::ProcessCurrentURL()+00180 06C25390 PPC 1664D2B4 nsImapProtocol::ProcessSelectedStateURL()+00328 06C25170 PPC 16654968 nsImapProtocol::Noop()+00068 06C25110 PPC 1664C530 nsImapProtocol::SendData(const char*)+0019C 06C250A0 PPC 175BB4B4 nsStreamListenerProxy::OnDataAvailable(nsIURL*, nsIInputStream*, unsigned int)+000C0 06C25040 PPC 175CB084 nsSocketTransport::OnDataAvailable(nsIURL*, nsIInputStream*, uns igned int)+00078 (CurStackBase does not seem to apply...dumping 4K.) Return addresses on the stack Stack Addr Frame Addr ISA Caller 06C256EC 68K 06C25496 06C256C4 68K 17779A7A _MD_wait+00052 06C25680 68K 04C3E3AA 06C2567C 68K 04C3E3AA 06C25634 68K 071FE826 06C25588 68K 17774062 PRP_TryLock+00C2E 06C25558 06C25554 68K 074A34F6 06C25508 06C25500 PPC 17774128 _PR_UserRunThread+000C4 06C25488 06C25480 PPC 17773850 _PR_FreeStack+00098 06C25458 06C25450 PPC 1664B468 nsImapProtocol::ImapThreadMain(void*)+ 002D8 06C25418 06C25410 PPC 1664BAFC nsImapProtocol::ImapThreadMainLoop()+ 0007C 06C253C8 06C253C0 PPC 17770824 PR_Wait+00068 06C25398 06C25390 PPC 1664BDAC nsImapProtocol::ProcessCurrentURL()+ 00180 06C25358 68K 06C25496 06C25302 68K 0000071E 06C252F8 06C252F0 PPC 1663A894 nsIMAPHostSessionList::GetHaveWeEverDiscoveredFolde rsForHost(const char*, const char*, int&)+0005C 06C252C8 68K 06C25496 06C252B8 06C252B0 PPC 1777071C PR_ExitMonitor+00054 06C25288 06C25280 PPC 1777071C PR_ExitMonitor+00054 06C25258 06C25250 PPC 1665B708 nsImapExtensionSinkProxy::~nsImapExtensionSinkProxy ()+00074 06C25248 06C25240 PPC 1664628C nsImapMailFolder::OnStopRunningUrl(nsIURL*, unsigne d int)+000EC 06C25218 06C25210 PPC 16657CFC nsImapProxyBase::~nsImapProxyBase()+ 0006C 06C251F8 06C251F0 PPC 1788429C operator delete(void*)+0001C 06C251D8 06C251D0 PPC 1668655C nsMsgDBFolder::AddRef()+00014 06C251B8 06C251B0 PPC 1788541C free+0006C 06C25178 06C25170 PPC 1664D2B4 nsImapProtocol::ProcessSelectedStateURL()+00328 06C25138 PPC 16651DAC nsImapProtocol::DeathSignalReceived()+ 0002C 06C25122 68K 0000071E 06C25118 06C25110 PPC 16654968 nsImapProtocol::Noop()+00068 06C250B8 06C250B0 PPC 1773F660 nsString2::Append(const char*, int)+ 00074 06C250A8 06C250A0 PPC 1664C530 nsImapProtocol::SendData(const char*)+ 0019C 06C250A4 06C250A0 68K 06C25146 06C25068 PPC 1773F268 nsString2::Assign(const char*, int)+ 00048 06C25058 06C25050 PPC 1782E068 nsCOMPtr_base::assign_with_QueryInterface(nsISuppor ts*, const nsID&, unsigned int*)+0004C 06C25048 06C25040 PPC 175BB4B4 nsStreamListenerProxy::OnDataAvailable(nsIURL*, nsI InputStream*, unsigned int)+000C0 06C25024 06C25020 68K 06C25146 06C25008 06C25000 PPC 1777071C PR_ExitMonitor+00054 06C24FF8 06C24FF0 PPC 175AFDBC nsNetlibStream::QueryInterface(const nsID&, void**) +000A4 06C24FE8 06C24FE0 PPC 175CB084 nsSocketTransport::OnDataAvailable(nsIURL*, nsIInpu tStream*, unsigned int)+00078 06C24FCC 68K 06C25146 06C24FC8 06C24FC0 PPC 1773BAD4 nsStr::Initialize(nsStr&, eCharSize)+ 00018 06C24F98 06C24F90 PPC 175CB7D8 nsSocketTransport::GetURLInfo(nsIURL*, URL_Struct_* *)+0003C The “apprunnerDebug” heap at 06AC7290 is ok Totaling the “apprunnerDebug” heap at 06AC7290 Total Blocks Total of Block Sizes Free 005D #93 0007B7D0 #505808 Nonrelocatable 00CA #202 0074E53C #7660860 Relocatable 0452 #1106 001C89B0 #1870256 Locked 0005 #5 001B5D20 #1793312 Purgeable and not locked 0000 #0 00000000 #0 Heap size 0579 #1401 009926BC #10036924 The target heap is the System heap at 00002800 The System heap at 00002800 is ok Totaling the System heap at 00002800 Total Blocks Total of Block Sizes Free 007F #127 002B4BD0 #2837456 Nonrelocatable 0D06 #3334 0057677C #5728124 Relocatable 0D2E #3374 00513D10 #5324048 Locked 0246 #582 003BC220 #3916320 Purgeable and not locked 011E #286 000AF480 #717952 Heap size 1AB3 #6835 00D3F05C #13889628
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M7
Actually, you'll get this fixed before necko lands =) any chance the server timed out on you (was your connection idle for say 29 minutes or more b4 you did get new mail)? We have a bug which we have a fix for on imap where we crash after the server times out & you then initiate an imap action like get new mail. The stack trace is identical to this one. It's undecided if we are going to take it for M6 or wait until M6 clears b4 landing. If you think the server timed out, lemme know and I'll mark this as a dup of that one. Thanks for the feedback!
Yeah, the server probably timed out because I was banging on it from netscape 4.6 at close to the same time. (mozilla -> 4.6 -> mozilla = crash!). Sounds like a dup.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
okay that does sound like a dup. I'm going to mark it as such. *** This bug has been marked as a duplicate of 6794 ***
Status: RESOLVED → VERIFIED
marking verified as a duplicate.
Moving all Mail/News Networking bugs to Mail/News Networking-Mail This may re-open previously Verified bugs due to a Bugzilla bug...if so, I will fix those bugs.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.