Important: Please read the Qt Code of Conduct -

Debugger hangs on macOS

  • setup:

    macOS 10.14, Xcode 9.4, Qt Creator  4.14.0 w/ Qt 5.15.2 (Clang 11.0 (Apple), 64 bit), 
    building against kit 5.15.2

    up front: no i can NOT upgrade macos or xcode, not an option.


    ERROR: Lldb stderr: error: <whatever_file>.o DWARF DW_TAG_array_type DIE at <some hex> has a class/union/struct element type DIE <more hex> that is a forward declaration, not a complete definition.
    Try compiling the source file with -fstandalone-debug or disable -gmodules

    this has been - reported - and discussed - at length - many times - before.

    None of those solutions work for me, including attempting all of them at the same time. This only recently started happening, like after a SW update or Qt Creator update, it's been working fine for years, but suddenly now not.

    eg: i have a class called SuperString. When i view said class in my test app (CFTest), i can go into the class and see members and i'm a happy camper. When i attempt to view said class in my main project which is monumental in size, the debugger hangs with the wagonwheel overlay, reporting the aforementioned error.


    • all things in said file are truly declared, not forward declared, AFAIK
    • i have no idea how to "compile the source file with -fstandalone-debug" or "disable -gmodules"

    in case it matters, near startup i see this:

    ERROR: Lldb stderr: warning: 'QtCore' contains a debug script. To run this script in this debug session:
        command script import "/Users/davec/Developer/Qt/5.15.2/clang_64/lib/QtCore.framework.dSYM/Contents/Resources/DWARF/../Python/"
    To run all discovered debug scripts in this session:
        settings set target.load-script-from-symbol-file true

    also in case it matters: sometimes i do NOT see the above error, i just get this output in the debugger log:

    >(lldb) script theDumper.fetchVariables(
      "autoderef": 1,
      "context": "",
      "displaystringlimit": "1000",
      "dyntype": 0,
      "expanded": [
      "fancy": 1,
      "formats": {
        "local.ctrlRef.i_taskID": 23,
        "local.cur_pli_id": 23,
        "local.hashLL": 23,
        "local.importCodec": 23,
        "local.key": 23,
        "local.key2": 23,
        "local.menuCmd": 23,
        "local.postKey": 23,
        "local.preKey": 23,
        "local.sort_index1S": 23,
        "local.sourcesP.i_id": 23,
        "local.swapped_aliasRec.u.v2.fileType": 23,
        "local.swapped_aliasRec.u.v2.volAttrs": 23,
        "local.this.i_rowBytesL": 23,
        "local.valL": 23
      "nativemixed": 0,
      "partialvar": "local.this",
      "passexceptions": 0,
      "qobjectnames": 0,
      "stringcutoff": "10000",
      "timestamps": 0,
      "token": 253,
      "typeformats": {},
      "watchers": []

    so another part of the question is: what are all those "formats" being fetched that have nothing to do with the current stack frame?

  • i'm really at my wit's end, my project is halted. i'll PAY someone to fix this.

  • @davecotter said in Debugger hangs on macOS:

    compile the source file with -fstandalone-debug" or "disable -gmodules

    First, I feel your pain. I haven't been bit by this specific issue, but it feels reminiscent to very painful memories of similar past tribulations.

    I'm going to read through all those links you posted to past discussions.

    Firstly, though:

    compile the source file with -fstandalone-debug" or "disable -gmodules

    ^^ is there a particular reason that this would be harder than the quite normal and routine task of adding and removing various -f flags as needed?

    I can think of two answers. (1) would be that this is harder than usual because the source file is a Qt framework file instead of your own. (2) would be that even though you see this line of text recommending fstandalone-debug, your compiler actually balks when you add it?

    I would think you can add -fstandalone-debug by configuring some of the qmake variables such as QMAKE_CXXFLAGS

    ... perhaps after I read the other links I will understand why it's not that simple. Here I go reading...

  • To possibly narrow the solution space, I would say that one of your links is entirely unrelated:

    ^^ that is Linux and gdb, which is a different scenario that mac and lldb. So you can disregard that one.

  • You can also disregard this other link:

    The error(s) you report are emitted directly from lldb (and specifically an Apple version of it), so bug reports of debuggers hanging on Windows and in gdb are only superficially similar and would be essentially "red herrings" or distracting time-wasters for you.

  • Based on my reading of your two most highly-relevant links:

    I would conclude that compiling your own debug binaries of the Qt framework, (and carefully monitoring which compiler flags you use when compiling Qt) will fix this issue.

    It's disappointing that the "official" binaries provided by Qt seem to be part of this problem, but I can also understand why they would choose to customize their official binaries to target the production/release use case and not the debugging use case.

    You mention "attempting all" solutions. Did you compile the Qt framework manually from source to generate your own debug Qt?

    Again, in an ideal world I think the Qt company would have provided such suitable binaries to you (especially if you have a paid commercial license), but I mostly agree with the comment by user 1329652 on StackOverflow: "Debug builds of Qt are generally on you - for full debug information you need the trifecta: debug binaries, debug symbols, and source code"

  • hi @KH-219Design, i very much appreciate your taking the time!

    to answer your Q: "is there a particular reason that this would be hard...", the answer is "it is hard because i do not know how to do it". I did figure out the flags thing, tried that, didn't help at all. so exactly HOW do i "disable -gmodules" ?

    note i'm only compiling my own source code, i'm not caring at all about building or debugging Qt itself. "build it yourself" isn't a solution. it should work out of the box.

    here's your new car!
    umm, but the engine doesn't turn on!
    oh, yeah we know. you have to build another engine yourself.
    but.. but... it COMES WITH an engine...
    yeah sorry but the engine it comes with doesn't work.
    then why did it come with an engine???

    can others experiencing this bug please comment on it?

  • can everyone please UPVOTE THIS BUG!

    to upvote: click above link, log in (or create account) if you haven't already, then click here:



Log in to reply