Segmentation fault caused by an innocent commit #1018

Closed
eras opened this Issue Feb 24, 2013 · 27 comments

Comments

Projects
None yet
9 participants

eras commented Feb 24, 2013

Steps to reproduce (100% for me. I'm curious if anyone else can reproduce this, though):

  1. Use revision cac79c0 (the version before that has no problems). My ~/.Slic3r is at http://www.modeemi.fi/~flux/reprap/slic3r/bugs/config-home.zip

  2. In the GUI, add an STL (I used http://www.modeemi.fi/~flux/reprap/slic3r/bugs/pin.stl)

  3. Segmentation fault

The error message is:

slic3r.pl: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
pure virtual method called
terminate called without an active exception
zsh: abort (core dumped) ./slic3r.pl

Sometimes the part about pure virtual method or terminate don't come up.

My backtrace looks as follows:

Core was generated by `/usr/bin/perl ./slic3r.pl'.
Program terminated with signal 6, Aborted.
#0  0x00007f67e86a0475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007f67e86a0475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f67e86a36f0 in *__GI_abort () at abort.c:92
#2  0x00007f67e8699621 in *__GI___assert_fail (assertion=0x7f67e0dce238 "!xcb_xlib_threads_sequence_lost", file=<optimized out>, line=273, 
    function=0x7f67e0dce618 "poll_for_event") at assert.c:81
#3  0x00007f67e0d5c943 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007f67e0d5c961 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007f67e0d5d08d in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007f67e0d4e71d in XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007f67e37db296 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#8  0x00007f67e1f92178 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007f67e1f9280b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007f67e1f92d42 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007f67e3b70817 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#12 0x00007f67e45d7268 in wxEventLoop::Run() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#13 0x00007f67e464933c in wxAppBase::MainLoop() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#14 0x00007f67e4d77811 in wxPliApp::MainLoop (this=0x25a5050) at cpp/app.h:93
#15 0x00007f67e4d62182 in XS_Wx__App_MainLoop (my_perl=0x16af010, cv=<optimized out>) at Wx.c:14275
#16 0x00007f67e915263c in Perl_pp_entersub () from /usr/lib/libperl.so.5.14
#17 0x00007f67e9149c16 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#18 0x00007f67e90eb725 in perl_run () from /usr/lib/libperl.so.5.14
#19 0x0000000000400f89 in main ()

I run Debian unstable with the following relevant package versions:

ii  libwx-perl              1:0.9911-1       amd64            interface to wxWidgets cross-platform GUI toolkit
ii  libwx-perl-processstream-perl                     0.32-1                            all          Wx::Perl module to access IO of external processes via events
ii  libwxbase2.8-0:amd64                              2.8.12.1-12                       amd64        wxBase library (runtime) - non-GUI support classes of wxWidgets toolkit
ii  libwxgtk2.8-0:amd64                               2.8.12.1-12                       amd64        wxWidgets Cross-platform C++ GUI toolkit (GTK+ runtime)

eras commented Feb 24, 2013

I would imagine it's some kind of a race condition. If I revert that change on current master, I can still reproduce the problem, even though I was not able to do it before that change. I got a different error message this time, though, sadly I did not have core dumping enabled:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
perl: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
zsh: abort      ./slic3r.pl

I should also mention that I have Net::DBus disabled in my system:

% perl -MNet::DBus ''
Can't locate Net/DBus/Binding/Bus.pm in @INC (@INC contains: /home/flux/perl5/lib/perl5/x86_64-linux-gnu-thread-multi /home/flux/perl5/lib/perl5/x86_64-linux-gnu-thread-multi /home/flux/perl5/lib/perl5 /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/lib/perl5/Net/DBus.pm line 95.
BEGIN failed--compilation aborted at /usr/lib/perl5/Net/DBus.pm line 95.
Compilation failed in require.
BEGIN failed--compilation aborted.

eras commented Feb 24, 2013

And here's a gdb backtrace of all threads with a new error message:

(gdb) thread apply all catch throw
(gdb) run
Starting program: /usr/bin/perl ./slic3r.pl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe3797700 (LWP 5450)]
[New Thread 0x7fffe2f96700 (LWP 5451)]
[New Thread 0x7fffe1b97700 (LWP 5452)]
[New Thread 0x7fffe1396700 (LWP 5453)]
[New Thread 0x7fffe0b95700 (LWP 5454)]
[New Thread 0x7fffdbfff700 (LWP 5455)]
[New Thread 0x7fffdb7fe700 (LWP 5456)]
[New Thread 0x7fffdaffd700 (LWP 5457)]
[New Thread 0x7fffda7fc700 (LWP 5458)]
[New Thread 0x7fffd9ffb700 (LWP 5459)]
[Thread 0x7fffdbfff700 (LWP 5455) exited]
[Thread 0x7fffe3797700 (LWP 5450) exited]
[Thread 0x7fffe2f96700 (LWP 5451) exited]
[Thread 0x7fffe0b95700 (LWP 5454) exited]
[Thread 0x7fffe1b97700 (LWP 5452) exited]
[Thread 0x7fffe1396700 (LWP 5453) exited]
[Thread 0x7fffda7fc700 (LWP 5458) exited]
[Thread 0x7fffd9ffb700 (LWP 5459) exited]
[Thread 0x7fffdaffd700 (LWP 5457) exited]
[New Thread 0x7fffdaffd700 (LWP 5495)]
[New Thread 0x7fffd9ffb700 (LWP 5496)]
[New Thread 0x7fffda7fc700 (LWP 5497)]
[New Thread 0x7fffe1396700 (LWP 5498)]
[New Thread 0x7fffe3797700 (LWP 5499)]
[New Thread 0x7fffe2f96700 (LWP 5500)]
[New Thread 0x7fffe1b97700 (LWP 5501)]
[New Thread 0x7fffe0b95700 (LWP 5502)]
[New Thread 0x7fffdbfff700 (LWP 5503)]
[Thread 0x7fffd9ffb700 (LWP 5496) exited]
[Thread 0x7fffdbfff700 (LWP 5503) exited]
[Thread 0x7fffe3797700 (LWP 5499) exited]
[Thread 0x7fffdb7fe700 (LWP 5456) exited]
[Thread 0x7fffe1396700 (LWP 5498) exited]
[Thread 0x7fffe2f96700 (LWP 5500) exited]
[Thread 0x7fffda7fc700 (LWP 5497) exited]
[Thread 0x7fffdaffd700 (LWP 5495) exited]
[Thread 0x7fffe1b97700 (LWP 5501) exited]
[New Thread 0x7fffe1b97700 (LWP 5542)]
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
perl: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff7062475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7062475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff70656f0 in *__GI_abort () at abort.c:92
#2  0x00007ffff705b621 in *__GI___assert_fail (assertion=0x7fffef790238 "!xcb_xlib_threads_sequence_lost", 
    file=<optimized out>, line=273, function=0x7fffef790618 "poll_for_event") at assert.c:81
#3  0x00007fffef71e943 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007fffef71e961 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007fffef71f08d in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007fffef71071d in XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007ffff219d296 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#8  0x00007ffff0954178 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff095480b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff0954d42 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff2532817 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#12 0x00007ffff2f99268 in wxEventLoop::Run() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#13 0x00007ffff300b33c in wxAppBase::MainLoop() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#14 0x00007ffff3739811 in wxPliApp::MainLoop (this=0x1507520) at cpp/app.h:93
#15 0x00007ffff3724182 in XS_Wx__App_MainLoop (my_perl=0x603010, cv=<optimized out>) at Wx.c:14275
#16 0x00007ffff7b1463c in Perl_pp_entersub () from /usr/lib/libperl.so.5.14
#17 0x00007ffff7b0bc16 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#18 0x00007ffff7aad725 in perl_run () from /usr/lib/libperl.so.5.14
#19 0x0000000000400f89 in main ()
(gdb) thread apply all bt

Thread 21 (Thread 0x7fffe1b97700 (LWP 5542)):
#0  __lll_unlock_wake () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:373
#1  0x00007ffff73c4704 in _L_unlock_532 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007ffff73c4634 in __pthread_mutex_unlock_usercnt (mutex=0x1529c98, decr=<optimized out>)
    at pthread_mutex_unlock.c:52
#3  0x00007fffecea687d in xcb_writev () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4  0x00007fffef71ed47 in _XSend () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007fffef71f27b in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007fffef703f99 in XGetGeometry () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007ffff21af875 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#8  0x00007ffff2185ac4 in gdk_window_get_geometry () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#9  0x00007ffff217e386 in gdk_screen_get_monitor_at_window () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#10 0x00007ffff265c053 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#11 0x00007ffff265e58b in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#12 0x00007ffff0e17cb7 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x00007ffff0e306b6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x00007ffff0e30f02 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x00007ffff2654c16 in gtk_widget_show () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#16 0x00007ffff24baca5 in gtk_dialog_run () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#17 0x00007ffff2ff70ca in wxMessageDialog::ShowModal() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#18 0x00007ffff37c6071 in XS_Wx__MessageDialog_ShowModal (my_perl=0x27053c0, cv=<optimized out>) at Frames.c:8676
#19 0x00007ffff7b1463c in Perl_pp_entersub () from /usr/lib/libperl.so.5.14
#20 0x00007ffff7b0bc16 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#21 0x00007ffff7b4445c in ?? () from /usr/lib/libperl.so.5.14
#22 0x00007ffff7b513df in Perl_pp_entereval () from /usr/lib/libperl.so.5.14
#23 0x00007ffff7b0bc16 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#24 0x00007ffff7aa75c9 in Perl_call_sv () from /usr/lib/libperl.so.5.14
#25 0x00007ffff7aedc18 in ?? () from /usr/lib/libperl.so.5.14
#26 0x00007ffff7aefa49 in Perl_vwarn () from /usr/lib/libperl.so.5.14
#27 0x00007ffff7aefd42 in Perl_warner () from /usr/lib/libperl.so.5.14
#28 0x00007ffff7acea50 in Perl_cv_undef () from /usr/lib/libperl.so.5.14
#29 0x00007ffff7b1ae5b in Perl_sv_clear () from /usr/lib/libperl.so.5.14
#30 0x00007ffff7b1b1c2 in Perl_sv_free2 () from /usr/lib/libperl.so.5.14
#31 0x00007ffff7b409b0 in Perl_free_tmps () from /usr/lib/libperl.so.5.14
#32 0x00007ffff7aa7a48 in Perl_call_sv () from /usr/lib/libperl.so.5.14
#33 0x00007ffff64da779 in ?? () from /usr/lib/perl/5.14/auto/threads/threads.so
#34 0x00007ffff73c0b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#35 0x00007ffff710aa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#36 0x0000000000000000 in ?? ()

Thread 19 (Thread 0x7fffe0b95700 (LWP 5502)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
#1  0x00007ffff0991c35 in g_cond_wait_until () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff092b2c1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff092b90a in g_async_queue_timeout_pop () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007ffff09788e2 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff0978105 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x00007ffff73c0b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#7  0x00007ffff710aa7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#8  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7fbb700 (LWP 5439)):
#0  0x00007ffff7062475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff70656f0 in *__GI_abort () at abort.c:92
#2  0x00007ffff705b621 in *__GI___assert_fail (assertion=0x7fffef790238 "!xcb_xlib_threads_sequence_lost", 
    file=<optimized out>, line=273, function=0x7fffef790618 "poll_for_event") at assert.c:81
#3  0x00007fffef71e943 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007fffef71e961 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007fffef71f08d in _XEventsQueued () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007fffef71071d in XPending () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007ffff219d296 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#8  0x00007ffff0954178 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff095480b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff0954d42 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff2532817 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#12 0x00007ffff2f99268 in wxEventLoop::Run() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#13 0x00007ffff300b33c in wxAppBase::MainLoop() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#14 0x00007ffff3739811 in wxPliApp::MainLoop (this=0x1507520) at cpp/app.h:93
#15 0x00007ffff3724182 in XS_Wx__App_MainLoop (my_perl=0x603010, cv=<optimized out>) at Wx.c:14275
#16 0x00007ffff7b1463c in Perl_pp_entersub () from /usr/lib/libperl.so.5.14
#17 0x00007ffff7b0bc16 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#18 0x00007ffff7aad725 in perl_run () from /usr/lib/libperl.so.5.14
#19 0x0000000000400f89 in main ()
(gdb) 

eras commented Feb 25, 2013

It appears that WxWidgets, its GTK front nor the perl bindings never call XInitThreads, so that may be the problem here. While it is unclear to me if Slic3r properly calls use threads; use threads::sharered; before use Wx, it didn't seem to help when I ensured that that happens. I'm yet to try injecting an XInitThreads call.

Owner

alexrj commented Feb 27, 2013

Uhm, it looks like threads::shared wasn't loaded before Wx. I just committed that change. Can you test? Thank you btw.

eras commented Feb 27, 2013

I'll try it earliest in the evening, thanks for the fix :).

Though, I'm doubtful it'll solve the problem (unless my try at injecting use threads::shared; failed), but these seem very relevant:

http://vtp.googlecode.com/svn/trunk/TerrainApps/wxSimple/app.cpp (search for XInitThreads)

http://forums.wxwidgets.org/viewtopic.php?f=23&t=32346

I'm don't know how to add a call to XInitThreads from a perl application, though.

eras commented Feb 27, 2013

Sadly the problem did not go away. but I took a new stab at it and the problem changed a bit. I used the following piece of code to inject XInitThreads call to Slic3r (watch out for the absolute path to libX11 in the source):

/* usage:
   gcc -shared -fPIC -o wrapXInitThreads.so wrapXInitThreads.c
   LD_PRELOAD=$PWD/wrapXInitThreads.so ./slic3r.pl
*/

#include <X11/Xlib.h>
#include <dlfcn.h>
#include <assert.h>

typedef Display* (*XOpenDisplayType)(_Xconst char *displayName);

XOpenDisplayType getFn(void)
{
  static XOpenDisplayType real = NULL;
  if (!real) {
    void* handle = dlopen("/usr/lib/x86_64-linux-gnu/libX11.so", RTLD_NOW | RTLD_GLOBAL);
    real = dlsym(handle, "XOpenDisplay");
    assert(real);
    puts("WrapXInitThreads");
    XInitThreads();
  }
  return real;
}

Display* XOpenDisplay(_Xconst char* displayName)
{
  return getFn()(displayName);
}

Once compiled I executed Slic3r (as in the comment), added pin.stl, and got the following error message before crashing:

Attempt to free unreferenced scalar: SV 0x30a9130, Perl interpreter: 0x2c1a7b0 at /usr/lib/perl/5.14/threads.pm line 101.

Maybe this hints to some other problem? After closing the dialog, a segmentation fault occurs:

% gdb =perl core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/perl...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 26294]
[New LWP 26400]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/perl ./slic3r.pl'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fc70179ba20 in gdk_window_set_geometry_hints () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
(gdb) thread apply all bt

Thread 2 (Thread 0x7fc6eb7fe700 (LWP 26400)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007fc6fed092e6 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2  0x00007fc6fed06717 in XTranslateCoordinates () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3  0x00007fc70179886f in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#4  0x00007fc70176fbdf in gdk_window_get_origin () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#5  0x00007fc701c46076 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#6  0x00007fc701c4858b in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#7  0x00007fc700401cb7 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x00007fc70041a6b6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x00007fc70041af02 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007fc701c3ec16 in gtk_widget_show () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#11 0x00007fc701aa4ca5 in gtk_dialog_run () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#12 0x00007fc7025e10ca in wxMessageDialog::ShowModal() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#13 0x00007fc702db0071 in XS_Wx__MessageDialog_ShowModal (my_perl=0x2c1a7b0, cv=<optimized out>) at Frames.c:8676
#14 0x00007fc706efa63c in Perl_pp_entersub () from /usr/lib/libperl.so.5.14
#15 0x00007fc706ef1c16 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#16 0x00007fc706e8d5c9 in Perl_call_sv () from /usr/lib/libperl.so.5.14
#17 0x00007fc706ed3c18 in ?? () from /usr/lib/libperl.so.5.14
#18 0x00007fc706ed5a49 in Perl_vwarn () from /usr/lib/libperl.so.5.14
#19 0x00007fc706ed5d42 in Perl_warner () from /usr/lib/libperl.so.5.14
#20 0x00007fc706f269a0 in Perl_free_tmps () from /usr/lib/libperl.so.5.14
#21 0x00007fc706e8da48 in Perl_call_sv () from /usr/lib/libperl.so.5.14
#22 0x00007fc7058c0779 in ?? () from /usr/lib/perl/5.14/auto/threads/threads.so
#23 0x00007fc7067a6b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#24 0x00007fc7064f0a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#25 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7fc7075a1700 (LWP 26294)):
#0  0x00007fc70179ba20 in gdk_window_set_geometry_hints () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#1  0x00007fc701c4673e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#2  0x00007fc700401cb7 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3  0x00007fc70041a6b6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x00007fc70041af02 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x00007fc701aa1a20 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#6  0x00007fc70174c357 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#7  0x00007fc6fff3e615 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x00007fc6fff3e948 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007fc6fff3ed42 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007fc701b1c817 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#11 0x00007fc702583268 in wxEventLoop::Run() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#12 0x00007fc7025f533c in wxAppBase::MainLoop() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#13 0x00007fc702d23811 in wxPliApp::MainLoop (this=0x19d12f0) at cpp/app.h:93
#14 0x00007fc702d0e182 in XS_Wx__App_MainLoop (my_perl=0xb2c010, cv=<optimized out>) at Wx.c:14275
#15 0x00007fc706efa63c in Perl_pp_entersub () from /usr/lib/libperl.so.5.14
#16 0x00007fc706ef1c16 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#17 0x00007fc706e93725 in perl_run () from /usr/lib/libperl.so.5.14
#18 0x0000000000400f89 in main ()
(gdb) 

That's all for now.. My best guess is that it is a concurrency problem in any of the three components: Wx, WxPerl, or Slic3r :/.

Collaborator

mesheldrake commented Feb 28, 2013

Since the problem started with a commit that has to do with a new config option, it might be good to have the exact config you are using when you can produce the crash 100% of the time. Use Slic3r's config export option (File->Export Config...) and post that single config file.

eras commented Feb 28, 2013

Here you are: http://www.modeemi.fi/~flux/reprap/slic3r/bugs/issue1018.ini

Although my theory is that just that proper amount of code at some critical path just pushed the race condition visible in my system. I've tried reverting that particular config, and yet later versions seem to exhibit the same behavior. (But they could of course trigger similar code paths as that particular change.)

Collaborator

mesheldrake commented Feb 28, 2013

Thanks for the config.
I could not reproduce this with the procedure described (including disabling Net::DBus) on Ubuntu 12.10 64bit.

One more thought: wxMessageDialog::ShowModal() seems to be involved, which would be used for an error report window, which the "innocent commit" might be capable of triggering. It looks like ShowModal() is also used for the About box. By any chance does Help->About Slic3r trigger the same crash? (Just a wild guess - but easy enough to check.)

eras commented Feb 28, 2013

The about dialog seems to work fine.

Is there some progress bar being shown when models are being loaded? If so, I think that would result in concurrent access to the Xlib.

An alternate idea is the effect of drawing the plate view while loading the STLs. Are they being drawn concurrently or after everything is complete, from the main event loop? That could be another explanation.

OhmEye commented Mar 3, 2013

FYI, I also have this issue starting with the same commit. I just finished running it down with a bisect and found this issue as I was about to open one.

Collaborator

mesheldrake commented Mar 4, 2013

@OhmEye - what OS? @eras mentioned he was running Debian unstable.You too?

OhmEye commented Mar 4, 2013

Opensuse 11.4 64 bit

Contributor

fehknt commented Mar 9, 2013

I loaded up a huge 4mb STL file and can support that it crashes when it tries to draw the bounding box on the plater, well after it is finished loading the file (and that progress bar has gone away). Then it waits for a bit thinking, then it comes back and very shortly after but before the object appears on the plater, it dies.
(Ubuntu 12.10 x64)

zelogik commented Mar 9, 2013

I have exactly the same problem,

slic3r.pl: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.
[1] 2010 segmentation fault (core dumped) /opt/Slic3r/slic3r.pl

Debian unstable/experimental, and I don't know if it's an update of Slic3r-git or a change with sysv to systemd ... because 1day ago Slic3r work without any problem.

zelogik commented Mar 9, 2013

I have remove my config file, and now it's work without problem only the first time.

Save "print Settings" "Filament Settings" and "Printer Settings", with any config name, stop Slic3r, restart it, and when I try to reload any .stl it's crash when it's try to draw.

Same problem here... If I add the stl file with default profiles selected and afterwards changing the profile to my modified ones it works most of the time and i'm able to export gcode without a problem. With previously choosing default profiles it crashes 1:10. With my profiles it crashes every time.

Another error message when opening stl files with modified profiles:
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
perl: ../../src/xcb_io.c:178: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
slic3r.pl: Fatal IO error 0 (Success) on X server :0.0.
Aborted (core dumped)

and this one (here i changed the extrusion multiplier to 1.25 for testing):
Done. Process took 0 minutes and 1.134 seconds
Filament required: 151.3mm (1.1cm3)
process 3135: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.
Most likely, the application called unref() too many times and removed a reference belonging to libdbus, since this is a shared connection.
Done. Process took 0 minutes and 1.305 seconds
Filament required: 147.0mm (1.0cm3)
Attempt to free unreferenced scalar: SV 0xae2780dc, Perl interpreter: 0xaf171af8 at /opt/Slic3r/lib/Slic3r.pm line 83.

Additional note: starting up slic3r with default profiles chosen --> no crash. changing to user profiles an adding a stl file --> no crash. Closing slic3r after this and fireing slic3r up again (this time with user profiles preselected) and adding a stl file --> crash...

So over all: Starting slic3r with user profiles instead of default profiles makes slic3r crash wehn adding a stl.

Is there a possibility for me to give u more informations? Logfiles or something to check for?

eras commented Mar 12, 2013

It seems the problem has been solved by commit b901e1f "Merge branch 'master' into simple-mode" (which I assume was then merged back to master). With that version (or the master) I can no longer reproduce the issue. Hooray, finally back to using all new Slic3r goodness!

OhmEye commented Mar 12, 2013

Confirming that I haven't reproduced the issue with the current master.

Seems to work now :D

Had to rm the slic3r folder and git clone again, 'git remote update' was not enough. offtopic question: Whats the difference?

Owner

alexrj commented Mar 12, 2013

@linuxlurak, you need "git pull" to update your working copy with the latest changes.

Okay, so I think we can close this one which was mysteriously fixed.

alexrj closed this Mar 12, 2013

LC_ALL=C slic3r.pl
Fixes this issue for me ( I just wanted to copy error message in English… )

bgamari commented Jun 25, 2013

Sadly I can still reproduce this in Slic3r 1f50d9c7e8830fon Ubuntu 13.04. Slic3r crashes shortly after clicking "Export G-code", producing the following on stderr,

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
perl: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

The backtrace isn't entirely reproducible. Here's one example,

#0  0x00007ffff76d6037 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff76d9698 in __GI_abort () at abort.c:90
#2  0x00007ffff76cee03 in __assert_fail_base (
    fmt=0x7ffff7825578 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion@entry=0x7ffff0783bd8 "!xcb_xlib_threads_sequence_lost", file=file@entry=0x7ffff0783e92 "../../src/xcb_io.c", line=line@entry=274, 
    function=function@entry=0x7ffff0783fb8 "poll_for_event") at assert.c:92
#3  0x00007ffff76ceeb2 in __GI___assert_fail (
    assertion=0x7ffff0783bd8 "!xcb_xlib_threads_sequence_lost", 
    file=0x7ffff0783e92 "../../src/xcb_io.c", line=274, 
    function=0x7ffff0783fb8 "poll_for_event") at assert.c:101
#4  0x00007ffff0712ae9 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007ffff0712b01 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007ffff071306d in _XEventsQueued ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007ffff07046bd in XPending ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007ffff1eb8983 in gdk_check_xpending (display=<optimized out>)
    at /build/buildd/gtk+2.0-2.24.17/gdk/x11/gdkevents-x11.c:159
#9  gdk_event_check (source=0x15bbfc0)
    at /build/buildd/gtk+2.0-2.24.17/gdk/x11/gdkevents-x11.c:2378
#10 0x00007ffff173cc69 in g_main_context_check ()
---Type <return> to continue, or q <return> to quit---
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff173d175 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff173d6ba in g_main_loop_run ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff2244fe7 in IA__gtk_main ()
    at /build/buildd/gtk+2.0-2.24.17/gtk/gtkmain.c:1271
#14 0x00007ffff2c87f78 in wxEventLoop::Run() ()
   from /usr/local/lib/perl/5.14.2/Alien/wxWidgets/gtk_2_8_12_uni/lib/libwx_gtk2u_core-2.8.so.0
#15 0x00007ffff2cf510b in wxAppBase::MainLoop() ()
   from /usr/local/lib/perl/5.14.2/Alien/wxWidgets/gtk_2_8_12_uni/lib/libwx_gtk2u_core-2.8.so.0
#16 0x00007ffff34659a1 in wxPliApp::MainLoop (this=0x158af10) at cpp/app.h:93
#17 0x00007ffff34505d2 in XS_Wx__App_MainLoop (my_perl=0x603010, 
    cv=<optimized out>) at Wx.c:14275
#18 0x00007ffff7b13fac in Perl_pp_entersub () from /usr/lib/libperl.so.5.14
#19 0x00007ffff7b0b526 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#20 0x00007ffff7aad7d5 in perl_run () from /usr/lib/libperl.so.5.14
#21 0x0000000000400e49 in main ()
(gdb) info threads
  Id   Target Id         Frame 
  11   Thread 0x7fffd3684700 (LWP 10584) "perl" 0x00007ffff1e9ccc9 in IA__gdk_window_is_viewable (window=0x2729480)
    at /build/buildd/gtk+2.0-2.24.17/gdk/gdkwindow.c:2705
  5    Thread 0x7fffd3e85700 (LWP 10557) "gmain" 0x00007ffff778c3cd in poll ()
    at ../sysdeps/unix/syscall-template.S:81
  4    Thread 0x7fffe1c46700 (LWP 10548) "pool" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  3    Thread 0x7fffe9132700 (LWP 10541) "gdbus" 0x00007ffff778c3cd in poll ()
    at ../sysdeps/unix/syscall-template.S:81
  2    Thread 0x7fffe9933700 (LWP 10540) "dconf worker" 0x00007ffff778c3cd in poll () at ../sysdeps/unix/syscall-template.S:81
* 1    Thread 0x7ffff7fc3740 (LWP 10536) "perl" 0x00007ffff76d6037 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56

Setting a breakpoint on XInitThreads suggests that this was never called during the process's life.

bgamari commented Jun 25, 2013

After trying the LD_PRELOAD trick provided by @eras, it seems that the crash occurs when Slic3r attempts to show a dialog during the slicing process (warning me of non-manifold-ness). When XInitThreads is injected with the LD_PRELOAD trick the crash is gone. This seems to confirm that threading is not properly initialized by any of the involved libraries.

bgamari commented Jun 25, 2013

I've tried adding use threads; use threads::shared; at the beginning of slic3r.pl before Wx is loaded, thinking that it only checks to enable threading support on first load. Sadly this didn't seem to make a difference. Unfortunately grepping through the wxPerl source turns up very few explicit references regarding threading support. Those that do appear suggest that the measures currently being taken are sufficient. That being said, it seems quite clear that XInitThreads is never called.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment