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

Re: [mp2] registry tests problems (powerpc-aix-5.1.0.0 platform / IBM RS6000)

Expand Messages
  • Alexey Bozrikov
    The core file actually have been created (although no Core dumped message anywhere during tests). That s the backtrace from Modperl-Registry test: [quote]
    Message 1 of 24 , Aug 2, 2004
    • 0 Attachment
      The core file actually have been created (although no 'Core dumped'
      message anywhere during tests). That's the backtrace from
      Modperl-Registry test:

      [quote]
      gdb /usr/local/apache2/bin/httpd -core t/core
      GNU gdb 6.1
      Copyright 2004 Free Software Foundation, Inc.
      GDB is free software, covered by the GNU General Public License, and you are
      welcome to change it and/or distribute copies of it under certain conditions.
      Type "show copying" to see the conditions.
      There is absolutely no warranty for GDB. Type "show warranty" for details.
      This GDB was configured as "powerpc-ibm-aix5.1.0.0"...
      Core was generated by `httpd'.
      Program terminated with signal 11, Segmentation fault.
      #0 0x1003169c in sig_coredump (sig=11) at mpm_common.c:955
      955 mpm_common.c: No such file or directory.
      in mpm_common.c
      (gdb) bt
      #0 0x1003169c in sig_coredump (sig=11) at mpm_common.c:955
      #1 <signal handler called>
      #2 0xd201ab70 in mpxs_Apache__RequestRec_content_type (r=???, type=???)
      at /home/bozy/src/modperl-2.0/xs/Apache/RequestRec/Apache__RequestRec.h:27
      #3 0xd201b344 in XS_Apache__RequestRec_content_type (cv=0x204347d4) at RequestRec.xs:155
      #4 0xd1ea2924 in Perl_pp_entersub () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
      #5 0xd1f1b864 in Perl_runops_standard () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
      #6 0xd1ee31e4 in S_call_body () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
      #7 0xd1ee2e64 in Perl_call_sv () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
      #8 0xd1f58ef8 in modperl_callback (handler=0x2032af48, p=0x20d55920, r=0x20d55958, s=0x20229130, args=0x2037acac)
      at modperl_callback.c:99
      #9 0xd1f5988c in modperl_callback_run_handlers (idx=6, type=4, r=0x20d55958, c=0x0, s=0x20229130, pconf=0x0, plog=0x0, ptemp=0x0,
      run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:268
      #10 0xd1f59b94 in modperl_callback_per_dir (idx=6, r=0x20d55958, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:356
      #11 0xd1f60fa0 in modperl_response_handler_run (r=0x20d55958, finish=0) at mod_perl.c:905
      #12 0xd1f61318 in modperl_response_handler_cgi (r=0x20d55958) at mod_perl.c:1000
      #13 0x1000aadc in ap_run_handler (r=0x20d55958) at config.c:151
      #14 0x1000b640 in ap_invoke_handler (r=0x20d55958) at config.c:358
      #15 0x1002c128 in ap_process_request (r=0x20d55958) at http_request.c:246
      #16 0x10038b9c in ap_process_http_connection (c=0x20d4d9f0) at http_core.c:250
      #17 0x100343cc in ap_run_process_connection (c=0x20d4d9f0) at connection.c:42
      #18 0x1002e988 in child_main (child_num_arg=0) at prefork.c:609
      #19 0x1002eb4c in make_child (s=0x0, slot=2) at prefork.c:703
      #20 0x1002eeb0 in perform_idle_server_maintenance (p=0x0) at prefork.c:838
      #21 0x1002f5e4 in ap_mpm_run (_pconf=0x20007868, plog=0xffffffff, s=0x0) at prefork.c:1039
      #22 0x100012dc in main (argc=7, argv=0x2ff22964) at main.c:617
      [unquote]

      Regards

      Alexey

      SB> Alexey Bozrikov wrote:

      SB> [taking the ModPerl-Registry branch of this multi-faced thread]

      >> Now, make test in ModPerl-Registry yields some error messages:
      SB> [...]
      >> t/404.t 2 2 100.00% 1-2
      >> t/bad_scripts.t 1 1 100.00% 1
      >> t/basic.t 18 1 5.56% 17
      >> t/cgi.t 2 1 50.00% 2
      >> 2 tests skipped.
      >> Failed 4/14 test scripts, 71.43% okay. 5/70 subtests failed, 92.86% okay.
      >> [warning] server localhost:8529 shutdown
      >> [warning] port 8529 still in use...
      >> ...done
      >> [ error] error running tests (please examine t/logs/error_log)
      >> [unquote]
      >>
      >> The Apache error log contains following:
      >>
      >> [quote cat t/logs/error_log]
      >> [Fri Jul 30 08:55:15 2004] [notice] Apache/2.0.49 (Unix)
      >> mod_perl/1.99_15-dev Perl/v5.8.4 PHP/5.0.0 DAV/2 configured --
      >> resuming normal operations
      >> [Fri Jul 30 08:55:15 2004] [info] Server built: Jul 15 2004 12:00:32
      >> [Fri Jul 30 08:55:15 2004] [debug] prefork.c(955): AcceptMutex: sysvsem (default: sysvsem)
      >>
      >> *** The following error entry is expected and harmless ***
      >> [Fri Jul 30 08:55:55 2004] [error]
      >> /home/bozy/src/modperl-2.0/ModPerl-Registry/t/cgi-bin/cannot_be_found
      >> not found or unable to stat
      >> [Fri Jul 30 08:55:55 2004] [error] mpxs_Apache__RequestRec_print:
      >> $r->print can't be called before the response phase during global
      >> destruction.\n
      >> [Fri Jul 30 08:55:56 2004] [notice] child pid 16168 exit signal Segmentation fault (11)

      SB> You have a few segfaults reported. could you arrange for core files to
      SB> be allowed? Apache-Test is already doing that (ulimit -c unlimited), but
      SB> it doesn't seem to have an affect. Do you know why?

      SB> Once you get the core files, show us their backtraces.
      SB> http://perl.apache.org/docs/2.0/user/help/help.html#Resolving_Segmentation_Faults

      SB> Now while you are rebuilding things, please use the current modperl cvs,
      SB> so we will be in sync. Thanks.
      SB> http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution





      ** Nothing is illegal until you get caught.


      --
      Report problems: http://perl.apache.org/bugs/
      Mail list info: http://perl.apache.org/maillist/modperl.html
      List etiquette: http://perl.apache.org/maillist/email-etiquette.html
    • Stas Bekman
      ... what does ??? means? is it a corrupted frame? why there is no address? Now, can you identify which test causes that? For example: cd ModPerl-Registry
      Message 2 of 24 , Aug 2, 2004
      • 0 Attachment
        Alexey Bozrikov wrote:
        > The core file actually have been created (although no 'Core dumped'
        > message anywhere during tests). That's the backtrace from
        > Modperl-Registry test:
        >
        > [quote]
        > gdb /usr/local/apache2/bin/httpd -core t/core
        > GNU gdb 6.1
        > Copyright 2004 Free Software Foundation, Inc.
        > GDB is free software, covered by the GNU General Public License, and you are
        > welcome to change it and/or distribute copies of it under certain conditions.
        > Type "show copying" to see the conditions.
        > There is absolutely no warranty for GDB. Type "show warranty" for details.
        > This GDB was configured as "powerpc-ibm-aix5.1.0.0"...
        > Core was generated by `httpd'.
        > Program terminated with signal 11, Segmentation fault.
        > #0 0x1003169c in sig_coredump (sig=11) at mpm_common.c:955
        > 955 mpm_common.c: No such file or directory.
        > in mpm_common.c
        > (gdb) bt
        > #0 0x1003169c in sig_coredump (sig=11) at mpm_common.c:955
        > #1 <signal handler called>
        > #2 0xd201ab70 in mpxs_Apache__RequestRec_content_type (r=???, type=???)

        what does ??? means? is it a corrupted frame? why there is no address?

        Now, can you identify which test causes that? For example:

        cd ModPerl-Registry
        t/TEST -start
        t/TEST -run t/404.t
        t/TEST -run t/cgi.t
        etc...

        --
        __________________________________________________________________
        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

        --
        Report problems: http://perl.apache.org/bugs/
        Mail list info: http://perl.apache.org/maillist/modperl.html
        List etiquette: http://perl.apache.org/maillist/email-etiquette.html
      • Alexey Bozrikov
        I guess these ??? symbols were due to use of old `IBM version of gdb, now I switched to 6.1, and grabbed latest modperl-2.0 CVS snapshot as well.
        Message 3 of 24 , Aug 5, 2004
        • 0 Attachment
          I guess these '???' symbols were due to use of old `IBM' version of gdb, now I switched
          to 6.1, and grabbed latest 'modperl-2.0' CVS snapshot as well.
          Modperl-Registry tests fail, this is something I've got from `TEST -debug':

          [quote]
          Failed Test Stat Wstat Total Fail Failed List of Failed
          -------------------------------------------------------------------------------
          t/404.t 2 2 100.00% 1-2
          t/bad_scripts.t 1 1 100.00% 1
          t/basic.t 18 1 5.56% 17
          t/cgi.t 2 1 50.00% 2
          2 tests skipped.
          Failed 4/14 test scripts, 71.43% okay. 5/70 subtests failed, 92.86% okay.
          [warning] server localhost:8529 shutdown
          [ error] error running tests (please examine t/logs/error_log)
          [ error] oh rats, server dumped core
          [ error] for stacktrace, run: gdb /usr/local/apache2/bin/httpd -core /home/bozy/src/modperl-2.0/ModPerl-Registry/t/core
          gdb /usr/local/apache2/bin/httpd -core /home/bozy/src/modperl-2.0/ModPerl-Registry/t/core
          GNU gdb 6.1
          [...skipped...]
          This GDB was configured as "powerpc-ibm-aix5.1.0.0"...(no debugging symbols found)...
          Core was generated by `httpd'.
          Program terminated with signal 11, Segmentation fault.
          #0 0x10033994 in sig_coredump ()
          (gdb) bt
          #0 0x10033994 in sig_coredump ()
          #1 <signal handler called>
          #2 0xd11cfae0 in mpxs_Apache__RequestRec_content_type (my_perl=0x202da868, r=0x20ee3088, type=0x20f49d08)
          at /home/bozy/src/modperl-2.0/xs/Apache/RequestRec/Apache__RequestRec.h:27
          #3 0xd11cf25c in XS_Apache__RequestRec_content_type (my_perl=0x202da868, cv=0x204bc530) at RequestRec.xs:37
          #4 0xd0ffc230 in Perl_pp_entersub () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
          #5 0xd1079054 in Perl_runops_standard () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
          #6 0xd0fba90c in S_call_body () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
          #7 0xd0fbea68 in Perl_call_sv () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
          #8 0xd0f7dd00 in modperl_callback (my_perl=0x202da868, handler=0x2038fdb8, p=
          gdbtypes.c:528: internal-error: make_cv_type: Assertion `TYPE_OBJFILE (*typeptr) == TYPE_OBJFILE (type) || TYPE_STUB (*typeptr)' failed.
          A problem internal to GDB has been detected,
          further debugging may prove unreliable.
          [unquote]

          Individual tests show following:

          t/TEST -start
          t/TEST -run t/404.t
          [all 2 test failed, server dumped core]

          t/logs-error_log shows following:
          [quote]
          [Thu Aug 05 16:03:25 2004] [notice] Apache/2.0.50 (Unix) mod_perl/1.99_15-dev Perl/v5.8.5 DAV/2 configured -- resuming normal operations
          [Thu Aug 05 16:03:25 2004] [info] Server built: Jul 30 2004 09:51:50
          [Thu Aug 05 16:03:25 2004] [debug] prefork.c(955): AcceptMutex: sysvsem (default: sysvsem)

          *** The following error entry is expected and harmless ***
          [Thu Aug 05 16:03:46 2004] [error] /home/bozy/src/modperl-2.0/ModPerl-Registry/t/cgi-bin/cannot_be_found not found or unable to stat
          [Thu Aug 05 16:03:46 2004] [notice] child pid 24056 exit signal Segmentation fault (11)
          [Thu Aug 05 16:03:46 2004] [error] /home/bozy/src/modperl-2.0/xs/Apache/RequestIO/Apache__RequestIO.h:92: $r->print can't be called befo
          re the response phase at /home/bozy/src/modperl-2.0/ModPerl-Registry/t/cgi-bin/status_change.pl line 3.\n
          [Thu Aug 05 16:08:00 2004] [info] removed PID file /home/bozy/src/modperl-2.0/ModPerl-Registry/t/logs/httpd.pid (pid=6650)
          [Thu Aug 05 16:08:00 2004] [notice] caught SIGTERM, shutting down
          [unquote]

          gdb ~apache/bin/httpd -core t/core
          [quote]
          (gdb) bt
          #0 0x10033994 in sig_coredump ()
          #1 <signal handler called>
          #2 0xd11cfad4 in mpxs_Apache__RequestRec_content_type (my_perl=0x202da868, r=0x20eec6d8, type=0x20ef47f8)
          at /home/bozy/src/modperl-2.0/xs/Apache/RequestRec/Apache__RequestRec.h:27
          #3 0xd11cf25c in XS_Apache__RequestRec_content_type (my_perl=0x202da868, cv=0x204bc530) at RequestRec.xs:37
          #4 0xd0ffc230 in Perl_pp_entersub () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
          #5 0xd1079054 in Perl_runops_standard () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
          #6 0xd0fba90c in S_call_body () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
          #7 0xd0fbea68 in Perl_call_sv () from /home/bozy/src/modperl-2.0/src/modules/perl/mod_perl.so
          #8 0xd0f7dd00 in modperl_callback (my_perl=0x202da868, handler=0x2057ec58, p=
          [unquote]


          t/TEST -start
          using Apache/2.0.50 (prefork MPM)
          server localhost:8529 started

          bozy@scf-db01 ~/src/modperl-2.0/ModPerl-Registry > t/TEST -run t/cgi.t
          t/cgi....# Failed test 2 in t/cgi.t at line 17
          t/cgi....FAILED test 2
          Failed 1/2 tests, 50.00% okay
          Failed Test Stat Wstat Total Fail Failed List of Failed
          -------------------------------------------------------------------------------
          t/cgi.t 2 1 50.00% 2
          Failed 1/1 test scripts, 0.00% okay. 1/2 subtests failed, 50.00% okay.

          No coredumps, though. t/logs/error_log shows following:
          [quote]
          [Thu Aug 05 16:08:04 2004] [notice] Apache/2.0.50 (Unix) mod_perl/1.99_15-dev Perl/v5.8.5 DAV/2 configured -- resuming normal operations
          [Thu Aug 05 16:08:04 2004] [info] Server built: Jul 30 2004 09:51:50
          [Thu Aug 05 16:08:04 2004] [debug] prefork.c(955): AcceptMutex: sysvsem (default: sysvsem)
          [Thu Aug 05 16:08:15 2004] [error] Global $r object is not available. Set:\n\tPerlOptions +GlobalRequest\nin httpd.conf at /usr/local/li
          b/perl5/5.8.5/CGI.pm line 315.\n

          [unquote]

          Does not really mean too much to me..


          Regards

          Alexey



          SB> Alexey Bozrikov wrote:
          >> The core file actually have been created (although no 'Core dumped'
          >> message anywhere during tests). That's the backtrace from
          >> Modperl-Registry test:
          >>
          >> [quote]
          >> gdb /usr/local/apache2/bin/httpd -core t/core
          >> GNU gdb 6.1
          >> Copyright 2004 Free Software Foundation, Inc.
          >> GDB is free software, covered by the GNU General Public License, and you are
          >> welcome to change it and/or distribute copies of it under certain conditions.
          >> Type "show copying" to see the conditions.
          >> There is absolutely no warranty for GDB. Type "show warranty" for details.
          >> This GDB was configured as "powerpc-ibm-aix5.1.0.0"...
          >> Core was generated by `httpd'.
          >> Program terminated with signal 11, Segmentation fault.
          >> #0 0x1003169c in sig_coredump (sig=11) at mpm_common.c:955
          >> 955 mpm_common.c: No such file or directory.
          >> in mpm_common.c
          >> (gdb) bt
          >> #0 0x1003169c in sig_coredump (sig=11) at mpm_common.c:955
          >> #1 <signal handler called>
          >> #2 0xd201ab70 in mpxs_Apache__RequestRec_content_type (r=???, type=???)

          SB> what does ??? means? is it a corrupted frame? why there is no address?

          SB> Now, can you identify which test causes that? For example:

          SB> cd ModPerl-Registry
          SB> t/TEST -start
          SB> t/TEST -run t/404.t
          SB> t/TEST -run t/cgi.t
          SB> etc...

          SB> --
          SB> __________________________________________________________________
          SB> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
          SB> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
          SB> mailto:stas@... http://use.perl.org http://apacheweek.com
          SB> http://modperlbook.org http://apache.org http://ticketmaster.com





          ** Make WAR, not SEX, it's safer!


          --
          Report problems: http://perl.apache.org/bugs/
          Mail list info: http://perl.apache.org/maillist/modperl.html
          List etiquette: http://perl.apache.org/maillist/email-etiquette.html
        • Stas Bekman
          I think I may know what the problem is (at least one of them). I ve used that t/cgi.t test with ModPerl-Registry and stepped through with gdb on your machine.
          Message 4 of 24 , Aug 9, 2004
          • 0 Attachment
            I think I may know what the problem is (at least one of them). I've used
            that t/cgi.t test with ModPerl-Registry and stepped through with gdb on
            your machine.

            This particular problem of not having Apache->request available, even
            though you run under 'SetHandler perl-script' seems to be due to the use
            of static variables.

            src/modules/perl/modperl_global.c creates a static variable for $r.

            static modperl_global_t MP_tls_##gname;

            which after expanding macros translates to:

            static modperl_global_t *MP_tls_request_rec

            Now observe:

            Breakpoint 7, modperl_global_request_set (r=0x20e3d738) at
            modperl_global.c:31
            31 MP_dRCFG;
            (gdb) n
            ...
            (gdb) n
            38 modperl_tls_set_request_rec(r);
            (gdb) p *MP_tls_request_rec
            $28 = {flags = 0, data = 0x0, name = 0x0}

            That's the value of MP_tls_request_rec before setting it to $r

            (gdb) n
            41 MpReqSET_GLOBAL_REQUEST_On(rcfg);
            (gdb) p *MP_tls_request_rec
            $29 = {flags = 0, data = 0x0, name = 0x0}

            As you can see it ain't working. So obviously when later on it tries to
            get that data out and use it, it fails and hence you get this kind of
            errors:

            Global $r object is not available. Set:\n\tPerlOptions
            +GlobalRequest\nin httpd.conf at ...

            So, are you aware with problems of using static variables on your
            platform? Is it compiler specific? Does it get them optimized away or
            something?

            If you rebuild your perl with ithreads and APR has ithreads too, which
            seems to be the case, since it links pthread

            *** (apr|apu)-config linking info

            -L/usr/local/apache2/lib -lapr-0 -lm -lnsl -lpthread
            -L/usr/local/apache2/lib -laprutil-0 -ldb-4.2 -lexpat -liconv

            and then rebuild mod_perl, it may fare better, as it'll use TLS instead
            of the static for this particular thing. If your threads implementation
            is good it should work well.

            Another possibility to try is to compile mod_perl statically, but I'm
            not sure if it's going to make any difference. I'd try a threaded perl
            first.

            BTW, should you explore it on your own (and may be faster machine :)
            I've attached the gdb debug script I have used. You use it as follows:

            console one: gdb --command=debug
            wait a bit now:
            console two: t/TEST -v -run t/cgi.t

            For more information see:
            http://perl.apache.org/docs/2.0/devel/debug/c.html#Precooked_gdb_Startup_Scripts


            --
            __________________________________________________________________
            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
          • Alexey Bozrikov
            I guess I am slowly starting to understand what s happening. I ve built modperl on other machine which has perl with ithreads, at least perl -V produces:
            Message 5 of 24 , Aug 9, 2004
            • 0 Attachment
              I guess I am slowly starting to understand what's happening. I've built
              modperl on other machine which has perl with ithreads, at least perl -V
              produces:

              [quote]
              osname=aix, osvers=5.1.0.0, archname=aix-thread-multi
              config_args=''
              hint=previous, useposix=true, d_sigaction=define
              usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
              [unquote]

              APR/APU config hast -lpthreads in it, and modperl Makefile has
              -lpthreads and _THREAD_SAFE macro defined.

              The result of t/cgi.t test is exactly the same as you described,
              error_log shows:
              [error] Global $r object is not available. Set:\n\tPerlOptions +GlobalRequest\nin httpd.conf at /usr/local/li
              b/perl5/5.8.5/CGI.pm line 315.\n

              There must be something wrong with static variables then, threads
              implementation on this platform is good enough to my belief for major
              software like Oracle, Apache or perl. We seem to be fairly close to
              positive result, I guess. I'll try to investigate, make
              some tests and revert back to you as soon as there are any results.

              Regards

              Alexei

              [skipped]
              SB> (gdb) n
              SB> 41 MpReqSET_GLOBAL_REQUEST_On(rcfg);
              SB> (gdb) p *MP_tls_request_rec
              SB> $29 = {flags = 0, data = 0x0, name = 0x0}

              SB> As you can see it ain't working. So obviously when later on it tries to
              SB> get that data out and use it, it fails and hence you get this kind of
              SB> errors:

              SB> Global $r object is not available. Set:\n\tPerlOptions
              SB> +GlobalRequest\nin httpd.conf at ...

              SB> So, are you aware with problems of using static variables on your
              SB> platform? Is it compiler specific? Does it get them optimized away or
              SB> something?

              SB> If you rebuild your perl with ithreads and APR has ithreads too, which
              SB> seems to be the case, since it links pthread

              [skipped]





              ** Mother Nature is a bitch.


              --
              Report problems: http://perl.apache.org/bugs/
              Mail list info: http://perl.apache.org/maillist/modperl.html
              List etiquette: http://perl.apache.org/maillist/email-etiquette.html
            Your message has been successfully submitted and would be delivered to recipients shortly.