Opened 21 months ago

Last modified 18 months ago

#14891 new defect

[MSW] thread sample deadlock

Reported by: ericj Owned by:
Priority: normal Milestone:
Component: wxMSW Version: stable-latest
Keywords: thread Cc:
Blocked By: Blocking:
Patch: no

Description

To reproduce:

  • start unmodified "thread" sample.
  • select "thread -> start a new thread"
  • select "thread -> stop the last spawned thread" before the thread terminates on its own (before counter reaches 10)

Program deadlocks and can only be killed through task manager.

I traced the problem down to an infinite loop in wxThreadInternal::WaitForTerminate "msw/thread.cpp". The call
result = traits->WaitForThread(m_hThread, waitMode);
(line 819 in today's SVN) always returns "WAIT_OBJECT_0 + 1", so that it never leaves the do/while loop.

I use threads often in my own projects and never had that problem. I have no idea what the sample does differently to cause this problem.

Tested with VS2003 + VS2005 under XP/32

Attachments (1)

14891_improve.diff download (988 bytes) - added by catalin 18 months ago.

Download all attachments as: .zip

Change History (3)

Changed 18 months ago by catalin

comment:1 Changed 18 months ago by catalin

This looks like a problem with the sample, because:

  • MyFrame::OnStopThread() will enter wxGetApp().m_critsect and then calls Delete() which waits for the thread to exit;
  • MyThread::Entry() tries to enter wxGetApp().m_critsect to check for wxGetApp().m_shuttingDown.

The patch attached improves the situation a bit by making "Stop the last spawned thread" option usable (it is completely unusable now). But it can still lead to a crash in the rare case when the main thread tries to delete a secondary thread that just deleted itself..

comment:2 Changed 18 months ago by VZ

(In [73568]) Fix, or at least make less common, deadlock in the thread sample.

Don't always deadlock when "Stop the last spawned thread" menu command is
selected. There is still a problem with a race condition which could result in
a crash when dereferencing an invalid pointer, but at least this doesn't
happen all the time, unlike the current bug.

Of course, the real solution would be to properly rewrite the sample to show
how thread deletion should be handled correctly...

See #14891.

Note: See TracTickets for help on using tickets.