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
