Out of curiosity, have you tried installing the ActiveState-5.8 RPM and
doing the testing?  It seems like an easy way to test your theory of
$platforms{'RedHat8.0'}->sucks = 1, as it installs in (I speak for the .deb)
/usr/local/ActivePerl-5.8 and is self-contained, so it can be installed
alongside the RedHat default package.  Methinks it's at least worth a shot.

http://www.activestate.com/Products/Download/Register.plex?id=ActivePerl

Christopher S. Cosby
SciCare Software Services
770.236.1128 

> -----Original Message-----
> From: Thomas Good [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 18, 2003 10:53 AM
> To: Tim Bunce
> Cc: Jarkko Hietaniemi; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Using perl 5.8.0?
> 
> 
> On Tue, 18 Mar 2003, Tim Bunce wrote:
> 
> > Thomas, did you get round to doing this?
> >
> > Tim.
> 
> Hi Tim,
> 
> I have worked on it a bit...
> 
> I attempted to reproduce the problem here at work on a test 
> machine running
> slackware 8.0.  I installed perl 5.8.0 and built.  No errors. 
>  Then I recalled
> that Redhat (in their wisdom) built the default perl 5.8 
> install with the
> multi-threading turned on.  I edited the Makefile and built 
> again.  Still no
> errors on slackware.  So, I have been reading through all of 
> the patches, etc,
> that redhat applied to the perl src to try and see what they 
> did that may
> have caused this.
> 
> I rebuilt perl from the src rpm on my redhat machine at home 
> and turned off
> multi-threading.  My script still hangs.  So, I have no idea 
> what is going
> on.  Here at work we run slackware on all boxes except the 
> IBM machine that
> has an LSI SCSI card (unsupported by slackware 8.x) and this 
> machine was the
> one that had trouble.  It now runs redhat 7.3 and perl 5.6.1 
> so it works fine.
> 
> In the interests of reproducing the problem I installed 
> redhat 8.0 on the
> a test box at home.  No difficulty whatsoever in reproducing 
> the error.  I
> tried to rebuild DBI as you suggested but ran into the usual 
> errors from
> redhat (broken dependency hell, as they cannot leave well 
> enough alone).
> That's as far as I've gotten.
> 
> To recap:
> 
> 1.  I cannot reproduce this problem on slackware.
> 2.  The problem is easily reproduced on redhat 8.
> 3.  Redhat does all kinds of odd things to the perl src (and 
> makes all sorts
>     of cute/disparaging comments in the code whilst doing so) 
> and this appears
>     to have either created or exacerbated the problem that is 
> causing my
>     scripts to hang.
> 
> I will try some more to get RH8 to agree to let me replace 
> the rpm dbi with
> a build that has your suggestions in place and then get back to you.
> 
> Sorry for the delay, very busy...
> 
> Cheers.
> 
> > On Wed, Feb 26, 2003 at 10:54:12AM +0000, Tim Bunce wrote:
> > > On Tue, Feb 25, 2003 at 05:30:31PM -0500, Thomas Good wrote:
> > > > On Tue, 25 Feb 2003, Tim Bunce wrote:
> > > >
> > > > > > While I was using 5.8 large data transfers via DBI 
> failed consistently.
> > > > > > I have compared notes with others (including 
> Lincoln Stein) and this
> > > > > > problem is easily reproduced.  In fact, I can't 
> stop reproducing it. ;-)
> > > > > >
> > > > > A self-contained test case would be ideal!
> > > >
> > > > Hi, I will try to put this together, meanwhile here is 
> a summary:
> > > >
> > > > I have a postgres table with 220 individual patient skills -
> > > > these skills become questions on a long form.  Another table
> > > > holding live patient records is queried and the returned values
> > > > serve as popup_menu() defaults
> > > >
> > > > Tr ( td ( "$skill[0]" )                         <-- 
> Here is the string/question
> > > >      td ( popup_menu( ...
> > > >                    -values=>['1 - Excellent', '2 - 
> Adequate', '3 - Needs Attention',
> > > >                              '4 - Needs Immediate 
> Attention', '5 - Not Applicable'],
> > > >                    -default=>"$row->{item_01}"  <-- 
> Here is the returned value
> > > >                       ...
> > > >
> > > > On wellworn test equipment (all ide, 64M RAM, clock 
> speed of 300MHz) running
> > > > Slackware 8.1, perl 5.6.1, DBI 1.25, Apache 1.3.26, 
> DBD-Pg 1.21, Postgres 7.3.1
> > > > this script runs.
> > > >
> > > > On a brand new IBM eServer (LSI SCSI, 512M RAM, 2 GHz 
> clock) running Redhat 8.0,
> > > > perl 5.8.0, DBI 1.28, Apache 2.0.40, DBD-Pg 1.21 the 
> script hangs.
> > > > I tried commenting out the defaults, etc.  Only 
> removing both queries allowed
> > > > the script to run.  The CGI form was not a problem, 
> even when I doubled the
> > > > length as a test.
> > >
> > > Enable tracing to a log file (eg set DBI_TRACE env var to 
> something
> > > like "6=/tmp/dbi.log") and then run the script using truss
> > > (or similar tool that shows operating system calls).
> > >
> > > As a (better) alternative to using truss you could do a kill -QUIT
> > > on the process once it has hung and then get a stack 
> trace from the
> > > core file.
> > >
> > > That would be useful, but to be *really* helpful the DBI 
> and DBD::Pg
> > > would need to be compiled and linked with debugging enabled (ie -g
> > > option to the compiler/linker).
> > >
> > > For the DBI you can do that by simply rebuilding it starting with
> > > "perl Makefile.PL -g".
> > >
> > > For DBD::Pg you may need to run "perl Makefile.PL" and 
> then hack the
> > > generated Makefile: Add -g as an option on the "CCCMD = $(CC) ..."
> > > line and also to the "OTHERLDFLAGS =" line.
> > >
> > > Once you've got the core file you can get a stack dump 
> using a debugger
> > > like gdb ("gdb /path/to/the/perl/you/used /path/to/core" 
> then "bt".)
> > >
> > > Tim.
> >
> 
> 
> --------------------------------------------------------------
> ---------
> Thomas Good                                  e-mail: 
> [EMAIL PROTECTED]
> Programmer/Analyst                           phone:   (+1) 
> 718.818.5528
> Residential Services                         fax:     (+1) 
> 718.818.5056
> Behavioral Health Services, SVCMC-NY         mobile:  (+1) 
> 917.282.7359
> 
> // Bitte nicht vergessen: der Kindermord bei Ypern.  Nie Wieder Krieg!
> 


     - - - - - - -  Appended by Scientific-Atlanta, Inc.  - - - - - - -  
This e-mail and any attachments may contain information which is confidential, 
proprietary, privileged or otherwise protected by law. The information is solely 
intended for the named addressee (or a person responsible for delivering it to the 
addressee). If you are not the intended recipient of this message, you are not 
authorized to read, print, retain, copy or disseminate this message or any part of it. 
If you have received this e-mail in error, please notify the sender immediately by 
return e-mail and delete it from your computer. 

Reply via email to