For reference, I've created another test which uses many more GUI elements and which causes a segmentation fault on Mac systems after less than 300 iterations:
$ ./relax devel_scripts/memory_management/GUI_uf_align_tensor_init.py This script works flawlessly on Linux and Windows systems. Regards, Edward On 17 March 2015 at 11:54, Edward d'Auvergne <edw...@nmr-relax.com> wrote: > 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
