smoothscroll anomolies

[Ernie Rael]

smoothscroll brings a sigh of relief. (and splitkeep is very cool). I'm
not sure if these smoothscroll issues have been mentioned; if so,
apologies for the noise.

vim 9.0.667, smoothscroll, splitkeep=screen

I've got a xxx.properties like

autoSynch=true
kind=adHoc
name=nb-full
path=file:/ref/nb/src/netbeans/apisupport/timers/ ... ~50K chars

with a monstrous last line.

Open the file, cursor on first line, enter ^E repeatedly, the screen
gets stuck on the long "path=..." line. You can put the cursor somewhere
in the middle of the long line, ^E until the cursor gets to the top and
it gets stuck.

Curiously, when the cursor is on the top line and "ft=", with ^E you can
visually see cursor go to the next line then go back. With
ft=jproperties the screen lines jump around a bit before settling.

=== possibly unrelated

I don't know if the following has anything to do with any of these new
options, but I don't remember having seen it before. Take file with a
single short line. Do "gvimdiff f1 f1". Do some ^Y. For every ^Y the
line is replicated above it and the actual file line moves down. ^E
undoes it line by line.

-ernie

[Bram Moolenaar]

Ernie Rael wrote:

> smoothscroll brings a sigh of relief. (and splitkeep is very cool). I'm
> not sure if these smoothscroll issues have been mentioned; if so,
> apologies for the noise.
>
> vim 9.0.667, smoothscroll, splitkeep=screen
>
> I've got a xxx.properties like
>
> autoSynch=true
> kind=adHoc
> name=nb-full
> path=file:/ref/nb/src/netbeans/apisupport/timers/ ... ~50K chars
>
> with a monstrous last line.
>
> Open the file, cursor on first line, enter ^E repeatedly, the screen
> gets stuck on the long "path=..." line. You can put the cursor somewhere
> in the middle of the long line, ^E until the cursor gets to the top and
> it gets stuck.

With the current version I don't see this problem. What is your
'scrolloff' set to?

> Curiously, when the cursor is on the top line and "ft=", with ^E you can
> visually see cursor go to the next line then go back. With
> ft=jproperties the screen lines jump around a bit before settling.
>
> === possibly unrelated
>
> I don't know if the following has anything to do with any of these new
> options, but I don't remember having seen it before. Take file with a
> single short line. Do "gvimdiff f1 f1". Do some ^Y. For every ^Y the
> line is replicated above it and the actual file line moves down. ^E
> undoes it line by line.

For me it crashes. I'll have a look later.

--
Facepalm reply #3: "I had a great time in Manhattan" "I thought you were
going to New York?"

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Ernie Rael]

On 10/5/22 2:15 PM, Bram Moolenaar wrote:
> Ernie Rael wrote:
>
>> smoothscroll brings a sigh of relief. (and splitkeep is very cool). I'm
>> not sure if these smoothscroll issues have been mentioned; if so,
>> apologies for the noise.
>>
>> vim 9.0.667, smoothscroll, splitkeep=screen
>>
>> I've got a xxx.properties like
>>
>> autoSynch=true
>> kind=adHoc
>> name=nb-full
>> path=file:/ref/nb/src/netbeans/apisupport/timers/ ... ~50K chars
>>
>> with a monstrous last line.
>>
>> Open the file, cursor on first line, enter ^E repeatedly, the screen
>> gets stuck on the long "path=..." line. You can put the cursor somewhere
>> in the middle of the long line, ^E until the cursor gets to the top and
>> it gets stuck.
> With the current version I don't see this problem. What is your
> 'scrolloff' set to?

scrolloff=0

I just tried

gvim -u NONE -U NONE
:set smoothscroll

Get the same screen stuck when cursor at top of screen and in a long
line with ^E behavior.

same thing with vim.

-ernie

[Ernie Rael]

I built ASAN with 9.0.669,

I tried both things, got some asan.* files. They mentiom Suppressions
used, nothing else.

I don't see the diff weirdness when I used -u NONE -U NONE, with either
vim/gvim. Get it with both vim/gvim with rc files.

You must have something that drives vim crazy in your rc.

-ernie

[Ernie Rael]

On 10/5/22 5:38 PM, Ernie Rael wrote:
> On 10/5/22 2:39 PM, Ernie Rael wrote:

>> On 10/5/22 2:15 PM, Bram Moolenaar wrote: For me it crashes.  I'll

>> have a look later.
>>>
>>
> I built ASAN with 9.0.669,
>
> I tried both things, got some asan.* files. They mentiom Suppressions
> used, nothing else.
>
> I don't see the diff weirdness when I used -u NONE -U NONE, with
> either vim/gvim. Get it with both vim/gvim with rc files.
>
> You must have something that drives vim crazy in your rc.
>
> -ernie
>

Since I was setup, I did a "make" in testdir. There was one asan problem
and some test failures that didn't seem too troubling:

=== asan ===============================================================

=================================================================
==1417488==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60b000006034 at pc 0x5600847f3392 bp 0x7ffcdd3788b0 sp 0x7ffcdd3788a0
WRITE of size 1 at 0x60b000006034 thread T0
    #0 0x5600847f3391 in utf_char2bytes /src/tools/vim/src/mbyte.c:2262
    #1 0x56008444fb67 in win_line /src/tools/vim/src/drawline.c:2824
    #2 0x5600844800e4 in win_update /src/tools/vim/src/drawscreen.c:2499
    #3 0x560084460096 in update_screen /src/tools/vim/src/drawscreen.c:326
    #4 0x5600845f64f3 in redraw_cmd /src/tools/vim/src/ex_docmd.c:8357
    #5 0x5600845f63d9 in ex_redraw /src/tools/vim/src/ex_docmd.c:8341
    #6 0x5600845b697c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #7 0x5600845a9b1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #8 0x560084e535ff in call_user_func /src/tools/vim/src/userfunc.c:2945
    #9 0x560084e55590 in call_user_func_check
/src/tools/vim/src/userfunc.c:3107
    #10 0x560084e5a3a5 in call_func /src/tools/vim/src/userfunc.c:3663
    #11 0x560084e46cb7 in get_func_tv /src/tools/vim/src/userfunc.c:1841
    #12 0x560084e6e6fa in ex_call_inner /src/tools/vim/src/userfunc.c:5647
    #13 0x560084e718e9 in ex_call /src/tools/vim/src/userfunc.c:5971
    #14 0x5600845b697c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #15 0x5600845a9b1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #16 0x5600844f1a5f in ex_execute /src/tools/vim/src/eval.c:6947
    #17 0x5600845b697c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #18 0x5600845a9b1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #19 0x560084e535ff in call_user_func /src/tools/vim/src/userfunc.c:2945
    #20 0x560084e55590 in call_user_func_check
/src/tools/vim/src/userfunc.c:3107
    #21 0x560084e5a3a5 in call_func /src/tools/vim/src/userfunc.c:3663
    #22 0x560084e46cb7 in get_func_tv /src/tools/vim/src/userfunc.c:1841
    #23 0x560084e6e6fa in ex_call_inner /src/tools/vim/src/userfunc.c:5647
    #24 0x560084e718e9 in ex_call /src/tools/vim/src/userfunc.c:5971
    #25 0x5600845b697c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #26 0x5600845a9b1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #27 0x560084b812dc in do_source_ext
/src/tools/vim/src/scriptfile.c:1667
    #28 0x560084b83255 in do_source /src/tools/vim/src/scriptfile.c:1811
    #29 0x560084b7d88c in cmd_source /src/tools/vim/src/scriptfile.c:1163
    #30 0x560084b7da5d in ex_source /src/tools/vim/src/scriptfile.c:1189
    #31 0x5600845b697c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #32 0x5600845a9b1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #33 0x5600845a75df in do_cmdline_cmd /src/tools/vim/src/ex_docmd.c:584
    #34 0x5600851731b3 in exe_commands /src/tools/vim/src/main.c:3135
    #35 0x56008516418c in vim_main2 /src/tools/vim/src/main.c:781
    #36 0x5600851634c8 in main /src/tools/vim/src/main.c:432
    #37 0x7f4aaa229d8f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
    #38 0x7f4aaa229e3f in __libc_start_main_impl ../csu/libc-start.c:392
    #39 0x5600842dded4 in _start (/src/tools/vim/src/vim+0x1322ed4)

0x60b000006034 is located 0 bytes to the right of 100-byte region
[0x60b000005fd0,0x60b000006034)
allocated by thread T0 here:
    #0 0x7f4aabeb4867 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x5600842de3af in lalloc /src/tools/vim/src/alloc.c:246
    #2 0x5600842de14e in alloc /src/tools/vim/src/alloc.c:151
    #3 0x56008444f6f7 in win_line /src/tools/vim/src/drawline.c:2802
    #4 0x5600844800e4 in win_update /src/tools/vim/src/drawscreen.c:2499
    #5 0x560084460096 in update_screen /src/tools/vim/src/drawscreen.c:326
    #6 0x5600845f64f3 in redraw_cmd /src/tools/vim/src/ex_docmd.c:8357
    #7 0x5600845f63d9 in ex_redraw /src/tools/vim/src/ex_docmd.c:8341
    #8 0x5600845b697c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #9 0x5600845a9b1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #10 0x560084e535ff in call_user_func /src/tools/vim/src/userfunc.c:2945
    #11 0x560084e55590 in call_user_func_check
/src/tools/vim/src/userfunc.c:3107
    #12 0x560084e5a3a5 in call_func /src/tools/vim/src/userfunc.c:3663
    #13 0x560084e46cb7 in get_func_tv /src/tools/vim/src/userfunc.c:1841
    #14 0x560084e6e6fa in ex_call_inner /src/tools/vim/src/userfunc.c:5647
    #15 0x560084e718e9 in ex_call /src/tools/vim/src/userfunc.c:5971
    #16 0x5600845b697c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #17 0x5600845a9b1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #18 0x5600844f1a5f in ex_execute /src/tools/vim/src/eval.c:6947
    #19 0x5600845b697c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #20 0x5600845a9b1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #21 0x560084e535ff in call_user_func /src/tools/vim/src/userfunc.c:2945
    #22 0x560084e55590 in call_user_func_check
/src/tools/vim/src/userfunc.c:3107
    #23 0x560084e5a3a5 in call_func /src/tools/vim/src/userfunc.c:3663
    #24 0x560084e46cb7 in get_func_tv /src/tools/vim/src/userfunc.c:1841
    #25 0x560084e6e6fa in ex_call_inner /src/tools/vim/src/userfunc.c:5647
    #26 0x560084e718e9 in ex_call /src/tools/vim/src/userfunc.c:5971
    #27 0x5600845b697c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #28 0x5600845a9b1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #29 0x560084b812dc in do_source_ext
/src/tools/vim/src/scriptfile.c:1667

SUMMARY: AddressSanitizer: heap-buffer-overflow
/src/tools/vim/src/mbyte.c:2262 in utf_char2bytes
Shadow bytes around the buggy address:
  0x0c167fff8bb0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c167fff8bc0: fd fd fd fd fd fd fa fa fa fa fa fa fa fa fd fd
  0x0c167fff8bd0: fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa
  0x0c167fff8be0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c167fff8bf0: fd fa fa fa fa fa fa fa fa fa 00 00 00 00 00 00
=>0x0c167fff8c00: 00 00 00 00 00 00[04]fa fa fa fa fa fa fa fa fa
  0x0c167fff8c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff8c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff8c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff8c40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff8c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==1417488==ABORTING

=== test results ==========================================================

-------------------------------
Executed:  5321 Tests
Skipped:    71 Tests
FAILED:     3 Tests


Failures:
From test_vim9_builtin.vim:
Found errors in Test_remote_expr():
command line..script
/src/tools/vim/src/testdir/runtest.vim[515]..function
RunTheTest[52]..Test_remote_expr[7]..<SNR>10_CheckDefExecAndScriptFailure[13]..<SNR>10_CheckDefExecFailure
line 7: ['remote_expr("", "")']: Expected 'E241: Unable to send to ' but
got 'E449: Invalid expression received': ['remote_expr("", "")']
command line..script
/src/tools/vim/src/testdir/runtest.vim[515]..function
RunTheTest[52]..Test_remote_expr[7]..<SNR>10_CheckDefExecAndScriptFailure[14]..<SNR>10_CheckScriptFailure
line 6: ['vim9script', 'remote_expr("", "")']: Expected 'E241: Unable to
send to ' but got 'E449: Invalid expression received': ['vim9script',
'remote_expr("", "")']
Found errors in Test_remote_foreground():
command line..script
/src/tools/vim/src/testdir/runtest.vim[515]..function
RunTheTest[52]..Test_remote_foreground line 8: command did not fail:
remote_foreground("")
Found errors in Test_remote_send():
command line..script
/src/tools/vim/src/testdir/runtest.vim[515]..function
RunTheTest[52]..Test_remote_send line 6: command did not fail:
remote_send("", "")

TEST FAILURE
make: *** [Makefile:53: report] Error 1

[Bram Moolenaar]

Ernie Rael wrote:

> > I built ASAN with 9.0.669,
> >

> > I tried both things, got some asan.* files. They mentiom Suppressions=20
> > used, nothing else.
> >
> > I don't see the diff weirdness when I used -u NONE -U NONE, with=20

> > either vim/gvim. Get it with both vim/gvim with rc files.
> >
> > You must have something that drives vim crazy in your rc.
> >
> > -ernie
> >
> Since I was setup, I did a "make" in testdir. There was one asan problem
> and some test failures that didn't seem too troubling:

For an ASAN log to be useful, I need a way to reproduce it. Ideally a
short script. Or, when it is from running tests, which test. I then
still have to binary search for the cause (commenting out parts of the
testa), which can take time.

On CI there is also a run with ASAN, thus normally things are caught
there.


--
Facepalm statement #5: "Petrol getting more expensive? Not for me, I'm always
tanking for 20 dollars"

[Ernie Rael]

On 10/5/22 2:39 PM, Ernie Rael wrote:

Just tried with 9.0.677. Same thing.

Note that if the long line is not the last line it behaves differently.
If the long line does not extend past the end of the screen it works.

-ernie

[Ernie Rael]

On 10/6/22 3:39 AM, Bram Moolenaar wrote:
> Ernie Rael wrote:
>
>>> I built ASAN with 9.0.669,
>>>

>> Since I was setup, I did a "make" in testdir. There was one asan problem
>> and some test failures that didn't seem too troubling:
> For an ASAN log to be useful, I need a way to reproduce it. Ideally a
> short script. Or, when it is from running tests, which test. I then
> still have to binary search for the cause (commenting out parts of the
> testa), which can take time.

Is there a way to associate an asan.### file with a particular test? I
tried doing "ls -lt" and occasionally you can see a some_test.res file
interspersed with the asan files. Something like a timestamp (optional?)
column in messages would do the trick. That would narrow things down to
a few tests.

-ernie

[Ernie Rael]

Any hints for tracking this down?

If I get some time, some ideas on where to put breakpoints would be
useful. (have to remember how to use termdebug)

-ernie

[Ernie Rael]

Tracked down the specific test within a particluar test file

$ make test_listlbr_utf8
00:00 Executing Test_linebreak_with_list_and_tabs()

This test has a checkered past

" this was causing a crash
func Test_linebreak_with_list_and_tabs()

While it's failing here, it there more info I can gather.

=================================================================
==1565972==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60b000001e34 at pc 0x55ef60917392 bp 0x7ffd02091160 sp 0x7ffd02091150
WRITE of size 1 at 0x60b000001e34 thread T0
    #0 0x55ef60917391 in utf_char2bytes /src/tools/vim/src/mbyte.c:2262
    #1 0x55ef60573b67 in win_line /src/tools/vim/src/drawline.c:2824
    #2 0x55ef605a40e4 in win_update /src/tools/vim/src/drawscreen.c:2499
    #3 0x55ef60584096 in update_screen /src/tools/vim/src/drawscreen.c:326
    #4 0x55ef6071a4f3 in redraw_cmd /src/tools/vim/src/ex_docmd.c:8357
    #5 0x55ef6071a3d9 in ex_redraw /src/tools/vim/src/ex_docmd.c:8341
    #6 0x55ef606da97c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #7 0x55ef606cdb1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #8 0x55ef60f775ff in call_user_func /src/tools/vim/src/userfunc.c:2945
    #9 0x55ef60f79590 in call_user_func_check
/src/tools/vim/src/userfunc.c:3107
    #10 0x55ef60f7e3a5 in call_func /src/tools/vim/src/userfunc.c:3663
    #11 0x55ef60f6acb7 in get_func_tv /src/tools/vim/src/userfunc.c:1841
    #12 0x55ef60f926fa in ex_call_inner /src/tools/vim/src/userfunc.c:5647
    #13 0x55ef60f958e9 in ex_call /src/tools/vim/src/userfunc.c:5971
    #14 0x55ef606da97c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #15 0x55ef606cdb1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #16 0x55ef60615a5f in ex_execute /src/tools/vim/src/eval.c:6947
    #17 0x55ef606da97c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #18 0x55ef606cdb1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #19 0x55ef60f775ff in call_user_func /src/tools/vim/src/userfunc.c:2945
    #20 0x55ef60f79590 in call_user_func_check
/src/tools/vim/src/userfunc.c:3107
    #21 0x55ef60f7e3a5 in call_func /src/tools/vim/src/userfunc.c:3663
    #22 0x55ef60f6acb7 in get_func_tv /src/tools/vim/src/userfunc.c:1841
    #23 0x55ef60f926fa in ex_call_inner /src/tools/vim/src/userfunc.c:5647
    #24 0x55ef60f958e9 in ex_call /src/tools/vim/src/userfunc.c:5971
    #25 0x55ef606da97c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #26 0x55ef606cdb1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #27 0x55ef60ca52dc in do_source_ext
/src/tools/vim/src/scriptfile.c:1667
    #28 0x55ef60ca7255 in do_source /src/tools/vim/src/scriptfile.c:1811
    #29 0x55ef60ca188c in cmd_source /src/tools/vim/src/scriptfile.c:1163
    #30 0x55ef60ca1a5d in ex_source /src/tools/vim/src/scriptfile.c:1189
    #31 0x55ef606da97c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #32 0x55ef606cdb1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #33 0x55ef606cb5df in do_cmdline_cmd /src/tools/vim/src/ex_docmd.c:584
    #34 0x55ef612971b3 in exe_commands /src/tools/vim/src/main.c:3135
    #35 0x55ef6128818c in vim_main2 /src/tools/vim/src/main.c:781
    #36 0x55ef612874c8 in main /src/tools/vim/src/main.c:432
    #37 0x7fb19ea29d8f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
    #38 0x7fb19ea29e3f in __libc_start_main_impl ../csu/libc-start.c:392
    #39 0x55ef60401ed4 in _start (/src/tools/vim/src/vim+0x1322ed4)

0x60b000001e34 is located 0 bytes to the right of 100-byte region
[0x60b000001dd0,0x60b000001e34)

allocated by thread T0 here:

    #0 0x7fb1a06b4867 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55ef604023af in lalloc /src/tools/vim/src/alloc.c:246
    #2 0x55ef6040214e in alloc /src/tools/vim/src/alloc.c:151
    #3 0x55ef605736f7 in win_line /src/tools/vim/src/drawline.c:2802
    #4 0x55ef605a40e4 in win_update /src/tools/vim/src/drawscreen.c:2499
    #5 0x55ef60584096 in update_screen /src/tools/vim/src/drawscreen.c:326
    #6 0x55ef6071a4f3 in redraw_cmd /src/tools/vim/src/ex_docmd.c:8357
    #7 0x55ef6071a3d9 in ex_redraw /src/tools/vim/src/ex_docmd.c:8341
    #8 0x55ef606da97c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #9 0x55ef606cdb1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #10 0x55ef60f775ff in call_user_func /src/tools/vim/src/userfunc.c:2945
    #11 0x55ef60f79590 in call_user_func_check
/src/tools/vim/src/userfunc.c:3107
    #12 0x55ef60f7e3a5 in call_func /src/tools/vim/src/userfunc.c:3663
    #13 0x55ef60f6acb7 in get_func_tv /src/tools/vim/src/userfunc.c:1841
    #14 0x55ef60f926fa in ex_call_inner /src/tools/vim/src/userfunc.c:5647
    #15 0x55ef60f958e9 in ex_call /src/tools/vim/src/userfunc.c:5971
    #16 0x55ef606da97c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #17 0x55ef606cdb1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #18 0x55ef60615a5f in ex_execute /src/tools/vim/src/eval.c:6947
    #19 0x55ef606da97c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #20 0x55ef606cdb1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #21 0x55ef60f775ff in call_user_func /src/tools/vim/src/userfunc.c:2945
    #22 0x55ef60f79590 in call_user_func_check
/src/tools/vim/src/userfunc.c:3107
    #23 0x55ef60f7e3a5 in call_func /src/tools/vim/src/userfunc.c:3663
    #24 0x55ef60f6acb7 in get_func_tv /src/tools/vim/src/userfunc.c:1841
    #25 0x55ef60f926fa in ex_call_inner /src/tools/vim/src/userfunc.c:5647
    #26 0x55ef60f958e9 in ex_call /src/tools/vim/src/userfunc.c:5971
    #27 0x55ef606da97c in do_one_cmd /src/tools/vim/src/ex_docmd.c:2561
    #28 0x55ef606cdb1a in do_cmdline /src/tools/vim/src/ex_docmd.c:990
    #29 0x55ef60ca52dc in do_source_ext

/src/tools/vim/src/scriptfile.c:1667

SUMMARY: AddressSanitizer: heap-buffer-overflow
/src/tools/vim/src/mbyte.c:2262 in utf_char2bytes
Shadow bytes around the buggy address:

  0x0c167fff8370: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c167fff8380: fd fd fd fd fd fd fa fa fa fa fa fa fa fa fd fd
  0x0c167fff8390: fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa
  0x0c167fff83a0: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c167fff83b0: fd fa fa fa fa fa fa fa fa fa 00 00 00 00 00 00
=>0x0c167fff83c0: 00 00 00 00 00 00[04]fa fa fa fa fa fa fa fa fa
  0x0c167fff83d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff83e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff83f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff8400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c167fff8410: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc

==1565972==ABORTING

[Bram Moolenaar]

> On 10/7/22 9:46 AM, Ernie Rael wrote:
> > On 10/6/22 3:39 AM, Bram Moolenaar wrote:
> >> Ernie Rael wrote:
> >>
> >>>> I built ASAN with 9.0.669,
> >>>>

> >>> Since I was setup, I did a "make" in testdir. There was one asan=20

> >>> problem
> >>> and some test failures that didn't seem too troubling:
> >> For an ASAN log to be useful, I need a way to reproduce it. Ideally a
> >> short script.  Or, when it is from running tests, which test. > I then
> >> still have to binary search for the cause (commenting out parts of the
> >> testa), which can take time.
> >
> > Is there a way to associate an asan.### file with a particular test? I
> > tried doing "ls -lt" and occasionally you can see a some_test.res file
> > interspersed with the asan files. Something like a timestamp
> > (optional?) column in messages would do the trick. That would narrow
> > things down to a few tests.
> >
> > -ernie
>
> Tracked down the specific test within a particluar test file
>
> $ make test_listlbr_utf8
> 00:00 Executing Test_linebreak_with_list_and_tabs()
>
> This test has a checkered past
>
> " this was causing a crash
> func Test_linebreak_with_list_and_tabs()
>
> While it's failing here, it there more info I can gather.
>
> =========================> =========================> ===============
> ==1565972==ERROR: AddressSanitizer: heap-buffer-overflow on address>
> 0x60b000001e34 at pc 0x55ef60917392 bp 0x7ffd02091160 sp 0x7ffd02091150
> WRITE of size 1 at 0x60b000001e34 thread T0

>     #0 0x55ef60917391 in utf_char2bytes /src/tools/vim/src/> mbyte.c:2262
>     #1 0x55ef60573b67 in win_line /src/tools/vim/src/drawli> ne.c:2824

>     #2 0x55ef605a40e4 in win_update /src/tools/vim/src/draw

[...]

> 0x60b000001e34 is located 0 bytes to the right of 100-byte region
> [0x60b000001dd0,0x60b000001e34)
> allocated by thread T0 here:
>     #0 0x7fb1a06b4867 in __interceptor_malloc
> ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     #1 0x55ef604023af in lalloc /src/tools/vim/src/alloc.c:> 246
>     #2 0x55ef6040214e in alloc /src/tools/vim/src/alloc.c:1> 51

>     #3 0x55ef605736f7 in win_line /src/tools/vim/src/drawli> ne.c:2802

>     #4 0x55ef605a40e4 in win_update /src/tools/vim/src/draw> screen.c:2499

This would mean that the line:

p = alloc(len + 1);

in drawline.c, now at line 2814, does not allocate enough. "len" is
computed from the size of w_lcs_chars.tab2, but it may also use
wp->w_lcs_chars.tab3, perhaps it takes more bytes?
Could change this line:

len = (tab_len * mb_char2len(wp->w_lcs_chars.tab2));

into:

len = (tab_len * mb_char2len(wp->w_lcs_chars.tab2)
+ mb_char2len(wp->w_lcs_chars.tab3));

I cannot reproduce it, can you try this change?



--
FATHER: Make sure the Prince doesn't leave this room until I come and
get him.
FIRST GUARD: Not ... to leave the room ... even if you come and get him.
FATHER: No. Until I come and get him.
SECOND GUARD: Hic.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Bram Moolenaar]

Ernie Rael wrote:

> >>> I built ASAN with 9.0.669,
> >>>
> >> Since I was setup, I did a "make" in testdir. There was one asan problem
> >> and some test failures that didn't seem too troubling:
> > For an ASAN log to be useful, I need a way to reproduce it. Ideally a
> > short script. Or, when it is from running tests, which test. I then
> > still have to binary search for the cause (commenting out parts of the
> > testa), which can take time.
>
> Is there a way to associate an asan.### file with a particular test? I
> tried doing "ls -lt" and occasionally you can see a some_test.res file
> interspersed with the asan files. Something like a timestamp (optional?)
> column in messages would do the trick. That would narrow things down to
> a few tests.

This is one of the reasons I use valgrind when possible. It's slow to
execute, but it doesn't require compiling everything and gives more
to-the-point information. But ASAN can catch different things, e.g. for
items on the stack.

AFAIK that number is the process ID, which is sequentially increasing,
but otherwise does not point to a specific test. Executing tests one by
one to narrow it down. Then commenting-out test functions to find out
where it happens, the commenting out lines to pinpoint it... It takes a
bit of effort.

--
FATHER: One day, lad, all this will be yours ...
PRINCE: What - the curtains?

[Ernie Rael]

That change gets rid of the failure. Looking at the code, I noticed that

            if (wlv.n_extra > 0)
                len += wlv.n_extra - tab_len;
could conceivably make len smaller. I put in

            if(wlv.n_extra - tab_len < 0) abort();
and the test crashes

-ernie

[Bram Moolenaar]

Adding a ch_log() call:
n_extra: 39, tab_len: 99

I don't quite understand the computations. In the loop wlv.n_extra is
incremented less if n_extra was non-zero before:

wlv.n_extra += mb_char2len(lcs)
- (saved_nextra > 0 ? 1 : 0);

I guess this is for when 'linebreak' is used.

The loop also bails out when running into the NUL:

if (*p == NUL)
{
tab_len = i;
break;
}

I don't know when that would happen or why. It won't work when "len" is
a bit more than needed (which happens when w_lcs_chars.tab3 is set).

I believe Christian wrote this, perhapsh he can explain. And add a few
comments to explain the computations.


--
You had connectors? Eeee, when I were a lad we 'ad to carry the
bits between the computer and the terminal with a spoon...

[Bram Moolenaar]

One thing I had nog thought of: this part of code is also executed when
tab_len is zero. Now that I computed the length correctly, it turned
zero (the second character takes two bytes, the third one byte,
resulting in length -1).

Skipping the code when tab_len is zero may fix the original problem
as well.

--
You were lucky. We lived for three months in a brown paper bag in a
septic tank. We used to have to get up at six o'clock in the morning,
clean the bag, eat a crust of stale bread, go to work down mill for
fourteen hours a day week in-week out. When we got home, our Dad
would thrash us to sleep with his belt!

[Ernie Rael]

On 10/7/22 2:28 PM, Bram Moolenaar wrote:

With patches

patch 9.0.0690: buffer size for expanding tab not correctly computed
patch 9.0.0691: lalloc(0) error in listchars test

test don't fail in my setup anymore. (no surprise)

-ernie

[Christian Brabandt]

On Sa, 08 Okt 2022, Bram Moolenaar wrote:

> I don't know when that would happen or why. It won't work when "len" is
> a bit more than needed (which happens when w_lcs_chars.tab3 is set).
>
> I believe Christian wrote this, perhapsh he can explain. And add a few
> comments to explain the computations.

Honestly, I do not remember and this was written before w_lcs_chars.tab3
existed.

I just remember that when I wrote it, I run into several corner cases
which would break displaying a line. But this may very well be a bug.
and this was around 10 years ago :(

Best,
Christian
--
Je größer die Achtung vor dem Menschenleben wird, desto geringer
wird die Achtung vor dem Tod.
-- Edmond & Jules de Goncourt

[Bram Moolenaar]

Should work better after patch 9.0.0701

--
FIRST GUARD: Ah! Now ... we're not allowed to ...
SIR LAUNCELOT runs him through, grabs his spear and stabs the other
guard who collapses in a heap. Hiccoughs quietly.

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD