Dominique Pelle wrote:
> Valgrind memory checker reports the following error:
>
> ==10724== Conditional jump or move depends on uninitialized value(s)
> ==10724== at 0x810A1EB: utf_off2cells (mbyte.c:1338)
> ==10724== by 0x815265C: screen_puts_len (screen.c:6326)
> ==10724== by 0x80EE251: screen_puts_mbyte (message.c:1684)
> ==10724== by 0x80EE6FE: msg_puts_display (message.c:1907)
> ==10724== by 0x80EE4B7: msg_puts_attr_len (message.c:1819)
> ==10724== by 0x80EE3F9: msg_puts_attr (message.c:1767)
> ==10724== by 0x80EE2E5: msg_puts (message.c:1717)
> ==10724== by 0x81A4A3A: version_msg (version.c:1184)
> ==10724== by 0x81A499C: list_version (version.c:1151)
> ==10724== by 0x81A46DC: ex_version (version.c:876)
> ==10724== by 0x809A1FB: do_one_cmd (ex_docmd.c:2622)
> ==10724== by 0x8097B18: do_cmdline (ex_docmd.c:1100)
> ==10724== by 0x80971E6: do_cmdline_cmd (ex_docmd.c:706)
> ==10724== by 0x80D752C: exe_commands (main.c:2638)
> ==10724== by 0x80D54F6: main (main.c:874)
>
> Error can be reproduced by simply running the ":version"
> command with the following conditions:
> - vim must be built with multi-byte support (error does not
> happen without multi-byte support)
> - terminal must be small (4 lines or less). Error does
> not happen in terminal larger than 4 lines.
>
> In a small xterm 80 columns x 4 lines, I can get the
> error with the following command:
>
> valgrind --num-callers=18 ./vim -u NONE -c ':version' 2> vg.log
>
> The relevant code is:
>
> mbyte.c:
>
> 1334 int
> 1335 utf_off2cells(off)
> 1336 unsigned off;
> 1337 {
> !!1338 return ScreenLines[off + 1] == 0 ? 2 : 1;
> 1339 }
>
> By adding some printf, I can see that 'off' parameter is
> initialized, but ScreenLines[off + 1] is uninitialized
> when accessed at line mbyte.c:1338.
>
> Adding some printf(), I can see that when error happens,
> off value is 319, so line mbyte.c:1338 accesses ScreenLines[320]
> which is uninitialized. 320 happens to match the size of my
> small terminal 80x4 = 320).
>
> From what I understand (I could be wrong), some Unicode characters
> may occupies two cells on the screen. I'm not sure what happens
> if such character was in the last cell of the screen (bottom
> right of terminal) or if such character was in the last column
> of any row of the screen. It looks like function utf_off2cells()
> accesses one cell beyond the screen to check for double cell
> Unicode characters.
That should not happen. The last cell in the line can never contain a
double-width character. Thus the check should not be done there.
> I also see that function screen_char_2() which writes into the
> screen ScreenLines[] handles last character of the screen
> specially to avoid scroll up (it avoids writing in last
> character).
>
> I can fix the error reported by valgrind with the attached
> patch, but I do not understand screen.c enough to say whether
> it's the correct approach or not.
It's not actually correct, although it probably works. You check if you
don't go past the end of the screen, but the check needed is to verify
we don't go past the end of the line. Since the first cell in the next
line is never the second half of a double-width character, your check
would also work.
Perhaps you can add a "max_off" variable, set to LineOffset[row] +
screen_Columns. Then avoid calling mb_off2cells(off) when off is
max_off - 2 or more.
--
The term "free software" is defined by Richard M. Stallman as
being software that isn't necessarily for free. Confusing?
Let's call it "Stallman software" then!
-- Bram Moolenaar
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
