FAQ
Hi,

I am new to the Catalyst framework and am running Catalyst on Kubuntu Linux using the built-in server with the TT view and DBIC database backend.

My problem is that sometimes the "end" sub in Root.pm hangs. All it has is the RenderView action (as generated by Catalyst), so I assume that is the culprit.

If I return the same template as was previously displayed on the page, then it hangs. There appears to be other occasions as well, but I haven't found any pattern yet.

Here is an example output from the terminal:

[info] *** Request 11 (0.000/s) [5758] [Sun Jun 28 08:11:16 2009] ***
[debug] Body Parameters are:
.-------------------------------------+--------------------------------------.
Parameter | Value |
+-------------------------------------+--------------------------------------+
Create | Create user |
password | x |
username | kalle |
verify_password | y |
'-------------------------------------+--------------------------------------'
[debug] "POST" request for "users/create" from "127.0.0.1"
[debug] Path is "users/create"
[debug] Found sessionid "29eee4bdb13bf24aa256c7dfebd87a5816ee5bc9" in cookie
[debug] Restored session "29eee4bdb13bf24aa256c7dfebd87a5816ee5bc9"
[debug] Rendering template "users/create_form.tt2"
[info] Request took 795.658106s (0.001/s)
.------------------------------------------------------------+-----------.
Action | Time |
+------------------------------------------------------------+-----------+
/users/create | 0.005603s |
/end | 795.6377s |
-> Cupper::View::TT->process | 795.6356s |
'------------------------------------------------------------+-----------'

As you can see, "end" has hanged in 795 seconds, and this output was not printed until AFTER I hit "Stop" in Firefox. Below is the code in users/create:

sub create : Local : ActionClass('Restricted') {
my ( $self, $c ) = @_;

# Retrieve the values from the form
my $username = $c->request->params->{username};
my $password = $c->request->params->{password};
my $verify_password = $c->request->params->{verify_password};

if ( ! $username || 4 < length $username ) {
$c->stash->{error_msg} = $c->localize('User name must be at least 5 characters long.');
$c->stash->{template} = 'users/create_form.tt2';
return;
}

if ( $password ne $verify_password ) {
$c->stash->{error_msg} = $c->localize('Passwords does not match.');
$c->stash->{template} = 'users/create_form.tt2';
return;
}

# Create the user
my $user = $c->model('DB::Users')->create(
{
user_id => 1,
username => $username,
password => $password,
}
);

# Store new model object in stash
$c->stash->{template} = 'users/list.tt2';
}


This particular request should take the "$password ne $verify_password" path and return the user to the "users/create_form" function.

Here is the content of the "Restricted" action:

sub execute {
my $self = shift;
my ( $controller, $c, $test ) = @_;

unless ( $c->user_exists() ) {
warn "BEFORE redirect";
$c->forward('/users/login_form');
warn "AFTER redirect";
return;
}
$self->NEXT::execute(@_);
}


I am unable to run a debugger on the catalyst server (I get a segmantation fault), so it is difficult to find exactly where
problem is.

Any help is appreciated.

KR,
Gunnar




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090627/f292aecd/attachment.htm

Search Discussions

  • Tomas Doran at Jun 28, 2009 at 3:13 pm

    On 28 Jun 2009, at 07:35, Gunnar Strand wrote:
    [debug] Rendering template "users/create_form.tt2"
    [info] Request took 795.658106s (0.001/s)
    .------------------------------------------------------------
    +-----------.
    Action |
    Time |
    +------------------------------------------------------------
    +-----------+
    /users/create |
    0.005603s |
    /end |
    795.6377s |
    -> Cupper::View::TT->process |
    795.6356s |
    '------------------------------------------------------------
    +-----------'

    As you can see, "end" has hanged in 795 seconds, and this output
    was not printed until AFTER I hit "Stop" in Firefox. Below is the
    code in users/create:
    This shows that the template processing is going into an infinite loop.

    Something in users/create_form.tt2 is going mad. I'd replace it with
    a blank template, check that fixes the issue, then work backwards
    from there, re-adding chunks of code until you find the culprit.

    Cheers
    t0m
  • Gunnar Strand at Jun 28, 2009 at 3:50 pm

    On 28 Jun 2009, at 07:35, Gunnar Strand wrote:
    [debug] Rendering template "users/create_form.tt2"
    [info] Request took 795.658106s (0.001/s)
    .------------------------------------------------------------+-----------.
    Action | Time |
    +------------------------------------------------------------+-----------+
    /users/create | 0.005603s |
    /end | 795.6377s |
    -> Cupper::View::TT->process | 795.6356s |
    '------------------------------------------------------------+-----------'

    As you can see, "end" has hanged in 795 seconds, and this output was not printed until AFTER I hit "Stop" in Firefox. Below is the code in users/create:
    This shows that the template processing is going into an infinite loop.

    Something in users/create_form.tt2 is going mad. I'd replace it with a blank template, check that fixes the issue, >then work backwards from there, re-adding chunks of code until you find the culprit.
    Thanks for th tip! I'll see if I can nail it down - the template structure isn't just that one file - I am using the "wrapper" support in TT.

    Is there any way of running the server in a debugger or to turn tracing on? Can I send a signal to it to get it to dump a stack trace somehow? Any attempt I've made so far just results in nothing or segmentation faults.

    KR,
    Gunnar

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/




    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090628/615299be/attachment.htm
  • Tomas Doran at Jun 28, 2009 at 4:24 pm

    On 28 Jun 2009, at 16:50, Gunnar Strand wrote:
    Thanks for th tip! I'll see if I can nail it down - the template
    structure isn't just that one file - I am using the "wrapper"
    support in TT.
    Right. I'd start by blanking the actual template, which will at least
    tell you if it's the template or the wrapper, and work from there..
    Is there any way of running the server in a debugger or to turn
    tracing on? Can I send a signal to it to get it to dump a stack
    trace somehow? Any attempt I've made so far just results in nothing
    or segmentation faults.
    well, I guess something like: $SIG{WINCH} = sub { Carp::cluck('here'); }

    + a SIGWINCH might be helpful.

    Or just alarm(3); in your controller action - should cause an
    exception (and so stack trace in debug mode) after 3s..

    I don't understand why you're seeing segfaults. What version of
    Catalyst are you using, what is your perl -V, and do you have the
    latest version of Variable::Magic installed? Also, if you could
    attach gdb and get the catalyst process to segfault, then a backtrace
    from c land could be useful.

    Cheers
    t0m
  • Gunnar Strand at Jun 29, 2009 at 4:39 am

    Is there any way of running the server in a debugger or to turn tracing on? Can I send a signal to it to get it to >dump a stack trace somehow? Any attempt I've made so far just results in nothing or segmentation faults.
    [...]

    I don't understand why you're seeing segfaults. What version of Catalyst are you using, what is your perl -V, and do you have the latest version of Variable::Magic installed? Also, if you could attach gdb and get the catalyst process to segfault, then a backtrace from c land could be useful.
    The debugger works now(!). I've always had problems with it but hadn't tried it for a while. Maybe a library got updated.

    Thanks for the tips!

    KR,
    Gunnar

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/




    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090628/4b380366/attachment.htm
  • Gunnar Strand at Jul 2, 2009 at 8:33 pm
    I found the problem. Turning on debugging for TT (DEBUG => DEBUG_ALL) in TT.pm showed that it hangs on the [% USE CGI %] directive. Apparently

    [% USE CGI('-no_debug') %]

    is needed. Got it from here:

    https://bugzilla.mozilla.org/show_bug.cgi?id7589

    Seems CGI thinks that it is begin run from command line and prompts for data.


    KR,
    Gunnar


    ________________________________
    From: Gunnar Strand <gunnarstrand@yahoo.com>
    To: The elegant MVC web framework <catalyst@lists.scsys.co.uk>
    Sent: Monday, June 29, 2009 6:39:41 AM
    Subject: Re: [Catalyst] Hangs in RenderView in "end"

    Is there any way of running the server in a debugger or to turn tracing on? Can I send a signal to it to get it to >dump a stack trace somehow? Any attempt I've made so far just results in nothing or segmentation faults.
    [...]

    I don't understand why you're seeing segfaults. What version of Catalyst are you using, what is your perl -V, and do you have the latest version of Variable::Magic installed? Also, if you could attach gdb and get the catalyst process to segfault, then a backtrace from c land could be useful.
    The debugger works now(!). I've always had problems with it but hadn't tried it for a while. Maybe a library got updated.

    Thanks for the tips!

    KR,
    Gunnar

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/



    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090702/9ec2a279/attachment.htm
  • Tomas Doran at Jul 2, 2009 at 9:47 pm

    On 2 Jul 2009, at 21:33, Gunnar Strand wrote:

    I found the problem. Turning on debugging for TT (DEBUG =>
    DEBUG_ALL) in TT.pm showed that it hangs on the [% USE CGI %]
    directive. Apparently

    [% USE CGI('-no_debug') %]

    is needed. Got it from here:

    https://bugzilla.mozilla.org/show_bug.cgi?id7589

    Seems CGI thinks that it is begin run from command line and prompts
    for data.
    Wow, that's a fairly unexpected gotcha.

    Any chance of a doc patch to make it easier for the next poor soul
    who gets stuck on this?

    Cheers
    t0m
  • Gordon Yeong at Jul 8, 2009 at 12:47 pm
    hi there

    I think i am facing the same fault.
    hmmm... When you mention TT.pm, do you mean the local TT.pm found in
    myApp/View/TT.pm or is it the TT.pm belonging to the Template Toolkit
    package?

    thanks

    Regards,
    Gordon Yeong


    2009/7/3 Gunnar Strand <gunnarstrand@yahoo.com>
    I found the problem. Turning on debugging for TT (DEBUG => DEBUG_ALL) in
    TT.pm showed that it hangs on the [% USE CGI %] directive. Apparently

    [% USE CGI('-no_debug') %]

    is needed. Got it from here:

    https://bugzilla.mozilla.org/show_bug.cgi?id7589

    Seems CGI thinks that it is begin run from command line and prompts for
    data.

    KR,
    Gunnar
    ------------------------------
    *From:* Gunnar Strand <gunnarstrand@yahoo.com>
    *To:* The elegant MVC web framework <catalyst@lists.scsys.co.uk>
    *Sent:* Monday, June 29, 2009 6:39:41 AM
    *Subject:* Re: [Catalyst] Hangs in RenderView in "end"
    Is there any way of running the server in a debugger or to turn tracing
    on? Can I send a signal to it to get it to >dump a stack trace somehow? Any
    attempt I've made so far just results in nothing or segmentation faults.
    [...]

    I don't understand why you're seeing segfaults. What version of Catalyst
    are you using, what is your perl -V, and do you have the latest version of
    Variable::Magic installed? Also, if you could attach gdb and get the
    catalyst process to segfault, then a backtrace from c land could be useful.

    The debugger works now(!). I've always had problems with it but hadn't
    tried it for a while. Maybe a library got updated.

    Thanks for the tips!

    KR,
    Gunnar

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/



    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090708/8697f4c2/attachment.htm
  • Gordon Yeong at Jul 8, 2009 at 12:57 pm
    hi there

    I am facing almost the same issue in that even clicking the "stop" button
    on firefox would see no difference in the debugging terminal or have a
    response from the webpage.
    When i have safari accesssing the same page, i can submit without a problem
    and the server doesn't hang.

    Any thoughts?

    thanks

    gordon

    2009/7/8 Gordon Yeong <anexiole@gmail.com>
    hi there

    I think i am facing the same fault.
    hmmm... When you mention TT.pm, do you mean the local TT.pm found in
    myApp/View/TT.pm or is it the TT.pm belonging to the Template Toolkit
    package?

    thanks

    Regards,
    Gordon Yeong


    2009/7/3 Gunnar Strand <gunnarstrand@yahoo.com>

    I found the problem. Turning on debugging for TT (DEBUG => DEBUG_ALL) in
    TT.pm showed that it hangs on the [% USE CGI %] directive. Apparently

    [% USE CGI('-no_debug') %]

    is needed. Got it from here:

    https://bugzilla.mozilla.org/show_bug.cgi?id7589

    Seems CGI thinks that it is begin run from command line and prompts for
    data.

    KR,
    Gunnar
    ------------------------------
    *From:* Gunnar Strand <gunnarstrand@yahoo.com>
    *To:* The elegant MVC web framework <catalyst@lists.scsys.co.uk>
    *Sent:* Monday, June 29, 2009 6:39:41 AM
    *Subject:* Re: [Catalyst] Hangs in RenderView in "end"
    Is there any way of running the server in a debugger or to turn
    tracing on? Can I send a signal to it to get it to >dump a stack trace
    somehow? Any attempt I've made so far just results in nothing or
    segmentation faults.
    [...]

    I don't understand why you're seeing segfaults. What version of Catalyst
    are you using, what is your perl -V, and do you have the latest version of
    Variable::Magic installed? Also, if you could attach gdb and get the
    catalyst process to segfault, then a backtrace from c land could be useful.

    The debugger works now(!). I've always had problems with it but hadn't
    tried it for a while. Maybe a library got updated.

    Thanks for the tips!

    KR,
    Gunnar

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/



    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090708/db4eb520/attachment.htm
  • Tomas Doran at Jul 8, 2009 at 4:42 pm

    Gordon Yeong wrote:
    hi there

    I am facing almost the same issue in that even clicking the "stop"
    button on firefox would see no difference in the debugging terminal or
    have a response from the webpage.
    When i have safari accesssing the same page, i can submit without a
    problem and the server doesn't hang.

    Any thoughts?
    This isn't a fastcgi/mod_deflate issue is it? Are you running both? If
    so, turn off mod_deflate and see if it fixes?

    Cheers
    t0m
  • Gordon Yeong at Jul 8, 2009 at 9:14 pm
    Mod deflate was never on because i made sure apache2 was shut down.
    I am using myapp_server.pl and the fault occurs.
    Tried to replicate the problem with safari and it doesn't occur.
    I believe there's some hidden complication with firefox.


    This isn't a fastcgi/mod_deflate issue is it? Are you running both? If so,
    turn off mod_deflate and see if it fixes?

    Cheers
    t0m

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090709/fe575c56/attachment.htm
  • Gordon Yeong at Jul 13, 2009 at 11:55 am
    I believe that firefox on mac OS X has a bug.
    I have tested with other browsers on both Mac Os X and windows platforms
    without any problems. Here's what I used:

    Mac Os X 10.5

    1. Safari

    Windows XP

    1. internet explorer
    2. firefox 3

    doesn't seem to have any issues.
    Any suggestions of how to prove this but such that I can perhaps log a call
    with the folks on mozilla?

    thanks:D

    Gordon



    2009/7/9 Gordon Yeong <anexiole@gmail.com>
    Mod deflate was never on because i made sure apache2 was shut down.
    I am using myapp_server.pl and the fault occurs.
    Tried to replicate the problem with safari and it doesn't occur.
    I believe there's some hidden complication with firefox.



    This isn't a fastcgi/mod_deflate issue is it? Are you running both? If so,
    turn off mod_deflate and see if it fixes?

    Cheers
    t0m

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090713/87229494/attachment.htm
  • Gordon Yeong at Jul 15, 2009 at 8:31 am
    hi, gents:)

    any ideas?
    I have tried firefox 3.0 and 3.5 on my mac os X and it causes
    myapp_server.pl to hang (ie. cause the CPU server to go 100%).

    Running an strace just shows me


    write(6, "=\"http://www.myexample.com."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)







    2009/7/13 Gordon Yeong <anexiole@gmail.com>
    I believe that firefox on mac OS X has a bug.
    I have tested with other browsers on both Mac Os X and windows platforms
    without any problems. Here's what I used:

    Mac Os X 10.5

    1. Safari

    Windows XP

    1. internet explorer
    2. firefox 3

    doesn't seem to have any issues.
    Any suggestions of how to prove this but such that I can perhaps log a
    call with the folks on mozilla?

    thanks:D

    Gordon
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090715/76e5a220/attachment.htm
  • Tomas Doran at Jul 15, 2009 at 9:08 pm

    On 15 Jul 2009, at 09:31, Gordon Yeong wrote:

    hi, gents:)

    any ideas?
    I have tried firefox 3.0 and 3.5 on my mac os X and it causes
    myapp_server.pl to hang (ie. cause the CPU server to go 100%).

    Running an strace just shows me


    write(6, "=\"http://www.myexample.com."..., 2715) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    write(6, "=\"http://www.myexample."..., 2715) = -1 EAGAIN (Resource
    temporarily unavailable)
    Hmm. I don't know why this could happen.

    Catalyst appears to be doing the correct thing here - from the Darwin
    reference man pages:

    [EAGAIN] The file is marked for non-blocking I/O, and
    no data could be written immediately.

    so I guess firefox has filled up the socket buffer in some way and
    isn't reading stuff, although I don't understand why Darwin is
    signaling Catalyst that the socket is available for writing, and then
    returning EAGAIN when we try to write :/

    Can you extract the section of the trace just before it goes into the
    EAGAIN loop and paste that?

    Which specific version / patch level of osX is this?

    Does using the Prefork engine work, or does it exhibit the same
    behavior?

    Cheers
    t0m
  • K. Akimoto at Jul 16, 2009 at 12:25 am
    hello, t0m,

    Good morning.

    1)Does using the Prefork engine work, or does it exhibit the same behavior?

    I am sorry as I can't tell you. This is because I have not tried it yet.
    Been developing and noticed this strange problem. I m pretty stuck
    halfway now with a Catalyst application that works fine sometimes on
    firefox MAC Os X but works fine always on any non-firefox 3.5 on mac os X.
    Good news is that the windows people running IE, Safari and FF would be
    able to use the application without a problem whilst us Mac folks using
    Firefox 3/3.5 will not be able to (and also hang my server) :(


    2) I have tried this on Mac OS X Leopard and Tiger (both running
    Firefox 3/3.5) . Problem comes up sometimes only. This is very sporadic
    because I tried the replicate the problem at another interval and
    Firefox was able to handle it.

    Tried it the next hour or evening and it jams up. Then, after restarted
    the catalyst application process, I use safari to perform the same tasks
    and no problems are observed.

    3) Here is an extract of the strace. Thank you :)


    accept(5, {sa_family¯_INET, sin_port=htons(50067),
    sin_addr=inet_addr("123.243.50.59")}, [10647353952623919120]) = 6
    ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff4c95dea0) = -1 EINVAL
    (Invalid argument)
    lseek(6, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
    ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff4c95dea0) = -1 EINVAL
    (Invalid argument)
    lseek(6, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
    fcntl(6, F_SETFD, FD_CLOEXEC) = 0 fcntl(6, F_GETFL)
    = 0x2 (flags O_RDWR)read(6, "GET / HTTP/1.1\r\nHost:
    www.myApp"..., 65536) = 514 getpeername(6, {sa_family¯_INET,
    sin_port=htons(50067), sin_addr=inet_addr("123.243.50.59")},
    [6788732235563401232]) = 0getsockname(6, {sa_family¯_INET,
    sin_port=htons(3000), sin_addr=inet_addr("125.214.64.65")},
    [6788732235563401232]) = 0
    open("/etc/hosts", O_RDONLY|0x80000 /* O_??? */) = 9fcntl(9, F_GETFD)
    = 0
    fcntl(9, F_SETFD, FD_CLOEXEC) = 0 fstat(9,
    {st_mode=S_IFREG|0644, st_size0, ...}) = 0
    mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
    = 0x2b0f67b6b000read(9, "127.0.0.1 localhost.localdomain "..., 4096) = 170
    close(9) = 0 munmap(0x2b0f67b6b000,
    4096) = 0
    rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0rt_sigaction(SIGCHLD,
    {SIG_DFL}, {SIG_IGN}, 8) = 0
    rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0rt_sigprocmask(SIG_BLOCK,
    [CHLD], [], 8) = 0rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) 0rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size!83, ...}) 0fcntl(6, F_GETFL) = 0x2 (flags O_RDWR)
    fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 alarm(10)
    = 0
    fcntl(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start932160,
    lene536}) = 0
    alarm(0) = 10 fcntl(3, F_SETLKW,
    {type=F_UNLCK, whence=SEEK_SET, start932160, lene536}) = 0
    alarm(10) = 0 fcntl(3, F_SETLKW,
    {type=F_WRLCK, whence=SEEK_SET, start#59296, lene536}) = 0alarm(0)
    = 10 fcntl(3, F_SETLKW, {type=F_UNLCK,
    whence=SEEK_SET, start#59296, lene536}) 0stat("/home/kakimoto/projects/myApp/root/src/index.tt2",
    {st_mode=S_IFREG|0755, st_size$8, ...}) 0stat("/home/kakimoto/projects/myApp/root/src/config/main", 0x70fcc0) -1 ENOENT (No such file or
    directory)stat("/home/kakimoto/projects/myApp/root/lib/config/main",
    {st_mode=S_IFREG|0755, st_size€3, ...}) = 0
    stat("/home/kakimoto/projects/myApp/root/src/config/col", 0x70fcc0) = -1
    ENOENT (No such file or directory)
    stat("/home/kakimoto/projects/myApp/root/lib/config/col",
    {st_mode=S_IFREG|0755, st_sizeD9, ...}) = 0
    stat("/home/kakimoto/projects/myApp/root/src/config/url", 0x70fcc0) = -1
    ENOENT (No such file or direc
    tory)
    stat("/home/kakimoto/projects/myApp/root/lib/config/url",
    {st_mode=S_IFREG|0755, st_size9, ...})
    stat("/home/kakimoto/projects/myApp/root/src/menu.tt2",
    {st_mode=S_IFREG|0755, st_sizeP2, ...}) = 0
    write(8, "SELECT me.id, me.password, me.fi"..., 276) = 276
    rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
    sendto(7, "B\0\0\0!\0dbdpg_p18331_2\0\0\0\0\1\0\0\0\0013\0\1"..., 56, 0,
    NULL, 0) = 56rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
    poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
    recvfrom(7,
    "2\0\0\0\4T\0\0\1\320\0\20id\0\0\0cN\0\1\0\0\0\27\0\4\377"..., 16384, 0,
    NULL, NULL) = 745
    stat("/home/kakimoto/projects/myApp/root/src/listings/search.tt2",
    {st_mode=S_IFREG|0755, st_size61
    , ...}) = 0
    open("/home/kakimoto/projects/myApp/root/src/listings/search.tt2",
    O_RDONLY) = 9
    ioctl(9, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff4c95ecf0) = -1 ENOTTY
    (Inappropriate ioctl for device)
    lseek(9, 0, SEEK_CUR) = 0
    fstat(9, {st_mode=S_IFREG|0755, st_size61, ...}) = 0
    fcntl(9, F_SETFD, FD_CLOEXEC) = 0fstat(9,
    {st_mode=S_IFREG|0755, st_size61, ...}) = 0
    read(9, "[% USE Dumper(Indent=1) -%]\n\n[%"..., 4096) = 1861
    read(9, "", 4096) 0stat("/home/kakimoto/projects/myApp/root/src/listings/search.tt2",
    {st_mode=S_IFREG|0755, st_size61
    , ...}) = 0close(9) = 0
    stat("/home/kakimoto/projects/myApp/root/src/listings/search.tt2",
    {st_mode=S_IFREG|0755, st_size61, ...}) = 0
    stat("/home/kakimoto/projects/myApp/script/../lib/Template/Plugin/Dumper.pmc",
    0x7fff4c95ef90) = -1 ENOENT (No such file or directory)
    stat("/home/kakimoto/projects/myApp/script/../lib/Template/Plugin/Dumper.pm",
    0x7fff4c95ee60) = -1 ENOENT (No such file or directory)
    stat("/usr/local/lib/perl5/5.8.9/x86_64-linux/Template/Plugin/Dumper.pmc",
    0x7fff4c95ef90) = -1 ENOENT (No such file or directory)
    stat("/usr/local/lib/perl5/5.8.9/x86_64-linux/Template/Plugin/Dumper.pm", 0x7fff4c95ee60)
    = -1 ENOENT (No such file or directory)
    stat("/usr/local/lib/perl5/5.8.9/Template/Plugin/Dumper.pmc",
    0x7fff4c95ef90) = -1 ENOENT (No such file or directory)
    stat("/usr/local/lib/perl5/5.8.9/Template/Plugin/Dumper.pm",
    0x7fff4c95ee60) = -1 ENOENT (No such file or directory)
    stat("/usr/local/lib/perl5/site_perl/5.8.9/x86_64-linux/Template/Plugin/Dumper.pmc",
    0x7fff4c95ef90) -1 ENOENT (No such file or directory)
    stat("/usr/local/lib/perl5/site_perl/5.8.9/x86_64-linux/Template/Plugin/Dumper.pm",
    {st_mode=S_IFREG|0
    444, st_size598, ...}) = 0
    open("/usr/local/lib/perl5/site_perl/5.8.9/x86_64-linux/Template/Plugin/Dumper.pm",
    O_RDONLY) = 9
    ioctl(9, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff4c95ec50) = -1 ENOTTY
    (Inappropriate ioctl for device)
    lseek(9, 0, SEEK_CUR) = 0
    read(9, "#==============================="..., 4096) = 3598lseek(9,
    1911, SEEK_SET) = 1911
    lseek(9, 0, SEEK_CUR) = 1911close(9)
    stat("/home/kakimoto/projects/myApp/root/src/site/wrapper", 0x70fcc0) -1 ENOENT (No such file or directory)
    stat("/home/kakimoto/projects/myApp/root/lib/site/wrapper",
    {st_mode=S_IFREG|0755, st_size356, ...}) = 0
    stat("/home/kakimoto/projects/myApp/root/src/ttsite.css",
    {st_mode=S_IFREG|0755, st_size770, ...}) = 0
    stat("/home/kakimoto/projects/myApp/root/src/site/header", 0x70fcc0) -1 ENOENT (No such file or directory)
    stat("/home/kakimoto/projects/myApp/root/lib/site/header",
    {st_mode=S_IFREG|0755, st_size245, ...}) = 0
    stat("/home/kakimoto/projects/myApp/root/src/sidebar.tt2",
    {st_mode=S_IFREG|0755, st_size�7, ...}) = 0
    stat("/home/kakimoto/projects/myApp/root/src/site/footer", 0x70fcc0) -1 ENOENT (No such file or directory)
    stat("/home/kakimoto/projects/myApp/root/lib/site/footer",
    {st_mode=S_IFREG|0755, st_size03, ...}) = 0
    brk(0x1d0a1000) = 0x1d0a1000
    brk(0x1d099000) = 0x1d099000
    alarm(10) = 0
    fcntl(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start932160,
    lene536}) = 0
    alarm(0) = 10
    fcntl(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start932160,
    lene536}) = 0
    alarm(10) = 0
    fcntl(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start#59296,
    lene536}) = 0
    alarm(0) = 10
    fcntl(3, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start#59296,
    lene536}) = 0
    write(6, "HTTP/1.0 200 OK\r\nConnection: clo"..., 18555) = 11520
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, "splay: inline;}\r\n#footer a {colo"..., 7035) = 1440
    write(6, " <!-- menu [start] -->\n "..., 5595) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, " <!-- menu [start] -->\n "..., 5595) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, " <!-- menu [start] -->\n "..., 5595) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, " <!-- menu [start] -->\n "..., 5595) = -1 EAGAIN
    (Resource temporarily unavailable)
    write(6, " <!-- menu [start] -->\n "..., 5595) = -1 EAGAIN
    (Resource temporarily unavailable)







    On Thu, Jul 16th, 2009 at 7:08 AM, Tomas Doran wrote:

    >
  • Gordon Yeong at Jul 16, 2009 at 12:57 am
    hey K

    thanks for including the error logs for me.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090716/0d31dfc6/attachment.htm
  • Gordon Yeong at Jul 16, 2009 at 2:20 am
    hey K,

    try running myApp_server.pl with "-k" . I tried it on my mac and it works
    just fine!

    :D anyway, would be interesting to find out why FF 3/3.5 causes the problem
    it does on Mac.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090716/dea2e824/attachment.htm
  • John Romkey at Jul 16, 2009 at 1:53 pm
    For what it's worth, I do my development under MacOS X 10.5 (currently
    10.5.7) and use FF 3.0.x (currently 3.0.11) as my primary browser for
    development and haven't run into any problems. I'm up-to-date on all
    the Catalyst packages. I normally run the built-in server with '-r -d'
    but deploy on a Debian system under Apache2 (also no problems).

    I also use Mason to render pages, not TT. I also don't use CGI.pm.

    I'd hope that you're not letting real users run against the built-in
    development server. And while it's a pain that the built-in server is
    hanging, that doesn't mean that your app under a deployment server
    would also hang.

    I gave up on FF 3.5 pretty quickly; I was having some Javascript and
    Firebug glitches and when it wouldn't show me the source to the page
    it was rendering I decided to try again later after 3.5.1 is out.

    I'm saying this just to say that Catalyst can work under MacOS X.
    Perhaps there's some combination of packages or MacOS X updates or the
    like which brings out this particular problem, but it's not the case
    that Catalyst is 100% having these issues under Mac OS X.

    kakimoto and Gordon, you did catch the earlier bit from Gunnar that
    using CGI.pm with debugging turned on was the culprit for him, didn't
    you? Are you using CGI.pm in your app or templates?
    - john romkey
    http://www.romkey.com/
  • Gordon Yeong at Jul 16, 2009 at 11:09 pm
    2009/7/16 John Romkey <romkey@apocalypse.org>
    For what it's worth, I do my development under MacOS X 10.5 (currently
    10.5.7) and use FF 3.0.x (currently 3.0.11) as my primary browser for
    development and haven't run into any problems. I'm up-to-date on all the
    Catalyst packages. I normally run the built-in server with '-r -d' but
    deploy on a Debian system under Apache2 (also no problems).
    Hi, John,.

    I believe K. akimoto was developing on an Ubuntu box and accessed his
    application for testing with a Firefox 3/3.5 browser on Mac OS X for
    testing.


    kakimoto and Gordon, you did catch the earlier bit from Gunnar that using
    CGI.pm with debugging turned on was the culprit for him, didn't you? Are you
    using CGI.pm in your app or templates?
    - john romkey
    http://www.romkey.com/


    Yes, we did discuss that and I checked the codes with no sight of CGI.pm (at
    least in the eyes of "fgrep -iRn CGI projects/myApp"



    I do have something to announce (and K. akimoto's tried this too). It's that

    he was running his app with "scripts/myapp_server.pl" - that caused the
    problem.

    I read up on the new book on Catalyst (woo hoo!) and ran it with the "-k"
    flag to keep connections alive (ie. "scripts/myapp_server.pl -k") and that
    seem to be stable (ie. Firefox 3/3.5 on Mac OS X was not hanging or taking
    his server down).

    Interesting but I am not entirely sure why Firefox 3/3.5 acts this way on
    Mac OS X.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090717/e64f1702/attachment.htm
  • Gunnar Strand at Jul 6, 2009 at 4:33 am
    Tomas Doran skrev:
    On 2 Jul 2009, at 21:33, Gunnar Strand wrote:

    I found the problem. Turning on debugging for TT (DEBUG => DEBUG_ALL)
    in TT.pm showed that it hangs on the [% USE CGI %] directive. Apparently

    [% USE CGI('-no_debug') %]

    is needed. Got it from here:

    https://bugzilla.mozilla.org/show_bug.cgi?id7589

    Seems CGI thinks that it is begin run from command line and prompts
    for data.
    Wow, that's a fairly unexpected gotcha.

    Any chance of a doc patch to make it easier for the next poor soul who
    gets stuck on this?
    Sure. Where would you like it?

    KR,
    Gunnar
    Cheers
    t0m


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Tomas Doran at Jul 6, 2009 at 8:13 am

    On 6 Jul 2009, at 05:33, Gunnar Strand wrote:

    Wow, that's a fairly unexpected gotcha.

    Any chance of a doc patch to make it easier for the next poor soul
    who
    gets stuck on this?
    Sure. Where would you like it?
    A 'NOTES' or 'CAVEATS' section in the POD for Catalyst::View::TT is
    the best place I can think of right now.

    Write something and it can go somewhere else if anyone has a better
    idea?

    Cheers
    t0m
  • Gunnar Strand at Jul 8, 2009 at 3:19 pm

    Gordon Yeong skrev:
    hi there

    I am facing almost the same issue in that even clicking the "stop"
    button on firefox would see no difference in the debugging terminal or
    have a response from the webpage.
    When i have safari accesssing the same page, i can submit without a
    problem and the server doesn't hang.

    Any thoughts?

    thanks

    gordon
    I turned on debugging in the local TT.pm in myApp as you describe below.
    I accessed the page on the application's server with Firefox only.
    Didn't try any other browser.

    In my case, the request was aborted and the server returned to normal
    after I clicked "Stop" in Firefox. So it only hung until then. I guess
    you can try to press Ctrl-D in the terminal window to get it to continue
    in case the server is waiting for input, but I never tried that (didn't
    think of it). At least you would know if that is the problem.

    I also tried running the server under a debugger (perl -d:ptkdb
    script/myapp_server.pl), but wasn't really getting me anywhere since I
    know too little about Catalyst/TT internals.

    KR,
    Gunnar
    2009/7/8 Gordon Yeong <anexiole@gmail.com

    hi there

    I think i am facing the same fault.
    hmmm... When you mention TT.pm, do you mean the local TT.pm found in
    myApp/View/TT.pm or is it the TT.pm belonging to the Template
    Toolkit package?

    thanks

    Regards,
    Gordon Yeong


    2009/7/3 Gunnar Strand <gunnarstrand@yahoo.com

    I found the problem. Turning on debugging for TT (DEBUG =>
    DEBUG_ALL) in TT.pm showed that it hangs on the [% USE CGI %]
    directive. Apparently

    [% USE CGI('-no_debug') %]

    is needed. Got it from here:

    https://bugzilla.mozilla.org/show_bug.cgi?id7589

    Seems CGI thinks that it is begin run from command line and
    prompts for data.

    KR,
    Gunnar
    ------------------------------------------------------------------------
    *From:* Gunnar Strand <gunnarstrand@yahoo.com
    *To:* The elegant MVC web framework
    <catalyst@lists.scsys.co.uk *Sent:* Monday, June 29, 2009 6:39:41 AM
    *Subject:* Re: [Catalyst] Hangs in RenderView in "end"
    Is there any way of running the server in a debugger or to
    turn tracing on? Can I send a signal to it to get it to >dump
    a stack trace somehow? Any attempt I've made so far just
    results in nothing or segmentation faults.
    [...]

    I don't understand why you're seeing segfaults. What version
    of Catalyst are you using, what is your perl -V, and do you
    have the latest version of Variable::Magic installed? Also, if
    you could attach gdb and get the catalyst process to segfault,
    then a backtrace from c land could be useful.

    The debugger works now(!). I've always had problems with it
    but hadn't tried it for a while. Maybe a library got updated.

    Thanks for the tips!

    KR,
    Gunnar

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo:
    http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/



    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo:
    http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

  • Gunnar Strand at Jul 9, 2009 at 6:45 am
    Tomas Doran skrev:
    On 6 Jul 2009, at 05:33, Gunnar Strand wrote:

    Wow, that's a fairly unexpected gotcha.

    Any chance of a doc patch to make it easier for the next poor soul who
    gets stuck on this?
    Sure. Where would you like it?
    A 'NOTES' or 'CAVEATS' section in the POD for Catalyst::View::TT is
    the best place I can think of right now.

    Write something and it can go somewhere else if anyone has a better idea?
    Here's what I wrote, and I've attached a patch for
    Catalyst::View::TT.pm. I'm very inexperienced using patches, so let me
    know if you want it in any other way.

    =head1 NOTES

    If you are using the L<CGI> module inside your templates, and you
    experience that the Catalyst server appears to hang while rendering
    the web page, then it may be due to the debug mode of L<CGI> (which is
    waiting for input in the terminal window). You can try turning off the
    debug mode using the "-no_debug" option and see if that solves you
    problem, eg.:

    [% USE CGI('-no_debug') %]



    KR,
    Gunnar
    Cheers
    t0m


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/







    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: cgi_debug.patch
    Type: application/octet-stream
    Size: 860 bytes
    Desc: not available
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090708/4c470ef0/cgi_debug.obj
  • Tomas Doran at Jul 12, 2009 at 12:06 am

    On 9 Jul 2009, at 07:45, Gunnar Strand wrote:
    Here's what I wrote, and I've attached a patch for
    Catalyst::View::TT.pm. I'm very inexperienced using patches, so let me
    know if you want it in any other way.
    I changed the wording slightly to be a little more affirmative and
    applied:

    http://dev.catalystframework.org/svnweb/Catalyst/revision?rev862

    Thanks very much!

    Cheers
    t0m

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJun 28, '09 at 6:35a
activeJul 16, '09 at 11:09p
posts24
users5
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase