Bug#858904: openscad: opengl / x11 strange "hanging" error (also found in other packages)
ok yes after using openscad consistently for several days now, i get recurrence of this well-known behaviour quite frequently. if i was to put an arbitrary percentage on it, it would be about... 2% (1-in-50) of every attempted move/rotate operation with the mouse. anyway, main point of this bugreport is to alert you: it's not openscad, it's definitely a dependency *of* openscad. l.
Bug#858904: openscad: opengl / x11 strange "hanging" error (also found in other packages)
hi chrysn, i have an extremely powerful machine with 16gb of 2400mhz DDR4 RAM, 8-core i7 and a 2500mbyte/sec SSD. speed is *not* a problem :) a simple model easily gives a framerate of appx 30fps. however it is working really rather hard: i had openscad run with a window @ 1940 x 1400 and was rotating the object round with the mouse for just over 30 seconds, possibly longer. one core jumped to a frequency of 2.27ghz and CPU usage was 50%. i've just tried this again but could not reproduce it. it *really* is a bit of a bitch i'm afraid. two circumstances where it's *definitely* reproducible: * current version of chrome browser when you're using the web-based facebook "chat". * resizing glxgears under fvwm2 (this one is 100%) this latter causes fvwm2 to show a wire-frame only, during which time the race condition is triggered instantly. other circumstances are much much harder to reproduce, which is why it's been well over a year, now, and this bug is still outstanding (wherever it is). sorry i couldn't give better news! l. On 3/28/17, chrysnwrote: > Hi, > > On Tue, Mar 28, 2017 at 01:56:21PM +0100, lkcl wrote: >> the issue appears to be that a race condition causes a frame to be >> dropped. however once there is only one frame dropped, *all* >> subsequent frames stop from that point onwards. > > that is a tricky one. > > I've tried to reproduce the issue with octave-gui as described in > #848895 (even under full CPU load as "helped" with the chromium > version), but it did not trigger a lockup on my machine. > > Are there any other known ways to trigger this (to find out which > machines are affected at all), or to trigger this in OpenSCAD? > > Best regards > chrysn >
Bug#858904: openscad: opengl / x11 strange "hanging" error (also found in other packages)
Hi, On Tue, Mar 28, 2017 at 01:56:21PM +0100, lkcl wrote: > the issue appears to be that a race condition causes a frame to be > dropped. however once there is only one frame dropped, *all* > subsequent frames stop from that point onwards. that is a tricky one. I've tried to reproduce the issue with octave-gui as described in #848895 (even under full CPU load as "helped" with the chromium version), but it did not trigger a lockup on my machine. Are there any other known ways to trigger this (to find out which machines are affected at all), or to trigger this in OpenSCAD? Best regards chrysn signature.asc Description: PGP signature
Bug#858904: openscad: opengl / x11 strange "hanging" error (also found in other packages)
Package: openscad Severity: important Tags: upstream as can be seen in #848895 and is being reported in an increasingly large number of other packages that use x11 and opengl, there is an obscure race-condition which is causing intermittent "hanging" of all and any packagees that make significant use of x11 / opengl. the issue appears to be that a race condition causes a frame to be dropped. however once there is only one frame dropped, *all* subsequent frames stop from that point onwards. the "recovery" method on chromium is to kill the errant process, but that's only because a background thread takes care of drawing the contents of a tab (which can subsequently be "refreshed"). in the case of most applications which are single-process, the "recovery" method is to press ctrl-alt-f1 then ctrl-alt-f7 which is an extremely bizarre way to break the deadlock that is 100% guaranteed to work. several people have reported totally different GPUs so it is known not to be a specific GPU-related issue. several people have reported using totally different window managers so it is known not to be a specific window-manager-related issue. however until the actual cause is known it's become necessary to alert *every* single affected package so that (eventually) the underlying cause can be tracked down, collaboratively. it also does not help that the exact dependency in which the root cause of the problem is simply... not known. the google chromium browser team have *attempted* to create workarounds for something like over a year, now, and each and every single workaround for the underlying race condition proves to have increasingly severe consequences, the most recent being unacceptably-high CPU load for several minutes across multiple threads, just before the race condition is triggered. so... sorry... complicated scenario! -- System Information: Debian Release: 7.4 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openscad depends on: pn libboost-filesystem1.55.0 pn libboost-program-options1.55.0 pn libboost-regex1.55.0 pn libboost-system1.55.0 pn libboost-thread1.55.0 ii libc6 2.23-4 pn libcgal10 ii libgcc1 1:6.3.0-10 ii libgl1-mesa-glx [libgl1]13.0.2-3 ii libglew1.10 1.10.0-3 ii libglib2.0-02.50.1-1 ii libglu1-mesa [libglu1] 9.0.0-2.1 ii libgmp102:6.1.2+dfsg-1 ii libmpfr43.1.3-1 ii libopencsg1 1.3.2-2+b1 ii libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libstdc++6 6.3.0-10 ii libx11-62:1.6.4-2 Versions of packages openscad recommends: pn openscad-mcad Versions of packages openscad suggests: pn geomview ii librecad 2.0.4-1 ii meshlab 1.3.2+dfsg1-2+b1 pn openscad-testing