search

OpenHantek / OpenHantek6022

OpenHantek6022 is a DSO software for Hantek USB digital signal oscilloscopes 6022BE / BL. Development OS is Debian Linux, but the program also works on FreeBSD, MacOS, RaspberryPi and Windows. No support for non-Linux related issues unless a volunteer steps in!
GNU General Public License v3.0
867 stars 152 forks source link

Error in `/usr/local/bin/OpenHantek': free(): invalid next size (fast): 0xac902f10 #76

Closed LubuntuSharp closed 4 years ago

LubuntuSharp commented 4 years ago

Describe the bug An exception comes out (stack trace attached stacktrace.log )

To Reproduce This comes out quite quickly after startup; I tried to use valgrind to find out the cause but under valgrind the program can run for as long as half an hour without exceptions

System info:

OpenHantek version: OpenHantek6022-303
OS: Lubuntu 16.04
Distribution, version: x86 32 bit
Video hardware: [Intel Integrated Graphics]
QT open gl 5.5.1
C++ compiler version: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609

Scope device (please complete the following information):

Device Hantek 6022BE, ...]
Program top line [e.g. OpenHantek6022 (Build ...) - Device ... (FW 0205)]

Additional context I run with --useGLES option

Ho-Ro commented 4 years ago

Sorry to say, but I've never got this error, so I don't know how to debug it :( I saw that you use 32bit and a quite old gcc, I use gcc version 8.3.0 (Debian 8.3.0-6) from debian stable 64bit, but also clang works fine for me when initialised in directory build with CC=/usr/bin/clang CXX=/usr/bin/clang++ cmake .., maybe worth a try ... I do not use clang as default, because I want to be as close as possible to the majority of other linux users compiling with gcc, while macOSX defaults to clang.

The line add_compile_options( -D_GLIBCXX_ASSERTIONS ) in top level CMakeLists.txt adds some range checking for C++ arrays, vectors, and strings, but there's no comparable setting for the nasty malloc/free issues. If it really is a "freeing already free memory" bug very early in the program run, it's probably due to the USB handling, since all GUI stuff uses the STL or Qt high level language structures like vector<>, which can also fail, but their crash dump should point to their lib section (?) You could try the latest build, I've added some robustness against race conditions regarding buffer size changes, but these issues were triggered with very fast repetitive user interactions (e.g. switching CH2 on/off/on/off...) during normal run with a visible trace on the screen. My easy and classic "debugging" workflow was to spread printf(...) or qDebug() << ... lines all over the source code, you will detect a lot of them commented out. Also uncommenting // #define DEBUG enables the output of timestampDebug(...) and produces a lot of info about (high level) USB communication. What I also did to hunt down sporadic crashes was to build and debug directly from qtcreator (in top level type qtcreator CMakeLists.txt), setting interesting variables as volatile prevents their content from being optimised away.

Good luck :)

LubuntuSharp commented 4 years ago

Solved by upgrading QT to 5.11.1 (from 5.5.1, which from what I learned had issues with memory management); btw, now I can enjoy a much more detailed image of the signal on the scope :-) So this item can be closed, Thanks a lot for your support and for this great and useful software! Regards,