> 
> On Tue, 2004-01-06 at 13:09, Tim Bunce wrote:
> > On Tue, Jan 06, 2004 at 12:29:43PM -0800, Michael Peppler wrote:
> > > On Tue, 2004-01-06 at 09:05, Sean Kelly wrote:
> > > > Quoting Gerald Richter <[EMAIL PROTECTED]>:
> > > > 
> > > > > Do you have any chance to test the same scripts with 
> Perl 5.8.0 
> > > > > ?
> > > > 
> > > >   I have now built and installed Perl 5.8.0 using GCC 
> 2.95.3 on my 
> > > > Solaris
> > > > 8 for sparc box.  I then installed DBI 1.39 and 
> DBD::Oracle 1.14.  Oracle 
> > > > 9i was already installed.
> > > > 
> > > >   Code snippet 1 
> (http://shortestpath.org/threads1.html) now > works 
> > > > fine 
> -
> > > > there is no longer a core dump when joining the threads.
> > > 
> > > I can reproduce the problem with DBD::Sybase, and both 5.8.2 and 
> > > 5.8.1.
> > > 
> > > The core dump is in the new pad.c file, on line 244 (in 
> > > Perl_pad_undef).
> > 
> > Would be great if someone can reduce it down to a pure-perl 
> test case 
> > (and then report it using perlbug, or by email to perl5-porters)
> 
> I wasn't able to create a pure-perl repro.
> 
> However, patching pad.c with the following at least avoids 
> the segfault:
> 
> *** pad.c~      Tue Sep 30 10:11:42 2003
> --- pad.c       Tue Jan  6 13:58:53 2004
> ***************
> *** 242,247 ****
> --- 242,248 ----
>         for (ix = AvFILLp(comppad_name); ix > 0; ix--) {
>             SV *namesv = namepad[ix];
>             if (namesv && namesv != &PL_sv_undef
> +               && SvPOK(namesv)
>                 && *SvPVX(namesv) == '&')
>             {
>                 CV *innercv = (CV*)curpad[ix];
> 
> 
> I'm almost certain that this isn't the *right* fix, as I get 
> a message about "Scalars leaked: 40" after running the script.

I had similar results under Win32 as per Michael.  I tried debugging it for
a bit to see something obvious, but nothing struck me and even when I was
into the perl source, I didn't get too deep -- just enough to understand the
Win32 port.

Note that I also tried (but not 100% sure it's the correct approach):
Set DBI_PUREPERL=2
Set DBI_DSN=dbi:Sponge:c:\

And then run the script (I changed the connect call to use the environment,
so I could switch the connections, to see if it was driver specific...it
wasn't, Oracle and ODBC did the same thing).  

The goal was to use DBI::PurePerl and a pure perl driver, eliminating the
XS.  Thus, I think it can be reproduced with "pure" perl, not just with the
XS code, if that helps.

Jeff




Reply via email to