openSUSE is not an enterprise product so it does not qualify for a CritSit.

I can confirm this problem with the 64bit DVD, segfaults on two totally different hardware setups.

Yes, I see this problem with the 64bit DVD build0556, but not with the i586.

From a 64bit openSUSE 11.2 host (2.6.31.12-0.2-desktop) with Intel Q9650,
running VirtualBox 3.1.6 r59338, the install segfaults during repository initialization. (GUI;CURSES,AutoYAST, all same results)


First part of /var/log/YaST2/signal:

YaST got signal 11 at YCP file Packages.ycp:1428
Liberating suppressed debugging messages:
[liby2] SymbolEntry.cc(setValue):107 SymbolEntry::setValue (progress_value@0x14378c0 = '0')
[libycp] ExecutionEnvironment.cc(pushframe):105 Push frame StackSize ()
[libycp] ExecutionEnvironment.cc(popframe):115 Pop frame 0x1b297a0
[libycp] ExecutionEnvironment.cc(pushframe):105 Push frame TopState ()
[libycp] ExecutionEnvironment.cc(popframe):115 Pop frame 0x1b1bc40
[liby2] SymbolEntry.cc(setValue):107 SymbolEntry::setValue (prev_state@0x1438400 = '$["current_stage":9, "current_step":9, "last_subprogress_max":0, "progress_label":"Initializing package manager...", "progress_max":10,

From /usr/share/YaST2/modules/Packages.ycp:1428
global void Initialize_StageInitial (...) 
...
  initial_source = Pkg::SourceCreateBase (base_url, "");

First part of callchain traceback:
Backtrace: (use c++filt to demangle)
/usr/lib64/liby2.so.2(_Z20signal_log_backtracev+0x1e)[0x7f0c9555d64e]
/usr/lib64/liby2.so.2(_Z14signal_handleri+0x157)[0x7f0c9555d857]
/lib64/libc.so.6(+0x32a20)[0x7f0c9365ea20]
/usr/lib64/libzypp.so.631(_ZN4zypp4repo8susetags10Downloader12consumeIndexERKN5boost13intrusive_ptrINS_6parser8susetags9RepoIndexEEE+0xa3)[0x7f0c8f8d7f3]
/usr/lib64/libzypp.so.631(_ZN4zypp6parser8susetags17ContentFileReader8endParseEv+0x45)[0xf70c8f6b2805]

Perhaps a duplicate of bug #595545?

Confirmed, it fails on vmware and a standard dell box with the same error. 
It seems the 64bit milestone 5 has not been tested by a single person before declaring it a milestone

DUPLICATE

*** This bug has been marked as a duplicate of bug 595545 ***

Are you sure this is a duplicate?

As I understand from bug 595545, the focus there is on changes due to boost 1.4x

But as shown above in comment 3, the function names are from boost 1.3x
( ..consumeIndexERKN5boost13.. )  so I don't think this build happened after factory was contaminated with the new boost code.

Now I'm no expert, so maybe there are some other valid reasons linked to 595545.
But I hope everyone doesn't just sit around and wait for 595545, only to discover that this problem (596071) still exists afterwards.  

Anyway, I noticed that the "Get It" website is still serving the defective 64bit DVD.
Already 2 collegues at work downloaded without knowing that it's 4467MB of junk.
This seems like a waste of time, bandwidth, and media for all involved.
If we don't expect a rapid re-release soon, should we not zap that option?

When is re-release expected if there is any.

(In reply to comment #7)
> Are you sure this is a duplicate?

Yes.

> But as shown above in comment 3, the function names are from boost 1.3x
> ( ..consumeIndexERKN5boost13.. )  so I don't think this build happened after
> factory was contaminated with the new boost code.

No. Just do 'nm /usr/lib64/libzypp.so| grep boost | less' (nm is from package binutils). 

You'll see that the numbers int those cryptic strings is not related to any version. There are also boot6 and boost9 and others, so the above is a '13' and not an abbreviated 1.3. 

These are just the low-level names the compiler assigns to the symbols in the library. Calling 'nm -C /usr/lib64/libzypp.so' will demangle and show them in a human readable form (well, at least for humans that talk C++).


(In reply to comment #8)
> When is re-release expected if there is any.

Sorry, but I don't know. A preliminary fix was already submitted (libzypp-7.0), so I hope a working 64bit version is available soon.