STEPS TO REPRODUCE: 1) Download a trunk Seamonkey Linux GTK1 .tar.gz starting with 2005-01-16-07 2) Start the browser 3) kill it with the SEGV signal EXPECTED RESULTS: talkback starts up and lets you send in a crash report ACTUAL RESULTS: talkback does not start Note: This works with a 2005-01-15-07. Also, I checked that the talkback binary is installed, and that I can run it from the command line. That part works fine. I've crashed three times already with today's nightly in the last 2 hours of browsing with it, and I'd really like to know what's causing the crashes so I can fix it. ;)
Cc'ing Chase in case there were changes to the builds that might have caused this regression. Boris: The builds from 1/15 that you said works, was it a .tar.gz or installer build? I don't remember, but I thought .tar builds did not have Talkback enabled.
These are all .tar.gz builds, and these have absolutely had talkback enabled for as long as I can recall (though there have been a time or two when that broke and was fixed).
This seems to be a Linux specific problem. I submitted a few crashes with yesterday's MozillaTrunk Win32 build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050125 Marcia said she is going to try to reproduce with recent Linux builds. It will be a good idea to test with both the tar.gz and installer builds. Chase is going to chime in with his thoughts soon.
this is a problem with both gtk1 (2005012711) and gtk2 (2005012605) non-installer builds. going to check a couple of installer builds to see if this is an issue there as well... tested on fedora core 2.
actually, gtk2 mozilla bits don't have an installer; just going to check the gtk1 full installer...
Cc'ing bryner and dbaron...in case they can help.
not a problem with the 2005012711-gtk1 installer build: the segv test crashes seamonkey and talkback comes up.
Summary: Talkback not working in builds after 2005-01-15 → Talkback not working in non-installer builds after 2005-01-15
The only change I made during the 1/14-1/16 period was to the symbol upload process which, if it broke anything, should only leave a stub talkback.xpi.
This might be related to bug 265492. Boris, what happens when you smite compreg.dat on one of these newer .tar.gz builds and restart Mozilla? Sairuh, could you test the build that worked for Boris (2005-01-15 .tar.gz) on your Linux system? It's possible while Talkback worked for him in that build it might not work for everyone.
Ah, yes. The tarball does indeed contain a compreg.dat, and killing it off before starting the browser does make talkback trigger properly.
tested 2005011507-trunk (gtk1) mozilla bits (on fc2) --both the non-installer and full installer-- and talkback came up when I issued -segv for both of them.
(In reply to comment #11) > tested 2005011507-trunk (gtk1) mozilla bits (on fc2) --both the non-installer > and full installer-- and talkback came up when I issued -segv for both of them. I think either Sairuh and Boris have similar systems or something check-in-wise changed significantly enough to break the default compreg.dat. It looks like the fix for this is similar to the fix for 265492.
Either that, or we changed where the tarballs are coming from... I don't see anything in that checkin range that should have significantly affected this.
Looks like we have a good idea of what's going on here. Reassigning this to Chase so he can take care of any issues on the build automation side.
Assignee: jay → cmp
One more piece of data: I did remove the compreg.dat, so now when I crash talkback runs. I sent in two talkback reports, but both show no symbols for the stack, just addresses....
OK, I've sent more talkback reports; all end up with no symbols. I'd really like to fix these crashes (a current trunk build is crashing for me about 3-4 times a day), but I can't figure out what to fix.... It'd be good to have this fixed for beta so we can get some useful crash feedback from it. :(
Jay and Chase, this needs to block beta1. Can we get a fix quickly?
Flags: blocking1.8b? → blocking1.8b+
This bug is about files showing up in the compressed archives of builds, not about no symbols appearing on the server. Let's file another bug for that to avoid tainting this one. Unless, bz, you are saying that crashes you file with installer builds show up with symbols and that there's a possibility that the compressed-archive-ness of these builds is causing the problem. If you haven't tested that, could you, to add another data point?
Hmm... With the installer build, I can't quite tell -- I send the incident, but when I run the talkback executable there are no incidents listed as sent. Removing compreg.dat has no effect on this. I ended up searching on comments, and that showed me an incident I had sent with the installer build. There were no symbols (so this may in fact be a separate bug). The build I was testing was the full-installer build from latest-trunk/. So yes, perhaps we need a separate bug on the no symbols issue...
Boris: Can you check which build ids are in the master.ini file of the builds for which you were able to send incidents, but did not see resolved stack traces? I can then look to see if we do have the symbol files stored on our end. We did run out of space around 1/15, and a few days worth of builds did not have symbols...but that should not be a problem with more recent builds (unless something is indeed broken).
The non-installer build I tested has: BuildID = "2005020905" The installer build has: BuildID = "2005021505"
Ok, so the missing symbols problem is a separate issue and I have logged bug 282397 for that. This bug is for fixing the compreg.dat problem so that we do not package that file with non-installer builds. I'm taking this bug and will try to get a patch submitted soon.
Assignee: cmp → jay
Summary: Talkback not working in non-installer builds after 2005-01-15 → Talkback not working in non-installer builds after 2005-01-15 because package contains compreg.dat
(In reply to comment #22) > Ok, so the missing symbols problem is a separate issue and I have logged bug > 282397 for that. This bug is for fixing the compreg.dat problem so that we do > not package that file with non-installer builds. > > I'm taking this bug and will try to get a patch submitted soon. Same goes for windows zip-builds, see Bug 253750 Talkback doesn't launch anymore on crash
We just need to find out a good place in the build config to specify which file(s) to exclude when the packages are put together. I'm new to working with the build system, so if anyone has any suggestions, please let me know (or attach a patch). I'm guessing any possible fixes for Seamonkey builds will be as easy as the patch in bug 265492.
After discussing this with dbaron and bryner, it looks like removing the compreg.dat is not the ideal solution here. If the only problem is that Talkback is not working with the current compreg.dat file included in non-installer builds, we need to figure out how to regenerate that file to include Talkback and then package it in. Reassigning to Chase since he probably has a better idea of how we can do that. Bryner said we should run regxpcom (which only works for Seamonkey builds) after the Talkback files have been copied to the mozilla directory so that Talkback is included in the compreg.dat file that is packaged and shipped.
Assignee: jay → cmp
Chase: This is a dupe of Bug 253750, but wasn't sure which one you wanted to keep open, so I'll leave it up to you to read through them both and dup one of them. Given the workaround of removing the compreg.dat file, I don't think this is a blocker for 1.8b. Someone with permission to change the flag, please do so. Thanks.
Er... given that the point of talkback is to collect crash data from people across the board, and that most people have no idea the workaround exists, and that we need crash data from beta to stabilize final, I think this should most emphatically block beta. If it's just me we're talking about, I can just use Mozilla with debug builds running under gdb if I want to catch the crashes I hit. But the point is that we want to catch crashes our _users_ (not developers) hit... Note also that some of our builds (GTK2 builds come to mind) only really come in non-installer form.
cmp says that the problem was exposed by a mistake that was made in the talkback staging code that caused the build to fail at the symbol push. This caused both (1) no symbols and (2) regxpcom not to be run. He said that problem was fixed a day or two ago, so now the symbols should be pushed and regxpcom should be being run. Have you tested a current .tar.gz build to see if talkback works? In particular, http://stage.mozilla.org/pub/mozilla.org/mozilla/nightly/2005-02-17-14-trunk/ But apparently it was never working for Windows and Mac tarballs, just Linux ones (for which the symbol staging error caused this regression).
Ah, yes. With a build from today, things work (I get talkback running, and I get symbols). Marking fixed.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
I think Chase wanted to leave the bug open to fix Windows and Mac.
Ah, ok. I should stop being so trigger-happy...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
so since Mac uses a non-installer disk image, does this mean stack traces from Mac crashes are lacking relevant info like symbols? if yes, should this get fixed for 1.8beta1?
OS: Linux → All
Hardware: PC → All
here is a -segv test crash from 2005021714-trunk Mac seamonkey: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=3768937
Sarah: Since you were able to trigger Talkback and submit an incident, it seems as if the compreg.dat problem is not an issue for Mac. The symbols problem was solved and was a separate issue. If you look at the stack of your incident, notice the resolved function names with filename and line no., being able to see those detailed stack frames mean that Talkback has processed your crash using proper Mac symbols files. Of course most of stack is not resolved, but that is a whole other issue due to the limitations of Talkback. Chase: Is the packaging process different for the Mac? If only Linux was running the regxpcom, why did Sarah's build work as expected? Maybe this is not a problem on Mac at all? We still need to fix Windows though, right?
I'm treating this bug as something that we need to verify either exists or doesn't on Mac and Windows. The problem right now on our end is that the code only does the compreg-regeneration for Linux and, though it leaves out Mac/Windows, it may be that these platforms were ignored because they are immune to this. Just need more time to verify/test, but we won't be able to get to this until after the releases.
tested with todays nightly on Win98SE: MozillaTrunk Build ID 2005021806 http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB3781872G I unzipped the zip creating a fresh new folder, started Mozilla, tested Bug 282707 to produce a crash, and got a silent crash, DocWatson comming up, but no talkback. Deleted compreg.dat, retried testcase, immediate crash. Symbols were included, as can be seen at the link above. Deleting compreg.dat on Windows zip-builds is needed since 2004-07-30, Bug 253750 Talkback doesn't launch anymore on crash for non-installer builds due to compreg.dat file (which doesn't have Talkback registered)
Mass reassign of open bugs for firstname.lastname@example.org to email@example.com.
Assignee: chase → build
Status: REOPENED → NEW
Can this be closed?
Robert, see comment 30.
During bug triage, this bug appears to be obsolete, so we are closing it. If you think this bug should be worked on, please reopen it and add comments explaining why. Thank you, The Build Team.
Status: NEW → RESOLVED
Last Resolved: 14 years ago → 12 years ago
Resolution: --- → WONTFIX
Component: Talkback Client → Talkback Client
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.