Bug 668350

Looks like a crash indeed, but it might take a bit of time to work out the crash. Can you explain *exactly* what you did to reproduce the crash please.

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

Haven't found a way to reproduce the issue.  Just looking at the corefile...

Core was generated by `/usr/sbin/packagekitd'.
Program terminated with signal 11, Segmentation fault.
#0  __pthread_mutex_lock (mutex=0x8) at pthread_mutex_lock.c:50
50	  unsigned int type = PTHREAD_MUTEX_TYPE (mutex);
(gdb) bt full
#0  __pthread_mutex_lock (mutex=0x8) at pthread_mutex_lock.c:50
        type = <value optimized out>
        id = <value optimized out>
#1  0x0000003c00c3cd1d in IA__g_main_loop_run (loop=0x1b23a70) at gmain.c:2786
        self = 0x1b0d0a0
        __PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#2  0x000000000041e966 in pk_transaction_extra_get_installed_package_for_file (extra=0x1b35340, filename=0x1b7aef0 "/usr/share/applications/kde4/kwrite.desktop") at pk-transaction-extra.c:146
        package = 0x0
        __FUNCTION__ = '\000' <repeats 51 times>
#3  0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) list
45	__pthread_mutex_lock (mutex)
46	     pthread_mutex_t *mutex;
47	{
48	  assert (sizeof (mutex->__size) >= sizeof (mutex->__data));
49	
50	  unsigned int type = PTHREAD_MUTEX_TYPE (mutex);
51	  if (__builtin_expect (type & ~PTHREAD_MUTEX_KIND_MASK_NP, 0))
52	    return __pthread_mutex_lock_full (mutex);
53	
54	  pid_t id = THREAD_GETMEM (THREAD_SELF, tid);
(gdb) p mutex
$1 = (pthread_mutex_t *) 0x8
(gdb) up
#1  0x0000003c00c3cd1d in IA__g_main_loop_run (loop=0x1b23a70) at gmain.c:2786
2786	    LOCK_CONTEXT (loop->context);
(gdb) list
2781		}
2782	
2783	      g_assert (got_ownership);
2784	    }
2785	  else
2786	    LOCK_CONTEXT (loop->context);
2787	#endif /* G_THREADS_ENABLED */ 
2788	
2789	  if (loop->context->in_check_or_prepare)
2790	    {
(gdb) p loop
$2 = (GMainLoop *) 0x1b23a70
(gdb) p loop->context
$3 = (GMainContext *) 0x0
(gdb) up
#2  0x000000000041e966 in pk_transaction_extra_get_installed_package_for_file (extra=0x1b35340, filename=0x1b7aef0 "/usr/share/applications/kde4/kwrite.desktop") at pk-transaction-extra.c:146
146		g_main_loop_run (extra->priv->loop);
(gdb) list
141			g_ptr_array_remove_range (extra->priv->list, 0, extra->priv->list->len);
142		pk_backend_reset (extra->priv->backend);
143		pk_backend_search_file (extra->priv->backend, pk_bitfield_value (PK_FILTER_ENUM_INSTALLED), filename);
144	
145		/* wait for finished */
146		g_main_loop_run (extra->priv->loop);
147	
148		/* check that we only matched one package */
149		if (extra->priv->list->len != 1) {
150			egg_warning ("not correct size, %i", extra->priv->list->len);
(gdb) p extra
$4 = 0x1b35340
(gdb) p extra->priv
$5 = (PkTransactionExtraPrivate *) 0x1b35360
(gdb) p extra->priv->loop
$6 = (GMainLoop *) 0x1b23a70
(gdb) p extra->priv->loop->context
$7 = (GMainContext *) 0x0
(gdb) 

Hmm, what is an extra->priv->loop->context?

(In reply to comment #8)
> Hmm, what is an extra->priv->loop->context?

In PACKAGEKIT_0_7_X we split up the different "extra" actions up into separate plugins. A plugin might be something like "update the icon database after installing a program" which might be run after any InstallPackage command.

Prior to the plugin change, we had this ugly thing called PkTransactionExtra which would be used by PkTransaction before and after a transaction. The way it was designed to work was that you would run the normal transaction which started the backend, and then did some other transaction when the backend finished. The "extra" step worked by hijacking the main loop inbetween the real transaction finishing and the plugin action starting. This meant we could delay the main transaction before we released control of the backend.

Now, we only create the extra mainloop in PkTransactionExtra::init and only destroy it in PkTransactionExtra::finalize, so we should always have a good extra mainloop to use in the program. Similarly, we only create PkTransactionExtra in PkTransaction::init and unref it in PkTransaction::finalize, so the extra helper is always present for the lifetime of the transaction.

For me to work out what's happening we need to look at the packagekitd verbose log. To get this we need to do (as root):

killall packagekitd
gdb /usr/sbin/packagekitd
r --verbose --disable-timer --backend=yum

then make it crash by using another terminal:

pkcon refresh

Now, saying all that, I can't actually make the daemon crash under those conditions. If you can, then please do:

bt

and upload the backtrace to this bug and *also* the complete log from packagekitd (the lines that starts TI:...) which will let me work out what's going wrong. Telling me what you did to cause it (e.g. "I ran pkcon refresh 48 times in a loop whilst the CPU was at 100%") Thanks.

Richard.

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

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

When you mark bugs as duplicate, why are you using a private one to track progress? This way other parties can just guess what's (not) going on...

@martin

We asked for FJ to be added to 743399 but as it contains HP commercial information so we were unable to.

I opened case 00646972 to publish any useful information from 743399 but have not had an opportunity to manually copy across the good bits. I'll do that asap today.

I was just wondering why this public bug wasn't used as master tracker for this problem, as it's obviously older than its duplicates. As you know, the FJ BZ is bug 738137.

The problem has been observed again under RHEL6.5.

Martin, I would vote for 
- reopening of bz743399, if we are sufficiently sure that this is the same issue
- opening a new bz, and in "additional info" hinting at poassible relation to bz743399

As mentioned earlier, I have no access to bz743399 and thus can't judge whether or not it's the same issue.

Sorry, indeed. Applying for FJ to access bz743399.

We got bz743399 reopened and Fujitsu group added.  Lets work on the issue there, i.e. upload a new application coredump which might exist.