Bug 214886

Created attachment 102532 [details]
/var/log/YaST2/*

Lslezak, the last call outside  inst_extrasources was this one:
ProductControl.ycp:917 Calling `inst_extrasources ($["enable_back":true, "enable_next":true])

The very last inst_extrasources log is this:
clients/inst_extrasources.ycp:312 Pkg Builtin called: SourceCreate

The very last things in macro_inst_cont.ycp are:
* Dialog with YLabel "Source http://download.opensuse.org/distribution/SL-OSS-factory/inst-s..."
* Source: /usr/share/YaST2/clients/inst_extrasources.ycp(SourceCreate (new_url, "/")):312
* UI::FakeUserInput( `RETRY );
and
* Dialog with YLabel "An error occurred while creating the installation source. Details: Unk..."
* Source: Popup.ycp(Popup::AnyQuestion (headline, message, Label::YesButton (), Label::NoButton (), `focus_yes)):503
* UI::FakeUserInput( `no_button );

Could you, please, tell me, how the client exited? What was the returned result?

y2start.log says:
    |-- YaST procedure ended successfully

Hm, the result should be always `auto.

I'll debug it...

I'm afraid this might be a duplicate of: Bug 214265 - YAST2 printer module crashes rebuilding the driver database

YaST aborts after the inst_extrasources client.

I've reproduced it and found it: inst_extrasource aborts in line 312 when you try to add the very last installation source (ZMD is installed and running).

The source URL was: http://download.suse.com/install/10.2/inst-source-extra/

It seems to be problem of Pkg:: -> lslezak
Anyway, inst_extrasource is also maintained by lslezak

I'll attach my logs. BTW: the YaST ABORT message was visible for quite a long time until the system booted.

Created attachment 102593 [details]
my YaST logs

In the log, there is a Error 503 - Service Unavailable, maybe this error is not properly handled by ZYPP. Just guessing...

The last line in the log is:
2006-10-25 16:44:32 <1> gizo(4376) [zypp::SourceManager] SourceManager.cc(releaseAllSources):241 SourceManager releasing all sources done.                     

Running the SourceCreate command (Pkg::SourceCreate("http://download.suse.com/install/10.2/inst-source-extra/","/")) in gdb revealed a segfault in zypp:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218692928 (LWP 6760)]
0xb6f9a528 in zypp::ResObject::summary (this=0x0) at ResObject.cc:58
58        { return pimpl().summary().text(); }
Current language:  auto; currently c++

Backtrace:
#0  0xb6f9a528 in zypp::ResObject::summary (this=0x0) at ResObject.cc:58
#1  0xb70e3252 in zypp::source::susetags::SuseTagsImpl::provideProducts (
    this=0xd4ce9b8, source_r=@0xbfcbb79c, store=@0xd4ce9c8)
    at SuseTagsImpl.cc:621
#2  0xb70e3761 in zypp::source::susetags::SuseTagsImpl::createResolvables (
    this=0xd4ce9b8, source_r=@0xbfcbb7e4) at SuseTagsImpl.cc:519
#3  0xb7090042 in zypp::source::SourceImpl::resolvables (this=0xd4ce9b8)
    at SourceImpl.cc:234
#4  0xb6fb006f in zypp::Source_Ref::resolvables (this=0xbfcbb9c8)
    at Source.cc:61
#5  0xb5ef0b28 in ZyppRecipients::MediaChangeReceive::requestMedia (
    this=0x80aa2f8, source=@0xbfcbb9c8, mediumNr=1, 
    error=zypp::media::MediaChangeReport::INVALID, description=@0xbfcbb9c4)
    at Callbacks.cc:812
#6  0xb7094e44 in zypp::source::SourceImpl::provideDirTree (this=0xd4ce9b8, 
    path_r=@0xbfcbbe10, media_nr=1) at SourceImpl.cc:650
#7  0xb70e73b2 in zypp::source::susetags::SuseTagsImpl::downloadMetadata (
    this=0xd4ce9b8) at SuseTagsImpl.cc:262
#8  0xb70ee401 in zypp::source::susetags::SuseTagsImpl::saveMetadataTo (
    this=0xd4ce9b8, dir_r=@0xbfcbc3f8) at SuseTagsImpl.cc:448
#9  0xb70eea9c in zypp::source::susetags::SuseTagsImpl::factoryInit (
    this=0xd4ce9b8) at SuseTagsImpl.cc:496
#10 0xb7092ebe in zypp::source::SourceImpl::factoryCtor (this=0xd4ce9b8, 
#0  0xb6f9a528 in zypp::ResObject::summary (this=0x0) at ResObject.cc:58
#1  0xb70e3252 in zypp::source::susetags::SuseTagsImpl::provideProducts (
    this=0xd4ce9b8, source_r=@0xbfcbb79c, store=@0xd4ce9c8)
    at SuseTagsImpl.cc:621
#2  0xb70e3761 in zypp::source::susetags::SuseTagsImpl::createResolvables (
    this=0xd4ce9b8, source_r=@0xbfcbb7e4) at SuseTagsImpl.cc:519
#3  0xb7090042 in zypp::source::SourceImpl::resolvables (this=0xd4ce9b8)
    at SourceImpl.cc:234
#4  0xb6fb006f in zypp::Source_Ref::resolvables (this=0xbfcbb9c8)
    at Source.cc:61
#5  0xb5ef0b28 in ZyppRecipients::MediaChangeReceive::requestMedia (
    this=0x80aa2f8, source=@0xbfcbb9c8, mediumNr=1, 
    error=zypp::media::MediaChangeReport::INVALID, description=@0xbfcbb9c4)
    at Callbacks.cc:812
#6  0xb7094e44 in zypp::source::SourceImpl::provideDirTree (this=0xd4ce9b8, 
    path_r=@0xbfcbbe10, media_nr=1) at SourceImpl.cc:650
#7  0xb70e73b2 in zypp::source::susetags::SuseTagsImpl::downloadMetadata (
    this=0xd4ce9b8) at SuseTagsImpl.cc:262
#8  0xb70ee401 in zypp::source::susetags::SuseTagsImpl::saveMetadataTo (
    this=0xd4ce9b8, dir_r=@0xbfcbc3f8) at SuseTagsImpl.cc:448
#9  0xb70eea9c in zypp::source::susetags::SuseTagsImpl::factoryInit (
    this=0xd4ce9b8) at SuseTagsImpl.cc:496
#10 0xb7092ebe in zypp::source::SourceImpl::factoryCtor (this=0xd4ce9b8, 
    media_r=@0xbfcbc748, path_r=@0xbfcbc640, alias_r=@0xbfcbc6d0, 
    cache_dir_r=@0xbfcbc648, base_source=false, auto_refresh=true)
    at SourceImpl.cc:175
#11 0xb6fba2cf in zypp::SourceFactory::createSourceImplWorkflow<zypp::source::susetags::SuseTagsImpl> (this=0xbfcbc94c, id=4, context=@0xbfcbc7a0)
    at SourceFactory.cc:50
#12 0xb6fb4897 in zypp::SourceFactory::createFrom (this=0xbfcbc94c, 
    url_r=@0xbfcbc93c, path_r=@0xbfcbcaa8, alias_r=dwarf2_read_address: Corrupted DWARF expression.
) at SourceFactory.cc:250
#13 0xb5ed4119 in createManagedSource (url_r=@0xbfcbcaa0, path_r=@0xbfcbcaa8, 
    base_source=false) at Source.cc:1000
#14 0xb5ed9900 in PkgModuleFunctions::SourceCreateEx (this=0x80a9b18, 
    media=@0xbfcbd514, pd=@0xbfcbd50c, base=false) at Source.cc:1253
#15 0xb5eda6df in PkgModuleFunctions::SourceCreate (this=0x80a9b18, 
    media=@0xbfcbd514, pd=@0xbfcbd50c) at Source.cc:1166
#16 0xb5e99fe0 in Y2PkgFunction::evaluateCall (this=0x8129b18)
    at PkgBuiltinCalls.h:87
#17 0xb7d5054e in YEFunction::evaluate () from /usr/lib/libycp.so.2
#18 0xb7d73727 in YSExpression::evaluate () from /usr/lib/libycp.so.2
#19 0xb7d8f8f9 in YBlock::evaluate () from /usr/lib/libycp.so.2
#20 0xb7d44044 in YCPCodeRep::evaluate () from /usr/lib/libycp.so.2
#21 0xb7f1ca1b in Y2WFMComponent::doActualWork ()
   from /usr/lib/YaST2/plugin/libpy2wfm.so.2
#22 0xb7ce4d71 in main () from /usr/lib/liby2.so.2

it segfaults in summary, so is either a TranslatedText problem, or the product being a invalid pointer. I will investigate

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

Raising severity, seems to happen very often.

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

Ad comment #13: No, it doesn't happen 'very often', it happens always you try to register THAT source :) I guess this is not a blocker because a workardound exists -> do not register that source.

Unfortunately, not registering that source may be a problem.

In my case, I asked for if I wanted to add an update source, the install routine chose http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/
Accepting that choice caused YaST to seg-fault and resulted in a second run-through after a reboot, this time not adding an update source, to be able to complete the installation.

One of the joys of setting up a proxy was being able to capture the requests YaST made as part of the setting up update sources. From peeking at the logs, it appears that the comment in comment #9 about the 503 error may be in the right area.

I've attached the log entries from my proxy showing the requests YaST made, which mirror was chosen, and the responses given. It appears that receiving a 500 error caused YaST to seg-fault.

Created attachment 102906 [details]
proxy log showing update source addition failure

Squid proxy logs shoing URLs requested by YaST when adding an update source. Last entry appears to be where YaST seg-faults.

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

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

Just doing some testing with curl.

Try:
curl -I -L http://download.suse.com/install/10.2/inst-source-extra/media.1/info.txt

and do it lot of times, faast.

First, download.suse.com balancer doesn't give the user the same mirror. It changes it all the time. And when you hit http://download.uni-hd.de/ftp/pub/linux/suse/install/10.2/inst-source-extra you can't connect to it, just for 1 file.

So basically the file of the source that gets this mirror assigned, is the one that fails.
http://download.opensuse.org does not seem to suffer from that random load balancing, I get always the same host.

Still, finding out why zypp does not let you retry is the other half of the bug.

Anyway, I am trying to find out why zypp reacts in that way to the error instead of allow retrying.

Christopher, can you check why the load balancing of suse.com works like that, and why inactive mirrors are there?

Ok, I think there is a bug in YaST2 type sources, where we use provideDirTree to download media.1 directory, but it does not follow the standard callback workflow.

Well, the bug actually has nothing to do with that.

The crash happens in:
report->requestMedia ( selfSourceRef(), media_nr, reason, excp.asUserString() );

lslezak, are you handling this callback, do we have the same signatures?

The callback is handled correctly, the signature is correct.

It crashes in source.resolvables().begin() call in pkg-bindings in requestMedia handler.

I think the problem is in the sequence of the bindings/zypp calls. Zypp calls requestMedia() callback with parameter source, but the problem is that the source has not been fully initialized yet (the initialization is in progress).

The bindings try to get some information from the passed Source_Ref, which obviously fails (segfaults) because the source has not been initialized.

A solution could be to pass Source_Ref::noSource reference when the source has not been initialized yet and handle this case in bindings.

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

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

We decided that we will initialize sources with the product name as alias, unless the user change it, why not using alias() there instead of iterating the product there?

Then, if the source is not yet initialized, it will be empty, but once it is initilized, it will display the product name, except if the user changed it to something custom?

I have a patch for pkg-bindings, and it does not crashes anymore.

Thank you! You are right, using the alias is the solution.

Fixed in yast2-pkg-bindings-2.13.103

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