Created attachment 3823 [details]
update log

Looks like it doesn't like when pango changes under its nose...

Can you reproduce it?
If yes could you attach gdb to its process before the crash in order to get a gdb trace?

CC: (none) => mageia

Trying to reproduce it now (takes a few hours).  I can't figure out how to
get the debuginfo packages installed.

If I exit the program after the first transaction, to enable the
debug repos and install the debuginfo packages,, then mgaonline can't
be restarted.

Is a gdb bt any use without the debuginfo packages installed?

That was strange.  It didn't segfault this time. It just disappeared
from the screen. htop shows
4 S  0.0  1.6  0:04.61 â  ââ /usr/bin/perl /usr/bin/mgaapplet
2 S  0.0  0.4  0:00.24 â  â  ââ mgaapplet-upgrade-helper --new_distro_version=3
2 S  0.0  0.4  0:00.00 â  â  â  ââ mgaapplet-upgrade-helper --new_distro_version=3
0 S  0.0  0.0  0:00.01 â  â  â  ââ /usr/sbin/userhelper -w mgaapplet-upgrade-helper --new_
2 t  0.0  1.3  0:00.57 â  â  â     ââ /usr/bin/perl /usr/sbin/mgaapplet-upgrade-helper --n
0 Z  0.0  0.0 59:20.86 â  â  â        ââ gurpmi2
0 Z  0.0  0.0  0:00.00 â  â  â        ââ xdg-screensaver
0 Z  0.0  0.0  0:00.00 â  â  â        ââ ionice

It seems it did finish though.  After a reboot, urpmi --auto-select
  Package                        Version      Release       Arch    
(medium "Core Release")
  dbus                           1.6.8        4.mga3        x86_64  
  dbus-x11                       1.6.8        4.mga3        x86_64  
  lib64dbus-devel                1.6.8        4.mga3        x86_64  
  lib64dbus1_3                   1.6.8        4.mga3        x86_64  
  python-dbus                    1.1.1        2.mga3        x86_64  
(medium "Core 32bit Release")
  libdbus1_3                     1.6.8        4.mga3        i586

After another reboot, Packages are up to date.

What about this bug? Can we close it for now?

CC: (none) => ennael1

No.  While it didn't segfault, it also still isn't completing
properly.  I'll close it if further testing shows it does
close properly.

Just got the segfault again, after the last package is
installed.

Trace looks the same as in the Description.

I'll see if it's possible to interrupt, enable the
debug repositories, and restart it.

After the first transaction, I added the debug repos and
installed the debug packages, but when trying to restart
mgaapplet, it still fails with ...
[dave@x3v ~]$ mgaapplet --testing
*** This build of Gtk2 was compiled with gtk+ 2.24.14, but is currently running with 2.24.10, which is too old.  We'll continue, but expect problems!
$[ used in numeric lt (<) (did you mean $] ?) at /usr/lib/perl5/vendor_perl/5.14.1/XML/Twig.pm line 7286.
$[ used in numeric lt (<) (did you mean $] ?) at /usr/lib/perl5/vendor_perl/5.14.1/XML/Twig.pm line 7292.
$[ used in numeric lt (<) (did you mean $] ?) at /usr/lib/perl5/vendor_perl/5.14.1/XML/Twig.pm line 7304.
retrieved   testing-x86_64?product=Default&version=2&mgaonline_version=2.79
getting exclusive lock on urpmi
unlocking urpmi database
medium "Core Updates" is up-to-date
<snip>
examining synthesis file [/var/lib/urpmi/Core 32bit Updates/synthesis.hdlist.cz]
Undefined subroutine &urpm::check_cache_dir called at /usr/bin/mgaapplet line 404.

Rebooting after the first transaction leaves a barely responsive
system, with dbus, networking etc, not working.

The undefined function problem has been fixed. Just need to do a new release of mgaonline in cauldron.

You need first to confirm whether fix.diff fixes your issue with not providing download directory

@Thierry: Was that last comment directed at me by the way? If so which fix.diff were you referring to? I'm a bit lost in the noise at the moment :D

IIUC, it's actually due to a problem related to consolehelper which meant that mgaapplet-upgrade-helper was not actually run as root and thus the download dir was not writable (by the user) and that caused an infinite loop. But off topic for this bug :)

Still segfaulting ...
The "mgaapplet-upgrade-helper" program has segfaulted with the following error:

  SEGV
  Glibc's trace:
  4: /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so(Perl_sighandler+0x1f0) [0x7f9c8b6fc510]
  5: /lib64/libpthread.so.0(+0xef70) [0x7f9c8a94ef70]
  6: /lib64/libharfbuzz.so.0(hb_buffer_add_utf8+0x3d0) [0x7f9c79fa45b0]
  7: /usr/lib64/pango/1.8.0/modules/pango-basic-fc.so(+0x1b54) [0x7f9c7a231b54]
  8: /usr/lib/../lib64/libpango-1.0.so.0(pango_shape+0x4a) [0x7f9c8450c18a]
  9: /usr/lib/../lib64/libpango-1.0.so.0(+0xf9f1) [0x7f9c844ef9f1]
  10: /usr/lib/../lib64/libpango-1.0.so.0(+0xfca9) [0x7f9c844efca9]
  11: /usr/lib/../lib64/libpango-1.0.so.0(+0x22677) [0x7f9c84502677]
  12: /usr/lib/../lib64/libpango-1.0.so.0(+0x234c6) [0x7f9c845034c6]
  13: /usr/lib/../lib64/libgtk-x11-2.0.so.0(+0x128aa1) [0x7f9c834a8aa1]
  14: /usr/lib/../lib64/libgtk-x11-2.0.so.0(+0x12a3dd) [0x7f9c834aa3dd]
  15: /lib/../lib64/libgobject-2.0.so.0(g_cclosure_marshal_VOID__BOXEDv+0x8d) [0x7f9c87a62fcd]
  16: /lib/../lib64/libgobject-2.0.so.0(+0xfe3c) [0x7f9c87a5fe3c]
  17: /lib/../lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x421) [0x7f9c87a78711]
  18: /lib/../lib64/libgobject-2.0.so.0(g_signal_emit_by_name+0x504) [0x7f9c87a79724]
  19: /usr/lib/../lib64/libgtk-x11-2.0.so.0(+0x1a3473) [0x7f9c83523473]
  
  Perl's trace:
  standalone::bug_handler() called from /usr/lib/libDrakX/standalone.pm:224
  standalone::__ANON__() called from /usr/lib/libDrakX/mygtk2.pm:1212
  (eval)() called from /usr/lib/libDrakX/mygtk2.pm:1212
  mygtk2::MagicWindow::AUTOLOAD() called from /usr/lib/libDrakX/ugtk2.pm:772
  ugtk2::show() called from /usr/lib/libDrakX/ugtk2.pm:765
  ugtk2::main() called from /usr/sbin/mgaapplet-upgrade-helper:159
  main::run_gurpmi() called from /usr/sbin/mgaapplet-upgrade-helper:426
  main::upgrade() called from /usr/sbin/mgaapplet-upgrade-helper:112


The last line from syslog, from before drakbug is ...
mgaapplet-upgrade-helper[5613]: removed files/directories (recursively) /var/lib/urpmi/stale_upgrade_in_progress

I got this too. It was right at the end tho' so all packages had been upgraded by this stage.

Not sure if this is useful or not. Downloaded and installed the debuginfo
packages before starting the upgrade (with rpm -i --force).

Found that when it reaches the end, it just disappears, until I quit
gdb, then it pops up the drakbug capture of the segfault.

Restarting gdb and running bt shows
(gdb) bt
#0  0x00007ff449dedd9d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ff446cdf9a4 in g_main_context_poll (n_fds=4, fds=0x26bb940, timeout=-1,
    context=0x1e956e0, priority=<optimized out>) at gmain.c:3584
#2  g_main_context_iterate (context=0x1e956e0, block=block@entry=1,
    dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3285
#3  0x00007ff446cdfe02 in g_main_loop_run (loop=0x26bb820) at gmain.c:3484
#4  0x00007ff440082047 in IA__gtk_main () at gtkmain.c:1257
#5  0x00007ff4472036e4 in gtk_main () at GClosure.xs:747
#6  0x00007ff44062d35e in XS_Gtk2_main (my_perl=<optimized out>, cv=0x1f3fa80)
    at xs/Gtk2.xs:449
#7  0x00007ff44af1da22 in Perl_pp_entersub (my_perl=0x10b7010) at pp_hot.c:2778
#8  0x00007ff44af16196 in Perl_runops_standard (my_perl=0x10b7010) at run.c:41
#9  0x00007ff44aeb1b45 in S_run_body (oldscope=1, my_perl=0x10b7010) at perl.c:2402
#10 perl_run (my_perl=0x10b7010) at perl.c:2320
#11 0x0000000000400f09 in main (argc=6, argv=0x7fffde6c7de8, env=0x7fffde6c7e20)
    at perlmain.c:120

And here is what drakbug captured ...
  SEGV
  Glibc's trace:
  4: /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so(Perl_sighandler+0x1f0) [0x7fbe43ebc510]
  5: /lib64/libpthread.so.0(+0xef70) [0x7fbe4310ef70]
  6: /lib64/libharfbuzz.so.0(hb_buffer_add_utf8+0x3d0) [0x7fbe327645b0]
  7: /usr/lib64/pango/1.8.0/modules/pango-basic-fc.so(+0x1b54) [0x7fbe329f1b54]
  8: /usr/lib/../lib64/libpango-1.0.so.0(pango_shape+0x4a) [0x7fbe3cccc18a]
  9: /usr/lib/../lib64/libpango-1.0.so.0(+0xf9f1) [0x7fbe3ccaf9f1]
  10: /usr/lib/../lib64/libpango-1.0.so.0(+0xfca9) [0x7fbe3ccafca9]
  11: /usr/lib/../lib64/libpango-1.0.so.0(+0x22677) [0x7fbe3ccc2677]
  12: /usr/lib/../lib64/libpango-1.0.so.0(+0x234c6) [0x7fbe3ccc34c6]
  13: /usr/lib/../lib64/libgtk-x11-2.0.so.0(+0x128aa1) [0x7fbe3bc68aa1]
  14: /usr/lib/../lib64/libgtk-x11-2.0.so.0(+0x12a3dd) [0x7fbe3bc6a3dd]
  15: /lib/../lib64/libgobject-2.0.so.0(g_cclosure_marshal_VOID__BOXEDv+0x8d) [0x7fbe40222fcd]
  16: /lib/../lib64/libgobject-2.0.so.0(+0xfe3c) [0x7fbe4021fe3c]
  17: /lib/../lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x421) [0x7fbe40238711]
  18: /lib/../lib64/libgobject-2.0.so.0(g_signal_emit_by_name+0x504) [0x7fbe40239724]
  19: /usr/lib/../lib64/libgtk-x11-2.0.so.0(+0x1a3473) [0x7fbe3bce3473]
  
  Perl's trace:
  standalone::bug_handler() called from /usr/lib/libDrakX/standalone.pm:224
  standalone::__ANON__() called from /usr/lib/libDrakX/mygtk2.pm:1212
  (eval)() called from /usr/lib/libDrakX/mygtk2.pm:1212
  mygtk2::MagicWindow::AUTOLOAD() called from /usr/lib/libDrakX/ugtk2.pm:772
  ugtk2::show() called from /usr/lib/libDrakX/ugtk2.pm:765
  ugtk2::main() called from /usr/sbin/mgaapplet-upgrade-helper:122
  main::run_gurpmi() called from /usr/sbin/mgaapplet-upgrade-helper:438
  main::upgrade() called from /usr/sbin/mgaapplet-upgrade-helper:75

Used theme: oxygen-gtk

Line 122 of /usr/sbin/mgaapplet-upgrade-helper in this version is
$succeeded_win->main and !$::testing and any::reboot();

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

CC: (none) => eeeemail

confirmed it at end of mgaonline update. (except at line 125 of mgaapplet-upgrade-helper; but that'll be because of the changes in this new iso)

donno if something necessary should be shown here... this breaks the reboot warning too...


Perl's trace:
  standalone::bug_handler() called from /usr/lib/libDrakX/standalone.pm:224
  standalone::__ANON__() called from /usr/lib/libDrakX/mygtk2.pm:1212
  (eval)() called from /usr/lib/libDrakX/mygtk2.pm:1212
  mygtk2::MagicWindow::AUTOLOAD() called from /usr/lib/libDrakX/ugtk2.pm:772
  ugtk2::show() called from /usr/lib/libDrakX/ugtk2.pm:765
  ugtk2::main() called from /usr/sbin/mgaapplet-upgrade-helper:125
  main::run_gurpmi() called from /usr/sbin/mgaapplet-upgrade-helper:442
  main::upgrade() called from /usr/sbin/mgaapplet-upgrade-helper:75

CC: (none) => alien

No we can't block the push for that one.
What's more this bug was already there with the old version.
We would need to restore old mgapplet reload code and make it reload on perl-Gtk2 upgrade (killall -USR1 mgapplet)

Blocks: 9744 => (none)

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

CC: (none) => bjarne.thomsen

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

CC: (none) => jeanjacquesbrucker

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

CC: (none) => girlando

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

CC: (none) => mbrace700

 Note that since that bug appears, the computer on which i was trying to upgrade Mageia didn't success to reboot (I don't remember were it fails exactly, and if there was some error message, but for sure, it was before any login available, kdm or ctrl+alt+F2... ).

 Then I tried to finish upgrade to Mageia 3 using the smallest non-free iso (http://www.mageia.org/fr/downloads/get/?q=Mageia-3-Boot-nonfree-x86_64-CD.iso), and upgrade fails, because of a corrupted rpmdb.

 Then I tried to install (eg. formating the root partion, keeping my /home partition) from http://www.mageia.org/fr/downloads/get/?q=Mageia-3-Boot-nonfree-x86_64-CD.iso and from http://www.mageia.org/fr/downloads/get/?q=Mageia-3-dual-CD.iso, but both fails in the same way : after installation and reboot, the kernel seems to be loaded successfully, but when systemd is launched the computer freeze (display output is stopped randomly during systemd traces) and of course before any login available, X or ctrl+alt+F2 ... F8.

 I am now trying to install with http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/iso/2/Mageia-2-dual-CD/Mageia-2-dual-CD.iso which should be the one I used to upgrade from Mandriva on my (big) laptop.

 Such upgrade problems are very annoying as I have migrated lot of unskilled users (friends, familly) from Windows to Mageia... My phone didn't ring about such issues yet, but I am afraid it may happens.

 Moreover, I have lost the BIOS password of my Notebook, and I won't be able to make it boot from an usb key if the upgrade fails (and I have only a Mageia 2 on it).

 :-(

I have been a little more lucky, in the sense that the on-line upgrade ended early, before replacing for instance the kernel. I have been able to reboot, and to access the recovery console (the normal boot hanged without any message). From the recovery console, with init=4 to access the wired internet, I performed the upgrade from the command line, as specified in the Mageia site. I received the message (which I had already seen during the graphical upgrade) that systemd.mga3.i586 could not be installed due to conflicts with the 64 bit version (my system is 64 bit). I discovered that this was caused by programs like adobe but also java that used 32 bits. I disistalled them, and proceed. I had to install some important parts of my previuos installation manually, like gdm and other GNOME programs. I finally got the graphical interface and a decently working system. With drakconf I also made some manual cleaning, upgrading various packages that still were in the Mageia 2 version. I rebooted, some parts of the gnome interface were not working, mainly because of what remained in the settings of the previous installation. But when I tried to access again drakconf, only a terminal like version, very limited, could be accessed. In addition, the root partitions were mounted as read-only, and I could not use urpmi or any other command. PANIC AGAIN ! I tried to make an upgrade of my existing installation with the installation DVD that I had downloaded on another computer, but without success. I unmounted and mounted rw the root partitions, so I could at least reinstal drakconf, but without any improvement, I finally read the message above, saying that pango may have been the culprit of the on-line upgrade. I reintalled pango with urpmi (using --replacepkg) and drakconf is working again. I am afraid to shut down the computer now.

I wrote the above in the hope it may be useful to others. Certainly the on-line upgrade need more testing before delivering, and we are a lot back in comparison with UBUNTU based systems, were the upgrade that I tested in my daughters PC always went very smootly.

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

CC: (none) => marc.maurer

Note that previous upgrade from Mageia 1 to Mageia 2 was also very smootly. This was on an other computer. Maybe (few chances but not impossible) there is also missing a configuration or package when upgrading from an installed Mageia 2 to Mageia 3 (without have upgrading Mageia 2 from Mageia 1).

Note also that the computer which fails to upgrade from Mageia 2 to Mageia 3, and after to install Mageia 3, is also a 64 bits (HP Compag 6820s).

The computer is now running back an installed Mageia 2, I am waiting for more information to try again to upgrade it (and if success to upgrade my other computers running Mageia 2).

wait... does this mean you upgraded from 32bit mageia 2 to 64bit mageia 3?

@  AL13N: no, it was (and it is back to) a 64bit mageia 2.

Though that's totally off topic regarding this bug report, such an upgrade is (painfully) possible:
- manually unpack a 64kit kernel
  (cd /; rpm2cpio /somepath/kernel*x86_64.rpm|cpio -id)
- manually running installkernel (just look at this package's
  %post scriptlet)
- reboot with this new kernel
- maybe do the same for glibc (warning! dangerous!)
- remove your urpmi media
- add the full media
- run urpmi --no-strict-arch --auto-select 

I once did it years ago (I think I'd to do more steps but I don't remember).
It's of course not supported :-)

yes, i did a similar thing once... but i just misread the statements.

the clue of this bug report is really that in our tests we had it crash only at the end...

i suspect other people who crash early might be to it breaking up in transactions and due to the internal restarts of mgaonline...

maybe this is due to having more packages installed than we had, possibly packages that are not from mageia...

sadly, i see no way to fix this at all... and it's not something that could've been avoided except for not upgrading pango at all... or coding for all possible api changes...

even in the future, such things seem only possible with some sort of rebooted upgrade... but i'm personally not in favor of such a thing and when i talked about this with noob-ish people, they didn't like that idea...

maybe there is another way...

the problems here are such that shared libraries that have already been upgraded but are modular and aren't loaded in filecache are being loaded due to something that happens... firefox/screensaver/etc...

what if we just somehow load these in filecache in advance? libraries and modular dependencies aren't really that big... and we do ask people to close all apps.

if you think about it, all the .so really just amount to maybe 500MB which is ram we could spare... we could even filecache them in some sort of ramdisk? it's not like there is alot of chance that they will be needed... ?

... or ... with some kind of snapshotting mechanism to install the new files in a hidden snapshot, so that after the upgrade(or reboot), it can be turned on in an instant.

i think with btrfs this could be possible on it's own...

at the end of updates/upgrade you get a choice, reboot now, or later, or turn on updates now...

or maybe we can patch the dl loader that it loads from a hidden archive of older .so files if the app in question is not the same as the one on disk.

when replacing old .so they could be moved into a hidden part and a kind of mapping (maybe some kind of hash?) could be used to load that one instead of the new one on disk?

at a reboot this could get cleaned (or we just use some tmpfs for this)...

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

CC: (none) => jmdutfoy

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

CC: (none) => yoshi

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

CC: (none) => jehan.marmottard

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

CC: (none) => evanlmartin

For Mageia 4, we will do offline upgrade which will prevent this bug to ever happen again.
On user confirmation, mgaapplet will download the regular installer, set up a boot entry for it (maybe in automatic mode), offer to reboot into it and voila

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

CC: (none) => crife30

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

CC: (none) => cwelbers

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

CC: (none) => sjaavaag

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

CC: (none) => nrcefe

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

CC: (none) => mageia

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

CC: (none) => ahsstd

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

CC: (none) => goetz.waschk

Obviously no longer current.

Status: NEW => RESOLVED
CC: (none) => nic
Resolution: (none) => FIXED