379847 - Access violation in AffixMgr::parse_affix 693a66eb [@ MYSPELL.DLL + 0x2915] when composing new mail in Windows Live Hotmail

Status: RESOLVED FIXED

(Core :: Spelling checker, defect)

Description

[Kenneth Heal]

This does not always occur, but did on this occasion and produced the crash seen in TB31841938Z on Firefox 2.0.0.4 rc1.

Installed extensions are:
United States English Dictionary 2.0.0.6
Dictionnaire MySpell en Français 1.0.1
Nederlands Woordenboek 1.0.5
Deutsches Wörterbuch, erweitert für Österreich 1.0.1
Talkback 2.0.0.4
Diccionario de Español/España 1.1
British English Dictionary 1.19
Dictionnaire MySpell en Français (réforme 1990) 1.0.1
Geiriadur Cymraeg 0.02
Dizionario italiano 3.0
Deutsches Wörterbuch 1.0.1

Using the default theme on this Windows 98 SE system.

Comment 1

[Martijn Wargers (dead)]

So it seems like the situation happens as described in bug 340362?

Comment 2

[Kenneth Heal]

Does any of the developers of the code have any confirmation on this ?  Is any more data needed?  Looking forward to an update from the developers.

Comment 3

[Majken Connor [:Kensie]]

Kenneth - I believe Martijn would like you to check out bug 340362 and let us know if that's the same as the issue you're having.

Comment 4

[Kenneth Heal]

I am _NOT_ the developer and I have no way to know this.  BTW Have you read the bug yourself?

Comment 5

[Majken Connor [:Kensie]]

I thought I had, but I've just looked at it now and I see your point.  There isn't really a description there at all to answer Martijn's question (not really a question?)

I'm not sure if information like which dictionary you're using at the time of the crash would be helpful.

Comment 6

[Kenneth Heal]

Precisely.  Not too sure which dictionary was in use at the time (would have been either Dutch, German or English-British); but I REALLY do think it is time that developers pulled their finger out here a little; in the very least to let us all know if they need any other information or details in order to fix this one.  (I am not even saying it must be fixed now, but a coherent explanation would be a start.)

I must admit to being somewhat extremely underwhelmed here.

Comment 7

[Majken Connor [:Kensie]]

Well attention gets paid less quickly if not many people are experiencing the same crash. Not sure who "all" is, unless you have friends that are having the same issue and you're reporting on their behalf as well.

Although it's not very often we get someone upset with us because we're *not* giving them some testing to do for us, I poked one of the devs to see what I can ask you to do that won't be a waste of time.

Go to C:\Program Files\Mozilla Firefox (or wherever you have Firefox installed) and check the dates on the dlls, see if any of the dates (especially on myspell.dll) is out of sync.

As well, you can see if you can either replicate it on a specific dictionary, or eliminate them by disabling them.  If we can determine it's dictionary specific that makes it easier for everyone else to try and reproduce.

Comment 8

[Kenneth Heal]

I agree it is not a high priority bug, but some kind of initial assessment seems reasonable.  Also the simple response of bug noted, no extra data needed would also be fine.  I doubt that anyone is really pleased if they report a bug and it appears to land in /dev/null.

Anyway, took a quick look and everything seems sweet:

C:\Program Files\Mozilla Firefox

ACCESS~1 DLL        13,952  02/05/07  22:47 AccessibleMarshal.dll	1.8.1.4: 2007050106
FREEBL3  DLL       200,829  01/05/07  17:38 freebl3.dll		3.11.4 Basic ECC
JS3250   DLL       455,272  02/05/07  22:47 js3250.dll		4.0
NSPR4    DLL       161,392  02/05/07  22:47 nspr4.dll			4.6.7 Beta
NSS3     DLL       378,472  02/05/07  22:47 nss3.dll			3.11.5 Basic ECC
NSSCKBI  DLL       259,696  02/05/07  22:47 nssckbi.dll		1.62
PLC4     DLL        34,424  02/05/07  22:47 plc4.dll			4.6.7 Beta
PLDS4    DLL        30,320  02/05/07  22:47 plds4.dll			4.6.7 Beta
SMIME3   DLL       112,232  02/05/07  22:47 smime3.dll		3.11.5 Basic ECC
SOFTOKN3 DLL       254,060  01/05/07  17:38 softokn3.dll		3.11.4 Basic ECC
SSL3     DLL       132,712  02/05/07  22:47 ssl3.dll			3.11.5 Basic ECC
XPCOM    DLL        13,416  02/05/07  22:47 xpcom.dll			1.8.1.4: 2007050106
XPCOM_~1 DLL        73,848  02/05/07  22:47 xpcom_compat.dll	1.8.1.4: 2007050106
XPCOM_~2 DLL       421,488  02/05/07  22:47 xpcom_core.dll		1.8.1.4: 2007050106
XPISTUB  DLL        12,400  02/05/07  22:47 xpistub.dll		1.8.1.4: 2007050106

C:\Program Files\Mozilla Firefox\components

JAR50    DLL        66,672  02/05/07  22:47 jar50.dll			1.8.1.4: 2007050106
JSD3250  DLL        54,376  02/05/07  22:47 jsd3250.dll		1.8.1.4: 2007050106
MYSPELL  DLL        34,952  02/05/07  22:47 myspell.dll		1.8.1.4: 2007050106
SPELLCHK DLL        46,720  02/05/07  22:47 spellchk.dll		1.8.1.4: 2007050106
XPINSTAL DLL       172,144  02/05/07  22:47 xpinstal.dll		1.8.1.4: 2007050106

Comment 9

[Martijn Wargers (dead)]

The question in comment 1 was meant for timeless, because the talkback ID that was added to this bug points exactly to the same code as bug 340362 was talking about.

Comment 10

[Majken Connor [:Kensie]]

Ahh, that makes sense, sorry for the confusion.

Comment 11

[Kenneth Heal]

I learnt on the irc channel that this component is from upstream.  Here's the current upstream equivalent:
http://go-ooo.org/lxr/source/whiteboard/lingucomponent/source/spellcheck/hunspell/affixmgr.cxx

Comment 12

[Kenneth Heal]

Comparing the OOo and Mozilla code shows these differences in this section of code:

OOo

3753              // piece 4 - is number of affentries
3754              case 3: { 
3755                        np++;
3756                        numents = atoi(piece); 
3757                        if (numents == 0) {
3758                            char * err = pHMgr->encode_flag(aflag);
3759                            fprintf(stderr, "error: affix %s header has incorrect entry count in line %s\n",
3760                                    err, nl);
3761                            free(err);
3762                            return 1;
3763                        }
3764                        ptr = (struct affentry *) malloc(numents * sizeof(struct affentry));
3765                        if (!ptr) return 1;
3766                        ptr->opts = ff;
3767                        if (utf8) ptr->opts += aeUTF8;
3768                        if (pHMgr->is_aliasf()) ptr->opts += aeALIASF;
3769                        if (pHMgr->is_aliasm()) ptr->opts += aeALIASM;
3770                        ptr->aflag = aflag;
3771                      }

MOZILLA_1_8_BRANCH

1187                        case 3: { 
1188                                  np++;
1189                                  numents = atoi(piece); 
1190                                  ptr = (struct affentry *) malloc(numents * sizeof(struct affentry));
-> 1191                                  ptr->xpflg = ff;
1192                                  ptr->achar = achar;
1193                                  break;
1194                                }

Trunk

1193         // piece 4 - is number of affentries
1194         case 3: { 
1195           np++;
1196           numents = atoi(piece); 
1197           ptr = (struct affentry *) malloc(numents * sizeof(struct affentry));
1198           ptr->xpflg = ff;
1199           ptr->achar = achar;
1200           break;
1201         }

I am not a C developer so I cannot do much more other than see there is a fair bit of difference and suspect this might be a known bug for OOo which got fixed.

Comment 13

[Kenneth Heal]

http://qa.openoffice.org/issues/show_bug.cgi?id=70848 looks a bit similar

Comment 14

[Martijn Wargers (dead)]

Attachment: patch?

Kenneth, thanks for the info.
Maybe this would fix the crash, but I can't reproduce this crash at all, so I can't say.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Nemeth, is this still relevant in the Hunspell world?

Comment 16

[Németh László]

I think, not. It seems, this problem caused by low memory and the unchecked memory allocation. Now Hunspell returns an error value instead of using the NULL pointer.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

FIXED on the trunk by the Hunspell landing.