#715784 [Mayhem] Bug report on dawgdic-tools: dawgdic-find crashes with exit status 139

Package:
dawgdic-tools
Source:
dawgdic
Description:
command line tools for DAWG dictionaries
Submitter:
Alexandre Rebert
Date:
2025-05-12 17:33:03 UTC
Severity:
normal
Tags:
#715784#5
Date:
2013-07-10 15:36:28 UTC
From:
To:
dawgdic-find crashes with exit status 139. We confirmed the crash by
re-running it in a fresh debian unstable installation.

The attachment [1] contains a testcase (under ./crash) crashing the
program. It ensures that you can easily reproduce the bug. Additionally,
under ./crash_info/, we include more information about the crash such as
a core dump, the dmesg generated by the crash, and its output.

Regards,
The Mayhem Team (Alexandre Rebert, Thanassis Avgerinos, Sang Kil Cha, David Brumley, Manuel Egele)
Cylab, Carnegie Mellon University

[1] http://www.forallsecure.com/bug-reports/12670e1c73290947f48a92a09dd0429017c89f2b/full_report

#715784#12
Date:
2024-11-13 18:54:56 UTC
From:
To:
I was able to replicate the crash with valgrind:

==419028== Memcheck, a memory error detector
==419028== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==419028== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==419028== Command: ../../obj/src/dawgdic-find
==419028==
==419028== Invalid read of size 4
==419028==    at 0x10AA4D: offset (dictionary-unit.h:60)
==419028==    by 0x10AA4D: Follow (dictionary.h:129)
==419028==    by 0x10AA4D: FindPrefixKeys (dawgdic-find.cc:109)
==419028==    by 0x10AA4D: main (dawgdic-find.cc:208)
==419028==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==419028==
==419028==
==419028== Process terminating with default action of signal 11 (SIGSEGV)
==419028==  Access not within mapped region at address 0x0
==419028==    at 0x10AA4D: offset (dictionary-unit.h:60)
==419028==    by 0x10AA4D: Follow (dictionary.h:129)
==419028==    by 0x10AA4D: FindPrefixKeys (dawgdic-find.cc:109)
==419028==    by 0x10AA4D: main (dawgdic-find.cc:208)
==419028==  If you believe this happened as a result of a stack
==419028==  overflow in your program's main thread (unlikely but
==419028==  possible), you can try to increase the size of the
==419028==  main thread stack using the --main-stacksize= flag.
==419028==  The main thread stack size used in this run was 8388608.
==419028==
==419028== HEAP SUMMARY:
==419028==     in use at exit: 77,855 bytes in 4 blocks
==419028==   total heap usage: 4 allocs, 0 frees, 77,855 bytes allocated
==419028==
==419028== LEAK SUMMARY:
==419028==    definitely lost: 0 bytes in 0 blocks
==419028==    indirectly lost: 0 bytes in 0 blocks
==419028==      possibly lost: 0 bytes in 0 blocks
==419028==    still reachable: 77,855 bytes in 4 blocks
==419028==         suppressed: 0 bytes in 0 blocks
==419028== Rerun with --leak-check=full to see details of leaked memory
==419028==
==419028== For lists of detected and suppressed errors, rerun with: -s
==419028== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
./crash.sh: line 20: 419028 Segmentation fault      (core dumped) env -i MALLOC_CHECK_=0 $GDB ../../obj/src/dawgdic-find < "$DIR/file___dev__stdin.symb"

No idea how to fix it, but at least it give an idea where the crash
happen with version 0.4.5-3.

#715784#17
Date:
2025-05-11 20:14:13 UTC
From:
To:
This specific issue is claimed to be fixed upstream, with some caveats.