FAQ
I'm having a hell of a time trying to track down the reasons
for this error.

I'm getting an error that looks like:

Use of uninitialized value $buffer in concatenation (.) or
string at /usr/share/perl5/Catalyst/Engine/CGI.pm line 220.

If I'm using the HTTP.pm Engine, I get the same error, but
with a different line number; in both cases, it's the line
beginning with "$buffer" in the $self->write method, which
looks like this in CGI.pm:

---
around write => sub {
my $orig = shift;
my ( $self, $c, $buffer ) = @_;

# Prepend the headers if they have not yet been sent
if ( $self->_has_header_buf ) {
$buffer = $self->_clear_header_buf . $buffer;
}

return $self->$orig( $c, $buffer );
};
---

I will say upfront that I don't know how to use the Perl
debugger.

I have tried a lot of way to isolate this, and just can't
figure out what's causing it. It does not happen on certain
requests; for example, if I deliberately enter an incorrect
password on a login page, I don't get it. But it happens on
almost all other requests; I don't see where in the
bogus-login cycle I might be avoiding something that could
short-circuit this. I've looked over my code fairly closely,
and I can't detect the pattern, or see anything that could be
causing this.

I should also note that this doesn't appear to have any effect
on my program; it "works" fine, I see all the pages, etc.

I'd be grateful if anyone could explain to me what might be
causing this, or where I can look to try to figure it out.

This is on Cat 5.80005 on Debian, with all modules up to date.

Thanks.

Jesse

Search Discussions

  • Merlyn Kline at Jun 22, 2009 at 9:18 am

    I'm getting an error that looks like:

    Use of uninitialized value $buffer in concatenation (.) or
    string at /usr/share/perl5/Catalyst/Engine/CGI.pm line 220.
    Deep in my job list I have some notes surrounding this issue saying that I
    need to investigate further and possibly submit a patch or two.
    Unfortunately these notes (a) refer to an old version of Catalyst using
    FastCGI and (b) turn out not to be quite as lucid as I'd recalled them
    being. Basically, though, the obvious proximal cause of this would be
    calling the write method with no parameter. This might seem an odd thing to
    do but might be as a result of a loop writing something in chunks and
    getting an empty chunk at the end or, as in my case, might be an attempt to
    work around a related problem where the simple concatenation of the buffer
    to the headers (as in the code you cited, below) causes problems because the
    headers are not UTF8 encoded and the buffer is, so perl tries to fix the
    encoding and ends up with the wrong thing - calling write() with no
    parameters (or, in later bodges, an empty string) fixes this by flushing the
    headers into the output stream before the buffer is concatenated to them.

    Hope this is a useful clue.

    Merlyn

    ---
    around write => sub {
    my $orig = shift;
    my ( $self, $c, $buffer ) = @_;

    # Prepend the headers if they have not yet been sent
    if ( $self->_has_header_buf ) {
    $buffer = $self->_clear_header_buf . $buffer;
    }

    return $self->$orig( $c, $buffer );
    };
    ---
  • Jesse Sheidlower at Jun 26, 2009 at 3:31 pm

    On Mon, Jun 22, 2009 at 10:18:40AM +0100, Merlyn Kline wrote:
    I'm getting an error that looks like:

    Use of uninitialized value $buffer in concatenation (.) or
    string at /usr/share/perl5/Catalyst/Engine/CGI.pm line 220.
    Deep in my job list I have some notes surrounding this issue saying that I
    need to investigate further and possibly submit a patch or two.
    Unfortunately these notes (a) refer to an old version of Catalyst using
    FastCGI and (b) turn out not to be quite as lucid as I'd recalled them
    being. Basically, though, the obvious proximal cause of this would be
    calling the write method with no parameter. This might seem an odd thing to
    do but might be as a result of a loop writing something in chunks and
    getting an empty chunk at the end or, as in my case, might be an attempt to
    work around a related problem where the simple concatenation of the buffer
    to the headers (as in the code you cited, below) causes problems because the
    headers are not UTF8 encoded and the buffer is, so perl tries to fix the
    encoding and ends up with the wrong thing - calling write() with no
    parameters (or, in later bodges, an empty string) fixes this by flushing the
    headers into the output stream before the buffer is concatenated to them.

    Hope this is a useful clue.
    I'm afraid this isn't too helpful for me at least; in this
    case I'm just an end user, not doing anything fancy here, so
    if there's a problem with buffer manipulation, I don't think
    it's because of something I'm doing.

    Grr.

    Jesse Sheidlower
    ---
    around write => sub {
    my $orig = shift;
    my ( $self, $c, $buffer ) = @_;

    # Prepend the headers if they have not yet been sent
    if ( $self->_has_header_buf ) {
    $buffer = $self->_clear_header_buf . $buffer;
    }

    return $self->$orig( $c, $buffer );
    };
    ---
  • Merlyn Kline at Jun 26, 2009 at 4:06 pm

    being. Basically, though, the obvious proximal cause of this would be
    calling the write method with no parameter. This might seem an
    [snip]
    I'm afraid this isn't too helpful for me at least; in this
    case I'm just an end user, not doing anything fancy here, so
    Presumably you *aren't*, in fact, calling the write method with no
    parameters (or an undef), accidentally or otherwise?

    Or perhaps another way to trigger this would be to set some headers and then
    never call the write method, so the attempt to flush the headers would end
    up in the code you cited with no buffer defined.

    Merlyn
  • Tomas Doran at Jun 28, 2009 at 2:20 pm

    On 26 Jun 2009, at 17:06, Merlyn Kline wrote:

    being. Basically, though, the obvious proximal cause of this
    would be
    calling the write method with no parameter. This might seem an
    [snip]
    I'm afraid this isn't too helpful for me at least; in this
    case I'm just an end user, not doing anything fancy here, so
    Presumably you *aren't*, in fact, calling the write method with no
    parameters (or an undef), accidentally or otherwise?

    Or perhaps another way to trigger this would be to set some headers
    and then
    never call the write method, so the attempt to flush the headers
    would end
    up in the code you cited with no buffer defined.
    I'd be adding something like this to your MyApp.pm:

    use Moose; # To the top :)

    # N.B. This has to go after __PACKAGE__->setup;
    before 'write' => sub {
    my ($self, $buf) = @_;
    Carp::cluck("write method called with undef buffer") if !defined
    $buf;
    };

    This should at least prove or disprove the 'write with undef' theory
    (you should see the warning, and a stack trace just before your
    undefined value warning), and should give you some insight into
    whodunnit from the stack trace if the hypothesis is true..

    Cheers
    t0m
  • Tomas Doran at Jun 30, 2009 at 8:40 pm

    On 20 Jun 2009, at 15:32, Jesse Sheidlower wrote:
    I'm having a hell of a time trying to track down the reasons
    for this error.

    I'm getting an error that looks like:

    Use of uninitialized value $buffer in concatenation (.) or
    string at /usr/share/perl5/Catalyst/Engine/CGI.pm line 220.
    For the benefit of the list, this is now fixed.

    http://dev.catalystframework.org/svnweb/Catalyst/revision?rev745
    http://dev.catalystframework.org/svnweb/Catalyst/revision?rev746

    Merlyn was exactly right, write was being called with undef, due to
    FillInForm setting the response body to undef.

    New release of FillInForm will follow shortly, and this will be fixed
    in the general case in the next Catalyst.

    What are people's thoughts about adding a specific warning if you try
    to write undef? (As you could still cause this warning by doing that
    explicitly)

    Cheers
    t0m
  • Merlyn Kline at Jul 1, 2009 at 9:11 am

    What are people's thoughts about adding a specific warning if you try
    to write undef? (As you could still cause this warning by doing that
    explicitly)
    Depends why you might do this - if it's legitimate (e.g. to force the
    headers to be flushed?) then it should be handled silently. Otherwise, a
    warning would seem sensible.

    I guess this is linked to the other thing I mentioned - the code here seems
    to just prepend the headers to the buffer but the headers are not (supposed
    to be?) UTF8 encoded whereas the buffer probably is so confusion can ensue.
    That's why I originally called write with no params (to flush the unencoded
    headers and work around that problem) and so recognised the symptom. As I
    said before though, that was all with rather an old Catalyst and I don't
    know the current state of play WRT all that.

    Merlyn
  • Tomas Doran at Jul 12, 2009 at 12:57 am

    On 1 Jul 2009, at 10:11, Merlyn Kline wrote:

    What are people's thoughts about adding a specific warning if you try
    to write undef? (As you could still cause this warning by doing that
    explicitly)
    Depends why you might do this - if it's legitimate (e.g. to force the
    headers to be flushed?) then it should be handled silently.
    Otherwise, a
    warning would seem sensible.
    Yeah, it totally is sane, for just that reason, and the warning is in
    Engine::HTTP (so the dev server), but not in other engines..

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

    Fixed!

    Cheers
    t0m

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJun 20, '09 at 2:32p
activeJul 12, '09 at 12:57a
posts8
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase