Re^4: XML::Twig too many children?

5.14.2 i686-linux-thread-multi with -Doptimize=-g didn't reveal much more.

Program received signal SIGSEGV, Segmentation fault.
0x08111b83 in Perl_sv_force_normal_flags (my_perl=0x81ca008, sv=0x85cd
+630, flags=1) at sv.c:4800
4800            sv_unref_flags(sv, flags);
(gdb) bt
#0  0x08111b83 in Perl_sv_force_normal_flags (my_perl=0x81ca008, sv=0x
+85cd630, flags=1) at sv.c:4800
#1  0x0813f7dd in Perl_leave_scope (my_perl=0x81ca008, base=74) at sco
+pe.c:900
#2  0x0813d4ac in Perl_pop_scope (my_perl=0x1) at scope.c:110
#3  0x08148cac in Perl_pp_return (my_perl=0x81ca008) at pp_ctl.c:2365
#4  0x080fd77e in Perl_runops_standard (my_perl=0x81ca008) at run.c:41
#5  0x0807d13e in Perl_call_sv (my_perl=0x81ca008, sv=0x85cd5e0, flags
+=45) at perl.c:2647
#6  0x08114ca6 in S_curse (my_perl=0x81ca008, sv=0x90740a0, check_refc
+nt=1 '\001') at sv.c:6342
#7  0x08114032 in Perl_sv_clear (my_perl=0x81ca008, orig_sv=0x90741a0)
+ at sv.c:6073
#8  0x081151b1 in Perl_sv_free2 (my_perl=0x81ca008, sv=0x90741a0) at s
+v.c:6474
#9  0x080f6afb in Perl_hv_free_ent (my_perl=0x81ca008, hv=0x9073fb0, e
+ntry=0x9074c14) at hv.c:1487
#10 0x080f7c1b in S_hfreeentries (my_perl=0x81ca008, hv=0x9073fb0) at 
+hv.c:1805
#11 0x080f8021 in Perl_hv_undef_flags (my_perl=0x81ca008, hv=0x9073fb0
+, flags=2) at hv.c:1892
#12 0x081142d6 in Perl_sv_clear (my_perl=0x81ca008, orig_sv=0x90740b0)
+ at sv.c:6125
#13 0x081151b1 in Perl_sv_free2 (my_perl=0x81ca008, sv=0x90740b0) at s
+v.c:6474
...
#72739 0x080f6afb in Perl_hv_free_ent (my_perl=0x81ca008, hv=0x875d3b0
+, entry=0x81ed1f4) at hv.c:1487
#72740 0x080f7c1b in S_hfreeentries (my_perl=0x81ca008, hv=0x875d3b0) 
+at hv.c:1805
#72741 0x080f8021 in Perl_hv_undef_flags (my_perl=0x81ca008, hv=0x875d
+3b0, flags=2) at hv.c:1892
#72742 0x081142d6 in Perl_sv_clear (my_perl=0x81ca008, orig_sv=0x875d4
+e0) at sv.c:6125
#72743 0x081151b1 in Perl_sv_free2 (my_perl=0x81ca008, sv=0x875d4e0) a
+t sv.c:6474
#72744 0x080f6afb in Perl_hv_free_ent (my_perl=0x81ca008, hv=0x875d310
+, entry=0x81ed170) at hv.c:1487
#72745 0x080f7c1b in S_hfreeentries (my_perl=0x81ca008, hv=0x875d310) 
+at hv.c:1805
#72746 0x080f8021 in Perl_hv_undef_flags (my_perl=0x81ca008, hv=0x875d
+310, flags=2) at hv.c:1892
#72747 0x081142d6 in Perl_sv_clear (my_perl=0x81ca008, orig_sv=0x875d3
+d0) at sv.c:6125
#72748 0x081151b1 in Perl_sv_free2 (my_perl=0x81ca008, sv=0x875d3d0) a
+t sv.c:6474
#72749 0x080f6afb in Perl_hv_free_ent (my_perl=0x81ca008, hv=0x875d200
+, entry=0x81ed0d4) at hv.c:1487
#72750 0x080f7c1b in S_hfreeentries (my_perl=0x81ca008, hv=0x875d200) 
+at hv.c:1805
#72751 0x080f8021 in Perl_hv_undef_flags (my_perl=0x81ca008, hv=0x875d
+200, flags=2) at hv.c:1892
#72752 0x081142d6 in Perl_sv_clear (my_perl=0x81ca008, orig_sv=0x875d2
+00) at sv.c:6125
#72753 0x081151b1 in Perl_sv_free2 (my_perl=0x81ca008, sv=0x875d200) a
+t sv.c:6474
#72754 0x0811b60c in Perl_sv_unref_flags (my_perl=0x1, ref=0x83fe490, 
+flags=1) at sv.c:9552
#72755 0x08111b93 in Perl_sv_force_normal_flags (my_perl=0x81ca008, sv
+=0x83fe490, flags=1) at sv.c:4800
#72756 0x0813f7dd in Perl_leave_scope (my_perl=0x81ca008, base=59) at 
+scope.c:900
#72757 0x0813d4ac in Perl_pop_scope (my_perl=0x1) at scope.c:110
#72758 0x08148cac in Perl_pp_return (my_perl=0x81ca008) at pp_ctl.c:23
+65
#72759 0x080fd77e in Perl_runops_standard (my_perl=0x81ca008) at run.c
+:41
#72760 0x0807d01c in Perl_call_sv (my_perl=0x81ca008, sv=0x84576f0, fl
+ags=6) at perl.c:2632
#72761 0xb7ab2d64 in endElement (userData=0x8466e68, name=0x873bc58 "l
+emma") at Expat.xs:575
#72762 0xb7a90a55 in ?? () from /usr/lib/../lib/libexpat.so.1
#72763 0xb7a918a1 in ?? () from /usr/lib/../lib/libexpat.so.1
#72764 0xb7a92db1 in ?? () from /usr/lib/../lib/libexpat.so.1
#72765 0xb7a9396a in ?? () from /usr/lib/../lib/libexpat.so.1
#72766 0xb7a8a64c in XML_ParseBuffer () from /usr/lib/../lib/libexpat.
+so.1
#72767 0xb7a8bab5 in XML_Parse () from /usr/lib/../lib/libexpat.so.1
#72768 0xb7aba485 in XS_XML__Parser__Expat_ParseString (my_perl=0x81ca
+008, cv=0x82cdb70) at Expat.xs:1446
#72769 0x08108852 in Perl_pp_entersub (my_perl=0x81ca008) at pp_hot.c:
+3046
#72770 0x080fd77e in Perl_runops_standard (my_perl=0x81ca008) at run.c
+:41
#72771 0x0807c93f in S_run_body (my_perl=0x81ca008, oldscope=1) at per
+l.c:2350
#72772 0x0807c4c5 in perl_run (my_perl=0x81ca008) at perl.c:2268
#72773 0x0805feed in main (argc=2, argv=0xbffff0d4, env=0xbffff0e0) at
+ perlmain.c:120
[download]

It wouldn't hurt to include this in your bug report, but file it with XML::Parser, not XML::Twig.

Comment on Re^4: XML::Twig too many children? Download Code

Replies are listed 'Best First'.
Re^5: XML::Twig too many children? by ikegami (Patriarch) on Feb 22, 2012 at 01:00 UTC
Yup, it's a stack overflow: `$ valgrind perl a.pl ==17235== Memcheck, a memory error detector ==17235== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et +al. ==17235== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h fo +r copyright info ==17235== Command: perl a.pl ==17235== ==17235== Stack overflow in thread 1: can't grow stack to 0xbe01ef78 ==17235== ...` [download] The more I think about it, the less I think it's a bug in XML::Parser. I think it's a bug in how Perl destroys deeply nested structures, which may or may not be fixable. There are few places where the C code that forms `perl` itself recurses, and those can lead to overflows of the limited-sized "C stack" (as opposed to the "Perl stack" the script uses), and this appears to be one of them. Updated after I remembered valgrind.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: XML::Twig too many children?
by ikegami (Patriarch) on Feb 22, 2012 at 01:00 UTC

Yup, it's a stack overflow:

$ valgrind perl a.pl
==17235== Memcheck, a memory error detector
==17235== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et 
+al.
==17235== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h fo
+r copyright info
==17235== Command: perl a.pl
==17235== 
==17235== Stack overflow in thread 1: can't grow stack to 0xbe01ef78
==17235== 
...
[download]

The more I think about it, the less I think it's a bug in XML::Parser. I think it's a bug in how Perl destroys deeply nested structures, which may or may not be fixable.

There are few places where the C code that forms perl itself recurses, and those can lead to overflows of the limited-sized "C stack" (as opposed to the "Perl stack" the script uses), and this appears to be one of them.

Updated after I remembered valgrind.

[reply]
[d/l]
[select]