Upon opening GNOME Activity Journal never gets past "Loading journal"

Bug #831436 reported by Pete Goodall
96
This bug affects 18 people
Affects Status Importance Assigned to Milestone
GNOME Activity Journal
Critical
Stefano Candori
gnome-activity-journal (Ubuntu)
Undecided
Manish Sinha (मनीष सिन्हा)

Bug Description

When I open GNOME Activity Journal I see a "Loading journal" message, but that message never goes away. At the bottom I see there is activity show on the graph, but it never loads in the main window. This also means I don't have access to the configuration button. In the terminal I see this message:

Using the "zeitgeist" module from /usr/lib/python2.7/dist-packages/zeitgeist
/usr/share/gnome-activity-journal/src/main.py:206: Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed
  self.show()

This is the only clue I have, but haven't found out what is causing this error (or even if it is relevant).

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gnome-activity-journal 0.8.0-1
ProcVersionSignature: Ubuntu 3.0.0-8.11-generic 3.0.1
Uname: Linux 3.0.0-8-generic x86_64
Architecture: amd64
Date: Mon Aug 22 16:51:40 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110728)
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-activity-journal
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Pete Goodall (pgoodall) wrote :
Changed in gnome-activity-journal:
importance: Undecided → High
milestone: none → 0.8.1
status: New → Confirmed
Revision history for this message
Pete Goodall (pgoodall) wrote :

So I stopped in the zeitgeist daemon (`zeitgeist-daemon --quit`), backed up my zeitgeist database (~/.local/share/zeitgeist/activity.sqlite) and deleted my zeitgeist database. Then I started zeitgeist-daemon again (`zeitgeist-daemon --replace`) and started gnome-activity-journal. Now gnome-activity-journal starts fine, but of course I have no history.

I stopped zeitgeist-daemon, restored my backup of the zeitgeist database and started zeitgeist-daemon in debug mode this time (`zeitgeist-daemon --log-level=DEBUG --replace`) and piped stdout and stderr to a file. I see the former behaviour in gnome-activity-journal (stuck at "Loading Journal") and as I watch a tail of the log file I see after about 10 seconds a bunch of dbus timeout errors.

I will attach the log file. According to zeitgeist-daemon the database is fine:

[DEBUG - zeitgeist.sql] Core schema is good. DB loaded in 1.32012367249ms

...but I'm getting dbus timeouts:

[ERROR - dbus.proxies] Introspect error on :1.316:/org/gnome/zeitgeist/monitor/1
: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not rec
eive a reply. Possible causes include: the remote application did not send a rep
ly, the message bus security policy blocked the reply, the reply timeout expired
, or the network connection was broken.
[DEBUG - dbus.proxies] Executing introspect queue due to error
[ERROR - dbus.proxies] Introspect error on :1.316:/org/gnome/zeitgeist/monitor/2
: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not rec
eive a reply. Possible causes include: the remote application did not send a rep
ly, the message bus security policy blocked the reply, the reply timeout expired
, or the network connection was broken.

That is just a sample. I get that several times in the log. Is this a problem with dbus then? Any thoughts?

Btw, this was milestoned for 0.8.1, but I'm now running 0.8.1:

$ dpkg-query -W zeitgeist*
zeitgeist 0.8.1.1-1
zeitgeist-core 0.8.1.1-1
zeitgeist-datahub 0.7.0-0ubuntu3
zeitgeist-extension-fts 0.0.7-0ubuntu2

Revision history for this message
Pete Goodall (pgoodall) wrote :
Changed in gnome-activity-journal (Ubuntu):
status: New → Confirmed
Revision history for this message
Michal Hruby (mhr3) wrote :

Could you paste the output of `dbus-monitor "sender='org.gnome.zeitgeist.Engine'" "destination='org.gnome.zeitgeist.Engine'"`? (run the command, then AJ, when it hangs press Ctrl+C in the terminal running dbus-monitor and save the output).

Revision history for this message
Pete Goodall (pgoodall) wrote :

Log file attached. I didn't restore the old db, but now that the fresh db must have some content I'm getting the same hang. Please let me know if you need a log from both the original database (with lots of content) and this database (with little content).

Revision history for this message
Greg Michalec (greg-primate) wrote :

Hey - I'm also experiencing this issue. Here is the output of the dbus-monitor command specified above (with a seemingly bad database).

Revision history for this message
Manish Sinha (मनीष सिन्हा) (manishsinha) wrote :

Surprisingly, I installed some 300MB of updates and now AJ starts working fine. Does it work for anymore after installing all latest updates?

Revision history for this message
Jorge Castro (jorge) wrote :

g-a-j works for me out of the box on an up to date oneiric (10 sep).

Revision history for this message
pablomme (pablomme) wrote :

It works for me too now.

Changed in gnome-activity-journal:
milestone: 0.8.1 → none
Revision history for this message
Jeremy Bicha (jbicha) wrote :

It does not work for me. The timeline at the bottom of the Loading screen says my activity stopped on Monday 26 September.

Revision history for this message
Manish Sinha (मनीष सिन्हा) (manishsinha) wrote : Re: [Bug 831436] Re: Upon opening GNOME Activity Journal never gets past "Loading journal"

It was working. After doing update (past beta 2) it broke again

Revision history for this message
arm-c (arickmcniel) wrote :

Same issue for me. No visible indicators for issue.

When run from command line, the following shows:

[code]
$ gnome-activity-journal
/usr/share/gnome-activity-journal/src/main.py:206: Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed
  self.show()
/usr/share/gnome-activity-journal/src/store.py:235: Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed
  while gtk.events_pending():gtk.main_iteration(False)
[/code]

Any suggestions?

Revision history for this message
Olivier R-D (olivier-roulet) wrote :

Same problem here.
I stopped zeitgeist, removed db
started zeitgeist => ~/.local/share/zeitgeist/activity.sqlite started
then worked 5 minutes

gnome-activity-jounal stalles again

Got 1 events in 0.000139s
[DEBUG - zeitgeist.engine] Where time spent in _get_event_from_row in 0.000000s
[DEBUG - zeitgeist.engine] Where time spent in _get_subject_from_row in 0.000000s
[DEBUG - zeitgeist.engine] Where time spent in apply_get_hooks in 0.000000s
[DEBUG - zeitgeist.notify] Client disconnected :1.400
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/6
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/5
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/4
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/3
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/2
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/1
[ERROR - dbus.proxies] Introspect error on :1.400:/org/gnome/zeitgeist/monitor/6: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
[DEBUG - dbus.proxies] Executing introspect queue due to error
^C[INFO - root] Shutting down Zeitgeist interface...
[DEBUG - zeitgeist.engine] Closing down the Zeitgeist engine...
[DEBUG - zeitgeist.extension] Unloading all extensions
[DEBUG - zeitgeist.extension] Unloading extension 'DataSourceRegistry'
[DEBUG - zeitgeist.extension] Unloading extension 'StorageMonitor'
[DEBUG - zeitgeist.extension] Unloading extension 'Blacklist'
[DEBUG - zeitgeist.extension] Unloading extension 'SearchEngineExtension'
[DEBUG - zeitgeist.extension] Unloading extension 'ActivityJournalExtension'

Revision history for this message
Michal Hruby (mhr3) wrote :

I finally had a chance to look into this properly, the problem is that the CairoHistogram class calls set_background on itself in the expose-event handler, which most likely pushes another synthetic expose event to the event processing queue and we get to a nice infinite loop without overflowing the stack.

I'm not sure if we just want to remove the set_background call, or move it somewhere where it won't cause havoc.
@Manish / RainCT thoughts?

Revision history for this message
Manish Sinha (मनीष सिन्हा) (manishsinha) wrote :

I got the application to run by just commenting out that line

Changed in gnome-activity-journal (Ubuntu):
assignee: nobody → Manish Sinha (मनीष सिन्हा) (manishsinha)
status: Confirmed → In Progress
Changed in gnome-activity-journal (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-activity-journal - 0.8.0-1ubuntu1

---------------
gnome-activity-journal (0.8.0-1ubuntu1) oneiric; urgency=low

  * Add patch to disable setting the background which was blocking AJ
    (LP: #831436)
 -- Manish Sinha <email address hidden> Tue, 04 Oct 2011 01:24:57 +0530

Changed in gnome-activity-journal (Ubuntu):
status: Fix Committed → Fix Released
Changed in gnome-activity-journal:
assignee: nobody → Manish Sinha (मनीष सिन्हा) (manishsinha)
importance: High → Critical
Revision history for this message
Michal Hruby (mhr3) wrote :

I just noticed today that there are more instances of setting background color inside expose event handler (in supporting_widgets.py and activity_widgets.py). Unfortunately these instances didn't cause such easily visible issue, what they do cause though is 100% cpu usage and blank pages for days when events are logged. :(

Revision history for this message
Manish Sinha (मनीष सिन्हा) (manishsinha) wrote :

Just tell me which component I should blame for this mess? I guess gdk?

I have for timebeing disabled setting of background. I guess cando can have a look at this

Changed in gnome-activity-journal:
assignee: Manish Sinha (मनीष सिन्हा) (manishsinha) → Stefano Candori (cando)
Revision history for this message
Sam_ (and-sam) wrote :

Manish, as requested in my dupe, yes it's python /usr/bin/gnome-activity-journal.

Revision history for this message
Sam_ (and-sam) wrote :

Edit some files, when finished open g-a-j, delete some event addresses, pc almost freezes, htop showed python on 98% cpu and 78 % mem. Not possible to make a screenshot of htop due to system lag, waiting a few minutes makes system responsible and numbers go down again. Zero hints in syslog, kern.log, Xorg.0.log.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers