Infinite loop while checking the state of the current WC?

[patrick.allaert]

When I am into a repository using Konqueror and switch on the kdesvn kpart view kdesvn begins to check the status and sometimes it seems to enter an infinite loop and continuously print: "Still checking for updates" until hanging. My only choice then is to kill Konqueror.

kdesvn build from SVN against r1275.

[alwin]

And opening the same in kdesvn itself?

[patrick.allaert]

I also have this problem using directly kdesvn.

Note that it is not perfectly reproducible but still happens in 70% of the cases on WC having this problems.

Note that the "Still checking for updates" is not always shown. I just successfully crashed kdesvn and last (french) messages was:

État externe /home/...
484 Byte sur 484 Byte transférés.
484 Byte sur 484 Byte transférés.

To isolate the problem I tried entering directly into a subdirectory NOT having an svn:externals (as shown in the output) and it fails also with:

Vérification de mises à jour démarrées en tâche de fond
300 Byte sur 300 Byte transférés.
484 Byte sur 484 Byte transférés.
484 Byte sur 484 Byte transférés.
Vérification de mises à jour en cours
Vérification de mises à jour en cours
[...]
Vérification de mises à jour en cours
Vérification de mises à jour en cours

In this last case kdesvn did not froze. When it frozes, I don't remember seeing the first "Vérification de mises à jour en cours" (="Still checking for updates").

Note also that my WC does not contain changes but is not up-to-date! Don't know if it helps.

[alwin]

hm. I'll try to implement some extra checking messages, but sounds a little bit strange (and like a network problem)

[m-a-g@…]

I have this problem to message repeat - "Still checking for updates"

I check the svn server - they working.

[test@…]

I did not have this problem in Kubuntu 7.04 but after update (correction: new install) to/of gutsy (7.10) I get this even though my HDD with the files is exactly the same (this tells me it is not a filesystem thing). This happens both for new and old (already present repositories).

While it is looping I can not do anything SVN-related so this bug renders my kdesvn totally unusable.

My kdesvn version is 0.12.1-1 in Kubuntu Gutsy, don't remember the version in my old install sorry.

[test@…]

Just updated to 0.14.1-1 by downloading source and compiling. Still getting the error after update. This is what I get:

Update /home/username/TR/TR_DBD Update complete /home/username/TR/TR_DBD (Rev 9296) Checking for updates started in background Finished '/home/username' is not a working copy Can't open file '/home/username/.svn/entries': No such file or directory 300 Byte of 300 Byte transferred. 526 Byte of 526 Byte transferred. 526 Byte of 526 Byte transferred. Still checking for updates Still checking for updates etc..

Why does it look for /home/username/.svn/entries ????? I checked it out to /home/username/TR/TR_DBD as you probably understand from the output above.

Ohh yeah, I'm on amd64 running KDE 3.5.8.

[test@…]

By going to "Configure kdesvn" => "Subversion" and unchecking "Start check for updates when open a working copy" I can use kdesvn eventhough it is a bit annoying :) to be without the auto-updates. I still get this message:

'/home/username' is not a working copy Can't open file '/home/username/.svn/entries': No such file or directory

when I open a working copy or press F5 for refresh.

[test@…]

Sorry for spamming you but I'm guessing you need as much info as possible and I haven't reported a bug before. If I start a debug-version of kdesvn from a console window this is what I get in the console together with the above state info in the application window:

kdesvn: WARNING: KXMLGUIClient::setXMLFile: cannot find .rc file kdesvnui.rc
kdesvn: Appname = kdesvn
kdesvn: WARNING: KXMLGUIClient::setXMLFile: cannot find .rc file kdesvn_part.rc
kdesvn: WARNING: KXMLGUIClient::setXMLFile: cannot find .rc file kdesvnui.rc
kdesvn: Enable update
kdesvn: Create cache for /home/username/TR/TR_DBD
kdesvn: ModifiedThread? seems stopped
Very strange! got a DCOPReplyWait opcode, but we were not waiting for a reply[[BR]] Very strange! got a DCOPReplyDelayed opcode, but we were not waiting for a reply[[BR]]

Yeah, also, sorry for the bad formating in the previous two posts.

[test@…]

I also wanted to mention that if "Start check for updates when open a working copy" IS checked I do get this error about 90% of the times I start kdesvn and go directly to open my repository, not 100% of the times.

All the times when I get the "Still checking for updates" and press the "x" in the upper right corner to close the program, the program window goes away but is followed by a crash if I close it within the first five "Still checking..." messages or so. The crash (signal 11) has the following backtrace (from debug executable):

Using host libthread_db library "/lib/libthread_db.so.1".

[Thread debugging using libthread_db enabled]

[New Thread 46982549562112 (LWP 17711)]

[KCrash handler]

#5 0x00002abaf3926b4e in operator>> () from /usr/lib/libqt-mt.so.3

#6 0x00002abaf58f386b in ?? () from /usr/lib/libDCOP.so.4

#7 0x00002abaf5901b98 in KDE_IceProcessMessages () from /usr/lib/libDCOP.so.4

#8 0x00002abaf58ef4cb in DCOPClient::callInternal ()

from /usr/lib/libDCOP.so.4

#9 0x00002abaf58ef7c9 in DCOPClient::callInternal ()

from /usr/lib/libDCOP.so.4

#10 0x00002abaf58f3cf8 in DCOPClient::call () from /usr/lib/libDCOP.so.4 #11 0x00002abaf58f3d23 in DCOPClient::call () from /usr/lib/libDCOP.so.4 #12 0x00002abaf58f3eee in DCOPClient::disconnectDCOPSignal ()

from /usr/lib/libDCOP.so.4

#13 0x00002abaf58f47b1 in DCOPObject::~DCOPObject ()

from /usr/lib/libDCOP.so.4

#14 0x00002abaf5db9b6b in KBookmarkManager::~KBookmarkManager ()

from /usr/lib/libkio.so.4

#15 0x00002abaf393cc9e in QGList::clear () from /usr/lib/libqt-mt.so.3 #16 0x00002abaf5dd56b7 in QPtrList<KBookmarkManager>::~QPtrList ()

from /usr/lib/libkio.so.4

#17 0x00002abaf5dd4c3f in KStaticDeleter<QPtrList<KBookmarkManager> >::destructObject () from /usr/lib/libkio.so.4 #18 0x00002abaf4ce2643 in KGlobal::deleteStaticDeleters ()

from /usr/lib/libkdecore.so.4

#19 0x00002abaf4d6544b in KApplication::~KApplication ()

from /usr/lib/libkdecore.so.4

#20 0x000000000040c614 in main (argc=1, argv=0x7fffb7aa8168)

at /home/frevi645/kdesvn/kdesvn-0.14.1/src/main.cpp:96

[alwin]

Sure that it isn't a kde problem? 'Cause it crashes in KDE stuff, not my. And dcop isn't used by kdesvn normaly.

I have not the right cpu to install a 64bit kubuntu into vmware, but I'll see if I can check it anywhere.

[anonymous]

As a workaround:

Put

ksvn+file:/

instead of

file://

in front of the path of the repository.
Or open the repository in Kdesvn and then click Subversion > Repository > Check out current repository-path. The "ksvn+file:/" should now be prepened to the path of the working directory. Otherwhise the dialogue should be the same as in Subversion > Common > Checkout a repository.

[test@…]

Hi Alvin and "anonymous"

Alvin: No I'm not sure of that, however I am inclined to say that you are right its just that I am really new on this so I don't trust myself on such calls so I just wanted to forward the information. I'll install the 32-bit version of Kubuntu in VMware and see if I get the same error.

anonymous: I will give what you state a try, thanks!

[alwin]

Replying to test@plz_remove_spam_last_also@test.viksten.nu@this.place.no:

Hi Alvin and "anonymous"

Alvin: No I'm not sure of that, however I am inclined to say that you are right its just that I am really new on this so I don't trust myself on such calls so I just wanted to forward the information. I'll install the 32-bit version of Kubuntu in VMware and see if I get the same error.

anonymous: I will give what you state a try, thanks!

Ok, I'll try a 32bit kubuntu next time.

[patrick.schoenmann@…]

I have the same problem on launching kdesvn...

Checking for updates started in background
300 Byte of 300 Byte transferred.
401 Byte of 401 Byte transferred.
401 Byte of 401 Byte transferred.
Still checking for updates
Still checking for updates
Still checking for updates
Still checking for updates
etc...

Actually, it manages to get the 3 first updates successfully, THEN asks for my KDEWallet password and that's where it begins to get stuck. Timeout issue?

Killing kdesvn, performing a cleaning from a shell by typing "svn cleanup", and then starting kdesvn again usually solves the problem.

[Stefan Blasi]

I have found the problem why there is an infinite loop. It seems to be an incompatibility between KDESVN and KDE Wallet. The infinite loop occurs because because getting username and password from KDE Wallet fails!

Following workaround should solve this issue:

1. Start Kdesvn as root
2. Go to the kdesvn settings
3. At tab svn: disable the option "store passwords into KDE wallet".

Now kdesvn saves your username and password self!

[Stefan Blasi]

I have forgotten an important detail: You have to start kdesvn always as root! Because the user defined settings are only used as root user! In my opinion is this another bug of kdesvn.

[alwin]

Replying to Stefan Blasi:

I have forgotten an important detail: You have to start kdesvn always as root!

?????? I use kdesvn always as normal user, what you describing here sounds more like a problem with your system, you may check if there are folders/files within the .kde - folder owned by root and only writeable/readable by user root. And I'm sure if kdesvn only could run as user root I had got more then one ticket about.

So check your system. Anyway the part about not getting password from kwallet I'll check, but this works here (and on other system) perfect.

[sgt-schnitzel]

Sorry, I don't think that it's a problem with the system of Mr. Blasi. I've got exactly the same problem an there are no files owned by root in my .kde directory. Moreover I am using a newly installed system (one week old, every single setting as it came out of the box).

Let's say that you don't have to run kdesvn as root, but the problem of the infinite loop can be solved by doing so. Strange enough, uhmm?

So what's the "real" solution?

[anonymous]

Replying to alwin:

Replying to Stefan Blasi:

I have forgotten an important detail: You have to start kdesvn always as root!

?????? I use kdesvn always as normal user, what you describing here sounds more like a problem with your system, you may check if there are folders/files within the .kde - folder owned by root and only writeable/readable by user root. And I'm sure if kdesvn only could run as user root I had got more then one ticket about.

So check your system. Anyway the part about not getting password from kwallet I'll check, but this works here (and on other system) perfect.

[anonymous]

First sorry about the post above!

There is definitly no problem with my system. I have checked the access rights of my .kde files and folders and they are all owned by normal user ( read and write permission )! Furthermore i have reinstalled kdesvn today and the problem still exists. And by the way: I'm not the only one with this problem!

[alwin]

Which problem? Not able using kdesvn as normal user or the endless loop when not opening kwallet?

the last one I try to search a reason for, but the first (kdesvn only as root) make simply no sense to me. And here - and elsewhere - works fine as normal user.

[noirsoldats]

Replying to alwin:

Which problem? Not able using kdesvn as normal user or the endless loop when not opening kwallet?

the last one I try to search a reason for, but the first (kdesvn only as root) make simply no sense to me. And here - and elsewhere - works fine as normal user.

Alwin, what you are viewing as two problems are not two seperate problems but a single problem and the way one person has found around it. The ultimate problem for this infinate loop is the way KDESVN is attempting to access the KWallet and failing repeatedly without erroring. The KDESVN only as room was a solution to this by turning KDESVN's useage of KWallet off on the root account and then only using KDESVN ran under root.

The same 'fix' works even for my normal non-root user.. Turning off KDESVN's use of KWallet in the config and forcing it to store the passwords itself works beautifully.

[alwin]

Replying to noirsoldats: Ah!

you're meaning it is 'cause the background process isn't able open the kdewallet while checking for updates?

[alwin]

I found an error which I'd fixed in r1436 - may you try it?

[alwin]

Ok tried something more in r1447 which seems fixing the kwallet problem.

[zexpe]

Replying to alwin:

Ok tried something more in r1447 which seems fixing the kwallet problem.

I had this exact same problem in a fresh install of Kubuntu Hardy - KDESVN v0.14.1.

So I uninstalled v0.14.1, downloaded the v0.14.6 source code, compiled and installed to /usr/local... and had the same problem.

I can confirm that forcing KDESVN to not use the KDE Wallet for storing passwords works for me - I deselected that default option, reopened KDESVN and at first it didn't work, but then I forced an update which brought up the user name and password dialogue, with a note that the password would be stored in KDESVN simple storage. Subsequent checks for updates now work.

[zexpe]

If the default option was to not use KDE wallet this bug would be less of a problem.

[alwin]

Know, there were a problem left which will get fixed next bigger release next days.