<InPhase>
That makes more sense. I was staring at your first link going "how??" lol
<InPhase>
guso9: I think it never leaves the if above L70 with that null.
<InPhase>
That's if null, maybe try something else, if still null throw.
<InPhase>
Not the most maintenance-robust structure to mix extra logic with the null guard, but it seems valid as a guard as-is.
<InPhase>
It'd be cleaner to write that as: if (!this->ctx && !strcmp(provider, "egl")) { ... } if (!this->ctx) { throw... } if (!this->ctx->makeCurrent()) { throw... } But it's logically equivalent, and probably compiles to the same code.
<guso9>
if this->ctx evaluates to null in line60, 61-69 is not executed, but line70 performs null->makeCurrent
guso9 has quit [Quit: Client closed]
hyperair has quit [Remote host closed the connection]
guso14 has joined #openscad
howiemnt has quit [Read error: Connection reset by peer]
howiemnt1 has joined #openscad
hyperair has joined #openscad
howiemnt1 has quit [Remote host closed the connection]
howiemnt1 has joined #openscad
fling has joined #openscad
hyperair has quit [Ping timeout: 252 seconds]
L29Ah has joined #openscad
guso14 has quit [Quit: Client closed]
mmu_man has joined #openscad
snakedGT has quit [Quit: Leaving]
mwette has joined #openscad
guso78k has joined #openscad
kintel has joined #openscad
<kintel>
guso I don't understand: "if this->ctx evaluates to null in line60, 61-69 is not executed, but line70 performs null->makeCurrent"
<kintel>
if this->ctx evaluates to null in line60, line 61-69 should most definitely be executed
<kintel>
..or am I experiencing pre-coffee blindness?
<kintel>
InPhase Yeah, the fallback logic is more convoluted than necessary. This code started diverging from my upstream offscreen GL testing repo. Is should fix that one day I'm bored ;)
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<InPhase>
kintel: You just need to share your coffee with guso78k. :) He missed processing the "!"
<guso78k>
I am awake now :) yes you are correct.
<guso78k>
i am hunting a segfault, i was confident, that i found it.
<guso78k>
he reports he tried this witgh " GNU guix package"
<InPhase>
guso78k: Are you able to reproduce it on Linux, I mean?
<guso78k>
i could try this next. i never tried to intentionally disable GLX ';)
<InPhase>
https://bpa.st/243Q I recommend running this on crazy segfaults. It tracks the maximum resident size of openscad in a log file, ~/.openscad_mem.log If you're getting surprise out of memory errors, this will make it clear from the amount of memory reported in the log file.
<InPhase>
I actually always run openscad this way, for long term record keeping, so there's no performance hit.
<InPhase>
Since memory outages will show up as segfaults, it can keep you from chasing the wrong tail.
<guso78k>
i believe its a static error. he repors , that all his ctests have failed
<InPhase>
Ah.
<InPhase>
Well that's different.
<InPhase>
guso78k: Note that this can occur from as simple as a compatibility mismatch in how two things were compiled. This will happen at runtime rather than at execution start if and only if something like dlopen is used.
<InPhase>
And guess what I see when I grep -r for every case of dlopen in the codebase...
<InPhase>
ext/glad/gl.h and ext/glad/glx.h
<InPhase>
I will be unshocked if the segfault is found to be happening on one of those two lines with handle = dopen(...)
<InPhase>
(Or promptly thereafter at usage.)
<guso78k>
right now i try to reproduce that now in linux, but need to compile first
<guso78k>
i can reproduce the bug in my linux with main openscad when i compile with -DENABLE_GLX=0
<guso78k>
any ctests which uses -o to write a png will fail
<kintel>
guso78 just so I understand this: There is a crash if neither EGL or GLX is found, as the GLView destructor assumes that a shader was initialized, and your PR fixes that.
<kintel>
..but with your PR, it's expected that OpenSCAD simply exits, right? ..since with neither EGL or GLX, there is no rendering support?
kintel has quit [Quit: My Mac has gone to sleep. ZZZzzz…]