Sid,

Could you take a look at this crasher?

This crash was found in 2.0.169.0 and is currently ranked #16 (based on the relative number of reports in the release).  There have been 22 reports from 19 clients.
http://crash/search?query=Chrome+2.0.169.0+LdrpCallTlsInitializers

This crash was found in 2.0.169.1 and is currently ranked #22 (based on the relative number of reports in the release).  There have been 14 reports from 13 clients.
http://crash/search?query=Chrome+2.0.169.1+LdrpCallTlsInitializers

I cannot seem to reproduce this in 168, 169 or on the trunk. The portion of code 
where this crashes is a third party code, and as such, I do not see anything amiss. 
This is a bit puzzling.

I am still looking to see what can be done about this crash - meanwhile adding Brett 
to this issue to seek his opinion.   

This crash was found in 2.0.170.0 and is currently ranked #14 (based on the relative number of reports in the release).  There have been 15 reports from 13 clients.
http://crash/search?query=Chrome+2.0.170.0+LdrpCallTlsInitializers

This crash was found in 2.0.170.0 and is currently ranked #14 (based on the relative number of reports in the release).  There have been 15 reports from 13 clients.
http://crash/search?query=Chrome+2.0.170.0+LdrpCallTlsInitializers

This crash was found in 2.0.171.0 and is currently ranked #14 (based on the relative number of reports in the release).  There have been 8 reports from 8 clients.
http://crash/search?query=Chrome+2.0.171.0+LdrpCallTlsInitializers

This crash was found in 2.0.171.0 and is currently ranked #14 (based on the relative number of reports in the release).  There have been 8 reports from 8 clients.
http://crash/search?query=Chrome+2.0.171.0+LdrpCallTlsInitializers

(No comment was entered for this change.)

Weird. I was looking at the list of bugs and noticed the owner email got messed up on 
this bug... Fixing.

Moving from milestone 2 to milestone 2.1.

 Issue 11791  has been merged into this issue.

It's still crashing in 172.x (well, this bug hasn't been worked on) and Mark set the
priority to P1. 

From  issue 11791 :

The full crash report details can be found at: 
http://go/crash/reportdetail?
reportid=faca3389f5399a5b&product=Chrome&version=2.0.172.23&signature=LdrpC
allTlsInitializers-14B55CB

Meta information:
Report ID: faca3389f5399a5b
Report Time: 2009/05/10 15:41:19, Sun
Uptime: 309 sec
Cumulative Uptime: 0 sec
User Email: 
User Comments: 
Product Name: Chrome
Product Version: 2.0.172.23
OS Name: Windows NT
OS Version: 5.1.2600 Service Pack 3
CPU Architecture: x86
CPU Info: GenuineIntel family 6 model 23 stepping 6
plat: Win32
ptype: browser
 

Just a wild guess:  In Line 399 of affentry.cxx, replacing '8' by |numconds| might
fix this crash. 

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=15939 

------------------------------------------------------------------------
r15939 | mal@chromium.org | 2009-05-12 22:07:03 -0700 (Tue, 12 May 2009) | 11 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/172/src/chrome/third_party/hunspell/src/hunspell/affentry.cxx?r1=15939&r2=15938
   M http://src.chromium.org/viewvc/chrome/branches/172/src/chrome/third_party/hunspell/src/hunspell/affixmgr.cxx?r1=15939&r2=15938

Apply codereview/115228 to 172.

This is a blind patch from http://codereview.chromium.org/115228.

Try to fix a crash in Hunspell by initializing cond.utf8 part of affentry and
checking whether its elements are populated before calling |free|. 

BUG= http://crbug.com/8551
TEST= None. The crash in the bug no longer shows up on the crash server.
TBR= jshin
Review URL: http://codereview.chromium.org/113324
------------------------------------------------------------------------

This is fixed on the 172 branch. The change should still land on trunk.

Ooops. I missed the other dtor (there are two dtors with the problem. I only fixed the 
dtor for Pfxentry while leaving the dtor for Sfxentry). I can now reliably reproduce 
this crash (switch to French spellcheck dictionary and type a paragraph or two of 
English in a textarea and close Chrome). 

Reopening. In addition to what I wrote in comment #21, more wall-papering is necessary. 
(For branch, I put it up at http://codereview.chromium.org/113368.)  But, that does not 
seem sufficient. (it's ok inside a debugger, but run by itself, Chrome was terminated 
in an unsual manner - paraphrasing of the error messsage I got from VCruntime). 

It appears that there are some entries in our French affix list with > 8 conditions, 
but Affentry struct can hold only up to 8 conditions. 

fr_FR.aff has entries like one shown below : The last field in each column is for 
conditions. Basically, the number of characters in the field is # of conditions. 
(field #3 will be replaced by field #4 when conditions in field 5 are all satisfied). 
There are conditions longer than 8, which would corrupt the memory. 

SFX wT N 87
SFX wT tre tre tre
SFX wT roître roissant croître
SFX wT roitre roissant croitre
SFX wT roître rû recroître
SFX wT roître rûs recroître
SFX wT roître rûe recroître
SFX wT roître rûes recroître
SFX wT roître ru décroître

------------------

Should we increase the number of conditions allowed? It's doable, but will lead to a 
lot of small heap-allocated memory fragments for languages like French because we 
have to give up special (space-saving) handling of ASCII-range characters.

Should we remove entries with > 8 conditions? That will hurt the spell-checking 
quality. 
 

I think lowering the spell-check quality is the best tradeoff here, presuming we can 
make a comprehensive fix at some point that allows more conditions.

I don't like the sound of tinkering with data structures --eg, allowing the Affentry 
struct more entries-- at this stage for 2.0.

I don't like the sound of lots of small heap allocations, which could affect 
performance and reliability for anyone using the French spellcheck dictionary.

I think users will be more willing to use a browser with a poor spell-checker than 
one that crashes a lot.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=16036 

------------------------------------------------------------------------
r16036 | mal@chromium.org | 2009-05-13 20:47:27 -0700 (Wed, 13 May 2009) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/172/src/chrome/third_party/hunspell/src/hunspell/affentry.cxx?r1=16036&r2=16035

A better fix for the hunspell crash. 

BUG= http://crbug.com/8551
TEST= Run Chrome with '--lang=fr'. Type some English text (or whatever text) and
quit Chrome. Chrome should not crash.
------------------------------------------------------------------------

Mark, I agree with you. I'll change fr_FR.aff and see if other aff files have the
same issue. 

Hunspell 1.2.8 does not have the restriction of max 8 conditions and its data
structure is  more streamlined. Apparently, that's why OpenOffice 3.x does not suffer
from this issue. 

http://dicollecte.free.fr/download/fr/ has 3 French dictionaries - classic, reform
1990 and classic + reform 1990. The last is recommended  What's currently used by
Chrome seems to be classic + reform v3.1 (Jan, 2009) (+ some additions?) and the
latest was v 3.2 released in April, 2009. Anyway, both classic and 1990 reform aff
files have entries with > 8 conditions although 1990 reform has fewer. 

I'm considerig reverting to the newest reform + classic version in which all the
entries have 8 or fewer conditions. It's 2.3.2 released in 2008. Unless there's a
data format incompatibility (not so likely. [1]), I guess it's safer for the branch
than pruning our current version with a script. 

For the trunk, perhaps, we'd better upgrade to Hunspell 1.2.8 to use the latest
French dictionary. 

To Sid, when you updated the French dictionary, you didn't seem to regenerate
fr_fr.bdic file. ( http://codereview.chromium.org/28054 and svn log of fr_fr.bdic
agree on that). Am I missing anything? Don't I have to regenerate fr_fr.bdic? 

Actually, I just realized, I don't think doing the extra allocation for the pfx entry 
will be a big deal if we want to do it. We only make those on demand, since we use a 
special internal structure to store the rules.

Brett, thanks for the info, but I'm wary of making a data structure change this late 
in the beta cycle as Mark said. 

2.3.2 was released in April 2008 and 3.1 (the current version in Chrome) was released 
in Jan 2009. So, I guess there's not much quality loss. 

As for bdict, I realized that it's coming from our server. So, after updating 
(downgrading)  'src' files (aff and dict) to 2.3.2, I have to generate the 
corresponding bdic file with our tool (convert_dict) to test. If it works well, I 
have to pass it over to our (download) server people, right? 
 

Jungshik, thanx for the wonderful work. If you make the new French dictionary, could 
you please send the .bdic file to me? I will have it uploaded to our download servers 
with Mark's help, and some changes in Chromium code.

Reply to comment 27: Yes, I uploaded only the .dic, .aff and the .dic_delta files, but 
did not upload the bdic files, as they can be readily generated using Brett's 
convert_dict tool.

 Issue 9948  has been merged into this issue.

For the record, the following CLs were checked into 172 brach:

http://src.chromium.org/viewvc/chrome?view=rev&revision=16113
http://src.chromium.org/viewvc/chrome?view=rev&revision=16120

For the trunk, this was checked in:

http://src.chromium.org/viewvc/chrome?view=rev&revision=16115
http://src.chromium.org/viewvc/chrome?view=rev&revision=16116
http://src.chromium.org/viewvc/chrome?view=rev&revision=16137

 Issue 11374  has been merged into this issue.

 Issue 11489  has been merged into this issue.

This crash was found in 2.0.172.27 and is currently ranked #6 (based on the relative number of reports in the release).  There have been 130 reports from 112 clients.
http://crash/search?query=Chrome+2.0.172.27+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 2.0.172.27

This crash was found in 2.0.172.28 and is currently ranked #616 (based on the relative number of reports in the release).  There have been 2 reports from 1 clients.
http://crash/search?query=Chrome+2.0.172.28+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 2.0.172.28

This crash was found in 2.0.181.1 and is currently ranked #33 (based on the relative number of reports in the release).  There have been 7 reports from 7 clients.
http://crash/search?query=Chrome+2.0.181.1+tcmalloc%3A%3AThreadCache%3A%3AFreeList%3A%3APopRange%28int%2Cvoid+*+*%2Cvoid+*+*%29
This crash looks like it has re-appeared in 2.0.181.1

This crash was found in 2.0.181.1 and is currently ranked #131 (based on the relative number of reports in the release).  There have been 2 reports from 2 clients.
http://crash/search?query=Chrome+2.0.181.1+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 2.0.181.1

Not to be too pedantic on a closed bug, but the crashes laforge's tool is digging up 
are not related to this bug (at least the ones I have looked at).

This bug is a crash in the hunspell AffixMgr destructor. Many other call stacks might 
wind up with LdrpCallTlsInitializers in the top frame. I'll change the subject to see 
if that helps.

I'm resetting this to P1, just in case it needs to be reopened for some reason.

This crash was found in 3.0.182.3 and is currently ranked #47 (based on the relative number of reports in the release).  There have been 9 reports from 9 clients.
http://crash/search?query=Chrome+3.0.182.3+tcmalloc%3A%3AThreadCache%3A%3AFreeList%3A%3APopRange%28int%2Cvoid+*+*%2Cvoid+*+*%29
This crash looks like it has re-appeared in 3.0.182.3

This crash was found in 3.0.182.3 and is currently ranked #136 (based on the relative number of reports in the release).  There have been 3 reports from 3 clients.
http://crash/search?query=Chrome+3.0.182.3+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 3.0.182.3

This crash was found in 3.0.183.1 and is currently ranked #49 (based on the relative number of reports in the release).  There have been 4 reports from 2 clients.
http://crash/search?query=Chrome+3.0.183.1+tcmalloc%3A%3AThreadCache%3A%3AFreeList%3A%3APopRange%28int%2Cvoid+*+*%2Cvoid+*+*%29
This crash looks like it has re-appeared in 3.0.183.1

This crash was found in 3.0.183.1 and is currently ranked #38 (based on the relative number of reports in the release).  There have been 18 reports from 14 clients.
http://crash/search?query=Chrome+3.0.183.1+tcmalloc%3A%3AThreadCache%3A%3AFreeList%3A%3APopRange%28int%2Cvoid+*+*%2Cvoid+*+*%29
This crash looks like it has re-appeared in 3.0.183.1

This crash was found in 3.0.183.1 and is currently ranked #136 (based on the relative number of reports in the release).  There have been 4 reports from 4 clients.
http://crash/search?query=Chrome+3.0.183.1+LdrpCallTlsInitializers
This crash does not appear to have been in 3.0.182.3

This crash was found in 3.0.187.1 and is currently ranked #19 (based on the relative number of reports in the release).  There have been 6 reports from 6 clients.
http://crash/search?query=Chrome+3.0.187.1+tcmalloc%3A%3AThreadCache%3A%3AFreeList%3A%3APopRange%28int%2Cvoid+*+*%2Cvoid+*+*%29
This crash looks like it has re-appeared in 3.0.187.1

This crash was found in 3.0.189.0 and is currently ranked #49 (based on the relative number of reports in the release).  There have been 2 reports from 2 clients.
http://crash/search?query=Chrome+3.0.189.0+tcmalloc%3A%3AThreadCache%3A%3AFreeList%3A%3APopRange%28int%2Cvoid+*+*%2Cvoid+*+*%29
This crash looks like it has re-appeared in 3.0.189.0

(No comment was entered for this change.)

Anthony, as Mark mentioned , crashes found by your tool is not specific enough. Can you change your tool so 
that it does not add to this bug unless the stack trace contains '~AffixMgr'? 

2.0.172.29 is the first 172 branch build with the fix for this bug ( 
http://chrome-svn/viewvc/chromeinternal/trunk/tools/buildspec/releases/2.0.172.29/DEPS?view=log ) and according 
to the crash report, there's NO crash report in ~AffixMgr in 2.0.172.29. 

There's one in 2.0.172.30.

Hmm, but there are many in hunspell::NodeReader::FindWord ...


http://crash/reportdetail?reportid=c4d79f0a22c2a86c but its stack is different from this one. Nonetheless, 
I'll take a look at it. 

My previous comment was confusing. 'hunspell::NodeReader::FindWord' crashes have 
nothing to do with this and it's filed as  issue 14721 . 

2.0.172.29 does not have any crash report with AffixMgr::~AffixMgr. Neither do 
3.0.18x.y's. However, 2.0.172.30 and 31 have 2 and 5 crash reports with the same 
stack signature as this bug deals with. ( http://crash/search?
query=product:Chrome+version:2.0.172.31+stack_signature:AffixMgr::~AffixMgr )

All of them were reported in June. I suspect (a) dictionary file(s) on users' 
machines were corrupted somehow. Anyway, there are only few crashes and I don't think 
we have to worry about them. 

This is really about a crash on 172 that has been fixed.

This crash was found in 4.0.220.1 and is currently ranked #370 (based on the relative number of reports in the release).  There have been 2 reports from 2 clients.

Report Link: http://crash/reportdetail?reportid=a24c863c5052c775
http://crash/search?query=Chrome+4.0.220.1+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.220.1

This crash was found in 4.0.222.12 and is currently ranked #160 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #168 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #173 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #173 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #183 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #191 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #197 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #213 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #221 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #229 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #236 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #245 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #258 (based on the relative number of reports in the release).  There have been 4 reports from 3 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #202 (based on the relative number of reports in the release).  There have been 5 reports from 4 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

(No comment was entered for this change.)

This crash was found in 4.0.222.12 and is currently ranked #211 (based on the relative number of reports in the release).  There have been 5 reports from 4 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #212 (based on the relative number of reports in the release).  There have been 5 reports from 4 clients.

Report Link: http://crash/reportdetail?reportid=51bc5060c9282d26
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #158 (based on the relative number of reports in the release).  There have been 7 reports from 6 clients.

Report Link: http://crash/reportdetail?reportid=526aa3a541c63ca6
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #164 (based on the relative number of reports in the release).  There have been 7 reports from 6 clients.

Report Link: http://crash/reportdetail?reportid=526aa3a541c63ca6
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #149 (based on the relative number of reports in the release).  There have been 8 reports from 7 clients.

Report Link: http://crash/reportdetail?reportid=526aa3a541c63ca6
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #158 (based on the relative number of reports in the release).  There have been 8 reports from 7 clients.

Report Link: http://crash/reportdetail?reportid=526aa3a541c63ca6
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

This crash was found in 4.0.222.12 and is currently ranked #173 (based on the relative number of reports in the release).  There have been 8 reports from 7 clients.

Report Link: http://crash/reportdetail?reportid=526aa3a541c63ca6
http://crash/search?query=Chrome+4.0.222.12+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.222.12

Can we do something to prevent crashbot from adding bogus reports to this bug? 

LdrpCallTlsInitializers just happened to be at the top of the stack for this issue, but 
this issue is about crash in AffixMgr dtor rather than about any memory alloc-related 
crash. 

This crash was found in 4.0.237.0 and is currently ranked #257 (based on the relative number of reports in the release).  There have been 2 reports from 2 clients.

Report Link: http://crash/reportdetail?reportid=0ef65f3d5614db68&newsig=
http://crash/search?query=Chrome+4.0.237.0+LdrpCallTlsInitializers
This crash looks like it has re-appeared in 4.0.237.0

This crash was found in 4.0.249.0 and is currently ranked #158 (based on the relative number of reports in the release).  There have been 2 reports from 2 clients.

Report Link: http://crash/reportdetail?reportid=61710b27ad94ed3e&newsig=
http://crash/search?query=Chrome+4.0.249.0+LdrpCallTlsInitializers
This crash does not appear to have been in 4.0.245.1