On Thu, 20 May 2021 13:04:08 -0400 "Greg Reagle" <l...@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>