Version: unspecified (using KDE 4.6.2) OS: Linux Ardour won't start with oxygen-gtk (latest git, branches: Master v1.0.4): ubuntuku@satellite:~$ ardour2 Ardour 2.8.11 (built using 7387 and GCC version 4.5.1) Copyright (C) 1999-2008 Paul Davis Some portions Copyright (C) Steve Harris, Ari Johnson, Brett Viren, Joel Baker Ardour comes with ABSOLUTELY NO WARRANTY not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This is free software, and you are welcome to redistribute it under certain conditions; see the source for copying conditions. Segmentation fault It runs fine with other gtk style e.g qtcurve. Reproducible: Always
Created attachment 59665 [details] screenshot It starts fine here, although it is not using oxygen-gtk as a style (see screenshot). (using same version as yours: 2.8.11 Could you - post a screenshot about how it looks with e.g. QtCurve - explain to me how to configure it to actually use the requested gtk style (e.g. oxygen-gtk, so that I can reproduce the crash). - try compile oxygen-gtk in debug mode (see CMakeLists.txt as well as README), and post any additional output. Thx, Hugo
Created attachment 59670 [details] ardour2 output
Created attachment 59671 [details] oxygen-gtk compile in debug mode
Here's a screencast: http://youtu.be/fCCq0xRhEeM?hd=1.
Please attach stack trace of the crash (get it via gdb 'bt' command after the crash under gdb). Be sure to compile oxygen-gtk with debug info enabled (configure it via 'cmake .. -DCMAKE_CXX_FLAGS=-g')
Created attachment 59684 [details] ardour debug with backtrace Attached the information you requested. Thanks.
Does it still crash if you change ENABLE_INNER_SHADOWS_HACK to 0 in CMakeLists.txt?
Yes, it still crashes.
This commit aa454297b5a365123ff971640d6e670f0d5117d7 somehow has fixed the issue. Any comments guys? :)
Not surprising. Cause of crash was likely the same as for bug 274623. So, please close the bug since it's fixed.
As you wish, thanks!
Cool ! I love fixing bugs unintentionally !
Guys, I'm using Kubuntu Natty and qtcurve as a gtk style. I installed ardour and it segfaults. I tried switching gtk style but it won't start no matter what. Have you got any advices? $ ardour2 Ardour 2.8.11 (built using 7387 and GCC version 4.5.1) Copyright (C) 1999-2008 Paul Davis Some portions Copyright (C) Steve Harris, Ari Johnson, Brett Viren, Joel Baker Ardour comes with ABSOLUTELY NO WARRANTY not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This is free software, and you are welcome to redistribute it under certain conditions; see the source for copying conditions. theme_init() called from internal clearlooks engine /usr/share/themes/Clearlooks/gtk-2.0/gtkrc:76: error: unexpected identifier `colorize_scrollbar', expected character `}' theme_init() called from internal clearlooks engine /usr/share/themes/Clearlooks/gtk-2.0/gtkrc:76: error: unexpected identifier `colorize_scrollbar', expected character `}' sto caricando il file predefinito di configurazione ui /etc/ardour2/ardour2_ui_default.conf Loading ui configuration file /etc/ardour2/ardour2_ui_dark.rc theme_init() called from internal clearlooks engine ardour: [INFO]: Ardour will be limited to 4096 open files loading system configuration file /etc/ardour2/ardour_system.rc ardour: [INFO]: No H/W specific optimizations in use Segmentation fault
If it crashes with QtCurve, it's not our bug. Clearlooks mentioned in the log is also unrelated to oxygen-gtk. Report to your distro bug tracker.
The bug needs to be reopened, because it crashes again with latest 1.3.2 oxygen-gtk2 version.
(In reply to comment #15) > The bug needs to be reopened, because it crashes again with latest 1.3.2 > oxygen-gtk2 version. We need at least a backtrace for the crash and confirmation that it does not happen with other gtk styles.
... can reproduce, and not in 1.3.1 So Investigating.
Created attachment 76923 [details] Ardour 2 backtrace Ardour 2 backtrace
I've attached the backtrace, and i confirm that with previous (1.3.0) oxygen-gtk2 version it runs fine.
yeah. Its a complicated crash. It comes from e5aea805e471b8d52de54d88e0b40b7436d30bba moving initialization of oxygen::QtSettings to instance_init (where is should be), causes, for ardour only, some recursion call (to instance_init). This is due to the call gtk_settings_set_string_property( settings, "gtk-font-name", ... ) Which probably triggers the update of an already existing widget, which itself retriggers instance_init. Right now I have no clue how to prevent that ... still investigating. (in previous commits the initialization was done prior to instance_init, so that the problem was not happening).
Created attachment 76925 [details] fixes the crash (please test and confirm) This patch fixes it. But I am not happy with the solution, and besides, it is far from being robust. There are other calls to gtk_settings all over the place. Why only this one causes the recursion I don't know. Likely because ardour defines its own style independently from oxygen-gtk, but ...
I'm sorry, but i still get segfaults
backtrace must be different then (since the guilty #41 0xb72ba732 in gtk_settings_set_string_property () from /usr/lib/libgtk-x11-2.0.so.0 call has been removed). (if not, it means patch has not been installed properly) Can you post new backtrace ?
Created attachment 76927 [details] Backtrace after the patch did i applied the patch?
Comment on attachment 76927 [details] Backtrace after the patch ... seems you did not. The lines "#41 0xb72ba732 in gtk_settings_set_string_property () from /usr/lib/libgtk-x11-2.0.so.0 #42 0xb3dd5a7a in Oxygen::QtSettings::loadKdeFonts (this=0x8707930)" are in both backtrace. And in the patch, you'll see I commented out the guilty call to "gtk_settings_set_string_property" (inside the Oxygen::QtSettings::loadKdeFonts method). Well, so it seems from the backtrace at least ;) Thanks for helping though.
Created attachment 76929 [details] backtrace Sorry, it seems that the patch has been applied now
Comment on attachment 76929 [details] backtrace ... yes. and now you have a crash that I don't have. Ok I'll investigate further.
*** This bug has been marked as a duplicate of bug 314545 ***