GNOME Bugzilla – Bug 662358
Tomboy often crashes (closes) on sync using Tomboy Web SyncServiceAddin
Last modified: 2017-07-31 12:48:32 UTC
I run Tomboy 1.8.0 on Xubuntu 11.10 (Installed Xubuntu-desktop on Ubuntu), and I noticed that everytime after my laptop was suspended, Tomboy crashes when I choose Search All Notes from the notification menu. $ uname -a Linux Redsandro 3.0.0-11-generic #18-Ubuntu SMP Tue Sep 13 23:38:01 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 11.10 Release: 11.10 Codename: oneiric Package: tomboy Versions: 1.8.0-1ubuntu1 (/var/lib/apt/lists/nl.archive.ubuntu.com_ubuntu_dists_oneiric_main_binary-amd64_Packages) (/var/lib/dpkg/status) Description Language: en File: /var/lib/apt/lists/nl.archive.ubuntu.com_ubuntu_dists_oneiric_main_i18n_Translation-en MD5: 0ac9b408adcee478aef231419f3a2e69 Description Language: File: /var/lib/apt/lists/nl.archive.ubuntu.com_ubuntu_dists_oneiric_main_binary-amd64_Packages MD5: 0ac9b408adcee478aef231419f3a2e69 Reverse Depends: tomboy:i386,tomboy ubuntu-sugar-remix,tomboy tomboy-latex,tomboy 0.7 tomboy-blogposter,tomboy 0.8 screenlets-pack-basic,tomboy screenlets-pack-all,tomboy gnome-applets,tomboy gnome,tomboy 1.6 ezgo-accessories,tomboy awn-applet-tomboy-applet,tomboy ubuntu-desktop,tomboy Dependencies: 1.8.0-1ubuntu1 - mono-runtime (2 2.10.1) libappindicator0.1-cil (2 0.3.91) libc6 (18 2.13) libc6.1 (18 2.13) libc0.1 (2 2.13) libdbus-glib1.0-cil (2 0.5) libdbus1.0-cil (2 0.7) libgconf2.0-cil (2 2.24.0) libglib2.0-0 (2 2.29.92) libglib2.0-cil (2 2.12.10-1ubuntu1) libgmime2.4-cil (2 2.4.4) libgtk2.0-0 (2 2.23.90) libgtk2.0-cil (2 2.12.10-1ubuntu1) libgtkspell0 (0 (null)) liblaunchpad-integration1.0-cil (2 0.1.33) libmono-addins-gui0.2-cil (2 0.6) libmono-addins0.2-cil (2 0.6) libmono-cairo4.0-cil (2 2.10.1) libmono-corlib4.0-cil (2 2.10.1) libmono-posix4.0-cil (2 2.10.1) libmono-system-core4.0-cil (2 2.10.3) libmono-system-xml4.0-cil (2 1.0) libmono-system4.0-cil (2 2.10.1) libproxy0 (2 0.2.3) gconf2 (2 2.28.1-2) libc6 (2 2.4) libx11-6 (0 (null)) evolution (0 (null)) tasque (0 (null)) tomboy:i386 (0 (null)) Provides: 1.8.0-1ubuntu1 - Reverse Provides: Package: xubuntu-desktop Versions: 2.138 (/var/lib/apt/lists/nl.archive.ubuntu.com_ubuntu_dists_oneiric_universe_binary-amd64_Packages) (/var/lib/dpkg/status) Description Language: en File: /var/lib/apt/lists/nl.archive.ubuntu.com_ubuntu_dists_oneiric_universe_i18n_Translation-en MD5: 25eeb522d88fba23a532953cbbf1638e Description Language: File: /var/lib/apt/lists/nl.archive.ubuntu.com_ubuntu_dists_oneiric_universe_binary-amd64_Packages MD5: 25eeb522d88fba23a532953cbbf1638e
I can't duplicate this. Would you mind starting tomboy with --debug and maybe something more will be done into the log.
Turns out booting, starting tomboy, suspending and waking is not enough for me to reproduce the crash either. There must be something else involved I do during an average session. I will append --debug to the 'session and startup' autostart entry for tomboy, and tail the log here when another crash occurs.
Darn, it crashed again today under similar circumstances, but there is no tomboy-debug.txt in ~. Now I manually started tomboy --debug (run dialog), and tomboy-debug.txt is not created. Is this file written on exit? If so, the crash probaby happens before it can write the file. If not, I must be doing something wrong, although not a lot can go wrong when typing 'tomboy --debug'.
Maybe this is relevant to failing to write a debug log, when running --debug from terminal: $ tomboy --debug ** Running Mono with --debug ** [DEBUG 05:53:02.861] Failed to register with session manager: org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
I think the log is just tomboy.log (even with the --debug switch) (In reply to comment #3) > Darn, it crashed again today under similar circumstances, but there is no > tomboy-debug.txt in ~. Now I manually started tomboy --debug (run dialog), and > tomboy-debug.txt is not created. Is this file written on exit? If so, the crash > probaby happens before it can write the file. If not, I must be doing something > wrong, although not a lot can go wrong when typing 'tomboy --debug'.
Tomboy crashed again, started with --debug. But there is no ~/tomboy* and no /var/log/tomboy*. Can someone be very specific about how to auto-launch tomboy with --debug (xfce) and where to find the debug logs? It seems fairly straightforward but I'm just not getting any. Debug logs I mean.
http://live.gnome.org/Tomboy/Directories Last log goes in ~/.config/tomboy/tomboy.log
D'oh! I found (older) tomboy-debug[number].txt files in ~, so I kind of assumed that was the place they hang out. Thanks for clarifying this. Unfortunately, Tomboy is kind of stick-in-the-mud about writing a new tomboy[number++].log or tomboy[timestamp].log, and prefers to use the same tomboy.log by overwriting (not appending). So I have to wait for it to crash all over again. Stay tuned!
Created attachment 201532 [details] Tomboy --debug logfile
Hello and welcome back to bug #662358 :) New crashes, new chances. I've collected the log, but nothing in the end that's hinting about an upcoming crash. I'm attaching the log. (Actually, I just posted it. Accidentally. Didn't know it would ignore what I typed, I thought they would be posted together.) It's almost as if tomboy crashes more often when you use it less. I still don't have a clue to the cause.
Whoa, just like that, a new type of possibly related bug? While my initial report was about crashing while clicking the 'search notes' option after resume from suspend, I now have a freeze after clicking a result from the searched notes. I will attach a screenshot which pretty much constrains what I just said for your convenience. Keep in mind that this freeze, the crash in my previous post which was unrelated to search, and all crashes on search are ALL after I suspended my computer at least once. Either a coincidence or a symptom, but I've never noticed a crash after a normal boot. Don't do that too often though.
Created attachment 201546 [details] Frozen search window symptom
I meant crash in stead of bug in my previous message. Again, nothing interesting in the debug log. The last lines were: 11/16/2011 3:26:32 PM [DEBUG]: Loading notebooks 11/16/2011 3:26:32 PM [DEBUG]: Object reference not set to an instance of an object 11/16/2011 3:26:43 PM [DEBUG]: Saving 'TO DO (Getting Things Done)'... 11/16/2011 3:27:42 PM [DEBUG]: Creating Buffer for 'Kladblok - Words'... That last one is the note I tried to open.
Another crash while searching, although I think this was actually because of syncing. I saw the text grey out. Tomboy survived two days. It seems Tomboy goes for weeks without crashing if I only do minor updates such as adding cake and butter to my shopping list, but when I do bigger edits, Tomboy gets quick on the crash. Attaching the log (see below)
Created attachment 201589 [details] Another tomboy debug log
And another one. After creating a bunch of lists in a note I hadn't edited for a long time. (...) 11/17/2011 2:31:01 PM [DEBUG]: Saving 'TMP'... 11/17/2011 2:31:01 PM [DEBUG]: Note saved or deleted within a minute of next autosync...resetting sync timer 11/17/2011 2:32:01 PM [DEBUG]: BackgroundSyncChecker: Checking server for updates 11/17/2011 2:32:01 PM [DEBUG]: Building web request for URL: https://one.ubuntu.com/notes/api/1.0/ 11/17/2011 2:32:01 PM [DEBUG]: Building web request for URL: https://one.ubuntu.com/notes/api/1.0/user/ 11/17/2011 2:32:02 PM [DEBUG]: BackgroundSyncChecker: Detected that sync would be a good idea now 11/17/2011 2:32:02 PM [DEBUG]: SyncThread using SyncServiceAddin: Tomboy Web 11/17/2011 2:32:02 PM [DEBUG]: SilentUI: SyncStateChanged: Connecting 11/17/2011 2:32:02 PM [DEBUG]: SilentUI: SyncStateChanged: AcquiringLock 11/17/2011 2:32:02 PM [DEBUG]: Building web request for URL: https://one.ubuntu.com/notes/api/1.0/ 11/17/2011 2:32:02 PM [DEBUG]: Building web request for URL: https://one.ubuntu.com/notes/api/1.0/user/ 11/17/2011 2:32:03 PM [DEBUG]: 8 11/17/2011 2:32:03 PM [DEBUG]: SilentUI: SyncStateChanged: PrepareDownload 11/17/2011 2:32:03 PM [DEBUG]: Sync: GetNoteUpdatesSince rev 427 11/17/2011 2:32:03 PM [DEBUG]: Building web request for URL: https://one.ubuntu.com/notes/api/1.0/op/?include_notes=true&since=427 11/17/2011 2:32:03 PM [DEBUG]: Sync: 0 updates since rev 427 11/17/2011 2:32:03 PM [DEBUG]: Building web request for URL: https://one.ubuntu.com/notes/api/1.0/op/ 11/17/2011 2:32:04 PM [DEBUG]: SilentUI: SyncStateChanged: PrepareUpload 11/17/2011 2:32:04 PM [DEBUG]: Saving 'TMP'... I'm beginning to think the initial Crash-on-search idea was a coincidence. It's mostly crash-on-sync. But only once, the next sync (on restart of Tomboy) goes fine.
This is a dup.... i'll have to find the other bug later. Its a thread issue in sync. Not sure what changed this release, but its happening way more often recently. Ubuntu users are going crazy over it :/
If I throw in a bunch of debug statements, would you be able to check this out from my GIT repo and install and test?
I would need some directions on how to do that. Replacing the default tomboy with a GIT one, while keeping my settings. I have not used GIT before.
It still happens a lot, a LOT. It often happens when there is a new note. (...) 1/22/2012 9:21:03 PM [DEBUG]: Saving 'New Note 72'... 1/22/2012 9:21:05 PM [DEBUG]: SyncThread using SyncServiceAddin: Tomboy Web 1/22/2012 9:21:05 PM [DEBUG]: Building web request for URL: https://one.ubuntu.com/notes/api/1.0/ (crashed here)
(And ignore the original bugreport... this is about syncing, not about suspending, it was all a weird coincindence.. I think. Changed the bug title.)
Agreed. (In reply to comment #21) > (And ignore the original bugreport... this is about syncing, not about > suspending, it was all a weird coincindence.. I think. Changed the bug title.)
Has there been any further progress on this issue? I'm running Tomboy 1.12.2, and tomboy rarely stays open more than half an hour or so without crashing (usually much less). (Arch Linux, Gnome 3.6.2, Tomboy 1.12.2) Is there anything I can do to help track the issue down? -Jonathan
*** Bug 690689 has been marked as a duplicate of this bug. ***
Created attachment 232215 [details] tomboy-debug.log
My bug was duped here. Just to be clear this bug is only concerting the case where Tomboy crashes/segfaults during synchronization, correct? The synchronization seems successful here, but Tomboy immediately crashes with a segfault. $ tomboy --debug > tomboy-debug.log & [1] 10974 (Tomboy:10974): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference. Native stacktrace: [1]+ Segmentation fault
(In reply to comment #26) Agreed, This is for the crash when syncing happens. Can you post the segmentation fault? It doesn't seem that the Tomboy log is catching anything useful. I think we are going to need the console output when Tomboy is manually started with --debug.
@Jared: Thanks for responding. Please see the details of comment #26. That _is_ the console output of starting Tomboy with --debug.
(In reply to comment #28) Oh boy! This is going to be fun....You can make this happen just about every time right?
On Wed, Dec 26, 2012 at 3:50 PM, Tomboy <bugzilla@gnome.org> wrote: > (In reply to comment #28) > Oh boy! This is going to be fun....You can make this happen just about every > time right? Oh boy is right! I just created, synced, deleted various test notes to and from both the system with the issue (Debian 7.0 Wheezy | Tomboy 1.10.0-2) and the system with no trouble (Ubuntu 12.04.1 LTS | Tomboy 1.10.1-0ubuntu1). Everything is working properly now. You are correct, I was able to reproduce this 100% of the time for a couple of days (approx 20-25 instances) as I tried to isolate what was triggering the segfault. It was crashing immediately after every sync. The syncing itself was always successful according to the debug log and my observations from the other client.
(In reply to comment #30) Do you want a debug build or are you comfortable running make on a custom branch that I provide?
As I am currently unable to replicate the issue, I am not sure how to proceed. I appreciate your following up on this, but I feel like I'm crying wolf. Perhaps there was some issue with the UbuntuOne servers during the time I was experiencing the problem?
@Jared, tekstr1der may not have been able to continue reproducing the issue, but I can still get it to happen fairly regularly. I'm happy to build a custom version from a debug branch that you provide if needed. I just build and installed the latest version directly from git ('master' branch), and got the below error after running for about 5 or 10 minutes. (note that the failed assertions actually happened several minutes after the last timestamp in the file) I'll attach my latest complete log of the debug stdout, but it ends with the following lines: [DEBUG 17:37:51.973] Saving 'Scratchpad'... * Assertion at mono-debug.c:462, condition `table->current_chunk->current_offset == table->current_chunk->allocated_size' not met * Assertion at exception.c:61, condition `o != NULL' not met * Assertion at exception.c:61, condition `o != NULL' not met * Assertion at exception.c:61, condition `o != NULL' not met * Assertion at exception.c:61, condition `o != NULL' not met * Assertion at exception.c:61, condition `o != NULL' not met
Created attachment 232417 [details] Latest debug stdout with failed assertion
Created attachment 232419 [details] Another debug log - no failed assertion this time Another debug output log, without any failed assertions this time. This crash happened when I was away from my computer.. so I'm not sure how long after the last timestamp until it actually crashed. (I piped both stdout and stderr to the same log this time, for a more complete log)
(In reply to comment #35) You can pull my debug branch (SyncCrash) from git@github.com:trepidity/Tomboy.git Thanks for helping track this issue down.
Created attachment 232421 [details] 2012-12-30c - With extra SyncCrash debug statements Here's my latest crash, while running a version built from your SyncCrash branch. -Jonathan
(In reply to comment #37) Nice!!! OK. Give me another day to see if I can fix the issue now. I'm fairly sure I know where it's crashing.
(In reply to comment #38) Sorry, but you need to pull from Git again. I couldn't see the cause, so I have more debug statements added. It appears to be in the WebSync Add-in though. I originally thought it was within the SyncManager.
Created attachment 232458 [details] 2013-01-01 - SyncCrash log Here's the latest crash. It refused to crash for me yesterday.. it ended up running for several hours, and I exited and restarted tomboy several times to try to get it to crash. When I exited and restarted today though, and it crashed fairly quickly. [DEBUG 10:58:03.593] GetConfiguredSyncService () [DEBUG 10:58:03.593] Creating SyncServer [DEBUG 10:58:03.593] Getting Configuration Settings Stacktrace: Is there any way I can get it to output a proper stacktrace? Do I need to add some compile flags or something?
Created attachment 232459 [details] 2013-01-01b - SyncCrash w/ stacktrace info Interestingly, I re-ran tomboy to try to ensure it's crashing in the same place every time... it looks like it is, but the crash this time contained a bunch of stacktrace information. I have no idea why it didn't show anything before but it did this time... it seems pretty random.
(In reply to comment #41) I haven't looked yet at this log, but thanks for poking me for debugging info. Doing a quick Google and a few tests, I found there is a much better way of debugging this. Try launching tomboy with these switches. mono --trace=E:all --debug Tomboy.exe >> tomboy_trace.log It should generate everything we need. Thanks to the following resources. http://www.mono-project.com/Debugging http://manpages.ubuntu.com/manpages/intrepid/man1/mcs.1.html http://stackoverflow.com/questions/12098808/mono-trace-myapp Last, but NOT least http://tirania.org/blog/archive/2010/Jul-21-1.html
It looks like support for these mono options is already available in the 'tomboy' wrapper script. I'm running the following command now, which should have the same effect: TOMBOY_DEBUG=1 TOMBOY_TRACE=E:all tomboy --debug I'll let you know when I manage to get it to crash again.
Created attachment 232460 [details] 20130101c - Crash with mono debug flags Here's the latest crash: [DEBUG 12:20:14.824] Getting Configuration Settings (Tomboy:20162): GConf-WARNING **: Got Disconnected from DBus. (Tomboy:20162): GConf-WARNING **: The connection to DBus was broken. Can't reinitialize it. [0x7ff5363ba700:] EXCEPTION handling: GLib.GException: No D-BUS daemon running Googling around a bit seems to show that a similar issue has been affecting Bashee as well, and there's some controversy over whether it's a bug in gconf itself, or just that multithreaded apps are calling gconf improperly.
Some other bug reports of interest: https://bugs.archlinux.org/task/32390 https://bugs.archlinux.org/task/32927 https://bugs.freedesktop.org/show_bug.cgi?id=54770 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694340 https://bugzilla.gnome.org/show_bug.cgi?id=688845 https://bugzilla.gnome.org/show_bug.cgi?id=683830
(In reply to comment #45) So I guess you are running Ubuntu?
No, I'm running Arch.
FWIW, I've pushed a change to the branch. I doubt it will make a difference, but if it could... Would you agree that basically this issue cannot be fixed by Tomboy?
I still get the crash even with your latest change (lazy dconf init). I've now installed the temporarily-patched version of gconf to verify that it really is the same problem.. if the crashes stop, we can be fairly sure it's the same issue that Banshee is seeing. I'm not entirely convinced that there's nothing Tomboy can do. When the Evolution team encountered the same issue, they introduced a temporary direct dbus dependancy, and called the dbus_g_thread_init() function themselves before using gconf. See https://bugzilla.gnome.org/show_bug.cgi?id=659756#c32 It's not an ideal solution, but it at least keeps Tomboy stable until you can move away from gconf or until gconf is updated to use gdbus instead of dbus.
(In reply to comment #49) See my latest push. If I read this correctly I've done what you have suggestion. Changes in Tomboy.cs
Based on a quick reading, my understanding is that dbus-sharp is a different implementation, and won't actually affect the libdbus stuff that gconf is using. I think you need an actual binding for libdbus itself, so you can call the dbus_g_thread_init() function and have it affect the libraries that gconf will be using.
(In reply to comment #51) Ug!! now you are getting outside of my abilities. I can't find any examples of what I think you are talking about. I found several code examples like what I have in there now. Would you or someone else be able to post some code snips of what I need. Has it crashed with my change in Main for Dbus.Init ()?
I used the patched gconf package yesterday, and went all day without a crash. (further proof that this is the same issue as Banshee is seeing) I then reverted back to the normal gconf package, and installed your latest version (with Dbus.Init), and it started crashing again. I don't know enough about mono development to have any idea what the actual code is that you need. On the dbus project site though, there's a page of bindings, and it includes some information about an (unmaintained) set of dbus bindings for mono. http://www.freedesktop.org/wiki/Software/DBusBindings#line-151 Notice this phrase: "For those interested in .NET support, the D-Bus Sharp implementation provides an alternative and is in active development. D-Bus Sharp is not a binding to the reference implementation, but an alternative implementation of the D-Bus protocol." Since we're not trying to actually use dbus, but trying to keep gconf's use of libdbus from crashing, another implementation won't help us... we need to actually call the libdbus function, since that's what gconf is using. I don't know if it's possible to use the (unmaintained) dbus-mono package.. or if maybe we don't need a complete set of bindings since we only need to call the one function... it may be possible to just define that one function as an external function somehow.
(In reply to comment #53) If the patch works for you, then it's unlikely we will go to far to implementing a fix. I did try to implement a piece of the dbus init code that was provided from the project you linked to. No clue if it actually will do anything, but I expect it would. Checkout commit 9eda700da4502919456e55a05ba5efbf1ca11a70 in github.com/trepidity/Tomboy/SyncCrash
(In reply to comment #53) > I don't know if it's possible to use the (unmaintained) dbus-mono package.. or > if maybe we don't need a complete set of bindings since we only need to call > the one function... it may be possible to just define that one function as an > external function somehow. dbus-mono is not just unmaintained, it's ancient and broken. dbus-sharp is the only option in Mono land right now, sorry.
The Tomboy team has moved from GNOME Bugzilla to GitHub for bug reports and feature requests: https://github.com/tomboy-notes/tomboy/issues/ Closing this report as NOTGNOME as part of Bugzilla Housekeeping (bug 781054) to keep tasks in one place. Please feel free to transfer this task to GitHub if this task is still valid in a recent Tomboy version. We are sorry for the inconvenience.