Bug 76578 - connect using mysql_read_default_file from perl scripts fails
connect using mysql_read_default_file from perl scripts fails
Product: Red Hat Linux
Classification: Retired
Component: mysql (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Patrick Macdonald
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-10-23 12:36 EDT by Berthold Cogel
Modified: 2007-04-18 12:47 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-03-27 10:10:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Berthold Cogel 2002-10-23 12:36:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

Description of problem:
Connecting to mysql server using DBI methods as described in
fails if mysql_read_default_file is used.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use mysql_read_default_file as described in

Actual Results:  Apache Log gives 'premature end of script header'.
Webpage shows 'Internal server error'

Expected Results:  Webpage with database query results

Additional info:

The bug appeared somewhere around mysql 3.23.49 and is fixed in mysql 3.23.50 or
Replacing libmysqlclient.so.10.0.0 in RedHat 7.3 (251027 bytes) with the version
from RedHat 7.2 (266812 bytes) fixes the problem (pre bug version?).
Comment 1 Patrick Macdonald 2003-03-27 10:10:17 EST
I was not able to reproduce this error using the current version of MySQL
(3.23.54a) available for RHL 7.3.  This is consistent with your findings as
listed under "Additional Information".  Please upgrade to the lastest
available version of MySQL if you have not done so already.

Thanks for letting us know about the problem.
Comment 2 IBM Bug Proxy 2005-07-26 13:32:27 EDT
---- Additional Comments From mranweil@us.ibm.com  2005-07-26 13:08 EDT -------
tar of logs, plus a dmesg from a different attempt

Sorry, for some reason I thought I had attached (but obviously hadn't).  The
dmesg is from a different install (trying default partitioning from that disk
rather than manual).  The tmpsdd and devsdd are basically just listings of sdd*
in the appropritate (/dev or /tmp) directory.  It's the node in /tmp that is
mounted during the install, even though fdisk doesn't show sdd1 existing. 

Note You need to log in before you can comment on or make changes to this bug.