Recent

Author Topic: One out of two threads fails to stop under OpenBSD if app is stopped via signals  (Read 1170 times)

TCH

  • Full Member
  • ***
  • Posts: 133
Here (http://oscomp.hu/depot/lazarus_openbsd_signaltest.zip) is a simple GUI program for Lazarus, which starts two simple threads and on close, stops them. The app can be signaled with SIGTERM, SIGHUP, SIGINT and SIGQUIT which will call Form1.Close and terminate the program.
Now, if i close the program with the close button, then everything is ok. However, if i do this with one of the terminating signals, then the thread created as second will fail to stop correctly and crashes the program.

Here is the log when thread 1 is created first: http://oscomp.hu/depot/lazarus_openbsd_signaltest_terminate.log
And here is the log when thread 2: http://oscomp.hu/depot/lazarus_openbsd_signaltest_terminate2.log

I would like to highlight again, the crash only occurs if the threads are created and i terminate the app via signals. Either if i do it with the close button, or there are no threads, then no error occurs.

This program works flawlessly under Linux, FreeBSD and Solaris, so in theory the bug is either in FreePascal or Lazarus, or in OpenBSD and not in the program.
It's the latest ( 6.8 ) AMD64 OpenBSD. FreePascal is 3.2.0 and Lazarus is 2.0.10-2.

Any help is appreciated in founding the cause behind this.

And to make things easier for anybody who is willing to help, here is my installscript of Lazarus for OpenBSD: http://oscomp.hu/depot/install_lazarus_openbsd.sh
You can just call it like this: install_lazarus_openbsd.sh x86_64 3.2.0 2.0.10 2
And it will automatically handle installing FreePascal, it's sources, the dependencies of Lazarus and then the build of Lazarus.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 897
You are lucky it doesn't cause issues on other systems. It is never safe to perform any operation in a signal handler beyond setting a global variable or similar. The reason is that you have no way to know which code is active when the signal arrives, so calling random routines can cause them to work with an application state that was in the process of being updated. Furthermore, since the signal could arrive on any thread, you may also have data synchronisation (data races) issues if it's a different one than the main program thread.

TCH

  • Full Member
  • ***
  • Posts: 133
I see, so the root of the problem was the bad conception of how my program handles interrupts. Thank you for enlightening me.

So, instead of calling the form's subroutines, i now set a pair of global semaphore which is being periodically checked by a timer what performs the actions according to the state of the semaphores. And the program no longer crashes under OpenBSD. Thank you again.

 

TinyPortal © 2005-2018