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
  • Stas Bekman
    Alexey Bozrikov wrote: [taking the ModPerl-Registry branch of this multi-faced thread] ... [...] ... You have a few segfaults reported. could you arrange for
    Message 1 of 24 , Aug 1, 2004
      Alexey Bozrikov wrote:

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

      > Now, make test in ModPerl-Registry yields some error messages:
      [...]
      > 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)

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

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

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

      --
      __________________________________________________________________
      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
      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 2 of 24 , Aug 2, 2004
        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 3 of 24 , Aug 2, 2004
          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 4 of 24 , Aug 5, 2004
            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 5 of 24 , Aug 9, 2004
              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 6 of 24 , Aug 9, 2004
                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.