oops. I forgot about that issue. Added to my TODO… so now time of inclusion is “soon (™)” :)
Esteban > On 29 May 2015, at 12:49, Nicolai Hess <[email protected]> wrote: > > 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] > <mailto:[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 > >
