On Fri, 2017-08-04 at 23:20 +0200, Yury V. Zaytsev wrote:

> The most obvious reason for the segfault would have been that somebody has 
> freed `view->filename_vpath` without setting it to NULL, but a quick grep 
> for `->filename_vpath` doesn't reveal anything suspicious :-(

Discussion on IRC made us think that it was using memory that has been
allocated but not initialised, because the MALLOC_PERTURB_=254
MALLOC_CHECK_=2 combination causes glibc to poison new memory
allocations with 0xFE and if you then see 0xFE anywhere, that means
that the program is buggy and interacting with uninitialised memory.


> So this makes me think that maybe something else corrupted the memory 
> indirectly, but then I can't see how this can be reasonably investigated 
> without a sanitizer like report or even better a reproducer...

The issue is easily reproducible for me and I think you could reproduce
it by introducing a 5 second sleep call just before the panel setup.

PS: you might be interested in the valgrind output for one of the
sessions where I was able to press Ctrl+x q early enough. The log
clearly shows that valgrind found a number of invalid reads.


PS: I would suggest running the mc code through some static analysis
tools, either via check-all-the-things or by manually running the tools
listed in these two configuration files:


If you are fine with using proprietary services to improve free code,
you could look at Coverity. You could also get Google to do some
fuzzing of the mc codebase.




Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to