Re: SIGBUS in Vim 7.4

Frew Schmidt <frioux@gmail.com> wrote:

> On Tuesday, May 10, 2016 at 11:03:45 PM UTC-7, Dominique Pelle wrote:
>> Frew Schmidt wrote:
>>
>> > Ok, so I built and installed a fresh vim according to
>> > Dominique's instructions and attempted both asan and valgrind.
>> > Either those things don't work together, or I can repro the bug
>> > immediately. Here's the error:
>>
>> I should have said: valgrind and asan don't work together indeed.
>> Either use a asan build, or use valgrind on a normal build (not stripped).
>>
>> Actually trying both tools (but not a the same time!) can be
>> useful as some bugs are only found by one tool:
>> - asan cannot find accesses to uninitialized memory
>> - valgrind cannot find overflow to global and stack variables
>>
>> > Note that this issue is *very* rare, maybe happens every few weeks,
>>
>> It's likely to be easier to reproduce i.e less rare with asan or valgrind,
>> as any access to freed memory will be detected for example, whereas
>> without such tools, vim may often work by luck and once in a while
>> crash.
>>
>> Regards
>> Dominique
>
> Ok, well I'll be running with the asan version till it happens again.
> If it doesn't happen in about a month I'll switch to the valgrind version.

Thanks. I should add: asan writes errors (if any) on stderr by default,
and since vim puts the terminal in cooked mode, asan error can be
garbled. So it's best to redirect stderr. The ASAN_OPTIONS
environment variable can be used for this. I put this in my ~/.bashrc:

export ASAN_OPTIONS="check_initialization_order=1:strict_init_order=1:detect_stack_use_after_return=1:detect_leaks=0:log_path=/home/pel/asan.log:abort_on_error=1"

The relevant part to redirect errors is "log_path=/home/pel/asan.log"
(obviously you can put a different file name)

See https://github.com/google/sanitizers/wiki/AddressSanitizerFlags
for more details.

> FWIW though, I suspect that a skilled practitioner might be able
> to suss out the actual cause of the bug with the coredump I already have.

It may not be so easy with a gdb stack alone: the memory error may
have happened much earlier than where the crash is detected in gdb.
That's why asan helps: if freed memory is accessed for example, the
error will be reported immediately when accessed, and asan will give
more information:
- the stack where freed memory is accessed
- the stack where memory was previously freed
- the stack where memory was previously allocated

Regards
Dominique

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.