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

Reply via email to