<teepee>
so, shall we check if it's actually water tight?
<teepee>
Notkea: not really, it's possible to run multiple instances of OpenSCAD that reload on save, but that's probably a bit annoying to setup
<Notkea>
yes, I'm currently running multiple instances, but it starts being a bit problematic in terms of performance with complex objects which get loaded and compiled multiple times instead of just being reused and just rendered with different angles :/
<teepee>
Notkea: opening multiple windows of one instance might help by sharing the cache
<Jack22>
nice one .. my prints are always watertight i wonder why .. maybe cuz PETg
<Jack22>
oh maybe it is too fuzzy so it is more an air filter Ü
<teepee>
I suppose chances would be better at slightly higher layer size and a bit hotter printing
<teepee>
no, it's just a couple of places at the bottom where it leaks, and there's some places that look like calculation errors with large spikes sticking out
<teepee>
that showed in the slicer already
<Notkea>
teepee: I didn't think of that; This should speed things up, thanks!
<teepee>
I guess a multi camera view would be nice, no idea how complicated that would be
<teepee>
I think there's even a ticket for that already
<Jack22>
Notkea these quad views are to allign and check geometry but in oSCAD the geometry is where your code put them so it is not needed to have constant all 3 views
<teepee>
when I'm lazy I just shift cubes around with ALT+Cursor keys. I suppose that quad view would be useful in those cases :)
<Jack22>
also those quad view often only refresh the actual window .. so not so different as switching the views with hotkeys
<Notkea>
quad view would still be very useful in my workflow as I appreciate having a complete overview of the object and not having to grab the mouse, switch from the text editor to the preview window, look around the thing…
<Jack22>
teepee still you can't move object with the mouse in any direction with unknown value
<Jack22>
notkea you have ctrl 4-0 to switch views
<teepee>
true, no direct mouse movement at this point
<teepee>
heh, now I want 4 monitors :)
<Notkea>
oh that helps! Still, this requires switching back and forth contexts instead of just having everything at a glance
<Jack22>
i think this is more of a " iam used to it " thing .. in autocad i had this quad view and when using other software you miss this, but it didn't take long until you get used to on view. Also in oSCAD i put in code without needing a view ( yeah and get surprised when it doesn't look as expected )
SamantazFox has joined #openscad
SamantazFox has quit [Read error: Connection reset by peer]
SamantazFox has joined #openscad
<Notkea>
I suppose it's also that I'm using an external editor and dislike having to jump from windows, tiles, views, back to the editor, all the while I have enough screen estate to have all the things always up next to each other x)
<Jack22>
you could use a script to export the 3 views as png .. and have these open in a webpage that refreshes the content
<Notkea>
and soon, I'll have a CAD-dashboard-thing :D
* teepee
makes mental note for a GSoC project improving the 3d view
<Jack22>
maybe you could use animation to switch the views automatically
<Jack22>
not sure if less than 1sec is possible
<Jack22>
oh yes you can use 0.2 fps .. for auto cycle the views
<InPhase>
I don't really go with the same workflow as you are looking for, but I do very often setup multiple views of the same thing while I'm in intermediate stages of development.
<Jack22>
doesn't that become super slow?
<InPhase>
Well you have natural opportunities to render and cache something if you need to.
<Jack22>
notkea if you change $vpr=[0,90,0]; in your code you should be able to control the view from your external editor
<InPhase>
But usually not. Most of my designs render in good time these days, in part because my computer is faster than when I started OpenSCAD, but mostly because I tend to make them more efficiently now.
<Jack22>
yes it is a good carrot to write nice code
<Jack22>
they should give all developers pentium 3 cpu - Ü
<Notkea>
it's quite neat to control the "camera" through the source file :D
<peeps>
i only ask since i saw a number of stat calls to paths with "sbin" in them. but now looking at my PATH, i guess that's typical? i DON'T recommend running as root btw
<peeps>
spuder: i would have started with a gdb stack trace from a build with debug info. i've never gotten anything useful from valgrind, and yeah you have to apply a patch like the one you found, that's always been a problem with valgrind & CGAL
<spuder>
Yes this is in a docker container so it is running as root. I'm not too familiar with GDB but I'll see if I can figure out how to get a core dump
<peeps>
you just need a debug build of openscad, and use gdb command "bt" for backtrace (not a coredump)
<peeps>
also i have no idea what that "fmt" call is for which looks like the last thing before strace fails
gunnbr_ has joined #openscad
<InPhase>
That's probably part of that xvfb-run thing, which must be a shell script.
<InPhase>
I really doubt OpenSCAD is executing /bin/rm and /usr/bin/fmt
<InPhase>
Ah yes, and right before it opens up stat("/tmp/xvfb-run.mXOqpW/Xauthority"
<InPhase>
See the WIFEXITED, which must be close to where xvfb-run takes over from the crash.
<InPhase>
spuder: Okay. In fact, I think you have accidentally made the most useless strace ever. lol
<InPhase>
spuder: OpenSCAD is launched on line 163, then it waits for OpenSCAD until line 191 at which point it checks the child process status and prints out an error log.
<InPhase>
spuder: So you did not strace anything at all from OpenSCAD. :)
<InPhase>
Maybe you want to try reproducing that again with the strace slapped directly on the OpenSCAD process. If necessary, make a copy of xvfb-run and intrusively add the strace to your copy, and run that instead of the original.
<InPhase>
Alternatively if you're more comfortable messing with docker, make a bash script to launch OpenSCAD with an strace, and setup docker to run that script instead of the OpenSCAD executable directly.
gunnbr_ has quit [Ping timeout: 240 seconds]
<InPhase>
spuder: Oh right, and also another option is you could use strace with the -f flag, which will follow child processes.
<InPhase>
That might be a little messier, but we already have the trace of what the xvfb-run part is doing, so we could mentally subtract that out.
<InPhase>
Generally I would preference a clean trace of just the target process if possible, because then it's very clear what you're dealing with.
<peeps>
surely there's some accepted way to run commands in docker as not-root?
<spuder>
If running as root is a problem, it is possible to run as non-root docker, but from my expierence a lot of people don't bother since the container is isolated and short lived.
<InPhase>
Looking better. Checking the first of the two as a priority.
<InPhase>
So you're having an OpenGL problem.
<InPhase>
I think.
<InPhase>
It looks like it's trying to complain about "X Error of failed request: BadRequest" at the very end, then it goes to munmap (a deallocate) and it promptly terminates, so I assume it's deallocating something that is not a valid pointer when it processes this error.
<InPhase>
So there's a chance this is two problems in one. It might be an OpenGL and a stack unwinding issue in that animate code. Let me inspect it for exception safety.
<spuder>
Oh good, so the strace worked. Thanks for looking at that. I'm still working on making a debug build to run gdb against. Might take me a bit
<InPhase>
The initial OpenGL problem is probably something amiss with the docker setup.
<InPhase>
Especially if you cannot reproduce this problem without docker.
<InPhase>
And I'm not sure of your particular background, but please understand this phase of debugging involves heuristic guesswork which tends to lead in the right direction on average, but has an error rate. :)
<InPhase>
One must chase a few intuitive leads in order to make timely progress.
<peeps>
i'd try not running as root... who knows what kind of graphics conflicts that could cause
<InPhase>
Hmm. So that last munmap right before the crash, is actually attempting to free some executable memory that is created and mapped to files like /root/.glvndrnLrnL and /root/.glvndD8w6g9
<InPhase>
I'm not sure what those are, but they both start with .glvnd
<InPhase>
So this might be some sort of temporary file used by OpenGL?
<InPhase>
glvnd is the "GL Vendor-Neutral Dispatch Library"
<InPhase>
I was unable to find any exception safety issues in OpenSCAD for animation, but I think it's not that sort of problem. I think the problem is entirely an OpenGL crash now.
<InPhase>
I think the OpenGL library has some sort of problem, attempts to report the error, fails hard, and segfaults itself.
<InPhase>
I'll document on github.
<spuder>
Thank you
KimK has quit [Quit: Leaving]
<InPhase>
spuder: openscad --info Since you're not running it graphically, running the info might give you some insight into the libraries actually in use.