Loading ...
Sorry, an error occurred while loading the content.

Re: [DOH!] Apache 2 SEGVs during test run

Expand Messages
  • Stas Bekman
    [don t forget to always reply to the list] ... OK, now I remember what the trace like you ve posted: (gdb) bt #0 0x4030d4d1 in __read_nocancel () from
    Message 1 of 4 , Jan 24, 2005
    • 0 Attachment
      [don't forget to always reply to the list]

      Dominique Quatravaux wrote:
      > -----BEGIN PGP SIGNED MESSAGE-----
      > Hash: SHA1
      >
      > Stas Bekman wrote:
      >
      > | what test has caused the segfault? can you do the verbose run of
      > | that test?
      >
      > Well I was able to reproduce that failure mode only twice, but one
      > another run gave me a deep recursion in Compress::Zlib. So I
      > recompiled Compress::Zlib from CPAN for the heck of it from CPAN and
      > all my problems went away. Doh!

      > | Dominique Quatravaux wrote:
      > |
      > |> Apache 2 SEGVs during the test run (see core dump at the end),
      > |> then tests fail randomly (Failed 23/221 test scripts, [...]
      > |> 77/2272 subtests).
      >
      > I recompiled HTML::Parser and those went mostly away too. Double doh!
      > Sorry for the fuss then.

      OK, now I remember what the trace like you've posted:

      (gdb) bt
      #0 0x4030d4d1 in __read_nocancel () from /lib/tls/libpthread.so.0
      #1 0x00000000 in ?? ()

      means. It means that you've build your modules with ithreads enabled perl.
      Then you have built a new perl *without* ithreads. But you didn't nuke the
      old modules. Now when you try to run those, you get the above segfault.
      Certainly forcing a recompile of those solves the problem, as you've reported.

      I've had a hell of segfaults when Mandrake cooker recently switched to a
      non-threaded perl (I had all Mandrake tools segfaulting, wtih the
      backtrace above).

      > I still have a few test failures in t/apache/content_length_header.t
      > (2 5 17), should I report those? (Basically my borged Apache from
      > backports.org seems to behave like a 2.1 version, because if I reverse
      > the test condition accordingly on lines 67 and 68 then tests 2 and 5
      > start working OK).

      Certainly.


      --
      __________________________________________________________________
      Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
      http://stason.org/ mod_perl Guide ---> http://perl.apache.org
      mailto:stas@... http://use.perl.org http://apacheweek.com
      http://modperlbook.org http://apache.org http://ticketmaster.com
    • Dominique Quatravaux
      ... Hash: SHA1 ... My mistake, sorry. ... Spot on. Brilliant, Holmes! ... Here we go. Still using the same software versions as when this thread began. t/TEST
      Message 2 of 4 , Jan 25, 2005
      • 0 Attachment
        -----BEGIN PGP SIGNED MESSAGE-----
        Hash: SHA1

        Stas Bekman wrote:

        | [don't forget to always reply to the list]

        My mistake, sorry.

        |
        | OK, now I remember what the trace like you've posted [...] means.
        | It means that you've build your modules with ithreads enabled perl.
        | Then you have built a new perl *without* ithreads. But you didn't
        | nuke the old modules. Now when you try to run those, you get the
        | above segfault. Certainly forcing a recompile of those solves the
        | problem, as you've reported.

        Spot on. Brilliant, Holmes!

        |> I still have a few test failures in
        |> t/apache/content_length_header.t (2 5 17), should I report those?
        |>
        |
        |
        | Certainly.
        |
        Here we go. Still using the same software versions as when this thread
        began.

        t/TEST -clean
        t/TEST -verbose t/apache/content_length_header.t

        [...]
        # testing : GET /TestApache__content_length_header C-L header
        # expected: 0
        # received: undef
        not ok 2
        # Failed test 2 in t/apache/content_length_header.t at line 50
        [...]
        # testing : GET /TestApache__content_length_header?set_content_length
        C-L header
        # expected: 0
        # received: 25
        not ok 5
        # Failed test 5 in t/apache/content_length_header.t at line 71
        [...]
        # testing : HEAD /TestApache__content_length_header?set_content_length
        C-L header
        # expected: undef
        # received: 25
        not ok 17
        # Failed test 17 in t/apache/content_length_header.t at line 71 fail #2
        [...]

        The rest of the tests are OK, and there is nothing weird in
        t/logs/error_log. Now if I apply

        - --- t/apache/content_length_header.t.ORIG 2005-01-25
        11:20:21.000000000 +0100
        +++ t/apache/content_length_header.t 2005-01-25 11:20:34.000000000
        +0100
        @@ -43,8 +43,8 @@
        ~ my $uri = $location;
        ~ my $res = $method->($uri);

        - - my $cl = have_min_apache_version(2.1) ? undef : 0;
        - - my $head_cl = have_min_apache_version(2.1) ? $cl : undef;
        + my $cl = 1 ? undef : 0;
        + my $head_cl = 1 ? $cl : undef;

        ~ ok t_cmp $res->code, 200, "$method $uri code";
        ~ ok t_cmp ($res->header('Content-Length'),

        then (unsurprisingly) test 2 passes, but 5 and 17 still fail in the
        same way as above.

        Regards,

        - --
        Dominique QUATRAVAUX Ingénieur senior
        01 44 42 00 08 IDEALX

        -----BEGIN PGP SIGNATURE-----
        Version: GnuPG v1.2.4 (GNU/Linux)
        Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

        iD8DBQFB9h60MJAKAU3mjcsRAigEAJwK/Zm9Mb4Z0zJX1LuHmv0g2ZMurwCfUZA+
        bAbMmdPEEwpjE8CG9wssR28=
        =ukpr
        -----END PGP SIGNATURE-----
      • Dominique Quatravaux
        ... Hash: SHA1 ... My mistake, sorry. ... Spot on. Brilliant, Holmes! :-) ... Here we go. Still using the same software versions as when this thread began.
        Message 3 of 4 , Jan 25, 2005
        • 0 Attachment
          -----BEGIN PGP SIGNED MESSAGE-----
          Hash: SHA1

          Stas Bekman wrote:

          | [don't forget to always reply to the list]

          My mistake, sorry.

          |
          | OK, now I remember what the trace like you've posted [...] means.
          | It means that you've build your modules with ithreads enabled perl.
          | Then you have built a new perl *without* ithreads. But you didn't
          | nuke the old modules. Now when you try to run those, you get the
          | above segfault. Certainly forcing a recompile of those solves the
          | problem, as you've reported.

          Spot on. Brilliant, Holmes! :-)

          |> I still have a few test failures in
          |> t/apache/content_length_header.t (2 5 17), should I report those?
          |>
          |
          |
          | Certainly.

          Here we go. Still using the same software versions as when this thread
          began.

          t/TEST -clean
          t/TEST -verbose t/apache/content_length_header.t

          [...]
          # testing : GET /TestApache__content_length_header C-L header
          # expected: 0
          # received: undef
          not ok 2
          # Failed test 2 in t/apache/content_length_header.t at line 50
          [...]
          # testing : GET /TestApache__content_length_header?set_content_length
          C-L header
          # expected: 0
          # received: 25
          not ok 5
          # Failed test 5 in t/apache/content_length_header.t at line 71
          [...]
          # testing : HEAD /TestApache__content_length_header?set_content_length
          C-L header
          # expected: undef
          # received: 25
          not ok 17
          # Failed test 17 in t/apache/content_length_header.t at line 71 fail #2
          [...]

          The rest of the tests are OK, and there is nothing weird in
          t/logs/error_log. Now if I apply

          - --- t/apache/content_length_header.t.ORIG 2005-01-25
          11:20:21.000000000 +0100
          +++ t/apache/content_length_header.t 2005-01-25 11:20:34.000000000
          +0100
          @@ -43,8 +43,8 @@
          ~ my $uri = $location;
          ~ my $res = $method->($uri);

          - - my $cl = have_min_apache_version(2.1) ? undef : 0;
          - - my $head_cl = have_min_apache_version(2.1) ? $cl : undef;
          + my $cl = 1 ? undef : 0;
          + my $head_cl = 1 ? $cl : undef;

          ~ ok t_cmp $res->code, 200, "$method $uri code";
          ~ ok t_cmp ($res->header('Content-Length'),

          then (unsurprisingly) test 2 passes, but 5 and 17 still fail in the
          same way as above.

          Regards,

          - --
          Dominique QUATRAVAUX Ingénieur senior
          01 44 42 00 08 IDEALX

          -----BEGIN PGP SIGNATURE-----
          Version: GnuPG v1.2.4 (GNU/Linux)
          Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

          iD8DBQFB9jCqMJAKAU3mjcsRAkpDAJ4nY9C9vtmgwNltVF4gtKpSqXA79wCfaII4
          9a9oH/a+YQ4tLHDQ4Yb5nLk=
          =3oLh
          -----END PGP SIGNATURE-----
        • Geoffrey Young
          ... that s not surprising. basically, this test is an informative one, designed to let us know how apache is behaving around this particular issue not
          Message 4 of 4 , Jan 25, 2005
          • 0 Attachment
            > - my $cl = have_min_apache_version(2.1) ? undef : 0;
            > - my $head_cl = have_min_apache_version(2.1) ? $cl : undef;
            > + my $cl = 1 ? undef : 0;
            > + my $head_cl = 1 ? $cl : undef;
            >
            > ~ ok t_cmp $res->code, 200, "$method $uri code";
            > ~ ok t_cmp ($res->header('Content-Length'),
            >
            > then (unsurprisingly) test 2 passes, but 5 and 17 still fail in the
            > same way as above.

            that's not surprising. basically, this test is an informative one, designed
            to let us know how apache is behaving around this particular issue not
            necessarily for mod_perl proper, but so our users know what to expect.

            so, I'll take a look at this when I can and update it to reflect the current
            situation as best I can, but there is no reason to worry about it as far as
            mod_perl goes.

            --Geoff
          Your message has been successfully submitted and would be delivered to recipients shortly.