Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances, but
goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as a
magic stamp value never gets updated because the X protocol message
never succeeds -- but it doesn't segfault.
I've got a patch
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as
a magic stamp value never gets updated because the X protocol message
never succeeds -- but it doesn't
Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(),
as a magic stamp value never gets updated because the X protocol
message never succeeds
There are now two patches, one from Egbert Eich (who reported the problem). I
haven't had time to look at his as it changes some deep, dark, dri stuff that
I wasn't ever involved with, but looks sane nonetheless. His avoids the error
reply from the X server, whereas mine copes with it
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as
a magic stamp value never gets updated because the X
Leif Delgass wrote:
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as
a magic stamp value never gets updated
Keith Whitwell wrote:
Leif Delgass wrote:
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar
circumstances, but goes into an infinite loop inside
DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value
Will all this stuff about context teardown fix the problem I'm having
with my glut based program that always gives me
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 144 (XFree86-DRI)
Minor opcode of failed request: 9 ()
Steven Paul Lilly wrote:
Will all this stuff about context teardown fix the problem I'm having
with my glut based program that always gives me
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 144 (XFree86-DRI)
Minor opcode
Good advice! It looks like a double free in __driUtilUpdateDrawableInfo
when freeing pdp-pClipRects. But at that point not only has pClipRects
been freed, so has pdp! This happens (in the original code) with
__driGarbageCollectDrawables being called before the driver's
DestroyContext and the
I investigated why radeonDestroyContext wasn't being called for many of
the Mesa demos. It turns out that only a few of the demos actually
destroy the window and/or context before exit()-ing on a key press event.
So if a glut app doesn't call glutDestroyWindow() or a glx app doesn't
call
Leif Delgass wrote:
I investigated why radeonDestroyContext wasn't being called for many of
the Mesa demos. It turns out that only a few of the demos actually
destroy the window and/or context before exit()-ing on a key press event.
So if a glut app doesn't call glutDestroyWindow() or a glx
Yes, I ran into this too when the DMA buffer is flushed in
radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE
macro in the lock function, so that makes sense. Where is the drawable
destroyed?
That's the one. I haven't looked at it deeply yet (which app did you see
It was with the texobj Mesa demo, which appears to call
glDeleteTextures and then glutDestroyWindow on ESC. I haven't looked at
the implementation of glutDestroyWindow yet.
On Tue, 4 Feb 2003, Keith Whitwell wrote:
Yes, I ran into this too when the DMA buffer is flushed in
Yes, it seems to segfault while trying to deal with the error returned from
the X server. It's correct that there should be an error, but it's not clear
why the segfault occurs...
Keith
Leif Delgass wrote:
It was with the texobj Mesa demo, which appears to call
glDeleteTextures and then
On Tue, 4 Feb 2003, Keith Whitwell wrote:
Yes, I ran into this too when the DMA buffer is flushed in
radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE
macro in the lock function, so that makes sense. Where is the drawable
destroyed?
That's the one. I
Leif Delgass wrote:
On Tue, 4 Feb 2003, Keith Whitwell wrote:
Yes, I ran into this too when the DMA buffer is flushed in
radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE
macro in the lock function, so that makes sense. Where is the drawable
destroyed?
That's the
17 matches
Mail list logo
