Created attachment 84561 [details]
JRE Log file

Created attachment 84562 [details]
exploratory patch

... can't reproduce.
Still, in order to try investigate, 
can you apply the patch above to oxygen-gtk2 and tell me if code is still crashing ? 
Thanks 

Hugo

Also, without the patch applied, could you try

- disable all widget animations (using oxygen-settings for instance, second tab of the style configuration)

- see if the crash still happens

- if not, re-enable animations one by one, untill the crash re-occurs

and report back ? 

Thanks in advance,

Hugo

I'm not sure if I'll have time to try the patch today, but even with the "Enable animations" box unchecked, the crash occurs. I doubt it makes any difference but I also unchecked the "Busy indicator steps" checkbox on that tab just in case.

However, I don't notice any visual difference (although I don't know what to look for either) with the box checked or unchecked. Do I need to restart anything after modifying the configuration in oxygen-settings?

I managed to test the patch, it didn't help. Same crash at the same point.

Probably unhelpful but in the interest of trial-and-error I also forced gtk_widget_style_is_modified to return true, same crash.

P.s. what do I need to do to force liboxygen-gtk.so to reload after it's been updated? I've been logging off and on which seems to achieve it while restarting the GTK app does not, but is there a simpler way?

Hi Tom,
1/ thanks for helping
2/ normally, only restarting the application should be enough to use the recompiled style
3/ when you applied the patch, was the crash exactly the same as before (notably with the same 
# Problematic frame:
# C  [libgobject-2.0.so.0+0x19528]  g_object_get_qdata+0x18
Or was it different ? 
4/ it is expected that applying the patch changes pretty much nothing to the visual appearance, since this code is meant to handle some special cases only
5/ When you turn off animations, well, animations should be gone :)
This includes notably, "smooth" (as opposed to instantaneous) glow on buttons, "smooth" displacement/fading of the highlighted rectangle when entering a menubar/toolbar or menu, as well as moving the mouse over it.
This kind of things.

Also, if you have time you can give a shot at the last part of comment #10 of https://bugs.kde.org/show_bug.cgi?id=329445

Thanks in advance,

Hugo

1) No worries, thanks for trying to fix it! Sorry for the delay in getting back, unfortunately real life!
2) My rudimentary test seemed to indicate otherwise: Replace liboxygen-gtk.so with the known broken one that suffered from https://bugs.kde.org/show_bug.cgi?id=324438 , see if I can add a remote location successfully - yes. Log out and log in again - try adding remote location - crashes as expected. Put back latest liboxygen-gtk.so, add remote location = crash. Log out and back in, try again and it works. It indicates liboxygen-gtk.so is only being reloaded on logout. It's a bit of a pain while testing but at least if I do I can be sure it's using the latest version.

3) Yes:

Stack: [0x00007f1392494000,0x00007f1392595000],  sp=0x00007f1392591d60,  free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libgobject-2.0.so.0+0x19528]  g_object_get_qdata+0x18

Full log file attached.

I will attempt the other fix now and report back.

Created attachment 84656 [details]
Log file (Zend) after applying exploratory patch

Not good news: The patch definitely applied successfully as the find dialog is no longer styled like oxygen (it has the GTK theme colours, but all buttons are square)

My classInit method looks like this:


  void StyleWrapper::classInit( OxygenStyleClass* klass )
    {

        #if OXYGEN_DEBUG
        std::cerr << "Oxygen::StyleWrapper::classInit" << std::endl;
        #endif

        GtkStyleClass* style_class( GTK_STYLE_CLASS( klass ) );

        _parentClass = static_cast<GtkStyleClass*>( g_type_class_peek_parent( klass ) );
/*
        style_class->draw_hline = draw_hline;
        style_class->draw_vline = draw_vline;
        style_class->draw_shadow = draw_shadow;
        style_class->draw_arrow = draw_arrow;

        style_class->draw_diamond = draw_diamond;

        style_class->draw_box = draw_box;
        style_class->draw_flat_box = draw_flat_box;
        style_class->draw_check = draw_check;
        style_class->draw_option = draw_option;
        style_class->draw_tab = draw_tab;
        style_class->draw_shadow_gap = draw_shadow_gap;
        style_class->draw_box_gap = draw_box_gap;
        style_class->draw_extension = draw_extension;
        style_class->draw_focus = draw_focus;
        style_class->draw_slider = draw_slider;
        style_class->draw_handle = draw_handle;
        style_class->draw_resize_grip = draw_resize_grip;
        style_class->draw_expander = draw_expander;

        // icon rendering
        style_class->render_icon = render_icon;

        // text rendering
        style_class->draw_layout = draw_layout;
*/
    }



Log file to follow but the crash is still at the same place:



Stack: [0x00007f3b43edc000,0x00007f3b43fdd000],  sp=0x00007f3b43fd9d20,  free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libgobject-2.0.so.0+0x19528]  g_object_get_qdata+0x18

Created attachment 84657 [details]
Log file after applying classInit change

I don't know much about the internals of KDE so I'm really just clutching at straws but QtCurve also suffers from this bug like oxygen-gtk. Does oxygen-gtk use anything from QtCurve?

Sorry for multiple comments but this may be useful:

https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/598371 

"It looks that is the bug in the GTK or Eclipse SWT library.
During window close process method org.eclipse.widgets.Display.removeWidget() calls native method org.eclipse.swt.internal.gtk.OS._g_object_get_qdata() which causes segmentation fault (it not cause Java exception due we are in native code).
Display.removeWidget() source code:
Widget removeWidget (long /*int*/ handle) {
 if (handle == 0) return null;
 lastWidget = null;
 Widget widget = null;
 int index = (int)/*64*/ OS.g_object_get_qdata (handle, SWT_OBJECT_INDEX) - 1;
 if (0 <= index && index < widgetTable.length) {
  widget = widgetTable [index];
  widgetTable [index] = null;
  indexTable [index] = freeSlot;
  freeSlot = index;
  OS.g_object_set_qdata (handle, SWT_OBJECT_INDEX, 0);
 }
 return widget;
}"

However, if it's a bug in glib or eclipse why doesn't it happen with other GTK themes? Oxygen and QtCurve must be doing something different to the other themes which triggers it?

More info, not sure this is helpful but if I

1) Open Eclipse (or zend)
2) Change the GTK2 theme to Raleigh
3) Change the GTK2 theme back to Oxygen

I can open and close the find dialog between 3 and 5 times (it's not consistent).

*** This bug has been confirmed by popular vote. ***

Could be of some help: TuxGuitar 1.2 also affected by similar bug (crashes when buttons pressed in settings dialog).
Kubuntu 14.04 beta2.
Also in gtk-applications run by superuser (bleachbit, gtkorphan) gtk-oxygen theme isn't applied.

> Also in gtk-applications run by superuser (bleachbit, gtkorphan) gtk-oxygen theme isn't applied.
It is completely unrelated and isn't a bug at all. Superuser is a completely separate user and has its own GTK configuration.

Created attachment 86074 [details]
How ZendStudio was lauched, and command ouput

My way to run zendstudio is the following 
#!/bin/sh
export LANG="en_US.UTF-8"
LC_CTYPE="fr_CH.UTF-8"
LC_NUMERIC="fr_CH.UTF-8"
LC_TIME="fr_CH.UTF-8"
LC_COLLATE="fr_CH.UTF-8"
LC_MONETARY="fr_CH.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="fr_CH.UTF-8"
LC_NAME="fr_CH.UTF-8"
LC_ADDRESS="fr_CH.UTF-8"
LC_TELEPHONE="fr_CH.UTF-8"
LC_MEASUREMENT="fr_CH.UTF-8"
LC_IDENTIFICATION="fr_CH.UTF-8"
export NSS_USE_SHARED_DB=true

export GTK_NATIVE_WINDOWS=1

# Patch Helios SR2
export MALLOC_CHECK_=0

#cleanup GTK ENV
#export GTK_RC_FILES=
#export GTK2_RC_FILES=
#export GTK_MODULES=
#export GTK_IM_MODULE=
##export GTK2_RC_FILES=/home/bruno/.gtkrc-2.0
# Crash without under 12.3 ...
ulimit -c unlimited

#export GTK2_RC_FILES=/usr/share/themes/Adwaita/gtk-2.0/gtkrc
/opt/Zend/ZendStudio/ZendStudio

Created attachment 86075 [details]
Dump log of the crash

This the /tmp/message related of the crash

Is there any update if this bug will ever be fixed?

As it's impossible to attach a big file here the related core dump is located there
https://dl.dropboxusercontent.com/u/13333867/Zend/core.bz2
(144MB)

Will be accessible ~7pm30 CEST (time to upload it)
beware it is 3.5GB uncompressed
-------------------------------------------------------------------
My first comment was not published too : I'm getting this kind of crash more & more with kde 4.13rc and ZendStudio 10.6.1 
If I uncomment all the gtk related cleanup line in my launch script (see previous comment) there no crash at all.

Can confirm the issue with:
- Kubuntu 14.04 amd64
- Eclipse 3.8.1
- java -version = java version "1.7.0_55" OpenJDK Runtime Environment (IcedTea 2.4.7, (7u55-2.4.7-1ubuntu1), OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

Tried the following workarounds, all did not help; opening the search menu (CTRL+F) and closing it with ESC only takes 2-3 attempts to crash Eclipse:

- Setting affinity (taskset -c 1 eclipse)
- Setting theme to Raleigh in systemsettings
- GTK2_RC_FILES=/usr/share/themes/Raleigh/gtk-2.0/gtkrc eclipse
- UBUNTU_MENUPROXY= eclipse
- Using all of the above at once ("export GTK2_RC_FILES=/usr/share/themes/Raleigh/gtk-2.0/gtkrc ; export UBUNTU_MENUPROXY= ; taskset -c 1 eclipse" - and setting Raleigh in systemsettings)


Typical hs_err file:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f487db99718, pid=13246, tid=139949693536000
#
# JRE version: OpenJDK Runtime Environment (7.0_55-b14) (build 1.7.0_55-b14)
# Java VM: OpenJDK 64-Bit Server VM (24.51-b03 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libgobject-2.0.so.0+0x19718] g_object_get_qdata+0x18
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

I spent this morning on our application crashing after having upgraded the openSuSE to 13.1. From several experiments I found, that at least for our crashing behaviour* it such related to
1) de-registration of a combobox (Java stacktraces shows this)
2) having been rendered a oxygen-gtk2 way (switching theme by setting GTK2_RC_FILES=/usr/share/themes/... <app> prevents from crashing)

I then had a look to the oxygen-gtk2 gtkrc. And my first modification already stopped our application from crashing: switched GtkComboBox::appears-as-list from 1 to 0. The combo appearance changes then to not show a list below the combo field but on top of it and without scroll bars, width is enlarged until content is fitting.

Maybe this info helps ... ?

*) I saw many traces and there seem to be also more problems leading to a SIGSEGV crash, at least one that was related on showing up a new widget.

I should have mentioned that our application bases on eclipse 3.7.1 rcp.

jstammi,
Very helpful, 
at least you found a working workaround to the crash
now: 
1/ this points to a Gtk issue (this is not the only issue there was with the appear-as-list, which is less and less maintain)
2/ we (oxygen) would really like to keep the flag set (appear-as-list) because it works well for many applications, and because it is consistent with what is used for Qt/KDE applications
All in all, this should then be reported upstream (-> gtk) for a proper fix.

Best,

Hugo

... one thing you could try is
- use another widget style (Raleigh)
- modify your gtkrc to set appears-as-list to 1 for this style
- see if the crash happens again
that would definitly put "oxygen" off-the-hook.

Having modified the Raleigh gtkrc to switch on the appears-as-list as recommended by Hugo, our application starts crashing again. So at least this problem, that indicates as described above - remember that AFAIS there are some more for which the symptoms are slightly different - this is no problem of the oxygen-gtk2 theme directly, but only by having switched on this flag by default.

So will go over to gtk bugtracker ...

Reported at GNOME as https://bugzilla.gnome.org/show_bug.cgi?id=736323.

Though this seems not the oxygen-gtk2's fault, you now know that it is caused by a specific option that you enable by default. And AFAIS a lot of people have/will run into this.
IMHO it would be a good idea to disable this at the moment. At least, and if such is possible, conditionally for specific gtk versions ... ?

Thank you for the report, Tom.

As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved.

I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Works with openSUSE Tumbleweed
Linux 5.9.12-1-default x86_64 GNU/Linux
nvidia: 450.80.02
Qt: 5.15.2
KDE Frameworks: 5.76.0
Plasma: 5.20.4 
kmail2 5.15.3 (20.08.3)

I've marked this as resolved as one of the affected users has confirmed it's fixed. However, if anyone else can still reproduce this bug please feel free to reopen it.