@hwd8868 I had the same problem. Manually adding opencvtypes.py file into /usr/share/qtcreator/debugger/ resolved the problem

Hi, Why not use a more recent version of Qt Creator ? Beside that, what compiler are you using ?

@aha_1980 : I just noticed something else: In the log file, there are lines saying "GDB 71101", presumably because it is using v7.11.1 (?!). But I have installed GDB v8.2 in both usr/bin and usr/local/bin. And I've set those locations in QtCreator's options pages for kits and for debuggers. There should be no way for QtCreator to find an older GDB version. The GDB version in both usr/ folders above is 8.2, confirmed by running via terminal. And I did not find any older stray 7.11.1 versions that QtCreator could be picking up. Another oddity. Is there any other options page where the GDB location needs to be set?

By build a debug version do you mean adding -DDEBUG -g to CFLAGS in my makefile? Hooray! Adding the -DDEBUG -g flags to my makefile fixed it! Thank you @aha_1980! I googled for this but nothing really came up, thanks!

I tried to investigate the issue further and figured out the following: it seems to be a problem with gdb and its disassembler when I start gdb in the console, it doesn't show me where the crash occurs, too in the debugger log, I get an error message "Disassembler failed" I tried also on another VM (Win 10, also) and a Win 7 Desktop and it works on the VM, however not on the Desktop and my first VM. I have no clue what the differences between these installations are :-( Is anyone aware of any Windows/Qt/MinGW settings that could make the disassembler fail? Thanks for any ideas, Sebastian

Any ideas? The same question had been brought up at the Qt mailing list years ago: http://lists.qt-project.org/pipermail/interest/2015-September/018826.html But the things suggested there did not helped me. Adding an expression for the d pointers did not help either.

Apparently related to: https://bugreports.qt.io/browse/QTCREATORBUG-17254

Hi, I found your topic and i have a problem with a SIGSEGV at the start of qt application when i used gdb. Your patch work with a previous problem i have with breakpoints but no with this one so have you an idea ? I'm using an imx6 platform with EGLFS and when upgrading Qt from 5.3.2 to 5.5.1, I can't start a debug. I try to backtrace in qtcreator but i can't find anything to help. Thanks, Here it's a part of gdb log. >909-exec-run Process AW_APP created; pid = 1370 >library-loaded,id="/lib/ld-linux-armhf.so.3",target-name="/lib/ld-linux-armhf.so.3",host-name="/opt/fsl-imx-fb/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/lib/ld-linux-armhf.so.3",symbols-loaded="0",thread-group="i1" Library /lib/ld-linux-armhf.so.3 loaded >909^running dNOTE: ENGINE RUN AND INFERIOR RUN OK sRunning. dState changed from EngineRunRequested(7) to InferiorRunOk(11) [master] dINFERIOR STARTED sDémarrage de l'application >*running,thread-id="all" dNOTE: INFERIOR STILL RUNNING IN STATE InferiorRunOk. >~"\nProgram received signal " >~"SIGSEGV, Segmentation fault.\n" >~"0x4dca9e24 in ?? ()\n" >*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x4dca9e24",func="??",args=[]},thread-id="1",stopped-threads="all",core="0" dNOTE: INFERIOR SPONTANEOUS STOP sStopped. > 914bt full >&"bt full\n" >~"#-1 0x4dca9e24 in ?? ()\n" >~"No symbol table info available.\n" >&"warning: Unable to restore previously selected frame.\n" Unable to restore previously selected frame. >914^done

Thanks for your advise. I'll try it.

me too facing same problem. is there any solutions.

@kuzulis I downloaded the versions of gdb and python as mentioned in the script you mentioned . now my project is working fine. I used this link to install gdb .

@Tusharh Hi and welcome to devnet A featrure as you request may be latest with larger projects too much for the debugger to handle. The closest to get such a behaviour is to use F11 and Shift+F11. F11 will enter every possible method and Shift+F11 will help you to run the remainder of the method. IMO sufficient enough to get a really detailed anaylsis of source code.

It was because I was in instruction-wise operation mode. Unchecking Debug → Operate By Instruction solved my problem.

Figured out the solution. In GDB, the option, load .gdbinit file on gdb startup was selected, but I did not have .gdbinit file, hence it was timing out searching for that file. I just unchecked that option and now it works just fine.