Okay, I didn't get any reply to my previous post (see below). The issue has now taken on a new element.
I have confirmed what appears to be a race condition with multiple IMAP connections to UW-IMAP that occurs when a user is logged in to rcmail and begins to download a large attachment. If the attachment doesn't complete its download sequence before the next scheduled check (1, 3, or 5 min) for new mail, the subsequent login to the IMAP Server causes UW-IMAP to kill the process that is downloading the attachment in favor of the new login connection. Here is a maillog example:
Sep 15 16:35:08 jwhatley imapd[70218]: Login user=jwhatley host=xxxxx.net [174.xxx.xxx.xxx] Sep 15 16:35:08 jwhatley imapd[70167]: Killed (lost mailbox lock) user=jwhatley host=xxxxx.net [174.xxx.xxx.xxx]
I understand that UW-IMAP is old and that we should consider replacing with Dovecot or Courier, but I would like to explore the issue before initiating such a recommendation.
I would really appreciate some feedback on this issue. Someone, perhaps Alec, could give me some guidance?
More specifically and in the interim, I need to know where in the code to change the option 1, 3, 5 minute(s) so that I can increase the maximum available time between checking for new mail. Or, in the alternative, is there any provision within the code for suspending checks while attachments are being downloaded?
Thank you all in advance for any assistance you can render.
Regards,
Jake Whatley
From: Jacob Whatley [mailto:jwhatley@rhyton.com] Sent: Thursday, September 09, 2010 11:34 AM To: 'dev@lists.roundcube.net' Subject: Revisiting ancient issue - Apache2 100% CPU when competing for UW-IMAP
I saw that this issue was identified and confirmed in 2008, but I was wondering if anyone had any further information on preventing 100% CPU processes in Apache2 when RCM loses the fight between competing connections to UW-IMAP (having RCM open while Outlook is also open and checking mail).
We have a system in place to kill these resource hogs, but I want to see if anyone has a better solution, aside from dumping UW-IMAP.
Thanks!
Jacob Whatley
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 16.09.2010 04:31, Jacob Whatley wrote:
I have confirmed what appears to be a race condition with multiple IMAP connections to UW-IMAP that occurs when a user is logged in to rcmail and begins to download a large attachment. If the attachment doesn't complete its download sequence before the next scheduled check (1, 3, or 5 min) for new mail, the subsequent login to the IMAP Server causes UW-IMAP to kill the process that is downloading the attachment in favor of the new login connection. Here is a maillog example:
If this is really the issue you could try with imapproxy. There're other places where concurent connections may happen. In neither way connection dropping shouldn't hang apache process. If so, I don't think we'll find a solution.
I understand that UW-IMAP is old and that we should consider replacing with Dovecot or Courier, but I would like to explore the issue before initiating such a recommendation.
More specifically and in the interim, I need to know where in the code to change the option 1, 3, 5 minute(s) so that I can increase the maximum available time between checking for new mail.
The time for checking you can set in Preferences/Mailbox View, you can set it up to 30 minutes. For testing use imap_debug option, log from imap conversation maybe helpful.
Thank you very much for your reply, Alek.
In neither way connection dropping shouldn't hang apache process. If so, I don't think we'll find a solution.
I was afraid that. If you don't mind, could I get your opinion on the best IMAP server for use in a Virtual Hosting (FreeBSD jail) environment. Hopefully one that will not change our existing /var/mail/<user> and /usr/home/<user> configuration.
The time for checking you can set in Preferences/Mailbox View, you can set it up to 30 minutes.
Sorry, but on 0.4 production here are the only options in preferences:
http://i822.photobucket.com/albums/zz149/Grymes_z/images/rc-preferences.jpg
I am not in a position where I can push a completely new build of rcmail, as it is in production and being used on thousands of servers at this time. However, I can make minor changes to files in the skel, such as adding an additional option for higher than the 5 minutes currently available.
For testing use imap_debug option, log from imap conversation maybe helpful.
I will do this on a test server, but I think you are correct about what we will find about hung apache.
I appreciate all that you do for this project!
Regards,
Jake
-----Original Message----- From: dev-bounces+jwhatley=rhyton.com@lists.roundcube.net [mailto:dev-bounces+jwhatley=rhyton.com@lists.roundcube.net] On Behalf Of A.L.E.C Sent: Thursday, September 16, 2010 2:12 AM To: dev@lists.roundcube.net Subject: Re: [RCD] Revisiting ancient issue - Apache2 100% CPU when competing for UW-IMAP
On 16.09.2010 04:31, Jacob Whatley wrote:
I have confirmed what appears to be a race condition with multiple IMAP connections to UW-IMAP that occurs when a user is logged in to rcmail and begins to download a large attachment. If the attachment doesn't complete its download sequence before the next scheduled check (1, 3, or 5 min) for new mail, the subsequent login to the IMAP Server causes UW-IMAP to kill
the
process that is downloading the attachment in favor of the new login connection. Here is a maillog example:
If this is really the issue you could try with imapproxy. There're other places where concurent connections may happen. In neither way connection dropping shouldn't hang apache process. If so, I don't think we'll find a solution.
I understand that UW-IMAP is old and that we should consider replacing
with
Dovecot or Courier, but I would like to explore the issue before
initiating
such a recommendation.
More specifically and in the interim, I need to know where in the code to change the option 1, 3, 5 minute(s) so that I can increase the maximum available time between checking for new mail.
The time for checking you can set in Preferences/Mailbox View, you can set it up to 30 minutes. For testing use imap_debug option, log from imap conversation maybe helpful.
On 16.09.2010 08:48, Jacob Whatley wrote:
I was afraid that. If you don't mind, could I get your opinion on the best IMAP server for use in a Virtual Hosting (FreeBSD jail) environment. Hopefully one that will not change our existing /var/mail/<user> and /usr/home/<user> configuration.
I'm not a guru in this, but from the other opinions Dovecot 1.2 is a good choice. The change will probably require some migration procedure.
http://wiki.dovecot.org/Migration/UW
The time for checking you can set in Preferences/Mailbox View, you can set it up to 30 minutes.
Sorry, but on 0.4 production here are the only options in preferences:
http://i822.photobucket.com/albums/zz149/Grymes_z/images/rc-preferences.jpg
You need to increase session_lifetime first.
I am not in a position where I can push a completely new build of rcmail, as it is in production and being used on thousands of servers at this time. However, I can make minor changes to files in the skel, such as adding an additional option for higher than the 5 minutes currently available.
Just install it in separate directory and connect with the same database.
I started using Roundcube in production 2 years ago. I ran Roundcube in different servers, and different installations. All of them with Dovecot as imap proxy. All of them with Apache processes using 100% CPU, whole day ( some minutes of interval between the hung processes), and this processes never die. I only see this problem Roundcube+Apache combination. I used several versions of PHP and didn't found the solution. My workaround was create an script to kill all apache processes that is using all the CPU.
Emerson Pinter
On Thu, 16 Sep 2010 08:56:40 +0200, "A.L.E.C" alec@alec.pl wrote:
On 16.09.2010 08:48, Jacob Whatley wrote:
I was afraid that. If you don't mind, could I get your opinion on the best IMAP server for use in a Virtual Hosting (FreeBSD jail) environment. Hopefully one that will not change our existing /var/mail/<user> and /usr/home/<user> configuration.
I'm not a guru in this, but from the other opinions Dovecot 1.2 is a good choice. The change will probably require some migration procedure.
http://wiki.dovecot.org/Migration/UW
The time for checking you can set in Preferences/Mailbox View, you can set it up to 30 minutes.
Sorry, but on 0.4 production here are the only options in preferences:
http://i822.photobucket.com/albums/zz149/Grymes_z/images/rc-preferences.jpg
You need to increase session_lifetime first.
I am not in a position where I can push a completely new build of rcmail, as it is in production and being used on thousands of servers at this time. However, I can make minor changes to files in the skel, such as adding an additional option for higher than the 5 minutes currently available.
Just install it in separate directory and connect with the same database.
List info: http://lists.roundcube.net/dev/ BT/aba52c80
For a record: I am using courier-imap, and I too have this problem from time to time (e.g. now). So it's definately not UW's fault. I think when I googled for it, it appeared to be a bug in PHP, isn't it?
Rimas
2010.09.16 15:35, Emerson Pinter rašė:
I started using Roundcube in production 2 years ago. I ran Roundcube in different servers, and different installations. All of them with Dovecot as imap proxy. All of them with Apache processes using 100% CPU, whole day ( some minutes of interval between the hung processes), and this processes never die. I only see this problem Roundcube+Apache combination. I used several versions of PHP and didn't found the solution. My workaround was create an script to kill all apache processes that is using all the CPU.
Emerson Pinter
On Thu, 16 Sep 2010 08:56:40 +0200, "A.L.E.C" alec@alec.pl wrote:
On 16.09.2010 08:48, Jacob Whatley wrote:
I was afraid that. If you don't mind, could I get your opinion on the best IMAP server for use in a Virtual Hosting (FreeBSD jail) environment. Hopefully one that will not change our existing /var/mail/<user> and /usr/home/<user> configuration.
I'm not a guru in this, but from the other opinions Dovecot 1.2 is a good choice. The change will probably require some migration procedure.
http://wiki.dovecot.org/Migration/UW
The time for checking you can set in Preferences/Mailbox View, you can set it up to 30 minutes.
Sorry, but on 0.4 production here are the only options in preferences:
http://i822.photobucket.com/albums/zz149/Grymes_z/images/rc-preferences.jpg
You need to increase session_lifetime first.
I am not in a position where I can push a completely new build of rcmail, as it is in production and being used on thousands of servers at this time. However, I can make minor changes to files in the skel, such as adding an additional option for higher than the 5 minutes currently available.
Just install it in separate directory and connect with the same database.
List info: http://lists.roundcube.net/dev/ BT/31bb9d8c
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 17.09.2010 10:22, Rimas Kudelis wrote:
For a record: I am using courier-imap, and I too have this problem from time to time (e.g. now). So it's definately not UW's fault. I think when I googled for it, it appeared to be a bug in PHP, isn't it?
Probably it's PHP's fault and maybe relied on specific PHP+Apache configuration.
2010.09.17 11:29, A.L.E.C rašė:
On 17.09.2010 10:22, Rimas Kudelis wrote:
For a record: I am using courier-imap, and I too have this problem from time to time (e.g. now). So it's definately not UW's fault. I think when I googled for it, it appeared to be a bug in PHP, isn't it?
Probably it's PHP's fault and maybe relied on specific PHP+Apache configuration.
I'm having this problem again, for about three hours now. Is there anything I could look for in my logs or any other means of debugging that would help?
Rimas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Tue, Sep 28, 2010 at 1:45 PM, Rimas Kudelis rq@akl.lt wrote:
2010.09.17 11:29, A.L.E.C rašė:
On 17.09.2010 10:22, Rimas Kudelis wrote:
For a record: I am using courier-imap, and I too have this problem from time to time (e.g. now). So it's definately not UW's fault. I think when I googled for it, it appeared to be a bug in PHP, isn't it?
Probably it's PHP's fault and maybe relied on specific PHP+Apache configuration.
I'm having this problem again, for about three hours now. Is there anything I could look for in my logs or any other means of debugging that would help?
Yes there is! :D
So to figure out what happens when RoundCube is used, I suggest you install xdebug and temporarily enable profiling of all requests. Beware though - the cachegrind files are huge and tend to eat diskspace quicker than you think. So make sure to watch the directory they are saved to.
In a nutshell!
sudo pecl install xdebug [depending on your PHP install, you may or may not have to manually insert the following into php.ini: extension=xdebug.so]
Then, use the following directives in php.ini: xdebug.profiler_enable=1 xdebug.profiler_output_dir=/dir/with/lots/of/space
Depending on your setup, you will need to restart PHP/Apache.
To analyze the files: http://kcachegrind.sf.net/ http://sourceforge.net/projects/wincachegrind/
This will allow you to troubleshoot where most time is spend and I guess this will either allow us to fix a bug (or more), or allow you to troubleshoot your setup and improve it.
If no one finds any errors in my writeup, I'd also add this to the wiki.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
2010.09.28 14:57, till rašė:
On Tue, Sep 28, 2010 at 1:45 PM, Rimas Kudelisrq@akl.lt wrote:
2010.09.17 11:29, A.L.E.C rašė:
On 17.09.2010 10:22, Rimas Kudelis wrote:
For a record: I am using courier-imap, and I too have this problem from time to time (e.g. now). So it's definately not UW's fault. I think when I googled for it, it appeared to be a bug in PHP, isn't it?
Probably it's PHP's fault and maybe relied on specific PHP+Apache configuration.
I'm having this problem again, for about three hours now. Is there anything I could look for in my logs or any other means of debugging that would help?
Yes there is! :D
So to figure out what happens when RoundCube is used, I suggest you install xdebug and temporarily enable profiling of all requests. Beware though - the cachegrind files are huge and tend to eat diskspace quicker than you think. So make sure to watch the directory they are saved to.
In a nutshell!
sudo pecl install xdebug [depending on your PHP install, you may or may not have to manually insert the following into php.ini: extension=xdebug.so]
Then, use the following directives in php.ini: xdebug.profiler_enable=1 xdebug.profiler_output_dir=/dir/with/lots/of/space
Depending on your setup, you will need to restart PHP/Apache.
To analyze the files: http://kcachegrind.sf.net/ http://sourceforge.net/projects/wincachegrind/
This will allow you to troubleshoot where most time is spend and I guess this will either allow us to fix a bug (or more), or allow you to troubleshoot your setup and improve it.
If no one finds any errors in my writeup, I'd also add this to the wiki.
Till
Thanks Till!
The thing is: if I restart Apache, I lose the dead process, and the time it appears next time will be rather unpredictable. Is there perhaps anything possible that doesn't involve apache restarts? By looking at the logs, I now know the email user who logged on in that session, and the 5 minutes time interval when the CPU usage rose up. What I don't know is what exactly that process is still doing and why it's connection is stuck in a CLOSE_WAIT state...
Rimas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Tue, Sep 28, 2010 at 1:57 PM, till till@php.net wrote:
On Tue, Sep 28, 2010 at 1:45 PM, Rimas Kudelis rq@akl.lt wrote:
2010.09.17 11:29, A.L.E.C rašė:
On 17.09.2010 10:22, Rimas Kudelis wrote:
For a record: I am using courier-imap, and I too have this problem from time to time (e.g. now). So it's definately not UW's fault. I think when I googled for it, it appeared to be a bug in PHP, isn't it?
Probably it's PHP's fault and maybe relied on specific PHP+Apache configuration.
I'm having this problem again, for about three hours now. Is there anything I could look for in my logs or any other means of debugging that would help?
Yes there is! :D
So to figure out what happens when RoundCube is used, I suggest you install xdebug and temporarily enable profiling of all requests. Beware though - the cachegrind files are huge and tend to eat diskspace quicker than you think. So make sure to watch the directory they are saved to.
In a nutshell!
sudo pecl install xdebug [depending on your PHP install, you may or may not have to manually insert the following into php.ini: extension=xdebug.so]
Sorry, the above should say: zend_extension=xdebug.so
Then, use the following directives in php.ini: xdebug.profiler_enable=1 xdebug.profiler_output_dir=/dir/with/lots/of/space
Depending on your setup, you will need to restart PHP/Apache.
To analyze the files: http://kcachegrind.sf.net/ http://sourceforge.net/projects/wincachegrind/
This will allow you to troubleshoot where most time is spend and I guess this will either allow us to fix a bug (or more), or allow you to troubleshoot your setup and improve it.
If no one finds any errors in my writeup, I'd also add this to the wiki.
Added it to the wiki: http://trac.roundcube.net/wiki/Howto_ReportIssues#DebuggingRoundCube
Till _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Tue, Sep 28, 2010 at 2:10 PM, Rimas Kudelis rq@akl.lt wrote:
2010.09.28 14:57, till rašė:
On Tue, Sep 28, 2010 at 1:45 PM, Rimas Kudelisrq@akl.lt wrote:
2010.09.17 11:29, A.L.E.C rašė:
On 17.09.2010 10:22, Rimas Kudelis wrote:
For a record: I am using courier-imap, and I too have this problem from time to time (e.g. now). So it's definately not UW's fault. I think when I googled for it, it appeared to be a bug in PHP, isn't it?
Probably it's PHP's fault and maybe relied on specific PHP+Apache configuration.
I'm having this problem again, for about three hours now. Is there anything I could look for in my logs or any other means of debugging that would help?
Yes there is! :D
So to figure out what happens when RoundCube is used, I suggest you install xdebug and temporarily enable profiling of all requests. Beware though - the cachegrind files are huge and tend to eat diskspace quicker than you think. So make sure to watch the directory they are saved to.
In a nutshell!
sudo pecl install xdebug [depending on your PHP install, you may or may not have to manually insert the following into php.ini: extension=xdebug.so]
Then, use the following directives in php.ini: xdebug.profiler_enable=1 xdebug.profiler_output_dir=/dir/with/lots/of/space
Depending on your setup, you will need to restart PHP/Apache.
To analyze the files: http://kcachegrind.sf.net/ http://sourceforge.net/projects/wincachegrind/
This will allow you to troubleshoot where most time is spend and I guess this will either allow us to fix a bug (or more), or allow you to troubleshoot your setup and improve it.
If no one finds any errors in my writeup, I'd also add this to the wiki.
Till
Thanks Till!
The thing is: if I restart Apache, I lose the dead process, and the time it appears next time will be rather unpredictable. Is there perhaps anything possible that doesn't involve apache restarts? By looking at the logs, I now know the email user who logged on in that session, and the 5 minutes time interval when the CPU usage rose up. What I don't know is what exactly that process is still doing and why it's connection is stuck in a CLOSE_WAIT state...
Rimas
Hi Rimas,
I suggest you install Xdebug now and periodically check what the profiler left for you.
Otherwise, there is no way to inspect what happened. At least none that I know of.
You could also use valgrind on Apache, but that also requires some sort of setup: http://bugs.php.net/bugs-getting-valgrind-log.php
Till _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Sep 28, 2010, at 7:10 AM, Rimas Kudelis wrote:
The thing is: if I restart Apache, I lose the dead process, and the
time it appears next time will be rather unpredictable. Is there perhaps anything possible that doesn't involve apache restarts?
You could always strace the process to see what system calls it is
running, or connect with gdb and see what function it is in. For gdb
you'll want to have apache and PHP compiled with debugging symbols.
This will show you where it is running inside of the C code of Apache
and PHP, which will be different from where you are in the PHP code of
roundcube. You may be able to poke around and find some clues about
where you are in roundcube. It's a start.
David
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Tue, Sep 28, 2010 at 2:15 PM, David Harris dharris@drh.net wrote:
On Sep 28, 2010, at 7:10 AM, Rimas Kudelis wrote:
The thing is: if I restart Apache, I lose the dead process, and the time it appears next time will be rather unpredictable. Is there perhaps anything possible that doesn't involve apache restarts?
You could always strace the process to see what system calls it is running, or connect with gdb and see what function it is in. For gdb you'll want to have apache and PHP compiled with debugging symbols. This will show you where it is running inside of the C code of Apache and PHP, which will be different from where you are in the PHP code of roundcube. You may be able to poke around and find some clues about where you are in roundcube. It's a start.
David
Hey David,
maybe you want to write up a quick howto?
Till _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
2010.09.28 15:15, David Harris rašė:
On Sep 28, 2010, at 7:10 AM, Rimas Kudelis wrote:
The thing is: if I restart Apache, I lose the dead process, and the time it appears next time will be rather unpredictable. Is there perhaps anything possible that doesn't involve apache restarts?
You could always strace the process to see what system calls it is running, or connect with gdb and see what function it is in. For gdb you'll want to have apache and PHP compiled with debugging symbols. This will show you where it is running inside of the C code of Apache and PHP, which will be different from where you are in the PHP code of roundcube. You may be able to poke around and find some clues about where you are in roundcube. It's a start.
hm, I downloaded the debug symbols and ran gdb. Now what? I ran a lot of step's, but all I see are zend_* filenames...
By the way, strace just attaches to the process, but doesn't output anything...
Rimas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 09/28/2010 02:42 PM, Rimas Kudelis wrote:
hm, I downloaded the debug symbols and ran gdb. Now what? I ran a lot of step's, but all I see are zend_* filenames...
By the way, strace just attaches to the process, but doesn't output anything...
attach to the process and issue "bt" (for backtrace)
you should then see which function the process is currently stuck in.
strace just confirms that the process is hanging. there should be a couple of lines output thou.
btw. do you use mod_php, suphp, suexec, ...?
cheers, raoul
2010.09.28 16:05, Raoul Bhatia [IPAX] rašė:
On 09/28/2010 02:42 PM, Rimas Kudelis wrote:
hm, I downloaded the debug symbols and ran gdb. Now what? I ran a lot of step's, but all I see are zend_* filenames...
By the way, strace just attaches to the process, but doesn't output anything...
attach to the process and issue "bt" (for backtrace)
you should then see which function the process is currently stuck in.
strace just confirms that the process is hanging. there should be a couple of lines output thou.
None. And it doesn't look like waiting for a command either. Inputting "bt" didn't do anything. I added -d -f to the commandline, then I at least saw some output:
# strace -d -f -p 29199 Process 29199 attached - interrupt to quit [wait(0x137f) = 29199] pid 29199 stopped, [SIGSTOP] bt <-- I waited for a few seconds before pressing ^C here ^Ccleanup: looking at pid 29199 Process 29199 detached
btw. do you use mod_php, suphp, suexec, ...?
I use suphp mostly, but not for stuff installed from packages (incl. Roundcube). That stuff runs on mod_php.
Rimas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 09/28/2010 03:18 PM, Rimas Kudelis wrote:
bt <-- I waited for a few seconds before pressing ^C here ^Ccleanup: looking at pid 29199 Process 29199 detached
bt is for "gdb" :)
gdb program pid, e.g. gdb /usr/sbin/apache2 1234
and then use bt to print a stacktrace
cheers, raoul
2010.09.28 16:34, Raoul Bhatia [IPAX] rašė:
On 09/28/2010 03:18 PM, Rimas Kudelis wrote:
bt<-- I waited for a few seconds before pressing ^C here ^Ccleanup: looking at pid 29199 Process 29199 detached
bt is for "gdb" :)
gdb program pid, e.g. gdb /usr/sbin/apache2 1234
and then use bt to print a stacktrace
yeah, it's all littered with "zend_*" and each backtrace shows different line numbers. :)
I installed xdebug per Till's suggestion. Will see what happens (ie when I'll hit that problem again)...
Rimas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
2010.09.28 15:11, till rašė:
On Tue, Sep 28, 2010 at 1:57 PM, tilltill@php.net wrote:
On Tue, Sep 28, 2010 at 1:45 PM, Rimas Kudelisrq@akl.lt wrote:
2010.09.17 11:29, A.L.E.C rašė:
On 17.09.2010 10:22, Rimas Kudelis wrote:
For a record: I am using courier-imap, and I too have this problem from time to time (e.g. now). So it's definately not UW's fault. I think when I googled for it, it appeared to be a bug in PHP, isn't it?
Probably it's PHP's fault and maybe relied on specific PHP+Apache configuration.
I'm having this problem again, for about three hours now. Is there anything I could look for in my logs or any other means of debugging that would help?
Yes there is! :D
So to figure out what happens when RoundCube is used, I suggest you install xdebug and temporarily enable profiling of all requests. Beware though - the cachegrind files are huge and tend to eat diskspace quicker than you think. So make sure to watch the directory they are saved to.
In a nutshell!
sudo pecl install xdebug [depending on your PHP install, you may or may not have to manually insert the following into php.ini: extension=xdebug.so]
Sorry, the above should say: zend_extension=xdebug.so
Then, use the following directives in php.ini: xdebug.profiler_enable=1 xdebug.profiler_output_dir=/dir/with/lots/of/space
Depending on your setup, you will need to restart PHP/Apache.
To analyze the files: http://kcachegrind.sf.net/ http://sourceforge.net/projects/wincachegrind/
This will allow you to troubleshoot where most time is spend and I guess this will either allow us to fix a bug (or more), or allow you to troubleshoot your setup and improve it.
If no one finds any errors in my writeup, I'd also add this to the wiki.
Added it to the wiki: http://trac.roundcube.net/wiki/Howto_ReportIssues#DebuggingRoundCube
Hi all,
quick heads-up: since enabling Xdebug, I've now twice had a problem of the server in question being inaccessible for some time (which is different from what I had previously – 100% cpu load). I looked at the cachegrind files, and one of them looks suspicious because of its size (800+ MB). Unsurprisingly, its header mentions Roundcube... :)
I'll probably try to run that file on wincachegrind, but I'm not sure it's a good idea (I suspect it will eat all my ram and freeze the computer...) Does anyone maybe want to take a look at it too? Hope it doesn't contain sensitive data, does it?
Rimas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
-
A.L.E.C -
David Harris -
Emerson Pinter -
Jacob Whatley -
Raoul Bhatia [IPAX] -
Rimas Kudelis -
till