Bug 360646

And i obtain xmessage:

xmessage

YaST got signal 11 at YCP file Wizard.ycp:273
/sbin/yast2:line 439: 9464 Segmentation fault $ybindir/y2base $module "$@"
"$SELECTED_GUI"$Y2_GEOMETRY $Y2UI_ARGS

This bug is in alpha 3 also.

Yes, i can confirm this bug still exists in Aplha3.

It seems to be problem of qt

With the information provided it could be anything. It could be mismatching shared libs. It could be something completely different. And if it's only in yast2-bootloader, why would it be a generic problem of the Qt UI?


2008-02-11 17:16:21 <1> linux-554y(3357) [wfm] Y2WFMComponent.cc(import):698 Y2WFMComponent::import (StorageClients)
2008-02-11 17:16:21 <1> linux-554y(3357) [wfm] Y2WFMComponent.cc(import):698 Y2WFMComponent::import (StorageClients)
2008-02-11 17:16:21 <1> linux-554y(3357) [wfm] Y2WFMComponent.cc(import):698 Y2WFMComponent::import (StorageClients)
2008-02-11 17:16:21 <1> linux-554y(3357) [wfm] Y2WFMComponent.cc(import):698 Y2WFMComponent::import (StorageClients)
2008-02-11 17:16:21 <1> linux-554y(3357) [YCP] Storage.ycp:2226 constructor Storage() end time:1202746581.643299204
2008-02-11 17:16:21 <1> linux-554y(3357) [qt-ui] src/YQUI_core.cc(YQUI):65 YQUI constructor start
2008-02-11 17:16:21 <1> linux-554y(3357) [qt-ui] src/YQUI_core.cc(processCommandLineArgs):245 Qt argument: YaST2
2008-02-11 17:16:21 <1> linux-554y(3357) [qt-ui] src/YQUI_core.cc(processCommandLineArgs):245 Qt argument: qt
2008-02-11 17:16:21 <1> linux-554y(3357) [qt-ui] src/YQUI_core.cc(calcDefaultSize):382 Default size: 895 x 683
2008-02-11 17:16:21 <1> linux-554y(3357) [qt-ui] src/YQUI_core.cc(qMessageHandler):569 <qt-debug> ("wizard", "full") 
2008-02-11 17:16:21 <1> linux-554y(3357) [qt-ui] src/YQUI_core.cc(qMessageHandler):569 <qt-debug> ("work_area") 
2008-02-11 17:16:21 <1> linux-554y(3357) [qt-ui] src/YQUI_core.cc(qMessageHandler):569 <qt-debug> ("steps") 
2008-02-11 17:16:21 <1> linux-554y(3357) [qt-ui] src/YQUI_core.cc(init_ui):204 Forcing /usr/lib/libQtGui.so.4 open successful
2008-02-11 17:16:21 <2> linux-554y(3357) [qt-ui] src/YQApplication.cc(loadPredefinedQtTranslations):119 Can't load translations for predefined Qt dialogs from /usr/share/qt4/translations/qt_en.qm
2008-02-11 17:16:21 <1> linux-554y(3357) [qt-ui] src/YQUI_core.cc(init_ui):223 YQUI constructor end. Thread ID: b5242b90
2008-02-11 17:16:21 <1> linux-554y(3357) [YCP] clients/bootloader.ycp:254 Starting bootloader configuration module
2008-02-11 17:16:21 <1> linux-554y(3357) [YCP] CommandLine.ycp:1214 ----------------------------------------
2008-02-11 17:16:21 <1> linux-554y(3357) [YCP] CommandLine.ycp:1215 Command line interface started
2008-02-11 17:16:21 <1> linux-554y(3357) [YCP] SuSERelease.ycp:47 File with release information: /etc/SuSE-release
2008-02-11 17:16:21 <3> linux-554y(3357) [liby2] genericfrontend.cc(signal_handler):133 got signal 11 at YCP file Wizard.ycp:273


We have a SIGSEGV handler that normally dumps a backtrace to the log. In this case it doesn't. This is suspicious.


Wizard.ycp:273 is:

	if ( haveFancyUI() )
	{
/*273*/	    UI::OpenDialog(`opt(`defaultsize ),
			   `Wizard(`back,  Label::BackButton(),
				   `abort, Label::AbortButton(),
				   `next,  Label::NextButton() ) );
	}


haveFancyUI() does several UI calls, yet the problem doesn't appear there, but in UI::OpenDialog().

2008-02-11 17:16:21 <1> linux-554y(3357) [YCP] CommandLine.ycp:1215 Command line interface started

This looks very suspicious. Why command line interface when the Qt UI was initialized? Wrong usage of CommandLine.ycp?

2 points: 
- I didn't change UI in yast2-bootloader...
- ncurses works. why? 

I know that were a lot of changes in yast UI. I accept that bootloader is not bugfree. But if I didn't change bootloader UI who is responsible for these problems? (dond't forget that ncurses works)

Coul you write me what I can do with it? (any special debug?)

NCurses does not try to open X11 windows. NCurses does not use the Wizard widget, but emulates a wizard-like layout with YCP. There are lots of differences. Plus, if it's a memory corruption somewhere, it might depend on memory layout. And of course the shared libs that are being loaded are very differnt.

Starting it with gdb to figure out _where_ it crashes would be a good start.
valgrind might be another useful tool.
And of course turning on full debug logging, too.

Created attachment 204234 [details]
backtrace

The one catch with this bug is that yast2 bootloader did not crash the first time when I ran it, only each subsequent time.
Anyway, here is the backtrace.

Created attachment 204235 [details]
y2log.gz with Y2DEBUG=1

Coolo, do we still have a problem with threading?
I wouldn't know what is different here from all the other places where we do the same. Several dozen OpenDialog() calls don't crash, and this one does. It might also be a Qt-4 bug.


#0  0x08b853c3 in ?? ()
#1  0x08b89098 in ?? ()
#2  0xb5e2124d in ?? () from /usr/lib/libQtGui.so.4
#3  0xb551e380 in ?? ()
#4  0xb7dd14ee in pthread_mutex_lock () from /lib/libpthread.so.0
#5  0xb5922756 in QCursor::handle () from /usr/lib/libQtGui.so.4
#6  0xb593131e in ?? () from /usr/lib/libQtGui.so.4
#7  0x08baab90 in ?? ()
#8  0xb5eda0a0 in ?? () from /usr/lib/libQtGui.so.4
#9  0xb5ed9420 in ?? () from /usr/lib/libQtGui.so.4
#10 0xb7a48780 in __cxa_atexit () from /lib/libc.so.6
#11 0xb5931499 in qt_x11_enforce_cursor () from /usr/lib/libQtGui.so.4
#12 0xb5935c96 in QWidgetPrivate::create_sys () from /usr/lib/libQtGui.so.4
#13 0xb5900b18 in QWidget::create () from /usr/lib/libQtGui.so.4
#14 0xb5907c8b in QWidget::setVisible () from /usr/lib/libQtGui.so.4
#15 0xb611b9ca in YQMainWinDock::show () from /usr/lib/YaST2/plugin/libpy2qt.so.2
#16 0xb611c28c in YQMainWinDock::add () from /usr/lib/YaST2/plugin/libpy2qt.so.2
#17 0xb610ac46 in YQDialog::YQDialog () from /usr/lib/YaST2/plugin/libpy2qt.so.2
#18 0xb6153a0e in YQWidgetFactory::createDialog () from /usr/lib/YaST2/plugin/libpy2qt.so.2
#19 0xb61539bf in covariant return thunk to YQWidgetFactory::createDialog(YDialogType, YDialogColorMode) ()   from /usr/lib/YaST2/plugin/libpy2qt.so.2
#20 0xb6a5f7f3 in YCP_UI::OpenDialog () from /usr/lib/YaST2/plugin/libpy2UI.so.2
#21 0xb6a48352 in YUINamespace::OpenDialog () from /usr/lib/YaST2/plugin/libpy2UI.so.2

2008-03-26 18:56:25 <0> os110-a3-vbox(6189) [libycp] ExecutionEnvironment.cc(pushframe):105 Push frame Wizard::OpenDialog (Wizard::NextBackDialog ())
2008-03-26 18:56:25 <0> os110-a3-vbox(6189) [liby2] SymbolEntry.cc(setValue):107 SymbolEntry::setValue (dialog@0x8164438 = '`VBox (`id (`WizardDialog), `ReplacePoint (`id (`topmenu), `Empty ()), `HBox (`HWeight (30, `ReplacePoint (`id (`helpSpace), `RichText (`id (`HelpText), ""))), `HSpacing (1), `HWeight (70, `VBox (`VSpacing (0,2), `HBox (`Heading (`id (`title), `opt (`hstretch), "YaST2\nInitializing ..."), `HStretch ()), `VWeight (1, `HVCenter (`opt (`hvstretch), `ReplacePoint (`id (`contents), `Empty ()))), `ReplacePoint (`id (`rep_button_box), `HBox (`HWeight (1, `ReplacePoint (`id (`rep_back), `PushButton (`id (`back), `opt (`key_F8), "&Back"))), `HStretch (), `ReplacePoint (`id (`rep_abort), `PushButton (`id (`abort), `opt (`key_F9), "Abo&rt")), `HStretch (), `HWeight (1, `ReplacePoint (`id (`rep_next), `PushButton (`id (`next), `opt (`key_F10, `default), "&Next"))))), `VSpacing (0,2))), `HSpacing (1)))')
2008-03-26 18:56:25 <0> os110-a3-vbox(6189) [libycp] ExecutionEnvironment.cc(pushframe):105 Push frame OpenDialog (`opt (`defaultsize), dialog)
2008-03-26 18:56:25 <0> os110-a3-vbox(6189) [qt-ui] src/YQMainWinDock.cc(YQMainWinDock):55 MainWinDock initial size: 800 x 553
2008-03-26 18:56:25 <0> os110-a3-vbox(6189) [qt-ui] src/YQDialog.cc(chooseParent):114 Adding dialog to mainWinDock
2008-03-26 18:56:25 <0> os110-a3-vbox(6189) [qt-ui] src/YQMainWinDock.cc(add):123 Adding dialog 0x8bb8478  to mainWinDock

Created attachment 204247 [details]
test script

This is that last YCPTerm from that log reformatted and wrapped into a YCP test script. This does not crash for me in my development environment.

I wonder why this fallback layout was used in the first place - Qt has a wizard widget. That should have been used, not the YCP emulation of the wizard.

last time I checked random yast2 module (live installer) with valgrind I noticed worrying hits, so I wouldn't stare at the crashing code too long.

And no, threading itself sounds hardly the problem - as all Qt code is run in one thread afaik.

The very first start of "yast2 bootloader" worked. Any subsequent start crashes, even after restarting X. Just like in comment #8.

So what is different here? Is some file written during the first call that makes a difference?

Most other YaST2 modules work fine. But  yast2 users crashes, too. It is also Perl-based, like yast2 bootloader.

Created attachment 204320 [details]
simple perl script using the YaST2 engine and UI

This does not crash, but it leaves a very suspicious error message:

tux@g240:~/tmp> ./perltest.pl
Importing UI
UI UI::OpenDialog (YaST::YCP::Term=HASH(0x83292fc))
UI UI::UserInput ()
UI UI::QueryWidget (YaST::YCP::Term=HASH(0x836e5f4), YaST::YCP::Symbol=SCALAR(0x8381c04))
UI UI::CloseDialog ()
It is 'test'
panic: free from wrong pool during global destruction.

Time for valgrind.

Created attachment 204330 [details]
valgrind run for perltest.pl

From within valgrind, perltest.pl segfaults, too.

Created attachment 204332 [details]
valgrind run for HelloWorld.ycp

For comparison: Valgrind run on HelloWorld.ycp. No segfault.

Well, no segfault, but still suspicious messages around  qt_x11_enforce_cursor.

*** Bug 363168 has been marked as a duplicate of this bug. ***

I still believe it's a problem in yast2-perl-bindings - overwriting memory somewhere and/or different startup order of all the Y2Components. IMHO it's too obvious that it happens with perl-based YaST2 modules (and AFAICS with all of them (?)).

*** Bug 373064 has been marked as a duplicate of this bug. ***

*** Bug 372989 has been marked as a duplicate of this bug. ***

*** Bug 375174 has been marked as a duplicate of this bug. ***

*** Bug 372339 has been marked as a duplicate of this bug. ***

Hm - bug #372339 uses vendor.ycp. It's not Perl based.

This bug also seen on PPC / iMac platform. However it seems there's a separate boot-loader problem on PPC (bug #374693), presumably not related.

*** Bug 357757 has been marked as a duplicate of this bug. ***

I'm on beta1 and bootloader works in my case.

(In reply to comment #30 from Rastislav Krupansky)
> I'm on beta1 and bootloader works in my case.

I am relieved to hear that. We should give that some more thorough testing.

I tested yast2-bootloader, yast2-vendor-cd, yast2-users and a number of other YaST2 modules that use the yast2-perl-bindings with Beta1. I couldn't reproduce any of the crashes.

AFAIK there was a change in Perl itself because of that message 

    panic: free from wrong pool during global destruction

Since the problem appeared only in Perl-based YaST2 modules and they all showed that message and now that message is gone and there is no more crash, I am pretty sure that those crashes were after-effects. The message sounds a lot like memory corruption.

-> FIXED.

*** Bug 368199 has been marked as a duplicate of this bug. ***