> On 10/7/22 2:28 PM, Bram Moolenaar wrote:
> >> 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?
> >
> >
> >
> 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
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 -- [email protected] -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20221008101127.680211C0592%40moolenaar.net.
