334.21, GTX260: Segfault in libnvidia-glcore.so.334.21 on glDrawElements

Graphics / Linux Linux
1

I’m in the middle of writing a graphics engine, and keep running into an issue where libnvidia-glcore will SIGSEGV during certain draw calls. While I haven’t tried to distill it down into the smallest possible combination of commands, it is 100% reproducible and appears to be triggered by the following sequence of events:

  • Call glUseProgram(x)
  • Set some uniforms/attrib pointers, but ultimately don't call glDrawElements or call it with count=0
  • Call glUseProgram(y)
  • Set some uniforms/attrib pointers, then call glDrawElements
  • Segfault!
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff354b960 in ?? () from /usr/lib/libnvidia-glcore.so.334.21
(gdb) bt
#0  0x00007ffff354b960 in ?? () from /usr/lib/libnvidia-glcore.so.334.21
#1  0x00007ffff35d8b88 in ?? () from /usr/lib/libnvidia-glcore.so.334.21
#2  0x00007ffff35dad8b in ?? () from /usr/lib/libnvidia-glcore.so.334.21
#3  0x00007ffff35db097 in ?? () from /usr/lib/libnvidia-glcore.so.334.21
#4  0x00007ffff32aabf2 in ?? () from /usr/lib/libnvidia-glcore.so.334.21
#5  0x00000000004eece8 in MR::Roundtree::Button::draw (this=0xf64380)
...

For reference, this is occuring under Arch Linux 64-bit with the 334.21 drivers on a GTX 260. See attachments for a copy of the nvidia-bug-report.sh log and an apitrace file terminating at a segfault.

nvidia-bug-report.log.gz (66.6 KB)
roundtree.segfault.trace.gz (157 KB)

2

Plz share sample apps/program to reproduce this issue with compilation procedure.

3

The Apitrace file attached will reproduce the segfault; it contains the entire GL command stream.

Have a look at calls 2763 to 2781; it’s a method to render a text string as a texture-mapped triangle list. In this case, the string is empty, so it sets the program, organizes the state and makes a couple of calls to glDrawElements with count=0. The next (unrelated) draw method will set the program, organize the state and segfault when calling glDrawElements, at which point the trace file ends.

(I’ve worked around the segfault in my code by skipping calls 2763-2781 if the string is empty.)

gunzip roundtree.segfault.trace.gz
glretrace roundtree.segfault.trace
  • To view the entire command stream and review the GL state at any point:
qapitrace roundtree.segfault.trace
4

Thanks for reporting this. We filed bug 1484396 to track it.

5

One of our engineers examined the trace and determined that in call #2795, it draws with vertex attribs 0 and 1 enabled. Vertex attrib 1 references buffer 13, for which you’ve never called BufferData. In other words, your draw call references an unallocated vertex array, and a crash is to be expected. This doesn’t appear to be a NVIDIA bug.

6

Okay, lesson learned; disable all the vertex attribs at the end of each draw block. (for some reason I thought this state got reset when the program changed)

Thank you for looking into it, I was thrown by how the same code ran fine under 3/4 target platforms. It’s curious that it crashes at just that particular spot, given that the entire trace is guilty of leaving extra vertex attribs enabled.