Opening "smb://14" ("14" is a workgroup name) via libsmbclient i get a 100% cpu usage. After the moving of gencache.tdb to the other directory the problem is disappear.
Created attachment 2997 [details] broken tdb file
Created attachment 2998 [details] output of libsmbclient (debuglevel=10)
Created attachment 2999 [details] libsmbclient test application
Created attachment 3000 [details] proposed patch The attached patch might solve this endless loop and replace it with "just" very high CPU load. The application should however still make progress. This patch needs further discussion, you might want to follow samba-technical@samba.org.
Volker's taken this one. It looks to be a general tdb issue rather than a problem in libsmbclient. Reassigning. (Volker, if it looks like there is also a libsmbclient problem, please let me know; otherwise I won't worry about this.) Derrell
Volker, has this been resolved? Derrell
No, I'm waiting for Tridge to give his ok with the patch. Volker
Tridge, it looks like this patch has been awaiting your approval for a year. If you get a chance, maybe you can take a look?
Tridge, re-assigning the bug to your for review. Thanks! Karolin
Re-assgning bug to Volker, as it seems he's going to implement another solution.
Ok, with http://git.samba.org/?p=samba.git;a=commitdiff;h=8a17cd810fa6c I've checked in a solution that makes gencache corruptions MUCH more unlikely. Gencache becomes a two-stage thing: One transient one without transactions and clear-if-first, and one permanent one with tdb transactions. This does not make it 100% impossible to run into a loop, but a restart of all samba/libsmbclient processes will solve it. I'm closing this as fixed, although the fix will not be in production releases before 3.5. Volker
*** Bug 4276 has been marked as a duplicate of this bug. ***