Segfault when using Data::Dumper #10

Closed
bfg opened this Issue Jul 4, 2011 · 3 comments

Comments

Projects
None yet
3 participants
@bfg

bfg commented Jul 4, 2011

The following code causes process segfault:

#!/usr/bin/perl

use strict;
use warnings;
use Data::Dumper;

sub { return [ 200, [ 'Content-Type', 'text/plain' ], [ "Hello world!\n" . Dumper($_[0]) ]] }

Opensuse 11.4 32bit, linux 2.6.37, ev 4.03, perl 5.12.3 (threads enabled).

Tested with curl:

  • first request: empty response
  • second requrest: empty response
  • third request: correct output
  • 4th request: segfault

Process output:

$ feersum --listen :9002 app.pl 
Feersum try_conn_write: Bad file descriptor
close at write shutdown: Bad file descriptor
^C
$ feersum --listen :9002 app.pl 
Segmentation fault

GDB stack trace:

(gdb) bt
#0  0xb7456718 in psgix_io_svt_get (my_perl=0x830d008, sv=0x85d08c4, mg=0x85d9354) at Feersum.xs:2103
#1  0x08106071 in Perl_mg_get ()
#2  0xb7426834 in DD_dump (my_perl=0x830d008, val=0x85d08c4, name=0x85dc0cc "$VAR1->{'psgix.io'}", namelen=19, retval=0x858b184, seenhv=0x858b704, postav=0x85d0a64, levelp=0xbf809128, indent=2, pad=0x858b574, xpad=0x858b014, 
    apad=0x858b664, sep=0x858b094, pair=0x85d0bd4, freezer=0x858b414, toaster=0x858b424, purity=0, deepcopy=0, quotekeys=1, bless=0x858b5f4, maxdepth=0, sortkeys=0x0) at Dumper.xs:307
#3  0xb7429aaf in DD_dump (my_perl=0x830d008, val=0x858b664, name=0x85d9544 "$VAR1", namelen=5, retval=0x858b184, seenhv=0x858b704, postav=0x85d0a64, levelp=0xbf809128, indent=2, pad=0x858b574, xpad=0x858b014, apad=0x858aef4, 
    sep=0x858b094, pair=0x85d0bd4, freezer=0x858b414, toaster=0x858b424, purity=0, deepcopy=0, quotekeys=1, bless=0x858b5f4, maxdepth=0, sortkeys=0x0) at Dumper.xs:789
#4  0xb742ecdc in XS_Data__Dumper_Dumpxs (my_perl=0x830d008, cv=0x85895c4) at Dumper.xs:1196
#5  0x08133820 in Perl_pp_entersub ()
#6  0x080f9172 in Perl_runops_debug ()
#7  0x08083bb8 in Perl_call_sv ()
#8  0xb7463b63 in call_request_callback () at Feersum.xs:1931
#9  process_request_ready_rinq () at Feersum.xs:732
#10 0xb7486f93 in ev_invoke_pending (loop=0xb74eb820) at libev/ev.c:2117
#11 0xb74c5f39 in ev_run (loop=0xb74eb820, flags=0) at libev/ev.c:2483
#12 0xb74c727f in XS_EV_run (my_perl=0x830d008, cv=0x835c1d4) at EV.c:827
#13 0x08133820 in Perl_pp_entersub ()
#14 0x080f9172 in Perl_runops_debug ()
#15 0x0808c05c in perl_run ()
#16 0x0806493d in main ()
(gdb) 
@audreyt

This comment has been minimized.

Show comment
Hide comment
@audreyt

audreyt Jul 5, 2011

Collaborator

Confirmed; this is because $env->{'psgix.io'} did not survive a mg_get(). It's a legitimate issue.

FWIW, Data::Dumper would work correctly if $env->{'psgix.io'} was first deleted -- I had to work around that for Mojo in kraih/mojo#152 .

Collaborator

audreyt commented Jul 5, 2011

Confirmed; this is because $env->{'psgix.io'} did not survive a mg_get(). It's a legitimate issue.

FWIW, Data::Dumper would work correctly if $env->{'psgix.io'} was first deleted -- I had to work around that for Mojo in kraih/mojo#152 .

@BlueT

This comment has been minimized.

Show comment
Hide comment
@BlueT

BlueT Jul 16, 2013

I think this issue could be closed. (if stash's still here....)

BlueT commented Jul 16, 2013

I think this issue could be closed. (if stash's still here....)

@audreyt

This comment has been minimized.

Show comment
Hide comment
@audreyt

audreyt Jul 16, 2013

Collaborator

Hi BlueT, do you mean that it's been fixed by an upstream module e.g. Plack?

Collaborator

audreyt commented Jul 16, 2013

Hi BlueT, do you mean that it's been fixed by an upstream module e.g. Plack?

@audreyt audreyt closed this Nov 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment