subject:"Re\: segfault"

Re: segfault after HTTP_MOVED_* and set_handlers()

2002-12-06 Thread Geoffrey Young



Stefano wrote:

Hello,

This is a  question about the correct use of set_handlers request
method.

I have some handlers stacked by the first one content handler;
one of them processing the request needs to redirect and then close
the HTTP response with a HTTP_MOVED_PERMANENTLY;

so I thought that the following stacked handlers have to be removed
from the stack with a $r->set_handlers('PerlHandler' => undef) in a way
such:

	$r->content_type('text/html') ;
	$r->header_out('Location', '/go/there') ;
	$r->set_handlers('PerlHandler' => undef) ;


you can't currently set_handlers() for the current phase.  sorry.  there was a patch 
floating around to do this, but it was never integrated.

	return HTTP_MOVED_PERMANENTLY ;


that should terminate the phase entirely and keep the other handlers from running - no 
need to explicitly undef the stack anyway.

HTH

--Geoff

Re: Segfault when using LWP

2002-03-01 Thread Ryan Veety


DOH!  Nevermind, I figured it out.  I didn't run ldconfig after upgrading
openssl, so httpd was linked to a different version than the ssl perl modules,
which aparently caused the segfaults...  Like I said earlier I thought it was
a library version mismatch so I recompiled *everything*, but for some reason
the perl modules seemed to pick up the new libcrypto without me running
ldconfig??.  Oh well, thanks anyway.

Ryan
 __
   .'  Ryan Veety <[EMAIL PROTECTED]> - http://www.ryanspc.com  `.
   |  PGP Key: http://www.ryanspc.com/pgp.txt   |
`--'

Re: segfault when using PerlRequire

2002-01-13 Thread John D Groenveld


> I assume that you use Apache DSO. I think that you need to rebuild your 
> perl with -Ubincompat5005. I cannot see the value of bincompat5005 in 
> your 'perl -V' 
> http://perl.apache.org/guide/install.html#When_DSO_can_be_Used

Still cores after explicit -Ubincompat5005, I'm fairly certain I answered
"NO" to that question. Thanks for pointing me to the guide, I'm due for
a refresher reading from top to bottom.
John
[EMAIL PROTECTED]

Re: segfault when using PerlRequire

2002-01-13 Thread Stas Bekman


John D Groenveld wrote:

> I hesitate to post this because I haven't kept up with my reading. I did 
> do several searches of my 28K message modperl mail folder and the list
> archives.
> 
> My httpd.conf reads...
> LoadModule perl_module  /opt/apache/libexec/libperl.so
> #PerlModule Apache::Status
> PerlRequire /home/stevens.1/apache-perl/conf/startup.pl
> 
> If I uncomment the PerlModule config, then no core dump.
> If I downgrade to perl-5.0.3, then no core dump.
> If I Configure -Uuselargefiles, I still core dump.
> 
> Solaris bug, Perl bug, modperl bug, Apache bug, or driver error?


I assume that you use Apache DSO. I think that you need to rebuild your 
perl with -Ubincompat5005. I cannot see the value of bincompat5005 in 
your 'perl -V' 
http://perl.apache.org/guide/install.html#When_DSO_can_be_Used


> Thanks,
> John
> [EMAIL PROTECTED]
> 
> gdb /opt/apache/bin/httpd
> GNU gdb 5.0
> Copyright 2000 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 "i386-pc-solaris2.7"...
> (gdb) run -d /home/stevens.1/apache-perl -X
> Starting program: /opt/apache/bin/httpd -d /home/stevens.1/apache-perl -X
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xdf7eaf83 in S_new_xpvnv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libper
> l.so
> (gdb) bt
> #0  0xdf7eaf83 in S_new_xpvnv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li
> bperl.so
> #1  0xdf7eb859 in Perl_sv_upgrade () from /opt/perl/lib/5.6.1/i86pc-solaris/COR
> E/libperl.so
> #2  0xdf7ba53a in Perl_pad_allocmy () from /opt/perl/lib/5.6.1/i86pc-solaris/CO
> RE/libperl.so
> #3  0xdf7a5f29 in Perl_yylex () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/lib
> perl.so
> #4  0xdf7b7f4f in Perl_yyparse () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l
> ibperl.so
> #5  0xdf80ce5a in S_doeval () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libpe
> rl.so
> #6  0xdf80e1c8 in Perl_pp_require () from /opt/perl/lib/5.6.1/i86pc-solaris/COR
> E/libperl.so
> #7  0xdf7e36cd in Perl_runops_standard () from /opt/perl/lib/5.6.1/i86pc-solari
> s/CORE/libperl.so
> #8  0xdf79ba0c in S_call_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li
> bperl.so
> #9  0xdf79b772 in Perl_call_sv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l
> ibperl.so
> #10 0xdf79eacb in S_call_list_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CO
> RE/libperl.so
> #11 0xdf79e743 in Perl_call_list () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE
> /libperl.so
> #12 0xdf7c37eb in Perl_newATTRSUB () from /opt/perl/lib/5.6.1/i86pc-solaris/COR
> E/libperl.so
> #13 0xdf7c0636 in Perl_utilize () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l
> ibperl.so
> #14 0xdf7b8d1a in Perl_yyparse () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l
> ibperl.so
> #15 0xdf80ce5a in S_doeval () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/libpe
> rl.so
> #16 0xdf80e1c8 in Perl_pp_require () from /opt/perl/lib/5.6.1/i86pc-solaris/COR
> E/libperl.so
> #17 0xdf7e36cd in Perl_runops_standard () from /opt/perl/lib/5.6.1/i86pc-solari
> s/CORE/libperl.so
> #18 0xdf79ba0c in S_call_body () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/li
> bperl.so
> #19 0xdf79bb92 in Perl_eval_sv () from /opt/perl/lib/5.6.1/i86pc-solaris/CORE/l
> ibperl.so
> #20 0xdf546147 in perl_do_file () from /opt/apache/libexec/libperl.so
> #21 0xdf5461f2 in perl_load_startup_script () from 
> /opt/apache/libexec/libperl.so
> #22 0xdf540f93 in perl_cmd_require () from /opt/apache/libexec/libperl.so
> #23 0x805e15b in invoke_cmd ()
> #24 0x805e629 in ap_handle_command ()
> #25 0x805e6cb in ap_srm_command_loop ()
> #26 0x805ed93 in ap_process_resource_config ()
> #27 0x805f718 in ap_read_config ()
> #28 0x806a26b in standalone_main ()
> #29 0x806abf0 in main ()
> #30 0x8057bf3 in _start ()
> 
> perl -V
> Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
>   Platform:
> osname=solaris, osvers=2.7, archname=i86pc-solaris
> uname='sunos stevens 5.7 generic_106542-18 i86pc i386 i86pc '
> config_args='-Dprefix=/opt/perl -Dcc=gcc -Duseshrplib -Uusemymalloc'
> hint=recommended, useposix=true, d_sigaction=define
> usethreads=undef use5005threads=undef useithreads=undef 
> usemultiplicity=undef
> useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
> use64bitint=undef use64bitall=undef uselongdouble=undef
>   Compiler:
> cc='gcc', ccflags ='-fno-strict-aliasing -I/opt/gnu/include 
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
> optimize='-O',
> cppflags='-fno-strict-aliasing -I/opt/gnu/include'
> ccversion='', gccversion='2.95.3 20010315 (release)', 
> gccosandvers='solaris2.7'
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
> d_longlong=define, longlongsize=8, d_lo

Re: SegFault report with backtrace

2001-11-05 Thread karnurme



> > Here is a simple Test.pm handler that causes segfaults in our server.
> By accident I discovered that the segfaults went away when I renamed
> the file!  At the time I was doing some work for a company in London,

Thanks for idea! I'm afraid that the segfault report may be affected by
the naming, but the original module that caused the error was not named as
Test.pm. What a coincidence if I picked the one problematic
naming; Kari, the Midas of Bugs...

Best wishes,
-- 

Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547

Re: SegFault report with backtrace

2001-11-05 Thread Ged Haywood


Hi there,

On Mon, 5 Nov 2001 [EMAIL PROTECTED] wrote:

> Here is a simple Test.pm handler that causes segfaults in our server.

Last year I had a Test.pm that caused segfaults too, on Solaris boxes.

By accident I discovered that the segfaults went away when I renamed
the file!  At the time I was doing some work for a company in London,
on a very tight schedule, so I never got the chance to investigate
further.  I sent a stack backtrace to Eric but we never got to the
bottom of it.

73,
Ged.

Re: segfault on start....

2001-10-02 Thread Derek Balling



>Joshua meant for you to run it in gdb with that option, but it might not
>be very helpfull if you didn't compile with CFLAGS=-g

Well, I did PERL_DEBUG=1, which allegedly does that. :)

>But you can try it anyay:
>
>gdb ../bin/httpd
>
>(gdb) run -X
>
>(gdb) bt
>
>and send the information it gives here.

(gdb) run -X -f conf/httpd.conf.mod_perl
Starting program: /web1.3/conf/../bin/httpd -X -f conf/httpd.conf.mod_perl

Program received signal SIGSEGV, Segmentation fault.
0x80de49c in Perl_gv_fetchpv ()
(gdb) bt
#0  0x80de49c in Perl_gv_fetchpv ()
#1  0x80da33f in Perl_get_sv ()
#2  0x808a461 in perl_create_request_config ()
#3  0x808a6ac in perl_cmd_handler_handlers ()
#4  0x80afde6 in ap_clear_module_list ()
#5  0x80b0223 in ap_handle_command ()
#6  0x80b02b7 in ap_srm_command_loop ()
#7  0x80b0910 in ap_process_resource_config ()
#8  0x80b1182 in ap_read_config ()
#9  0x80bb0a9 in main ()
#10 0x400df1eb in __libc_start_main (main=0x80bae1c , argc=4,
 argv=0xbc54, init=0x8062748 <_init>, fini=0x816442c <_fini>,
 rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbc4c)
 at ../sysdeps/generic/libc-start.c:90

>  > Pretend like I'm NOT some C-code guru, and explain to me what I need
>>  to do, because it doesn't seem like doing what the docs say is
>>  helping. *chuckle*
>
>Isn't there anything about debugging in the documentation?

It all seems centered around, near as I can tell, "debugging a server 
that runs but takes a dump on a particular script/URL/etc."

D

-- 
+-+-+
| [EMAIL PROTECTED]  | "Thou art the ruins of the noblest man  |
|  Derek J. Balling   |  That ever lived in the tide of times.  |
| |  Woe to the hand that shed this costly  |
| |  blood" - Julius Caesar Act 3, Scene 1  |
+-+-+

Re: segfault on start....

2001-10-02 Thread Joshua Chamas

Derek Balling wrote:
> 
> >
> >Run your httpd in -X mode without the help of the apachectl start
> >script.  You can get that under gdb. -X mode runs in single
> >process mode, and is most handy for diagnosing problems such
> >as these.
> 
> I guess I'm dense:
> 
> # ../bin/httpd -X -f conf/httpd.conf.mod_perl
> Segmentation fault
> 
> how is this more helpful? ;)
> 
> Pretend like I'm NOT some C-code guru, and explain to me what I need
> to do, because it doesn't seem like doing what the docs say is
> helping. *chuckle*
> 

unix prompt> gdb ../bin/httpd
... gdb header stuff ...
(gdb) run -X -f conf/httpd.conf.mod_perl
Segfault
(gdb) bt
!!! UGLY STACK TRACE TO FOLLOW !!!

This *MIGHT* give the real gurus on the list something
to work with.  Its how I have debugged many a segfault
in my day.  This or something like it.  You can also
load up a core dump with gdb, but I can't remember
the last time I did that, so I have no real directions
here, but its probably just 

prompt> gdb core
...
(gdb) bt
[ find out where it segfaulted ]

--Josh
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks Founder   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051

Re: segfault on start....

2001-10-02 Thread Thomas Eibner


On Tue, Oct 02, 2001 at 10:46:45PM -0700, Derek Balling wrote:
> >Run your httpd in -X mode without the help of the apachectl start
> >script.  You can get that under gdb. -X mode runs in single
> >process mode, and is most handy for diagnosing problems such
> >as these.
> 
> I guess I'm dense:
> 
> # ../bin/httpd -X -f conf/httpd.conf.mod_perl
> Segmentation fault
> 
> how is this more helpful? ;)

Joshua meant for you to run it in gdb with that option, but it might not
be very helpfull if you didn't compile with CFLAGS=-g
But you can try it anyay:

gdb ../bin/httpd

(gdb) run -X

(gdb) bt

and send the information it gives here.

Another option would be to:

to use strace|truss|whatever your system uses to trace system call

strace ../bin/httpd -X

Which might give you a lot of information which will very likely be
to much to post here.

> Pretend like I'm NOT some C-code guru, and explain to me what I need 
> to do, because it doesn't seem like doing what the docs say is 
> helping. *chuckle*

Isn't there anything about debugging in the documentation?

-- 
  Thomas Eibner  DnsZone 
  mod_pointer

Re: segfault on start....

2001-10-02 Thread Derek Balling


At 10:38 PM -0700 10/2/01, Joshua Chamas wrote:
>Derek Balling wrote:
>>
>>  Did that. THAT's the output I get, nothing more. Make test, and the
>>  test server all check out 100% and run fine, its only when I put it
>>  in production that it takes a dump, and leaves absolutely nothing
>>  except what you see there.
>>
>>  Lots of the "segfault" stuff in SUPPORT has to do with "when it
>>  segfaults on a request". It's hard to "attach to the running process"
>>  or "send the request that causes the segfault" when you can't get
>>  that far. ;)
>>
>
>Run your httpd in -X mode without the help of the apachectl start
>script.  You can get that under gdb. -X mode runs in single
>process mode, and is most handy for diagnosing problems such
>as these.

I guess I'm dense:

# ../bin/httpd -X -f conf/httpd.conf.mod_perl
Segmentation fault

how is this more helpful? ;)

Pretend like I'm NOT some C-code guru, and explain to me what I need 
to do, because it doesn't seem like doing what the docs say is 
helping. *chuckle*

What can I give you that would be helpful to debug this? :)

D

-- 
+-+-+
| [EMAIL PROTECTED]  | "Thou art the ruins of the noblest man  |
|  Derek J. Balling   |  That ever lived in the tide of times.  |
| |  Woe to the hand that shed this costly  |
| |  blood" - Julius Caesar Act 3, Scene 1  |
+-+-+

Re: segfault on start....

2001-10-02 Thread Joshua Chamas


Derek Balling wrote:
> 
> Did that. THAT's the output I get, nothing more. Make test, and the
> test server all check out 100% and run fine, its only when I put it
> in production that it takes a dump, and leaves absolutely nothing
> except what you see there.
> 
> Lots of the "segfault" stuff in SUPPORT has to do with "when it
> segfaults on a request". It's hard to "attach to the running process"
> or "send the request that causes the segfault" when you can't get
> that far. ;)
> 

Run your httpd in -X mode without the help of the apachectl start
script.  You can get that under gdb. -X mode runs in single 
process mode, and is most handy for diagnosing problems such
as these.

--Josh
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks Founder   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051

Re: segfault on start....

2001-10-02 Thread Derek Balling

At 1:01 PM +0800 10/3/01, Stas Bekman wrote:
>Derek Balling wrote:
>
>>I seem to have something boned... I can't even run an apachectl 
>>configtest without segfaulting.
>>
>># ../bin/apachectl start
>>../bin/apachectl: line 171: 16563 Segmentation fault  $HTTPD
>>../bin/apachectl start: httpd could not be started
>>
>>Removing the Apache::Registry call from my httpd.conf makes the 
>>problem go away immediately.
>>
>>This is on apache 1.3.20, mod_perl 1.26, and perl 5.6.1 (-V output 
>>at the bottom)
>>
>>Anyone have any thoughts?
>
>
>Please follow the instructions in the SUPPORT file in the modperl 
>source distro to report a segfault. thanks.

Did that. THAT's the output I get, nothing more. Make test, and the 
test server all check out 100% and run fine, its only when I put it 
in production that it takes a dump, and leaves absolutely nothing 
except what you see there.

Lots of the "segfault" stuff in SUPPORT has to do with "when it 
segfaults on a request". It's hard to "attach to the running process" 
or "send the request that causes the segfault" when you can't get 
that far. ;)

D

-- 
+-+-+
| [EMAIL PROTECTED]  | "Thou art the ruins of the noblest man  |
|  Derek J. Balling   |  That ever lived in the tide of times.  |
| |  Woe to the hand that shed this costly  |
| |  blood" - Julius Caesar Act 3, Scene 1  |
+-+-+

Re: segfault on start....

2001-10-02 Thread Stas Bekman


Derek Balling wrote:

> I seem to have something boned... I can't even run an apachectl 
> configtest without segfaulting.
> 
> # ../bin/apachectl start
> ../bin/apachectl: line 171: 16563 Segmentation fault  $HTTPD
> ../bin/apachectl start: httpd could not be started
> 
> Removing the Apache::Registry call from my httpd.conf makes the problem 
> go away immediately.
> 
> This is on apache 1.3.20, mod_perl 1.26, and perl 5.6.1 (-V output at 
> the bottom)
> 
> Anyone have any thoughts?


Please follow the instructions in the SUPPORT file in the modperl source distro to 
report a segfault. thanks.



_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Re: segfault

2001-09-08 Thread Bob Mroczka


Thanks for your suggestion.  I followed the doc
at the link you specified and got it working.

Bob

Stas Bekman wrote:
> 
> On Fri, 7 Sep 2001, Bob Mroczka wrote:
> 
> > I just compiled and installed
> > Apache 1.3.20 with mod_perl 1.26
> > and mod_ssl-2.8.4.  Apache
> > segfaults almost immediately on all requests.
> >
> > For kicks I compiled Apache
> > without mod_ssl and the segfaults disappear.
> > Also interesting is the fact that when
> > I compile without mod_ssl make test
> > completes successfully but when I include
> > mod_ssl the make test fails to start a httpd process
> > due to a syntax error:
> > letting apache warm up...\c
> > Syntax error on line 3 of /usr/src/mod_perl-1.26/t/conf/httpd.conf:
> > Invalid command '=pod', perhaps mis-spelled or defined by a module not
> > included in the server configuration
> > done
> > /usr/bin/perl t/TEST 0
> > still waiting for server to warm up...not ok
> 
> you have used PREP_HTTPD, of course make test won't work.
> You want to follow this scenario while installing mod_ssl+mod_perl
> http://perl.apache.org/guide/install.html#mod_perl_and_mod_ssl_openssl_
> and you will be all set.
> 
> > When I run apache under -X and strace here is what
> > happens when the request comes in:
> > 26480 read(5, "GET / HTTP/1.0\r\nConnection: Keep"..., 4096) = 277
> > 26480 rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
> > 26480 time(NULL)= 17985
> > 26480 alarm(300)= 300
> > 26480 alarm(0)  = 300
> > 26480 stat64(0x8170710, 0xb17c) = 0
> > 26480 --- SIGSEGV (Segmentation fault) ---
> > 26480 +++ killed by SIGSEGV +++
> >
> > Does anyone have any suggestions?
> 
> You have kindly provided everything but the core trace. See the SUPPORT
> file to learn how to do that, but first try to build using the details
> from above.
> 
> _
> Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
> http://stason.org/   mod_perl Guide  http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED]   http://apachetoday.com http://eXtropia.com/
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Re: segfault

2001-09-07 Thread Stas Bekman


On Fri, 7 Sep 2001, Bob Mroczka wrote:

> I just compiled and installed
> Apache 1.3.20 with mod_perl 1.26
> and mod_ssl-2.8.4.  Apache
> segfaults almost immediately on all requests.
>
> For kicks I compiled Apache
> without mod_ssl and the segfaults disappear.
> Also interesting is the fact that when
> I compile without mod_ssl make test
> completes successfully but when I include
> mod_ssl the make test fails to start a httpd process
> due to a syntax error:
> letting apache warm up...\c
> Syntax error on line 3 of /usr/src/mod_perl-1.26/t/conf/httpd.conf:
> Invalid command '=pod', perhaps mis-spelled or defined by a module not
> included in the server configuration
> done
> /usr/bin/perl t/TEST 0
> still waiting for server to warm up...not ok

you have used PREP_HTTPD, of course make test won't work.
You want to follow this scenario while installing mod_ssl+mod_perl
http://perl.apache.org/guide/install.html#mod_perl_and_mod_ssl_openssl_
and you will be all set.

> When I run apache under -X and strace here is what
> happens when the request comes in:
> 26480 read(5, "GET / HTTP/1.0\r\nConnection: Keep"..., 4096) = 277
> 26480 rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
> 26480 time(NULL)= 17985
> 26480 alarm(300)= 300
> 26480 alarm(0)  = 300
> 26480 stat64(0x8170710, 0xb17c) = 0
> 26480 --- SIGSEGV (Segmentation fault) ---
> 26480 +++ killed by SIGSEGV +++
>
> Does anyone have any suggestions?

You have kindly provided everything but the core trace. See the SUPPORT
file to learn how to do that, but first try to build using the details
from above.


_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Re: segfault with mod_perl, Oraperl, XML::Parser

2001-08-03 Thread Matt Sergeant


On 03 Aug 2001 10:26:37 -0700, Scott Kister wrote:
> Thanks everyone for their help, I tried all the suggestions with no
> luck, and I definitely configured Apache without expat. I finally
> ended up parsing the XML in perl instead of using Expat. Since I
> already had handlers, it was quite easy, although still needs better
> validation and error handling.

Try XML::LibXML.

--


/||** Founder and CTO  **  **   http://axkit.com/ **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** mod_perl news and resources: http://take23.org  **
 \\//
 //\\
//  \\

Re: segfault with mod_perl, Oraperl, XML::Parser

2001-08-03 Thread Scott Kister


Thanks everyone for their help, I tried all the suggestions with no
luck, and I definitely configured Apache without expat. I finally
ended up parsing the XML in perl instead of using Expat. Since I
already had handlers, it was quite easy, although still needs better
validation and error handling.

When I get a chance I'll see if this works on mod_perl 2.0. If anyone
does get this to work on Solaris 2.8 x86, please let me know.

Thanks, Scott

#!./perl
use DBD::Oracle;
use XML::Parser::Expat;
my $parser = new XML::Parser::Expat;
$parser->parse(' here we go ');

# perl-5.6.1
# mod_perl-1.26
# apache 1.3.20
# expat-1.95.1
# DBD-Oracle-1.06
# DBI-1.15
# XML-Parser-2.30

# config_args='-Dcc=gcc -Ubincompat5005 -Uuselargefiles -Uusemymalloc -des'

On Tue, July 31 16:37 +0100, Tim Bunce wrote:
> On Mon, Jul 30, 2001 at 03:30:48PM -0400, Philip Mak wrote:
> > On Mon, 30 Jul 2001, Scott Kister wrote:
> > 
> > > uselargefiles=define
> > 
> > Have you tried turning off "uselargefiles"?
> > 
> > I might be off track here, but recently I tried to install mod_perl on
> > Solaris 5.8. It kept segfaulting until I turned off "uselargefiles" and
> > binary compatibility with 5.00503. You could try recompiling perl with
> > this configure line, then recompiling mod_perl and see what happens:
> > 
> > sh Configure -des -Dcc=gcc -Ubincompat5005 -Uuselargefiles
> 
> And   -Uusemymalloc
> 
> (or something like that) to get perl to use the system's own malloc.
> 
> Tim.

Re: segfault with mod_perl, Oraperl, XML::Parser

2001-08-01 Thread Tim Bunce


On Mon, Jul 30, 2001 at 03:30:48PM -0400, Philip Mak wrote:
> On Mon, 30 Jul 2001, Scott Kister wrote:
> 
> > uselargefiles=define
> 
> Have you tried turning off "uselargefiles"?
> 
> I might be off track here, but recently I tried to install mod_perl on
> Solaris 5.8. It kept segfaulting until I turned off "uselargefiles" and
> binary compatibility with 5.00503. You could try recompiling perl with
> this configure line, then recompiling mod_perl and see what happens:
> 
> sh Configure -des -Dcc=gcc -Ubincompat5005 -Uuselargefiles

And -Uusemymalloc

(or something like that) to get perl to use the system's own malloc.

Tim.

Re: segfault w/ Apache 1.3.20, mod_perl 1.26

2001-08-01 Thread Doug MacEachern


On Sun, 22 Jul 2001, Richard L. Goerwitz III wrote:

> I apologize if this problem has already been identified and solved.
> After upgrading from mod_perl 1.25 to mod_perl 1.26 I fired up an
> Apache server instance that uses a config file with an extensive
> set of  sections.  I'm using the Perl that came with
> my Linux (RedHat 7.0) machine, namely 5.6.0.

i can't reproduce with 5.6.1.  can you post a  section the produces
the segv?

Re: segfault with mod_perl, Oraperl, XML::Parser

2001-07-30 Thread Philip Mak


On Mon, 30 Jul 2001, Scott Kister wrote:

> uselargefiles=define

Have you tried turning off "uselargefiles"?

I might be off track here, but recently I tried to install mod_perl on
Solaris 5.8. It kept segfaulting until I turned off "uselargefiles" and
binary compatibility with 5.00503. You could try recompiling perl with
this configure line, then recompiling mod_perl and see what happens:

sh Configure -des -Dcc=gcc -Ubincompat5005 -Uuselargefiles

Re: segfault with mod_perl, Oraperl, XML::Parser

2001-07-30 Thread Scott Kister


I've been looking into this some more without much progress. Is anyone
on this list successfully using modperl, DBD::Oracle, and XML::Parser
on Solaris 2.8 x86?

Are there any known symbol conflicts with Oracle's libclntsh.so and
Expat? Any good alternative perl XML Parsers to Expat?

Thanks, Scott

On Sun, July 22 13:30 -0700, Scott Kister wrote:
> 
> This program core dumps when run under mod_perl on Solaris 2.8 x86.
> 
> #!./perl
> use Oraperl;  # use DBD::Oracle; fails as well
> use XML::Parser;
> my $parser = new XML::Parser;
> $parser->parsestring(''); # fails with valid xml here as well
> 
> It runs fine on Linux and Sparc Solaris. It also works fine from the
> command line, or if I remove the use Oraperl line. I'm using the
> following releases. I had the same problem under apache 1.3.19 and
> mod_perl-1.25, and with perl compiled with and without usemymalloc.
> I also tried Apache with mod_perl as a DSO and statically linked.
> 
> apache 1.3.20
> expat-1.95.1
> mod_perl-1.26
> perl-5.6.1
> DBD-Oracle-1.06
> DBI-1.15
> XML-Parser-2.30
> 
> I searched the web and found a known problem with symbol conflict with
> apache's expat, but I have --disable-rule=EXPAT. I also saw a
> recommendation to use XML-Parser-2.29, which I tried with no success.
> Has anyone here seen this problem or have ideas on how to solve it?
> 
> The gdb backtrace:
> (gdb) bt
> #0  0xdefd3f98 in ?? ()
> #1  0xdfbd7da9 in ?? ()
> #2  0xdfbdeee2 in ?? ()
> #3  0xdfbd31a9 in ?? ()
> #4  0xdf78c6d1 in Perl_pp_entersub ()
>from /server/local/apache/libexec/libperl.so
> #5  0xdf786f92 in Perl_runops_standard ()
>from /server/local/apache/libexec/libperl.so
> #6  0xdf7484d6 in S_call_body () from /server/local/apache/libexec/libperl.so
> #7  0xdf74829a in Perl_call_sv () from /server/local/apache/libexec/libperl.so
> #8  0xdf729676 in perl_call_handler ()
>from /server/local/apache/libexec/libperl.so
> #9  0xdf728ef4 in perl_run_stacked_handlers ()
>from /server/local/apache/libexec/libperl.so
> #10 0xdf727734 in perl_handler () from /server/local/apache/libexec/libperl.so
> #11 0x80739a5 in ap_invoke_handler ()
> #12 0x8088398 in process_request_internal ()
> #13 0x8088402 in ap_process_request ()
> #14 0x807f2db in child_main ()
> #15 0x807f564 in make_child ()
> #16 0x807f8ec in perform_idle_server_maintenance ()
> #17 0x807fe21 in standalone_main ()
> #18 0x8080460 in main ()
> #19 0x8056adf in _start ()
> 
> I turned on the nontstop debugging. The output from where it seg faults
> is as follows.
> 
> entering XML::Parser::Expat::parse
>  438:   my $self = shift;
>  439:   my $arg = shift;
>  440:   croak "Parse already in progress (Expat)" if $self->{_State_};
>  441:   $self->{_State_} = 1;
>  442:   my $parser = $self->{Parser};
>  443:   my $ioref;
>  444:   my $result = 0;
>  446:   if (defined $arg) {
>  447: if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handle')) {
>  455:   eval {
>  456: $ioref = *{$arg}{IO};
>  456: $ioref = *{$arg}{IO};
> -- end of output, seg fault here
> 
> XML/Parser.pm
> 455  sub Char {
> 456my $expat = shift;
> 457my $text = shift;
> 458my $class = "${$expat}{Pkg}::Characters";
> 459my $clist = $expat->{Curlist};
> 
> 
> perl configure options:
>  -Dprefix=/server/local -Uusemymalloc -Ubincompat5005 -des
> 
> % perl -V
> Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
>   Platform:
> osname=solaris, osvers=2.8, archname=i86pc-solaris
> uname='sunos x86-b 5.8 generic_108529-06 i86pc i386 i86pc '
> config_args='-Dprefix=/server/local -Uinstallusrbinperl -Ubincompat5005 -des'
> hint=recommended, useposix=true, d_sigaction=define
> usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
> useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
> use64bitint=undef use64bitall=undef uselongdouble=undef
>   Compiler:
> cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE 
>-D_FILE_OFFSET_BITS=64',
> optimize='-O',
> cppflags='-fno-strict-aliasing -I/usr/local/include'
> ccversion='', gccversion='2.95.2 19991024 (release)', gccosandvers='solaris2.8'
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
> ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
> alignbytes=4, usemymalloc=y, prototype=define
>   Linker and Libraries:
> ld='cc', ldflags =' -L/usr/local/lib '
> libpth=/usr/local/lib /usr/lib /usr/ccs/lib
> libs=-lsocket -lnsl -ldl -lm -lc
> perllibs=-lsocket -lnsl -ldl -lm -lc
> libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
>   Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
> cccdlflags='-fPIC', lddlflags='-G -L/usr

Re: segfault w/ Apache 1.3.20, mod_perl 1.26

2001-07-22 Thread Richard L. Goerwitz III


Ged Haywood wrote:

> IIRC there was a problem with the compiler (gcc) that came with RH7.0,
> which compiler are you using?

I'm using the patched version of GCC that RedHat later released,
gcc-2.96-85.

Dunno if it's relevant, but I see the following ChangeLog entry that
might or might not be relevant to this problem (for mod_perl 1.25_01
- July 6, 2001):

  adjust perl_clear_symtab() to deal properly bleedperl's version of
  cv_undef() (which broke modules with directive handlers)
  thanks to Geoffrey Young for the spot

On perl_clear_symtab() see below.

Note that I tried both mod_perl 1.26 and 1.26_01, and both behave
similarly.  I.e., both coredump after handling all the commands in
my  section.  The coredump happens inside Perl_sv_free:

  #0  0x81fe1d2 in Perl_sv_free ()
  #1  0x81d5e84 in Perl_cv_undef ()
  #2  0x80acba9 in perl_clear_symtab ()

The message in my error_log file is:

  Attempt to free unreferenced scalar.

> Send us the output of "perl -V" and also the arguments you gave to
> Makefile.PL, then when they all get back from the conference maybe
> someone will have your answer.

Ok, first the Makefile.PL args.  I tried this various ways (e.g., with
and without PERL_DEBUG; also, with just PERL_TRACE):

SSL_BASE='/usr' perl Makefile.PL APACHE_SRC=/usr/local/src/apache/src
USE_APACI=1 EVERYTHING=1 PERL_DEBUG=1 ADD_MODULE=all DO_HTTPD=1
APACI_ARGS='--enable-module=all' 

Here's my perl -V output:

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
osname=linux, osvers=2.2.17-8smp, archname=i386-linux
uname='linux porky.devel.redhat.com 2.2.17-8smp #1 smp fri nov 17
16:12:17 est 2000 i686 unknown '
config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc
-Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr
-Darchname=i386-linux -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm
-Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Uuselargefiles'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=undef 
use64bitint=undef use64bitall=undef uselongdouble=undef
usesocks=undef
  Compiler:
cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96
2731 (Red Hat Linux 7.1 2.96-78)
cppflags='-fno-strict-aliasing'
ccflags ='-fno-strict-aliasing'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -ldl -lm -lc -lcrypt
libc=/lib/libc-2.2.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl): 
  Compile-time options:
  Built under linux
  Compiled at Apr  3 2001 11:27:33
  @INC:
/usr/lib/perl5/5.6.0/i386-linux
/usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i386-linux
/usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl
.

> Does this happen with a static build?

Yes, indeed it does.

-- 

Richard Goerwitz   [EMAIL PROTECTED]
tel: 401 438 8978

Re: segfault w/ Apache 1.3.20, mod_perl 1.26

2001-07-22 Thread Ged Haywood

Hi there,

On Sun, 22 Jul 2001, Richard L. Goerwitz III wrote:

> After upgrading from mod_perl 1.25 to mod_perl 1.26 I fired up an
> Apache server instance that uses a config file with an extensive
> set of  sections.  I'm using the Perl that came with
> my Linux (RedHat 7.0) machine, namely 5.6.0.

IIRC there was a problem with the compiler (gcc) that came with RH7.0,
which compiler are you using?

Send us the output of "perl -V" and also the arguments you gave to
Makefile.PL, then when they all get back from the conference maybe
someone will have your answer.

Does this happen with a static build?

(Ducks for cover before Doug reads this... :)

73,
Ged.

PS: Please don't change your subject line, it messes up the thread.

Re: Segfault on ppc-linux with modperl-1.25 with Apache 1.3.19 whencalling $r->send_fd()

2001-06-13 Thread Doug MacEachern


On 19 Mar 2001, Mark Lipscombe wrote:


>   open ($FH, $fname);
...
>   $r->send_fd($FH);

you didn't check the return value of open();  patch below will check if
the filehandle is NULL and croak rather than segfault.

Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.122
diff -u -r1.122 Apache.xs
--- src/modules/perl/Apache.xs  2001/06/14 04:36:21 1.122
+++ src/modules/perl/Apache.xs  2001/06/14 05:24:25
@@ -956,6 +956,10 @@
 long length
 
 CODE:
+if (!f) {
+croak("send_fd: NULL filehandle "
+  "(hint: did you check the return value of open?)");
+}
 RETVAL = send_fd_length(f, r, length);
 
 OUTPUT:

Re: segfault on subrequest?

2001-06-13 Thread Doug MacEachern


On Thu, 15 Mar 2001, Pierre Phaneuf wrote:

> 
> I have a PerlTransHandler that is very simple:

the problem is likely that your trans handler is recursing.  try adding
this to prevent recursion:
 
> sub handler {
>   my($r) = @_;

return unless $r->is_main;

>   my($info);
> 
>   $info = $r->lookup_file('/home/pp/pierre.jpg')->content_type();
> 
>   warn("content type is $info\n");
> 
>   return DECLINED;
> }
> 
> But it causes a segfault when invoked... I removed the
> "->content_type()", so that I should normally see something like
> "Apache::SubRequest=SCALAR(0x815eb54)", but it also crashes.
> 
> I tried using the exact same handler as a PerlHandler and as a
> PerlHeaderParserHandler instead, and it works perfectly. I was thinking
> that calling lookup_uri from within a PerlTransHandler might be a bad
> idea (infinite loops!), but I would have thought that lookup_file would
> be ok...
> 
> Okay, maybe everyone will jump in my face about this: this is on an
> updated Red Hat 7.0 system, using Red Hat's Apache and mod_perl RPM
> packages.
> 
>

Re: Segfault: apache-1.3.17+modperl-1.25

2001-02-15 Thread dima



Hmm,
 have you built mod_perl with PERL_USELARGEFILES=0?

 I've got almost the same set up (RH7) running just fine.

On Wed, 14 Feb 2001, Gary Algier wrote:

> My children are segfaulting.
>
> I have:
>   Solaris 2.6 (w/all latest patches installed right after the OS)
>   Perl 5.6.0 (no largefiles, no threads)
>   Apache 1.3.17
>   modperl 1.25 (as a DSO)
>   gcc 2.95.2 (using Sun's as and ld)
>
> If I run apache leaving out:
>   LoadModule perl_modulelibexec/libperl.so
>   AddModule mod_perl.c
> it runs just fine.  Put them in and the child seg faults.   I did manage
> to gdb the process and it says:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xef0a2e00 in perl_header_parser ()
> (gdb) where
> #0  0xef0a2e00 in perl_header_parser ()
> #1  0x20714 in run_method ()
> #2  0x208e4 in ap_header_parse ()
> #3  0x3d9bc in process_request_internal ()
> #4  0x3ded0 in ap_process_request ()
> #5  0x314c8 in child_main ()
> #6  0x31854 in make_child ()
> #7  0x31dcc in perform_idle_server_maintenance ()
> #8  0x32630 in standalone_main ()
> #9  0x32f64 in main ()
>
> Unfortunately, there are no debugging symbols so it is limited.  It wasn't
> easy getting this, though if it would help I will endeavor to rebuild
> everything with debugging symbols and try again.
>
> In general, I know that DSOs are working as I runtime load the max.  I also
> load php 4.0.4pl1 that way and it works.
>
> Any ideas?  Does the trace help?
>
>
>
> --
> Gary Algier, WB2FWZ   [EMAIL PROTECTED]   +1 856 787 2758
> Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054  Fax:+1 856 866 2033
>
>A self-addressed envelope would be addressed "envelope."
>

Re: Segfault: apache-1.3.17+modperl-1.25

2001-02-14 Thread Vasily Petrushin


On Wed, 14 Feb 2001, Gary Algier wrote:

> My children are segfaulting.
> 
> I have:
>   Solaris 2.6 (w/all latest patches installed right after the OS)
>   Perl 5.6.0 (no largefiles, no threads)
>   Apache 1.3.17
>   modperl 1.25 (as a DSO)
>   gcc 2.95.2 (using Sun's as and ld

I had same problems. Try to compile mod_perl statically.
Works fine.

> 
> If I run apache leaving out:
>   LoadModule perl_modulelibexec/libperl.so
>   AddModule mod_perl.c
> it runs just fine.  Put them in and the child seg faults.   I did manage
> to gdb the process and it says:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xef0a2e00 in perl_header_parser ()
> (gdb) where
> #0  0xef0a2e00 in perl_header_parser ()
> #1  0x20714 in run_method ()
> #2  0x208e4 in ap_header_parse ()
> #3  0x3d9bc in process_request_internal ()
> #4  0x3ded0 in ap_process_request ()
> #5  0x314c8 in child_main ()
> #6  0x31854 in make_child ()
> #7  0x31dcc in perform_idle_server_maintenance ()
> #8  0x32630 in standalone_main ()
> #9  0x32f64 in main ()
> 
> Unfortunately, there are no debugging symbols so it is limited.  It wasn't
> easy getting this, though if it would help I will endeavor to rebuild
> everything with debugging symbols and try again.
> 
> In general, I know that DSOs are working as I runtime load the max.  I also
> load php 4.0.4pl1 that way and it works.
> 
> Any ideas?  Does the trace help?
> 
> 
> 
> -- 
> Gary Algier, WB2FWZ   [EMAIL PROTECTED]   +1 856 787 2758
> Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054  Fax:+1 856 866 2033
> 
>A self-addressed envelope would be addressed "envelope."
> 

Vasily Petrushin
+7 (095) 2508363
http://www.interfax.ru
mailto:[EMAIL PROTECTED]

Re: Segfault: apache-1.3.17+modperl-1.25

2001-02-14 Thread ___cliff rayman___


did u compile the perl, apache and mod_perl all with the
same compiler, assembler and linker??  you may want to search
in the archives:
solaris dso sigsegv

i remember quite a few issues a while back.

hth,

--
___cliff [EMAIL PROTECTED]http://www.genwax.com/

Gary Algier wrote:

> My children are segfaulting.
>
> I have:
> Solaris 2.6 (w/all latest patches installed right after the OS)
> Perl 5.6.0 (no largefiles, no threads)
> Apache 1.3.17
> modperl 1.25 (as a DSO)
> gcc 2.95.2 (using Sun's as and ld)
>
> If I run apache leaving out:
> LoadModule perl_modulelibexec/libperl.so
> AddModule mod_perl.c
> it runs just fine.  Put them in and the child seg faults.   I did manage
> to gdb the process and it says:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xef0a2e00 in perl_header_parser ()
> (gdb) where
> #0  0xef0a2e00 in perl_header_parser ()
> #1  0x20714 in run_method ()
> #2  0x208e4 in ap_header_parse ()
> #3  0x3d9bc in process_request_internal ()
> #4  0x3ded0 in ap_process_request ()
> #5  0x314c8 in child_main ()
> #6  0x31854 in make_child ()
> #7  0x31dcc in perform_idle_server_maintenance ()
> #8  0x32630 in standalone_main ()
> #9  0x32f64 in main ()
>
> Unfortunately, there are no debugging symbols so it is limited.  It wasn't
> easy getting this, though if it would help I will endeavor to rebuild
> everything with debugging symbols and try again.
>
> In general, I know that DSOs are working as I runtime load the max.  I also
> load php 4.0.4pl1 that way and it works.
>
> Any ideas?  Does the trace help?
>

Re: Segfault in perl_handler_ismethod

2000-08-15 Thread Doug MacEachern


On Mon, 26 Jun 2000, Rich Williams wrote:

> 
> Hi,
> 
> Linux 2.2.14, Apache 1.3.12, Perl 5.6.0, mod_perl 1.24.
> 
> On the first request, I get a segfault after perl_handler_ismethod
> is called.
> 
> #0  0x40280fdc in mod_perl_register_cleanup (r=0x92ba3fc, sv=0x1) at mod_perl.c:1242
> #1  0x40280fb0 in perl_handler_ismethod (pclass=0x92ba3fc, sub=0x1 of bounds>) at mod_perl.c:1236

this is a strange looking stacktrace, but this might be fixed in cvs with
this change:
fix for 'sub handler : method {}' support when method is not found
[Eric Cholet <[EMAIL PROTECTED]>]

Re: Segfault Apache1.3.12/mod_perl1.24/Solaris2.6

2000-08-15 Thread Doug MacEachern


On Mon, 19 Jun 2000, G.W. Haywood wrote:

> Hi Eric,
> 
> > > [Fri Jun 16 17:20:21 2000] [notice] \
> > > child pid 22310 exit signal Segmentation Fault (11)
> 
> On Mon, 19 Jun 2000, Eric Cholet wrote:
> 
> > backtrace.
> 
> (gdb) bt
> #0  0x2b444 in perl_handler_ismethod ()
> #1  0x2c43c in perl_call_handler ()
> #2  0x2bd5c in perl_run_stacked_handlers ()
> #3  0x29920 in perl_handler ()
> #4  0x7fce8 in ap_invoke_handler ()
> #5  0x9bdfc in ap_some_auth_required ()
> #6  0x9be7c in ap_process_request ()
> #7  0x8fbac in ap_child_terminate ()
> #8  0x8fe14 in ap_child_terminate ()
> #9  0x90014 in ap_child_terminate ()
> #10 0x908f4 in ap_child_terminate ()
> #11 0x914a0 in main ()
> 
> Curiously enough, Apache::Registry seems to run ok with a simple
> "Hello world" type of script.  Stay tuned.

if you haven't tried already, this bug has been fixed in cvs for quite a
while:
fix for 'sub handler : method {}' support when method is not found
[Eric Cholet <[EMAIL PROTECTED]>]

Re: segfault from Apache::Cookie and Apache::SSI

2000-08-10 Thread Perrin Harkins


On Fri, 11 Aug 2000, G.W. Haywood wrote:
> What compiler(s)?

gcc -v says:
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

Re: segfault from Apache::Cookie and Apache::SSI

2000-08-10 Thread G.W. Haywood


Hi again Perrin,

On Thu, 10 Aug 2000, Perrin Harkins wrote:

> I'm using Red Hat's Perl RPM, but Apache/mod_perl is compiled
> from source.

What compiler(s)?

73,
Ged.

Re: segfault from Apache::Cookie and Apache::SSI

2000-08-10 Thread Perrin Harkins


On Fri, 11 Aug 2000, G.W. Haywood wrote:
> DSO or static?

Static.  I'm using Red Hat's Perl RPM, but Apache/mod_perl is compiled
from source.

- Perrin

Re: segfault from Apache::Cookie and Apache::SSI

2000-08-10 Thread G.W. Haywood


Hi Perrin,

On Thu, 10 Aug 2000, Perrin Harkins wrote:

> I'm getting repeatable segfaults (every time) by feeding a simple
> file to Apache::SSI.

DSO or static?

73,
Ged.

RE: segfault on DBI->connect (was Re: Apache segfault)

2000-07-18 Thread Trond Arve Nordheim

That was not the problem.
I've tried that on all 3 servers, without results...

- dufuz

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 18. juli 2000 14:27
To: Trond Arve Nordheim
Cc: [EMAIL PROTECTED]
Subject: segfault on DBI->connect (was Re: Apache segfault)

Compile PHP using --with-mysql=/usr (or whatever turns out to be the
appropriate way of telling PHP not to use its own internal mysql
library on your platform).

-- 
Richard Goerwitz[EMAIL PROTECTED]

Re: Segfault Apache1.3.12/mod_perl1.24/Solaris2.6

2000-06-19 Thread G.W. Haywood


Hi Eric,

> > [Fri Jun 16 17:20:21 2000] [notice] \
> > child pid 22310 exit signal Segmentation Fault (11)

On Mon, 19 Jun 2000, Eric Cholet wrote:

> backtrace.

(gdb) bt
#0  0x2b444 in perl_handler_ismethod ()
#1  0x2c43c in perl_call_handler ()
#2  0x2bd5c in perl_run_stacked_handlers ()
#3  0x29920 in perl_handler ()
#4  0x7fce8 in ap_invoke_handler ()
#5  0x9bdfc in ap_some_auth_required ()
#6  0x9be7c in ap_process_request ()
#7  0x8fbac in ap_child_terminate ()
#8  0x8fe14 in ap_child_terminate ()
#9  0x90014 in ap_child_terminate ()
#10 0x908f4 in ap_child_terminate ()
#11 0x914a0 in main ()

Curiously enough, Apache::Registry seems to run ok with a simple
"Hello world" type of script.  Stay tuned.

73,
Ged.

Re: Segfault Apache1.3.12/mod_perl1.24/Solaris2.6

2000-06-19 Thread Eric Cholet


> Hi all, 
> 
> Sorry, this is a bit long.
[snip] 
> [Fri Jun 16 17:20:21 2000] [notice] \
> child pid 22310 exit signal Segmentation Fault (11)
[snip] 
> There is no core dump and the same thing happens with the -X switch.

please see the instructions in SUPPORT on how to provide a backtrace.

--
Eric

Re: Segfault in second time through sub request...

2000-06-02 Thread Matt Sergeant

Replying to my own post... I found the problem - I was caching a
subrequest in the child's memory and trying to call lookup_* again with
that cached request. Doesn't work for fairly obvious reasons.

On Fri, 2 Jun 2000, Matt Sergeant wrote:

> Running under httpd -X, first time through my subrequest goes fine, second
> time through it segfaults. Here's the non-debugging bt:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x8080757 in ap_copy_table ()
> (gdb) bt
> #0  0x8080757 in ap_copy_table ()
> #1  0x80937ef in ap_set_sub_req_protocol ()
> #2  0x8098156 in ap_sub_req_lookup_file ()
> #3  0x2af188 in XS_Apache_lookup_file ()
>from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/Apache.so
> #4  0x5f6b6f6f in ?? ()
> Cannot access memory at address 0x62636f64
> 
> Probably not a huge amount of help, and it smacks of a bug in Apache,
> rather than mod_perl. Still a PITA for me ;-)
> 
> Config: Apache 1.3.12, Perl 5.00503, mod_perl 1.24. Non-DSO.
> 
> 

-- 

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

Re: segfault: perl 5.6.0, apache 1.3.12, mod_perl 1.24 and XML::Parser

2000-05-22 Thread Doug MacEachern

On Sat, 20 May 2000, Matthew Darwin wrote:

> 
> My apache dies about 30% of the time when handling any mod_perl request
> that requires XML::Parser.  Any other page (even pages that use
> mod_perl) are 100% ok.
> 
> Are there any known issues with this (besides the requirement for
> --disable-rule=expat)?  This all worked fine with perl 5.005_03 +
> mod_perl 1.23.   I'll get more info if nobody has seen this before.

double check that Apache is being built with the CFLAGS you set for
large file support.  other than that, you'll need to get a stacktrace (see
SUPPORT doc)

Re: Segfault on DBI->connect

2000-05-17 Thread Richard L. Goerwitz


Many of us have been experiencing segfaults on DBI->connect when using the
DBD-mysql
drivers.

I wonder if anyone has found a solution.

I've appended a pretty comprehensive overview of the problem below.

Problem description:  Child Apache process segfaults on DBI->connect with
Apache
1.3.12 and Msql-Mysql-modules-1.22{11,12,13,14} (maybe other versions,
too).  This
happens with mod_perl versions 1.22 through 1.24.  I happen to be running
RedHat
6.1 with egcs-2.91.66, but I've built everything (from Perl to Apache) from
scratch.

Anyway, the point of failure has been found: the MySQL mysql_real_connect()
routine called by Msql-Mysql-modules-1.22{11-14} gets passed a NULL first
arg.
So far nobody has figured out what is going on here, and why this problem
has only now started to crop up.  It seemed to appear when I upgraded
mod_perl
to 1.22 and Apache to 1.3.12.

Here's one of my low-level traces.  Farther below I offer a DBI->trace(9)
trace,
which shows what's going on from Perl/DBI/DBD's point of view.

> Running Apache with a -X argument yields the following backtrace when my
> mod_perl module does a DBI->connect (str, username, passwd, { options }).
> Note the null mysql argument 
> |
> v
> #0  0x80ef5b7 in mysql_real_connect (mysql=0x0,
> host=0x8a99db8 "catlin.cis.brown.edu", user=0x8a9b550 "proxystuff",
> passwd=0x8a9b568 "Kui0-,12!", db=0x8a99e40 "proxysession", port=3306,
> unix_socket=0x0, client_flag=0) at libmysql.c:1125
> #1  0x402d01fd in mysql_dr_connect ()
>  from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> #2  0x402d0540 in _MyLogin ()
>  from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so

I really don't know how the null first argument is getting passed to
mysql_real_connect.

Here's a DBI->trace (9) of what's going on.  I confess that I don't
understand
most of this output (which comes from my Apache error log file):

>  DBI 1.13-nothread dispatch trace level set to 9
>   -> 
>DBI->Apache::DBI::connect(dbi:mysql:database=proxysession;host=catlin.cis.brown.edu;port=3306,
> proxystuff, Kui0-,12!)
>   -> DBI->install_driver(mysql) for perl=5.00503 pid=14122 ruid=99 euid=99
>  install_driver: DBD::mysql loaded (version 2.0414)
>   New DBI::dr (for DBD::mysql::dr, parent=, id=)
>   dbih_setup_handle(DBI::dr=HASH(0x858a0e8)=>DBI::dr=HASH(0x8930414), 
>DBD::mysql::dr, 0, Null!)
>   dbih_make_com(Null!, DBD::mysql::dr, 84)
>   dbih_setup_attrib(DBI::dr=HASH(0x8930414), Err, Null!) SCALAR(0x89259cc) (already 
>defined)
>   dbih_setup_attrib(DBI::dr=HASH(0x8930414), State, Null!) SCALAR(0x858a3ac) 
>(already defined)
>   dbih_setup_attrib(DBI::dr=HASH(0x8930414), Errstr, Null!) SCALAR(0x89259e4) 
>(already defined)
>   dbih_setup_attrib(DBI::dr=HASH(0x8930414), Handlers, Null!) ARRAY(0x89304c8) 
>(already defined)
>   dbih_setup_attrib(DBI::dr=HASH(0x8930414), Debug, Null!) 0 (already defined)<- 
>install_driver= DBI::dr=HASH(0x858a0e8)
>   >> FETCH DISPATCH (DBI::dr=HASH(0x8930414) rc2/1 @2 g0 a866b270) at 
>/usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 64.
>   <- FETCH= 'mysql' ('Name' from cache) at 
>/usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 64.
>   >> connect DISPATCH (DBI::dr=HASH(0x858a0e8) rc1/5 @5 g0 a866b288) at 
>/usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 120.
>   -> connect for DBD::mysql::dr (DBI::dr=HASH(0x858a0e8)~0x8930414 
>'database=proxysession;host=catlin.cis.brown.edu;port=3306' 'proxystuff' 'pKui0-,12!' 
>HASH(0x892441c))
>   New DBI::db (for DBD::mysql::db, parent=DBI::dr=HASH(0x8930414), 
>id=HASH(0x8930450))
>   dbih_setup_handle(DBI::db=HASH(0x89304a4)=>DBI::db=HASH(0x893a058), 
>DBD::mysql::db, 8587d60, HASH(0x8930450))
>   dbih_make_com(DBI::dr=HASH(0x8930414), DBD::mysql::db, 520)
>   dbih_setup_attrib(DBI::db=HASH(0x893a058), Err, DBI::dr=HASH(0x8930414)) 
>SCALAR(0x89259cc) (already defined)
>   dbih_setup_attrib(DBI::db=HASH(0x893a058), State, DBI::dr=HASH(0x8930414)) 
>SCALAR(0x858a3ac) (already defined)
>   dbih_setup_attrib(DBI::db=HASH(0x893a058), Errstr, DBI::dr=HASH(0x8930414)) 
>SCALAR(0x89259e4) (already defined)
>   dbih_setup_attrib(DBI::db=HASH(0x893a058), Handlers, DBI::dr=HASH(0x8930414)) 
>ARRAY(0x89304c8) (already defined)
>   dbih_setup_attrib(DBI::db=HASH(0x893a058), Debug, DBI::dr=HASH(0x8930414)) 0 
>(already defined)
>   imp_dbh->connect: dsn = database=proxysession;host=catlin.cis.brown.edu;port=3306, 
>uid = proxystuff, pwd = Kui0-,12!
>   imp_dbh->MyLogin: dbname = proxysession, uid = proxystuff, pwd = Kui0-,12!,host = 
>catlin.cis.brown.edu, port = 3306
>   imp_dbh->MyConnect: host = catlin.cis.brown.edu, port = 3306, uid = proxystuff, 
>pwd = Kui0-,12!
>   imp_dbh->MyConnect: client_flags = 0
> [Wed May 17 11:17:29 2000] [notice] child pid 14122 exit signal Segmentation fault 
>(11)

-- 
Richard Goerwitz[EMAIL PROTECTED]

Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12

2000-05-10 Thread Alan Burlison

Michael Poole wrote:

> In hopes that this would fix the APXS build, I tried rebuilding with
> that, but whenever the httpd tried to load the php3 or perl module, it
> would die in pthread_mutex_lock.  This was slightly odd, since php3
> would load fine when httpd was statically linked against mod_perl.
> For the time being, I'll just roll back to using static mod_perl and
> dynamic mod_ssl and php3.

No, that's what you would expect.  The problem is being caused because
perl amd mod_perl are being built to be largefile aware, whereas by
default Apache is not.  By following Doug's instructions to let mod_perl
build httpd you are building it with the same flags needed to make
perl/modperl largefile aware, so Apache too ends up being largefile
aware and all the bits then are in sync.

If you use APXS you are building Apache seperately and with the standard
config, i.e. not largefile aware, so it breaks.  If you want to use APXS
you have to build Apache to be largefile aware yourself.  On Solaris at
least the way to do this is to set CFLAGS='-D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64' in your environment before invoking the Apache
configure.

-- 
Alan Burlison

Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12

2000-04-27 Thread Michael Poole

Doug MacEachern <[EMAIL PROTECTED]> writes:

> can you see if this patch fixes the problem?  make sure you let mod_perl
> build httpd and pass USE_APACI=1 to Makefile.PL
> 
> --- Makefile.PL 2000/04/21 06:24:27 1.158
> +++ Makefile.PL 2000/04/27 22:45:30 1.160
> @@ -186,7 +186,7 @@
>  $PERL_DEBUG = "";
>  $PERL_DESTRUCT_LEVEL = "";
>  $PERL_STATIC_EXTS = "";
> -$PERL_EXTRA_CFLAGS = "";
> +$PERL_EXTRA_CFLAGS = $] >= 5.006 ? $Config{ccflags} : "";
>  $SSLCacheServerPort = 8539;
>  $SSL_BASE = ""; 
>  $Port = $ENV{HTTP_PORT} || 8529;

Yes.  Using the same Makefile.PL invocation that failed before (see my
previous email), this passes "make test."  I haven't tried running it
in my full pseudo-production environment because that also uses mod_ssl,
but the test suite checks out okay.

In hopes that this would fix the APXS build, I tried rebuilding with
that, but whenever the httpd tried to load the php3 or perl module, it
would die in pthread_mutex_lock.  This was slightly odd, since php3
would load fine when httpd was statically linked against mod_perl.
For the time being, I'll just roll back to using static mod_perl and
dynamic mod_ssl and php3.

Michael

Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12

2000-04-27 Thread Michael Poole


Doug MacEachern <[EMAIL PROTECTED]> writes:

> > perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/sbin/apxs EVERYTHING=1
> 
> probably a long shot, but any difference if you build with USE_DSO=1
> instead of USE_APXS ?

My apologies for taking so long to reply -- it's been a busy week.
>From a clean apache_1.3.12 and mod_perl-1.23 tree, running:
  perl Makefile.PL APACHE_SRC=../apache_1.3.12/src DO_HTTPD=1 \
USE_APACI=1 USE_DSO=1 EVERYTHING=1
  make
  make test

results in almost all of the tests failing.  When I try to start the
server manually (using the same parameters as 'make test' gives it),
it gets SIGSEGV while parsing the httpd config files.  A backtrace
from gdb shows:

(gdb) bt
#0  _dl_debug_state () at dl-debug.c:56
#1  0x4000a3eb in _dl_catch_error (errstring=0xbfffc034, 
operate=0x40148d20 , args=0xbfffc038) at dl-error.c:141
#2  0x401490cd in _dl_open (
file=0x866cc20 
"/usr/local/lib/perl5/5.6.0/i686-linux-thread-multi-64all/auto/IO/IO.so", mode=1, 
caller=0xbfffc034) at dl-open.c:232
#3  0x4006a063 in dlopen_doit (a=0xbfffc148) at dlopen.c:41
#4  0x4000a3eb in _dl_catch_error (errstring=0x4006bd00, 
operate=0x4006a038 , args=0xbfffc148) at dl-error.c:141
#5  0x4006a549 in _dlerror_run (operate=0x4006a038 , 
args=0xbfffc148) at dlerror.c:125
#6  0x4006a023 in __dlopen_check (
file=0x866cc20 
"/usr/local/lib/perl5/5.6.0/i686-linux-thread-multi-64all/auto/IO/IO.so", mode=1) at 
dlopen.c:53
#7  0x401b09e9 in XS_DynaLoader_dl_load_file ()
   from 
/usr/local/stow/apache/1.3.12/src/mod_perl-1.23/t/../../apache_1.3.12/src/modules/perl/libperl.so
[... much Perl internals elided ...]
#54 0x40171257 in perl_cmd_require ()
   from 
/usr/local/stow/apache/1.3.12/src/mod_perl-1.23/t/../../apache_1.3.12/src/modules/perl/libperl.so
#55 0x806b67e in invoke_cmd ()
#56 0x806bb01 in ap_handle_command ()
#57 0x806bb9d in ap_srm_command_loop ()
#58 0x806bff4 in ap_process_resource_config ()
#59 0x806c8f8 in ap_read_config ()
#60 0x8076570 in standalone_main ()
#61 0x8076e9c in main ()
#62 0x400841eb in __libc_start_main (main=0x8076b04 , argc=6, 
argv=0xbc54, init=0x804e3cc <_init>, fini=0x8093b64 <_fini>, 
rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbc4c)
at ../sysdeps/generic/libc-start.c:90

and t/logs/error_log contains:

[notice] END block called for startup.pl
[notice] Destruction->DESTROY called for $global_object

(I'm not sure if that's an error or just diagnostics; it looks like
the latter.  If the SEGV is unrelated to it, I could continue hunting
down the error given hints on what to look for.  But not all is lost
-- see my reply to your other email.)

Michael

Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12

2000-04-27 Thread Doug MacEachern


can you see if this patch fixes the problem?  make sure you let mod_perl
build httpd and pass USE_APACI=1 to Makefile.PL

--- Makefile.PL 2000/04/21 06:24:27 1.158
+++ Makefile.PL 2000/04/27 22:45:30 1.160
@@ -186,7 +186,7 @@
 $PERL_DEBUG = "";
 $PERL_DESTRUCT_LEVEL = "";
 $PERL_STATIC_EXTS = "";
-$PERL_EXTRA_CFLAGS = "";
+$PERL_EXTRA_CFLAGS = $] >= 5.006 ? $Config{ccflags} : "";
 $SSLCacheServerPort = 8539;
 $SSL_BASE = ""; 
 $Port = $ENV{HTTP_PORT} || 8529;

Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12

2000-04-25 Thread Doug MacEachern


> perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/sbin/apxs EVERYTHING=1

probably a long shot, but any difference if you build with USE_DSO=1
instead of USE_APXS ?

Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12

2000-04-25 Thread Michael Poole

Doug MacEachern <[EMAIL PROTECTED]> writes:

> On 22 Apr 2000, Michael Poole wrote:
> 
> > I get a segfault on the first page access to Apache (it's just a
> > request for / on the server).  Backtrace:
> ... 
> > That line of mod_perl.c is "dPPDIR;"
> > However, r->per_dir_config is NULL, so the get_module_config() call there
> > ends up dereferencing a NULL pointer to generate the SEGV.
> 
> that's stange.  what options did you give mod_perl's Makefile.PL?
> did mod_perl's 'make test' pass?
> what request is the server handling when this happens?

perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/sbin/apxs EVERYTHING=1

'make test' refused to run since it was using APXS

The server was handling "GET / HTTP/1.0" at the time (the first request
made to the server).

My "solution" to this point (suggested by Dave Mee) is to just use
APACI to link mod_perl statically into Apache.  It's worked perfectly
so far, although it is a bit kludgy.

Michael

Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12

2000-04-25 Thread Doug MacEachern

On 22 Apr 2000, Michael Poole wrote:

> I get a segfault on the first page access to Apache (it's just a
> request for / on the server).  Backtrace:
... 
> That line of mod_perl.c is "dPPDIR;"
> However, r->per_dir_config is NULL, so the get_module_config() call there
> ends up dereferencing a NULL pointer to generate the SEGV.

that's stange.  what options did you give mod_perl's Makefile.PL?
did mod_perl's 'make test' pass?
what request is the server handling when this happens?

Re: Segfault on DBI->Connect

2000-04-20 Thread Doug MacEachern

On Sun, 16 Apr 2000, Jochen Wiedmann wrote:

> Btw, Doug, as I see the sigpipe thing: What do you recommend for the
> DBD::mysql driver? (Remember the "MySQL morning bug"?) Should we
> enable or disable SIGPIPE?

apache no longer catches SIGPIPE as of 1.3.6, so it may not be an issue
anymore if mysql throws/catches SIGPIPE.  but, gut says it's best to
avoid using SIGPIPE if possible, as somebody else might stomp on it.

Re: Segfault on DBI->Connect

2000-04-18 Thread Jochen Wiedmann


Drew Degentesh wrote:

> Below is a backtrace of my segfault received on DBI->Connect (sorry but my
> perl and apache binaries are stripped)... you can see that mysql_close is
> being called with a null argument, rather than mysql_real_connect as
> indicated in some of the other backtraces reported.
> 
> -+-
> Starting program: /usr/local/apache/bin/httpd -X
> 
> Program received signal SIGSEGV, Segmentation fault.
> mysql_close (mysql=0x0) at libmysql.c:1555
> 1555  end_server(mysql);
> #0  mysql_close (mysql=0x0) at libmysql.c:1555
> #1  0x403bf254 in __DTOR_END__ ()
>from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> #2  0x403ac0dd in mysql_dr_connect ()
>from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so

This looks like you are calling mysql_real_connect, something fails
and so mysql_close is called with a NULL argument. Can you deduce
somehow what goes wrong? We might check the MySQL sources then?


Thanks,

Jochen

RE: Segfault on DBI->Connect

2000-04-17 Thread Drew Degentesh


Jochen,

> If you are using the DBD-mysql sources, as distributed by me, the
> mysql_real_connect function will *never* be called with a NULL
> argument. This cannot happen, if mysql_init() is called before
> mysql_real_connect(). (Unless you are using some patches that I have
> recently reached me from the mod_perl mailing list, but that I haven't
> verified yet.) Calling mysql_real_connect with mysql==NULL will surely
> cause a SEGFAULT.
>

I'm using:
Redhat 6.1 (Linux 2.2.12-20RS )
Apache/1.3.12 (from distribution)
mod_perl: 1.22 (compiled from source, running as a DSO through APXS)
mysql  Ver 9.36 Distrib 3.22.27 (from distribution)
perl 5.005_03 (from distribution)
Msql-Mysql-modules-1.2211 (compiled form source, retreived from CPAN)
DBI-1.13 (compiled form source, retreived from CPAN)

None of which are sporting any modifications.



Below is a backtrace of my segfault received on DBI->Connect (sorry but my
perl and apache binaries are stripped)... you can see that mysql_close is
being called with a null argument, rather than mysql_real_connect as
indicated in some of the other backtraces reported.

-+-
Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
mysql_close (mysql=0x0) at libmysql.c:1555
1555  end_server(mysql);
#0  mysql_close (mysql=0x0) at libmysql.c:1555
#1  0x403bf254 in __DTOR_END__ ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#2  0x403ac0dd in mysql_dr_connect ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#3  0x403ac420 in _MyLogin ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#4  0x403ac48f in mysql_db_login ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#5  0x403affd8 in XS_DBD__mysql__db__login ()
...
-+-

Any suggestions for a fix?

Regards,

Drew Degentesh



> -Original Message-
> From: Jochen Wiedmann [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, April 15, 2000 6:57 PM
> To: Doug MacEachern
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Segfault on DBI->Connect
>
>
>
>
> On Tue, 11 Apr 2000, Doug MacEachern wrote:
>
> > On Tue, 4 Apr 2000 [EMAIL PROTECTED] wrote:
> >
> > > I've been seeing the same segfault-on-connect problem
> with Apache 1.2.12
> > > + mod_perl 1.22 + DBI 1.13 + Msql-Mysql-modules 1.2211.
> The segfault is
> > > due to a null first argument being passed to mysql_real_connect().
> > >
> > > Running Apache with a -X argument yields the following
> backtrace when my
> > > mod_perl module does a DBI->connect (str, username,
> passwd, { options }).
> > > Note the null mysql argument 
> > > |
> > > V
> > > #0  0x80ef5b7 in mysql_real_connect (mysql=0x0,
> > > host=0x8a99db8 "hostname.brown.edu", user=0x8a9b550
> "username",
> > > passwd=0x8a9b568 "password", db=0x8a99e40
> "databasename", port=3306,
> > > unix_socket=0x0, client_flag=0) at libmysql.c:1125
> > > #1  0x402d01fd in mysql_dr_connect ()
> > >from
> /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> > > #2  0x402d0540 in _MyLogin ()
> > >from
> /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> > >
> > > The mysql_real_connect routine does a set_sigpipe(mysql),
> which triggers
> > > the segfault.
>
> So my question remains: Why the heck *are* you passing a NULL
> argument?
> Is this because of some bug in the DBD::mysql driver or are you using
> modified sources?
>
> Btw, Doug, as I see the sigpipe thing: What do you recommend for the
> DBD::mysql driver? (Remember the "MySQL morning bug"?) Should we
> enable or disable SIGPIPE?
>
>
> Thanks,
>
> Jochen
>
>
>

Re: Segfault on DBI->Connect

2000-04-15 Thread Jochen Wiedmann

On Tue, 11 Apr 2000, Doug MacEachern wrote:

> On Tue, 4 Apr 2000 [EMAIL PROTECTED] wrote:
> 
> > I've been seeing the same segfault-on-connect problem with Apache 1.2.12
> > + mod_perl 1.22 + DBI 1.13 + Msql-Mysql-modules 1.2211.  The segfault is
> > due to a null first argument being passed to mysql_real_connect().
> > 
> > Running Apache with a -X argument yields the following backtrace when my
> > mod_perl module does a DBI->connect (str, username, passwd, { options }).
> > Note the null mysql argument 
> > |
> > V
> > #0  0x80ef5b7 in mysql_real_connect (mysql=0x0, 
> > host=0x8a99db8 "hostname.brown.edu", user=0x8a9b550 "username", 
> > passwd=0x8a9b568 "password", db=0x8a99e40 "databasename", port=3306, 
> > unix_socket=0x0, client_flag=0) at libmysql.c:1125
> > #1  0x402d01fd in mysql_dr_connect ()
> >from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> > #2  0x402d0540 in _MyLogin ()
> >from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> > 
> > The mysql_real_connect routine does a set_sigpipe(mysql), which triggers
> > the segfault.

If you are using the DBD-mysql sources, as distributed by me, the
mysql_real_connect function will *never* be called with a NULL
argument. This cannot happen, if mysql_init() is called before
mysql_real_connect(). (Unless you are using some patches that I have
recently reached me from the mod_perl mailing list, but that I haven't
verified yet.) Calling mysql_real_connect with mysql==NULL will surely
cause a SEGFAULT.

So my question remains: Why the heck *are* you passing a NULL argument?
Is this because of some bug in the DBD::mysql driver or are you using
modified sources?

Btw, Doug, as I see the sigpipe thing: What do you recommend for the
DBD::mysql driver? (Remember the "MySQL morning bug"?) Should we
enable or disable SIGPIPE?

Thanks,

Jochen

Re: Segfault with Embperl, Apache::Session

2000-04-13 Thread Jason Bodnar

The binaries on both boxes are the same. They get rdist'd out from one
machine every night.

I'm going to rebuild the latest versions of everything on the 2.7 machine
tomorrow and see if that makes a difference. 

At 10:57 PM 4/13/00 -0400, Mark Imbriaco wrote:
>On Thu, 13 Apr 2000, Jason Bodnar wrote:
>
>> Hmmm ... maybe it's a problem with Solaris 5.7?
>
>Can you try the binaries from the 2.6 box on the 2.7 box to see if that
>works?  That would at least kind of indicate whether it's an OS bug or a
>configuration bug.
>
>-Mark
>

--
Jason Bodnar + Tivoli Systems = [EMAIL PROTECTED]

Re: Segfault with Embperl, Apache::Session

2000-04-13 Thread Mark Imbriaco


On Thu, 13 Apr 2000, Jason Bodnar wrote:

> Hmmm ... maybe it's a problem with Solaris 5.7?

Can you try the binaries from the 2.6 box on the 2.7 box to see if that
works?  That would at least kind of indicate whether it's an OS bug or a
configuration bug.

-Mark

RE: Segfault with Embperl, Apache::Session

2000-04-13 Thread Doug MacEachern


this copy-n-paste from ~/Mail/.sent-mail-dec-1999 might help:
---
a few things could shed some more light:
build a libperld.a and compile with PERL_DEBUG=1 (see SUPPORT doc)

and/or, in gdb:

(gdb) source mod_perl-1.21/.gdbinit
(gdb) curinfo

should tell you the line/filename of the offending Perl code

add this to the .gdbinit (which is in the modperl cvs tree):

define longmess
   set $sv = perl_eval_pv("Carp::longmess()", 1)
   printf "%s\n", ((XPV*) ($sv)->sv_any )->xpv_pv
end

(gdb) longmess

should produce a Perl stacktrace

Re: Segfault in __pthread_mutex_lock

2000-04-13 Thread Doug MacEachern

On Thu, 13 Apr 2000, Shevek wrote:

> I have a nasty feeling this might be the RULE_EXPAT thing, I didn't do a
> RULE_EXPAT=no when building Apache. Is there documentation describing the
> dirty details of the issue? Can anybody confirm?

well, are you using XML::Parser?  if so, why not confirm yourself by
trying RULE_EXPAT=no?

RE: Segfault with Embperl, Apache::Session

2000-04-13 Thread Gerald Richter


>
> #0  0xff1d7540 in Perl_sv_clear ()
>from
> /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so

It crashs somewhere deep inside of Perl, so it's hard to say what's happeing
here.

I would first try to recompile all modules (maybe Perl itself also), to make
sure things fit together

Gerald

RE: Segfault with Embperl, Apache::Session

2000-04-13 Thread Jason Bodnar


#0  0xff1d7540 in Perl_sv_clear ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#1  0xff1d7880 in Perl_sv_free ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#2  0xff1ea2a8 in Perl_free_tmps ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#3  0xff1cc1a4 in Perl_pp_nextstate ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#4  0xff1cc07c in Perl_runops ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#5  0xff19b188 in perl_call_sv ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#6  0xff059a2c in CallCV ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#7  0xff05a088 in EvalAndCall ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#8  0xff05a390 in EMBPERL_EvalTransFlags ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#9  0xff05a3e4 in EMBPERL_EvalTrans ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#10 0xff050e7c in ScanCmdEvals ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#11 0xff053e5c in EMBPERL_ProcessBlock ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#12 0xff05aa84 in EMBPERL_EvalMain ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#13 0xff053adc in ProcessFile ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#14 0xff054430 in EMBPERL_ExecuteReq ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#15 0xff04d32c in XS_HTML__Embperl__Req_ExecuteReq ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#16 0xff1d1558 in Perl_pp_entersub ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#17 0xff1cc07c in Perl_runops ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#18 0xff19b188 in perl_call_sv ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#19 0xff059a2c in CallCV ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#20 0xff05a088 in EvalAndCall ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#21 0xff05a390 in EMBPERL_EvalTransFlags ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#22 0xff05a3e4 in EMBPERL_EvalTrans ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#23 0xff050e7c in ScanCmdEvals ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#24 0xff053e5c in EMBPERL_ProcessBlock ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#25 0xff05aa84 in EMBPERL_EvalMain ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#26 0xff053adc in ProcessFile ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#27 0xff054430 in EMBPERL_ExecuteReq ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#28 0xff04d32c in XS_HTML__Embperl__Req_ExecuteReq ()
   from
/opt/gnu/depot/perl5.004_04/lib/site_perl/sun4-solaris/auto/HTML/Embperl/Embperl
.so
#29 0xff1d1558 in Perl_pp_entersub ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#30 0xff1cc07c in Perl_runops ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#31 0xff19b188 in perl_call_sv ()
   from /opt/gnu/depot/perl5.004_04/lib/sun4-solaris/5.00404/CORE/libperl.so
#32 0x5bffc in perl_call_handler ()
#33 0x5b880 in perl_run_stacked_handlers ()
#34 0x5a45c in perl_handler ()
#35 0x7c544 in ap_invoke_handler ()
#36 0x98348 in ap_some_auth_required ()
#37 0x983c8 in ap_process_request ()
#38 0x8c1f4 in ap_child_terminate ()
#39 0x8c45c in ap_child_terminate ()
#40 0x8c65c in ap_child_terminate ()
#41 0x8cf40 in ap_child_terminate ()
#42 0x8dadc in main ()



On 13-Apr-2000 Gerald Richter wrote:
>> If you tell me what to do I'll try to get a stack backtrace.
>>
> 
> http://perl.apache.org/embperl/Faq.pod.1.html#make_test_fails_with_a_SIG
> _
> 
> Gerald

-- 
Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems

Love isn't hopeless.  Look, maybe I'm no expert on the subject, but there
was one time I got it right.

-- Homer Simpson
   Another Simpson's Clip Show

RE: Segfault with Embperl, Apache::Session

2000-04-13 Thread Gerald Richter


> If you tell me what to do I'll try to get a stack backtrace.
>

http://perl.apache.org/embperl/Faq.pod.1.html#make_test_fails_with_a_SIG
_

Gerald

Re: Segfault with Embperl, Apache::Session

2000-04-13 Thread Jason Bodnar


On 13-Apr-2000 Mark Ng wrote:
> can you tell me the following about your 2 systems (the one that works and
> the new
> one),  I have the same problem.
> 
> I need to know:
> Versions of: Perl

Both are 5.004_04

> apache

Both are 1.3.9

> modperl

Both are 1.21

> embperl

Both are 1.2.1

> OS (Exact version and path level)

Machine where I'm getting the errors: SunOS esc-dev 5.7 Generic_106541-04 sun4u
sparc
Machine where it works: SunOS twidow.dev.tivoli.com 5.6 Generic_105181-16 sun4u
sparc

Hmmm ... maybe it's a problem with Solaris 5.7?

> cc compiler used.

Used gcc 2.8.0 for everything.

 
> 
> Mark
> 
> Jason Bodnar wrote:
> 
>> Trying to use Apache::Session with Embperl 1.2.1, mod_perl 1.21, Apache
>> 1.3.9.
>> I've got this running on another machine just fine with the exact same setup
>> (I
>> think).
>>
>> I created a db called sessions with a table called sessions:
>>
>> mysql> show fields from sessions;
>> +---+-+--+-+-+---+
>> | Field | Type| Null | Key | Default | Extra |
>> +---+-+--+-+-+---+
>> | id| varchar(16) |  | PRI | |   |
>> | length| int(11) | YES  | | NULL|   |
>> | a_session | text| YES  | | NULL|   |
>> +---+-+--+-+-+---+
>> 3 rows in set (0.00 sec)
>>
>> When I try access an Embperl page that uses %udat I get:
>>
>> [Thu Apr 13 14:51:05 2000] [notice] Apache/1.3.9 (Unix) mod_perl/1.21
>> configured -- resuming normal operations
>> panic: restartop
>> [Thu Apr 13 14:51:23 2000] [notice] child pid 14373 exit signal Segmentation
>> Fault (11)
>>
>> --
>> Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems
>>
>> Homer:  Well, the evening began at the Gentleman's Club, where we were
>> discussing Wittgenstein over a game of backgammon.
>>
>> Scully: Mr. Simpson, it's a felony to lie to the FBI.
>>
>> Homer:  We were sitting in Barney's car eating packets of mustard.  Ya
>> happy?
>>
>>The Springfield Files
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems

I strive for greatness but will settle for mediocrity. -- Jason Bodnar

RE: Segfault with Embperl, Apache::Session

2000-04-13 Thread Jason Bodnar


On 13-Apr-2000 Gerald Richter wrote:
>> Trying to use Apache::Session with Embperl 1.2.1, mod_perl 1.21,
>> Apache 1.3.9.
>> I've got this running on another machine just fine with the exact
>> same setup (I
>> think).
>>
>>
>> When I try access an Embperl page that uses %udat I get:
>>
>> [Thu Apr 13 14:51:05 2000] [notice] Apache/1.3.9 (Unix) mod_perl/1.21
>> configured -- resuming normal operations
>> panic: restartop
>> [Thu Apr 13 14:51:23 2000] [notice] child pid 14373 exit signal
>> Segmentation
>> Fault (11)
>>
>>
> 
> Any chance to get a stack backtrace from gdb? Is mod_perl link staticly into
> Apache or loaded as DSO? If the second, than upgrade to mod_perl 1.22

If you tell me what to do I'll try to get a stack backtrace.

mod_perl is staticly linked.

-- 
Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems

Second class?  What about Social Security, bus discounts, Medic-Alert
jewelery, Gold Bond powder, pants all the way up to your armpits, and
all those other senior perks?  Oh, if you ask me, old folks have it
pretty sweet.

-- Homer Simpson
   Raging Abe Simpson and His Grumbling Grandson in
   "The Curse of the Flying Hellfish"

RE: Segfault with Embperl, Apache::Session

2000-04-13 Thread Gerald Richter


> Trying to use Apache::Session with Embperl 1.2.1, mod_perl 1.21,
> Apache 1.3.9.
> I've got this running on another machine just fine with the exact
> same setup (I
> think).
>
>
> When I try access an Embperl page that uses %udat I get:
>
> [Thu Apr 13 14:51:05 2000] [notice] Apache/1.3.9 (Unix) mod_perl/1.21
> configured -- resuming normal operations
> panic: restartop
> [Thu Apr 13 14:51:23 2000] [notice] child pid 14373 exit signal
> Segmentation
> Fault (11)
>
>

Any chance to get a stack backtrace from gdb? Is mod_perl link staticly into
Apache or loaded as DSO? If the second, than upgrade to mod_perl 1.22

Gerald

-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-

Re: Segfault on DBI->Connect

2000-04-11 Thread Doug MacEachern


this seems to becoming quite a common problem, i wonder if Jochen can shed
some light?

On Tue, 4 Apr 2000 [EMAIL PROTECTED] wrote:

> I've been seeing the same segfault-on-connect problem with Apache 1.2.12
> + mod_perl 1.22 + DBI 1.13 + Msql-Mysql-modules 1.2211.  The segfault is
> due to a null first argument being passed to mysql_real_connect().
> 
> Running Apache with a -X argument yields the following backtrace when my
> mod_perl module does a DBI->connect (str, username, passwd, { options }).
> Note the null mysql argument 
> |
> V
> #0  0x80ef5b7 in mysql_real_connect (mysql=0x0, 
> host=0x8a99db8 "hostname.brown.edu", user=0x8a9b550 "username", 
> passwd=0x8a9b568 "password", db=0x8a99e40 "databasename", port=3306, 
> unix_socket=0x0, client_flag=0) at libmysql.c:1125
> #1  0x402d01fd in mysql_dr_connect ()
>from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> #2  0x402d0540 in _MyLogin ()
>from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> 
> The mysql_real_connect routine does a set_sigpipe(mysql), which triggers
> the segfault.
> 
> This problem has only come up since I upgraded Apache/mod_perl from
> 1.3.9/1.21 to 1.3.12/1.22.
> 
> Richard Goerwitz
>

Re: Segfault on DBI->Connect (was mod_perl and AuthenDBI headaches)

2000-04-10 Thread Drew Degentesh


Hi,

after some browsing of the [EMAIL PROTECTED] archives, I see now that my
AuthDBI problem is the same as this thread (Segfault on DBI->Connect). I
tried the workaround suggested by wil (*sock=0 before mysql_init(sock)) to
no avail.

Here's a backtrace from gdb httpd -X. Has any headway been made on this
problem? If you need more information, let me know...


Drew



Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
mysql_close (mysql=0x0) at libmysql.c:1555
1555  end_server(mysql);
(gdb) bt
#0  mysql_close (mysql=0x0) at libmysql.c:1555
#1  0x403bf254 in __DTOR_END__ ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#2  0x403ac0dd in mysql_dr_connect ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#3  0x403ac420 in _MyLogin ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#4  0x403ac48f in mysql_db_login ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#5  0x403affd8 in XS_DBD__mysql__db__login ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#6  0x80eba06 in Perl_pp_entersub ()
#7  0x81159ad in Perl_runops_standard ()
#8  0x80bddf1 in perl_call_sv ()
#9  0x4039ce81 in XS_DBI_dispatch ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBI/DBI.so
#10 0x80eba06 in Perl_pp_entersub ()
#11 0x81159ad in Perl_runops_standard ()
#12 0x80bddf1 in perl_call_sv ()
#13 0x806426b in perl_call_handler ()
#14 0x8063c1d in perl_run_stacked_handlers ()
#15 0x806295d in perl_handler ()
#16 0x807c013 in ap_invoke_handler ()
#17 0x808f559 in process_request_internal ()
#18 0x808f5bc in ap_process_request ()
#19 0x8086e5e in child_main ()
#20 0x8086fec in make_child ()
#21 0x8087149 in startup_children ()
#22 0x8087776 in standalone_main ()
#23 0x8087f03 in main ()
#24 0x400cc1eb in __libc_start_main (main=0x8087bbc , argc=2,
argv=0xbd74, init=0x80605a4 <_init>, fini=0x8115a8c <_fini>,
rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbd6c)
at ../sysdeps/generic/libc-start.c:90
(gdb)

Re: Segfault on DBI->Connect

2000-04-05 Thread Richard L. Goerwitz


We seem to be dancing around the DBI->connect segfault problem with MySQL
DBI drivers.  Maybe someone here who reads other relevant lists could for-
ward our traffic and see if we can create some synergy there.

Our basic story is that, with Apache 1.3.12 and mod_perl 1.22 (with DBI
version 1.13 and Msql-Mysql-modules-1.2211), many of us are getting seg-
faults when we call DBI->connect.  I happen to be running RedHat 6.1 with
egcs-2.91.66.  Maybe this is a compiler issue.

Anyway, the point of failure has been found: the MySQL mysql_real_connect()
routine called by Msql-Mysql-modules-1.2211 gets passed a NULL first arg.
So far nobody has figured out what is going on here, and why this problem
has only now started to crop up.

Just to review, here are some relevant portions of our discussion thread.
(As I noted above, it might be really helpful if those with subscriptions
to related lists could repost this information appropriately.)

Relevant quotes:

> Running Apache with a -X argument yields the following backtrace when my
> mod_perl module does a DBI->connect (str, username, passwd, { options }).
> Note the null mysql argument 
> |
> #0  0x80ef5b7 in mysql_real_connect (mysql=0x0,
> host=0x8a99db8 "hostname.brown.edu", user=0x8a9b550 "username",
> passwd=0x8a9b568 "password", db=0x8a99e40 "databasename", port=3306,
> unix_socket=0x0, client_flag=0) at libmysql.c:1125
> #1  0x402d01fd in mysql_dr_connect ()
>from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> #2  0x402d0540 in _MyLogin ()
>from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> 
> The mysql_real_connect routine does a set_sigpipe(mysql), which triggers
> the segfault.

Here's one response -

>> Right,  I had the exact same problem.  Took me almost 1 day to solve.
>> I'm using apache 1.3.12 / mod_perl 1.22 / DBI 1.13 / Msql-Mysql-modules 1.22.11
>>
>> original code:
>> --
>> mysql_init(*sock);
>> 
>> modified:
>> --
>> *sock = 0;
>> mysql_init(*sock);

(I'm not sure how well this will work, since the DBI driver for MySQL takes
elaborate measures to pass a pointer to a MYSQL struct into MyConnect, which
then gets initialized by mysql_init.  The DBI driver relies on the
side-effect
of mysql_init initializing its first argument.  So if we manually set *sock
to zero, other stuff might break.)

Richard Goerwitz
Brown University

Re: Segfault on DBI->Connect

2000-04-05 Thread Junk mails



Right,  I had the exact same problem.  Took me almost 1 day to solve.
I'm using apache 1.3.12 / mod_perl 1.22 / DBI 1.13 / Msql-Mysql-modules 1.22.11

Under normal CGI environment everything works fine but when run with mod_perl
it just segfaults.
As Richard mentioned it's due to a NULL MySQL pointer being passed to the
mysql_init() function of the libmysqlclient library.
I've made a one-line change to the Msql-Mysql-modules-1.2210/mysql/dbdimp.c
at the MyConnect() function, initialize *sock to 0 before sending it to
mysql_init().

original code:
--
mysql_init(*sock);

modified:
--
*sock = 0;
mysql_init(*sock);


This should take you one step further.
Disclaimer: I do not know why this is happening, probably due to the multi-
processes apache+mod_perl environment.  According to the MySQL docs, mysql_init
is supposed to initialize a connection handle for the MySQL struct pointed to
by "MySQL *", if the pointer is null, it'll allocate mem for it.
I'm still experimenting, don't know if this will break anything else!!!
So use with care!!

wil.

--- original message ---

Subject:  Re: Segfault on DBI->Connect
Author:   [EMAIL PROTECTED]
Date: Tue, 4 Apr 2000 10:19:51 -0400

I've been seeing the same segfault-on-connect problem with Apache 1.2.12
+ mod_perl 1.22 + DBI 1.13 + Msql-Mysql-modules 1.2211.  The segfault is
due to a null first argument being passed to mysql_real_connect().

Running Apache with a -X argument yields the following backtrace when my
mod_perl module does a DBI->connect (str, username, passwd, { options }).
Note the null mysql argument 
|
V
#0  0x80ef5b7 in mysql_real_connect (mysql=0x0, 
host=0x8a99db8 "hostname.brown.edu", user=0x8a9b550 "username", 
passwd=0x8a9b568 "password", db=0x8a99e40 "databasename", port=3306, 
unix_socket=0x0, client_flag=0) at libmysql.c:1125
#1  0x402d01fd in mysql_dr_connect ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#2  0x402d0540 in _MyLogin ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so

The mysql_real_connect routine does a set_sigpipe(mysql), which triggers
the segfault.

This problem has only come up since I upgraded Apache/mod_perl from
1.3.9/1.21 to 1.3.12/1.22.

Richard Goerwitz


--- original message ---
Subject:  Segfault on DBI->Connect
Author:   Valter Mazzola <[EMAIL PROTECTED]>
Date: Sat, 01 Apr 2000 18:10:43 CEST

i've a mod_perl script that connect to a mysql db, but sometimes it segfault 
on DBI->connect. i'm using Apache::Registry & Apache::DBI for persistend db 
connection, use strict and the script it's a package. i've read the docs but 
probably i'm missing something.
The persistent DBI connection is ok as i can see from DBI->trace(4)
in the error_log

thank you for your help in advance

valter mazzola, italy
__
Get Your Private, Free Email at http://www.hotmail.com

Re: Segfault on DBI->Connect

2000-04-04 Thread richard


I've been seeing the same segfault-on-connect problem with Apache 1.2.12
+ mod_perl 1.22 + DBI 1.13 + Msql-Mysql-modules 1.2211.  The segfault is
due to a null first argument being passed to mysql_real_connect().

Running Apache with a -X argument yields the following backtrace when my
mod_perl module does a DBI->connect (str, username, passwd, { options }).
Note the null mysql argument 
|
V
#0  0x80ef5b7 in mysql_real_connect (mysql=0x0, 
host=0x8a99db8 "hostname.brown.edu", user=0x8a9b550 "username", 
passwd=0x8a9b568 "password", db=0x8a99e40 "databasename", port=3306, 
unix_socket=0x0, client_flag=0) at libmysql.c:1125
#1  0x402d01fd in mysql_dr_connect ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#2  0x402d0540 in _MyLogin ()
   from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so

The mysql_real_connect routine does a set_sigpipe(mysql), which triggers
the segfault.

This problem has only come up since I upgraded Apache/mod_perl from
1.3.9/1.21 to 1.3.12/1.22.

Richard Goerwitz

RE: Re: Segfault on DBI->Connect

2000-04-04 Thread Valter Mazzola




>From: James G Smith <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>CC: Valter Mazzola <[EMAIL PROTECTED]>, Doug MacEachern 
><[EMAIL PROTECTED]>
>Subject: Re: Segfault on DBI->Connect
>Date: Mon, 03 Apr 2000 00:13:14 -0500
>
>Doug MacEachern <[EMAIL PROTECTED]> wrote:
> >On Sat, 1 Apr 2000, Valter Mazzola wrote:
> >
> >> i've a mod_perl script that connect to a mysql db, but sometimes it 
>segfault
> >> on DBI->connect. i'm using Apache::Registry & Apache::DBI for 
>persistend db
> >> connection, use strict and the script it's a package. i've read the 
>docs but
> >> probably i'm missing something.
> >
> >if you could provide info the SUPPORT doc asks for (including 
>stacktrace),
> >that would help.
>
>Definitely.  I remember running into something like this before.
>I searched the list archives, but couldn't find it -- reminds me
>to make the subject meaningful :)
>
>If I remember correctly, this was a problem that could be traced
>to the DBD::mysql module.  Specifically, the DBD::mysql::db::_login
>call (lines 104-160 of DBD/mysql.pm).  But it's been at least half
>a year since then, so take this as a rough guide as to where you
>might want to look.
>+
thank you for your answer, i'll look into

A NOTE:
Will be wonderful to have more mod_perl debug info when similar  events 
happens without to becoming too crazy with
setting up a decent debug ... specially for newbies .. like me.

it's difficult to do a thing like Velocigen, instead of having mod_perl 
crashing apache when things goes wrong (due to inexperienced people...like 
me?)

__
Get Your Private, Free Email at http://www.hotmail.com

Re: Segfault on DBI->Connect

2000-04-02 Thread James G Smith


Doug MacEachern <[EMAIL PROTECTED]> wrote:
>On Sat, 1 Apr 2000, Valter Mazzola wrote:
>
>> i've a mod_perl script that connect to a mysql db, but sometimes it segfault 
>> on DBI->connect. i'm using Apache::Registry & Apache::DBI for persistend db 
>> connection, use strict and the script it's a package. i've read the docs but 
>> probably i'm missing something.
>
>if you could provide info the SUPPORT doc asks for (including stacktrace),
>that would help.

Definitely.  I remember running into something like this before.  
I searched the list archives, but couldn't find it -- reminds me 
to make the subject meaningful :)

If I remember correctly, this was a problem that could be traced 
to the DBD::mysql module.  Specifically, the DBD::mysql::db::_login 
call (lines 104-160 of DBD/mysql.pm).  But it's been at least half 
a year since then, so take this as a rough guide as to where you 
might want to look.
+-
James Smith - [EMAIL PROTECTED] | http://www.jamesmith.com/
[EMAIL PROTECTED] | http://sourcegarden.org/
  [EMAIL PROTECTED]  | http://cis.tamu.edu/systems/opensystems/
+--

Re: Segfault on DBI->Connect

2000-04-02 Thread Doug MacEachern

On Sat, 1 Apr 2000, Valter Mazzola wrote:

> i've a mod_perl script that connect to a mysql db, but sometimes it segfault 
> on DBI->connect. i'm using Apache::Registry & Apache::DBI for persistend db 
> connection, use strict and the script it's a package. i've read the docs but 
> probably i'm missing something.

if you could provide info the SUPPORT doc asks for (including stacktrace),
that would help.

Re: Segfault in Apache 1.3.9 due to DynaLoader.pm?

1999-10-01 Thread Keith G. Murphy

Doug MacEachern wrote:
> 
> how did you build mod_perl?  as dso?  if so, try build static.

Didn't build it at all.  It was a binary deb from Debian.  I'm currently
trying to build it from source, but having trouble pointing it to the
apache source tree.

Thanks for the replies, though, folks.  I have a bug report in to
Debian.

70 matches

Mail list logo