On 07/08/15 09:20, Carsten Schoenert wrote: > Hello Daniel, > > On Thu, Aug 06, 2015 at 06:24:22PM +0200, Daniel Pocock wrote: >> I did some more tests >> >> I moved the following to a backup location: >> ~/.icedove >> ~/.thunderbird >> ~/.cache/icedove >> >> so it should create a completely new profile. > ~/.thunderbird is completely unrelated to Debian's Icedove, this comes > from something different. > The cached files should be safe, but it's no problem to move them out of > the way. >
I moved it out of the way just in case, it had been there a long time >> Then I run it in safe mode to avoid any plugins: >> >> $ icedove -safe-mode >> >> The main window appears but it is unresponsive to any mouse clicks on >> any of the buttons or menus. I looked for any modal popup windows or >> dialogs that may have blocked mouse clicks on the main window but I >> couldn't find any. > I have currently absolutely no clue what could be going wrong here. > The diff between 31.7.0 and 31.8.0 is not spectacul and I can't really > believe that Mozilla has something broken by this update. You are the > currently first and only person that reports such strange working mode. I'm not certain that it was brought about by the upgrade or some other issue >> I attach a screenshot. The console output is: >> >> $ icedove -safe-mode >> >> (process:7319): GLib-CRITICAL **: g_slice_set_config: assertion >> 'sys_page_size == 0' failed >> TypeError: nounDef is undefined >> -- Exception object -- >> * >> -- Stack Trace -- >> gloda_ns_newQuery@resource:///modules/gloda/gloda.js:1897:5 >> ContactIdentityCompleter@resource://gre/components/glautocomp.js:178:7 >> nsAutoCompleteGloda@resource://gre/components/glautocomp.js:493:5 >> XPCOMUtils__getFactory/factory.createInstance@resource://gre/modules/XPCOMUtils.jsm:271:11 >> glodaSearch_XBL_Constructor@chrome://messenger/content/search.xml:75:1 > This messages on the console are quite a good sign as they are small. > As you wrote you have created a completely new profile thre must be > something different. The last time I saw such behavior was by using the > upstream Lightning package and not the iceowl-extension package, but > this is irrelevant here, you are running a new profile. > Could remove the various plugins via apt-get remove (or similar) to > figure out if probably some plugins are ignoring the safe mode? I tried removing two extensions that were installed as packages: xul-ext-tbdialout iceowl-extension and this didn't resolve the issue > But I suspect something on the file system, isn't there something spurious to > see while strace is running? I haven't gone through the strace output in great detail yet > You are not working on a NFS/CIFS or BTRFS filesystem? It is a BtrFs filesystem accessed over NFS It has been working this way for a long time I checked the BtrFs filesystem and it definitely has free space and free metadata space (I understand there can be problems when these fill up and people don't realize it) Even if there is something corrupt, why can't Icedove create a new profile or give an error to explain where it is stuck? > Happen this all on a new profile if you using the older version 31.7.0 > from snapshots.d.o. > > In version 31.8.0 we have to use the internal libnss library as the > Jessie version is now to old. > >> I used strace to capture all activity during startup and tried to work >> out what else it may have been looking for in $HOME. There were over >> 1500 references to distinct files in $HOME > What files? > That confirms my minds that the file system could be corrupted. > Let me see if there is a way to summarize what it is trying to access In some cases it is trying to access things which don't exist, e.g. searching for a particular file in various places. Some of these accesses to $HOME appear to be from libraries rather than Icedove itself. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
