Bram Moolenaar <[email protected]> wrote: > Christian Brabandt wrote: > >> > >> When using the spell correction feature ("set spelllang=de_de spell") a >> > >> word containing a german "ß" (0xDF) is displayed incorrectly if it is >> > >> found to be misspelled: >> > >> >> > >> Wir wohnen nicht in der >>>Georgenkirchstraße<<<, sondern in der >> > >> >>>Hauptstraße<<<. >> > >> >> > >> In this sample "Georgenkirchstraße" is flagged as misspelled (as >> > >> opposed to "Hauptstraße") - which would be ok - but the "ß" in the >> > >> flagged word is not considered as a valid word character; hence the >> > >> word cannot be directly added (w/o creating a selection) to the >> > >> exception list with e.g. "zg". >> > >> >> > > >> > > While I can't say anything about it, I noticed that this crashes my vim >> > > with a slight variation of the above sentence: >> > > >> > > gdb --args ./vim -u NONE -U NONE -N -c ":put ='Wir wohnen nicht in der >> > > >>>Georgenkirch straße<<<, sondern in der >>>Hauptstraße<<<'" -c 'set >> > > spell spelllang=de >> > > >> > > [Vim starts and puts that sentence in the buffer] >> > > :norm! fsz= >> > > >> > > SIGSEGV, Segmentation fault. >> > >> > ...snip... >> > >> > I also see the German eszett not being highlighted by the >> > spelling checker (bug). However, I don't see any crash using >> > Linux x86 or Linux x86_64 with Vim-7.3.515. I used the latest >> > German dictionary which Vim downloaded automatically >> > when setting ':set spelllang=de'. >> >> I guess, *smp got invalid somehow. This patch prevents, that it gets >> overwritten: >> >> diff --git a/src/spell.c b/src/spell.c >> --- a/src/spell.c >> +++ b/src/spell.c >> @@ -14766,6 +14766,9 @@ >> z = 0; >> k = 0; >> } >> + /* prevent overwriting of *smp pointer */ >> + if (smp != slang->sl_sal.ga_data) >> + smp = (salitem_T *)slang->sl_sal.ga_data; >> } > > This patch doesn't make sense. It would suggest slang->sl_sal.ga_data > is changed, or that smp is changed. I don't see how that could happen. > Could this be a memory access error? I could not reproduce it though. > > When using valgrind I do find this: > > ==22362== Conditional jump or move depends on uninitialised value(s) > ==22362== at 0x81BD866: spell_soundfold_wsal (spell.c:14741) > ==22362== by 0x81BC11B: spell_soundfold (spell.c:14106) > ==22362== by 0x81BA588: stp_sal_score (spell.c:13189) > > Since word[] is just after smp and on the stack order is reversed, I > suspect the length of the mch_memmove is wrong.
I'm not able to reproduce this Valgrind error. Nor can I reproduce the issue in this thread. For me, smp is always equal to slang->sl_sal.ga_data. Perhaps the bug happens only with some locale? What is your locale? When valgrind reports "uninitialized value(s)", it can help to add the valgrind command line option --track-origins=yes. It gives better error reporting at the cost of running slightly slower (which is why it's off by default). Regards -- Dominique -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
