Closed Bug 246557 Opened 21 years ago Closed 20 years ago

crash not recorded by talkback

Categories

(Core Graveyard :: Talkback Client, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mkl_mozilla, Assigned: namachi)

References

(
URL
)

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040608 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040608 crash caused by bug 246048 won't be recorded by talkback. I am using zipped nigtly builds (no install). When I try to launch talkback.exe manual there is no incident too. Reproducible: Always Steps to Reproduce: 1. Use build with bug 246048 (20040610) 2. Open www.cnn.com 3. Right click any link multiple times (do not select anything from context menu, just right click) 4. Mozilla will eventually crash and takback won't record this crash
Well, this is interesting, since the 2004-06-10 build has the patch that caused bug 246048 to crash backed out.
Yes, you are right. The exact build ID was 2004060908. I got downloaded to my PC in morning 2004/06/10
Most of the bug 246048 crashes are recorded by talkback though. Maybe talkback simply isn't properly included in the zip builds?
Another crash that won't trigger talkback is bug 244470 yet anther is bug 244619 and bug 244454 too. None of [crash] bugs I was able to reproduce has triggered talkback.
I think at some point you've disabled Talkback, then. Talkback is working fine for me in an installer build on Windows XP, and I haven't seen any other bug reports about this. When you do run Talkback.exe, please let us know what is under Settings -- "Turn Agent On" or "Turn Agent Off".
When I run talkback manualy in settings I see: "Turn Agent On". I did another test: 1) Clean W2K instalation 2) Download latest mozilla-i586-pc-msvc.zip 3) unzip to c:\ 4) run c:\mozilla\mozilla.exe 5) all crashes from comment #4 are still not recorded by talkback. So: to me it looks like in **zip** builds talkback doesn't work
*** Bug 247118 has been marked as a duplicate of this bug. ***
I think there's a general talkbalk problem. Compare bug 247118 and bug 247546 comment 0. Confirming based on the dupes and own experience. FWIW: Using installer trunk builds on XP Pro. Adding REGRESSION keyword.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
I'm the reporter of bug 247546. My problems with talkback differ slightly from what is described in this bug. I have looked at my bugs in talkback, by running "mozilla/components/talkback/talkback". This shows 2 bugs reported with moz 1.7 version 20040514: TB137346K -Comment starts with: "Had numerous tabs open." -Not visible from the talkback findfast page. TB57995K -Comment starts with: "Browsing many pages." -Visible from findfast page, but doesn't show the comment. Finally, how fast is the Talkback server? If people are not seeing messages in talkback findfast, then could this mean the server is slow to populate the DB? Conclusion: The missing incident problem could be a separate bug in talkback. It could also be due to a slow talkback server. There could be a bug in insering comments into the talkback database.
There are two bugs here. 1. (the original) is that some crashes do not trigger the talkback crash reporting utility at all. That's what this bug should track. 2. the duped bug is that talkback searching doesn't show reported incidents. This is because our server is having problems and reports aren't being _processed_ (they are being recorded) so you can't get at them from the talkback-public search. This bug is something we already know about and doesn't belong in this particular report.
Currently Talkback isn´t working in the zip builds, see Bug 253750 Talkback doesn't launch anymore on crash Sometimes the files are missing in the components folder: master.ini, talkback-l10n.ini, talkback.cnt, talkback.exe, talkback.hlp currently Firefox is missing the master.ini. Even if all files are installed, Talkback doesn´t trigger. Workaround: after installation, delete compreg.dat in the components folder. It will be recreated at next start. There is one more problem, I saw only once, firsttime, today, but found it reported somewhere: The Talkback client tried to transmit the record, and to me it seemed it had been successful, but it told it was unable to deliver. I checked fastfind, gave a try to the last two numbers, and saw my report had succeeded. I tried to resend it, to get the TBID, but it couldn´t send. Maybe, the server didn´t accept the duplicate report, so no chance to get the Talkback ID.
Flags: blocking1.8a6?
Flags: blocking1.8a6? → blocking1.8a6-
Is this bug still alive?. I have daily crashes in Firefox, and 2-3 crashes each day in Thunderbird. Current nightly builds. Talkback doesn't catch the crashes. And yes, it is enabled.
Still crashing. No talkback caching. I've started a thread in mozillazine: http://forums.mozillazine.org/viewtopic.php?p=1882339&sid=87f7052ec83c47317c5c0918b4e23724 16:30, six crashes today. Talkback is enabled, but catches nothing.
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Answering comment #11, I have *ONLY* the following files in my talkback component folder: -rw-r--r-- 1 jcea users 2779 2005-11-16 15:10 master.ini -rwxr-xr-x 1 jcea users 1705552 2005-10-19 14:17 talkback -rwxr-xr-x 1 jcea users 145324 2005-10-19 14:17 talkback.so -rw-r--r-- 1 jcea users 5893 2005-10-19 14:17 XTalkback.ad I upgrade firefox everyday using automatic update and nighlty builds.
Seems that talkback does not work very good on Linux systems. I get several crashes daily and Talkback does not trigger. Perhaps 1 out of 20 or 30 triggers talkback. If i'm running FF from a console i can see the crash message on the console. Seems always related to JavaScript. Running 1.5RC2
I'm now running Firefox under GDB. Hope to catch any of my >10 daily crashes.
GDB is of no help here, seems: Couldn't get registers: No such process. (gdb) Continuing. Cannot fetch general-purpose registers for thread 1090849712: generic error I launched Firefox and attached GDB to that process. It didn't work. Any suggestion?. Three crashes in the last two hours. I'm a bit tired of it... :-)
Talkback has many client and server-side bugs that we are unable to fix because we still do not have access to the source code. This bug is something that will not be fixed anytime soon, so marking WONTFIX. Don't worry, when/if we get the source, I will be sure to query for all Talkback related bugs that we have marked WONTFIX and reconsider them.
Status: NEW → RESOLVED
Closed: 20 years ago
Flags: blocking1.8.1?
Flags: blocking1.8.1-
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
Resolution: --- → WONTFIX
sounds like the app is being forcibly quit. breakpoint all the various exit routines using gdb.
What routines are that, timeless?. I am not an expert in Firefox source code. Not yet, at least :-p
exit, atexit, abort, ... i don't have a list. it's not mozilla specific, you can do a google search and find them.
No luck: >>>>> [...] Reading symbols from /lib/libresmgr.so.1...done. Loaded symbols for /lib/libresmgr.so.1 Reading symbols from /home/jcea/firefox/libnssckbi.so...done. Loaded symbols for /home/jcea/firefox/libnssckbi.so Reading symbols from /opt/gnome/lib/pango/1.4.0/modules/pango-basic-fc.so...done. Loaded symbols for /opt/gnome/lib/pango/1.4.0/modules/pango-basic-fc.so 0x4016d0b1 in PR_Unlock () from /home/jcea/firefox/libnspr4.so (gdb) br abort Breakpoint 1 at 0x40a75cd6 (gdb) br exit Breakpoint 2 at 0x40a77146 (gdb) br atexit Function "atexit" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) br _exit Breakpoint 3 at 0x40ad9b68 (gdb) c Continuing. [New Thread 1119742896 (LWP 4307)] [Thread 1121844144 (LWP 4284) exited] Couldn't get registers: No such process. (gdb) q The program is running. Quit anyway (and detach it)? (y or n) y Quitting: thread_db_get_info: cannot get thread info: generic error <<<<< Any idea?.
I've monitored firefox under "strace", with some filters to "clear the signal". I'm stunned: >>>>> $ strace -p 9216 2>&1 | grep -v read | grep -v write | grep -v select | grep -v ioctl | grep -v poll | grep -v gettimeofday [...] futex(0x89e9624, FUTEX_WAKE, 1) = 1 futex(0x89e9628, FUTEX_WAKE, 1) = 1 futex(0x89e9624, FUTEX_WAKE, 1) = 1 lseek(29, 1141248, SEEK_SET) = 1141248 +++ killed by SIGKILL +++ <<<<< What is going on?. Who is sending the SIGKILL?. Seems not to be firefox itself, since I dont see the "signal" syscall?. I'm lost.
oom killer?
Good try, but you missed :-p I have 1 GB of RAM and 4GB of swap: >>>>> jcea@castor:/proc> free total used free shared buffers cached Mem: 1033088 1020948 12140 0 3108 118912 -/+ buffers/cache: 898928 134160 Swap: 4200956 890232 3310724 <<<<< And I have disabled OOM ages ago: >>>>> castor:~ # cat /proc/sys/vm/overcommit_memory 0 <<<<<
See comments in bug 303050.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.