Bug 3262 - lib64webkitgtk1.0_0 should obsolte/provides lib64webkitgtk-1.00 (drakconf.real segfaulted in webkit)
Summary: lib64webkitgtk1.0_0 should obsolte/provides lib64webkitgtk-1.00 (drakconf.rea...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard:
Keywords: Junior_job
Depends on:
Blocks:
 
Reported: 2011-11-04 12:06 CET by Jerome Quelin
Modified: 2012-02-07 16:26 CET (History)
7 users (show)

See Also:
Source RPM: webkit
CVE:
Status comment:


Attachments

Description Jerome Quelin 2011-11-04 12:06:24 CET
The "drakconf.real" program crashed. Drakbug-13.63 caught it.

just launched "drakconf", window appeared then the bug report tool opened, saying it crashed.

Backtrace was:
SEGV
standalone::bug_handler() called from /usr/lib/libDrakX/standalone.pm:220
standalone::__ANON__() called from /usr/sbin/drakconf.real:1108
(eval)() called from /usr/sbin/drakconf.real:1108

GDB backtrace was (its interesting part is below Perl_pp_fork() or Perl_pp_waitpid()):
Attaching to program: /usr/bin/perl, process 16696
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f0ac657052e in waitpid () from /lib64/libpthread.so.0
#0  0x00007f0ac657052e in waitpid () from /lib64/libpthread.so.0
#1  0x00007f0ac73011a7 in Perl_wait4pid () from /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#2  0x00007f0ac736f4c8 in Perl_pp_waitpid () from /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#3  0x00007f0ac731c7e6 in Perl_runops_standard () from /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#4  0x00007f0ac72bc1ee in perl_run () from /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE/libperl.so
#5  0x0000000000400f34 in main ()
A debugging session is active.

	Inferior 1 [process 16696] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
Kernel version = 3.1.0-desktop-2.mga2
Distribution=Mageia release 2 (Cauldron) for x86_64
CPU=Intel(R) Core(TM)2 Duo CPU     P7450  @ 2.13GHz
Comment 1 Marja Van Waes 2011-11-23 16:18:16 CET
You didn't by any chance happen to use the oxygen-gtk theme when this happened?

CC: (none) => marja11

Thierry Vignaud 2011-12-10 05:35:21 CET

Keywords: (none) => NEEDINFO
CC: (none) => thierry.vignaud

Comment 2 Jerome Quelin 2011-12-10 12:29:23 CET
i am using oxygen theme. i don't know if oxygen-gtk was in effect - how can i check?
Comment 3 Marja Van Waes 2011-12-10 13:57:21 CET
open a terminal and type 

drakbug


in cauldron this now shows the theme you are using
Comment 4 Jerome Quelin 2011-12-10 19:35:19 CET
Used theme: oxygen-gtk
Comment 5 Marja Van Waes 2011-12-10 21:33:54 CET
@ Jerome

Thanks for replying :)

This looks like a duplicate of bug 2679

Can you reproduce the crash? If you can, you could prove it isn't or is a duplicate, by doing the following:

(Copied from comment 7 and 9 in bug 2679 and adapted to this drakconf crash):

1) enable the core debug medium, then

2) install at least the following packages: gcc-debug, glibc-debug, perl-debug,
perl-Glib-debug, perl-Gtk2-debug, glib2.0-debug, gtk+2.0-debug, gdb

3) open a terminal, log in as root

4) run "killall drakconf.real; gdb -q --args perl /usr/sbin/drakconf.real"

5) type "run" 

6) once it crashed, type "bt" and copy the stack trace in a file you attach
here
Comment 6 Jerome Quelin 2011-12-12 12:58:35 CET
# killall drakconf.real; gdb -q --args perl /usr/sbin/drakconf.real
drakconf.real: no process found
Reading symbols from /usr/bin/perl...Reading symbols from /usr/lib/debug/usr/bin/perl5.14.2.debug...done.
done.
(gdb) run
Starting program: /usr/bin/perl /usr/sbin/drakconf.real
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 9784.
Detaching after fork from child process 9789.
Detaching after fork from child process 9790.
Detaching after fork from child process 9792.
[New Thread 0x7fffe7c70700 (LWP 9794)]
[New Thread 0x7fffe736f700 (LWP 9795)]
"/usr/bin/drakmenustyle" is not executable [Menus] at /usr/sbin/drakconf.real line 822.
"/usr/sbin/drakbackup" is not executable [Backups] at /usr/sbin/drakconf.real line 822.
"/usr/sbin/drakvirt" is not executable [Virtualization] at /usr/sbin/drakconf.real line 822.
"/usr/sbin/tomoyo-gui" is not executable [Tomoyo Policy] at /usr/sbin/drakconf.real line 822.
"/usr/sbin/drakguard" is not executable [Parental Controls] at /usr/sbin/drakconf.real line 822.
[New Thread 0x7fffe50ad700 (LWP 9796)]
[New Thread 0x7fffe48ac700 (LWP 9797)]
[New Thread 0x7fff9ffff700 (LWP 9798)]
[New Thread 0x7fff9f7fe700 (LWP 9799)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff69feff0 in __sigsetjmp () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff69feff0 in __sigsetjmp () from /lib64/libc.so.6
#1  0x00007fffed25089c in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#2  0x00007fffed250163 in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#3  0x00007fffed25035d in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#4  0x00007fffed7ab461 in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#5  0x00007fffed6ded3a in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#6  0x00007fffed6e7af6 in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#7  0x00007fffed7390ab in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#8  0x00007fffed72f90a in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#9  0x00007fffed25205a in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#10 0x00007fffefbd1135 in async_ready_callback_wrapper (source_object=0x7fff980022a0 [GLocalFileInputStream], res=0x1c09760, user_data=0x0) at ginputstream.c:470
#11 0x00007fffefbe2b7d in g_simple_async_result_complete (simple=0x1c09760 [GSimpleAsyncResult]) at gsimpleasyncresult.c:744
#12 0x00007fffefbe2c18 in complete_in_idle_cb_for_thread (_data=0x1c422a0) at gsimpleasyncresult.c:812
#13 0x00007ffff3f5855a in g_main_dispatch (context=0xe83ae0) at gmain.c:2513
#14 g_main_context_dispatch (context=0xe83ae0) at gmain.c:3050
#15 0x00007ffff3f58918 in g_main_context_iterate (context=0xe83ae0, block=1, dispatch=1, self=<optimized out>) at gmain.c:3121
#16 0x00007ffff3f58cfa in g_main_loop_run (loop=0x14f1ea0) at gmain.c:3315
#17 0x00007ffff08ee427 in IA__gtk_main () at gtkmain.c:1256
#18 0x00007ffff0ee8a69 in XS_Gtk2_main (my_perl=<optimized out>, cv=0xf15a78) at xs/Gtk2.xs:449
#19 0x00007ffff7b18690 in Perl_pp_entersub (my_perl=0x602010) at pp_hot.c:3046
#20 0x00007ffff7b0f7f6 in Perl_runops_standard (my_perl=0x602010) at run.c:41
#21 0x00007ffff7aaf1fe in S_run_body (oldscope=1, my_perl=0x602010) at perl.c:2350
#22 perl_run (my_perl=0x602010) at perl.c:2268
#23 0x0000000000400f34 in main (argc=2, argv=0x7fffffffe0b8, env=0x7fffffffe0d0) at perlmain.c:120
(gdb)
Comment 7 Thierry Vignaud 2011-12-12 14:30:07 CET
1) next time attach rather than paste stack traces as they got mangled
2) you obviously lack debug info for /usr/lib64/libwebkitgtk-1.0.so.0

Please attach the trace with all debug info installed.
Also what's the output of "rpm -q lib64webkitgtk1.0_0" ?

Summary: drakconf.real segfaulted => drakconf.real segfaulted in webkit
Source RPM: drakconf-12.21.9-3.mga2 => webkit

Comment 8 Jerome Quelin 2011-12-12 16:23:50 CET
i installed webkit-debug (268Mb!!) but still get the same missing information in stack trace:
#1  0x00007fffed25089c in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#2  0x00007fffed250163 in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#3  0x00007fffed25035d in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#4  0x00007fffed7ab461 in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#5  0x00007fffed6ded3a in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#6  0x00007fffed6e7af6 in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#7  0x00007fffed7390ab in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#8  0x00007fffed72f90a in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0
#9  0x00007fffed25205a in ?? () from /usr/lib/../lib64/libwebkitgtk-1.0.so.0

(thus not attaching new output which is the same)

# rpm -q lib64webkitgtk1.0_0
package lib64webkitgtk1.0_0 is not installed
# grep lib64webkitgtk /var/log/rpmpkgs
lib64webkitgtk-1.00-1.3.12-3.mga1.x86_64.rpm
lib64webkitgtk3.0_0-1.6.1-2.mga2.x86_64.rpm
Comment 9 Thierry Vignaud 2011-12-12 16:28:55 CET
I would have said that versions of of the library & the debug packages weren't synced.
But there's something fishy on your machine since lib64webkitgtk1.0_0 is the one providing /usr/lib64/libwebkitgtk-1.0.so.0
What reports "rpm -qf /usr/lib64/libwebkitgtk-1.0.so.0" ?
Comment 10 Jerome Quelin 2011-12-12 17:33:48 CET
$ rpm -qf /usr/lib64/libwebkitgtk-1.0.so.0
lib64webkitgtk-1.00-1.3.12-3.mga1
Comment 11 Thierry Vignaud 2011-12-12 19:18:17 CET
Either you misfilled the version as cauldron or you've a quite outdated machine...
Comment 12 Jerome Quelin 2011-12-13 12:16:48 CET
i do have a cauldron box, and it's updated *at least* once a week.
Comment 13 Thierry Vignaud 2011-12-13 12:31:41 CET
Then you have an issue since webkitgtk should have been updated to lib64webkitgtk1.0_0
Else there's a packaging issue preventing upgrade.
Comment 14 Jerome Quelin 2011-12-13 12:40:27 CET
i suspect a packaging issue, since i'm updating with "urpmi --auto-update", never with --keep, and my skip list is empty.
my media are: core, core32, tainted and non-free.

i'll try to install lib64webkitgtk1.0_0 manually
Comment 15 Jerome Quelin 2011-12-13 12:46:43 CET
# urpmi lib64webkitgtk1.0_0 
To satisfy dependencies, the following packages are going to be installed:
   Package                        Version      Release       Arch   
(medium "core")
  lib64javascriptcoregtk1.0_0    1.6.1        2.mga2        x86_64  
  lib64webkitgtk1.0_0            1.6.1        2.mga2        x86_64  
  webkit                         1.6.1        2.mga2        x86_64  
  webkit1.0                      1.6.1        2.mga2        x86_64  
26MB of additional disk space will be used.
5MB of packages will be retrieved.
Proceed with the installation of the 4 packages? (Y/n) ^C
# egrep ^webkit /var/log/rpmpkgs
webkit1.0-webinspector-1.6.1-2.mga2.x86_64.rpm
webkit3-1.6.1-2.mga2.x86_64.rpm
webkit3.0-1.6.1-2.mga2.x86_64.rpm
webkit3.0-webinspector-1.6.1-2.mga2.x86_64.rpm

==> what is this webkit3 package providing the same webkit 1.6.1 version? this is the problem i guess...
Comment 16 Jerome Quelin 2011-12-13 12:47:31 CET
installing webkit-1.6.1-2.mga2.x86_64.rpm webkit1.0-1.6.1-2.mga2.x86_64.rpm lib64webkitgtk1.0_0-1.6.1-2.mga2.x86_64.rpm lib64javascriptcoregtk1.0_0-1.6.1-2.mga2.x86_64.rpm from /var/cache/urpmi/rpms
Preparing...                     ##########################################################################################################################################################
Installation failed:    file /usr/lib64/libwebkitgtk-1.0.so.0 from install of lib64webkitgtk1.0_0-1:1.6.1-2.mga2.x86_64 conflicts with file from package lib64webkitgtk-1.00-1.3.12-3.mga1.x86_64
Comment 17 Jerome Quelin 2011-12-13 12:49:14 CET
# rpm -q lib64webkitgtk-1.00
lib64webkitgtk-1.00-1.3.12-3.mga1
# rpm -e lib64webkitgtk-1.00
error: Failed dependencies:
        libwebkitgtk-1.0.so.0()(64bit) is needed by (installed) perl-Gtk2-WebKit-0.90.0-3.mga2.x86_64
        libwebkitgtk-1.0.so.0()(64bit) is needed by (installed) gimp-1:2.7.3-1.mga2.x86_64

==> definitely a packaging issue for webkit libs.
Comment 18 Jerome Quelin 2012-01-10 14:37:24 CET
ok, i force removed lib64webkitgtk-1.00 and reinstalled lib64webkitgtk1.0_0:
# rpm -e --nodeps lib64webkitgtk-1.00
# urpmi lib64webkitgtk1.0_0

everything is working fine, no more segfault.
i definitely think there is a packaging error somewhere, but feel free to close the bug if you want to.
Thierry Vignaud 2012-01-10 19:20:45 CET

Summary: drakconf.real segfaulted in webkit => lib64webkitgtk1.0_0 should obsolte/provides lib64webkitgtk-1.00 (drakconf.real segfaulted in webkit)

Thierry Vignaud 2012-01-10 19:22:20 CET

Keywords: NEEDINFO => Junior_job

Comment 19 Manuel Hiebel 2012-02-06 14:14:34 CET
Any news, or closing ?
Comment 20 Marja Van Waes 2012-02-06 14:28:43 CET
(In reply to comment #19)
> Any news, or closing ?

On 2012-01-10 19:20:45 CET, Thierry changed the summary to
lib64webkitgtk1.0_0 should obsolte/provides lib64webkitgtk-1.00 (drakconf.real segfaulted in webkit)
and 2012-01-10 19:22:20 CET, he set the Junior_job keyword

cc'ing some committers

CC: (none) => dmorganec, fundawang, jani.valimaa, mageia, pterjan

Comment 21 Funda Wang 2012-02-06 14:37:58 CET
I don't know where does lib64webkitgtk-1.00 come from, and we never made 1.3.x for Mageia 1.

i.e., lib64webkitgtk-1.00 comes from a unsupported 3rd-party repository.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Comment 22 Thierry Vignaud 2012-02-06 16:38:06 CET
It doesn't.
I had the same issue and I never used a 3rd party repo

See also Bug #2024

See also "Merge with webkit3 package" (http://svnweb.mageia.org/packages/cauldron/webkit/current/SPECS/webkit.spec?revision=110401&view=markup) which suggests we'd two webkit packages at some stage, hence the issue (there was such an hint in comment #15 too).

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

Comment 23 Thierry Vignaud 2012-02-06 16:44:12 CET
Proof here: https://bugs.mageia.org/show_bug.cgi?id=383#c9
Comment 24 Funda Wang 2012-02-06 16:53:09 CET
Looking at comment#16, we never had webkit 1.3.x for released mageia 1. And we don't have any histroy against webkitgtk package :(
Comment 26 Thierry Vignaud 2012-02-06 16:59:54 CET
http://svnweb.mageia.org/packages/cauldron/webkit/current/SPECS/webkit.spec?r1=117154&r2=117789&pathrev=132796 results in bogus:

$ rpm -qp --obsoletes lib64webkitgtk1.0_0-1.7.4-1.mga2.x86_64.rpm |grep 1.00
lib64webkitgtk-1.00<=_1.3.12-3.mga1
Comment 27 Thierry Vignaud 2012-02-06 17:05:32 CET
Should be:

Obsoletes:      %{mklibname webkitgtk-1.00} <= 1.3.12-3.mga1

instead of:

Obsoletes:      %mklibname webkitgtk-1.00 <= 1.3.12-3.mga1

I'll fix that tonight if nobody does it before me

Status: REOPENED => ASSIGNED

Comment 28 Thierry Vignaud 2012-02-07 10:26:09 CET
Obsoletes tag is now fixed since this morning.
If it doesn't upgrade nicely on your machine, please reopen

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Comment 29 Marja Van Waes 2012-02-07 16:26:07 CET
changing the "assigned to" field from bugsquad to Thierry Vignaud, so he'll get the honour for fixing this bug :)

Assignee: bugsquad => thierry.vignaud


Note You need to log in before you can comment on or make changes to this bug.