I *think* there may be a bug in recent drivers regards glShaderSource() and multiple strings being assembled. I have gone over my own code quite a few times and I can't find an error - although I am not totally convinced it isn't my fault yet. It works fine on other vendors hardware though currently. So I wanted to check if this was a known bug currently?
I am effectively calling it with: glShaderSource(shader, snippets, snippetSizes, 9)
But each snippet string is a mix of null terminated strings and fixed length ones (with -1 lengths to mark the null terminated ones).
My array of string sizes contains:
| [0] | -1 |
| [1] | -1 |
| [2] | 2112 |
| [3] | 1 |
| [4] | 334 |
| [5] | 1 |
| [6] | 2173 |
| [7] | 2182 |
| [8] | -1 |
Which seems to match up fine with my string buffers (I can't see any off by one errors etc so far). With the -1 size ones being null terminated correctly. One thing is that some of those string snippets of length 1 only contain newline characters ([3] & [5] specifically). So I wondered if it was possible your driver was tripping up there?
Also I memory map these string snippets from files in so I wonder also if your driver was reading past and causing the access violation I am seeing?
....
Having dug into it some more it seems if I pass explicit lengths for all string snippets the crash goes away (So in the test case above I replace the -1's with exact lengths). So I suspect you have a bug in your handling of null terminated strings?
