49414 - On my machine, the app crashes on exit every single time. [@ OleRegisterMgr::~OleRegisterMgr() line 111]

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P2)

Description

[selmer (gone)]

Commercial 2000-081708-M18 (and at least yesterday's build too, possibly more)
NT 4.0.

Launch browser w/AIM autologin.  Close app.

Get dialog about referencing location 0xffffffff and sometimes other addresses
like 0x000000014.  No talkback report because it doesn't come up in this case.

Comment 1

[selmer (gone)]

Adding crash keyword, nominating nsbeta3.

Comment 2

[Asa Dotzler [:asa]]

[e-mail] can you try to reproduce this in a mozilla build.  I am
unable to repro with 081708 mozilla build on NT or win2K.  It might help us
narrow it down if you tried on mozilla and could not reproduce it.

Comment 3

[selmer (gone)]

Will look at this w/mozilla on Monday.  Disambiguating summary.

Comment 4

[selmer (gone)]

Using today's 82313-m18 build with a brand new (but not activated) profile, I
still get the same crash on exit.  Sorry, didn't get to trying a mozilla build
yet...

Comment 5

[leger]

*** Bug 49998 has been marked as a duplicate of this bug. ***

Comment 6

[leger]

selmer, I just searched for a talkback under your name for this issues, and 
cannot find one.  Can you reproduce, send in a Talkback, and get stack trace 
data in this bug please?  Thanks!

Comment 7

[selmer (gone)]

Jan, talkback doesn't come up for this hence no talkback reports on it.  I need 
to get a debug build and see if it repros there (for some reason, I haven't had 
a debug build on my machine for a long time ;^)

Comment 8

[johng]

nav triage team:
recommend nsbeta3- because no one can reproduce, no stack trace, etc.
reassigning to selmer, y'all decide

Comment 9

[Curtis Williams]

Since 49998 was marked as a duplicate of this bug, I can provide a talkback.  
I've just sent one in with [e-mail] and TalkBack ID TB16255662Q as 
the ID number.  Good luck!

Comment 10

[selmer (gone)]

On my Win98 machine I also crash every time.  I have talkback IDs for that
machine: TB16291275H and TB16246741Z.

Comment 11

[selmer (gone)]

There is talkback in this bug now.  Back to you.

Comment 12

[johng]

nav triage team:
nsbeta3+
setting as P2 because we don't know how many users run into this problem.
Won't P1 it without a reproducable test case....

Comment 13

[selmer (gone)]

The Win98 crashes went away after I fixed my prefs.  My prefs had been pointing
various directories into a non-existent profile area from back in the old days
when it went into the build directory.  Fixing those to point into my actual
profile corrected this problem on that machine.

Unfortunately, I did not have a similar situation on my NT box.  All directories
appear to be correct and valid on my NT.  This is the machine where I don't get
talkback reports.

Comment 14

[Bill Law]

No cycles for this one unless we can reproduce it with a debug build.

Steve, can you try running somebody's debug build and see if you can reproduce 
it?  The stack trace would likely reveal what's happened.  It also isn't likely 
an xpapps bug anyway.  Maybe we could give it to somebody less doomed (but they 
won't likely do anything either unless we can recreate it in the laboratory).

Comment 15

[selmer (gone)]

Using 9/12 mozilla build, I can reproduce this.  Here is *a* stack trace I got, 
but I'm not sure I believe this one.

DIMM! 642090db()
USER32! 77e7e21c()
USER32! 77e71982()
NTDLL! 77f763a3()
OleRegisterMgr::~OleRegisterMgr() line 111
$E20() + 42 bytes
_CRT_INIT(void * 0x01c60000, unsigned long 0, void * 0x00000001) line 236
_DllMainCRTStartup(void * 0x01c60000, unsigned long 0, void * 0x00000001) line 
289 + 17 bytes
NTDLL! 77f69dca()
KERNEL32! 77f19ffb()
doexit(int 0, int 0, int 0) line 392
exit(int 0) line 279 + 13 bytes
mainCRTStartup() line 345
KERNEL32! 77f1ba06()

When I ran without the debugger, I got this message on the console: "###!!! 
ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 0', file 
d:\5\mozilla\xpcom\build\nsXPComInit.cpp, line 667" and then the memory 
exception followed very quickly.

In the debugger, I had to wade through a whole series of assertions but never 
made it to this one before ending up back in the debugger.  I think the message 
about component manager is more likely relevant.

Comment 16

[selmer (gone)]

Cleared up a lot of the assertions, I had a bogus news server defined.  It seems
that whether or not the component manager assertion comes before or after the
crash is slightly random.  I've had the crash happen first a couple times now.
(Or maybe getting rid of those assertions changed things.)

Anyway, now I believe the stack trace and I'm wondering if there's some
configuration on my machine that might be involved.

Any suggestions?

Comment 17

[Bill Law]

I have no idea what's going on.

I see the "component manager being held past xpcom shutdown" assertion now and 
again.  I always attributed it to bad karma.  I usually say "ignore" (and 
sometimes it crashes?) or just "Abort" 'cause it's faster.

I've seen that stack before, too, it seems.  Funny thing is that there's doesn't 
seem to be any Mozilla code in there.  It's all VC++ runtime stuff.

Comment 18

[selmer (gone)]

Could it be due to some configuration on my machine?  Is it possible we're using
the compiler in a way that brings us here even without explicit calls in the app?

Comment 19

[scalkins]

*** Bug 52836 has been marked as a duplicate of this bug. ***

Comment 20

[scalkins]

cc myself.
I see this every time on my Winnt spk5 system, running commercial release builds
up to today (2000-09-18-08M18) I always run installer. I saw it consistently on
a co-workers system with Win 2000 spk1 also.It also occured fo me if I launch
-Aim or -mail and simply exit those apps.
Note, when I exit the app with the same build at home (on dialup 56k line) I
won't crash. It's only on the builds on the lan at work that this crash occurs.
The only other diff from the builds at home is I run a custom install to save
some time. I installed Browser, mail, talkback and IM, with no language paks or
java at home.

Comment 21

[Erik van der Poel]

I get the same stack trace as selmer above. I'm using NT 4.0, build 1381, SP3,
with MSIE 5.00.2919.6307 installed.

Comment 22

[Jay Patel [:jay]]

Adding topcrash keyword...this is a topcrasher according to talkback data. [@ 
0x00000040 - nsQueryInterface::operator()]  The stacktrace from bug 52836 is the 
same as those in the latest talkback reports.  Here are some entries and a 
stacktrace:

0x00000040 19671430
         line 
        Build: 2000091506 CrashDate: 2000-09-15 UptimeMinutes: 2  Total: 151 
        OS: Windows NT  4.0 build 1381
        URL: 
        Comment: Crash exiting browser...aim is in sidebar logged in Win32 
2000-09-15-06M18
        Stacktrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=17493406

    0x00000040 19671430
         line 
        Build: 2000091506 CrashDate: 2000-09-15 UptimeMinutes: 0  Total: 151 
        OS: Windows NT  4.0 build 1381
        URL: 
        Comment: Crash exiting browser
        Stacktrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=17493984

    0x00000040 19671430
         line 
        Build: 2000091506 CrashDate: 2000-09-15 UptimeMinutes: 0  Total: 152 
        OS: Windows NT  4.0 build 1381
        URL: 
        Comment: crash exiting aim
        Stacktrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=17495798

0x00000040 19671430
         line 
        Build: 2000091506 CrashDate: 2000-09-15 UptimeMinutes: 115  Total: 149 
        OS: Windows NT  4.0 build 1381
        URL: 
        Comment: crash exiting seamonkey Win32 2000-09-15-06M18
        Stacktrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=17493226

0x00000040 f12e5c88
         line 
        Build: 2000091508 CrashDate: 2000-09-17 UptimeMinutes: 16  Total: 16 
        OS: Windows 98  4.10 build 67766446
        URL: 
        Comment: closing the app! arf arf arf
        Stacktrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=17534744

Stack trace from a crash with build 2000091508:
Incident ID 17534744 
0x00000040 
DoPostScriptEvaluated 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 
68] 
nsXPCWrappedJSClass::CallMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 
1180] 
nsXPCWrappedJS::CallMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 319] 
PrepareAndDispatch 
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp, 
line 102] 
SharedStub 
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp, 
line 125] 

Comment 23

[John Bandhauer]

The stuf in the talkback reports is almost certainly a dup of 52940 which I just 
fixed. It would have failed in different places depending randomly on how soon 
the free'd memory was recycled.

I don't know about this OleRegisterMgr::~OleRegisterMgr() business.

The first run only asserts in Component Manager are annoying but harmless. We 
just don't have shutdown order under very good control.

I'd vote for just marking this a dup of 52940. But if there is something here 
you want to preserve separately then fine by me.

Comment 24

[selmer (gone)]

I have never gotten talkback to come up when hitting this problem.  The
OleRegister cruft is really what's in my stack trace.  I don't think the stuff
jpatel added belongs in this bug and I don't think this is a dup of 52940.
Please don't dup/close this bug unless you can verify it.

Has anyone who gets the OleRegister stack ever seen talkback come up for it?

Comment 25

[John Bandhauer]

selmer, I gotcha. Maybe you should change the subject line back to what it was 
or to mention "OleRegisterMgr::~OleRegisterMgr()" or the aim angle if 
appropriate. The addition to the subject that jpatel made threw me.

Comment 26

[selmer (gone)]

Changing summary to reflect OleRegister stack.  Please take other stacks
elsewhere :-)

Comment 27

[Erik van der Poel]

When the OleRegisterMgr thing happens to me, I don't get Talkback.

Comment 28

[verah (gone)]

Nav triage team: Minusing this because we can't reproduce consistently; however, 
this problem will be addressed... and addressed again... and again...

Comment 29

[Frank Tang]

DIMM.DLL is related to Active IME. See 
http://msdn.microsoft.com/workshop/misc/AIMM/reference/objects/CActiveIMM.asp

It seems DIMM.DLL is not installed by default NT4/95/98 installation. You 
probably need to download the ActiveIME to reproduce it.
add kato-san, yokoyama, and shanjian  to the cc list.
you may need to install some Active IME to reproduce this. For Netscape people, 
you can find the active IME we put in the internal place in 
http://blues/users/bobj/publish/MS%205.01%20LangPacks/

I believe anyone of these have dimm.dll in it.

Comment 30

[selmer (gone)]

I uninstalled the IME and rebooted and now I don't crash on exit anymore.
Thanks for the info!

Would a release note suffice for this?  (Crashing when you were exiting anyway...)

Comment 31

[Jay Patel [:jay]]

Sorry for the confusion, but if my info from 9/18 isn't related to this bug, why 
is bug 52836 marked a dup of this one?  Please point me to the right place or 
let me know if i should log a new bug for the crash involving 
nsQueryInterface::operator().  Thanks.

Comment 32

[Bill Law]

We have a fix, reportedly, reassigning.

Comment 33

[Shanjian Li]

I reproduced the bug on mozilla with NT4, it is very annoying. After I 
compared the implementation with mine for 4.x, I found the problem is 
caused by a missing function call before release AIMM. here is the diff:

Index: nsToolkit.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/windows/nsToolkit.cpp,v
retrieving revision 3.12
diff -c -r3.12 nsToolkit.cpp
*** nsToolkit.cpp       2000/04/26 06:22:21     3.12
--- nsToolkit.cpp       2000/09/21 21:02:59
***************
*** 189,194 ****
--- 189,195 ----

      if (!nsToolkit::gAIMMCount) {
          if(nsToolkit::gAIMMApp) {
+             nsToolkit::gAIMMApp->Deactivate();
              nsToolkit::gAIMMApp->Release();
              nsToolkit::gAIMMApp = NULL;
          }

Comment 34

[Shanjian Li]

remove nsbeta3- in status whiteboard.

My fix is simple and straitforward. Same implementation for 4.x has been 
working for several months. I strongly recommend to check in this fix.

Comment 35

[Frank Tang]

make sense, check it in.

Comment 36

[Frank Tang]

r/a=ftang

Comment 37

[Shanjian Li]

fix checked in.

Comment 38

[sairuh (rarely reading bugmail)]

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]