develooper Front page | perl.perl5.porters | Postings from May 2013

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

Thread Previous | Thread Next
From:
Linda Walsh via RT
Date:
May 5, 2013 22:40
Subject:
[perl #78728] glibc detected *** /usr/bin/perl: corrupted double-linked list (was 5.10, is now 5.16.2)
Message ID:
rt-3.6.HEAD-28177-1367793641-1740.78728-15-0@perl.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::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::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.
---
  You seem to think I spent no time trying to get around this.  Why would
I spend months in developing and debugging this and voluntarily shelve
it for 2.5 years if it was something I could do?





  You seem to think I spent no time trying to get around this.  Why would
I spend months in developing and debugging this and voluntarily shelve
it for 2.5 years if it was something I could do?






---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=78728

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About