Author Topic: hang on startup in src/sdk/compiler.cpp: race condition  (Read 721 times)

Offline jggimi

  • Single posting newcomer
  • *
  • Posts: 3
hang on startup in src/sdk/compiler.cpp: race condition
« on: April 09, 2022, 02:57:11 pm »
During startup, compiler.cpp iterates through all known compilers testing for availability with a call to wxExecute().  This will occasionally hang waiting on a dispatched select(2) -- and this will occur at different points in the iteration through the list of compilers, so there is some race condition occurring that affects behavior of wxWidgets, glib, or perhaps system call functionality. 

OS: OpenBSD, 7.1-current.
wxWidgets: 3.0.5.1
glib2: 2.70.5

If I switch the wxExecute flags wxEXEC_SYNC and wxEXEC_NOEVENTS to wxEXEC_ASYNC, the race condition does not occur.  All compiler tests complete and C::B starts up without problems.   

While this is an apparent working circumvention, I'm concerned that it may have a detrimental impact that I do not foresee, and would appreciate a review.  I could use some advice as to whether to keep this circumvention in place or not, and perhaps, how I could dig down deeper to determine the root cause of the hang on select().

Thank you in advance for any insights or guidance you may have.

---

This circumvention was tested with svn 12783.

Patch:
Code
Index: src/sdk/compiler.cpp
--- src/sdk/compiler.cpp.orig
+++ src/sdk/compiler.cpp
@@ -1600,10 +1600,7 @@ long Compiler::Execute(const wxString& cmd, wxArrayStr
 long Compiler::Execute(const wxString& cmd, wxArrayString& output)
 {
     wxLogNull logNo; // do not warn if execution fails
-    int flags = wxEXEC_SYNC;
-    // Stop event-loop while wxExecute runs, to avoid a deadlock on startup,
-    // that occurs from time to time on wx3
-    flags |= wxEXEC_NOEVENTS;
+    int flags = wxEXEC_ASYNC;
     return wxExecute(cmd, output, flags);
 }
 #endif // __WXMSW__

Hanging thread backtrace:
Quote
Thread 1 (thread 417033):
#0  _thread_sys_select () at /tmp/-:3
#1  0x00000bc712e4c33e in _libc_select_cancel (nfds=20, readfds=0x7f7ffffed820, writefds=0x7f7ffffed8a0, exceptfds=0xbc712e469aa <_thread_sys_select+10>, timeout=0x0) at /usr/src/lib/libc/sys/w_select.c:28
#2  0x00000bc79c98e6a9 in wxSelectSets::Select (this=<optimized out>, nfds=20, tv=0x0) at ./src/common/selectdispatcher.cpp:109
#3  wxSelectDispatcher::DoSelect (this=0x7f7ffffedbe0, sets=..., timeout=<optimized out>) at ./src/common/selectdispatcher.cpp:230
#4  wxSelectDispatcher::Dispatch (this=0x7f7ffffedbe0, timeout=<optimized out>) at ./src/common/selectdispatcher.cpp:249
#5  0x00000bc79c9a72d4 in (anonymous namespace)::BlockUntilChildExit (execData=...) at ./src/unix/utilsunx.cpp:554
#6  wxExecute (argv=<optimized out>, flags=<optimized out>, process=<optimized out>, env=<optimized out>) at ./src/unix/utilsunx.cpp:858
#7  0x00000bc79c9a637b in wxExecute (command=..., flags=17, process=0xbc6d4753400, env=0x0) at ./src/unix/utilsunx.cpp:475
#8  0x00000bc79c9c2e02 in wxDoExecuteWithCapture (command=..., output=..., error=0x0, flags=<optimized out>, env=0x0) at ./src/common/utilscmn.cpp:687
#9  0x00000bc7902a6b37 in Compiler::Execute (this=<optimized out>, cmd=..., output=...) at compiler.cpp:1607
#10 0x00000bc7902a4f1e in Compiler::EvalXMLCondition (this=0xbc6d4777380, node=0xbc76db86100) at compiler.cpp:1344
#11 0x00000bc790294a4f in Compiler::LoadDefaultOptions (this=0xbc6d4777380, name=..., recursion=1) at compiler.cpp:864
#12 0x00000bc7902949ae in Compiler::LoadDefaultOptions (this=0xbc6d4777380, name=..., recursion=0) at compiler.cpp:1072
#13 0x00000bc7902935dd in Compiler::Reset (this=0xbc6d4777380) at compiler.cpp:163
#14 0x00000bc76db293e9 in CompilerXML::CompilerXML (this=0xbc6d4777380, name=..., ID=..., file=...) at compilerXML.cpp:24
#15 0x00000bc76dac113f in CompilerGCC::DoRegisterCompilers (this=<optimized out>) at compilergcc.cpp:994
#16 0x00000bc76dabec9e in CompilerGCC::OnAttach (this=0xbc711a17c00) at compilergcc.cpp:361
#17 0x00000bc79025d97b in cbPlugin::Attach (this=0xbc711a17c00) at cbplugin.cpp:73
#18 0x00000bc7903734bf in PluginManager::AttachPlugin (plugin=0xbc711a17c00, ignoreSafeMode=<error reading variable: Cannot access memory at address 0x0>, this=<optimized out>) at pluginmanager.cpp:197
#19 PluginManager::LoadAllPlugins (this=<optimized out>) at pluginmanager.cpp:1119
#20 0x00000bc4b0ab9b09 in MainFrame::ScanForPlugins (this=0xbc6d198a7b0) at main.cpp:1496
#21 0x00000bc4b0ab4d1a in MainFrame::MainFrame (this=0xbc6d198a7b0, parent=<optimized out>) at main.cpp:794
#22 0x00000bc4b0a2543c in CodeBlocksApp::InitFrame (this=0xbc70c5e7800) at app.cpp:494
#23 CodeBlocksApp::OnInit (this=0xbc70c5e7800) at app.cpp:717
#24 0x00000bc79c90b06d in wxEntry (argc=<optimized out>, argv=<optimized out>) at ./src/common/init.cpp:490
#25 0x00000bc4b0a2267e in main (argc=1, argv=0x7f7ffffed820) at app.cpp:327
Edit: clarity, release levels
« Last Edit: April 09, 2022, 03:11:57 pm by jggimi »

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1016
Re: hang on startup in src/sdk/compiler.cpp: race condition
« Reply #1 on: April 09, 2022, 08:29:03 pm »
If you do that compiler detection will not work. You can try to use the MSW code, it uses wxEXEC_ASYNC but the root cause must be fixed.

Offline jggimi

  • Single posting newcomer
  • *
  • Posts: 3
Re: hang on startup in src/sdk/compiler.cpp: race condition
« Reply #2 on: April 10, 2022, 05:20:55 am »
During testing, the default clang compiler was discovered for a new user, so I didn't perceive non-discovery as a risk. 

I will look at the wxMSW handling code as you've recommended..  And I will try to dig into the thread's stack frames to try to determine what is happening the next time I get a hang.

Thank you!

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9640
Re: hang on startup in src/sdk/compiler.cpp: race condition
« Reply #3 on: April 15, 2022, 10:54:45 am »
Remember that this may behave differently on Linux/Windows. Maybe we cannot resolve both issues with one code base but must act in a platform-dependent way.
I wonder what is executed at the moment it hangs. It is a specific command? What if you run this command in a shell?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline jggimi

  • Single posting newcomer
  • *
  • Posts: 3
Re: hang on startup in src/sdk/compiler.cpp: race condition
« Reply #4 on: April 17, 2022, 10:22:12 pm »
It seems to be related to other X Windows applications -- e.g.: other running applications, such as Firefox.  I thought it might have been a gtk-related issue, as the most common time a hang occurs is when Firefox is running.  So I thought, initially, that the problem was Gtk related in some way.  But it also happens when only Qt-based applications are running, so the only commonality I have discovered, so far, is just X Windows.  I've tried different window managers (i3wm, fluxbox) and the intermittent hangs occur with both.

When run from within a shell, during a hang I just see stdout messages stop during compiler checks.