Talkback not working in non-installer builds after 2005-01-15 because package contains compreg.dat

RESOLVED WONTFIX

Status

--
major
RESOLVED WONTFIX
14 years ago
7 years ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

({regression})

Trunk
regression
Bug Flags:
blocking1.8b +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
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.  ;)

Comment 1

14 years ago
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.
(Reporter)

Comment 2

14 years ago
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).

Comment 3

14 years ago
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...

Comment 6

14 years ago
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.
Keywords: regression
Summary: Talkback not working in builds after 2005-01-15 → Talkback not working in non-installer builds after 2005-01-15

Comment 8

14 years ago
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.

Comment 9

14 years ago
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.
(Reporter)

Comment 10

14 years ago
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.

Comment 12

14 years ago
(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.
(Reporter)

Comment 13

14 years ago
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.

Comment 14

14 years ago
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
(Reporter)

Comment 15

14 years ago
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....
(Reporter)

Comment 16

14 years ago
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.  :(
Flags: blocking1.8b?

Comment 17

14 years ago
Jay and Chase, this needs to block beta1.  Can we get a fix quickly?
Flags: blocking1.8b? → blocking1.8b+

Comment 18

14 years ago
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?
(Reporter)

Comment 19

14 years ago
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...

Comment 20

14 years ago
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).
(Reporter)

Comment 21

14 years ago
The non-installer build I tested has:

  BuildID = "2005020905"


The installer build has:

  BuildID = "2005021505"

Comment 22

14 years ago
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

Comment 23

14 years ago
(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

Comment 24

14 years ago
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.

Comment 25

14 years ago
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

Comment 26

14 years ago
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.
(Reporter)

Comment 27

14 years ago
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).
(Reporter)

Comment 29

14 years ago
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
(Reporter)

Comment 31

14 years ago
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

Comment 34

14 years ago
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?

Comment 35

14 years ago
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.

Comment 36

14 years ago
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)

Comment 37

14 years ago
Should this be duped against bug 253750?
Depends on: 265492

Comment 38

13 years ago
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
Status: REOPENED → NEW
Can this be closed? 
(Reporter)

Comment 40

13 years ago
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 ago12 years ago
Resolution: --- → WONTFIX

Updated

10 years ago
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.