Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the HTML-FormHandler CPAN distribution.

Report information
The Basics
Id: 92411
Status: open
Priority: 0/
Queue: HTML-FormHandler

People
Owner: Nobody in particular
Requestors: KENTNL [...] cpan.org
zefram [...] fysh.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: memory bug on 5.19.7+
Date: Thu, 23 Jan 2014 15:31:12 +0000
To: bug-HTML-FormHandler [...] rt.cpan.org
From: Zefram <zefram [...] fysh.org>
On Perl 5.19.7 and 5.19.8, HTML-FormHandler-0.40055 is failing its tests for me, with memory-related problems. I've seen this on 5.19.7: t/fields/repeatable.t ................... 1/? perl: malloc.c:4538: _int_malloc: Assertion `victim->fd_nextsize->bk_nextsize == victim' failed. t/fields/repeatable.t ................... All 3 subtests passed And these two failure modes on 5.19.8: t/fields/repeatable.t ................... 1/? perl: malloc.c:4636: _int_malloc: Assertion `victim->fd_nextsize->bk_nextsize == victim' failed. t/fields/repeatable.t ................... All 2 subtests passed panic: attempt to copy freed scalar 9a07b7c to 9bc935c at /opt/perl-5.19.8/lib/site_perl/5.19.8/i686-linux-64int-ld/Class/MOP/Method/Wrapped.pm line 163. # Tests were run but no plan was declared and done_testing() was not seen. # Looks like your test exited with 255 just after 2. Attempt to free unreferenced scalar: SV 0x9a07b7c during global destruction. t/fields/repeatable.t ................... Dubious, test returned 255 (wstat 65280, 0xff00) All 2 subtests passed 5.19.7 introduced a memory bug, which was noted to affect Test-Without-Module [perl #120657]. I initially thought HTML-FormHandler was a victim of the same bug. But that bug was supposedly fixed in 5.19.8, and Test-Without-Module duly works again, but HTML-FormHandler is still broken. It could be a bug in HTML-FormHandler, a different core bug, or the same core bug having not been properly fixed. -zefram
Sill broken on 5.19.9 and seeing failures from in on bleed on cpan testers.

Here's a  gdb backtrace from a debug perl.

looks like the trigger is in op.c
Subject: gdb.txt
Thread 1 (process 869681): #0 0x00007ffff6f14535 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007ffff6f159b8 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007ffff6f59f3a in __malloc_assert () from /lib64/libc.so.6 No symbol table info available. #3 0x00007ffff6f5ccd5 in _int_malloc () from /lib64/libc.so.6 No symbol table info available. #4 0x00007ffff6f5e974 in calloc () from /lib64/libc.so.6 No symbol table info available. #5 0x000000000042503c in S_new_slab (sz=128) at op.c:146 slab = <optimized out> #6 Perl_Slab_Alloc (sz=12) at op.c:240 slab = 0x8e0c30 slab2 = <optimized out> slot = <optimized out> o = <optimized out> opsz = 10 space = <optimized out> __PRETTY_FUNCTION__ = "Perl_Slab_Alloc" #7 0x000000000042c168 in Perl_newSTATEOP (flags=0, label=0x0, o=0x0) at op.c:5963 seq = 22246 utf8 = 0 cop = <optimized out> __PRETTY_FUNCTION__ = "Perl_newSTATEOP" #8 0x000000000043c015 in Perl_utilize (aver=<optimized out>, floor=168, version=<optimized out>, idop=0x8e1b48, arg=<optimized out>) at op.c:5402 pack = <optimized out> imop = <optimized out> veop = <optimized out> use_version = 0x0 #9 0x0000000000482aa7 in Perl_yyparse (gramtype=gramtype@entry=258) at perly.y:398 yystate = <optimized out> yyn = 34 yyresult = <optimized out> yytoken = 20 parser = 0x22581a0 ps = 0x8df480 yyval = <optimized out> #10 0x000000000054c605 in S_doeval (gimme=gimme@entry=2, outside=outside@entry=0x0, seq=<optimized out>, hh=hh@entry=0x0) at pp_ctl.c:3475 sp = 0x25e76b8 saveop = 0xb4e8c8 clear_hints = <optimized out> oldcurcop = <optimized out> in_require = true yystatus = <optimized out> evalcv = 0x25e6298 __PRETTY_FUNCTION__ = "S_doeval" #11 0x000000000055f1a1 in Perl_pp_require () at pp_ctl.c:4131 sp = 0x25e76b8 cx = <optimized out> sv = <optimized out> name = <optimized out> len = 19 unixname = <optimized out> unixlen = 19 tryname = 0x8e2ba0 "lib/HTML/FormHandler.pm" namesv = <optimized out> gimme = 2 filter_has_file = <optimized out> tryrsfp = 0x8c8e60 filter_cache = <optimized out> filter_state = <optimized out> filter_sub = <optimized out> hook_sv = <optimized out> encoding = 0x0 op = <optimized out> saved_errno = <optimized out> path_searchable = true __PRETTY_FUNCTION__ = "Perl_pp_require" #12 0x00000000004c2dca in Perl_runops_debug () at dump.c:2420 No locals. #13 0x000000000044b7f9 in S_run_body (oldscope=1) at perl.c:2444 No locals. #14 perl_run (my_perl=<optimized out>) at perl.c:2365 oldscope = 1 ret = <optimized out> cur_env = {je_prev = 0x8b6b40 <PL_start_env>, je_buf = {{__jmpbuf = {0, -6199615863609367576, 4336116, 140737488342816, 0, 0, 6199615861954700264, -6199615342113463320}, __mask_was_saved = 0, __saved_mask = {__val = {0, 9182208, 6, 9146264, 1, 13, 148565664, 0, 0, 5267746, 0, 4336116, 6279040, 4793511, 0, 140737353774760}}}}, je_ret = 3, je_mustcatch = false} __PRETTY_FUNCTION__ = "perl_run" #15 0x00000000004229e5 in main (argc=4, argv=0x7fffffffcf28, env=0x7fffffffcf50) at perlmain.c:112 exitstatus = <optimized out> i = <optimized out> quit A debugging session is active. Inferior 1 [process 869681] will be killed. Quit anyway? (y or n)

Seems you can reduce the code, a few observations:

replace 'use_ok' with 'require'  = no problem
replace 'use_ok' with use = FAIL
replace 'use_ok' with require && import = no problem
replace 'use_ok' with BEGIN { require && import } = FAIL
replace 'use_ok' with BEGIN { require  } = FAIL

Avoid calling: $field->init_state == no memory problem

And avoiding calling  `` extends 'HTML::FormHandler' `` == no memory problem.

The place it fails in the Perl OP Stack is:

(/home/kent/perl5/perlbrew/perls/perl-5.19.9/lib/site_perl/5.19.9/Module/Runtime.pm:267)    padsv($name)
(/home/kent/perl5/perlbrew/perls/perl-5.19.9/lib/site_perl/5.19.9/Module/Runtime.pm:267)    const(PV(".pm"\0))
(/home/kent/perl5/perlbrew/perls/perl-5.19.9/lib/site_perl/5.19.9/Module/Runtime.pm:267)    concat
(/home/kent/perl5/perlbrew/perls/perl-5.19.9/lib/site_perl/5.19.9/Module/Runtime.pm:267)    leavesub
(/home/kent/perl5/perlbrew/perls/perl-5.19.9/lib/site_perl/5.19.9/Module/Runtime.pm:317)    require
perl: malloc.c:3523: _int_malloc: Assertion `victim->fd_nextsize->bk_nextsize == victim' failed.

Triggered from the last 'extends' in the test.

Seems there  is something going on with ->create_element

And oddly, if you change the ->create_element call to happen in void context, you instead get:

*** Error in `perl': corrupted double-linked list: 0x0000000001d61b40 ***


( And again, you don't get the error without the "require HTML::FormHandler"  )

Also, moving the require statement to above the ->create_element call makes the problem vanish.






 

Subject: fail.t
use strict; use warnings; use Test::More; BEGIN { require HTML::FormHandler::Field::Repeatable; } # test to verify that contains hashref passed in to construction of # a repeatable field is used to build the 'contains' field my $args = { name => 'test_field', init_contains => { wrapper_class => ['hfh', 'repinst'] }, }; my $field = HTML::FormHandler::Field::Repeatable->new( %$args ); $field->contains( # Comment this $field->create_element ) # And this for a double-linked-list corruption ; require HTML::FormHandler; # Move up, earlier, problem will vanish. pass('ok'); done_testing;
I'm starting to get a feeling this is messed up in a special way.

cloning an object causing list util to mess up loading XS? Wut?

Subject: fail.t
use strict; use warnings; use Test::More; BEGIN { require HTML::FormHandler::Field::Repeatable; } # ## test to verify that contains hashref passed in to construction of # a repeatable field is used to build the 'contains' field my $args = { name => 'test_field', init_contains => { wrapper_class => [ 'hfh', 'repinst' ] }, }; my $field = HTML::FormHandler::Field::Repeatable->new(%$args); use Data::Clone qw(clone); $field->contains( clone ( $field ) ); eval "use List::Util"; # fails here pass('ok'); done_testing;
Sweet, the patch here fixes the failure!

https://rt.cpan.org/Ticket/Display.html?id=92570