Closed Bug 69949 Opened 24 years ago Closed 24 years ago

Crash in nsCOMPtr<nsIStreamObserver>::assign_with_AddRef

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: andreas.koenig, Assigned: dougt)

Details

(Keywords: crash) 

Build: dfrom CVS as of today
Reproducable: yes

After I built mozilla from CVS today, it didn't startup with the error:

Finished reading in bookmarks.html  (561291 microseconds)
WEBSHELL+ = 3
Enabling Quirk StyleSheet
### ERROR, cannot create a search session. TypeError:
Components.classes[searchSession] has no properties
Enabling Quirk StyleSheet
zsh: exit 139   ./mozilla


I removed my ~/.mozilla directory and retried, Mozilla rebuilt ~/.mozilla from
~/.netscape and failed with the same error.
bad
Severity: normal → blocker
Keywords: crash, smoketest
Confirming, since the shrike tinderbox is crashing with the same error.
Status: UNCONFIRMED → NEW
Ever confirmed: true
a lot of checkins could have affected this: see
http://bonsai.mozilla.org/cvsquery.cgi?branch=HEAD&file=mozilla/xpfe/components/search/&date=week
for the complete list.
The most interesting one is from blakeross. CC'ing him.
The "ERROR, cannot create a search session" message is showing up on all
tinderboxes, whether or not they are crashing.  It and the crash are probably
separate issues, and perhaps this bug should only cover one of them.
The error messages started between 19:16 (nebiros tinderbox) and 19:36 (genoa
tinderbox) which means they were probably caused by blakeross's 19:27-19:31
checkin.

The crashes are occurring only on shrike and nebiros tinderboxes and seem to be
caused by checkins between 4:31 and 8:10.  The only such checkins claiming (!)
to be part of the build were by rbs.
Does anybody have a stack trace for the crash?

(And how should we split this bug?)
SearchSession problem has been fixed. Not sure about the crash, I don't think 
that's mine.
can anyone reproduce a startup crash with the release builds? if not, this needs 
to have it's severity reduced, or at least have the smoketest keyword removed.
I do not see this crash with release verification linux build 2001022308 on
RedHat6.2
The crash problem may just be a clobber issue related to the search session
problem.  My clobber build crashed the first time I hit that problem last night
but when I ran the browser again, the crash went away.
Likely a clobber problem as my changes have nothing to do with session history.
There were some change of #define in nsIFrame.h/nsHTMLParts.h, e.g, 0x01000
becoming 0x10000, so clobber would bring such #define back in sync in case
depend didn't catch them.
Could somebody get a stack trace for this crash?   That may involve actually
debugging on the shrike tinderbox, but it sure would be nice to know what the
problem is here. 
Here is a backtrace of the crash:

(gdb) bt
#0  _dl_debug_state () at dl-debug.c:56
#1  0x40442a50 in _dl_open (
    file=0x81fe688
"/home/k/bin/moz/mozilla-20010205/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so",
mode=14, caller=0x81feac0)
    at dl-open.c:250
#2  0x403013d3 in dlopen_doit (a=0xbfffefc8) at dlopen.c:41
#3  0x4000ac3b in _dl_catch_error (errstring=0x806b158, 
    operate=0x403013a8 <dlopen_doit>, args=0xbfffefc8) at dl-error.c:141
#4  0x403018b9 in _dlerror_run (operate=0x403013a8 <dlopen_doit>, 
    args=0xbfffefc8) at dlerror.c:125
#5  0x40301393 in __dlopen_check (
    file=0x81fe688
"/home/k/bin/moz/mozilla-20010205/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so",
mode=1) at dlopen.c:53
#6  0x402b912a in pr_LoadLibraryByPathname (
    name=0x81fe688
"/home/k/bin/moz/mozilla-20010205/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so",
flags=1) at prlink.c:740
#7  0x402b8fef in PR_LoadLibraryWithFlags (libSpec={
      type = PR_LibSpec_Pathname, value = {
        pathname = 0x81fe688
"/home/k/bin/moz/mozilla-20010205/mozilla/dist/bin/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so",
mac_named_fragment = {
          fsspec = 0x81fe688, name = 0x4181a2f4 "rel:libgkplugin.so"}, 
        mac_indexed_fragment = {fsspec = 0x81fe688, index = 1099014900}}}, 
    flags=1) at prlink.c:448
#8  0x41803713 in nsPluginFile::LoadPlugin (this=0xbffff0a4, 
    outLibrary=@0xbffff0a0) at nsPluginsDirUnix.cpp:199
#9  0x417fa393 in nsPluginHostImpl::ScanPluginsDirectory (this=0x81f71a8, 
    pluginsDir=@0xbffff124, compManager=0x806c0f0, layoutPath=0x81f7720, 
    checkForUnwantedPlugins=0) at nsPluginHostImpl.cpp:3261
#10 0x417fa732 in nsPluginHostImpl::LoadPlugins (this=0x81f71a8)
    at nsPluginHostImpl.cpp:3349
#11 0x417f9daa in nsPluginHostImpl::FindPluginEnabledForType (this=0x81f71a8, 
    aMimeType=0x417c43b6 "application/x-java-vm", aPlugin=@0xbffff1b0)
    at nsPluginHostImpl.cpp:3070
#12 0x417f9ed0 in nsPluginHostImpl::GetPluginFactory (this=0x81f71a8, 
    aMimeType=0x417c43b6 "application/x-java-vm", aPlugin=0xbffff210)
    at nsPluginHostImpl.cpp:3112
#13 0x417b1c86 in nsJVMManager::StartupJVM (this=0x81f1580)
    at nsJVMManager.cpp:602
#14 0x417b2199 in nsJVMManager::MaybeStartupLiveConnect (this=0x81f1580)
    at nsJVMManager.cpp:778
#15 0x417b293e in nsJVMManager::StartupLiveConnect (this=0x81f1580, 
    runtime=0x810fab0, outStarted=@0xbffff2ac) at nsJVMManager.h:128
#16 0x40671d76 in nsJSEnvironment::nsJSEnvironment (this=0x81f5f28)
    at nsJSEnvironment.cpp:1505
#17 0x40671966 in nsJSEnvironment::GetScriptingEnvironment ()
    at nsJSEnvironment.cpp:1446
#18 0x4067215d in NS_CreateScriptContext (aGlobal=0x815b718, 
    aContext=0x815d558) at nsJSEnvironment.cpp:1545
#19 0x40e98df6 in nsDocShell::EnsureScriptEnvironment (this=0x815d4a8)
    at nsDocShell.cpp:4372
#20 0x40e9a16b in nsWebShell::GetInterface (this=0x815d4a8, aIID=@0x405f9f34, 
    aInstancePtr=0xbffff474) at nsWebShell.cpp:327
#21 0x40138aba in nsGetInterface::operator() (this=0xbffff4fc, 
    aIID=@0x405f9f34, aInstancePtr=0xbffff474) at nsIInterfaceRequestor.cpp:37
#22 0x405e1b38 in nsCOMPtr<nsIDOMWindowInternal>::assign_from_helper (
    this=0xbffff508, helper=@0xbffff4fc, aIID=@0x405f9f34)
---Type <return> to continue, or q <return> to quit---
    at ../../../dist/include/nsCOMPtr.h:970
#23 0x405e65f2 in nsCOMPtr<nsIDOMWindowInternal>::nsCOMPtr (this=0xbffff508, 
    helper=@0xbffff4fc) at ../../../dist/include/nsCOMPtr.h:551
#24 0x405cae76 in nsAppShellService::GetHiddenWindowAndJSContext (
    this=0x80b9668, aWindow=0xbffff564, aJSContext=0xbffff560)
    at nsAppShellService.cpp:723
#25 0x405c92ba in nsAppShellService::SetXPConnectSafeContext (this=0x80b9668)
    at nsAppShellService.cpp:191
#26 0x405c9724 in nsAppShellService::CreateHiddenWindow (this=0x80b9668)
    at nsAppShellService.cpp:247
#27 0x805657b in main1 (argc=1, argv=0xbffff7f4, nativeApp=0x0)
    at nsAppRunner.cpp:951
#28 0x805746a in main (argc=1, argv=0xbffff7f4) at nsAppRunner.cpp:1270


I removed the java2 directory now and still have a crash. Will take some time to
create the next stack trace.
After manually removing dust that was left over from my failed attempt to get
JRE running (compare bug 66840), I get this stack trace. I change the Subject
line because the old one ("ERROR, cannot create a search session") was
apparently not related to the crash.

Program received signal SIGSEGV, Segmentation fault.
0x40cfc433 in nsCOMPtr<nsIStreamObserver>::assign_with_AddRef (this=0x83cb95c, 
    rawPtr=0xbffff168) at ../../../../dist/include/nsCOMPtr.h:961
961           NSCAP_ADDREF(this, rawPtr);
(gdb) bt
#0  0x40cfc433 in nsCOMPtr<nsIStreamObserver>::assign_with_AddRef (
    this=0x83cb95c, rawPtr=0xbffff168)
    at ../../../../dist/include/nsCOMPtr.h:961
#1  0x40d0a44b in nsCOMPtr<nsIStreamObserver>::operator= (this=0x83cb95c, 
    rhs=0xbffff168) at ../../../../dist/include/nsCOMPtr.h:582
#2  0x40c8a3ea in nsStreamIOChannel::SetListener (this=0x83cb920, 
    listener=0xbffff168) at nsInputStreamChannel.h:81
#3  0x40c89963 in nsStreamIOChannel::AsyncOpen (this=0x83cb920, 
    listener=0xbffff168, ctxt=0x40f22ce0) at nsInputStreamChannel.cpp:293
#4  0x40f50d43 in nsSecureBrowserUIImpl::OnStateChange (this=0x42679070, 
    aWebProgress=0x4263e1ac, aRequest=0x83cb920, aProgressStateFlags=65552, 
    aStatus=0) at nsSecureBrowserUIImpl.cpp:352
#5  0x40efdb2f in nsDocLoaderImpl::FireOnStateChange (this=0x4263e198, 
    aProgress=0x4263e1ac, aRequest=0x83cb920, aStateFlags=65552, aStatus=0)
    at nsDocLoader.cpp:1308
#6  0x40efc4da in nsDocLoaderImpl::doStopURLLoad (this=0x4263e198, 
    request=0x83cb920, aStatus=0) at nsDocLoader.cpp:701
#7  0x40efbf86 in nsDocLoaderImpl::OnStopRequest (this=0x4263e198, 
    request=0x83cb920, aCtxt=0x0, aStatus=0, aMsg=0x401adbd0)
    at nsDocLoader.cpp:551
#8  0x40c882f2 in nsLoadGroup::RemoveRequest (this=0x4263e228, 
    request=0x83cb920, ctxt=0x0, aStatus=0, aStatusArg=0x401adbd0)
    at nsLoadGroup.cpp:518
#9  0x40c8a231 in nsStreamIOChannel::OnStopRequest (this=0x83cb920, 
    request=0x420779ec, context=0x0, aStatus=0, aStatusArg=0x401adbd0)
    at nsInputStreamChannel.cpp:475
#10 0x40c7a421 in nsOnStopRequestEvent::HandleEvent (this=0x8368118)
    at nsStreamObserverProxy.cpp:177
#11 0x40c7a160 in nsStreamObserverEvent::HandlePLEvent (aEvent=0x8368118)
    at nsStreamObserverProxy.cpp:77
#12 0x4012976e in PL_HandleEvent (self=0x8368118) at plevent.c:576
#13 0x4012958c in PL_ProcessPendingEvents (self=0x80af8f0) at plevent.c:509
#14 0x4012b4b9 in nsEventQueueImpl::ProcessPendingEvents (this=0x80af8c8)
    at nsEventQueue.cpp:361
#15 0x407eddc4 in event_processor_callback (data=0x80af8c8, source=7, 
    condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#16 0x407ed9ff in our_gdk_io_invoke (source=0x8220358, condition=G_IO_IN, 
    data=0x8236bc8) at nsAppShell.cpp:58
#17 0x409ab47a in g_io_unix_dispatch (source_data=0x8220370, 
    current_time=0xbffff540, user_data=0x8236bc8) at giounix.c:135
#18 0x409ac9b6 in g_main_dispatch (dispatch_time=0xbffff540) at gmain.c:656
#19 0x409acf71 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#20 0x409ad0e9 in g_main_run (loop=0x82203b8) at gmain.c:935
#21 0x408dccda in gtk_main () at gtkmain.c:476
#22 0x407ee4ba in nsAppShell::Run (this=0x80b26d0) at nsAppShell.cpp:350
#23 0x405c9fc4 in nsAppShellService::Run (this=0x80b9668)
    at nsAppShellService.cpp:407
#24 0x8056773 in main1 (argc=1, argv=0xbffff7f4, nativeApp=0x0)
    at nsAppRunner.cpp:978
#25 0x805746a in main (argc=1, argv=0xbffff7f4) at nsAppRunner.cpp:1270
Summary: ERROR, cannot create a search session → Crash in nsCOMPtr<nsIStreamObserver>::assign_with_AddRef
Are you sure your PSM build is in sync with the rest of your build?  (What does
line 352 of extensions/psm-glue/src/nsSecureBrowserUIImpl.cpp say in your tree?)
No, my PSM sources are not up-to-date. Will fix that now (wouldn't it be nice if
that happened automatically?).

line 352 reads:
     channel->GetNotificationCallbacks(getter_AddRefs(requestor));

could you do a clobber build at least for the psm directory, and report back if 
you still crash?

With the magic
  gmake -f client.mk pull_all
  gmake -f client.mk build_all
  gmake -f client.mk pull_all BUILD_MODULES=psm
  gmake -f client.mk build_all BUILD_MODULES=psm

I got rid of the crash. Does that mean that once you have built with PSM you
have to go through all 4 commands every time? Or is that just an accident today?

this was probably a result of dougt's major rewrite of network.  i would think 
that you can make clean (from somewhere) instead of building psm if you want to 
stop using it.

this doesn't belong to search.
Assignee: matt → dougt
Severity: blocker → major
Component: Search → Networking
Keywords: smoketest
QA Contact: claudius → tever
wfm per reporter
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.