Bug#900678: slic3r: Segfaults at start since new wxwidgets.

[Olly Betts]

On Wed, Oct 10, 2018 at 09:26:17AM +1300, Olly Betts wrote:
> If we could automate "GDK_BACKEND=x11" (or equivalent via the GDK
> API) in wxwidgets that would be a neater way to address this until
> the upstream code is updated to not require X11, but that seems to
> be tricky to do because we don't know if wxGLCanvas will be used
> or not at the point where we need to do this.  Forcing X11 for all
> apps using the gtk3 flavour of wxwidgets3.0 seems a bad idea.

It occurs to me that we could add the code to force X11 so that it
activates when the libwx_gtk3u_gl-3.0.so is loaded.  If the app is
linked to that library that makes it very likely wxGLCanvas will
be used, and if it isn't linked to that library, it won't be.

I tend to think this is probably better handled by adding workaround
code to affected apps though - they'll need it to work under Wayland
on other distros after all.

Cheers,
Olly

Bug#900678: slic3r: Segfaults at start since new wxwidgets.

[Tobias Frost]

Package: slic3r
Version: 1.3.0+dfsg1-2
Severity: important

Hi,

Slic3r segfaults immediatly after launching.

Triaging into it is seems that the update of wxwidgets
causes this, at least I can reproduce on my other machine
that when I update wxwidgets slic3r begins to fail.

Attached is a gdb trace

About the wxwdgets triaging:
I've downgraded to the version I had before the segfault on the
other machine. I did not invesitage if an intermediate version fixes it.
The version I've downgraded to was: 3.0.3.1+dfsg2-1. (via snapshot.d.o)

This is the aptitude log file for the downgrade:
$ cat /var/log/aptitude
Aptitude 0.8.10: log report
Sun, Jun  3 2018 12:00:38 +0200

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 11 packages, and remove 11 packages.
114 MB of disk space will be freed

[REMOVE, NOT USED] fonts-freefont-ttf:amd64 20120503-8
[REMOVE, NOT USED] libalut0:amd64 1.1.0-5+b2
[REMOVE, NOT USED] libftgl2:amd64 2.1.3~rc5-4+nmu1.2
[REMOVE, NOT USED] libwxgtk-media3.0-gtk3-0v5:amd64 3.0.4+dfsg-4
[REMOVE, NOT USED] libwxgtk-media3.0-gtk3-dev:amd64 3.0.4+dfsg-4
[REMOVE, NOT USED] libwxgtk3.0-gtk3-dev:amd64 3.0.4+dfsg-4
[INSTALL, DEPENDENCIES] libwxgtk-media3.0-0v5:amd64 3.0.3.1+dfsg2-1
[INSTALL, DEPENDENCIES] libwxgtk-media3.0-dev:amd64 3.0.3.1+dfsg2-1
[INSTALL, DEPENDENCIES] libwxgtk3.0-dev:amd64 3.0.3.1+dfsg2-1
[DOWNGRADE] libalien-wxwidgets-perl:amd64 0.69+dfsg-2 -> 0.67+dfsg-3+b5
[DOWNGRADE] libwx-glcanvas-perl:amd64 0.09-5 -> 0.09-3+b5
[DOWNGRADE] libwx-perl:amd64 1:0.9932-4 -> 1:0.9932-2
[DOWNGRADE] libwxbase3.0-0v5:amd64 3.0.4+dfsg-4 -> 3.0.3.1+dfsg2-1
[DOWNGRADE] libwxbase3.0-dev:amd64 3.0.4+dfsg-4 -> 3.0.3.1+dfsg2-1
[DOWNGRADE] libwxgtk3.0-0v5:amd64 3.0.4+dfsg-4 -> 3.0.3.1+dfsg2-1
[DOWNGRADE] wx-common:amd64 3.0.4+dfsg-4 -> 3.0.3.1+dfsg2-1
[DOWNGRADE] wx3.0-headers:amd64 3.0.4+dfsg-4 -> 3.0.3.1+dfsg2-1
[REMOVE] darkradiant:amd64 2.6.0-2
[REMOVE] darkradiant-plugins-darkmod:amd64 2.6.0-2
[REMOVE] libwxgtk3.0-gtk3-0v5:amd64 3.0.4+dfsg-4
[REMOVE] libwxgtk3.0-gtk3-0v5-dbgsym:amd64 3.0.4+dfsg-4
[REMOVE] libx11-6-dbgsym:amd64 2:1.6.5-1


Log complete.

Let me know if I can somehow help to triage this further.

--
tobi


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages slic3r depends on:
ii  libboost-filesystem1.62.0  1.62.0+dfsg-5.1
ii  libboost-geometry-utils-perl   0.15-2+b6
ii  libboost-system1.62.0  1.62.0+dfsg-5.1
ii  libboost-thread1.62.0  1.62.0+dfsg-5.1
ii  libc6  2.27-3
ii  libencode-locale-perl  1.05-1
ii  libexpat1  2.2.5-3
ii  libgcc11:8.1.0-5
ii  libio-stringy-perl 2.111-2
ii  libmath-convexhull-monotonechain-perl  0.1-1+b6
ii  libmath-geometry-voronoi-perl  1.3-3
ii  libmath-planepath-perl 126-1
ii  libmoo-perl2.003004-1
ii  libstdc++6 8.1.0-5
pn  libstorable-perl   
ii  perl [libtime-hires-perl]  5.26.2-5
ii  perl-base [perlapi-5.26.2] 5.26.2-5

Versions of packages slic3r recommends:
ii  libclass-xsaccessor-perl  1.19-2+b12
ii  libio-all-perl0.87-1
ii  libopengl-perl0.7000+dfsg-1
ii  libpdf-api2-perl  2.033-1
ii  libsvg-perl   2.84-1
ii  libwx-glcanvas-perl   0.09-5
ii  libwx-perl1:0.9932-4
ii  libxml-sax-expatxs-perl   1.33-2+b4

slic3r suggests no packages.

-- no debconf information
Starting program: /usr/bin/perl /usr/bin/slic3r
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe839e700 (LWP 19422)]
[New Thread 0x7fffe7b9d700 (LWP 19423)]
[New Thread 0x7fffe739c700 (LWP 19424)]

Thread 1 "perl" received signal SIGSEGV, Segmentation fault.
0x70858c49 in XQueryExtension (dpy=0x568d7900, name=0x7fffe43b7cc6 
"GLX", major_opcode=0x7fffe40730b4, 
first_event=0x7fffcdb4, first_error=0x7fffe40730b8) at 
../../src/QuExt.c:43
43  ../../src/QuExt.c: No such file or directory.
#0  0x70858c49 in XQueryExtension (dpy=0x568d7900, 
name=0x7fffe43b7cc6 "GLX", major_opcode=0x7fffe40730b4, 
first_event=0x7fffcdb4, first_error=0x7fffe40730b8) at ../../src/QuExt.c:43
#1  0x7fffe43b43b2 in  () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#2  0x7fffe43b0415 in glXQueryVersion () at 
/usr/lib/x86_64-linux-gnu

Bug#900678: slic3r: Segfaults at start since new wxwidgets.

[Tobias Frost]

Control: severity -1 serious
Control: retitle -1 wxwidgets3.0: wxGLCanvas doesn't work with Wayland
Control: reassign -1 wxwidgets3.0
Control: forwarded -1 https://trac.wxwidgets.org/ticket/17702
Control: affects -1 slic3r
Control: affects -1 slic3r-prusa

I've debugged into it and it seems that slic3r just crashes under
wayland. 

I think we're seeing https://trac.wxwidgets.org/ticket/17702
So I will reassign this bug to wxwidgets now...
As wayland is the default, I increase severity to serious.

Workaround for those who are affected as well:
GDK_BACKEND=x11 slic3r 

Slic3r-prusa seems to have the same problem, so setting that this bug
affects it too.

--
tobi

Bug#900678: slic3r: Segfaults at start since new wxwidgets.

[Olly Betts]

Control: severity -1 important

On Sat, Sep 29, 2018 at 06:16:05PM +0200, Tobias Frost wrote:
> I think we're seeing https://trac.wxwidgets.org/ticket/17702
> So I will reassign this bug to wxwidgets now...
> As wayland is the default, I increase severity to serious.

The definition of "serious" is:

| a severe violation of Debian policy (roughly, it violates a "must" or
| "required" directive), or, in the package maintainer's or release
| manager's opinion, makes the package unsuitable for release.

I can't think what in policy is violated here, and while the situation
is clearly far from ideal I don't think it makes wxwidgets3.0 unsuitable
for release.

This only affects applications using wxGLCanvas, and only those using
the gtk3 flavour of the library (currently we provide both gtk2 and gtk3
flavours built from the same source package, and gtk2 doesn't directly
support wayland).

If applications want to use the gtk3 flavour and wxGLCanvas they can
automate the workaround by setting "GDK_BACKEND=x11" early on (there are
some code snippets to do this in the upstream ticket), so my opinion
(as a maintainer of the package) is that "important" is a more
appropriate severity here, and I'm lowering the severity (unless a
release manager disagrees).

Fixing the underlying issue requires rewriting the OpenGL support
in the upstream wxWidgets code to not use X11 calls.  Until that
happens, if this remains RC then currently the least awful way we
have to fix this is probably to drop OpenGL support from the gtk3
flavour, and force reverse dependencies currently using the gtk3 flavour
and wxGLCanvas to move back to the gtk2 flavour.  Given there's a
reliable workaround that doesn't seem helpful.

If we could automate "GDK_BACKEND=x11" (or equivalent via the GDK
API) in wxwidgets that would be a neater way to address this until
the upstream code is updated to not require X11, but that seems to
be tricky to do because we don't know if wxGLCanvas will be used
or not at the point where we need to do this.  Forcing X11 for all
apps using the gtk3 flavour of wxwidgets3.0 seems a bad idea.

Cheers,
Olly