Was the trace collected on the NVIDIA system or the Intel system?

(In reply to Ian Romanick from comment #1)
> Was the trace collected on the NVIDIA system or the Intel system?

The Intel system.

At the point of failure the code is sending a sequence of texture tiles to glTexImage2D. It's somewhat of a hangover from image tiling that was necessary with the GM945 and OpenGL 1.4 and the need for POT texture sizes.

I tried the trace with a very, very old version of apitrace and current master.  I was unable to reproduce the segfault with current Mesa master on Broadwell on either version.  If I'm cross referencing CPUs to GPUs correctly (using https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units), we should have about the same GPU.

I do get:

614: message: shader compiler issue 1: FS SIMD8 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
614: message: shader compiler issue 2: FS SIMD16 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
614: message: shader compiler issue 3: VS SIMD8 shader: 22 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 352 to 288 bytes.
614: message: shader compiler issue 4: FS SIMD16 shader: 2 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 32 to 32 bytes.
614: message: shader compiler issue 5: VS SIMD8 shader: 10 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 160 to 96 bytes.
error: xlib: GLXBadDrawable
error: xlib: GLXBadDrawable
error: drawable failed to resize: expected 32x32, got 0x0
649: message: shader compiler issue 6: FS SIMD8 shader: 4 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 64 to 48 bytes.
649: message: shader compiler issue 7: FS SIMD16 shader: 4 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 64 to 48 bytes.
649: message: shader compiler issue 8: VS SIMD8 shader: 10 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 160 to 96 bytes.
659: message: shader compiler issue 9: FS SIMD8 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
659: message: shader compiler issue 10: FS SIMD16 shader: 5 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 80 to 48 bytes.
659: message: shader compiler issue 11: VS SIMD8 shader: 18 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 288 to 256 bytes.
661: message: shader compiler issue 12: VS SIMD8 shader: 18 inst, 0 loops, 0:0 spills:fills, Promoted 0 constants, compacted 288 to 256 bytes.
error: xlib: GLXBadDrawable
error: xlib: GLXBadDrawable
error: drawable failed to resize: expected 1365x1024, got 0x0
715: message: api performance issue 13: Multi-LOD fast clear - giving up (256x256x8).

After this there a bunch more instances of the Multi-LOD fast clear performance warning.  Through the whole thing I just get a black window.

Can you provide a backtrace from the segfault?

The GPU as reported by Mesa is: HD Graphics 6000 (Broadwell GT3)

I built apitrace just this morning (Matt Turner suggested it). The screen is indeed blank because it is loading the initial splash image. There are about 48 calls to glTexImage2D to load the tiles for the splash page. It doesn't crash on the first call.

I'm obviously new to apitrace but I'll try and get a back trace...

Created attachment 119309 [details]
trace dump

you can see the sequential calls to dlTexImage2D...

Sorry... I didn't ask clearly enough.  I just wanted a stack backtrace from GDB from the point of the segfault.  You should just be able to

gdb --args ./glretrace seg_fault_glTexImage2d.trace 

"r", the "bt".

There are a couple weird things in that trace... are you really setting the filter mode and warp modes with glTexParameterf (instead of glTexParameteri)?  It's legal, but a little weird...

I wonder if the segfault (which only occurs for you in apitrace, right?) is due to apitrace doing weird things with GL_UNPACK_* settings you're using... like not having the source buffer set up correctly so that glTexImage reads past the end or something.  Dunno.

Created attachment 119310 [details]
artefacts when rendering via FBO

It is possible that there are two issues:

[1] 
That there is a long-standing bug in my glTexImage2D code which runs fine on Nvidia and even with the old GM945 !!

[2] 
That there is something up with glTexImage2D that somehow messes up the image only when I use an FBO and is cleverly detected by apitrace.

I don't think I can use GDB because the code doesn't crash when run normally, only with apitrace. It could be a bug in apitrace, maybe...

I'm really just trying to figure out the artefacts since the code "seems" to run reliably for weeks on end.

I cleaned these up:

There are a couple weird things in that trace... are you really setting the filter mode and warp modes with glTexParameterf (instead of glTexParameteri)?  It's legal, but a little weird...

No change.

1305 glGetTexLevelParameteriv(target = GL_TEXTURE_2D, level = 0, pname = GL_TEXTURE_COMPRESSED, params = &0)

1306 glGenTextures(n = 1, textures = &46)
1307 glBindTexture(target = GL_TEXTURE_2D, texture = 46)
1308 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_LINEAR)
1309 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_BASE_LEVEL, param = 0)
1310 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR)
1311 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_CLAMP_TO_EDGE)
1312 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_CLAMP_TO_EDGE)
1313 glPixelStorei(pname = GL_UNPACK_ROW_LENGTH, param = 2048)
1314 glPixelStorei(pname = GL_UNPACK_SKIP_PIXELS, param = 768)
1315 glPixelStorei(pname = GL_UNPACK_SKIP_ROWS, param = 1280)
1316 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_GENERATE_MIPMAP, param = 1)
1317 glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGB, width = 256, height = 256, border = 0, format = GL_RGBA, type = GL_UNSIGNED_BYTE, pixels = blob(12585984))
1319 glGetTexLevelParameteriv(target = GL_TEXTURE_2D, level = 0, pname = GL_TEXTURE_COMPRESSED, params = &0)

1320 glGenTextures(n = 1, textures = &47)
1321 glBindTexture(target = GL_TEXTURE_2D, texture = 47)
1322 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_LINEAR)
1323 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_BASE_LEVEL, param = 0)
1324 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR_MIPMAP_LINEAR)
1325 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, param = GL_CLAMP_TO_EDGE)
1326 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, param = GL_CLAMP_TO_EDGE)
1327 glPixelStorei(pname = GL_UNPACK_ROW_LENGTH, param = 2048)
1328 glPixelStorei(pname = GL_UNPACK_SKIP_PIXELS, param = 1024)
1329 glPixelStorei(pname = GL_UNPACK_SKIP_ROWS, param = 1280)
1330 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_GENERATE_MIPMAP, param = 1)

and then a seg fault

(In reply to Clive McCarthy from comment #9)
> I don't think I can use GDB because the code doesn't crash when run
> normally, only with apitrace. It could be a bug in apitrace, maybe...

You can run apitrace in GDB. :)  I gave the command line that I used in comment #7.  Does that (or something similar) work for you?

My gut tells me that the rendering problem and the apitrace crash are separate issues.  If we can sort out what's going wrong with apitrace, I should be able to use the trace you provided to debug the rendering problem.

I agree. I'll run GDB as you suggest. Damn -- have to solve an ancillary problem to get to the real one.

I installed the development version of Mesa 11.1 dated November 4th. The artefacts experienced when blitting to and rendering via an FBO from Mesa 11.1 dated October 26th, that were the start of this report, have gone.

I think you can close this bug out.

Dear Reporter,

This Mesa bug has been in the "NEEDINFO" status for over 60 days. I am closing this bug based on lack of response but feel free to reopen if resolution is still needed. Please ensure you're supplying the correct information as requested.

Thank you.