php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #13857 Attempting to load shared modules causes header problems.
Submitted: 2001-10-28 10:55 UTC Modified: 2002-06-06 21:12 UTC
From: kyrian at ore dot org Assigned:
Status: Not a bug Package: Dynamic loading
PHP Version: 4.0.6 OS: RedHat 6.1 (ish)
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: kyrian at ore dot org
New email:
PHP Version: OS:

 

 [2001-10-28 10:55 UTC] kyrian at ore dot org
At Jani's request, recreating this bug report with a password so I can edit it directly...

This condition has been present in PHP's 4.0.4pl1 through to snapshot version php4-200110030000

Basically what happens is that whenever we use an "extension=module.so" line in our php.ini, we see the headers generated by the "expose_php = yes" configuration condition, and the "Content-type:", and any session-related headers in the body content of a web page generated by PHP. The only way to make this go away is of course to not use loadable modules, which is not exactly optimal for us.

It happens with a range of modules, basically every one that we have tried. It also happens with "extension=non-existent-module.so".

However as Jani rightly said, there would be complaints all over the place about this one if it happened to everyone, so  it must be dependant on some other factor, ie. the OS.

There's some background information following this...

Oh, our config has been varied considerably through the various releases, due to customer demand for new features to be compiled in, but the latest version we've been using is:

./configure --with-mysql=/usr --with-gd --enable-force-cgi-redirect --with-config-file-path=/etc/php4/cgi/ --with-imap --enable-ftp --with-openssl --with-kerberos=/usr/kerberos --with-jpeg=/usr --with-pdflib --with-domxl --with-wbmp
--with-zlib=/usr --with-bz2

No doubt you'll email me if you need more info ;-)

K.

PS. For reference, because it's probably useful, this used to be "Bug #13176 Updated: Headers output in HTML body.", but I didn't put in a password, so I had to email updates, hence the new bug report.

>It doesn't seem to be related to "extension=module.so" where the module
>is already compiled in explicitly, or where it isn't. It also doesn't
>seem to be related to a specific module.
>
>I think you're right, though. I think it's probably a problem specific
>to PHP on a certain (RedHat) architecture.
>
>The best way to solve it looks to be to consider the mechanism involved
>in loading the modules, and seeing what code external to PHP is called,
>and what it might be doing that's nasty.
>
>So, here's what our ld.so is:
>
>"[root@fred cgi]# rpm -qi ld.so-1.9.5-8
>Name        : ld.so                        Relocations: (not
>relocateable)
>Version     : 1.9.5                             Vendor: Red Hat Software
>Release     : 8                             Build Date: Tue Aug 25
>10:55:21 1998
>Install date: Wed Jan 13 17:50:46 1999      Build Host: porky.redhat.com
>Group       : Libraries                     Source RPM:
>ld.so-1.9.5-8.src.rpm
>Size        : 251943                           License: BSD
>Packager    : Red Hat Software <bugs@redhat.com>
>Summary     : Shared library configuration tool and old dynamic loader
>Description :
>
>This package contains the shared library configuration tool, ldconfig,
>which
>is required by many packages. It also includes the shared library loader
>and dynamic loader for Linux libc 5."
>
>Also, it might be of import that we are compiling on a different machine
>to that which we are deploying the PHP binary (for security etc., we
>don't have compilers on our world-facing web servers, and hence have to
>compile elsewhere).
>
>But I don't know for sure. This is all rather in depth code stuff for
>me...
>
>> >> [2001-09-06 11:47:31] sniper@php.net
>> >>
>> >> Does this happen with certain script?
>> >All scripts for all of our customers it seems, until we remove all
>> >dynamic module loading in their php.ini.
>>
>> This is odd. Does plain vanilla php.ini-dist copied to php.ini work??
>>
>> >> Does this happen with latest CVS snapshot from
>> >> http://snaps.php.net/ ?
>> >Haven't had a chance to test this yet, but it's happened in every
>> >version from 4.0.4pl1 through to 4.0.6 so far...
>>
>> Please try the snapshot. There have been so many fixes and at least
>> two of them were module loading related.
>>
>> --Jani



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-01-14 02:36 UTC] lobbin@php.net
Do the happen on 4.1.1?
 [2002-01-14 07:25 UTC] kyrian at ore dot org
Unfortunately I've lost access (due to quitting the company) to the machines on which I originally was able to produce this problem.

AFAIK it wasn't restricted to just those machines, though and happened on any RedHat 6.x machine, so I'll try and find one that I've not upgraded at home, and test it on that, as well as on a RH7.2 machine, and see what happens.

This may take some time, though...
 [2002-06-06 21:12 UTC] sniper@php.net
No feedback and so far nobody else has been able to
reproduce this..

 [2002-06-06 21:12 UTC] sniper@php.net
No feedback and so far nobody else has been able to
reproduce this..

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 09:01:28 2024 UTC