glibc detected *** /usr/bin/perl: corrupted double-linked list (was 5.10, is now 5.16.2)

p5pRT commented 14 years ago

Migrated from rt.perl.org#78728 (status was 'resolved')

Searchable as RT78728$

p5pRT commented 14 years ago

From lawalsh@tlinx.org

Created by lawalsh@tlinx.org

Running a long HTML parse program -- about 1665 lines long that is in primary development. If I could figure out how to add an attachment\, I could attach one here. It processes a local data file though it can try to download files as guest from a website. I don't believe it actually downloads any files before crashing.

It is sensitive to the input file -- since running it twice in a row doesn't create the coredump. I have to 'restore' my input file to freshly downloaded file\, (i.e. my perl program modifies the data file\, thus a 2nd run doesn't follow the same execution as the first).

I also have a core (6.6M uncompressed) file to add somewhere\, compressed: 7z:860K\, gz:1.3M\, bz2:1.1M).

Traceback\, will include here:


*** glibc detected *** /usr/bin/perl: corrupted double-linked list: 0x0000000001bfeab0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x73226)[0x7f00c7628226]
/lib64/libc.so.6(+0x75cb0)[0x7f00c762acb0]
/lib64/libc.so.6(__libc_malloc+0x79)[0x7f00c762caa9]
/usr/bin/perl(Perl_safesysmalloc+0x4d)[0x45ca0d]
/usr/bin/perl(Perl_sv_grow+0xf8)[0x496208]
/usr/bin/perl(Perl_sv_setpvn+0x18c)[0x4996ac]
/usr/bin/perl(Perl_newSVpvn+0x56)[0x4998d6]
/usr/bin/perl[0x45daab]
/usr/bin/perl[0x45b4f2]
/usr/bin/perl(Perl_vcroak+0x1e)[0x45b64e]
/usr/bin/perl(Perl_safesysmalloc+0x0)[0x45c9c0]
/usr/bin/perl(Perl_sv_unref_flags+0x19b)[0x49348b]
/usr/bin/perl(Perl_sv_chop+0x227)[0x498b47]
/usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/HTML/Parser/Parser.so(+0xc0bb)[0x7f00c432c0bb]
/usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/HTML/Parser/Parser.so(XS_HTML__Parser_parse+0x113)[0x7f00c432c873]
/usr/bin/perl(Perl_pp_entersub+0x5ba)[0x47ca4a]
/usr/bin/perl(Perl_runops_debug+0x134)[0x454c84]
/usr/bin/perl(perl_run+0x454)[0x478c74]
/usr/bin/perl(main+0xdc)[0x42176c]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f00c75d3b7d]
/usr/bin/perl[0x4215c9]
======= Memory map: ========
00400000-00586000 r-xp 00000000 08:26 39250758 /usr/bin/perl
00785000-00786000 r--p 00185000 08:26 39250758 /usr/bin/perl
00786000-0078a000 rw-p 00186000 08:26 39250758 /usr/bin/perl
01702000-01cc0000 rw-p 00000000 00:00 0 [heap]
7f00c0000000-7f00c0021000 rw-p 00000000 00:00 0
7f00c0021000-7f00c4000000 ---p 00000000 00:00 0
7f00c4109000-7f00c411f000 r-xp 00000000 08:21 40262764 /lib64/libgcc_s.so.1
7f00c411f000-7f00c431e000 ---p 00016000 08:21 40262764 /lib64/libgcc_s.so.1
7f00c431e000-7f00c431f000 r--p 00015000 08:21 40262764 /lib64/libgcc_s.so.1
7f00c431f000-7f00c4320000 rw-p 00016000 08:21 40262764 /lib64/libgcc_s.so.1
7f00c4320000-7f00c4331000 r-xp 00000000 08:26 17264503 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/HTML/Parser/Parser.so
7f00c4331000-7f00c4531000 ---p 00011000 08:26 17264503 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/HTML/Parser/Parser.so
7f00c4531000-7f00c4532000 r--p 00011000 08:26 17264503 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/HTML/Parser/Parser.so
7f00c4532000-7f00c4533000 rw-p 00012000 08:26 17264503 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/HTML/Parser/Parser.so
7f00c4533000-7f00c4542000 r-xp 00000000 08:26 37965018 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/Data/Alias/Alias.so
7f00c4542000-7f00c4741000 ---p 0000f000 08:26 37965018 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/Data/Alias/Alias.so
7f00c4741000-7f00c4742000 r--p 0000e000 08:26 37965018 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/Data/Alias/Alias.so
7f00c4742000-7f00c4743000 rw-p 0000f000 08:26 37965018 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/Data/Alias/Alias.so
7f00c4743000-7f00c4752000 r-xp 00000000 08:26 16935572 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Encode/Encode.so
7f00c4752000-7f00c4952000 ---p 0000f000 08:26 16935572 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Encode/Encode.so
7f00c4952000-7f00c4953000 r--p 0000f000 08:26 16935572 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Encode/Encode.so
7f00c4953000-7f00c4954000 rw-p 00010000 08:26 16935572 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Encode/Encode.so
7f00c4954000-7f00c495e000 r-xp 00000000 08:26 51662457 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/PerlIO/encoding/encoding.so
7f00c495e000-7f00c4b5d000 ---p 0000a000 08:26 51662457 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/PerlIO/encoding/encoding.so
7f00c4b5d000-7f00c4b5e000 r--p 00009000 08:26 51662457 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/PerlIO/encoding/encoding.so
7f00c4b5e000-7f00c4b5f000 rw-p 0000a000 08:26 51662457 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/PerlIO/encoding/encoding.so
7f00c4b5f000-7f00c4b6d000 r-xp 00000000 08:26 42444098 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so
7f00c4b6d000-7f00c4d6c000 ---p 0000e000 08:26 42444098 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so
7f00c4d6c000-7f00c4d6d000 r--p 0000d000 08:26 42444098 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so
7f00c4d6d000-7f00c4d6e000 rw-p 0000e000 08:26 42444098 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so
7f00c4d6e000-7f00c4d70000 r-xp 00000000 08:21 40262792 /lib64/libkeyutils-1.2.so
7f00c4d70000-7f00c4f6f000 ---p 00002000 08:21 40262792 /lib64/libkeyutils-1.2.so
7f00c4f6f000-7f00c4f70000 r--p 00001000 08:21 40262792 /lib64/libkeyutils-1.2.so
7f00c4f70000-7f00c4f71000 rw-p 00002000 08:21 40262792 /lib64/libkeyutils-1.2.so
7f00c4f71000-7f00c4f78000 r-xp 00000000 08:26 34083387 /usr/lib64/libkrb5support.so.0.1
7f00c4f78000-7f00c5178000 ---p 00007000 08:26 34083387 /usr/lib64/libkrb5support.so.0.1
7f00c5178000-7f00c5179000 r--p 00007000 08:26 34083387 /usr/lib64/libkrb5support.so.0.1
7f00c5179000-7f00c517a000 rw-p 00008000 08:26 34083387 /usr/lib64/libkrb5support.so.0.1
7f00c517a000-7f00c517d000 r-xp 00000000 08:21 34091016 /lib64/libcom_err.so.2.1
7f00c517d000-7f00c537c000 ---p 00003000 08:21 34091016 /lib64/libcom_err.so.2.1
7f00c537c000-7f00c537d000 r--p 00002000 08:21 34091016 /lib64/libcom_err.so.2.1
7f00c537d000-7f00c537e000 rw-p 00003000 08:21 34091016 /lib64/libcom_err.so.2.1
7f00c537e000-7f00c53a8000 r-xp 00000000 08:26 34083378 /usr/lib64/libk5crypto.so.3.1
7f00c53a8000-7f00c55a7000 ---p 0002a000 08:26 34083378 /usr/lib64/libk5crypto.so.3.1
7f00c55a7000-7f00c55a9000 r--p 00029000 08:26 34083378 /usr/lib64/libk5crypto.so.3.1
7f00c55a9000-7f00c55aa000 rw-p 0002b000 08:26 34083378 /usr/lib64/libk5crypto.so.3.1
7f00c55aa000-7f00c565c000 r-xp 00000000 08:26 34083385 /usr/lib64/libkrb5.so.3.3
7f00c565c000-7f00c585c000 ---p 000b2000 08:26 34083385 /usr/lib64/libkrb5.so.3.3
7f00c585c000-7f00c5864000 r--p 000b2000 08:26 34083385 /usr/lib64/libkrb5.so.3.3
7f00c5864000-7f00c5866000 rw-p 000ba000 08:26 34083385 /usr/lib64/libkrb5.so.3.3
7f00c5866000-7f00c587f000 r-xp 00000000 08:26 35096507 /usr/lib64/libsasl2.so.2.0.23
7f00c587f000-7f00c5a7e000 ---p 00019000 08:26 35096507 /usr/lib64/libsasl2.so.2.0.23
7f00c5a7e000-7f00c5a7f000 r--p 00018000 08:26 35096507 /usr/lib64/libsasl2.so.2.0.23
7f00c5a7f000-7f00c5a80000 rw-p 00019000 08:26 35096507 /usr/lib64/libsasl2.so.2.0.23
7f00c5a80000-7f00c5a93000 r-xp 00000000 08:21 34193288 /lib64/libresolv-2.11.2.so
7f00c5a93000-7f00c5c93000 ---p 00013000 08:21 34193288 /lib64/libresolv-2.11.2.so
7f00c5c93000-7f00c5c94000 r--p 00013000 08:21 34193288 /lib64/libresolv-2.11.2.so
7f00c5c94000-7f00c5c95000 rw-p 00014000 08:21 34193288 /lib64/libresolv-2.11.2.so
7f00c5c95000-7f00c5c97000 rw-p 00000000 00:00 0
7f00c5c97000-7f00c5ca6000 r-xp 00000000 08:26 35176476 /usr/lib64/liblber-2.4.so.2.5.0
7f00c5ca6000-7f00c5ea5000 ---p 0000f000 08:26 35176476 /usr/lib64/liblber-2.4.so.2.5.0
7f00c5ea5000-7f00c5ea6000 r--p 0000e000 08:26 35176476 /usr/lib64/liblber-2.4.so.2.5.0
7f00c5ea6000-7f00c5ea7000 rw-p 0000f000 08:26 35176476 /usr/lib64/liblber-2.4.so.2.5.0
7f00c5ea7000-7f00c5ebb000 r-xp 00000000 08:21 40262768 /lib64/libz.so.1.2.3
7f00c5ebb000-7f00c60bb000 ---p 00014000 08:21 40262768 /lib64/libz.so.1.2.3
7f00c60bb000-7f00c60bc000 r--p 00014000 08:21 40262768 /lib64/libz.so.1.2.3
7f00c60bc000-7f00c60bd000 rw-p 00015000 08:21 40262768 /lib64/libz.so.1.2.3
7f00c60bd000-7f00c60ea000 r-xp 00000000 08:26 34083412 /usr/lib64/libgssapi_krb5.so.2.2
7f00c60ea000-7f00c62ea000 ---p 0002d000 08:26 34083412 /usr/lib64/libgssapi_krb5.so.2.2
7f00c62ea000-7f00c62eb000 r--p 0002d000 08:26 34083412 /usr/lib64/libgssapi_krb5.so.2.2
7f00c62eb000-7f00c62ec000 rw-p 0002e000 08:26 34083412 /usr/lib64/libgssapi_krb5.so.2.2
7f00c62ec000-7f00c632f000 r-xp 00000000 08:26 35175050 /usr/lib64/libldap-2.4.so.2.5.0
7f00c632f000-7f00c652e000 ---p 00043000 08:26 35175050 /usr/lib64/libldap-2.4.so.2.5.0
7f00c652e000-7f00c652f000 r--p 00042000 08:26 35175050 /usr/lib64/libldap-2.4.so.2.5.0
7f00c652f000-7f00c6531000 rw-p 00043000 08:26 35175050 /usr/lib64/libldap-2.4.so.2.5.0
7f00c6531000-7f00c6694000 r-xp 00000000 08:26 34433043 /usr/lib64/libcrypto.so.0.9.8
7f00c6694000-7f00c6893000 ---p 00163000 08:26 34433043 /usr/lib64/libcrypto.so.0.9.8
7f00c6893000-7f00c68a1000 r--p 00162000 08:26 34433043 /usr/lib64/libcrypto.so.0.9.8
7f00c68a1000-7f00c68b9000 rw-p 00170000 08:26 34433043 /usr/lib64/libcrypto.so.0.9.8
7f00c68b9000-7f00c68bd000 rw-p 00000000 00:00 0
7f00c68bd000-7f00c6908000 r-xp 00000000 08:26 34433046 /usr/lib64/libssl.so.0.9.8
7f00c6908000-7f00c6b07000 ---p 0004b000 08:26 34433046 /usr/lib64/libssl.so.0.9.8
7f00c6b07000-7f00c6b09000 r--p 0004a000 08:26 34433046 /usr/lib64/libssl.so.0.9.8
7f00c6b09000-7f00c6b0f000 rw-p 0004c000 08:26 34433046 /usr/lib64/libssl.so.0.9.8
7f00c6b0f000-7f00c6b40000 r-xp 00000000 08:26 35175710 /usr/lib64/libidn.so.11.5.39
7f00c6b40000-7f00c6d40000 ---p 00031000 08:26 35175710 /usr/lib64/libidn.so.11.5.39
7f00c6d40000-7f00c6d41000 r--p 00031000 08:26 35175710 /usr/lib64/libidn.so.11.5.39
7f00c6d41000-7f00c6d42000 rw-p 00032000 08:26 35175710 /usr/lib64/libidn.so.11.5.39
7f00c6d42000-7f00c6d87000 r-xp 00000000 08:26 35174303 /usr/lib64/libcurl.so.4.1.1
7f00c6d87000-7f00c6f87000 ---p 00045000 08:26 35174303 /usr/lib64/libcurl.so.4.1.1
7f00c6f87000-7f00c6f88000 r--p 00045000 08:26 35174303 /usr/lib64/libcurl.so.4.1.1
7f00c6f88000-7f00c6f89000 rw-p 00046000 08:26 35174303 /usr/lib64/libcurl.so.4.1.1
7f00c6f89000-7f00c6fa2000 r-xp 00000000 08:26 7889672 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/WWW/Curl/Curl.so
7f00c6fa2000-7f00c71a1000 ---p 00019000 08:26 7889672 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/WWW/Curl/Curl.so
7f00c71a1000-7f00c71a2000 r--p 00018000 08:26 7889672 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/WWW/Curl/Curl.so
7f00c71a2000-7f00c71a3000 rw-p 00019000 08:26 7889672 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/WWW/Curl/Curl.so
7f00c71a3000-7f00c71ab000 r-xp 00000000 08:21 34193290 /lib64/librt-2.11.2.so
7f00c71ab000-7f00c73aa000 ---p 00008000 08:21 34193290 /lib64/librt-2.11.2.so
7f00c73aa000-7f00c73ab000 r--p 00007000 08:21 34193290 /lib64/librt-2.11.2.so
7f00c73ab000-7f00c73ac000 rw-p 00008000 08:21 34193290 /lib64/librt-2.11.2.so
7f00c73ac000-7f00c73b4000 r-xp 00000000 08:26 29997 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Time/HiRes/HiRes.so
7f00c73b4000-7f00c75b3000 ---p 00008000 08:26 29997 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Time/HiRes/HiRes.so
7f00c75b3000-7f00c75b4000 r--p 00007000 08:26 29997 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Time/HiRes/HiRes.so
7f00c75b4000-7f00c75b5000 rw-p 00008000 08:26 29997 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/auto/Time/HiRes/HiRes.so
7f00c75b5000-7f00c770b000 r-xp 00000000 08:21 34085926 /lib64/libc-2.11.2.so
7f00c770b000-7f00c790b000 ---p 00156000 08:21 34085926 /lib64/libc-2.11.2.so
7f00c790b000-7f00c790f000 r--p 00156000 08:21 34085926 /lib64/libc-2.11.2.so
7f00c790f000-7f00c7910000 rw-p 0015a000 08:21 34085926 /lib64/libc-2.11.2.so
7f00c7910000-7f00c7915000 rw-p 00000000 00:00 0
7f00c7915000-7f00c792c000 r-xp 00000000 08:21 34179960 /lib64/libpthread-2.11.2.so
7f00c792c000-7f00c7b2c000 ---p 00017000 08:21 34179960 /lib64/libpthread-2.11.2.so
7f00c7b2c000-7f00c7b2d000 r--p 00017000 08:21 34179960 /lib64/libpthread-2.11.2.so
7f00c7b2d000-7f00c7b2e000 rw-p 00018000 08:21 34179960 /lib64/libpthread-2.11.2.so
7f00c7b2e000-7f00c7b32000 rw-p 00000000 00:00 0
7f00c7b32000-7f00c7b3d000 r-xp 00000000 08:21 34085931 /lib64/libcrypt-2.11.2.so
7f00c7b3d000-7f00c7d3d000 ---p 0000b000 08:21 34085931 /lib64/libcrypt-2.11.2.so
7f00c7d3d000-7f00c7d3e000 r--p 0000b000 08:21 34085931 /lib64/libcrypt-2.11.2.so
7f00c7d3e000-7f00c7d3f000 rw-p 0000c000 08:21 34085931 /lib64/libcrypt-2.11.2.so
7f00c7d3f000-7f00c7d6d000 rw-p 00000000 00:00 0
7f00c7d6d000-7f00c7d6f000 r-xp 00000000 08:21 34085933 /lib64/libdl-2.11.2.so
7f00c7d6f000-7f00c7f6f000 ---p 00002000 08:21 34085933 /lib64/libdl-2.11.2.so
7f00c7f6f000-7f00c7f70000 r--p 00002000 08:21 34085933 /lib64/libdl-2.11.2.so
7f00c7f70000-7f00c7f71000 rw-p 00003000 08:21 34085933 /lib64/libdl-2.11.2.so
7f00c7f71000-7f00c7fc7000 r-xp 00000000 08:21 34085937 /lib64/libm-2.11.2.so
7f00c7fc7000-7f00c81c6000 ---p 00056000 08:21 34085937 /lib64/libm-2.11.2.so
7f00c81c6000-7f00c81c7000 r--p 00055000 08:21 34085937 /lib64/libm-2.11.2.so
7f00c81c7000-7f00c81c8000 rw-p 00056000 08:21 34085937 /lib64/libm-2.11.2.so
7f00c81c8000-7f00c81e7000 r-xp 00000000 08:21 34085813 /lib64/ld-2.11.2.so
7f00c829e000-7f00c838b000 r--p 00000000 08:26 1107518 /usr/lib/locale/en_US.utf8/LC_COLLATE
7f00c838b000-7f00c8390000 rw-p 00000000 00:00 0
7f00c83d4000-7f00c83d5000 r--p 00000000 08:26 1107512 /usr/lib/locale/en_US.utf8/LC_NUMERIC
7f00c83d5000-7f00c83d6000 r--p 00000000 08:26 540176 /usr/lib/locale/en_US.utf8/LC_TIME
7f00c83d6000-7f00c83d7000 r--p 00000000 08:26 540175 /usr/lib/locale/en_US.utf8/LC_MONETARY
7f00c83d7000-7f00c83d8000 r--p 00000000 08:26 51313329 /usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES
7f00c83d8000-7f00c83d9000 r--p 00000000 08:26 38310951 /usr/lib/locale/en_US.utf8/LC_PAPER
7f00c83d9000-7f00c83da000 r--p 00000000 08:26 38310967 /usr/lib/locale/en_US.utf8/LC_NAME
7f00c83da000-7f00c83db000 r--p 00000000 08:26 540173 /usr/lib/locale/en_US.utf8/LC_ADDRESS
7f00c83db000-7f00c83dc000 r--p 00000000 08:26 38310820 /usr/lib/locale/en_US.utf8/LC_TELEPHONE
7f00c83dc000-7f00c83dd000 r--p 00000000 08:26 38310952 /usr/lib/locale/en_US.utf8/LC_MEASUREMENT
7f00c83dd000-7f00c83e4000 r--s 00000000 08:26 51318147 /usr/lib64/gconv/gconv-modules.cache
7f00c83e4000-7f00c83e5000 r--p 00000000 08:26 540174 /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
7f00c83e5000-7f00c83e6000 rw-p 00000000 00:00 0
7f00c83e6000-7f00c83e7000 r--p 0001e000 08:21 34085813 /lib64/ld-2.11.2.so
7f00c83e7000-7f00c83e8000 rw-p 0001f000 08:21 34085813 /lib64/ld-2.11.2.so
7f00c83e8000-7f00c83e9000 rw-p 00000000 00:00 0
7fff8b07a000-7fff8b09c000 rw-p 00000000 00:00 0 [stack]
7fff8b1e9000-7fff8b1ea000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)

Perl Info

``` Flags: category=core severity=critical This perlbug was built using Perl 5.10.0 - Fri Jul 30 00:12:10 UTC 2010 It is being executed now by Perl 5.10.0 - Thu Sep 16 16:14:28 UTC 2010. Site configuration information for perl 5.10.0: Configured by abuild at Thu Sep 16 16:14:28 UTC 2010. Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=linux, osvers=2.6.31, archname=x86_64-linux-thread-multi uname='linux build35 2.6.31 #1 smp 2010-01-06 16:07:25 +0100 x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -DEBUGGING=both -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -pipe -g', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing -pipe' ccversion='', gccversion='4.4.1 [gcc-4_4-branch revision 150839]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.10.1.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.10.1' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64' Locally applied patches: @INC for perl 5.10.0: /usr/local/lib/perl/5.8 /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl . Environment for perl 5.10.0: HOME=/home/law LANG=en_US.UTF-8 LANGUAGE (unset) LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH=/usr/lib64/mpi/gcc/openmpi/lib64 LOGDIR (unset) PATH=.:/sbin:/usr/local/sbin:/usr/lib64/mpi/gcc/openmpi/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/sbin PERL5LIB=/usr/local/lib/perl/5.8 PERL_BADLANG (unset) SHELL=/bin/bash ```

p5pRT commented 14 years ago

From perl-diddler@tlinx.org

adding core file

p5pRT commented 14 years ago

From perl-diddler@tlinx.org

core.7z

p5pRT commented 14 years ago

From @cpansprout

On Sat Oct 30 17:20:24 2010\, lawalsh@tlinx.org wrote:

Running a long HTML parse program -- about 1665 lines long that is in primary development. If I could figure out how to add an attachment\, I could attach one here.

You should be able to send an e-mail with an attachment to perlbug-followup@perl.org\, with [perl #78728] in the subject. It may take a few days to show up\, as that address is moderated (I think).

It processes a local data file though it can try to download files as guest from a website. I don't believe it actually downloads any files before crashing.

It is sensitive to the input file -- since running it twice in a row doesn't create the coredump. I have to 'restore' my input file to freshly downloaded file\, (i.e. my perl program modifies the data file\, thus a 2nd run doesn't follow the same execution as the first).

Could you attach your script and the HTML input file?

(If the core.7z file contains those\, could you re-send it as a .tar.gz or zip?)

p5pRT commented 14 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 14 years ago

From perl-diddler@tlinx.org

All in bugstuff.tgz.

It's not just 1 html file -- in fact there could be some randomness involved\, as I changed 1 line\, and it took a different number of runs to reproduce the error\, but in my setup\, with the current data files\, running "crawl.pl" seems to do a Segmentation fault the very first run -- which is now *different* than the previous error shown -- so something may be stomping on something [pseudo]-randomly** -- giving me a glib detectable double-ptr free in some cases\, but a plain segv in the current incarnation.

In an empty directory\, I reproduced the error with just the script file running running it as:

while ! test -e core; do crawl.pl done

Note that as it's setup now\, it fetches 1 item per invocation.

I've modified it to only fetch 1 item/invocation (can be tweaked\, search for 'FETCHMAX')\, as it creates a failure case w/fewer files downloaded.

** - The randomness is due in part to the fact that the cache isn't static from run to run: html files in particular are parsed and rewritten on the fly to localize links (even if the links are already localized\, as the parser doesn't know if a page is coming from the net or from cache) - this can result in bugs in address translations or whatever\, creating perturbations in future invocations that will cause the same files to be parsed differently on successive runs (even though they shouldn't be -- as I *STRESS*\, this is far from being of even alpha quality!)

By tweaking the max items fetched/run\, I'm pretty certain it will change how perl fails or crashes\, as smaller values for fetches/run\, will allow the parser-rewriter routines to perturb the file more...(what a feature! ;-) ).

To run this w/ the current files\, unpack the bugstuff.tgz file into an *empty* directory. To reproduce new failures\, just extract 'crawl.pl' from the tar file\, and run it with the 3-line script shown above (loop until core file appears)\, or (if you get rid of the core file\, then some other terminating condition). I've seen it return as many as 55 files before dying of something.

FWIW...many of the things it tries to fetch have butchered addresses that end up fetching nothing (other than a 'not found message).

At this point\, for all I know\, it could be something in SuSE's build procedure\, but I made sure to updated my perl package to the latest revision from their update server for OpenSuSE 11.2. FYI\, PERL 5.12 isn't included in OpenSuSE until its 11.3 release\, and upgrading is NOT a trivial task).

Thanks for looking into this so quickly!

Linda Walsh

p5pRT commented 14 years ago

From perl-diddler@tlinx.org

bugstuff.tgz

p5pRT commented 14 years ago

From @rurban

2010/10/31 lawalsh@tlinx.org \perlbug\-followup@perl\.org:

*** glibc detected *** /usr/bin/perl: corrupted double-linked list: 0x0000000001bfeab0 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x73226)[0x7f00c7628226] /lib64/libc.so.6(+0x75cb0)[0x7f00c762acb0] /lib64/libc.so.6(__libc_malloc+0x79)[0x7f00c762caa9] /usr/bin/perl(Perl_safesysmalloc+0x4d)[0x45ca0d] /usr/bin/perl(Perl_sv_grow+0xf8)[0x496208]

This looks very much like an internal glibc error in malloc\, not in perl per se. -- Reini Urban

p5pRT commented 14 years ago

From perl-diddler@tlinx.org

FReini Urban wrote:

2010/10/31 lawalsh@tlinx.org \perlbug\-followup@perl\.org:

This looks very much like an internal glibc error in malloc\, not in perl per se.

FYI...

(Not disputing your assessment)\, but wanted to mention it also dies no explicit glib error or traceback. Instead\, just does a Segmentation Violation. Core dump for the segv is in the tar.gz attached to the bug along with the script source and data files (though script can 'reproduce' the "datafiles"\, as detailed in the bug report).

The core associated with the traceback was attached by itself in .7z format (another open source format that takes about 40-50% less space than gzip).

Both may be in glibc\, but there seems to be some pseudo randomness about what the error type may indicating the possibility of some memory corruption\, but that's just a guess based on it failing at different places. I think the core in the tgz file is a different error type than the one shown in the traceback (both are from the same script\, but different runs).

Just adding in my 2 cents... ;-)

p5pRT commented 14 years ago

From @cpansprout

On Sun Oct 31 14:48:50 2010\, Linda.Walsh wrote:

All in bugstuff.tgz.

Attached is a reduced version of the script.

One of the first things I tried was to changed the open() call that creates the file to write to /dev/null. Then I could reproduce the bug more reliably.

I think this is a bug in HTML::Parser. I have sent a report to the LWP mailing list.

When a new HTML::Parser object is created from within a start handler\, the internal state of the existing parser gets corrupted.

You may be able to work around the problem by moving the creation of the parser from sub new to sub parse\,

p5pRT commented 14 years ago

From @cpansprout

crawl.pl

p5pRT commented 13 years ago

@iabyn - Status changed from 'open' to 'rejected'

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

In perl 5.16.2, this program still dumps core in multiple ways.

Perl shouldn't do this, regardless of what bad library is thought to be causing this. Obviously if the library on CPAN is at fault, perl needs to protect itself against such libraries (or random doo doo being thrown at it.. not that this program was random, but that it still causes 2 types of errors -- core dump and a HANG,

...
hang...final:
*** Error in `/usr/bin/perl': corrupted double-linked list:
0x0000000001610f50 ***

Core was generated by `/usr/bin/perl ./crawl.pl'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004b6668 in Perl_sv_chop ()
(gdb) where
#0 0x00000000004b6668 in Perl_sv_chop ()
#1 0x00007f4aafa35af3 in parse (my_perl=my_perl@entry=0x93d010,
p_state=p_state@entry=0xe956c0, chunk=chunk@entry=0xe3b758,
self=self@entry=0xe94ce0) at hparser.c:1885
#2 0x00007f4aafa36e4d in XS_HTML__Parser_parse (my_perl=0x93d010,
cv=<optimized out>) at Parser.xs:412
#3 0x00000000004a66c2 in Perl_pp_entersub ()
#4 0x000000000049ee66 in Perl_runops_standard ()
#5 0x000000000043cbb2 in perl_run ()
#6 0x000000000041ec5b in main ()
(gdb)

um... maybe someone in perl core needs to look at why this is dying in such a horrid manner?

How do I attach a file to this?

Got the whole thing repeatable in a tmp dir -- 72K compressed tar...

This bug is 3 years old and still not solved...and people wonder why my frustration level might gone a bit high?

p5pRT commented 11 years ago

perl-diddler@tlinx.org - Status changed from 'rejected' to 'new'

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

Note first time I run the test case, I get the error in perl-- corrupted double-linked list (and hang) -- pressing SIGQUIT (ctl-backslash) .. got a core dump and got this stack backtrace:

Core was generated by `/usr/bin/perl ./crawl.pl'.
Program terminated with signal 3, Quit.
#0 0x00007f4bb223c09b in __lll_lock_wait_private () from /lib64/libc.so.6
(gdb) where
#0 0x00007f4bb223c09b in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x00007f4bb21c7a3c in _L_lock_10265 () from /lib64/libc.so.6
#2 0x00007f4bb21c5255 in malloc () from /lib64/libc.so.6
#3 0x00007f4bb2e53252 in local_strdup () from /lib64/ld-linux-x86-64.so.2
#4 0x00007f4bb2e564b5 in _dl_map_object () from /lib64/ld-linux-x86-64.so.2
#5 0x00007f4bb2e6083e in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#6 0x00007f4bb2e5c7a6 in _dl_catch_error () from
/lib64/ld-linux-x86-64.so.2
#7 0x00007f4bb2e602b9 in _dl_open () from /lib64/ld-linux-x86-64.so.2
#8 0x00007f4bb2265e62 in do_dlopen () from /lib64/libc.so.6
#9 0x00007f4bb2e5c7a6 in _dl_catch_error () from
/lib64/ld-linux-x86-64.so.2
#10 0x00007f4bb2265eff in dlerror_run () from /lib64/libc.so.6
#11 0x00007f4bb2265f71 in __libc_dlopen_mode () from /lib64/libc.so.6
#12 0x00007f4bb2241735 in init () from /lib64/libc.so.6
#13 0x00007f4bb2500d90 in pthread_once () from /lib64/libpthread.so.0
#14 0x00007f4bb2241854 in backtrace () from /lib64/libc.so.6
#15 0x00007f4bb21bc095 in __libc_message () from /lib64/libc.so.6
#16 0x00007f4bb21c1bf6 in malloc_printerr () from /lib64/libc.so.6
#17 0x00007f4bb21c2c0a in _int_free () from /lib64/libc.so.6
#18 0x00000000004b00a9 in Perl_sv_clear ()
#19 0x00000000004b0772 in Perl_sv_free2 ()
#20 0x00000000004d3440 in Perl_free_tmps ()
#21 0x000000000049f4f5 in Perl_pp_nextstate ()
#22 0x000000000049ee66 in Perl_runops_standard ()
#23 0x000000000043cbb2 in perl_run ()
#24 0x000000000041ec5b in main ()

============== Running it again, I get a segmentation fault instead of the dll list

(it dies when the program is parsing the same file), FWIW:

It has a backtrace of:
Core was generated by `/usr/bin/perl ./crawl.pl'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004b6668 in Perl_sv_chop ()
(gdb) where
#0 0x00000000004b6668 in Perl_sv_chop ()
#1 0x00007ffda0bcaaf3 in parse (my_perl=my_perl@entry=0x1ef0010,
p_state=p_state@entry=0x24ebe70, chunk=chunk@entry=0x23e9868,
self=self@entry=0x24edca8) at hparser.c:1885
#2 0x00007ffda0bcbe4d in XS_HTML__Parser_parse (my_perl=0x1ef0010,
cv=<optimized out>) at Parser.xs:412
#3 0x00000000004a66c2 in Perl_pp_entersub ()
#4 0x000000000049ee66 in Perl_runops_standard ()
#5 0x000000000043cbb2 in perl_run ()
#6 0x00000000Core was generated by `/usr/bin/perl ./crawl.pl'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004b6668 in Perl_sv_chop ()
(gdb) where
#0 0x00000000004b6668 in Perl_sv_chop ()
#1 0x00007ffda0bcaaf3 in parse (my_perl=my_perl@entry=0x1ef0010,
p_state=p_state@entry=0x24ebe70, chunk=chunk@entry=0x23e9868,
self=self@entry=0x24edca8) at hparser.c:1885
#2 0x00007ffda0bcbe4d in XS_HTML__Parser_parse (my_perl=0x1ef0010,
cv=<optimized out>) at Parser.xs:412
#3 0x00000000004a66c2 in Perl_pp_entersub ()
#4 0x000000000049ee66 in Perl_runops_standard ()
#5 0x000000000043cbb2 in perl_run ()
#6 0x000000000041ec5b in main ()0041ec5b in main ()

Now I'd love to generate a debug perl and give more info on this, but I have not been able to generate perl on my machine since I reported that problem last summer. == actually, that's not entirely true,

I can generate one without 'DB: support (which I don't need)... for whatever reason, the DB tests fail -- even though all the needed DB files are supposedly loaded ... Of course suse's version generates in factory where they generate files on completely clean sterile systems now and refuse to even TEST build products in an opensuse fully installed 'Devel' environment....(they don't test product interactions so much these days, it seems, only things installed a specific way in a specific environment)... ;-) It's a feature -- makes building so much easier!...

hmmm....

um... attachments?

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

Ah HA! figured out how to do the attachment...AFAICT\, it doesn't access any files (other than installed perl libs) outside of the dir...

BTW... I haven't touched or looked at this code for about ... well about 2.5 years... so I may know the code only 'so so'...

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

bug78728.tar.xz

p5pRT commented 11 years ago

From [Unknown Contact. See original ticket]

Ah HA! figured out how to do the attachment...AFAICT\, it doesn't access any files (other than installed perl libs) outside of the dir...

BTW... I haven't touched or looked at this code for about ... well about 2.5 years... so I may know the code only 'so so'...

p5pRT commented 11 years ago

perl-diddler@tlinx.org - Status changed from 'new' to 'open'

p5pRT commented 11 years ago

From @doughera88

On Wed\, 1 May 2013\, Linda Walsh via RT wrote:

Ah HA! figured out how to do the attachment...AFAICT\, it doesn't access any files (other than installed perl libs) outside of the dir...

BTW... I haven't touched or looked at this code for about ... well about 2.5 years... so I may know the code only 'so so'...

This code is crashing in HTML::Parser\, which is maintained on CPAN outside of the perl core.

I would recommend two things:

1. Reduce the test case much further. Currently\, it relies on some external modules (some of which rely on external libraries or programs)\, apparently tries to fetch stuff from other web sites\, and I'm not sure what else. If at all possible\, please try to reduce it to a self-contained test that simply tries to parse the problematic file. For memory corruption problems\, this isn't always easy -- sometimes some of those preliminaries are necessary to set the stage\, but usually not all of them.

2. Submit the reduced test to the HTML::Parser queue on rt.cpan.org.

Thanks\,

-- Andy Dougherty doughera@lafayette.edu

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

Looking at this further\, it seems the last place it was executing was inside Carp: HTML::Parser::parse(/usr/lib/perl5/5.16.2/Carp.pm:86): 86: return longmess_heavy(@_); DB\<16> n Signal SEGV at crawl.pl line 1554. Aborted (core dumped)

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

This bug was originally filed against perl 5.10 in 2010 as bug #78728. I tried to re-open it and update it for perl 5.16.2\, but only got as far as re-opening it. Didn't seem to be a way to change the perl release to the current one other than to re-submit as new.

Dies in one of two ways depending on if it is the first or 2nd run...

First time\, it just hangs after displaying the error message so had to press ctl-backslash to generate a coredump...

Core was generated by `/usr/bin/perl ./crawl.pl'.
Program terminated with signal 3, Quit.
#0 0x00007f4bb223c09b in __lll_lock_wait_private () from /lib64/libc.so.6
(gdb) where
#0 0x00007f4bb223c09b in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x00007f4bb21c7a3c in _L_lock_10265 () from /lib64/libc.so.6
#2 0x00007f4bb21c5255 in malloc () from /lib64/libc.so.6
#3 0x00007f4bb2e53252 in local_strdup () from /lib64/ld-linux-x86-64.so.2
#4 0x00007f4bb2e564b5 in _dl_map_object () from /lib64/ld-linux-x86-64.so.2
#5 0x00007f4bb2e6083e in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#6 0x00007f4bb2e5c7a6 in _dl_catch_error () from
/lib64/ld-linux-x86-64.so.2
#7 0x00007f4bb2e602b9 in _dl_open () from /lib64/ld-linux-x86-64.so.2
#8 0x00007f4bb2265e62 in do_dlopen () from /lib64/libc.so.6
#9 0x00007f4bb2e5c7a6 in _dl_catch_error () from
/lib64/ld-linux-x86-64.so.2
#10 0x00007f4bb2265eff in dlerror_run () from /lib64/libc.so.6
#11 0x00007f4bb2265f71 in __libc_dlopen_mode () from /lib64/libc.so.6
#12 0x00007f4bb2241735 in init () from /lib64/libc.so.6
#13 0x00007f4bb2500d90 in pthread_once () from /lib64/libpthread.so.0
#14 0x00007f4bb2241854 in backtrace () from /lib64/libc.so.6
#15 0x00007f4bb21bc095 in __libc_message () from /lib64/libc.so.6
#16 0x00007f4bb21c1bf6 in malloc_printerr () from /lib64/libc.so.6
#17 0x00007f4bb21c2c0a in _int_free () from /lib64/libc.so.6
#18 0x00000000004b00a9 in Perl_sv_clear ()
#19 0x00000000004b0772 in Perl_sv_free2 ()
#20 0x00000000004d3440 in Perl_free_tmps ()
#21 0x000000000049f4f5 in Perl_pp_nextstate ()
#22 0x000000000049ee66 in Perl_runops_standard ()
#23 0x000000000043cbb2 in perl_run ()
#24 0x000000000041ec5b in main ()

==============
Running it again, I get a segmentation fault instead of the dll list

(it dies when the program is parsing the same file), FWIW:

It has a backtrace of:
Core was generated by `/usr/bin/perl ./crawl.pl'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004b6668 in Perl_sv_chop ()
(gdb) where
#0 0x00000000004b6668 in Perl_sv_chop ()
#1 0x00007ffda0bcaaf3 in parse (my_perl=my_perl@entry=0x1ef0010,
p_state=p_state@entry=0x24ebe70, chunk=chunk@entry=0x23e9868,
self=self@entry=0x24edca8) at hparser.c:1885
#2 0x00007ffda0bcbe4d in XS_HTML__Parser_parse (my_perl=0x1ef0010,
cv=<optimized out>) at Parser.xs:412
#3 0x00000000004a66c2 in Perl_pp_entersub ()
#4 0x000000000049ee66 in Perl_runops_standard ()
#5 0x000000000043cbb2 in perl_run ()
#6 0x00000000Core was generated by `/usr/bin/perl ./crawl.pl'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004b6668 in Perl_sv_chop ()
(gdb) where
#0 0x00000000004b6668 in Perl_sv_chop ()
#1 0x00007ffda0bcaaf3 in parse (my_perl=my_perl@entry=0x1ef0010,
p_state=p_state@entry=0x24ebe70, chunk=chunk@entry=0x23e9868,
self=self@entry=0x24edca8) at hparser.c:1885
#2 0x00007ffda0bcbe4d in XS_HTML__Parser_parse (my_perl=0x1ef0010,
cv=<optimized out>) at Parser.xs:412
#3 0x00000000004a66c2 in Perl_pp_entersub ()
#4 0x000000000049ee66 in Perl_runops_standard ()
#5 0x000000000043cbb2 in perl_run ()
#6 0x000000000041ec5b in main ()0041ec5b in main ()

I'll see about attaching the compressed tar of the prog & data when this
comes back with a bug id..

I'll see about attaching the compressed tar of the prog & data when this comes back with a bug id..

Perl Info

``` Flags: category=core severity=high This perlbug was built using Perl 5.16.2 - Fri Feb 15 01:17:37 UTC 2013 It is being executed now by Perl 5.16.2 - Fri Feb 15 01:12:05 UTC 2013. Site configuration information for perl 5.16.2: Configured by abuild at Fri Feb 15 01:12:05 UTC 2013. Summary of my perl5 (revision 5 version 16 subversion 2) configuration: Platform: osname=linux, osvers=3.4.6-2.10-default, archname=x86_64-linux-thread-multi uname='linux build34 3.4.6-2.10-default #1 smp thu jul 26 09:36:26 utc 2012 (641c197) x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.7.2 20130108 [gcc-4_7-branch revision 195012]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.17.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.17' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector' Locally applied patches: @INC for perl 5.16.2: /home/law/bin/lib /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.2 /usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.2 /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/5.16.2 /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.2 /usr/lib/perl5/site_perl . Environment for perl 5.16.2: HOME=/home/law LANG=en_US.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.:/home/law/bin/lib:/home/law/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/opt/dell/srvadmin/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib PERL5OPT=-CSA -I/home/law/bin/lib PERL_BADLANG (unset) SHELL=/bin/bash ```

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

Added attachment from previous bug w/test case.

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

bug78728.tar.xz

p5pRT commented 11 years ago

From [Unknown Contact. See original ticket]

Added attachment from previous bug w/test case.

p5pRT commented 11 years ago

perl-diddler@tlinx.org - Status changed from 'new' to 'open'

p5pRT commented 11 years ago

From @Corion

Hello Linda\,

please read the previous comments you got on bug report #78728 [1]. Your bug report is for HTML::Parser and has very little to do with the Perl core if anything at all.

Please do not reopen bugs that have been closed unless you actually follow them up with a short\, self-contained example of Perl code that reproduces the issue. The file you attached to this bug contains various HTML files\, some PNG file and a 43k Perl file\, and it is likely much easier for you to reduce the amount of data needed to reproduce the error than it is for other people who do not have your setup.

Thanks\, -max

[1] https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=78728

p5pRT commented 11 years ago

From @Leont

On Sat\, May 4\, 2013 at 3:24 PM\, Linda Walsh \perlbug\-followup@perl\.org wrote:

This bug was originally filed against perl 5.10 in 2010 as bug #78728. I tried to re-open it and update it for perl 5.16.2\, but only got as far as re-opening it. Didn't seem to be a way to change the perl release to the current one other than to re-submit as new.

Why the hell do you open a new ticket? It's more work to merge this one into the old one that to change a marker on that ticket.

Dies in one of two ways depending on if it is the first or 2nd run...

Non-determinism\, how lovely.

First time\, it just hangs after displaying the error message so had to press ctl-backslash to generate a coredump...

Core was generated by `/usr/bin/perl ./crawl.pl'. Program terminated with signal 3\, Quit. #0 0x00007f4bb223c09b in __lll_lock_wait_private () from /lib64/libc.so.6 (gdb) where #0 0x00007f4bb223c09b in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x00007f4bb21c7a3c in _L_lock_10265 () from /lib64/libc.so.6 #2 0x00007f4bb21c5255 in malloc () from /lib64/libc.so.6 #3 0x00007f4bb2e53252 in local_strdup () from /lib64/ld-linux-x86-64.so.2 #4 0x00007f4bb2e564b5 in _dl_map_object () from /lib64/ld-linux-x86-64.so.2 #5 0x00007f4bb2e6083e in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #6 0x00007f4bb2e5c7a6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #7 0x00007f4bb2e602b9 in _dl_open () from /lib64/ld-linux-x86-64.so.2 #8 0x00007f4bb2265e62 in do_dlopen () from /lib64/libc.so.6 #9 0x00007f4bb2e5c7a6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #10 0x00007f4bb2265eff in dlerror_run () from /lib64/libc.so.6 #11 0x00007f4bb2265f71 in __libc_dlopen_mode () from /lib64/libc.so.6 #12 0x00007f4bb2241735 in init () from /lib64/libc.so.6 #13 0x00007f4bb2500d90 in pthread_once () from /lib64/libpthread.so.0 #14 0x00007f4bb2241854 in backtrace () from /lib64/libc.so.6 #15 0x00007f4bb21bc095 in __libc_message () from /lib64/libc.so.6 #16 0x00007f4bb21c1bf6 in malloc_printerr () from /lib64/libc.so.6 #17 0x00007f4bb21c2c0a in _int_free () from /lib64/libc.so.6 #18 0x00000000004b00a9 in Perl_sv_clear () #19 0x00000000004b0772 in Perl_sv_free2 () #20 0x00000000004d3440 in Perl_free_tmps () #21 0x000000000049f4f5 in Perl_pp_nextstate () #22 0x000000000049ee66 in Perl_runops_standard () #23 0x000000000043cbb2 in perl_run () #24 0x000000000041ec5b in main ()

So it crashes somewhere deep into allocating memory\, while trying to give an error about some other issue. Something went terribly wrong. My first guess is this to be caused by #31923\, :encoding and threads are no friends.

============== Running it again\, I get a segmentation fault instead of the dll list

(it dies when the program is parsing the same file)\, FWIW:

It has a backtrace of: Core was generated by `/usr/bin/perl ./crawl.pl'. Program terminated with signal 11\, Segmentation fault. #0 0x00000000004b6668 in Perl_sv_chop () (gdb) where #0 0x00000000004b6668 in Perl_sv_chop () #1 0x00007ffda0bcaaf3 in parse (my_perl=my_perl@entry=0x1ef0010\, p_state=p_state@entry=0x24ebe70\, chunk=chunk@entry=0x23e9868\, self=self@entry=0x24edca8) at hparser.c:1885 #2 0x00007ffda0bcbe4d in XS_HTML__Parser_parse (my_perl=0x1ef0010\, cv=\) at Parser.xs:412 #3 0x00000000004a66c2 in Perl_pp_entersub () #4 0x000000000049ee66 in Perl_runops_standard () #5 0x000000000043cbb2 in perl_run () #6 0x00000000Core was generated by `/usr/bin/perl ./crawl.pl'. Program terminated with signal 11\, Segmentation fault. #0 0x00000000004b6668 in Perl_sv_chop () (gdb) where #0 0x00000000004b6668 in Perl_sv_chop () #1 0x00007ffda0bcaaf3 in parse (my_perl=my_perl@entry=0x1ef0010\, p_state=p_state@entry=0x24ebe70\, chunk=chunk@entry=0x23e9868\, self=self@entry=0x24edca8) at hparser.c:1885 #2 0x00007ffda0bcbe4d in XS_HTML__Parser_parse (my_perl=0x1ef0010\, cv=\) at Parser.xs:412 #3 0x00000000004a66c2 in Perl_pp_entersub () #4 0x000000000049ee66 in Perl_runops_standard () #5 0x000000000043cbb2 in perl_run () #6 0x000000000041ec5b in main ()0041ec5b in main ()

I'm guessing this is the other side of the same coin.

I'll see about attaching the compressed tar of the prog & data when this comes back with a bug id..

Your attached program is way too big to properly analyze\, but I already gave you my first suspect.

Also\, you might not want to include your torrent files and other stuff in tarballs you send to perlbug…

Leon

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Sat May 04 08:41:04 2013\, LeonT wrote:

Why the hell do you open a new ticket? It's more work to merge this one into the old one that to change a marker on that ticket.

Didn't seem to be a way to change the perl release to the current one other than to re-submit as new.

I said I opened a new ticket as there seemed to be no way to change the perl release to the current one. I opened the other one and updated it -- but got no indication that it did anything. I.e. I already tried "not opening a new ticket"\, but the system didn't appear to have any way to do what you ask.

Why do you ask such argumentative\, rhetorical questions when I already explained I didn't know how to do what you you suggest?

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Sat May 04 08:41:04 2013\, LeonT wrote:

Non-determinism\, how lovely.

I agree... that perl should exhibit such behavior in a rather mundane program was disturbing.

So it crashes somewhere deep into allocating memory\, while trying to give an error about some other issue. Something went terribly wrong. My first guess is this to be caused by #31923\, :encoding and threads are no friends.

Slight problem with that -- there are no threads being used. While I designed some of the Queue package modules to be thread safe to the best of my limited understanding at the time I wrote it\, I never got to the point of using any thread or fork calls so I'm pretty sure I am making no invocations of threads.

As for encoding -- you can't read and write to STDIO without it being encoded by perl\, so its hard to write any program that doesn't use encoding.

Your attached program is way too big to properly analyze\, but I already gave you my first suspect.

Yup. If I had any further ability to analyze it\, I think I would have done it.

Also\, you might not want to include your torrent files and other stuff in tarballs you send to perlbug…

There isn't anything private or personal in the data included. The use data that's been publicly available for almost 3 years and relatively static except for the website changing from ".com" => ".me".

It crashes very quickly and reliably.

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Sat May 04 07:18:26 2013\, corion@cpan.org wrote:

Hello Linda\,

please read the previous comments you got on bug report #78728 [1]. Your bug report is for HTML::Parser and has very little to do with the Perl core if anything at all.

As mentioned in the other report\, it dies in Carp trying to throw a fatal error -- Carp isn't "HTML::Parser"....

Please do not reopen bugs that have been closed unless you actually follow them up with a short\, self-contained example of Perl code that reproduces the issue.

I included 1 relatively short perl program. The specific data sets up the problem. using a different data set would take longer to trigger the bug.

The file you attached to this bug contains various

HTML files\, some PNG file and a 43k Perl file\, and it is likely much easier for you to reduce the amount of data needed to reproduce the error than it is for other people who do not have your setup.

Anyone who has read the bug has my setup. It is completely self-contained other than relying on standard\, static Perl-cpan library routines that have been the same for years.

If I had the ability to debug it or isolate it anymore\, I would have done so 3 years ago rather than sidelining the project -- but I hoped that the bugs in perl would be fixed to the point where it doesn't die with a core dump and I might be able to make progress in developing and/or debugging it.

Are you saying no one in the perl community has more expertise in the internals of perl than me? Perhaps you'd like to nominate me as the next pumpkin king as well?

p5pRT commented 11 years ago

From @Corion

Hello Linda\,

having now looked at your program\, it pulls in several external modules that are not supported by the perl5-porters:

Readonly Data::Alias LWP::Curl HTML::Parser

Please reduce your program until it either does not need any of those anymore and still reproduces the problem\, or raise the error with the module which causes the problem to occur. So far\, you have not shown that the problem is caused by Perl.

Many modules that use the Perl-C interface ("XS") are problematic and prone to crashes. HTML::Parser\, Data::Alias and LWP::Curl pull in such parts\, which make it highly unlikely that the problem is with Perl and far more likely that the problem is with one of the modules.

The last bug got closed because the diagnosis was that the problem was with HTML::Parser. What steps have you taken to eliminate HTML::Parser from your test program?

-max

p5pRT commented 11 years ago

From @Leont

On Sat\, May 4\, 2013 at 6:29 PM\, Linda Walsh via RT \perlbug\-followup@perl\.org wrote:

If I had the ability to debug it or isolate it anymore\, I would have done so 3 years ago rather than sidelining the project -- but I hoped that the bugs in perl would be fixed to the point where it doesn't die with a core dump and I might be able to make progress in developing and/or debugging it.

Are you saying no one in the perl community has more expertise in the internals of perl than me? Perhaps you'd like to nominate me as the next pumpkin king as well?

No\, we're saying that you haven't even shown the problem to be in perl itself and you're not motivating anyone to do the work for you. Our volunteers have better things to do with their time.

Leon

p5pRT commented 11 years ago

From @doughera88

On Sat\, 4 May 2013\, Linda Walsh via RT wrote:

On Sat May 04 07:18:26 2013\, corion@cpan.org wrote:

Hello Linda\,

please read the previous comments you got on bug report #78728 [1]. Your bug report is for HTML::Parser and has very little to do with the Perl core if anything at all. --- As mentioned in the other report\, it dies in Carp trying to throw a fatal error -- Carp isn't "HTML::Parser"....

No\, but Carp is called from within functions called from within HTML::Parser.

Please do not reopen bugs that have been closed unless you actually follow them up with a short\, self-contained example of Perl code that reproduces the issue. --- I included 1 relatively short perl program. The specific data sets up the problem. using a different data set would take longer to trigger the bug.

The file you attached to this bug contains various

HTML files\, some PNG file and a 43k Perl file\, and it is likely much easier for you to reduce the amount of data needed to reproduce the error than it is for other people who do not have your setup. ---- Anyone who has read the bug has my setup. It is completely self-contained other than relying on standard\, static Perl-cpan library routines that have been the same for years.

No\, that is not true. I\, for one\, do not have your setup. It was not completely self contained. It would have required the installation of several cpan libraries as well as external programs that those libraries depend on. It then appeared to fetch data files from the internet. Are each and every one of those extra modules and steps needed?

You are most likely to get help from the volunteers who maintain perl and perl modules if you provide your bug report in the most trimmed-down fashion possible\, ideally in a completely self-contained targeted program that doesn't do a lot of extra stuff and that has all the non-essential parts removed. If you can't be bothered to take the time to do that\, then I fail to see why you think anyone else should volunteer their time to do so.

-- Andy Dougherty doughera@lafayette.edu

p5pRT commented 11 years ago

From perl-diddler@tlinx.org

On Sun May 05 11:31:52 2013\, doughera wrote:

On Sat\, 4 May 2013\, Linda Walsh via RT wrote:
As mentioned in the other report\, it dies in Carp trying to
throw a fatal error \-\- Carp isn't "HTML&#8203;::Parser"\.\.\.\.
No\, but Carp is called from within functions called from within HTML::Parser.

I fail to see the relevance. This is from a user perspective just like perl relies on library and OS calls. If perl was to call a write function on the host OS\, and the host OS responded with a coredump or blue-screen\, or whatever it does\, would you consider that to be a bug in perl?

Most OS developers would not -- since the boundaries are such that in normal operation\, actions of a client program shouldn't cause the OS to panic or die. In the same way\, a perl-program\, should not have to wonder how it is at fault\, if perl dies. Perl should not die.

In a similar way\, if a user is running some application\, say a word processor\, and crashes when they misspell a word -- it wouldn't be considered a problem in the user's document (despite that they misspelled the word)\, but in the application.

If we look at the documentation for Carp\, I find no circumstance in which a segfault or generation of bad-calls to a system library are considered normal or "documented" behavior. By the same token\, If I was looking through Carp's sources\, I doubt that any call it is making is documented to do those either -- yet AFAIK\, it only is using perl.

If there is any place where perl's documented behavior is that it should produce a segfault or should call system libraries in ways that are documented to be wrong\, please tell me\, as I don't believe there are. I don't know of any circumstance under which perl's behavior is considered normal\, expected or accepted behavior.

Anyone who has read the bug has my setup. It is completely self-contained other than relying on standard\, static Perl-cpan library routines that have been the same for years.

No\, that is not true. I\, for one\, do not have your setup. It was not completely self contained. It would have required the installation of several cpan libraries as well as external programs that those libraries depend on.

I said it was self-contained other than relying on standard perl-cpan libraries routines. I included the data files I did as they comprise 'processed' (though perhaps incorrectly)\, data that\, if removed\, the program goes off and fetches things from the internet that may or may not show the error (I put in a limit of amount it could fetch per run while developing -- so it might have to be run several times before duplicating the error. But with the included\, cached files\, it duplicates it in the 1st or 2nd time through the parser rather reliably.

Note\, the fact that I report perl crashing as a bug in perl doesn't reflect any perceived quality about the *input* I am giving it. It reflects the belief that perl shouldn't crash\, and that here was a test case that someone on 'linux'\, could easily use to crash perl in versions 5.10 -> 5.16.2\, rather reliably.

I can assure you\, the program I was working on wasn't even close to being done -- if I had to estimate\, it might be 33% done\, but easily less than that. I was NOT trying to get anyone to debug my program -- I would rather they NOT\, as it would be embarrassing as it was not near done. But development ground to a halt because no matter what the input\, perl eventually crashed. With the right input (that I included)\, it crashed early.

If the program caused a reliable kernel panic or OS-core dump\, I'd report that as a bug in the OS as the program isn't running as a program that tries to play tricks with the host-interpreter's or host-os's address space.

Usually with products the problem is developers *can't* reproduce the user's symptoms. I felt I had included everything needed to reproduce the problem in a short amount of time (\<1s).

While I can fiddle with my program to try to work around perl's crash -- that wouldn't fix the bug in perl.

The question shouldn't be do I have some "simplest case" -- as that isn't well defined -- what is defined is perl's documented behavior -- none of which includes hanging on double free's\, nor dumping core from segmentation violations.

GIVEN the above -- in running the program again\, I can occasionally get a third result where it starts to dump the last page it was working on (using Devel::Dumper)\, which gives me a way to possible proceed forward. I try to build in a fair amount of debug into a complex program -- but if non of my debug can be called due to perl dumping core\, that limits my ability to debug the program and produce a test case for something that will crash perl -- when perl should be robust enough to not crash in the face of normal perl input.

It then appeared to

fetch data files from the internet. Are each and every one of those extra modules and steps needed?

I think it tries to fetch thumbnails that for some reason are not cacheable. The html files it tries to preprocess and leave on disk.

I've tried scores of variations -- and I had plenty of times when I didn't hit the bug early or didn't hit it reliably\, but after much banging of head against the wall\, I had hoped to actually give a test case to developers so they could find out where it crashed in perl and look back as to how it got there and use it to beef up perl so it wouldn't die with such input -- allowing me to make use of things like the perl-debugger or such to correct the misspelled words and further work on the program.

If it was truly not in perl\, then one might think that using a version that was 3 major releases later might show different behavior (as well as being on a different OS and with different runtime libraries). But that it still crashes perl with the same type of memory corruption seems to conspicuously point to some problem in perl that could be fixed -- which is why I reported the bug in perl and not somewhere else.

If it caused my OS to panic\, I'd report it there. I wasn't able to see why it crashed randomly from the application side\, since when it does -- it's buried deep inside perl. So it seemed most ideal to look at the place where it crashes to proceed.

I'll still see if I can reduce it\, but that it crashed quickly and reliably I had thought would have been sufficient for most projects.

You are most likely to get help from the volunteers who maintain perl and perl modules if you provide your bug report in the most trimmed-down fashion possible\, ideally in a completely self-contained targeted program that doesn't do a lot of extra stuff and that has all the non- essential parts removed. If you can't be bothered to take the time to do that\, then I fail to see why you think anyone else should volunteer their time to do so. ---On Sun May 05 11:31:52 2013\, doughera wrote: On Sat\, 4 May 2013\, Linda Walsh via RT wrote:
As mentioned in the other report\, it dies in Carp trying to
throw a fatal error \-\- Carp isn't "HTML&#8203;::Parser"\.\.\.\.
No\, but Carp is called from within functions called from within HTML::Parser.