Bug#858904: openscad: opengl / x11 strange "hanging" error (also found in other packages)

2017-04-03 Thread Luke Kenneth Casson Leighton
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)

2017-03-28 Thread Luke Kenneth Casson Leighton
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, chrysn  wrote:
> 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)

2017-03-28 Thread chrysn
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)

2017-03-28 Thread lkcl
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