Bug#794742: more testing
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. 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 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? But I suspect something on the file system, isn't there something spurious to see while strace is running? You are not working on a NFS/CIFS or BTRFS filesystem? 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. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794742: more testing
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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794742: more testing
On Fri, Aug 07, 2015 at 10:33:17AM +0200, Daniel Pocock wrote: 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) There is also #757199, that is BTRFS related. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757199 Maybe you find some similarity to your behavior. Even if there is something corrupt, why can't Icedove create a new profile or give an error to explain where it is stuck? Well, that's a common problem of the main software public interesst out there. The variety of possibilities is much wider on Linux platforms than on Windows. And unfortunately Windows users are the bigger part of users. There are many many small issues living for more than five years ... And Thunderbird is just again on the way to get the problems summarized and solved after the loss of main support by the Mozilla Coorporation. We can't do much here, the code base is just too big to make anything useful in my sparse free time. Sorry, but I can't make any promisses here. 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. Could you please check if you move the profile to a normal local filesystem problems are gone? I think the behavior is more or less the same as on bug report #757199. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794742: more testing
Ok, I finally found the root cause of this problem On the NFS server, dmesg output included the line: lockd: cannot monitor host1 repeated many times. It would appear several times each time I tried to start icedove. Looking in other logs, I found that /var had filled up on the NFS server and this was causing problems for the lockd process to write in /var/lib/nfs/* There had been no other obvious signs of trouble and the lack of feedback from Icedove and the log line telling me password prompt failed or user canceled it was a distraction from spotting the real problem. So, Icedove is not specifically broken, it is just giving really inadequate feedback in the case of problems like this. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794742: more testing
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. 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 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 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
