Re: [bug #23389] GUI tests segfaults in 3.3.7Re: [bug #23389] GUI tests segfaults in 3.3.7For 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 <edward@xxxxxxxxxxxxx> 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 <edward@xxxxxxxxxxxxx> 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 <edward@xxxxxxxxxxxxx> 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 <edward@xxxxxxxxxxxxx> 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-ADDRESS@xxxxxxx> 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@xxxxxxx 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