the woes of multithreading

Started by biggeruniverse, October 12, 2006, 06:51:50

Previous topic - Next topic

biggeruniverse

1.0b3, i915, Linux (DRI)

Here's an interesting problem:

I have one thread building a dynamic VBO, another rendering from it (semaphore locks).

problem is, after a short while, I invariably get this:
#  SIGSEGV (0xb) at pc=0xa953c34f, pid=21334, tid=2842680240
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# C  [i915_dri.so+0x11a34f]

Not entirely an unusual occurance on this platform, but here is some interesting stack frame:
Stack: [0xa967e000,0xa96fe000),  sp=0xa96fcb2c,  free space=506k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [i915_dri.so+0x11a34f]
C  [i915_dri.so+0x11b6f1]  _tnl_generic_emit+0x51
C  [i915_dri.so+0x10a591]
C  [i915_dri.so+0x1005a7]  _tnl_run_pipeline+0xfe
C  [i915_dri.so+0xff522]
C  [liblwjgl.so+0x2520b]  Java_org_lwjgl_opengl_GL12_nglDrawRangeElements+0x4b
J  org.lwjgl.opengl.GL12.nglDrawRangeElements(IIIIILjava/nio/Buffer;IJ)V
J  org.lwjgl.opengl.GL12.glDrawRangeElements(IIILjava/nio/IntBuffer;)V

Seems like I'm running over then end of the range, but this shouldn't be, since the range is only updated when data have been placed in the buffer (VBO build thread is a batcher). Is there some case where the data has not been fully flushed to the card?

EDIT: for readability