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 <[email protected]>: > 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 > >
