Hey guys. I'm trying to make my engine cross platform but I've stumbled across an issue. I'm trying to use the command glDrawElementsBaseVertex, and this works perfectly in Windows, but not at all in Linux. I've traced the problem to there, and I checked that my VAO is bound and that all the parameters to the function are exactly the same. Where could I find the source of this issue? I'm using gl3w if that's relevant (because glew is outdated). I can't really show my entire code here because it's thousands upon thousands of lines across multiple DLLs, but if you'd like to take a look at something I could paste that section here. Thanks in advance!
glDrawElementsBaseVertex causes segfault on Linux but no issues on Windows
The OS is not relevant.
What is relevant is the hardware and drivers. If either don't support that entry point, then the function pointer for it will be NULL, and it will crash if you try to use it.
The OS is not relevant.
What is relevant is the hardware and drivers. If either don't support that entry point, then the function pointer for it will be NULL, and it will crash if you try to use it.
this...
Make sure you validate your function pointers!
What kind of segfault is it? Read or write? Do you know the memory address?
Implementations of GL often crash inside glDraw* functions because you've passed an invalid pointer to an early state/resource setting function, which the implementation has simply cached for use on the next draw call.
Author
The OS is not relevant.
What is relevant is the hardware and drivers. If either don't support that entry point, then the function pointer for it will be NULL, and it will crash if you try to use it.
The OS is not relevant.
What is relevant is the hardware and drivers. If either don't support that entry point, then the function pointer for it will be NULL, and it will crash if you try to use it.
this...
Make sure you validate your function pointers!
What kind of segfault is it? Read or write? Do you know the memory address?
Implementations of GL often crash inside glDraw* functions because you've passed an invalid pointer to an early state/resource setting function, which the implementation has simply cached for use on the next draw call.
I did try check the function address before posting this topic and it seemed to be working fine. I did an upgrade and I'm pretty sure I have the latest driver version installed. I'm not super experienced with Linux development so how can I tell you the default state? And if I use the same code for Linux and windows (aside from windowing code), shouldn't the pointer be valid?
Not necessarily. GL is a specification, not a library. Different drivers contain different libraries that attempt to comply with that specification, each with their own actual behaviours.And if I use the same code for Linux and windows (aside from windowing code), shouldn't the pointer be valid?
If you're using GL in a way that the spec says that you're not allowed to, then perhaps one implementation is pessimistic and contains error handling to tolerate buggy apps, while the other implementation assumes that all apps also follow the spec and encounters undefined behaviour when apps don't.
Also if it's a bug in your code where you're passing an invalid pointer, then it comes down to the details of that bug. Perhaps it's a "use after free bug", but on Windows the memory allocator hasn't unmapped the pages used by that allocation (meaning that reading from the "free'ed" memory won't actually crash), while on Linux the pages are unmapped immediately, leading to a segfault when GL attempts to read from them.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
