Closed Bug 279993 Opened 18 years ago Closed 15 years ago

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


(Core Graveyard :: Talkback Client, defect)

Not set


(Not tracked)



(Reporter: bzbarsky, Unassigned)



(Keywords: regression)


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

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.
Closed: 18 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...
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
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

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
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)
Should this be duped against bug 253750?
Depends on: 265492
Mass reassign of open bugs for to build@mozilla-org.bugs.
Assignee: chase → build
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.
Closed: 18 years ago15 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.