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)
Tracking
(Not tracked)
M7
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
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M7
Assignee | ||
Comment 1•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 3•26 years ago
|
||
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 ***
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.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•