2015-05-29 13:22 GMT+02:00 Esteban Lorenzano <[email protected]>: > oops. I forgot about that issue. Added to my TODO… so now time of > inclusion is “soon (™)” :) > > :) Thanks
> 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]>: > >> 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 >> >> > >
