The assert that Jeff saw in Issue 701 is not directly related. An access violation ...
12 years, 5 months ago
(2012-07-11 14:25:36 UTC)
#1
The assert that Jeff saw in Issue 701 is not directly related. An access
violation occurs when calling config() on a NULL texture pointer. However, when
SampleApp is attached to the VS debugger an exception handler is installed (for
some unknown reason, maybe by part the GL driver or win32 layer). The exception
gets handled but we jump way up the call stack, leaving Gr things in an
inconsistent state. We later hit the assert.
The work around is to use windbg which does a first chance break on the AV.
On 2012/07/11 14:25:36, bsalomon wrote: > The assert that Jeff saw in Issue 701 is ...
12 years, 5 months ago
(2012-07-11 14:43:02 UTC)
#2
On 2012/07/11 14:25:36, bsalomon wrote:
> The assert that Jeff saw in Issue 701 is not directly related. An access
> violation occurs when calling config() on a NULL texture pointer. However,
when
> SampleApp is attached to the VS debugger an exception handler is installed
(for
> some unknown reason, maybe by part the GL driver or win32 layer). The
exception
> gets handled but we jump way up the call stack, leaving Gr things in an
> inconsistent state. We later hit the assert.
>
> The work around is to use windbg which does a first chance break on the AV.
Rob points out that first chance breaking in VS can be enabled in
Debug->Exceptions (check "Thrown" box)
Issue 6353087: Fix assumption that enabled stage implies texture is present
(Closed)
Created 12 years, 5 months ago by bsalomon
Modified 12 years, 5 months ago
Reviewers: TomH
Base URL: http://skia.googlecode.com/svn/trunk/
Comments: 0