Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OpenScad 2019.04.07 hangs on "New" or "Open File" when running in 32bit userspace on 64bit Linux kernel #2933

Open
KlausKnopper opened this issue Apr 13, 2019 · 17 comments
Open

OpenScad 2019.04.07 hangs on "New" or "Open File" when running in 32bit userspace on 64bit Linux kernel #2933

KlausKnopper opened this issue Apr 13, 2019 · 17 comments
Labels
OS: Linux Type: Bug

Comments

@KlausKnopper
Copy link

KlausKnopper commented Apr 13, 2019 •
edited by MichaelAtOz
Loading

Recent issues of openscad (also nightly builds) hang indefinitely in the editor/preview view on 32bit Debian, intel i915 graphics. Stable version 2015.03 built with exactly the same libraries works on the same machine.

strace of version 2019.04.07 keeps looping in
3848 ioctl(11, DRM_IOCTL_I915_GEM_MADVISE, 0xfff0178c) = 0
3848 ioctl(11, DRM_IOCTL_I915_GEM_BUSY, 0xfff01724) = 0
...repeating...

The error might be similar to the previously reported QT5 crash on start issue on Windows machines, though the workaround of changing QT_OPENGL=(anything...) does not work here.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
@t-paul
Copy link
Member

t-paul commented Apr 14, 2019

Please add the details asked for in that FAQ entry: How_do_I_report_bugs?

That sounds like a tricky one, so we need to collect all the information we can. I don't see how to easily reproduce, or is it reproducable in some VM?

@KlausKnopper
Copy link
Author

KlausKnopper commented Apr 14, 2019 via email

@t-paul
Copy link
Member

t-paul commented Apr 14, 2019

I can't reproduce on a fresh installed debian-unstable, so an ISO showing the issue would be useful. I think that installed Gnome on Wayland, not sure if that is important.

Linux debian-unstable-32bit 4.19.0-4-686-pae #1 SMP Debian 4.19.28-2 (2019-03-15) i686 GNU/Linux

Library Info... (interesting memory amount ;-)

OpenSCAD Version: 2019.01-RC2
System information: Linux 4.19.0-4-686-pae #1 SMP Debian 4.19.28-2 (2019-03-15) i686 Debian GNU/Linux buster/sid 2 CPUs 16777216.00 TB RAM
User Agent: OpenSCAD/2019.01-RC2 (Linux i686; Debian GNU/Linux buster/sid)
Compiler: GCC "8.3.0" 32bit
MinGW build: No
Debug build: No
Boost version: 1_67
Eigen version: 3.3.7
CGAL version, kernels: 4.13, Cartesian, Extended_cartesian, Epeck
OpenCSG version: OpenCSG 1.4.2
Qt version: 5.11.3
QScintilla version: 2.10.4
InputDrivers: 
GLib version: 2.58.3
lodepng version: 20180910
libzip version: 1.5.1
fontconfig version: 2.13.1
freetype version: 2.9.1
harfbuzz version: 2.3.1
lib3mf version: 1.8.1

GLEW version: 2.1.0
OpenGL Version: 3.1 Mesa 18.3.4
GL Renderer: llvmpipe (LLVM 7.0, 128 bits)
GL Vendor: VMware, Inc.
RGBA(8880), depth(0), stencil(0)
GL_ARB_framebuffer_object: yes
GL_EXT_framebuffer_object: yes
GL_EXT_packed_depth_stencil: yes

Qt graphics widget: QOpenGLWidget
QSurfaceFormat: RGBA(8880), depth(0), stencil(0)

@donbright
Copy link
Sponsor Member

does it work with software rendering? (Is that even still a thing?)

IIRC you can test by running this:

 $ LIBGL_ALWAYS_SOFTWARE=1 openscad

@KlausKnopper
Copy link
Author

LIBGL_ALWAYS_SOFTWARE=1 openscad-nightly

hangs the same way.

@t-paul
Copy link
Member

t-paul commented May 2, 2019

Yes, I'm seeing that in my test VM too. I'm a bit stuck as it's not reproducible on a "normal" 32bit Debian VM. The only item remaining on my idea list is to get an AppImage going for 32bit and see what that is doing when run the Knoppix image.

@KlausKnopper
Copy link
Author

KlausKnopper commented Jul 23, 2019 via email

@KlausKnopper KlausKnopper changed the title OpenScad 2019.04.07 hangs on "New" or "Open File" on Intel Graphics / Linux OpenScad 2019.04.07 hangs on "New" or "Open File" when running in 32bit userspace on 64bit Linux kernel Jul 30, 2019
@KlausKnopper
Copy link
Author

Changed issue topic to reflect the recent findings.

@t-paul
Copy link
Member

t-paul commented Oct 24, 2019

I still can't reproduce in any development environment. I've now installed a Debian 10/32-bit VM and updated the kernel to an amd64 variant.
Interestingly that totally broke booting into gdm so that seems to be affected by the issue too. After installing lxdm graphical login was possible. Compiling and running current master of OpenSCAD on that system works fine.

@KlausKnopper
Copy link
Author

KlausKnopper commented Oct 24, 2019 via email

@t-paul
Copy link
Member

t-paul commented Oct 24, 2019

Yep, I did:

dpkg --add-architecture amd64
apt-get update
apt-get --no-install-recommends install linux-image-amd64:amd64
uname -a
Linux debian10-32bit 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux

But maybe later booted into the wrong kernel again. I can now reproduce the issue and it seems it hangs inside swrast_dri.so. OpenSCAD does run when disabling the axis markers but the display is still not correct.
Unfortunately I don't think there's much that can be done on OpenSCAD side to fix the issue. Maybe there's a way to disable DRI but I could not find a setting for that yet.

@KlausKnopper
Copy link
Author

KlausKnopper commented Oct 25, 2019 via email

@t-paul
Copy link
Member

t-paul commented Oct 25, 2019

True, it's triggered by a change in OpenSCAD. Other applications are probably not a good reference as OpenSCAD still uses ancient OpenGL, partially even fixed pipeline which is probably (hopefully?) not used much anymore.
I tried to check with RenderDoc but this requires OpenGL 3.2+ context. So it might be OpenSCAD doing something wrong with the API but without tools that's going to be hard to find. Maybe someone reading this has pointers to other ways of validating OpenGL API calls?

@t-paul
Copy link
Member

t-paul commented Oct 26, 2019

Hmm, git bisect produced

git bisect start
# bad: [6ec97fda154b0578688ab98723685c66af7a7a71] More MacOS builds.
git bisect bad 6ec97fda154b0578688ab98723685c66af7a7a71
# good: [be4fd23dc6b9f4de44c5a4c5cee94894dc139393] Cleaned out old 32-bit Mac builds
git bisect good be4fd23dc6b9f4de44c5a4c5cee94894dc139393
# good: [bf6153592bebd0299722b4c535ef827bdaeec5f1] make the default value of getVec3 explicit by overloading getVec3
git bisect good bf6153592bebd0299722b4c535ef827bdaeec5f1
# bad: [1434fb9ec370294aa18205c3bbdb8d21db89750e] Check only actual parameter sets for isEmpty().
git bisect bad 1434fb9ec370294aa18205c3bbdb8d21db89750e
# good: [c31b627be142f3304b8fa6870a53a3b10ce2c17a] Merge pull request #2638 from MichaelPFrey/para
git bisect good c31b627be142f3304b8fa6870a53a3b10ce2c17a
# bad: [9147d940f3464ae59b113689f8fde1c4df003cfc] Merge pull request #2708 from openscad/3d-printing-updates
git bisect bad 9147d940f3464ae59b113689f8fde1c4df003cfc
# good: [ed93d3fec5d11bedc06f5200a3a740a72c7b6c56] Merge pull request #2672 from openscad/3d-printing-init-dialog
git bisect good ed93d3fec5d11bedc06f5200a3a740a72c7b6c56
# good: [155f90406cb0a86840208567531596c4da03e810] move the "try catch" for readability and to make it more modular
git bisect good 155f90406cb0a86840208567531596c4da03e810
# good: [88417b32b873912ded901630c4198c0828911916] clean up
git bisect good 88417b32b873912ded901630c4198c0828911916
# bad: [69bf5a55475102be43c2ddc698198e85821332b3] Merge pull request #2697 from MichaelPFrey/ParaRangeCheck
git bisect bad 69bf5a55475102be43c2ddc698198e85821332b3
# good: [8b6e905f68d7ce19db1ef3e649dc85c25b315cd9] Merge pull request #2706 from openscad/amf-remove-experimental-flag
git bisect good 8b6e905f68d7ce19db1ef3e649dc85c25b315cd9
# good: [0d1bc651f0d4e407905f477d99965b17e2e2b144] clean up
git bisect good 0d1bc651f0d4e407905f477d99965b17e2e2b144
# bad: [d26ea931d7bb0583496e1245ef9c7fa3de871939] Merge pull request #2710 from openscad/input-driver-remove-experimental-flag
git bisect bad d26ea931d7bb0583496e1245ef9c7fa3de871939
# bad: [2b505f1dd943d0051db2130d5029bdb7ebf6d830] Change input-driver experimental flag to cover only the DBus driver (fixes #2704).
git bisect bad 2b505f1dd943d0051db2130d5029bdb7ebf6d830
# first bad commit: [2b505f1dd943d0051db2130d5029bdb7ebf6d830] Change input-driver experimental flag to cover only the DBus driver (fixes #2704).

Which seems pretty strange as the offending commit does not touch any of the display logic. Assuming it could have something to do with Qt initalizing stuff, I disabled the change in the bad commit and it worked afterwards. But after applying the similar change to master it did not help. And now even recompiling some of the good commits are broken. So I'm a bit at a loss here.

@t-paul
Copy link
Member

t-paul commented Oct 27, 2019

So the issue is triggered when processing the custom QEvents created from the input driver code via QCoreApplication::postEvent(). It's not clear how that would deadlock in the OpenGL driver and I don't see a way to fix that yet.

@t-paul t-paul mentioned this issue Nov 11, 2019
Open
@KlausKnopper
Copy link
Author

Workaround: In input/InputDriverManager.cc (openscad version 2021.01), replace

void InputDriverManager::postEvent(InputEvent *event){
 ...  QCoreApplication::postEvent(window, event);
}

by an empty function, and openscad works again compiled in 32bit running on a 64bit kernel, no freezes anymore. As far as I can tell, keyboard and mouse are still working without the call to postEvent().

My best guess is that for some reason, input events may get retransmitted in an endless loop in the combination of 32bit application+64bit kernel.

So, the DRM messages observed in the log may have been unrelated or caused by openscad trying to readjust the graphics canvas too frequently because of exceed input events.

@t-paul
Copy link
Member

t-paul commented Feb 3, 2022

Yes, this is only used for 3D-Mouse / Gamepad and so on. As those will be non-functional, it might make sense to also make sure those devices are disabled.

I think the easy config options were only added after the release for the cmake build. The options would be

  • ENABLE_JOYSTICK
  • ENABLE_QGAMEPAD
  • ENABLE_HIDAPI
  • ENABLE_SPNAV
  • ENABLE_DBUS

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
OS: Linux Type: Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@kintel @donbright @t-paul @KlausKnopper