Bug 694520

You have a test machine to reproduce this?

The bug can be triggered choosing 'Other->Propose New Configuration' twice
(shortcut: Alt-E Alt-P, tested with textmode yast).

The trick seems to be to choose the option a second time _before_ yast has
finished the proposal (that is, be quick). On Bernhards test machine yast
takes its time, so this bug can be easily triggered. But it even happens on
my 11.3 workstation if you try hard enough.

So, this rather looks like an UI oder YaST core bug to me.

The backtrace looks like this:
/usr/lib64/liby2.so.2(_Z20signal_log_backtracev+0x1e)[0x7ff401287d6e]
/usr/lib64/liby2.so.2(_Z14signal_handleri+0x157)[0x7ff401287f77]
/lib64/libc.so.6(+0x32b30)[0x7ff3ff376b30]
/usr/lib64/libycpvalues.so.3(_ZN10YCPElementC2ERKS_+0x4)[0x7ff400bfa394]
/usr/lib64/libycpvalues.so.3(_ZNK10YCPListRep5valueEi+0x138)[0x7ff400bfb908]
/usr/lib64/libycpvalues.so.3(_ZNK10YCPListRep13functionalAddERK8YCPValueb+0x9d)[0x7ff400bfc7bd]
/usr/lib64/libycp.so.3(+0xc7f1b)[0x7ff401564f1b]
/usr/lib64/libycp.so.3(_ZN9YEBuiltin8evaluateEb+0x9ea)[0x7ff40150c90a]
/usr/lib64/libycp.so.3(_ZN8YSAssign8evaluateEb+0x44)[0x7ff401521b74]
/usr/lib64/libycp.so.3(_ZN6YBlock8evaluateEb+0x1d2)[0x7ff401533f72]
/usr/lib64/libycp.so.3(_ZN13Y2YCPFunction12evaluateCallEv+0x300)[0x7ff401509910]
/usr/lib64/libycp.so.3(_ZN10YEFunction8evaluateEb+0x2df)[0x7ff40150fb8f]
/usr/lib64/libycp.so.3(_ZN9YEBuiltin8evaluateEb+0x52e)[0x7ff40150c44e]
/usr/lib64/libycp.so.3(_ZN6YETerm8evaluateEb+0xde)[0x7ff4015082ce]
/usr/lib64/libycp.so.3(_ZN8YSReturn8evaluateEb+0x45)[0x7ff401521d65]
/usr/lib64/libycp.so.3(_ZN6YBlock8evaluateEb+0x1d2)[0x7ff401533f72]
/usr/lib64/libycp.so.3(_ZN13Y2YCPFunction12evaluateCallEv+0x300)[0x7ff401509910]
/usr/lib64/libycp.so.3(_ZN17YEFunctionPointer8evaluateEb+0x5a6)[0x7ff40150ee26]
/usr/lib64/libycp.so.3(_ZN9YSBracket8evaluateEb+0x61)[0x7ff401527f31]
/usr/lib64/libycp.so.3(_ZN6YBlock8evaluateEb+0x1d2)[0x7ff401533f72]
/usr/lib64/libycp.so.3(_ZN7YSBlock8evaluateEb+0x11)[0x7ff4015211e1]
/usr/lib64/libycp.so.3(_ZN4YSIf8evaluateEb+0x233)[0x7ff401521823]
/usr/lib64/libycp.so.3(_ZN6YBlock8evaluateEb+0x1d2)[0x7ff401533f72]
/usr/lib64/libycp.so.3(_ZN7YSBlock8evaluateEb+0x11)[0x7ff4015211e1]
/usr/lib64/libycp.so.3(_ZN4YSIf8evaluateEb+0x233)[0x7ff401521823]
/usr/lib64/libycp.so.3(_ZN4YSIf8evaluateEb+0x264)[0x7ff401521854]

It crashes in libycp. Martin, could you please look into it?

The crashing code is as simple as:
    list<string> ret = nil;
    ret = add (ret, "none");

and it is triggered by 
  any a = 0;
  list<string> ret = [ (string) a];

which produces nil instead of [nil] as I'd expect.

The two bugs in comment 5 are fixed in yast2-core-2.21.1 
SVN:
 http://svn.opensuse.org/viewcvs/yast?rev=64124&view=rev
 http://svn.opensuse.org/viewcvs/yast?rev=64125&view=rev
OBS Factory SR:
 https://build.opensuse.org/request/show/71665

Now let's find what triggered them. That is really strange, it looks like in Bernhard's logs SCR is really messed up, but I'd need the yast logs from /mnt to find out.

Steffen, are you sure you reproduced the same bug? Can you attach the logs from that?

Created attachment 431805 [details]
y2log

Created attachment 431807 [details]
signal

These are the logs from my last experiments.

Thanks. That is something different -> bug 696595.

Bernhard, do you still have the logs from your case? If I want to reproduce it, did you use any special settings?

This is an autogenerated message for OBS integration:
This bug (694520) was mentioned in
https://build.opensuse.org/request/show/71744 Factory / yast2-core

Created attachment 431877 [details]
yast2 logs after another crash

The machine is a Dell T3500. It has 11 partitions with MS-Windows(never booted), 4 Linuxes, 2 VGs and 5 LVs and it needs ~2 seconds to update the yast2 bootloader listing with the new proposal. Bug does not happen, if you wait after triggering first proposal - you will have to cancel and restart yast2 bootloader to have a chance to see the bug.

Steps To Reproduce:
yast2 bootloader
alt-e (Other)
alt-p (Propose New Configuration)
+quickly repeatedly press alt-e (Other) 
 (one would be enough, but it needs to happen at the right time)
press Enter (or select any other option in there - does not matter which)
=> segfaults

OK, but comment 12 is bug 696595. Sorry, I meant the crash from comment 0, May 18, at installation time (before reboot).

Ah, sorry for mixing that up. The machine is the one described in comment 12 anyway, so maybe there is even something left in the yast logs there.
If that and the logs from comment 0 are insufficient, I could try to install 11.4 into the same partition again.

Maybe I did choose minimal install - apart from that and the existing partitioning/installs I did nothing special during install. It popped up an error when trying to install grub (so grub2 from ubuntu was still installed). I told it to retry, error came again. Told it to retry once more, segfaulted.

Pepa, the crash has been fixed. You may want to find out what went wrong with the bootloader:

In comment 0, y2log at 13:39:12 calls Bootloader_API in the chroot
In comment 12, y2log-6.gz:
2011-05-18 11:39:12 <3> linux(12481) [Interpreter] <stdin>:224 Loading module 'Bootloader_API' failed

Hmm, logs there is really useless.
Steffen I found long time ago, that during instal when bootloader do remote call, then logs from perl-Bootloader disappear. It is really annoying as it can contain important information. Maybe we should solve it better then now? ( especially as limal logger looks like deprecated )

Bernhard, have you tested this against 12.1 at all?  It would be nice to have it fixed in time for release.

I can NOT reproduce this problem in openSuSE 12.1 Milestone 5 using the steps outlined above.  Can anybody find an alternative way to trigger this, or should the bug be closed?

Just did a 12.1 install on the same machine and it did not show this problem.
I would leave the bug open for 11.4 as it did happen there and possible fixes only went to Factory.

As it works in 12.1 I'm closing this bug as fixed even though realistically
we won't get a fix for 11.4.

I agree Steffan.  Thanks for closing.