Dominique Pelle wrote:
> 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).
I located the problem: using strlen() on an int pointer. Not a good
idea! :-)
This doesn't solve the highlighting, just the potential crash.
--
DENNIS: Oh, very nice. King, eh! I expect you've got a palace and fine
clothes and courtiers and plenty of food. And how d'you get that? By
exploiting the workers! By hanging on to outdated imperialist dogma
which perpetuates the social and economic differences in our society!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
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
