Closed Bug 328428 Opened 20 years ago Closed 20 years ago

talkback causes (VC8) build to crash [@ ntdll.dll]

Categories

(Core Graveyard :: Talkback Client, defect)

Product:
Core Graveyard
Component:
Talkback Client
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: Peter6, Assigned: jay)

References

Details

(Keywords: crash)

Crash Data

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060223 Firefox/1.6a1 ID:2006022323 - Cairo build repro: just browse and crash TB15532030H TB15533279M TB15535442W Incident ID: 15532030 Stack Signature ntdll.dll + 0x4d989 (0x77fcd989) 61b73c38 Product ID FirefoxTrunk Build ID 2006022308 Trigger Time 2006-02-23 10:53:32.0 Platform Win32 Operating System Windows NT 5.0 build 2195 Module ntdll.dll + (0004d989) URL visited User Comments crash while switching tabs (cairo build) Since Last Crash 27 sec Total Uptime 27 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace ntdll.dll + 0x4d989 (0x77fcd989) ntdll.dll + 0x4b80c (0x77fcb80c) FULLSOFT.DLL + 0xf625 (0x01cbf625) FULLSOFT.DLL + 0x10cf7 (0x01cc0cf7) FULLSOFT.DLL + 0xed36 (0x01cbed36) FULLSOFT.DLL + 0xedb2 (0x01cbedb2) ntdll.dll + 0x806c (0x77f8806c) ntdll.dll + 0xaa67 (0x77f8aa67) KERNEL32.dll + 0x2ba3c (0x7c59ba3c) MSVCR80.dll + 0x298e (0x6021298e) MSVCR80.dll + 0x2a36 (0x60212a36)
Severity: normal → major
Whiteboard: cairo
hrm, those stacks suck. wonder if our talkback stacks are busted...
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060224 Firefox/1.6a1 ID:2006022400 TB15543701Q TB15543702K TB15559571K The odd thing is, talkback pops up, I fill in the form and send it. After that I can still browse for at least 20 seconds before Firefox simply closes it self.
after testing lots of startups I'd say this is a crash on start (with delay). If the browser runs for a few minutes it's not likely crashing anymore. Furthermore, my initial set of tabs does not require the startup of any plugin , they're all plain pages like mozillazine, bugzilla, tinderboxen and Gmail
Severity: major → critical
Keywords: crash
sofar all attempts to narrow this down to anything have failed. - Nothing shows up in javascript-/error-console (monitoring strict/chrome msgs) - No unusual spikes in taskmanager - Nothing unexpected shows in the nspr.log while crashing in "leakmode"
After i've downloaded a new build and close it once it has be opened I sometimes get a windows alert box with the following message: The instruction at "0x77fcb333" referenced memory at "0x00000000". The memory could not be "written" Click on OK to terminate the program. (I don't know if this is related to the crash)
Another data point (sucky stack): TB15786105Q
The crash does not occur in a non-cairo build The crash does not occur in -safe-mode The crash does occur with extensions disabled (how different can this be from -safemode) I reconstructed my whole profile, but can't get rid of the crash extensions used: DOM Inspector 1.9a1 Talkback 1.6a1 Adblock Plus 0.6.1.1 Cookie Button 0.8.4 Tab Sidebar 2.0a1.rev543 Nightly Tester Tools 0.8b2.rev533 JavaScript Options 1.2.4.rev431 Console² 0.3.3
Right, gotcha, kindof I use ChatZilla-xulrunner from http://thumper.kicks-ass.org/wordpress/chatzilla-on-xulrunner/ and I only crash the Firefox-cairo build if ChatZilla is running without it, no crashes anymore
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060308 Firefox/1.6a1 ID:2006030803 (cairo-enabled, places-enabled) Dunno about that peter. I get these crashes regularly (TB16086928Q being the latest), and I don't use Chatzilla. I use a few of the same extensions as you tho (Dom, Talkback, NTT, Console²).
(In reply to comment #9) > Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060308 > Firefox/1.6a1 ID:2006030803 (cairo-enabled, places-enabled) > > Dunno about that peter. I get these crashes regularly (TB16086928Q being the > latest), and I don't use Chatzilla. I use a few of the same extensions as you > tho (Dom, Talkback, NTT, Console²). > For me, if i don't run the installer CX-xulrunner (or the older one i still have) the crashes are gone. Run CZ xulrunner and I crash 20-30 times per day
offcouse I crashed right after my last post , with CZ NOT enabled :-(
after discussion on moz forums, this is defenitly win2k-only
Summary: random crash while browsing [@ ntdll.dll] → random crash while browsing, win2k-only [@ ntdll.dll]
Is this really the bug of cairo build? The official non-cairo build doesn't use MSVCR80.dll. Because it's built by VC++6. # I cannot reproduce this bug with CVS debug build that is built by VC++.net(7.1).
(In reply to comment #13) > Is this really the bug of cairo build? The official non-cairo build doesn't use > MSVCR80.dll. Because it's built by VC++6. > # I cannot reproduce this bug with CVS debug build that is built by > VC++.net(7.1). > probably not. I have a VC8 debug build at(In reply to comment #13) > Is this really the bug of cairo build? The official non-cairo build doesn't use > MSVCR80.dll. Because it's built by VC++6. > # I cannot reproduce this bug with CVS debug build that is built by > VC++.net(7.1). > I uploaded a VC8 debug build if you'd like to try (it's a bit out of my league). http://pvanderwoude.com/firefox_30_20060311_debug_build.zip
Cannot this reproduce with non-cairo VC8 build?
(In reply to comment #15) > Cannot this reproduce with non-cairo VC8 build? > Only happens with a cairo enabled VC8 build, the non-cairo one shows no signs of problems. (thanks to Mossop for providing those builds)
> MSVCR80.dll + 0x298e (0x6021298e) > MSVCR80.dll + 0x2a36 (0x60212a36) These addresses are in _endthreadex function. Thread synchronization problem? Can you reproduce this when autoupdate is disabled?
(In reply to comment #17) > Can you reproduce this when autoupdate is disabled? I just crashed again with autoupdate disabled, talkback ID: TB16357708K
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060314 Firefox/1.6a1 ID:2006031409 [cairo] No, still crashes with "automatically check for updates" for all 3 options disabled. TB16363465H (same stacktrace as before)
Flags: blocking1.9a1?
Im pretty sure ive been having this crash at school on a zip build ive been downloading. This installation has absolutely nothing but flashplayer and acrobat reader plugins installed. I can't submit talkback reports because its blocked in the schools firewall :(
I get the same here, however, I'm on a Mac. Browser just randomly closes when closing or switching tabs. It happens a different times, I can surf for 30mins fine, or sometimes 20secs. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060317 Firefox/1.6a1 ID:0000000000
(In reply to comment #21) > I get the same here, however, I'm on a Mac. > > Browser just randomly closes when closing or switching tabs. It happens a > different times, I can surf for 30mins fine, or sometimes 20secs. > > Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060317 > Firefox/1.6a1 ID:0000000000 No mozilla-released Mac builds are built with cairo gfx (and the current state of cairo gfx + cocoa widgets isn't such that you can actually use it for real browsing); so, that's a different bug, unrelated to this.
This may well be a VC8 issue Vlad. The latest trunk builds haven't got DOMi and Talkback enabled and they don't crash. I narrowed the problem down to Talkback. If I leave it disabled , FF won't crash anymore.
(In reply to comment #23) > This may well be a VC8 issue Vlad. You said this did't happen with non-cairo VC8 build in comment #16. Is it also talkback disabled? > The latest trunk builds haven't got DOMi and Talkback enabled and they don't > crash. > I narrowed the problem down to Talkback. > If I leave it disabled , FF won't crash anymore. You said the crash occured with extensions disabled in comment #7. Don't you count talkback in extensions? How did you disable talkback?
yeah, sorry for that The crash does not occur in -safe-mode (alll extensions are disabled) The crash does occur with extensions disabled (how different can this be from -safemode) (all but DOMi and Talkback are disabled) I have DOMi enabled and Talkback disabled and the crash w/i the first few minutes after startup is definitly gone I'm changing the summary, I'm not sure what Product/Component should be
Summary: random crash while browsing, win2k-only [@ ntdll.dll] → talkback causes (VC8) build to crash , win2k-only [@ ntdll.dll]
Component: GFX: Thebes → Talkback Client
Whiteboard: cairo
Assignee: nobody → jay
QA Contact: thebes → chofmann
wondering if the talkback glue code and client binary have been re-built under vc8. I'm guessing glue code yes and client not. preed, any thoughts? That would be something to check out and try to fix this.
here is a query to ~1000 crash reports with fullsoft.dll in the top five frames of the stack. scroll down to see the ntdll.dll crashes that are talked about in this bug... http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stack&match=contains&searchfor=fullsoft.dll&vendor=MozillaOrg&product=FirefoxTrunk&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=stack It doesn't appear that this problem is exclusively win2k... There are plenty of reports showing XP with similar stack traces like this one http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=17383753 FirefoxTrunk Build ID 2006032404 Trigger Time 2006-04-10 03:15:32.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module ntdll.dll + (0000215c) URL visited <a href='http://www.security.nnov.ru/soft/3proxy/doc/html/man3/3proxy.cfg.3.html'>http://www.security.nnov.ru/soft/3proxy/doc/html/man3/3proxy.cfg.3.html</a> User Comments Reading the url mentioned. Some scroll - oops... Since Last Crash 1071 sec Total Uptime 10313 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace ntdll.dll + 0x215c (0x77f5215c) ntdll.dll + 0x1fbf (0x77f51fbf) FULLSOFT.DLL + 0xf625 (0x01c1f625) FULLSOFT.DLL + 0x10cf7 (0x01c20cf7) FULLSOFT.DLL + 0xed36 (0x01c1ed36) FULLSOFT.DLL + 0xedb2 (0x01c1edb2) ntdll.dll + 0x2e3aa (0x77f7e3aa) ntdll.dll + 0x7b78 (0x77f57b78) kernel32.dll + 0x13c87 (0x77e73c87) MSVCR80.dll + 0x298e (0x6021298e) MSVCR80.dll + 0x2a36 (0x60212a36) and this one http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=17158649 Windows NT 5.1 build 2600 MozillaOrgFirefoxTrunkWin322006040312 http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=17182540 Windows NT 5.1 build 2600 FirefoxTrunk2006040405 ntering text within the fields in site http://puck.nether.net/npa-nxx/ ntdll.dll + 0x33aed (0x77f83aed) ntdll.dll + 0x8cca (0x77f58cca) FULLSOFT.DLL + 0xf625 (0x001bf625) FULLSOFT.DLL + 0x10cf7 (0x001c0cf7) FULLSOFT.DLL + 0xed36 (0x001bed36) FULLSOFT.DLL + 0xedb2 (0x001bedb2) ntdll.dll + 0xb42c (0x77f5b42c) ntdll.dll + 0x129df (0x77f629df) kernel32.dll + 0x14af8 (0x77e74af8) MSVCR80.dll + 0x298e (0x6022298e) MSVCR80.dll + 0x2a36 (0x60222a36)
Summary: talkback causes (VC8) build to crash , win2k-only [@ ntdll.dll] → talkback causes (VC8) build to crash [@ ntdll.dll]
gotta have talkback for any kind of a good alpha. 1.9a1+
Flags: blocking1.9a1? → blocking1.9a1+
haven't been able to reproduce in about 40 mintues of heavy browsing with ~30 tabs open and lots of moving around... and running chatzilla... I installed Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060411 Firefox/3.0a1 out of ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk first install didn't seem to have talkback on by default so I had to go back and run a custom install to get it turned on... getting talkback turn on 100% for trunk builds in another bug...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060418 Firefox/3.0a1 ID:2006041810 [cairo] I get a crash just after Firefox start. TB17718628Q [Win XP]
I can still reproduce this on 4/17 build too. See TB17669795G and TB17669791E
(In reply to comment #31) > I can still reproduce this on 4/17 build too. when you enabled talkback?
of course. # I cannot reproduce if talkback is disabled.
Are the people seeing this bug all using Nightly Tester Tools?
(In reply to comment #34) > Are the people seeing this bug all using Nightly Tester Tools? Well, I am indeed. I had to turn off Nightly Tester Tools because it caused endless assertions in my debug build (this started a few days ago). Since then, I can't remember I crashed anymore randomly with this backtrace.
I don't know if it's of any help or not, but when I was using nightlies and seeing this crash I was not using nightly tester tools. I stopped using trunk builds after Cairo and Places landed so I don't know after that.
Blocks: 334616
(In reply to comment #34) > Are the people seeing this bug all using Nightly Tester Tools? I just crashed in ntdll.dll with Nightly Tester Tools disabled.
Any time I try to install latest Cairo trunk on the Pacifica one, I got crash on msvcr80.dll. On my 2 other PC's, I did the same, and it worked like a charm. 3 are using up to date XP pro SP2. I cannot point the difference. Strange.
(In reply to comment #38) > Any time I try to install latest Cairo trunk on the Pacifica one, I got crash > on msvcr80.dll. > > On my 2 other PC's, I did the same, and it worked like a charm. > > 3 are using up to date XP pro SP2. > I cannot point the difference. > > Strange. > I tried with/without talkback , and I do not use NTT. Same result, CRASH.
(In reply to comment #39) Is it really the same bug? What's your talkback ID?
(In reply to comment #40) > (In reply to comment #39) > Is it really the same bug? What's your talkback ID? > I do not have, these are instant crashes, I didn't even install talkback.
I cannot reproduce this bug after clean install(but my profile was not cleaned up).
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060511 Minefield/3.0a1 ID:2006051110 [cairo] I'm not getting this crash anymore since a few days Seems fixed by bug 336593
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
Crash Signature: [@ ntdll.dll]
You need to log in before you can comment on or make changes to this bug.