remember the milk plugin causes gnome-do crashes with sigsegv

Bug #578170 reported by Nishith Nand
72
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Do Plugins
New
Undecided
Peng Deng
gnome-do-plugins (Ubuntu)
Confirmed
Undecided
Peng Deng

Bug Description

Binary package hint: gnome-do

Gnome-do crashes after a while. Here is the stack trace. It has lots of unresolved symbols I looked for a dev build but couldn't find one in the PPA.

Arch: i386
Do: 0.8.3.1
ubuntu 10.04 fully updated
Kernel: 2.6.32-22-generic #33-Ubuntu

Please let me know if you need any more information or if there is something I can do (pun unintended :D).

****************************************************************************************************************************************************************

Debug info from gdb:

[Error 14:29:58.484] [RTM] Not authorized to use a Remember The Milk account.
[Thread debugging using libthread_db enabled]
[New Thread 0x2197b70 (LWP 14390)]
[New Thread 0x5119b70 (LWP 14383)]
[New Thread 0x38bab70 (LWP 14381)]
[New Thread 0x551eb70 (LWP 14378)]
[New Thread 0x1c65b70 (LWP 14376)]
[New Thread 0x19f8b70 (LWP 14316)]
[New Thread 0x95eb70 (LWP 14313)]
[New Thread 0xb51b70 (LWP 14312)]
0x00f76422 in __kernel_vsyscall ()
  9 Thread 0xb51b70 (LWP 14312) 0x00f76422 in __kernel_vsyscall ()
  8 Thread 0x95eb70 (LWP 14313) 0x00f76422 in __kernel_vsyscall ()
  7 Thread 0x19f8b70 (LWP 14316) 0x00f76422 in __kernel_vsyscall ()
  6 Thread 0x1c65b70 (LWP 14376) 0x00f76422 in __kernel_vsyscall ()
  5 Thread 0x551eb70 (LWP 14378) 0x00f76422 in __kernel_vsyscall ()
  4 Thread 0x38bab70 (LWP 14381) 0x00f76422 in __kernel_vsyscall ()
  3 Thread 0x5119b70 (LWP 14383) 0x00f76422 in __kernel_vsyscall ()
  2 Thread 0x2197b70 (LWP 14390) 0x00f76422 in __kernel_vsyscall ()
* 1 Thread 0x1946f0 (LWP 14311) 0x00f76422 in __kernel_vsyscall ()

Thread 9 (Thread 0xb51b70 (LWP 14312)):
#0 0x00f76422 in __kernel_vsyscall ()
#1 0x00d62736 in nanosleep () at ../sysdeps/unix/syscall-template.S:82
#2 0x081a6af8 in ?? ()
#3 0x00d5a96e in start_thread (arg=0xb51b70) at pthread_create.c:300
#4 0x007d1a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 8 (Thread 0x95eb70 (LWP 14313)):
#0 0x00f76422 in __kernel_vsyscall ()
#1 0x00d61245 in sem_wait@@GLIBC_2.1 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.S:80
#2 0x0812e199 in ?? ()
#3 0x081527ea in ?? ()
#4 0x081c3062 in ?? ()
#5 0x081e1925 in ?? ()
#6 0x00d5a96e in start_thread (arg=0x95eb70) at pthread_create.c:300
#7 0x007d1a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 7 (Thread 0x19f8b70 (LWP 14316)):
#0 0x00f76422 in __kernel_vsyscall ()
#1 0x007c3b86 in *__GI___poll (fds=0x859ff4, nfds=5, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:87
#2 0x005b24eb in g_poll () from /lib/libglib-2.0.so.0
#3 0x005a50ac in ?? () from /lib/libglib-2.0.so.0
#4 0x005a5817 in g_main_loop_run () from /lib/libglib-2.0.so.0
#5 0x0153d400 in ?? () from /usr/lib/libORBit-2.so.0
#6 0x005cbdcf in ?? () from /lib/libglib-2.0.so.0
#7 0x00d5a96e in start_thread (arg=0x19f8b70) at pthread_create.c:300
#8 0x007d1a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 6 (Thread 0x1c65b70 (LWP 14376)):
#0 0x00f76422 in __kernel_vsyscall ()
#1 0x00d5f015 in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122
#2 0x081ac841 in ?? ()
#3 0x081ac8b4 in ?? ()
#4 0x081c742f in ?? ()
#5 0x0814f763 in ?? ()
#6 0x01f066d5 in ?? ()
#7 0x01f063e7 in ?? ()
#8 0x072044ce in ?? ()
#9 0x00b40509 in ?? ()
#10 0x08110ef4 in mono_runtime_delegate_invoke ()
#11 0x0815285b in ?? ()
#12 0x081c3062 in ?? ()
#13 0x081e1925 in ?? ()
#14 0x00d5a96e in start_thread (arg=0x1c65b70) at pthread_create.c:300
#15 0x007d1a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 5 (Thread 0x551eb70 (LWP 14378)):
#0 0x00f76422 in __kernel_vsyscall ()
#1 0x00d5f015 in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122
#2 0x081ac841 in ?? ()
#3 0x081ac8b4 in ?? ()
#4 0x081c742f in ?? ()
#5 0x0814dfc9 in ?? ()
#6 0x07768b20 in ?? ()
#7 0x07768a1b in ?? ()
#8 0x00ec3f2c in ?? ()
#9 0x00ebfa4a in ?? ()
#10 0x00ebeba5 in ?? ()
#11 0x07768980 in ?? ()
#12 0x077688bb in ?? ()
#13 0x07765f3c in ?? ()
#14 0x077647f2 in ?? ()
#15 0x01f0e5a8 in ?? ()
#16 0x01f0308f in ?? ()
#17 0x01f02b2a in ?? ()
#18 0x05298107 in ?? ()
#19 0x00b40509 in ?? ()
#20 0x08110ef4 in mono_runtime_delegate_invoke ()
#21 0x0815285b in ?? ()
#22 0x081c3062 in ?? ()
#23 0x081e1925 in ?? ()
#24 0x00d5a96e in start_thread (arg=0x551eb70) at pthread_create.c:300
#25 0x007d1a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 4 (Thread 0x38bab70 (LWP 14381)):
#0 0x00f76422 in __kernel_vsyscall ()
#1 0x00d5f015 in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122
#2 0x081ac841 in ?? ()
#3 0x081ac8b4 in ?? ()
#4 0x081c742f in ?? ()
#5 0x08155604 in ?? ()
#6 0x081527ea in ?? ()
#7 0x081c3062 in ?? ()
#8 0x081e1925 in ?? ()
#9 0x00d5a96e in start_thread (arg=0x38bab70) at pthread_create.c:300
#10 0x007d1a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 3 (Thread 0x5119b70 (LWP 14383)):
#0 0x00f76422 in __kernel_vsyscall ()
#1 0x007d2286 in epoll_wait () at ../sysdeps/unix/syscall-template.S:82
#2 0x08156292 in ?? ()
#3 0x081527ea in ?? ()
#4 0x081c3062 in ?? ()
#5 0x081e1925 in ?? ()
#6 0x00d5a96e in start_thread (arg=0x5119b70) at pthread_create.c:300
#7 0x007d1a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 2 (Thread 0x2197b70 (LWP 14390)):
#0 0x00f76422 in __kernel_vsyscall ()
#1 0x00d5f015 in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122
#2 0x081ac841 in ?? ()
#3 0x081ac8b4 in ?? ()
#4 0x081c742f in ?? ()
#5 0x08155604 in ?? ()
#6 0x081527ea in ?? ()
#7 0x081c3062 in ?? ()
#8 0x081e1925 in ?? ()
#9 0x00d5a96e in start_thread (arg=0x2197b70) at pthread_create.c:300
#10 0x007d1a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 1 (Thread 0x1946f0 (LWP 14311)):
#0 0x00f76422 in __kernel_vsyscall ()
#1 0x007c3b86 in *__GI___poll (fds=0x859ff4, nfds=8, timeout=3883)
    at ../sysdeps/unix/sysv/linux/poll.c:87
#2 0x005b24eb in g_poll () from /lib/libglib-2.0.so.0
#3 0x005a50ac in ?? () from /lib/libglib-2.0.so.0
#4 0x005a5817 in g_main_loop_run () from /lib/libglib-2.0.so.0
#5 0x02634299 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#6 0x068a09e0 in ?? ()
#7 0x068a09a3 in ?? ()
#8 0x00ac44bf in ?? ()
#9 0x00ac4204 in ?? ()
#10 0x08113b1e in mono_runtime_exec_main ()
#11 0x0811429a in mono_runtime_run_main ()
#12 0x080b3524 in mono_main ()
#13 0x0805ad25 in ?? ()
#14 0x0071abd6 in __libc_start_main (main=0x805ad00, argc=2,
    ubp_av=0xbf8417f4, init=0x81e6be0, fini=0x81e6bd0,
    rtld_fini=0xbd40c0 <_dl_fini>, stack_end=0xbf8417ec) at libc-start.c:226
#15 0x0805ac61 in ?? ()

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Aborted

****************************************************************************************************************************************************************

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: gnome-do 0.8.3.1+dfsg-1ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
NonfreeKernelModules: fglrx
Architecture: i386
Date: Mon May 10 14:40:02 2010
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100325)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_IN
 SHELL=/bin/bash
SourcePackage: gnome-do

Revision history for this message
Nishith Nand (nishith) wrote :
Revision history for this message
Jeremy Wilkins (jer-wilkins) wrote :

Getting this on both of my machines running Lucid and Do 0.8.3.1 (from the Lucid repos).

Typically Do crashes after less than five minutes.
Such a shame, as this is how I get things done with my machine.
Never had this problem in the 0.8.3.1 I compiled in Karmic.

Tried a fix from the Ubuntu forums:
sudo killall mono
rm -r /home/<me>/.wapi

Appeared to fix the problem for a few minutes, but that's uncertain.

Revision history for this message
Jeremy Wilkins (jer-wilkins) wrote :
Revision history for this message
Jeremy Wilkins (jer-wilkins) wrote :

Possibly related to https://bugs.launchpad.net/do/+bug/564388 ?
Both crash do with frightful regularity on both my laptop and desktop machine after installing Lucid.

Revision history for this message
Daniel (daniel123+launchpad) wrote :

Your error log gave me a hint on this. I think this might have to do with unauthorized remember the milk. I was having similar issues since upgrading to Lucid.

I authorized Remember The Milk last night and I left the machine on and there hasn't been a crash yet.

Revision history for this message
Nishith Nand (nishith) wrote : Re: [Bug 578170] Re: gnome-do crashes with sigsegv while executing native code

I tried doing that but did not work for me. I tried both authorizing it and
removing the plugin. Didn't help.

On Sat, May 15, 2010 at 8:51 PM, Daniel
<<email address hidden><daniel123%<email address hidden>>
> wrote:

> Your error log gave me a hint on this. I think this might have to do
> with unauthorized remember the milk. I was having similar issues since
> upgrading to Lucid.
>
> I authorized Remember The Milk last night and I left the machine on and
> there hasn't been a crash yet.
>
> --
> gnome-do crashes with sigsegv while executing native code
> https://bugs.launchpad.net/bugs/578170
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Nishith Nand (nishith) wrote : Re: gnome-do crashes with sigsegv while executing native code

Looks like I was mistaken, removing the "Remember the Milk" plugin does stop Gnome-Do from crashing.

summary: - gnome-do crashes with sigsegv while executing native code
+ remember the milk plugin causes gnome-do crashes with sigsegv
Peng Deng (d6g)
Changed in do:
assignee: nobody → Peng Deng (d6g)
Changed in gnome-do (Ubuntu):
assignee: nobody → Peng Deng (d6g)
Revision history for this message
Jeremy Wilkins (jer-wilkins) wrote :

Authorizing RTM appears to have resolved the issue.

Revision history for this message
Nishith Nand (nishith) wrote : Re: [Bug 578170] Re: remember the milk plugin causes gnome-do crashes with sigsegv

The authorization seems to disappear after a restart. Once Authorized, Gnome
do does not crash.

On Wed, May 19, 2010 at 11:35 PM, Jeremy Wilkins <email address hidden>wrote:

> Authorizing RTM appears to have resolved the issue.
>
> --
> remember the milk plugin causes gnome-do crashes with sigsegv
> https://bugs.launchpad.net/bugs/578170
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Peng Deng (d6g)
affects: gnome-do (Ubuntu) → gnome-do-plugins (Ubuntu)
affects: do → do-plugins
Revision history for this message
Peng Deng (d6g) wrote :

It seems this problem is related to Bug #536925, although that one is marked as "fix released" now.

The problem happens when retrieving the token (used to communicate with RTM server) from gnome keyring and it is actually beyond the plugin level.

When I modify the code to store the token in a non-secure manner (i.e. directly into gconf path), I don't see the issue. But I don't want to take the risk by leaving the token to be easily accessed.

Should we mark this bug as invalid? Since the problem is either at Do core or gnome-keyring-sharp.

Revision history for this message
Daniel (daniel123+launchpad) wrote :

Peng,

=======================
RTM plugin bug is invalid
=======================
If the bug isn't in remember the milk, then absolutely targeting the remember the milk plugin for a fix an invalid solution.

=======================
Where to file the bug
=======================
But, a new bug for gnome-do or gnome-keyring should be opened (or this bug should be modified to point to gnome-do or gnome-keyring). I'm not familiar with your code, but if it would be easy for you to make a toy program (based on remember the milk plugin code) that can directly access the gnome-keyring, then perhaps we could determine which layer is creating the error: gnome-do or gnome-keyring.

======================
Easy unit test or test case to demonstrate bug
======================
It sounds like you understand exactly what is triggering the bug. Based on that, if you could write a minimal test case (just copying and pasting code from rtm plugin code path), couldn't that make debugging and future regressions on this issue much improved?
It seems that gnome-do uses NUnit to some extent (not sure how much....). But writing a concise unit test that exploits this bug is probably the best way to prove the bug and creating the right material to have it fixed.

Thanks for all of the time you've put into fixing this issue in addition to all of the time you've put into making a great program already. Sorry to offer advice as in the above manner. But, I figure the above approach is better than just marking the issue as entirely invalid. While there is no "bug" at the remember the milk level, the issue at the higher level should be reported so that it can be remedied.

Thanks again,

Daniel

Revision history for this message
Robert Dyer (psybers) wrote :
Download full text (9.1 KiB)

The problem is with recent changes to gnome-keyring-sharp and require
modification in Do Core.

RAOF has already created a fixed branch for that issue. He is just
being lazy pushing it.

On Mon, May 24, 2010 at 6:57 AM, Peng Deng <email address hidden> wrote:
> It seems this problem is related to Bug #536925, although that one is
> marked as "fix released" now.
>
> The problem happens when retrieving the token (used to communicate with
> RTM server) from gnome keyring and it is actually beyond the plugin
> level.
>
> When I modify the code to store the token in a non-secure manner (i.e.
> directly into gconf path), I don't see the issue. But I don't want to
> take the risk by leaving the token to be easily accessed.
>
> Should we mark this bug as invalid? Since the problem is either at Do
> core or gnome-keyring-sharp.
>
> --
> remember the milk plugin causes gnome-do crashes with sigsegv
> https://bugs.launchpad.net/bugs/578170
> You received this bug notification because you are subscribed to Do
> Plugins.
>
> Status in Do Plugins Project: New
> Status in “gnome-do-plugins” package in Ubuntu: New
>
> Bug description:
> Binary package hint: gnome-do
>
> Gnome-do crashes after a while. Here is the stack trace. It has lots of unresolved symbols I looked for a dev build but couldn't find one in the PPA.
>
> Arch: i386
> Do: 0.8.3.1
> ubuntu 10.04 fully updated
> Kernel:  2.6.32-22-generic #33-Ubuntu
>
> Please let me know if you need any more information or if there is something I can do (pun unintended :D).
>
> ****************************************************************************************************************************************************************
>
> Debug info from gdb:
>
> [Error 14:29:58.484] [RTM] Not authorized to use a Remember The Milk account.
> [Thread debugging using libthread_db enabled]
> [New Thread 0x2197b70 (LWP 14390)]
> [New Thread 0x5119b70 (LWP 14383)]
> [New Thread 0x38bab70 (LWP 14381)]
> [New Thread 0x551eb70 (LWP 14378)]
> [New Thread 0x1c65b70 (LWP 14376)]
> [New Thread 0x19f8b70 (LWP 14316)]
> [New Thread 0x95eb70 (LWP 14313)]
> [New Thread 0xb51b70 (LWP 14312)]
> 0x00f76422 in __kernel_vsyscall ()
>  9 Thread 0xb51b70 (LWP 14312)  0x00f76422 in __kernel_vsyscall ()
>  8 Thread 0x95eb70 (LWP 14313)  0x00f76422 in __kernel_vsyscall ()
>  7 Thread 0x19f8b70 (LWP 14316)  0x00f76422 in __kernel_vsyscall ()
>  6 Thread 0x1c65b70 (LWP 14376)  0x00f76422 in __kernel_vsyscall ()
>  5 Thread 0x551eb70 (LWP 14378)  0x00f76422 in __kernel_vsyscall ()
>  4 Thread 0x38bab70 (LWP 14381)  0x00f76422 in __kernel_vsyscall ()
>  3 Thread 0x5119b70 (LWP 14383)  0x00f76422 in __kernel_vsyscall ()
>  2 Thread 0x2197b70 (LWP 14390)  0x00f76422 in __kernel_vsyscall ()
> * 1 Thread 0x1946f0 (LWP 14311)  0x00f76422 in __kernel_vsyscall ()
>
> Thread 9 (Thread 0xb51b70 (LWP 14312)):
> #0  0x00f76422 in __kernel_vsyscall ()
> #1  0x00d62736 in nanosleep () at ../sysdeps/unix/syscall-template.S:82
> #2  0x081a6af8 in ?? ()
> #3  0x00d5a96e in start_thread (arg=0xb51b70) at pthread_create.c:300
> #4  0x007d1a0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
>
> Thread 8 (Thread 0x95eb70 (LWP 14313)):
> #0  0x00f76...

Read more...

Revision history for this message
Daniel (daniel123+launchpad) wrote :

Do you know if there's a PPA with this fix applied?

Daniel

Revision history for this message
clockworkpc (clockworkpc) wrote :
Download full text (24.1 KiB)

Hi,

I've been getting the same problems...

I'm not sure if this debugging output adds to what you know, but I've added it just in case it's useful.
Any news on a fix?

TERMINAL OUPUT:

[Debug 13:36:44.476] [PluginManager] Loaded "RTMListItemSource" from plugin.
[Debug 13:36:44.476] [PluginManager] Loaded "RTMLocationItemSource" from plugin.
[Debug 13:36:44.476] [PluginManager] Loaded "RTMTaskItemSource" from plugin.
[Debug 13:36:44.476] [PluginManager] Loaded "RTMTagItemSource" from plugin.
[Info 13:36:44.478] [Services] Successfully located service of type AbstractApplicationService.
[Debug 13:36:44.478] [PluginManager] Loaded "InternalItemSource" from plugin.
[Debug 13:36:44.478] [PluginManager] Loaded "ItemSourceItemSource" from plugin.
[Debug 13:36:44.480] [PluginManager] Loaded "PlacesItemSource" from plugin.
[Debug 13:36:44.481] [PluginManager] Loaded "ApplicationItemSource" from plugin.
[Debug 13:36:44.482] [PluginManager] Loaded "GNOMESpecialLocationsItemSource" from plugin.
[Debug 13:36:44.482] [PluginManager] Loaded "ProfileItemSource" from plugin.
[Debug 13:36:44.483] [PluginManager] Loaded "MusicItemSource" from plugin.
[Debug 13:36:44.484] [PluginManager] Loaded "SessionCommandsItemSource" from plugin.
[Debug 13:36:44.484] [PluginManager] Loaded "ScreenshotItemSource" from plugin.
[Debug 13:36:44.517] [PluginManager] Loaded "ScreenItemSource" from plugin.

(Do:5248): Wnck-CRITICAL **: wnck_set_client_type got called multiple times.

[Info 13:36:44.543] [Services] Successfully located service of type PathsService.
[Debug 13:36:44.567] [PluginManager] Loaded "WindowItemSource" from plugin.
[Debug 13:36:44.568] [PluginManager] Loaded "EmailAction" from plugin.
[Debug 13:36:44.569] [PluginManager] Loaded "OpenAction" from plugin.
[Debug 13:36:44.573] [PluginManager] Loaded "OpenUrlAction" from plugin.
[Debug 13:36:44.574] [PluginManager] Loaded "OpenWithAction" from plugin.
[Debug 13:36:44.574] [PluginManager] Loaded "RevealAction" from plugin.
[Debug 13:36:44.574] [PluginManager] Loaded "RunAction" from plugin.
[Debug 13:36:44.575] [PluginManager] Loaded "OpenSearchAction" from plugin.
[Debug 13:36:44.575] [PluginManager] Loaded "PastebinAction" from plugin.
[Debug 13:36:44.576] [PluginManager] Loaded "DefineAction" from plugin.
[Debug 13:36:44.577] [PluginManager] Loaded "RTMAddTags" from plugin.
[Debug 13:36:44.577] [PluginManager] Loaded "RTMNewList" from plugin.
[Debug 13:36:44.577] [PluginManager] Loaded "RTMNewNote" from plugin.
[Debug 13:36:44.577] [PluginManager] Loaded "RTMNewTask" from plugin.
[Debug 13:36:44.577] [PluginManager] Loaded "RTMDeleteList" from plugin.
[Debug 13:36:44.577] [PluginManager] Loaded "RTMDeleteNote" from plugin.
[Debug 13:36:44.577] [PluginManager] Loaded "RTMDeleteTags" from plugin.
[Debug 13:36:44.578] [PluginManager] Loaded "RTMDeleteTask" from plugin.
[Debug 13:36:44.578] [PluginManager] Loaded "RTMCompleteTask" from plugin.
[Debug 13:36:44.578] [PluginManager] Loaded "RTMSetPriority" from plugin.
[Debug 13:36:44.578] [PluginManager] Loaded "RTMSetDue" from plugin.
[Debug 13:36:44.578] [PluginManager] Loaded "RTMSetUrl" from plugin.
[Debug 13:36:44.578] [PluginManager] Loaded "RTMRenameList...

Revision history for this message
plotzer (alex-ploss) wrote :

Hi,

still same authentication problem here.

Today I noticed somthing strange:
When Do runs from autostart or the app launcher, the RTM authentication token can not be accessed (though it is stored in keyring).
However, when starting Do manually from a Terminal, the token can be accessed and using RTM works well. This holds true even after re-login, or reboot.

So, instead of re-authenticating every restart, I'll go for a workaround starting Do via an "Application in Terminal" launcher.

cheers,
alex

Revision history for this message
clockworkpc (clockworkpc) wrote :

@ Alex

I've been using this workaround, but it doesn't always work for me:

See this video for an example:
http://www.youtube.com/watch?v=rRWmy7BiSTk

Revision history for this message
munddr (munddr) wrote :

I'm having the exact same problem. Is there an update to this? It is indeed quite an annoying bug...

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-do-plugins (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.