May 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] ec95a6: 50074

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: ec95a6bbb53327bccec2f4b8ebf8abc2f416c9b7 https://github.com/pharo-project/pharo-core/commit/ec95a6bbb53327bccec2f4b8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-29 (Fri, 29 May 2015) Changed paths: A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline21_.st M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/development_.st M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1215_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version13_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50073.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50074.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50073.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50074.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50074 a MC http://files.pharo.org/image/50/50074.zip

May 29, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50073 Home: https://github.com/pharo-project/pharo-core

May 29, 2015

[pharo-project/pharo-core] 2e9129: 50073

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 2e9129f2ce3dc4e686385980a3f0841e56a6ea30 https://github.com/pharo-project/pharo-core/commit/2e9129f2ce3dc4e686385980… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-29 (Fri, 29 May 2015) Changed paths: A AST-Core.package/RBBlockNode.class/instance/initialization/initialize.st A EmbeddedFreeType.package/LucidaGrandeRegular.class/README.md A EmbeddedFreeType.package/LucidaGrandeRegular.class/class/accessing/fontContents.st A EmbeddedFreeType.package/LucidaGrandeRegular.class/class/accessing/fontDirectory.st A EmbeddedFreeType.package/LucidaGrandeRegular.class/class/accessing/fontReference.st A EmbeddedFreeType.package/LucidaGrandeRegular.class/class/accessing/installFontsIn_.st A EmbeddedFreeType.package/LucidaGrandeRegular.class/class/accessing/originalFileName.st A EmbeddedFreeType.package/LucidaGrandeRegular.class/class/class initialization/initialize.st A EmbeddedFreeType.package/LucidaGrandeRegular.class/definition.st M Keymapping-Tools-Spec.package/KMDescription.class/instance/initialization/initializeWidgets.st M Morphic-Base.package/ToggleMenuItemMorph.class/instance/drawing-private/drawKeyTextOn_.st M Morphic-Base.package/ToggleMenuItemMorph.class/instance/layout/minWidth.st A Morphic-Base.package/ToggleMenuItemMorph.class/instance/private/keyTextExpanded.st A Morphic-Base.package/ToggleMenuItemShortcut.class/README.md A Morphic-Base.package/ToggleMenuItemShortcut.class/class/instance creation/new.st A Morphic-Base.package/ToggleMenuItemShortcut.class/class/instance creation/owner_keyText_.st A Morphic-Base.package/ToggleMenuItemShortcut.class/class/private/expandCondensedStyle_.st A Morphic-Base.package/ToggleMenuItemShortcut.class/class/private/expandFullStyle_.st A Morphic-Base.package/ToggleMenuItemShortcut.class/class/private/expand_.st A Morphic-Base.package/ToggleMenuItemShortcut.class/class/private/keyTextShortcuts.st A Morphic-Base.package/ToggleMenuItemShortcut.class/class/private/shortcutClass.st A Morphic-Base.package/ToggleMenuItemShortcut.class/definition.st A Morphic-Base.package/ToggleMenuItemShortcut.class/instance/accessing/keyText.st A Morphic-Base.package/ToggleMenuItemShortcut.class/instance/accessing/owner.st A Morphic-Base.package/ToggleMenuItemShortcut.class/instance/drawing/drawOn_.st A Morphic-Base.package/ToggleMenuItemShortcut.class/instance/initialization/initializeOwner_keyText_.st A Morphic-Base.package/ToggleMenuItemShortcut.class/instance/private/boundsForKeyText_font_.st A Morphic-Base.package/ToggleMenuItemShortcutWithSymbol.class/README.md A Morphic-Base.package/ToggleMenuItemShortcutWithSymbol.class/class/accessing/symbolFont.st A Morphic-Base.package/ToggleMenuItemShortcutWithSymbol.class/class/accessing/symbolTable.st A Morphic-Base.package/ToggleMenuItemShortcutWithSymbol.class/class/accessing/symbolTableAt_ifAbsent_.st A Morphic-Base.package/ToggleMenuItemShortcutWithSymbol.class/class/private/createSymbolFont.st A Morphic-Base.package/ToggleMenuItemShortcutWithSymbol.class/class/private/createSymbolTable.st A Morphic-Base.package/ToggleMenuItemShortcutWithSymbol.class/class/testing/canBeUsed.st A Morphic-Base.package/ToggleMenuItemShortcutWithSymbol.class/definition.st A Morphic-Base.package/ToggleMenuItemShortcutWithSymbol.class/instance/drawing/drawOn_.st A Morphic-Base.package/ToggleMenuItemShortcutWithText.class/README.md A Morphic-Base.package/ToggleMenuItemShortcutWithText.class/definition.st A Morphic-Base.package/ToggleMenuItemShortcutWithText.class/instance/drawing/drawOn_.st M Morphic-Core.package/WorldState.class/class/world menu items/mostUsedToolsOn_.st M Morphic-Core.package/WorldState.class/class/world menu items/quitItemsOn_.st M NautilusRefactoring.package/extension/TClassDescription/instance/sourceCodeRefactoringMenu_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50072.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50073.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50072.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50073.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Platforms.package/MacOSPlatform.class/instance/accessing/menuShortcutString.st A System-Platforms.package/OSPlatform.class/instance/accessing/menuShortcutString.st A System-Platforms.package/UnixPlatform.class/instance/accessing/menuShortcutString.st A System-Platforms.package/Win32Platform.class/instance/accessing/menuShortcutString.st Log Message: ----------- 50073 15626 SHRBStyle dnu for incomplete block nodes https://pharo.fogbugz.com/f/cases/15626 15628 Remove ComposableModel>>#instantiateModels:s senders in Keymapping-Tools-Spec https://pharo.fogbugz.com/f/cases/15628 15621 show complete menu modifiers https://pharo.fogbugz.com/f/cases/15621 http://files.pharo.org/image/50/50073.zip

May 29, 2015

Re: [Pharo-dev] OSWindow + X Server problem ?

by Nicolai Hess

2015-05-29 13:22 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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 <nicolaihess(a)web.de> 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 <matthieu.lacaton(a)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 >> >> > >

May 29, 2015

Re: [Pharo-dev] OSWindow + X Server problem ?

by Matthieu Lacaton

oops too. I didn't see that bug on fogbugz :( My bad, sorry ! 2015-05-29 13:22 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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 <nicolaihess(a)web.de> 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 <matthieu.lacaton(a)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 >> >> > >

May 29, 2015

Re: [Pharo-dev] OSWindow + X Server problem ?

by Esteban Lorenzano

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 <nicolaihess(a)web.de> 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 <matthieu.lacaton(a)gmail.com <mailto: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 > >

May 29, 2015

Re: [Pharo-dev] OSWindow + X Server problem ?

by Nicolai Hess

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(a)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 > >

May 29, 2015

OSWindow + X Server problem ?

by Matthieu Lacaton

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

May 29, 2015

Re: [Pharo-dev] [Pharo-users] [Pre-ANN][Job] We are looking for a "Engineer R&D"

by Marcus Denker

> On 29 May 2015, at 10:28, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: > > Excerpts from Marcus Denker's message of 2015-05-29 10:17:24 +0200: >> Hi, >> >> Good news: the job is not constraint by the â2 years after universityâ condition, but instead it is a >> so called âExperienced Engineerâ position: >> >> http://www.inria.fr/en/institute/recruitment/offers/find-a-position?nPostin… > > that link does not work for me, is it this one? > http://www.inria.fr/en/institute/recruitment/offers/find-a-position/%28view… > Yes! Marcus

May 29, 2015

Re: [Pharo-dev] [Pre-ANN][Job] We are looking for a "Engineer R&D"

by Marcus Denker

Hi, Good news: the job is not constraint by the â2 years after universityâ condition, but instead it is a so called âExperienced Engineerâ position: http://www.inria.fr/en/institute/recruitment/offers/find-a-position?nPostin… Marcus > On 22 May 2015, at 13:36, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > No job posting yet as we are seeing what exact kind of person we can hire. There is a certain > chance that this will not be constrained to âtwo years after universityâ. > > Job posting will be finalised next week, if you are interested (or now someone who might) > ==> please contact me already now. > > Marcus > >> On 19 May 2015, at 17:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> We will put the official announce online later this weekâ¦ we are looking to fill a a âyoung engineer positionâ. >> This is for recent graduates who finished their degree 2013/2014/2015. >> >> The topic is to work for 2 years on improving âremoteâ debugging for cases like server deployment, typical >> cloud scenarios and when using embedded Pharo images (e.g. for robotics). >> >> If you are interested (or know someone who might), please contact me. >> (official announcement will be online later this week). >> >> Marcus >> >

May 29, 2015