Results 1 to 5 of 5

Thread: QThread stack overflow when exiting

  1. #1
    Join Date
    Jan 2006
    Posts
    17
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default QThread stack overflow when exiting

    Hi all. I'm using QT 3.3.1 on Windows and have an application with a QThread object. An exit command could come from 2 different places: the user closing the window or an external application that I'm hooking to exiting.

    The child thread is responsible for communicating with the external app and posting when the exit has occurred. I have 2 booleans to indicate where the exit command has come from. If the exit command came from the GUI, then guiCommandedExit is set to true. If the exit came from the external app, then externalCommandedExit is set to true. Before checking/setting either of those flags, I do a myMutex.lock( ). After the check/set, I do myMutex.unlock( ).

    The problem that I'm running into is that when the exit event occurs (through the GUI), I'm getting a large number of "First-chance exception in [my_app].exe" along with a stack overflow notice. This is the first time I've done anything with threads since Operating Systems 1 in college, so forgive me if I'm missing something obvious. Any help that can be provided is appreciated. Thanks in advance.

    Qt Code:
    1. class MyThread
    2. {
    3.  
    4. public:
    5. void run( );
    6.  
    7. };
    8.  
    9. MyThread::run( )
    10. {
    11.  
    12. while ((!/*externally commanded exit*/) && (!guiCommandedExit))
    13. {
    14.  
    15. /* communicate with the external app */
    16.  
    17. }/* end while no exit */
    18.  
    19. myMutex.lock( );
    20.  
    21. if (!guiCommandedExit)
    22. {
    23.  
    24. /* post to close the GUI */
    25. externalCommandedExit = true;
    26.  
    27. }
    28.  
    29. myMutex.unlock( );
    30.  
    31. }/* end ::run */
    32.  
    33. void
    34. MainGui::closeEvent( QCloseEvent* event )
    35. {
    36.  
    37. myMutex.lock( );
    38.  
    39. if (!externalCommandedExit)
    40. {
    41.  
    42. guiCommandedExit = true;
    43.  
    44. myMutex.unlock( );
    45.  
    46. myThread->wait( );
    47.  
    48. }
    49.  
    50. QApplication::exit( 0 );
    51.  
    52. event->accept( );
    53.  
    54. }/* end ::closeEvent */
    To copy to clipboard, switch view to plain text mode 
    The end of time is reached around the year 8000, by which time we expect Qt to be obsolete.

    -Note in QDate documentation. It's nice that Qt has been able to predict when the world will end.

  2. #2
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QThread stack overflow when exiting

    Hard to say, as this code doesn't do much, but you have (at least) one mistake here:

    Qt Code:
    1. MainGui::closeEvent( QCloseEvent* event )
    2. {
    3. myMutex.lock( );
    4. if (!externalCommandedExit)
    5. {
    6. guiCommandedExit = true;
    7. myMutex.unlock( );
    8. myThread->wait( );
    9. }
    10. QApplication::exit( 0 );
    11. event->accept( );
    12. }/* end ::closeEvent */
    To copy to clipboard, switch view to plain text mode 
    What happens if externalCommandedExit is true? mutex will never be unlocked... The thread locks the mutex too, so it might create a deadlock (on MyThread->wait()).

    But as I said, hard to say without seeing the rest of the code.

    BTW. Think about redesigning your code, there are surely simpler ways to do what you want.

  3. #3
    Join Date
    Jan 2006
    Posts
    17
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QThread stack overflow when exiting

    Quote Originally Posted by wysota
    Hard to say, as this code doesn't do much, but you have (at least) one mistake here:

    Qt Code:
    1. MainGui::closeEvent( QCloseEvent* event )
    2. {
    3. myMutex.lock( );
    4. if (!externalCommandedExit)
    5. {
    6. guiCommandedExit = true;
    7. myMutex.unlock( );
    8. myThread->wait( );
    9. }
    10. QApplication::exit( 0 );
    11. event->accept( );
    12. }/* end ::closeEvent */
    To copy to clipboard, switch view to plain text mode 
    What happens if externalCommandedExit is true? mutex will never be unlocked... The thread locks the mutex too, so it might create a deadlock (on MyThread->wait()).

    But as I said, hard to say without seeing the rest of the code.

    BTW. Think about redesigning your code, there are surely simpler ways to do what you want.
    Thanks for the reply. You are correct that I had that line wrong. Thanks for pointing it out. However, I haven't been trying to kill the program through the external application yet, so that shouldn't be coming into play. I built and ran on UNIX and it exited without a problem.
    The end of time is reached around the year 8000, by which time we expect Qt to be obsolete.

    -Note in QDate documentation. It's nice that Qt has been able to predict when the world will end.

  4. #4
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QThread stack overflow when exiting

    I guess you shouldn't call QApplication::exit() from the close event. If you accept the event and make sure the app gets closed when this particular window closes, you'll achieve the same effect.

  5. #5
    Join Date
    Jan 2006
    Posts
    17
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QThread stack overflow when exiting

    After much beating of heads against walls, I found that I was reaching my return statement at the end of my main function and the exceptions being thrown occurr in one of the Windows DLL's. With the help of a friend of mine here at work, we compared Makefiles between a multi-threaded application that wasn't QT and the qmake-generated Makefile. It turns out that the qmake-generated Makefile had the compiler option set for it to have been built as a DLL instead of an executable, so we changed the CFLAGS and CXXFLAGS from -MDd to -MTd along with adding /nodefaultlib:"msvcrt.lib" to the LFLAGS. This seemed to fix the problem. Is this a known problem? I do have TEMPLATE: app in my .pro.

    Thanks for your help.
    The end of time is reached around the year 8000, by which time we expect Qt to be obsolete.

    -Note in QDate documentation. It's nice that Qt has been able to predict when the world will end.

Similar Threads

  1. Replies: 8
    Last Post: 25th February 2009, 08:29

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.