Closed Bug 19511 Opened 20 years ago Closed 19 years ago

nsMsgFolder::GetVisibleSubFolders() crash when called from js

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME
Future

People

(Reporter: ppandit, Assigned: scottputterman)

Details

(Keywords: crash)

Attachments

(1 file)

Using debug build from 11/17/99 on Windows NT

I have a testcase that calls GetVisibleSubFolders() within the nsMsgFolder
interface. When it hits the C++ code I get a crash (Unhandled exception
in mozilla.exe (MSGBSUTIL.DLL) 0xC0000005 Access Violation.

Looks like I need a result parameter?

Here is the code:
var msgService =
Components.classes['component://netscape/messenger/services/session'].getService
(Components.interfaces.nsIMsgMailSession);
var accountManager = msgService.accountManager;
var defaultAccount = accountManager.defaultAccount;
var ourincomingserver = defaultAccount.incomingServer;
var rf = ourincomingserver.RootFolder;
var rfasmsgfolder = rf.QueryInterface(Components.interfaces.nsIMsgFolder);
var subfolders = rfasmsgfolder.getVisibleSubFolders();

Here is the trace:
nsMsgFolder::GetVisibleSubFolders(nsMsgFolder * const 0x02f0419c, nsIEnumerator
* * 0x0012e1b4) line 611 + 24 bytes
XPTC_InvokeByIndex(nsISupports * 0x02f0419c, unsigned int 35, unsigned int 1,
nsXPTCVariant * 0x0012e1b4) line 139
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x02eb1900,
nsXPCWrappedNative * 0x02f26f20, const XPCNativeMemberDescriptor * 0x02528160,
nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long *
0x024dece8, long * 0x0012e364) line 894 + 43 bytes
WrappedNative_CallMethod(JSContext * 0x02eb1900, JSObject * 0x024d4ac0, unsigned
int 0, long * 0x024dece8, long * 0x0012e364) line 191 + 34 bytes
js_Invoke(JSContext * 0x02eb1900, unsigned int 0, unsigned int 0) line 673 + 26
bytes
js_Interpret(JSContext * 0x02eb1900, long * 0x0012ebb8) line 2245 + 15 bytes
js_Invoke(JSContext * 0x02eb1900, unsigned int 0, unsigned int 0) line 689 + 13
bytes
js_Interpret(JSContext * 0x02eb1900, long * 0x0012f42c) line 2245 + 15 bytes
js_Execute(JSContext * 0x02eb1900, JSObject * 0x024d4ca8, JSScript * 0x02f208b0,
JSFunction * 0x00000000, JSStackFrame * 0x00000000, int 0, long * 0x0012f42c)
line 846 + 13 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x02eb1900, JSObject * 0x024d4ca8,
JSPrincipals * 0x02f1dcc4, const unsigned short * 0x0012f95c, unsigned int 20,
const char * 0x02f20cb0, unsigned int 46, long * 0x0012f42c) line 2717 + 27
bytes
nsJSContext::EvaluateString(nsJSContext * const 0x02eb1a90, const nsString &
{...}, void * 0x024d4ca8, nsIPrincipal * 0x02f1dcc0, const char * 0x02f20cb0,
unsigned int 46, const char * 0x00000000, nsString & {...}, int * 0x0012f464)
line 227 + 53 bytes
HTMLContentSink::EvaluateScript(nsString & {...}, int 46, const char *
0x00000000) line 3593
HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 3787
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x02f0d930, const nsIParserNode
& {...}) line 2606 + 12 bytes
CNavDTD::AddLeaf(const nsIParserNode * 0x02f17460) line 2979 + 28 bytes
CNavDTD::HandleScriptToken(const nsIParserNode * 0x02f17460) line 1763 + 12
bytes
CNavDTD::OpenContainer(const nsIParserNode * 0x02f17460, nsHTMLTag
eHTMLTag_script, int 1, int -1) line 2756 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x0235cb60, nsHTMLTag eHTMLTag_script,
nsIParserNode * 0x02f17460) line 1020 + 20 bytes
CNavDTD::HandleStartToken(CToken * 0x0235cb60) line 1324 + 22 bytes
CNavDTD::HandleToken(CNavDTD * const 0x02ed41c0, CToken * 0x01a18560, nsIParser
* 0x02f0ada0) line 732 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x02ed41c0, nsIParser * 0x02f0ada0,
nsITokenizer * 0x02ed4480, nsITokenObserver * 0x00000000, nsIContentSink *
0x02f0d930) line 529 + 20 bytes
nsParser::BuildModel() line 1030 + 34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 956 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x02f0ada4, nsIChannel * 0x02f1d6e0,
nsISupports * 0x00000000, nsIInputStream * 0x02f0a038, unsigned int 0, unsigned
int 1731) line 1306 + 19 bytes
nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x02f18f80,
nsIChannel * 0x02f1d6e0, nsISupports * 0x00000000, nsIInputStream * 0x02f0a038,
unsigned int 0, unsigned int 1731) line 1177 + 43 bytes
nsChannelListener::OnDataAvailable(nsChannelListener * const 0x02f1e860,
nsIChannel * 0x02f1d6e0, nsISupports * 0x00000000, nsIInputStream * 0x02f0a038,
unsigned int 0, unsigned int 1731) line 1364
nsFileChannel::OnDataAvailable(nsFileChannel * const 0x02f1d6e4, nsIChannel *
0x02f0ccb0, nsISupports * 0x00000000, nsIInputStream * 0x02f0a038, unsigned int
0, unsigned int 1731) line 471
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x02f0c650)
line 417
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x02f0c880) line 173 + 12 bytes
PL_HandleEvent(PLEvent * 0x02f0c880) line 537 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01012480) line 498 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x003603ea, unsigned int 49449, unsigned int 0,
long 16852096) line 972 + 9 bytes
USER32! 77e71820()
01012480()

Here is the C++ code:
NS_IMETHODIMP
nsMsgFolder::GetVisibleSubFolders(nsIEnumerator* *result)
{
  nsresult rv;
  nsCOMPtr<nsISupportsArray> vFolders;
  rv = nsFilterBy(mSubFolders, nsCanBeInFolderPane, nsnull,
getter_AddRefs(vFolders));
  if (NS_FAILED(rv)) return rv;
  rv = vFolders->Enumerate(result);
  return rv;
}
Assignee: phil → putterman
QA Contact: lchiang → ppandit
Assign QA Contact to ppandit
Assign bug to putterman for inital review
Target Milestone: M15
I don't even know if we are supporting this.
Status: NEW → ASSIGNED
Target Milestone: M15 → M20
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
Par, is this still valid? 
Yes the bug is still valid.
Load the (rewritten) testcase from this bug report within mozilla.
==> You should get a crash.

Par
It's only valid in the sense that actually calling the function crashes.  It's 
not being called from anywhere nor is it meant to be called from anywhere.  
Basically this function should be removed from the idl and implementation.  It 
was one of those functions that was ported over a long time ago when we first 
started working on the project but doesn't fit into this project anymore and it 
was forgotten and should just be cleaned up.  The fact that this crashes won't 
affect the product as it currently stands.
moving to future milestone.
Target Milestone: M20 → Future
Putterman, I don't crash on the testcase. Can you still reproduce this?
I'm not set up to try this right now, but if we don't crash, let's just mark
worksforme.
Marking to worksforme per putterman. Wanna verify too?
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
QA Contact: ppandit → stephend
Worksforme using builds:

2001-07-19-13 Windows 2000, Mac OS 9.1 and RedHat 7.1

VERIFIED wfm.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.