Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-40585

OS X 10.9+: Warning / Crash with modal windows

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2: Important
    • Resolution: Done
    • Affects Version/s: 4.8.7, 5.4.1
    • Fix Version/s: None
    • Component/s: GUI: Window management
    • Labels:
      None
    • Environment:
      OS X 10.9.5 or OS X 10.10.3
    • Platform/s:
      macOS

      Description

      Hello. There have been multiple bugs reported (QTBUG-32943 and QTBUG-37699 come to mind offhand) regarding some warnings and crashes that occur in Qt when on OS X Mavericks (10.9) or, at least in its current state, Yosemite (10.10). This is still happening on Qt4 and Qt5. In particular, whenever I close a window, I usually see the following message when running the program from the command line. (CAVEAT: This program uses Qt 4.8.7 with the backported patch I posted under QTBUG-37699, which makes the accompanying "modalSession has been exited prematurely - check for a reentrant call to endModalSession:" messages go away. However, with or without the patch, crashes will occur.)


      2014-08-04 13:29:25.376 Python[71022:507] -[NSApplication runModalSession:]: Use of freed session detected. Do not call runModalSession: after calling endModalSesion:.

      On occasion, the window closure is accompanied by a crash. This seems to be random. I haven't really seen it myself but I know other users have run into it more frequently.

      I believe I've finally fixed this issue. I've attached a patch that makes the warnings go away on my system. (I haven't seen any crashes yet but it's still too early to tell.) I'll also see about getting the code submitted for a code review.

      Here's what seems to be happening, partially based off discussions I've had with other developers. Under QEventDispatcherMac::processEvents() (Qt4)/QCocoaEventDispatcher::processEvents() (Qt5), there's an if/else statement which checks the "canExec_Qt" and "canExec_3rdParty" variables. The if condition includes a while loop where qt_mac_waitForMoreModalSessionEvents() (Qt4)/qt_mac_waitForMoreEvents() (Qt5) keeps getting called. Somehow, processEvents() gets called again, and everything seems to get handled elsewhere, with the else condition getting hits hundreds-to-thousands times a second. When the window is closed, cleanup occurs under the else condition. Shortly after this, back at the while loop mentioned earlier, an event occurs, and the while condition gets hit again.

      This is where things seem to go wrong. runModalSession() gets called again, with the session having already been freed. I'm told that the Cocoa API changed quite a bit in 10.9, presumably with more asserts and such being inserted. It seems that we're trying to use a freed session and throws up the warning. After that, it's hard to tell if Apple causes the crash or if it's Qt. Admittedly, this means it's hard to tell is this patch fixes the crashes or if it just obfuscates an even deeper issue.

      Does anybody have any more feedback? I'm just trying to push this issue forward and get a solution into Qt. (If any devs need code that can reproduce this issue, I'm happy to supply some.) Note that, strictly speaking, there are two separate pieces to my Qt4 patch. The first element is what I've talked about throughout this description. It's the big chunk at the top of the patch file. The rest of it is some code I backported from Qt5 that seems to make the code a little more stable. I don't know if it's needed. I just know that it doesn't seem to hurt my code.

      Thanks.

        Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

            Assignee:
            tpochep Timur Pocheptsov
            Reporter:
            droark Douglas Roark
            Votes:
            17 Vote for this issue
            Watchers:
            22 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Gerrit Reviews

                There are no open Gerrit changes