CodeLite causes system freeze?

[caibbor]

Every once in a while, sometimes several times a day, I will end a debug session in CodeLite (nothing fancy ever done other than breakpoints) and CodeLite (or one of it's dependencies) will hang up my whole linux system. I am unable to do anything except drop to a virtual terminal to execute commands. From there, using 'top' I can see that Xorg is using 100% CPU. I used to just kill Xorg afterward which would get me back to work again, but now I just do a full reboot (very fast boot time).

At least the last time it happened, after the debug session ended, codelite didn't fully go back into normal mode again, but it looked like some of the UI was in the middle of changing back.

I've been wondering how to report this, since a total-lockup is presumable unlikely to generate a report. What do you recommend? It's possible that this is a X.org or dependency bug or possibly some distribution-specific thing.

I'm on XUbuntu, this bug has happened all the way from CodeLite 10 to the current state in git (11.0.5 I believe).

I am also using stock codelite configuration under ~/.CodeLite other than a few preference tweaks such as key combos and colors and whatnot.

Code: Select all

root@antic-Inspiron-7559:/home/antic# uname -a
Linux antic-Inspiron-7559 4.9.11-040911-generic #201702181031 SMP Sat Feb 18 15:33:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
root@antic-Inspiron-7559:/home/antic# cat /etc/issue
Ubuntu 16.04.3 LTS \n \l

root@antic-Inspiron-7559:/home/antic# gdb -v
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 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".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
root@antic-Inspiron-7559:/home/antic# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.2.0-1ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~16.04) 
root@antic-Inspiron-7559:/home/antic# codelite -v
09:30:51: Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx containers,compatible with 2.8).
CodeLite IDE v11.0.5

[eranif]

Did you try to figure out what these error means:

Code: Select all

09:30:51: Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx containers,compatible with 2.8).

Looks like that the wxWidgets libraries that were present during link time are not the ones that are actually being loaded by CodeLite during runtime

[caibbor]

I don't think that's relevant because I don't get that error with other versions of codelite while still experiencing the freeze-up.

I only get that warning after 'make install' with the latest git I've been experiencing these crashes since CodeLite 10, which I install with normal Ubuntu packages. either way, warning or no, I get the same sort of freeze. *shrug*

[eranif]

I never experienced this, on the other hand, I am not using ArchLinux...
I would still investigate these error messages, it defnitly means that the runtime libraries are not aligned with the one loaded during build time.
And since CodeLite itself does not "talk" to x-server (it does that through wxWidgets->GTK) it might be related

[DavidGH]

Hi,

I used to just kill Xorg afterward which would get me back to work again, but now I just do a full reboot (very fast boot time).

Have you tried killing CodeLite instead? 'pkill codelite' should work; and it's an interesting data-point if it doesn't.

Which wxWidgets version(s) are installed on your system? If you have both 2.8 and 3, and other programs depend on 2.8 so you can't easily uninstall it, the easiest way to ensure that CodeLite uses the correct libs at runtime is to configure CodeLite with -DCOPY_WX_LIBS=1. That way the wx3 runtime libs are installed inside /usr/lib/codelite/ and the CodeLite instance knows to link to them.

Have you tried running CodeLite inside gdb? You'll probably still get the freezes, but the gdb terminal might contain useful error messages after you kill CodeLite from the virtual terminal.

Regards,

David

[DavidGH]

Have you tried running CodeLite inside gdb? You'll probably still get the freezes, but the gdb terminal might contain useful error messages after you kill CodeLite from the virtual terminal

Thinking harder, a better way would be to wait for a freeze, then start gdb in the virtual terminal and attach to CodeLite. That way you can not only get a backtrace, but also see if Xorg returns to normal when the CodeLite instance is paused.

[caibbor]

Killing codelite would sometimes result in the system unfreezing, however many times killing codelite would still leave X.Org completely hung up. So that's why I started killing X.Org, and most recently just doing a reboot.

I will find out what wxWidgets I'm running shortly.
I am going to revert to try to get CodeLite to run without producing that error (with -DCOPY_WX_LIBS=1).
I'll try attaching gdb to codelite next time it freezes.
I will report back here when I have more information.

[caibbor]

Codelite Froze today (or one of it's dependencies). I attached GDB to it in a virtual terminal and did a backtrace. then I quite GDB and did the same for Xorg.

I don't know whether quitting GDB while attached to CodeLite caused codelite to exit, so I'm not sure if the Xorg backtrace is a correct portrait of the situation. I immediately (and foolishly) attempted to switch back to X.Org while GDB was still attached to it, resulting in a total lockup and had to hit the power switch. Hah.

CodeLite Backtrace:
https://www.dropbox.com/s/5xeierguhguuk ... 5.jpg?dl=0

XOrg Backtrace:
https://www.dropbox.com/s/q68zi97ks76s0 ... 9.jpg?dl=0

Also, here's this:

Code: Select all

antic@antic-Inspiron-7559:~$ dpkg -l | grep -i wxwidg
ii  libwxbase2.8-0:amd64                          2.8.12.1+dfsg2-2ubuntu2+1~webupd8~xenial0                amd64        wxBase library (runtime) - non-GUI support classes of wxWidgets toolkit
ii  libwxbase3.0-0v5:amd64                        3.0.2+dfsg-1.3ubuntu0.1                                  amd64        wxBase library (runtime) - non-GUI support classes of wxWidgets toolkit
ii  libwxbase3.0-dev                              3.0.2+dfsg-1.3ubuntu0.1                                  amd64        wxBase library (development) - non-GUI support classes of wxWidgets toolkit
ii  libwxgtk2.8-0:amd64                           2.8.12.1+dfsg2-2ubuntu2+1~webupd8~xenial0                amd64        wxWidgets Cross-platform C++ GUI toolkit (GTK+ runtime)
ii  libwxgtk3.0-0v5:amd64                         3.0.2+dfsg-1.3ubuntu0.1                                  amd64        wxWidgets Cross-platform C++ GUI toolkit (GTK+ runtime)
ii  libwxgtk3.0-dev                               3.0.2+dfsg-1.3ubuntu0.1                                  amd64        wxWidgets Cross-platform C++ GUI toolkit (GTK+ development)
ii  python-wxgtk3.0                               3.0.2.0+dfsg-1build1                                     amd64        Python interface to the wxWidgets Cross-platform C++ GUI toolkit
ii  wx-common                                     3.0.2+dfsg-1.3ubuntu0.1                                  amd64        wxWidgets Cross-platform C++ GUI toolkit (common support files)
ii  wx3.0-headers                                 3.0.2+dfsg-1.3ubuntu0.1                                  amd64        wxWidgets Cross-platform C++ GUI toolkit (header files)

[DavidGH]

So you have both wx2.8.12 and wx3.0.2 installed. You could do
ldd ${/path/to}/codelite
to check if a particular codelite binary is wrongly linking, or check that building with -DCOPY_WX_LIBS=1 has worked.

Unfortunately the gdb backtrace was unhelpful; it just showed the wx event-loop. In case it's a different CodeLite thread that's misbehaving it might be worth trying again, doing:
thread apply all bt
instead of just bt. And it might also be worth doing several iterations of:
Ctrl-C
bt
continue
just in case it shows something different.

I don't know anything about what Xorg backtraces should look like.

Have you tried a -DCOPY_WX_LIBS=1 build yet? If so, and it's no better, it might be worth building (or installing) wx3.1.0 in case that helps.

[caibbor]

I'm very pressed for time, so what I'm going to do is roll back to CodeLite 10 from Ubuntu's repos, which also has the freeze issue as mentioned but does not have the wxWidgets warning. Then the next time it freezes I'll try to get the best backtrace I can, as you've instructed.

I'll report back once I have more information