Bug 767666 - yast sw_single gtk segfault
yast sw_single gtk segfault
: 765000 768496 768666 769965 770347 (view as bug list)
Classification: openSUSE
Product: openSUSE 12.2
Classification: openSUSE
Component: YaST2
x86-64 openSUSE 12.2
: P5 - None : Major (vote)
: ---
Assigned To: Federico Mena Quintero
Jiri Srain
Depends on:
  Show dependency treegraph
Reported: 2012-06-19 11:02 UTC by Bernhard Wiedemann
Modified: 2012-07-07 20:04 UTC (History)
10 users (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Wiedemann 2012-06-19 11:02:05 UTC
this is from
gdb --args  /usr/lib/YaST2/bin/y2base sw_single gtk

#0  0x00007fffdccd31bd in __gnu_cxx::__exchange_and_add_dispatch(int*, int)
[clone .constprop.79] () from /usr/lib64/YaST2/plugin/libpy2gtk_pkg.so.2
#1  0x00007fffdccd76fe in YGPackageSelector::Impl::refreshQuery() ()
   from /usr/lib64/YaST2/plugin/libpy2gtk_pkg.so.2
#2  0x00007fffdccff6af in
YGtkPkgQueryWidget::notifyDelay(int)::inner::timeout_cb(void*) () from
#3  0x00007fffebd08f9b in ?? () from /usr/lib64/libglib-2.0.so.0
#4  0x00007fffebd08405 in g_main_context_dispatch ()
   from /usr/lib64/libglib-2.0.so.0
#5  0x00007fffebd08738 in ?? () from /usr/lib64/libglib-2.0.so.0
#6  0x00007fffebd087f4 in g_main_context_iteration ()
   from /usr/lib64/libglib-2.0.so.0
#7  0x00007fffeea43c6c in YGUI::waitInput(unsigned long, bool) ()
   from /usr/lib64/YaST2/plugin/libpy2gtk.so.2
#8  0x00007ffff46c09a6 in YDialog::waitForEvent(int) ()
   from /usr/lib64/libyui.so.4
#9  0x00007fffeea42789 in YGUI::runPkgSelection(YWidget*) ()
   from /usr/lib64/YaST2/plugin/libpy2gtk.so.2
#10 0x00007ffff493073c in YCP_UI::RunPkgSelection(YCPValue const&) ()
   from /usr/lib64/YaST2/plugin/libpy2UI.so.2
#11 0x00007ffff491b60d in YUINamespace::RunPkgSelection(YCPValue const&) ()
   from /usr/lib64/YaST2/plugin/libpy2UI.so.2
#12 0x00007ffff491ee16 in YUIFunction::evaluateCall_int() ()
   from /usr/lib64/YaST2/plugin/libpy2UI.so.2
#13 0x00007ffff49360b9 in YCPBuiltinCaller::call() ()
   from /usr/lib64/YaST2/plugin/libpy2UI.so.2
#14 0x00007ffff46a0db1 in YUI::uiThreadMainLoop() ()
   from /usr/lib64/libyui.so.4
#15 0x00007ffff46a0f0e in start_ui_thread(void*) () from /usr/lib64/libyui.so.4
#16 0x00007ffff673be0e in start_thread () from /lib64/libpthread.so.0
#17 0x00007ffff5a5c28d in clone () from /lib64/libc.so.6
Comment 1 Thomas Göttlicher 2012-06-20 08:24:51 UTC
Ricardo, could you please look into that? Thank you in advance.
Comment 2 Thomas Göttlicher 2012-06-20 08:40:39 UTC
Federico can you fix this bug or otherwise pass it to Vincent, please? Many thanks.
Comment 3 Stephan Kulow 2012-06-20 12:56:33 UTC
Marking as ship stopper. If we can't fix it, we need to drop it and replace it with qt.
Comment 4 Josef Reidinger 2012-06-20 20:30:18 UTC
Bernhard - could you please describe exact way how to reproduce seg-fault? I try it with the latest factory and it start up without problems ( maybe fix in yast2-core solve issue ).
Comment 5 Bernhard Wiedemann 2012-06-21 06:46:18 UTC
Josef, I enter "g" in the search box (not even pressing return).
this happens with yast2-core-2.23.2 from YaST:Head, too
but it works with qt and ncurses
Comment 6 Josef Reidinger 2012-06-21 09:42:34 UTC
Ah, OK, it is not clear for me from description. I try to look at it today.
Comment 7 Josef Reidinger 2012-06-21 12:24:17 UTC
OK, I get more detailed debug log and it looks like it is somewhere in list destructor, which looks really strange for me, so if there is some gcc47 or glib expert it would be nice if he can look. I try some workaround if something help.

our source code:
https://github.com/libyui/libyui-gtk-pkg/blob/master/src/ygtkpkgsearchentry.cc#L306 ( yes I agree it is not good code, I am just curious why it doesn't work as it use copy constructor and should destroy local list )

#0  0x00007fffdcb1a1bd in __exchange_and_add (__mem=0x5500007fffe4cac0, __val=<optimized out>)
    at /usr/include/c++/4.7/ext/atomicity.h:48
#1  __gnu_cxx::__exchange_and_add_dispatch (__mem=0x5500007fffe4cac0, __val=-1)
    at /usr/include/c++/4.7/ext/atomicity.h:81
#2  0x00007fffdcb1e6fe in _M_dispose (__a=..., this=<optimized out>)
    at /usr/include/c++/4.7/bits/basic_string.h:242
#3  ~basic_string (this=<optimized out>, __in_chrg=<optimized out>)
    at /usr/include/c++/4.7/bits/basic_string.h:536
#4  destroy (__p=<optimized out>, this=<optimized out>)
    at /usr/include/c++/4.7/ext/new_allocator.h:123
#5  _M_clear (this=0x7fffe9ab7910) at /usr/include/c++/4.7/bits/list.tcc:78
#6  ~_List_base (this=0x7fffe9ab7910, __in_chrg=<optimized out>)
    at /usr/include/c++/4.7/bits/stl_list.h:401
#7  ~list (this=0x7fffe9ab7910, __in_chrg=<optimized out>)
    at /usr/include/c++/4.7/bits/stl_list.h:458
#8  YGPackageSelector::Impl::refreshQuery (this=0x7fffe42d5850)
    at /usr/src/debug/yast2-gtk-2.22.5/src/pkg/YGPackageSelector.cc:529
#9  0x00007fffdcb466af in YGtkPkgQueryWidget::notifyDelay(int)::inner::timeout_cb(void*) ()
    at /usr/src/debug/yast2-gtk-2.22.5/src/pkg/ygtkpkgquerywidget.h:40
#10 0x00007fffebd0ff9b in ?? () from /usr/lib64/libglib-2.0.so.0
#11 0x00007fffebd0f405 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#12 0x00007fffebd0f738 in ?? () from /usr/lib64/libglib-2.0.so.0
#13 0x00007fffebd0f7f4 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#14 0x00007fffeea4ac6c in YGUI::waitInput (this=0x14036c0, timeout_ms=0, block=true)
    at /usr/src/debug/yast2-gtk-2.22.5/src/YGUI.cc:212
#15 0x00007ffff46c79a6 in YDialog::waitForEvent(int) () from /usr/lib64/libyui.so.4
#16 0x00007fffeea49789 in YGUI::runPkgSelection (this=<optimized out>, 
    packageSelector=0x7fffe4061c90) at /usr/src/debug/yast2-gtk-2.22.5/src/YGUI.cc:274
#17 0x00007ffff493773c in YCP_UI::RunPkgSelection (value_id=...) at YCP_UI.cc:1396
#18 0x00007ffff492260d in YUINamespace::RunPkgSelection (this=<optimized out>, widget_id=...)
    at YUINamespace.cc:542
#19 0x00007ffff4925e16 in YUIFunction::evaluateCall_int (this=0x27e2280) at UIBuiltinCalls.h:161
#20 0x00007ffff493d0b9 in YCPBuiltinCaller::call (this=0x1403630) at YCPBuiltinCaller.cc:51
#21 0x00007ffff46a7db1 in YUI::uiThreadMainLoop() () from /usr/lib64/libyui.so.4
#22 0x00007ffff46a7f0e in start_ui_thread(void*) () from /usr/lib64/libyui.so.4
#23 0x00007ffff6742e0e in start_thread () from /lib64/libpthread.so.0
#24 0x00007ffff5a6328d in clone () from /lib64/libc.so.6
Comment 9 Vincent Untz 2012-06-21 13:01:04 UTC
The code:

gchar **_keywords = g_strsplit (text, delimiter, -1);
for (gchar **i = _keywords; *i; i++)
  if (**i)
    keywords.push_back (*i);
g_strfreev (_keywords);
return keywords;

Does "keywords.push_back (*i);" actually copy the gchar *?  My guess is no, so you end up with pointers in keywords, that are pointing to memory freed in g_strfreev().
Comment 10 Josef Reidinger 2012-06-21 13:06:19 UTC
(In reply to comment #9)
> The code:
> gchar **_keywords = g_strsplit (text, delimiter, -1);
> for (gchar **i = _keywords; *i; i++)
>   if (**i)
>     keywords.push_back (*i);
> g_strfreev (_keywords);
> return keywords;
> Does "keywords.push_back (*i);" actually copy the gchar *?  My guess is no, so
> you end up with pointers in keywords, that are pointing to memory freed in
> g_strfreev().

I think yes, as it should initialize std::string and it should not use use given pointer
Comment 11 Michael Matz 2012-06-21 14:30:36 UTC
Hrmpf.  A c++11/c++98 incompatibility.  An explanation is here:

In this case it's the problem with std::list incompatibility.  You compile
libycp (yast2-core) with -std=c++0x, hence it's std:list methods expect
a structure with the added elements.  The gtk plugin OTOH (yast2-gtk) is
compiled without any -std=xxx options, hence uses c++98, where std::list
doesn't have that member.  Now, what happens is this:

#1  0x00007fda4c7e96ac in YGPackageSelector::Impl::refreshQuery (
    at /usr/src/debug/yast2-gtk-2.22.5/src/pkg/YGPackageSelector.cc:529
529                             keywords = m_entry->getText();
(gdb) down
#0  0x00007fda67849bf8 in std::list<std::string, std::allocator<std::string> >::operator=(std::list<std::string, std::allocator<std::string> > const&) ()
   from /usr/lib64/libycp.so.3

Note how the function dealing with the list (operator=) called from
yast2-gtk (c++98) is resolved to a variant in libycp.so.3 (c++11).  That method
happily overwrites a member it expects to exist, but actually clobbering
a pointer member (I think the _M_next pointer, but may be wrong) the c++98
code expects there.  From there it goes downhill.

You can't mix c++11 and c++98 code, not even over shared library border :-(
(Or you have to tighly control your own exports;  if libycp.so wouldn't have
exported that std::list method (symbol _ZNSt4listISsSaISsEEaSERKS1_), it wouldn't have been picked up by yast2-gtk.)
Comment 12 Josef Reidinger 2012-06-21 15:26:54 UTC
(In reply to comment #11)
Michal thanks for detailed explain. I try to simple fix it with compile with c++11 and let see where I can get. ( I don't know this impact of c++11 I think it can make more noise in distribution ).
Comment 13 Josef Reidinger 2012-06-21 16:41:14 UTC
OK, so I create workaround that fix this issue ( adding -std=c++1x and I successfully test it ). I try to integrate it also to libyui git.
create sr https://build.opensuse.org/request/show/125696
Comment 14 Bernhard Wiedemann 2012-06-23 13:36:42 UTC
I have also seen this working with Factory + yast2-gtk from YaST:Head
Comment 15 Andreas Jaeger 2012-06-25 08:46:57 UTC
*** Bug 765000 has been marked as a duplicate of this bug. ***
Comment 16 Thomas Göttlicher 2012-07-02 08:20:03 UTC
*** Bug 768666 has been marked as a duplicate of this bug. ***
Comment 17 Thomas Göttlicher 2012-07-02 11:27:59 UTC
*** Bug 768496 has been marked as a duplicate of this bug. ***
Comment 18 Andreas Jaeger 2012-07-07 19:57:38 UTC
*** Bug 770347 has been marked as a duplicate of this bug. ***
Comment 19 Andreas Jaeger 2012-07-07 20:04:08 UTC
*** Bug 769965 has been marked as a duplicate of this bug. ***