Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. App crashes when Qt core calls WinAPI's "DispatchMessage" function

App crashes when Qt core calls WinAPI's "DispatchMessage" function

Scheduled Pinned Locked Moved Unsolved General and Desktop
windowsqtcorewinapiqtcreator
3 Posts 2 Posters 1.3k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P Offline
    P Offline
    psi-1
    wrote on 13 Feb 2019, 16:04 last edited by aha_1980
    #1

    When I run my app in a Debug mode in QtCreator, it crashes at some moment, a debugger stops in disassembler, and shows an error message:
    "The inferior stopped because it triggered an exception.
    Stopped in thread 8 by: Exception at 0x5245ad29, code: 0xc0000409: , flags=0x1 (execution cannot be continued)."

    Call stack is rather vague:

    1  vk_optimusGetInstanceProcAddr nvoglv64  0x5245ad29     
    2  DrvValidateVersion            nvoglv64  0x5205fa33     
    3  DrvPresentBuffers             nvoglv64  0x520afd6f     
    4  DrvPresentBuffers             nvoglv64  0x520ae0c6     
    5  DrvPresentBuffers             nvoglv64  0x5209c076     
    6  DrvPresentBuffers             nvoglv64  0x521a4f0e     
    7  DrvPresentBuffers             nvoglv64  0x521a7cc4     
    8  DrvPresentBuffers             nvoglv64  0x521a6f9d     
    9  DrvPresentBuffers             nvoglv64  0x521a81cb     
    10 DrvPresentBuffers             nvoglv64  0x521bf5d9     
    11 DrvValidateVersion            nvoglv64  0x5205cb6e     
    12 DrvPresentBuffers             nvoglv64  0x521819b2     
    13 DrvPresentBuffers             nvoglv64  0x52145786     
    14 nvoglv64                                0x51d5e08d     
    15 nvoglv64                                0x51ca1e29     
    16 nvoglv64                                0x51e13100     
    17 nvoglv64                                0x51e12eb0     
    18 DrvValidateVersion            nvoglv64  0x52061f8b     
    19 BaseThreadInitThunk           KERNEL32  0x7ffecfab3dc4 
    20 RtlUserThreadStart            ntdll     0x7ffed02e3691
    

    I managed to trace the way: it goes in QEventLoop::exec() function in qeventloop.cpp file; at line 214 it calls processEvents() function, then in goes in QEventLoop::processEvents(ProcessEventsFlags flags), at line 136 it goes in QWindowsGuiEventDispatcher::processEvents(QEventLoop::ProcessEventsFlags flags) in qwindowsguieventdispatcher.cpp file, then at line 74 (it hits this line twice — the second time is when the crush occurs) — in QEventDispatcherWin32::processEvents(QEventLoop::ProcessEventsFlags flags) in qeventdispatcher_win.cpp file. Finally, at line 629 it calls DispatchMessage(&msg) WinAPI macro with msg class members having these values:

    Name	Value		Type
    
    hwnd	0xd0690		HWND__*
    lParam	0		int64
    message	1025		unsigned int
    pt	@0x23a6fc484	tagPOINT
       x	592		long
       y	472		long
    time	18834015	unsigned long
    wParam	0		unsigned int64
    

    When I make the next step (press F10 or F11), I find myself in disassemler, as described above.
    The app consists of one little executable and several dlls and is built with CMake. It didn't behave like that before, when it was just one executable and was built with qmake.
    What's wrong, and how it may be fixed?

    K 1 Reply Last reply 13 Feb 2019, 16:24
    0
    • P psi-1
      13 Feb 2019, 16:04

      When I run my app in a Debug mode in QtCreator, it crashes at some moment, a debugger stops in disassembler, and shows an error message:
      "The inferior stopped because it triggered an exception.
      Stopped in thread 8 by: Exception at 0x5245ad29, code: 0xc0000409: , flags=0x1 (execution cannot be continued)."

      Call stack is rather vague:

      1  vk_optimusGetInstanceProcAddr nvoglv64  0x5245ad29     
      2  DrvValidateVersion            nvoglv64  0x5205fa33     
      3  DrvPresentBuffers             nvoglv64  0x520afd6f     
      4  DrvPresentBuffers             nvoglv64  0x520ae0c6     
      5  DrvPresentBuffers             nvoglv64  0x5209c076     
      6  DrvPresentBuffers             nvoglv64  0x521a4f0e     
      7  DrvPresentBuffers             nvoglv64  0x521a7cc4     
      8  DrvPresentBuffers             nvoglv64  0x521a6f9d     
      9  DrvPresentBuffers             nvoglv64  0x521a81cb     
      10 DrvPresentBuffers             nvoglv64  0x521bf5d9     
      11 DrvValidateVersion            nvoglv64  0x5205cb6e     
      12 DrvPresentBuffers             nvoglv64  0x521819b2     
      13 DrvPresentBuffers             nvoglv64  0x52145786     
      14 nvoglv64                                0x51d5e08d     
      15 nvoglv64                                0x51ca1e29     
      16 nvoglv64                                0x51e13100     
      17 nvoglv64                                0x51e12eb0     
      18 DrvValidateVersion            nvoglv64  0x52061f8b     
      19 BaseThreadInitThunk           KERNEL32  0x7ffecfab3dc4 
      20 RtlUserThreadStart            ntdll     0x7ffed02e3691
      

      I managed to trace the way: it goes in QEventLoop::exec() function in qeventloop.cpp file; at line 214 it calls processEvents() function, then in goes in QEventLoop::processEvents(ProcessEventsFlags flags), at line 136 it goes in QWindowsGuiEventDispatcher::processEvents(QEventLoop::ProcessEventsFlags flags) in qwindowsguieventdispatcher.cpp file, then at line 74 (it hits this line twice — the second time is when the crush occurs) — in QEventDispatcherWin32::processEvents(QEventLoop::ProcessEventsFlags flags) in qeventdispatcher_win.cpp file. Finally, at line 629 it calls DispatchMessage(&msg) WinAPI macro with msg class members having these values:

      Name	Value		Type
      
      hwnd	0xd0690		HWND__*
      lParam	0		int64
      message	1025		unsigned int
      pt	@0x23a6fc484	tagPOINT
         x	592		long
         y	472		long
      time	18834015	unsigned long
      wParam	0		unsigned int64
      

      When I make the next step (press F10 or F11), I find myself in disassemler, as described above.
      The app consists of one little executable and several dlls and is built with CMake. It didn't behave like that before, when it was just one executable and was built with qmake.
      What's wrong, and how it may be fixed?

      K Offline
      K Offline
      kshegunov
      Moderators
      wrote on 13 Feb 2019, 16:24 last edited by
      #2

      @psi-1 said in App crushes when Qt core calls WinAPI's "DispatchMessage" function:

      hwnd    0xd0690    HWND__*
      

      This address is rather suspicious. Please tell me you don't have global QWidgets?
      Btw, 0xc0000409 is stack overflow, so be on the lookout for endless recursion.

      Read and abide by the Qt Code of Conduct

      P 1 Reply Last reply 14 Feb 2019, 10:38
      3
      • K kshegunov
        13 Feb 2019, 16:24

        @psi-1 said in App crushes when Qt core calls WinAPI's "DispatchMessage" function:

        hwnd    0xd0690    HWND__*
        

        This address is rather suspicious. Please tell me you don't have global QWidgets?
        Btw, 0xc0000409 is stack overflow, so be on the lookout for endless recursion.

        P Offline
        P Offline
        psi-1
        wrote on 14 Feb 2019, 10:38 last edited by
        #3

        @kshegunov said in App crushes when Qt core calls WinAPI's "DispatchMessage" function:

        This address is rather suspicious. Please tell me you don't have global QWidgets?

        No, I have only a dll with function

        extern "C" CORE_SHARED_API QMainWindow * svCreateMainWindow()
        { return new MainWindow; }
        

        (CORE_SHARED_API is __declspec(dllexport))

        @kshegunov said in App crushes when Qt core calls WinAPI's "DispatchMessage" function:

        Btw, 0xc0000409 is stack overflow, so be on the lookout for endless recursion.

        As I said, QWindowsGuiEventDispatcher::processEvents() is called twice, and I believe those calls are on the same stack level (crush happens in the second call).

        1 Reply Last reply
        0

        1/3

        13 Feb 2019, 16:04

        • Login

        • Login or register to search.
        1 out of 3
        • First post
          1/3
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • Users
        • Groups
        • Search
        • Get Qt Extensions
        • Unsolved