This is already known and a fix was provided by ronie. 14911 <https://pharo.fogbugz.com/default.asp?14911> XLib missing call I asked about this already and when this will be included. But no response so far. 2015-05-29 12:08 GMT+02:00 Matthieu Lacaton <matthieu.lacaton@gmail.com>:
Hello everyone,
I think I found a bug with OSWindow when using the X11 server :
Everytime you open an OSWindow (it doesn't matter what you do with it, you can even close it you just need to have opened an OSWindow once) when you want to quit your image you get a segmentation fault on the "quitPrimitive". Or sometimes you can have a error: "double free or corruption (out)".
To reproduce it you just have to open an empty OSWindow with "OSWindow new." then close it and close your image.
It is not a big problem because the image is still saved and closed and nothing bad happens when you reopen it but it is just frustrating to have a segfault everytime you close your image.
I've been able to get a C stack backtrace :
/home/matthieu/Documents/Pharo5/pharo-vm/pharo[0x80a3352]
/home/matthieu/Documents/Pharo5/pharo-vm/pharo[0x80a36a3] [0xf772a410] /lib/i386-linux-gnu/libpthread.so.0(__pthread_mutex_lock+0x16)[0xf76a5036] /usr/lib/i386-linux-gnu/libX11.so.6(+0x23f0d)[0xf710df0d] /usr/lib/i386-linux-gnu/libX11.so.6(XrmDestroyDatabase+0x2d)[0xf712888d]
/usr/lib/i386-linux-gnu/libX11.so.6(_XFreeDisplayStructure+0x473)[0xf710fbf3] /usr/lib/i386-linux-gnu/libX11.so.6(XCloseDisplay+0xd9)[0xf70fd0f9]
/home/matthieu/Documents/Pharo5/pharo-vm/vm-display-X11(disconnectXDisplay+0xcf)[0xf771dd3f]
/home/matthieu/Documents/Pharo5/pharo-vm/vm-display-X11(+0x11d74)[0xf771dd74]
/home/matthieu/Documents/Pharo5/pharo-vm/pharo(ioExitWithErrorCode+0x20)[0x80a3990] /home/matthieu/Documents/Pharo5/pharo-vm/pharo[0x807551f]
/home/matthieu/Documents/Pharo5/pharo-vm/pharo(interpret+0x234c)[0x80973cc]
/home/matthieu/Documents/Pharo5/pharo-vm/pharo(enterSmalltalkExecutiveImplementation+0x59)[0x809a5c9] /home/matthieu/Documents/Pharo5/pharo-vm/pharo(interpret+0x1ee)[0x809526e] /home/matthieu/Documents/Pharo5/pharo-vm/pharo(main+0x2b2)[0x805ba82] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf7507a83] /home/matthieu/Documents/Pharo5/pharo-vm/pharo[0x805bda1]
By digging up a bit I think I may have a hint about why this happens :
When you initialize the X11 server you need to make a choice about calling XInitThreads() or not. Here is a part of the man of XInitThreads() :
*The XInitThreads function initializes Xlib support for concurrent
threads. This function must be the first Xlib function a multi-threaded program calls, and it must complete before any other Xlib call is made. This function returns a nonzero status if initialization was successful; otherwise, it returns zero. On systems that do not support threads, this function always returns zero. *
*It is only necessary to call this function if multiple threads might use Xlib concurrently. If all calls to Xlib functions are protected by some other access mechanism (for example, a mutual exclusion lock in a toolkit or through explicit client programming), Xlib thread initialization is not required. It is recommended that single-threaded programs not call this function.*
I've searched a bit in the Pharo VM code and I have not found any call to XInitThreads() and it seems normal because it only opens one window in a single thread.
Now the problem is that SDL makes a call to XinitThreads() in the file "SDL_x11video.c" in the function : "X11_CreateDevice(int devindex)" because SDL needs it.
This means basically that the XinitThreads() function is called from the same process than the VM one after the first Xlib calls have been made.
So to sum up, the VM initializes the X server in single thread mode. Then SDL changes it to multi thread mode so the X server probably creates a mutex to handle everything. Now when we try to close the VM the main window that was opened in single thread mode makes the mutex crash and it results in a segfault.
If I am right it means that adding a call to XInitThreads() in the initialization of the X11 server in the VM code could maybe solve this problem.
What do you think about it ?
Cheers,
Matthieu