Right, the first thing to note is that General Options background colour
setting only has an impact on new windows that are created, not existing
ones. My background colour is normally white. So I just did a test of
changing that General Options setting to black, then saving the project
(otherwise that option is definitely not remembered!), then quitting, then
starting up again. The existing windows were white, as before. Then I
created a new window and its background came out black. And it didn't
crash. This is with OpenGL on my Mac (ATI Radeon 9600 XT OpenGL Engine,
1.5 ATI-1.4.18).
[ You can check the background color setting in a project by opening the
file PROJECT_NAME/ccpnmr/Analysis.xml and looking for backgroundColor (an
attribute of AnalysisProject). That will give you an ID (e.g. "_3") and
you can then look for a Color with that ID, e.g.
<Color _ID="_3" r="0.0" g="0.0" b="0.0" name="black">
which gives you the color name. ]
So setting this background color should have no impact on whether or not
the project crashes when re-starting, at least I cannot see why it has any
impact. So I'm not sure what is going on.
Wayne
On Mon, 12 Feb 2007, Murali Vadivelu wrote:
> Dear Wayne,
>
> My background was set to black. All windows are black except one (out
> of 7 or so). When I set the General options background colour to
> 'white', save, close and reopen under OpenGL it repeatably crashes,
> and the option is reset to black again. Under Tk, it does not crash
> but the option gets reset to black.
>
> Many thanks.
>
> Best,
> Murali.
>
> On 12 Feb 2007, at 17:39, Wayne Boucher wrote:
>
> > Hello,
> >
> > The only Analysis (rather than Python) function that is mentioned is
> > init_Py_Gl_handler, which is the first function going into the C world
> > that is called (indirectly) by a specific Python function.
> > Assuming that
> > that stack trace is complete and correct, then it's hard to see why
> > it's
> > crashing in that function since not a heck of a lot happens there
> > except a
> > call to a Python C function and then a call to an Analysis proper
> > (i.e.
> > unrelated to Python) C function. And if you believe that stack
> > trace then
> > the crash didn't happen inside either of those two functions. The
> > remaining lines of code are about as innocuous as you can get.
> >
> > static PyObject *init_Py_Gl_handler(PyObject *self, PyObject *args)
> > {
> > PyObject *widget;
> > #ifdef USE_GL_TRUE
> > int direct = GL_TRUE;
> > #else
> > int direct = GL_FALSE;
> > #endif
> >
> > if (!PyArg_ParseTuple(args, "O|i", &widget, &direct))
> > RETURN_OBJ_ERROR("must have one argument: widget");
> >
> > return new_py_gl_handler(widget, direct ? CCPN_TRUE : CCPN_FALSE);
> > }
> >
> > Wayne
> >
> > On Mon, 12 Feb 2007, Murali Vadivelu wrote:
> >
> >> Date/Time: 2007-02-12 17:12:15.562 +0000
> >> OS Version: 10.4.8 (Build 8L127)
> >> Report Version: 4
> >>
> >> Command: python2.5
> >> Path: /sw_10.4/bin/python2.5
> >> Parent: sh [22787]
> >>
> >> Version: ??? (???)
> >>
> >> PID: 22788
> >> Thread: 0
> >>
> >> Exception: EXC_BAD_ACCESS (0x0001)
> >> Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
> >>
> >> Thread 0 Crashed:
> >> 0 <<00000000>> 0x00000000 0 + 0
> >> 1 GlHandler.so 0x0284b54c init_Py_Gl_handler + 252
> >> 2 python2.5 0x00020474 PyObject_Call + 52 (abstract.c:
> >> 1861)
> >> 3 python2.5 0x0009dfe8 PyEval_EvalFrameEx + 20328
> >> (ceval.c:
> >> 3848)
> >
> > and a lot more...
>
|