Mailing List Archive: Cherokee: users

503 Reverse Proxy - Resolution and recommendations

Index | Next | Previous | View Threaded

pubcrawler.com at gmail

Oct 5, 2009, 10:08 PM

Post #1 of 15 (823 views)
Permalink

503 Reverse Proxy - Resolution and recommendations

Well I believe we have conquered the 503 Reverse Proxy issues finally
and this is my information on the causes and how to resolve this issue
and perhaps other similar issues going forward. I'll submit this
information to bug tracking and recommend we provide this information
in the docs and/or cookbooks.

The dreaded 503 error as well as other unexplainable 5xx errors that
occur after some run time are likely all linked directly to ulimit
settings - specifically open file descriptors. This also applies to
open files/file descriptors caused by use of I/O cache even if you are
not using reverse proxy.

This resolution wouldn't have been possible without Alvaro's long term
assistance as well as Stefan and other folks on the list here; you
folks are the best.

This is our successful resolution after 48 hours of run time on a
single server under a respectable amount of traffic.

In Cherokee-Admin: Advanced > Resources
File descriptors: by default I believe our install had an empty value
- unsure if this value is required or optional. We had no value
therein which essentially just left ulimit -n open file value at
whatever default value the OS had for the given user Cherokee is run
under. Everyone should set ulimit in Cherokee-admin ALWAYS. The
environment variables from the OS are subject to change, might not be
what you expect, etc. This is the only way to hard set the ulimit for
Cherokee and have a predictable set point.

File descriptor value needs to go as high as reasonable versus
resources of the machine. If the server is dedicated and only you are
on the machine, set it to something very high like 90000. This logic
is especially true if you have a busy website.

In Cherokee-Admin: Advanced > Nonces clean up time
Nonces clean up time I believe was null in our installation. Unsure if
this is a required value or not and what happens if no value is
specified. In our experience leaving this value empty means open file
descriptors are kept open artificially long - or perhaps infinitely,
which creates a large number of idle but open descriptors on the
server. Worst case is when under traffic load the number of open
files become excessive until all descriptors are used and thus a 503
error is served.

Nonces is another value that should be set in EVERY Cherokee
installation. Cleanups need to happen in our experience otherwise
eventually resource exhaustion occurs and 503s only get served.

Nonces clean up time we have set intentionally low at value of 5. This
means cleanup is done every 5 seconds. This has intended consequence
of closing open file descriptors, which prevents them from piling up
in unused heap. We have tested longer value of 10 seconds which works
also just fine, just more open file descriptors being used.
Clarification is needed on what intended task of this cleanup is and
what meets qualification to be cleaned up each time it is ran.

In Cherokee-Admin: Advanced > I/O Cache

I/O Cache is another open file descriptor user. The more cacheable
items you have the more open files there will be. When under traffic
load this will add to consumed open file descriptors. Our solution
with the 503 errors was to turn I/O cache off, which reduced 503 error
frequency, but did not prevent such.

Based on prior changes we made we reenabled I/O cache with no adverse effect.

I want to note clearly that these items indicate no deficiency in
Cherokee whatsoever. The same logic has been applied to fix problems
someone was experiencing with Cherokee on SunOS as well as issues
someone else was having with Varnish. If you Google any web server
ulimit:
apache ulimit
nginx ulimit
etc...

You will find many discussions about the same issues with each and
every pieces of web server software.

Finally, as a disclaimer, setting ulimit for open descriptors high
like I said above might have the side effect of consuming more RAM. I
have yet to see anything scary from these settings, but we run
Cherokee on a machine with 2GB of RAM that is mostly there for
Cherokee to use. Your mileage might vary, so test always and feel free
to ask me anything or recommend updates to any of this.

-Paul
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

abarrera at neurosecurity

Oct 6, 2009, 12:47 AM

Post #2 of 15 (783 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

On Tuesday 06 October 2009 07:08:06 pub crawler wrote:
> Well I believe we have conquered the 503 Reverse Proxy issues finally
> and this is my information on the causes and how to resolve this issue
> and perhaps other similar issues going forward. I'll submit this
> information to bug tracking and recommend we provide this information
> in the docs and/or cookbooks.
>

Awesome description and tips Paul, thanks a lot for them. Not experiencing 503
(yet) but it's a very wise advise.

Thanks also to Alvaro and Stefan for helping you out.

This info shouls definetely be up in some place in the doc section.

Alex

--
http://www.neurosecurity.com

"We must be the change we wish to see in the world"
Mahatma Gandhi
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

abarrera at neurosecurity

Oct 6, 2009, 12:47 AM

Post #3 of 15 (781 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

jorge.sarmiento at gmail

Oct 6, 2009, 2:32 AM

Post #4 of 15 (787 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

> This info shouls definetely be up in some place in the doc section.
>

+1

jorge.sarmiento at gmail

Oct 6, 2009, 2:32 AM

Post #5 of 15 (789 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

> This info shouls definetely be up in some place in the doc section.
>

+1

alvaro at octality

Oct 6, 2009, 9:03 AM

Post #6 of 15 (782 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

Hello Paul,
First of all, thanks a million for documenting the issue!! I bet your mail
will be useful for many people.
However, I'd like to clarify a something. I missed the part where you asked
about nonces mail in the previous mail, and that seems to have leaded to a
misunderstanding:

On Tue, Oct 6, 2009 at 1:08 PM, pub crawler <pubcrawler.com [at] gmail>wrote:

>
> In Cherokee-Admin: Advanced > Nonces clean up time
> Nonces clean up time I believe was null in our installation. Unsure if
> this is a required value or not and what happens if no value is
> specified. In our experience leaving this value empty means open file
> descriptors are kept open artificially long - or perhaps infinitely,
> which creates a large number of idle but open descriptors on the
> server. Worst case is when under traffic load the number of open
> files become excessive until all descriptors are used and thus a 503
> error is served.
>
> Nonces is another value that should be set in EVERY Cherokee
> installation. Cleanups need to happen in our experience otherwise
> eventually resource exhaustion occurs and 503s only get served.
>
> Nonces clean up time we have set intentionally low at value of 5. This
> means cleanup is done every 5 seconds. This has intended consequence
> of closing open file descriptors, which prevents them from piling up
> in unused heap. We have tested longer value of 10 seconds which works
> also just fine, just more open file descriptors being used.
> Clarification is needed on what intended task of this cleanup is and
> what meets qualification to be cleaned up each time it is ran.
>

The "nonce"s cache has actually nothing to do with the file descriptor
usage. Nonces are little strings that are exchanged between the web browser
and the web server for authentication purposes. That cache is no more than a
handful of short strings; neither it requires much memory, nor it holds any
opened file descriptor.

Leaving the option empty (so it uses the default value) should be alright.

--
Greetings, alo
http://www.alobbs.com/

pubcrawler.com at gmail

Oct 6, 2009, 9:30 AM

Post #7 of 15 (782 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

Let me look at nonces once again and isolate that value in production
and determine what if anything is occurring without a value there.
Fairly certain that is the correlating factor to the 503's even though
it seems from your description unrelated.

I'll report back with my further findings later this week.

Keep the input coming :)

On 10/6/09, Alvaro Lopez Ortega <alvaro [at] octality> wrote:
> Hello Paul,
> First of all, thanks a million for documenting the issue!! I bet your mail
> will be useful for many people.
> However, I'd like to clarify a something. I missed the part where you asked
> about nonces mail in the previous mail, and that seems to have leaded to a
> misunderstanding:
>
> On Tue, Oct 6, 2009 at 1:08 PM, pub crawler <pubcrawler.com [at] gmail>wrote:
>
>>
>> In Cherokee-Admin: Advanced > Nonces clean up time
>> Nonces clean up time I believe was null in our installation. Unsure if
>> this is a required value or not and what happens if no value is
>> specified. In our experience leaving this value empty means open file
>> descriptors are kept open artificially long - or perhaps infinitely,
>> which creates a large number of idle but open descriptors on the
>> server. Worst case is when under traffic load the number of open
>> files become excessive until all descriptors are used and thus a 503
>> error is served.
>>
>> Nonces is another value that should be set in EVERY Cherokee
>> installation. Cleanups need to happen in our experience otherwise
>> eventually resource exhaustion occurs and 503s only get served.
>>
>> Nonces clean up time we have set intentionally low at value of 5. This
>> means cleanup is done every 5 seconds. This has intended consequence
>> of closing open file descriptors, which prevents them from piling up
>> in unused heap. We have tested longer value of 10 seconds which works
>> also just fine, just more open file descriptors being used.
>> Clarification is needed on what intended task of this cleanup is and
>> what meets qualification to be cleaned up each time it is ran.
>>
>
> The "nonce"s cache has actually nothing to do with the file descriptor
> usage. Nonces are little strings that are exchanged between the web browser
> and the web server for authentication purposes. That cache is no more than a
> handful of short strings; neither it requires much memory, nor it holds any
> opened file descriptor.
>
> Leaving the option empty (so it uses the default value) should be alright.
>
> --
> Greetings, alo
> http://www.alobbs.com/
>
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

taher at unixwars

Oct 6, 2009, 10:26 AM

Post #8 of 15 (782 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

Hi Paul.

pub crawler wrote:
> Let me look at nonces once again and isolate that value in production
> and determine what if anything is occurring without a value there.
> Fairly certain that is the correlating factor to the 503's even though
> it seems from your description unrelated.
>
> I'll report back with my further findings later this week.
>
>
Please do. Once you've confirmed the issue, I'd be glad to add your
report to the documentation with whatever findings you might add and any
other tips our users might find interesting.

I'm sure it will be very useful to everybody ;-)

Cheers

--
taher [at] unixwars
http://unixwars.com/

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

jjamor at gmail

Oct 7, 2009, 7:15 PM

Post #9 of 15 (768 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

Hi!

pub crawler escribi�:
> Well I believe we have conquered the 503 Reverse Proxy issues finally
> and this is my information on the causes and how to resolve this issue
> and perhaps other similar issues going forward. I'll submit this
> information to bug tracking and recommend we provide this information
> in the docs and/or cookbooks.

I have applied your suggested changes, although since our migration to
0.99.24 the 5xx error has not been repeated (I guess).

Many thanks!

Best,

--

Juan Jose Amor Iglesias // -+- �Vor�gine! -+-
jjamor -at- gmail.com // juanjo -at- dramor.net

-------------------- Visit my Blog! ---------------------
The Boring Stories Written By DrAmor: http://dramor.net/blog/
---------------------------------------------------------------
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

linportal at gmail

Oct 8, 2009, 5:45 AM

Post #10 of 15 (768 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

Juan Jos� Amor wrote:
> Hi!
>
> pub crawler escribi�:
>> Well I believe we have conquered the 503 Reverse Proxy issues finally
>> and this is my information on the causes and how to resolve this issue
>> and perhaps other similar issues going forward. I'll submit this
>> information to bug tracking and recommend we provide this information
>> in the docs and/or cookbooks.
>
> I have applied your suggested changes, although since our migration to
> 0.99.24 the 5xx error has not been repeated (I guess).
>

I also have "trouble" to get the dreaded 504 Gateway timeout since I've
moved to 0.99.24 (actually the latest svn!). :)

While I was running 0.99.22 I've had numerous "lockups" where cherokee
would return 504 to all clients during 15-20 min window, and then
magically recover all by itself. In all such occasions it would log 200
0 (size) in the log file, so it seems that logging could be improved to
better reflect the reality. I might report this to the bug tracker if I
see it again.

But, I'll still keep running with full tracing turned on, for another
week or so, before I'm completely sure that the problem is gone.
--
http://www.linuxinsight.com/
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

stefan at konink

Oct 8, 2009, 5:47 AM

Post #11 of 15 (769 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

LinuxInsight schreef:
> But, I'll still keep running with full tracing turned on, for another
> week or so, before I'm completely sure that the problem is gone.

Thanks for that! All help with debugging is seriously appreciated :)

Stefan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAkrN33gACgkQYH1+F2Rqwn3TpgCggXOpO80TdRwnOxseoCFMB8sz
WtAAnR+RMmp5CXSthGVzcbDHDlXlt2VV
=KZTI
-----END PGP SIGNATURE-----
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

linportal at gmail

Oct 8, 2009, 2:37 PM

Post #12 of 15 (767 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

LinuxInsight wrote:
> Juan Jos� Amor wrote:
>> Hi!
>>
>> pub crawler escribi�:
>>> Well I believe we have conquered the 503 Reverse Proxy issues finally
>>> and this is my information on the causes and how to resolve this issue
>>> and perhaps other similar issues going forward. I'll submit this
>>> information to bug tracking and recommend we provide this information
>>> in the docs and/or cookbooks.
>>
>> I have applied your suggested changes, although since our migration to
>> 0.99.24 the 5xx error has not been repeated (I guess).
>>
>
> I also have "trouble" to get the dreaded 504 Gateway timeout since I've
> moved to 0.99.24 (actually the latest svn!). :)
>
> While I was running 0.99.22 I've had numerous "lockups" where cherokee
> would return 504 to all clients during 15-20 min window, and then
> magically recover all by itself. In all such occasions it would log 200
> 0 (size) in the log file, so it seems that logging could be improved to
> better reflect the reality. I might report this to the bug tracker if I
> see it again.
>
> But, I'll still keep running with full tracing turned on, for another
> week or so, before I'm completely sure that the problem is gone.

Oh well, I really spoke too soon. The problem happened again, php pages
weren't served for ~ 17min. It started with this:

{0xf7f4cd90} [08/09/2009 10:47:34.356] thread.c:0526 (
process_polling_connections): conn 0x91556f8(fd=67): Time out
{0xf7f4cd90} [08/09/2009 10:47:34.356] socket.c:0985 (
cherokee_socket_bufwrite): write fd=67 len=187 ret=0 written=187
{0xf7f4cd90} [08/09/2009 10:47:34.356] util.c:1310 (
cherokee_fd_close): fd=67 re=0
{0xf7f4cd90} [08/09/2009 10:47:34.356] socket.c:0208 (
cherokee_socket_close): fd=67 is_tls=0 re=0
{0xf7f4cd90} [08/09/2009 10:47:34.356] handler_fcgi.c:0317 (
cherokee_handler_fcgi_free): fcgi handler free: 0x9081540
{0xf7f4cd90} [08/09/2009 10:47:34.356] util.c:1310 (
cherokee_fd_close): fd=70 re=0
{0xf7f4cd90} [08/09/2009 10:47:34.356] socket.c:0208 (
cherokee_socket_close): fd=70 is_tls=0 re=0
{0xf7f4cd90} [08/09/2009 10:47:34.356] connection.c:0357 (
cherokee_connection_clean): conn 0x91556f8, has headers 0

conn 0x91556f8 was the first one to timeout (after 60 seconds) and for
the next 17 minutes all connections that dispatched requests to php-cgi
timeouted in such manner and sent 504 Gateway timeout. Serving static
content (icons, files..) worked normally during that time.

I've gone through the setup phase of the connection above and there's
nothing weird there, it gets matched to many rules, rewritten, and
finally a request is dispatched to php-cgi. It surely looks like php-cgi
never answers and such behavior continues for a long time after this
first failure.

cherokee.error has absolutely nothing in it
standard apache log has this (ip obscured):

1x4.2y7.1z2.6 - - [08/Oct/2009:10:47:34 +0200] "GET
/proc_sys_net_ipv4_route_secret_interval.html HTTP/1.1" 200 0 "-"
"Mozilla/4.0 (compatible;)"

So it logs that it returned 200 and zero content size, but in reality
504 is returned to the browser really.

During those 17 minutes, there isn't any kind of overload, requests come
at a normal pace, CPU utilization in fact drops because php-cgi
obviously are not processing requests etc. Then at some point in time,
everything automagically heals, php pages continue to be server normally
once again, and exactly the same php-cgi processes are doing it.

This really looks like a tough problem, even with full tracing turned on
it's not obvious who's responsible for such behavior, cherokee or
php-cgi? Although I'm heavily inclined to the idea that php-cgi is the
culprit.
--
http://www.linuxinsight.com/
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

alvaro at octality

Oct 14, 2009, 8:15 AM

Post #13 of 15 (757 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

On 08/10/2009, at 23:37, LinuxInsight wrote:
LinuxInsight wrote:
>> Juan Jos� Amor wrote:
>>> pub crawler escribi�:
>>>> Well I believe we have conquered the 503 Reverse Proxy issues
>>>> finally
>>>> and this is my information on the causes and how to resolve this
>>>> issue
>>>> and perhaps other similar issues going forward. I'll submit this
>>>> information to bug tracking and recommend we provide this
>>>> information
>>>> in the docs and/or cookbooks.
>>>
>>> I have applied your suggested changes, although since our
>>> migration to
>>> 0.99.24 the 5xx error has not been repeated (I guess).
>>
>> I also have "trouble" to get the dreaded 504 Gateway timeout since
>> I've
>> moved to 0.99.24 (actually the latest svn!). :)
>>
>> While I was running 0.99.22 I've had numerous "lockups" where
>> cherokee
>> would return 504 to all clients during 15-20 min window, and then
>> magically recover all by itself. In all such occasions it would log
>> 200
>> 0 (size) in the log file, so it seems that logging could be
>> improved to
>> better reflect the reality. I might report this to the bug tracker
>> if I
>> see it again.
>>
>> But, I'll still keep running with full tracing turned on, for another
>> week or so, before I'm completely sure that the problem is gone.
>
> Oh well, I really spoke too soon. The problem happened again, php
> pages
> weren't served for ~ 17min. It started with this:
>
> {0xf7f4cd90} [08/09/2009 10:47:34.356] thread.c:0526 (
> process_polling_connections): conn 0x91556f8(fd=67): Time out
> {0xf7f4cd90} [08/09/2009 10:47:34.356] socket.c:0985 (
> cherokee_socket_bufwrite): write fd=67 len=187 ret=0 written=187
> {0xf7f4cd90} [08/09/2009 10:47:34.356] util.c:1310 (
> cherokee_fd_close): fd=67 re=0
> {0xf7f4cd90} [08/09/2009 10:47:34.356] socket.c:0208 (
> cherokee_socket_close): fd=67 is_tls=0 re=0
> {0xf7f4cd90} [08/09/2009 10:47:34.356] handler_fcgi.c:0317 (
> cherokee_handler_fcgi_free): fcgi handler free: 0x9081540
> {0xf7f4cd90} [08/09/2009 10:47:34.356] util.c:1310 (
> cherokee_fd_close): fd=70 re=0
> {0xf7f4cd90} [08/09/2009 10:47:34.356] socket.c:0208 (
> cherokee_socket_close): fd=70 is_tls=0 re=0
> {0xf7f4cd90} [08/09/2009 10:47:34.356] connection.c:0357 (
> cherokee_connection_clean): conn 0x91556f8, has headers 0
>
> conn 0x91556f8 was the first one to timeout (after 60 seconds) and for
> the next 17 minutes all connections that dispatched requests to php-
> cgi
> timeouted in such manner and sent 504 Gateway timeout. Serving static
> content (icons, files..) worked normally during that time.
>
> I've gone through the setup phase of the connection above and there's
> nothing weird there, it gets matched to many rules, rewritten, and
> finally a request is dispatched to php-cgi. It surely looks like php-
> cgi
> never answers and such behavior continues for a long time after this
> first failure.
>
> cherokee.error has absolutely nothing in it
> standard apache log has this (ip obscured):
>
> 1x4.2y7.1z2.6 - - [08/Oct/2009:10:47:34 +0200] "GET
> /proc_sys_net_ipv4_route_secret_interval.html HTTP/1.1" 200 0 "-"
> "Mozilla/4.0 (compatible;)"
>
> So it logs that it returned 200 and zero content size, but in reality
> 504 is returned to the browser really.
>
> During those 17 minutes, there isn't any kind of overload, requests
> come
> at a normal pace, CPU utilization in fact drops because php-cgi
> obviously are not processing requests etc. Then at some point in time,
> everything automagically heals, php pages continue to be server
> normally
> once again, and exactly the same php-cgi processes are doing it.
>
> This really looks like a tough problem, even with full tracing
> turned on
> it's not obvious who's responsible for such behavior, cherokee or
> php-cgi? Although I'm heavily inclined to the idea that php-cgi is the
> culprit.

Yeah, I'm tempted so think so, although I have no way to confirm it
quite yet.

Reached this point, the only think we can do is to find a way to
consistently reproduce the issue. That would be the only way in which
we'd be able to trace the issue in depth (both, the Cherokee and PHP
side of things).

Thanks for all the debugging BTW; good stuff!

--
Octality
http://www.octality.com/

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

stefan at konink

Oct 14, 2009, 8:20 AM

Post #14 of 15 (755 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Alvaro Lopez Ortega schreef:
> Yeah, I'm tempted so think so, although I have no way to confirm it
> quite yet.
>
> Reached this point, the only think we can do is to find a way to
> consistently reproduce the issue. That would be the only way in which
> we'd be able to trace the issue in depth (both, the Cherokee and PHP
> side of things).
>
> Thanks for all the debugging BTW; good stuff!

GDB 7.0 has reverse debugging support. So it could be a very good thing
to get the latest gdb so we can do all kind of interesting stuff just
after such thing happens.

Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAkrV7E8ACgkQYH1+F2Rqwn14rgCdEHCo/HiX++nghcvOg4IPNrpD
zSIAnjTRgpgQ4tRNfhYnZ2tbyUm+e7BB
=DH+0
-----END PGP SIGNATURE-----
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

alvaro at octality

Oct 14, 2009, 10:04 AM

Post #15 of 15 (753 views)
Permalink

Re: 503 Reverse Proxy - Resolution and recommendations [In reply to]

On 14/10/2009, at 17:20, Stefan de Konink wrote:
Alvaro Lopez Ortega schreef:
>> Yeah, I'm tempted so think so, although I have no way to confirm it
>> quite yet.
>>
>> Reached this point, the only think we can do is to find a way to
>> consistently reproduce the issue. That would be the only way in which
>> we'd be able to trace the issue in depth (both, the Cherokee and PHP
>> side of things).
>>
>> Thanks for all the debugging BTW; good stuff!
>
> GDB 7.0 has reverse debugging support. So it could be a very good
> thing
> to get the latest gdb so we can do all kind of interesting stuff just
> after such thing happens.

Regardless of how fancy the whole reverse debugging stuff appears, in
this case the only useful feature for us would be record/replay. I
wouldn't personally put my hope on this to find and fix the issue. :-)

--
Octality
http://www.octality.com/

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads