Hi, Here is a good example of where the Mac GUI limits can be tested:
$ ./relax devel_scripts/memory_management/GUI_uf_time.py This repetitively calls the time user function 10000 times. This uses the muppy module from the powerful Pympler package (https://pythonhosted.org/Pympler/). Looking at the 'muppy_log' file produced, it can be seen that no extra memory is being leaked. I.e. all the GUI objects are released. The memory between iteration 100 and the last iteration is the same (except for some extra Python objects after iteration 1700 when the first invisible problems probably occur). The way the time user function is called is that the user function window is created and then destroyed each time. No wxPython objects are present in memory after the user function is destroyed. This is different to the GUI behaviour where the window is created and then closed by being hidden, and a second call simply reopens the original window. However this test demonstrates the Mac GUI object failure point extremely clearly. This executes perfectly fine on Linux and Windows systems. However on Mac systems, the memory errors will eventually appear, and finally relax will crash. However nothing will be seen in the muppy log file. So there is nothing in Python memory which is causing this. Rather the Mac system will not release the GUI objects. I would love to know how to whack the Mac system over the head to release these things! Maybe there is a workaround in wxPython for this. Or maybe it is a wxWidgets bug that will be fixed in the future. In any case, I am completely lost as to how to handle this Python-wxPython-wxWidgets-Mac OS X bug. If this simple script could be made to work, then many Mac GUI issues will simply disappear. Regards, Edward On 17 March 2015 at 10:40, Edward d'Auvergne <edw...@nmr-relax.com> wrote: > Hi, > > Would anyone know of any tools in Mac OS X which can be used to track > GUI object usage? In MS Windows, the task manager can be set up to > display "USER Objects" and "GUI Objects". I have used this for > debugging to allow the GUI tests to pass again on that system and not > run into the 10,000 object limits. But in Mac and Linux systems, I > have no idea what can be used for a GUI debugging tool! If I could > see these and have an idea about their usage, I might be able to track > down possible GUI object leaks and maybe get the tests to run again. > It might be possible to save memory in other areas, or to even force > Macs to release the GUI objects. But we are currently completely > blind as to what is happening with wxPython, GUI objects, and the Mac > way of handling these. > > Cheers, > > Edward > > > > > On 15 March 2015 at 14:11, Edward d'Auvergne <edw...@nmr-relax.com> wrote: >> Hi, >> >> The error I see is: >> >> """ >> $ ./relax --gui-tests >> >> >> ============= >> = GUI tests = >> ============= >> >> .........................................Sun Mar 15 13:53:41 Mac.local >> Python[248] <Error>: kCGErrorFailure: _CGSBindWindowBacking: cannot >> map backing data shmem >> Sun Mar 15 13:53:41 Mac.local Python[248] <Error>: kCGErrorFailure: >> Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are >> logged. >> Sun Mar 15 13:53:41 Mac.local Python[248] <Error>: kCGErrorFailure: >> _CGSLockWindow: Unable to lock window >> Sun Mar 15 13:53:41 Mac.local Python[248] <Error>: kCGErrorFailure: >> _CGSBindWindowBacking: cannot map backing data shmem >> Sun Mar 15 13:53:41 Mac.local Python[248] <Error>: kCGErrorFailure: >> _CGSLockWindow: Unable to lock window >> Sun Mar 15 13:53:41 Mac.local Python[248] <Error>: kCGErrorFailure: >> _CGSBindWindowBacking: cannot map backing data shmem >> Sun Mar 15 13:53:41 Mac.local Python[248] <Error>: kCGErrorFailure: >> _CGSLockWindow: Unable to lock window >> """ >> >> >> This is repeated many, many times until I see: >> >> """ >> Python(248,0x3bd540) malloc: *** mmap(size=2097152) failed (error code=12) >> *** error: can't allocate region >> *** set a breakpoint in malloc_error_break to debug >> """ >> >> This too is repeated many, many times. Then the memory runs out and >> "Segmentation fault" is printed and a window pops up saying that >> Python died unexpectedly. >> >> Regards, >> >> Edward >> >> On 15 March 2015 at 13:48, Edward d'Auvergne <edw...@nmr-relax.com> wrote: >>> Hi Jack, >>> >>> Maybe you might be able to help solve this problem. It is rather >>> difficult and I think the easiest solution is to blacklist GUI tests >>> from running on Mac OS X. However despite the segfaults, I find the >>> tests useful to make sure all is well in the GUI on a Mac. The >>> problem is either a bug in wxPython, well really wxWidgets, or a >>> design flaw in Mac OS X. From what I've read, it sounds more like a >>> Mac design flaw. >>> >>> This was previously a problem on MS Windows, but I have solved it for >>> that OS in relax 3.3.6 (http://wiki.nmr-relax.com/Relax_3.3.6). All >>> operating systems have a hard limit for the number of GUI objects that >>> can be created (windows, panels, buttons, etc.). In MS Windows, this >>> is called "User Objects" and there the limit is 10,000, and "GDI >>> Object" which has the same limit. In Mac systems, I'm not sure what >>> the equivalent are called. In Linux, the limits are so high that >>> we'll never encountered the problem. In relax these limits are >>> reached due to the design of the GUI, specifically the user function >>> windows. If all the user function windows are open simultaneously, >>> then the Windows and Mac limits are reached and Python errors or >>> segfaults are seen respectively. The current design is that after >>> closing a user function window, it remains in memory so that when you >>> reopen it, all its settings and values from the previous execution are >>> still there. This is very useful for repetitive operations such as >>> loading peak list data. But when running the test suite, as the user >>> function windows remain permanently open, the hard GUI limits are >>> reached in both Windows and Macs. This problem has only recently >>> surfaced as the number of GUI tests have expanded and more of the user >>> functions are executed. In the future as the GUI tests expand even >>> more, this will become more and more of a problem. >>> >>> The solution in relax 3.3.6 was to destroy all user function windows >>> at the end of each GUI test (see >>> http://www.nmr-relax.com/api/3.3/test_suite.gui_tests.base_classes-pysrc.html#GuiTestCase.tearDown >>> and >>> http://www.nmr-relax.com/api/3.3/gui.spin_viewer.frame-pysrc.html#Spin_view_window.Destroy >>> for this design). This frees the User Objects and GDI Objects in MS >>> Windows. However this is were the Mac OS X design flaw hurts. In the >>> Mac, the system will not release the GUI objects until the program >>> terminates! So despite the window Destroy() function calls, the limit >>> will be reached and a segfault will occur. I have desperately >>> searched for a solution for this for Mac systems, but have found none. >>> It sounds like the wxWidget people blame the Mac OS design flaw. >>> Maybe in the future, wxWidgets will find a workaround that can then be >>> used in relax. But until then, we are pretty much bound to have >>> segfaults in Mac systems in the GUI tests. I really have not idea >>> what we can do to solve this issue! >>> >>> Regards, >>> >>> Edward >>> >>> >>> >>> >>> >>> On 14 March 2015 at 22:35, Jack Howarth >>> <no-reply.invalid-addr...@gna.org> wrote: >>>> Follow-up Comment #1, bug #23389 (project relax): >>>> >>>> This failure also appears in 3.3.6 with 'relax --test-suite'. Oddly it >>>> doesn't >>>> occur with 'relax --gui-tests'. >>>> >>>> _______________________________________________________ >>>> >>>> Reply to this item at: >>>> >>>> <http://gna.org/bugs/?23389> >>>> >>>> _______________________________________________ >>>> Message sent via/by Gna! >>>> http://gna.org/ >>>> >>>> >>>> _______________________________________________ >>>> relax (http://www.nmr-relax.com) >>>> >>>> This is the relax-devel mailing list >>>> relax-devel@gna.org >>>> >>>> To unsubscribe from this list, get a password >>>> reminder, or change your subscription options, >>>> visit the list information page at >>>> https://mail.gna.org/listinfo/relax-devel _______________________________________________ relax (http://www.nmr-relax.com) This is the relax-devel mailing list relax-devel@gna.org To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
