On Thu, 20 May 2021 13:04:08 -0400
"Greg Reagle" <list_AT_speedpost.net> wrote:
> I have used dvtm in the past but gave up because of crashes that were
> unpredictable. I know C and I have recently learned a bit more about
> gdb and core dumps and debugging
Enable coredumps (`ulimit -c unlimited` works for the current shell
session), run dvtm, and examine the backtrace in gdb when it crashes.
Reply if you need help understanding the backtrace. If you get lines
full of question marks and no symbols, you'll want to ensure that dvtm
is compiled with debugging symbols and that they are not stripped out
of the binary or any other libraries that dvtm is dependent on.
> So my first question: Is there any consistently reproducible bug in
> dvtm? I use Debian stable (I can use the latest git version of dvtm
> of course). My other question: Would it be possible or a good idea
> to use the fuzz program to fuzz test it? Would there be a better way
> to fuzz test it?
Using git master would definitely be advised. Running it under valgrind
would also help pinpoint places in the code that try working with
uninitialised memory. Of course you can fuzz input to dvtm while
valgrind is analysing it to run it through its paces; just note that
fuzzing and "consistently reproducible" are mutually exclusive.
--
wowaname <https://wowana.me/pgp.xht>
Received on Sun Jun 20 2021 - 22:34:45 CEST