#13595 [Com]: Solution for "PHP Fatal error: Unable to start session mm module in Unknown on
ID: 13595
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Session related
Operating System: Debian Sid
PHP Version: 4.0.6
New Comment:
Hello,
I'm still having problems with this.
PHP 4.1.2
Redhat 7.2
latest updates and fixes from Redhat are installed
Already checkec everything mentioned above, nothing works for me. I
don't get it all the time. It happens only when PHP is used at the
command line or in cronjobs...
Already searched google etc, no solution found so far.
Thanks.
Previous Comments:
[2002-08-09 14:24:32] [EMAIL PROTECTED]
I'm also using debian sid, and the same happens. PHP 4.2.1, nothing in
/tmp. The first time it happened I removed php4, and re-installed it,
and the problem was gone. And when it occured 15 minutes ago I tried
removing php4-cgi, which I also had installed, and the problem is gone
now. So there might be a kind of clash between php4 and php4-cgi?
But anyway, it would be very nice to have a more descriptive output
from php4...
[2002-07-30 22:49:50] [EMAIL PROTECTED]
So, following this thread, I'm still not having any luck.
I'm running debian-woodie, and upgraded to the 4.2.1 package for it. I
checked my php.ini for weird paths, checked /tmp and (because someone
mentioned it) /etc for session_mm files, and the problem still
persists. Here's what I get out of strace:
open("/usr/lib/apache/1.3/libphp4.so", O_RDONLY) = 4
[...]
open("/usr/lib/libmm.so.11", O_RDONLY) = 4
[...]
open("./php.ini", O_RDONLY|O_LARGEFILE) = 5
getcwd("/etc/php4/apache", 4096)= 17
lstat("/etc/php4/apache/php.ini", {st_mode=S_IFREG|0644, st_size=26777,
...}) = 0
open("/etc/ld.so.cache", O_RDONLY) = 5
open("/lib/libnss_db.so.2", O_RDONLY) = 5
open("/lib/libnss_files.so.2", O_RDONLY) = 5
open("/usr/lib/libdb3.so.3", O_RDONLY) = 5
open("/var/lib/misc/protocols.db", O_RDWR|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open("/var/lib/misc/protocols.db", O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open("/etc/protocols", O_RDONLY)= 5
open("/var/lib/misc/protocols.db", O_RDWR|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open("/var/lib/misc/protocols.db", O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open("/etc/protocols", O_RDONLY)= 5
unlink("/tmp/session_mm_apache0.sem") = -1 ENOENT (No such file or
directory)
I left in some cruft, because I have no idea what's going on.
If anyone has any thoughts...
-j
[2002-06-18 09:19:23] [EMAIL PROTECTED]
Hi y'all,
This 'bug' is solved long time ago.
1 Upgrade to php 4.2.1
2 see /tmp for a session_mm.sem and remove it.
[2002-06-18 04:00:23] [EMAIL PROTECTED]
This is most likely fixed in the latest version. Please reopen if PHP
4.2.1 doesn't fix the problem.
[2002-06-12 22:15:51] [EMAIL PROTECTED]
I get
fstat64(3, {st_mode=S_IFREG|0644, st_size=1748, ...}) = 0
unlink("/tmp/session_mm_apache0.sem") = -1 ENOENT (No such file or
directory)
before it dies, any idea? (using debian linux)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/13595
--
Edit this bug report at http://bugs.php.net/?id=13595&edit=1
#21224 [Com]: apache configure fails at php module
ID: 21224 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: Problem solved (for me) when removing --enable-versioning from the configure Previous Comments: [2002-12-30 09:32:31] [EMAIL PROTECTED] I'm having the same problem building 4.3.0 with Apache on my server, previous builds were ok: RedHat Linux 7.1 kernel 2.4.18-18.7.xsmp gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-112.7.1) ld -v GNU ld version 2.10.91 (with BFD 2.10.91.0.2) libtool --version ltmain.sh (GNU libtool) 1.3.5 (1.385.2.206 2000/05/27 11:12:27) ./configure --prefix=/usr/local/php \ --with-config-file-path=/usr/local/php --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql --with-oci8=/usr/local/oracle \ --with-oracle=/usr/local/oracle --with-sybase-ct=/opt/sybase-12.5/OCS-12_5 \ --with-pdflib=/usr/local/pdflib --with-jpeg --with-tiff --with-zlib \ --with-gd --with-ttf --with-freetype --with-xml --with-gettext \ --enable-ftp --enable-versioning --enable-sockets --enable-calendar \ --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-debugger \ --enable-magic-quotes --enable-rpath --enable-short-tags --enable-posix \ --enable-session --enable-xml --enable-bcmath --enable-ctype --enable-mailparse \ --with-apache=../apache_1.3.27 ./configure --with-layout=Apache --prefix=/usr/local/apache \ --activate-module=src/modules/php4/libphp4.a --enable-module=so \ --enable-module=rewrite --add-module=mod_gzip.c Configuring for Apache, Version 1.3.27 + using installation path layout: Apache (config.layout) + activated php4 module (modules/php4/libphp4.a) + on-the-fly added and activated gzip module (modules/extra/mod_gzip.o) Creating Makefile Creating Configuration.apaci in src Creating Makefile in src + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o rewrite_module uses ConfigStart/End + using -lndbm for DBM support enabling DBM support for mod_rewrite o php4_module uses ConfigStart/End + using system Expat + using -ldl for vendor DSO support + checking sizeof various data types + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. The below error output from the compilation ** test will give you an idea what is failing. Note that ** Apache requires an ANSI C Compiler, such as gcc. Error Output for sanity check cd ..; gcc -DLINUX=22 -I/usr/include/db1 `./apaci` -o helpers/dummy helpers/dummy.c -Wl,-rpath,/usr/local/mysql/lib/mysql -Wl,-rpath,/usr/local/oracle/lib -Wl,-rpath,/lib -Wl,-rpath,/usr/local/pdflib/lib -Wl,-rpath,/usr/local/pgsql/lib -Wl,-rpath,/opt/sybase-12.5/OCS-12_5/lib -rdynamic -L/usr/local/mysql/lib/mysql -L/usr/local/oracle/lib -L/lib -L/usr/local/pdflib/lib -L/usr/local/pgsql/lib -L/opt/sybase-12.5/OCS-12_5/lib -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -export-symbols /usr/local/src/php-4.3.0/sapi/apache/php.sym -rdynamic -L/usr/local/mysql/lib/mysql -L/usr/local/oracle/lib -L/lib -L/usr/local/pdflib/lib -L/usr/local/pgsql/lib -L/opt/sybase-12.5/OCS-12_5/lib -lsybtcl -lintl -lcomn -lct -lcs -lpq -lpdf -lz -lpng -lmysqlclient -lttf -lpng -lz -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -ldl -lm -lnsl -lclntsh -ldl -lm -lnsl -lclntsh -lm -lcrypt -lndbm -lexpat -ldl /usr/bin/ld:/usr/local/src/php-4.3.0/sapi/apache/php.sym: file format not recognized; treating as linker script /usr/bin/ld:/usr/local/src/php-4.3.0/sapi/apache/php.sym:2: parse error collect2: ld returned 1 exit status make: *** [dummy] Error 1 = End of Error Report = Aborting! [2002-12-30 05:59:59] [EMAIL PROTECTED] Same problem at Linux RedHat 6.2 machines, some with: GNU ld 2.9.5 ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) and others with: GNU ld 2.13.2 ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [2002-12-28 04:33:22] [EMAIL PROTECTED] the libtool on the php distribution tree is: ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) I have to say that previous versions of php up to 4.3.0rc2 compiled fine on the same system. [2002-12-28 01:01:44] [EMAIL PROTECTED] What version of libtool are you using? [2002-12-27 16:58:54] [EMAIL PRO
Bug #16128 Updated: move_uploaded_file breaks safe_mode and open_basedir restrictions
ID: 16128
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *General Issues
Operating System: Linux 2.4.13
PHP Version: 4.1.2
New Comment:
In CVS it's fixed _if_ you use open_basedir. But if you don't, the
php_checkuid fails to do it's work...
Previous Comments:
[2002-03-17 16:03:34] [EMAIL PROTECTED]
This bug has been fixed in CVS.
[2002-03-17 15:21:37] [EMAIL PROTECTED]
The script in this example is a bit crippled due to wordwrapping. Here
is the original script:
http://root.net-force.nl/prog.txt
[2002-03-17 15:05:11] [EMAIL PROTECTED]
One of my customers has found a way to break my safe_mode and
open_basedir restrictions. (www.net-force.nl)
He created the following script:
$file was sucessfully
uploaded";
} else {
echo "Sorry, your file exceeds the size limit of $size_limit
bytes";
}}
echo "
Upload a file:
";
?>
As you can see, he moved the uploaded file to:
"/domains/killanet.org/public_html/www/test/"
Which should be impossible, because my httpd.conf says:
DocumentRoot /domains/net-force.nl/public_html/root/
ServerName root.net-force.nl
CustomLog /domains/net-force.nl/logs/access_log combined
ErrorLog /domains/net-force.nl/logs/error_log
php_admin_value safe_mode 1
php_admin_value open_basedir /domains/net
force.nl/public_html/root/
As you can see I have both set safe_mode and the open_basedir
restriction but this user is able to upload any file where the apache
user has write access.
Credits fly out to [EMAIL PROTECTED] for finding this bug.
--
Edit this bug report at http://bugs.php.net/?id=16128&edit=1
#25051 [NEW]: translating between gettext language identifiers and 'Accept-Language' ones
From: wouter at grep dot be Operating system: irrelevant PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: translating between gettext language identifiers and 'Accept-Language' ones Description: Hi, Linking in the GNU gettext library is a good thing, as that makes translating documents a lot easier, more manageable. However, as the point usually is not to translate into whatever the server admin wants it to be, but to translate into a human language, it would be nice if there was a general-purpose function that can translate the information in 'Accept-Language' and 'Accept-Encoding' into a gettext-style language string; that way, translating would be much easier. -- Edit bug report at http://bugs.php.net/?id=25051&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25051&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25051&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25051&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25051&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25051&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25051&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25051&r=support Expected behavior: http://bugs.php.net/fix.php?id=25051&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25051&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25051&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25051&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25051&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25051&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25051&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25051&r=gnused
#49462 [Com]: Session variables not saved after redirect, session_write_close(), die() used
ID: 49462
Comment by: wouter at prepaidwebhost dot nl
Reported By: greg dot solak at profiletwist dot com
Status: No Feedback
Bug Type: Session related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
Same problem, however not on the 5.3 version of PHP, but using PHP
5.2.10-2.2 on Debian Squeeze.
Previous Comments:
[2009-09-12 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-09-04 11:26:41] j...@php.net
Also, your example script really can't work since it does not have
session_start() called at all. It's not enough that you say it's there
when it clearly isn't.
[2009-09-04 11:25:33] j...@php.net
Does this happen with PHP 5.2.10 ? (hint: works just fine for me on
several sites without any problems..)
[2009-09-03 23:01:05] greg dot solak at profiletwist dot com
Description:
PHP SESSION variable $_SESSION['user_level'] is not saved after the
page is redirected using header(location: ...). Session_write_close()is
used right before redirect. After redirect die() is called. After a
second attempt at login, everything works!
Reproduce code:
---
// Change session properties
$_SESSION['user_level'] = 7;
// Force session to save changes before redirection
session_write_close(); // REQUIRED
// Regenerate session id for security + fix bug in which some session
variables are lost during redirect
session_regenerate_id(true);
// Redirect to Access main page
header('Location: http://www.domain.com/access/main.php');
die();
?>
Expected result:
At the new page (the one the user was redirected to) the
$SESSION['user_level'] should == 7. However, the session variable was
not saved, as the user is redirected back to the login page. After a
second attempt at logging in, everything works as expected.
Actual result:
--
Redirected back to login page, because when php checked if the user had
the proper credentials
if ($_SESSION['user_level'] != 7) {
// redirect back to login page
}
Other improtant information: session_start(); is called on every page.
--
Edit this bug report at http://bugs.php.net/?id=49462&edit=1
#39401 [Opn]: conflicting types for utf8_mime2text
ID: 39401 User updated by: wouter at widexs dot nl Reported By: wouter at widexs dot nl Status: Open Bug Type: IMAP related Operating System: Linux PHP Version: 4.4.4 New Comment: That's not the point ;) It's the hope to have this fixed in 4.4.5 so we can use it without patching, just like in 5.x Previous Comments: [2007-01-26 12:33:40] dmda at yandex dot ru you can fix this with following: open ext/php_imap.c in your favorite editor, remove utf8_mime2text prototype (it's just wrong), find utf8_mime2text function call and add 3rd arguement: U8T_CANONICAL that's all tricks. [2007-01-22 15:53:01] php at aaronrubin dot com Are there any plans to patch this? The latest snapshots still have the same issue. [2007-01-03 19:42:41] jmoseley at pgtv dot com Can someone provide a patch for 4.4.4? The latest CVS release of 4.4.4 does not include the fix. I'd compile 5.2.0, but I am having linker problems since I run a Solaris box that uses a GCC compiler build with Sun's ld, blah, blah, blah. ---- [2006-11-17 10:26:53] wouter at widexs dot nl This was indeed fixed when using full-path, BUT it is still present in PHP 4.4.4 and PHP4-dev. (bugfix from 5.x not backported to 4.x) [2006-11-07 20:53:18] [EMAIL PROTECTED] It works just fine here as long as the fullpath to the library is specified ala /usr/local/imap-2006c The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/39401 -- Edit this bug report at http://bugs.php.net/?id=39401&edit=1
#39401 [NEW]: conflicting types for utf8_mime2text
From: wouter at widexs dot nl Operating system: Linux PHP version: 5.2.0 PHP Bug Type: IMAP related Bug description: conflicting types for utf8_mime2text Description: I get an error when trying to build PHP 5.2.0 with imap c-client 2006c1 (ftp://ftp.cac.washington.edu/mail/imap-2006c1.tar.Z) : /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' Which is correct, because: * PHP 5.2.0 : long utf8_mime2text(SIZEDTEXT *src, SIZEDTEXT *dst); * imap c-client 2006c1 : long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags); Haven't tested with previous versions of PHP, but I assume the same will happen. IMAP c-client 2004g gives no problem. This could be seen as a DUP of #37948 and #38941, but it is still present in 5.2.0 ... Actual result: -- /bin/sh /opt/install/widexs_apache_2006_017/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/imap/ -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/ -DPHP_ATOM_INC -I/opt/install/widexs_apache_2006_017/php-5.2.0/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/main -I/opt/install/widexs_apache_2006_017/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/ssl/include -I/usr/local/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/date/lib -I/usr/include/freetype2 -I/opt/install/widexs_apache_2006_017/imap-2006c1/c-client -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/oniguruma -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/mysql/include/mysql -I/usr/local/pgsql/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/TSRM -I/opt/install/widexs_apache_2006_017/php-5.2.0/Zend-I/usr/include -g -O2 -c /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c -o ext/imap/php_imap.lo /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' -- Edit bug report at http://bugs.php.net/?id=39401&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39401&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39401&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39401&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39401&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39401&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39401&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39401&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39401&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39401&r=support Expected behavior:http://bugs.php.net/fix.php?id=39401&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39401&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39401&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39401&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39401&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39401&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39401&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39401&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39401&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39401&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39401&r=mysqlcfg
#39401 [Fbk->Opn]: conflicting types for utf8_mime2text
ID: 39401 User updated by: wouter at widexs dot nl Reported By: wouter at widexs dot nl -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Linux PHP Version: 5.2.0 New Comment: Yes, it does :) grep "mail_append_set" src/c-client/mail.h SEARCHSET *mail_append_set (SEARCHSET *set,unsigned long msgno); Previous Comments: [2006-11-06 17:01:26] [EMAIL PROTECTED] Does your imap's mail.h header contain the mail_append_set() function? [2006-11-06 15:23:14] wouter at widexs dot nl Description: I get an error when trying to build PHP 5.2.0 with imap c-client 2006c1 (ftp://ftp.cac.washington.edu/mail/imap-2006c1.tar.Z) : /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' Which is correct, because: * PHP 5.2.0 : long utf8_mime2text(SIZEDTEXT *src, SIZEDTEXT *dst); * imap c-client 2006c1 : long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags); Haven't tested with previous versions of PHP, but I assume the same will happen. IMAP c-client 2004g gives no problem. This could be seen as a DUP of #37948 and #38941, but it is still present in 5.2.0 ... Actual result: -- /bin/sh /opt/install/widexs_apache_2006_017/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/imap/ -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/ -DPHP_ATOM_INC -I/opt/install/widexs_apache_2006_017/php-5.2.0/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/main -I/opt/install/widexs_apache_2006_017/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/ssl/include -I/usr/local/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/date/lib -I/usr/include/freetype2 -I/opt/install/widexs_apache_2006_017/imap-2006c1/c-client -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/oniguruma -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/mysql/include/mysql -I/usr/local/pgsql/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/TSRM -I/opt/install/widexs_apache_2006_017/php-5.2.0/Zend-I/usr/include -g -O2 -c /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c -o ext/imap/php_imap.lo /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' -- Edit this bug report at http://bugs.php.net/?id=39401&edit=1
#39401 [Fbk->Opn]: conflicting types for utf8_mime2text
ID: 39401 User updated by: wouter at widexs dot nl Reported By: wouter at widexs dot nl -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Linux PHP Version: 5.2.0 New Comment: It hasn't ... php-5.2.0/main/php_config.h:/* #undef HAVE_NEW_MIME2TEXT */ Previous Comments: [2006-11-07 17:09:03] [EMAIL PROTECTED] Can you see if HAVE_NEW_MIME2TEXT is defined inside PHP's main.h ? [2006-11-06 18:25:37] wouter at widexs dot nl Yes, it does :) grep "mail_append_set" src/c-client/mail.h SEARCHSET *mail_append_set (SEARCHSET *set,unsigned long msgno); [2006-11-06 17:01:26] [EMAIL PROTECTED] Does your imap's mail.h header contain the mail_append_set() function? ---- [2006-11-06 15:23:14] wouter at widexs dot nl Description: I get an error when trying to build PHP 5.2.0 with imap c-client 2006c1 (ftp://ftp.cac.washington.edu/mail/imap-2006c1.tar.Z) : /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' Which is correct, because: * PHP 5.2.0 : long utf8_mime2text(SIZEDTEXT *src, SIZEDTEXT *dst); * imap c-client 2006c1 : long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags); Haven't tested with previous versions of PHP, but I assume the same will happen. IMAP c-client 2004g gives no problem. This could be seen as a DUP of #37948 and #38941, but it is still present in 5.2.0 ... Actual result: -- /bin/sh /opt/install/widexs_apache_2006_017/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/imap/ -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/ -DPHP_ATOM_INC -I/opt/install/widexs_apache_2006_017/php-5.2.0/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/main -I/opt/install/widexs_apache_2006_017/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/ssl/include -I/usr/local/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/date/lib -I/usr/include/freetype2 -I/opt/install/widexs_apache_2006_017/imap-2006c1/c-client -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/oniguruma -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/mysql/include/mysql -I/usr/local/pgsql/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/TSRM -I/opt/install/widexs_apache_2006_017/php-5.2.0/Zend-I/usr/include -g -O2 -c /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c -o ext/imap/php_imap.lo /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' -- Edit this bug report at http://bugs.php.net/?id=39401&edit=1
#39401 [Opn]: conflicting types for utf8_mime2text
ID: 39401 User updated by: wouter at widexs dot nl Reported By: wouter at widexs dot nl Status: Open Bug Type: IMAP related Operating System: Linux PHP Version: 5.2.0 New Comment: CHECKING FOR HAVE_NEW_MIME2TEXT configure:45679: ../imap-2006c1/c-client/mail.h: No such file or directory This file exists though... If I change configure from : #include <$IMAP_INC_DIR/mail.h> to #include "$IMAP_INC_DIR/mail.h" It correctly works... Previous Comments: [2006-11-07 18:49:33] wouter at widexs dot nl It hasn't ... php-5.2.0/main/php_config.h:/* #undef HAVE_NEW_MIME2TEXT */ [2006-11-07 17:09:03] [EMAIL PROTECTED] Can you see if HAVE_NEW_MIME2TEXT is defined inside PHP's main.h ? ---- [2006-11-06 18:25:37] wouter at widexs dot nl Yes, it does :) grep "mail_append_set" src/c-client/mail.h SEARCHSET *mail_append_set (SEARCHSET *set,unsigned long msgno); [2006-11-06 17:01:26] [EMAIL PROTECTED] Does your imap's mail.h header contain the mail_append_set() function? -------- [2006-11-06 15:23:14] wouter at widexs dot nl Description: I get an error when trying to build PHP 5.2.0 with imap c-client 2006c1 (ftp://ftp.cac.washington.edu/mail/imap-2006c1.tar.Z) : /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' Which is correct, because: * PHP 5.2.0 : long utf8_mime2text(SIZEDTEXT *src, SIZEDTEXT *dst); * imap c-client 2006c1 : long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags); Haven't tested with previous versions of PHP, but I assume the same will happen. IMAP c-client 2004g gives no problem. This could be seen as a DUP of #37948 and #38941, but it is still present in 5.2.0 ... Actual result: -- /bin/sh /opt/install/widexs_apache_2006_017/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/imap/ -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/ -DPHP_ATOM_INC -I/opt/install/widexs_apache_2006_017/php-5.2.0/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/main -I/opt/install/widexs_apache_2006_017/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/ssl/include -I/usr/local/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/date/lib -I/usr/include/freetype2 -I/opt/install/widexs_apache_2006_017/imap-2006c1/c-client -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/oniguruma -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/mysql/include/mysql -I/usr/local/pgsql/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/TSRM -I/opt/install/widexs_apache_2006_017/php-5.2.0/Zend-I/usr/include -g -O2 -c /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c -o ext/imap/php_imap.lo /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' -- Edit this bug report at http://bugs.php.net/?id=39401&edit=1
#39401 [Opn]: conflicting types for utf8_mime2text
ID: 39401 User updated by: wouter at widexs dot nl Reported By: wouter at widexs dot nl Status: Open Bug Type: IMAP related Operating System: Linux PHP Version: 5.2.0 New Comment: This patch fixes my problem ... --- php-5.2.0/configure Wed Nov 1 03:01:06 2006 +++ php-5.2.0-fix/configure Tue Nov 7 20:55:02 2006 @@ -45673,10 +45673,12 @@ rm -f conftest* +old_CPPFLAGS=$CPPFLAGS + CPPFLAGS=-I$IMAP_INC_DIR cat > conftest.$ac_ext < +#include "mail.h" EOF if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | egrep "mail_append_set" >/dev/null 2>&1; then @@ -45690,7 +45692,8 @@ fi rm -f conftest* - +CPPFLAGS=$old_CPPFLAGS + old_CPPFLAGS=$CPPFLAGS CPPFLAGS=-I$IMAP_INC_DIR cat > conftest.$ac_ext < to #include "$IMAP_INC_DIR/mail.h" It correctly works... -------- [2006-11-07 18:49:33] wouter at widexs dot nl It hasn't ... php-5.2.0/main/php_config.h:/* #undef HAVE_NEW_MIME2TEXT */ [2006-11-07 17:09:03] [EMAIL PROTECTED] Can you see if HAVE_NEW_MIME2TEXT is defined inside PHP's main.h ? ---- [2006-11-06 18:25:37] wouter at widexs dot nl Yes, it does :) grep "mail_append_set" src/c-client/mail.h SEARCHSET *mail_append_set (SEARCHSET *set,unsigned long msgno); [2006-11-06 17:01:26] [EMAIL PROTECTED] Does your imap's mail.h header contain the mail_append_set() function? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/39401 -- Edit this bug report at http://bugs.php.net/?id=39401&edit=1
#39401 [Bgs->Opn]: conflicting types for utf8_mime2text
ID: 39401 User updated by: wouter at widexs dot nl Reported By: wouter at widexs dot nl -Status: Bogus +Status: Open Bug Type: IMAP related Operating System: Linux -PHP Version: 5.2.0 +PHP Version: 4.4.4 New Comment: This was indeed fixed when using full-path, BUT it is still present in PHP 4.4.4 and PHP4-dev. (bugfix from 5.x not backported to 4.x) Previous Comments: [2006-11-07 20:53:18] [EMAIL PROTECTED] It works just fine here as long as the fullpath to the library is specified ala /usr/local/imap-2006c [2006-11-07 19:58:52] wouter at widexs dot nl This patch fixes my problem ... --- php-5.2.0/configure Wed Nov 1 03:01:06 2006 +++ php-5.2.0-fix/configure Tue Nov 7 20:55:02 2006 @@ -45673,10 +45673,12 @@ rm -f conftest* +old_CPPFLAGS=$CPPFLAGS + CPPFLAGS=-I$IMAP_INC_DIR cat > conftest.$ac_ext < +#include "mail.h" EOF if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | egrep "mail_append_set" >/dev/null 2>&1; then @@ -45690,7 +45692,8 @@ fi rm -f conftest* - +CPPFLAGS=$old_CPPFLAGS + old_CPPFLAGS=$CPPFLAGS CPPFLAGS=-I$IMAP_INC_DIR cat > conftest.$ac_ext < to #include "$IMAP_INC_DIR/mail.h" It correctly works... -------- [2006-11-07 18:49:33] wouter at widexs dot nl It hasn't ... php-5.2.0/main/php_config.h:/* #undef HAVE_NEW_MIME2TEXT */ [2006-11-07 17:09:03] [EMAIL PROTECTED] Can you see if HAVE_NEW_MIME2TEXT is defined inside PHP's main.h ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/39401 -- Edit this bug report at http://bugs.php.net/?id=39401&edit=1
#41346 [NEW]: segmentation fault on domxml_document_parser
From: wouter at widexs dot nl Operating system: Linux PHP version: 4.4.7 PHP Bug Type: *XML functions Bug description: segmentation fault on domxml_document_parser Description: PHP 4.4.7 as Apache 2.0.59 DSO module gives a segmentation fault when parsing specific xml code. I've been unable to locate the exact code as of yet that triggers this. (since multiple clients use the piece of code i found in the backtrace) A 'bt full' is also available, which might reveal more info for you. I've disabled any Zend + 3rd-party extensions, thus only PHP-only extensions built-in. Reproduce code: --- Don't have it, though it has to be something like this : #16 0xb75b8952 in domxml_document_parser (mode=144905360, loadtype=0, source=0x8ac77e4 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>\r\nhttp://www.w3.org/1999/xhtml\";>\r\nhttp://gmpg.org/x";..., data=0x0) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4006 Which is used in WordPress CMS if I'm correct. Expected result: No segmentation fault :) Actual result: -- backtrace : (gdb) bt #0 0xb7a21df3 in free () from /lib/libc.so.6 #1 0xb6faf788 in xmlResetError__internal_alias (err=0xbfd65360) at error.c:871 #2 0xb6faeb94 in __xmlRaiseError (schannel=0, channel=0xb75b2ebc , data=0xbfd651e0, ctx=0xbfd651e0, nod=0x8ae0ee8, domain=23, code=504, level=XML_ERR_ERROR, file=0x0, line=-2147483636, str1=0x8b247f8 "ul", str2=0x8b247f8 "ul", str3=0xbfd62690 "()", int1=35, col=1, msg=0xb70706a0 "Element %s content does not follow the DTD, expecting %s, got %s\n") at error.c:534 #3 0xb6fda6f8 in xmlErrValidNode (ctxt=0x23, node=0x8ae0ee8, error=XML_DTD_CONTENT_MODEL, msg=0xb70706a0 "Element %s content does not follow the DTD, expecting %s, got %s\n", str1=0xb7adc4a4 "", str2=0xbfd63a20 "(li)+", str3=0xbfd62690 "()") at valid.c:152 #4 0xb6fe0763 in xmlValidateElementContent (ctxt=0x8a314fc, child=0x8ae0f38, elemDecl=0xbfd62690, warn=1, parent=0x8ae0ee8) at valid.c:5366 #5 0xb6fe15f6 in xmlValidateOneElement__internal_alias (ctxt=0x8a314fc, doc=0x8ae0f38, elem=0x8ae0ee8) at valid.c:6052 #6 0xb705b5d4 in xmlSAX2EndElementNs__internal_alias (ctx=0x8a31490, localname=0x8b06f4a "ul", prefix=0x0, URI=0x8b06ddf "http://www.w3.org/1999/xhtml";) at SAX2.c:2315 #7 0xb6fbf56e in xmlParseEndTag2 (ctxt=0x8a31490, prefix=0x0, URI=0x8b06ddf "http://www.w3.org/1999/xhtml";, line=28, nsNr=0, tlen=0) at parser.c:8207 #8 0xb6fbff9d in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8542 #9 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #10 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #11 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #12 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #13 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #14 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #15 0xb6fc1133 in xmlParseDocument__internal_alias (ctxt=0x8a31490) at parser.c:9129 #16 0xb75b8952 in domxml_document_parser (mode=144905360, loadtype=0, source=0x8ac77e4 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>\r\nhttp://www.w3.org/1999/xhtml\";>\r\nhttp://gmpg.org/x";..., data=0x0) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4006 #17 0xb75b8a46 in zif_xmldoc (ht=2, return_value=0x8a31264, this_ptr=0x0, return_value_used=1) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4042 #18 0xb76d576a in execute (op_array=0x8a9ee10) at /opt/install/widexs_apache_2006_026/php-4.4.7/Zend/zend_execute.c:1681 #19 0xb76d551c in execute (op_array=0x8a40960) at /opt/install/widexs_apache_2006_026/php-4.4.7/Zend/zend_execute.c:1725 #20 0xb76d551c in execute (op_array=0x8984534) at /opt/install/widexs_apache_2006_026/php-4.4.7/Zend/zend_execute.c:1725 #21 0xb76c8fbf in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /opt/install/widexs_apache_2006_026/php-4.4.7/Zend/zend.c:939 #22 0xb76a4068 in php_execute_script (primary_file=0xbfd6ab70) at /opt/install/widexs_apache_2006_026/php-4.4.7/main/main.c:1757 #23 0xb76d96a7 in php_handler (r=0x8978608) at /opt/install/widexs_apache_2006_026/php-4.4.7/sapi/apache2handler/sapi_apache2.c:581 #24 0x080af902 in ap_run_handler () #25 0x080b0071 in ap_invoke_handler () #26 0x0809050d in ap_process_request () #27 0x0808a977 in ap_process_http_connection () #28 0x080bc422 in ap_run_process_connection () #29 0x080bc810 in ap_process_connection () #30 0x080ae19f in child_main () #31 0x080ae329 in make_child () #32 0x080ae39e in startup_children ()
#41346 [Fbk->Opn]: segmentation fault on domxml_document_parser
ID: 41346 User updated by: wouter at widexs dot nl Reported By: wouter at widexs dot nl -Status: Feedback +Status: Open Bug Type: *XML functions Operating System: Linux PHP Version: 4.4.7 New Comment: I've updated libxml2 (2.6.28), so I'll monitor for a while if the segmentation faults still occur. However, still weird that 4.4.6 did never give these segmentation faults, and 4.4.7 is compiled against the same libxml2 version (2.6.23, bit old perhaps) Previous Comments: [2007-05-10 13:22:00] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. You might want to try a newer libxml2 version as it looks like the crash might be caused there. (cant be sure without a reproduceable case though) [2007-05-10 07:53:07] wouter at widexs dot nl Description: PHP 4.4.7 as Apache 2.0.59 DSO module gives a segmentation fault when parsing specific xml code. I've been unable to locate the exact code as of yet that triggers this. (since multiple clients use the piece of code i found in the backtrace) A 'bt full' is also available, which might reveal more info for you. I've disabled any Zend + 3rd-party extensions, thus only PHP-only extensions built-in. Reproduce code: --- Don't have it, though it has to be something like this : #16 0xb75b8952 in domxml_document_parser (mode=144905360, loadtype=0, source=0x8ac77e4 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>\r\nhttp://www.w3.org/1999/xhtml\";>\r\nhttp://gmpg.org/x";..., data=0x0) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4006 Which is used in WordPress CMS if I'm correct. Expected result: No segmentation fault :) Actual result: -- backtrace : (gdb) bt #0 0xb7a21df3 in free () from /lib/libc.so.6 #1 0xb6faf788 in xmlResetError__internal_alias (err=0xbfd65360) at error.c:871 #2 0xb6faeb94 in __xmlRaiseError (schannel=0, channel=0xb75b2ebc , data=0xbfd651e0, ctx=0xbfd651e0, nod=0x8ae0ee8, domain=23, code=504, level=XML_ERR_ERROR, file=0x0, line=-2147483636, str1=0x8b247f8 "ul", str2=0x8b247f8 "ul", str3=0xbfd62690 "()", int1=35, col=1, msg=0xb70706a0 "Element %s content does not follow the DTD, expecting %s, got %s\n") at error.c:534 #3 0xb6fda6f8 in xmlErrValidNode (ctxt=0x23, node=0x8ae0ee8, error=XML_DTD_CONTENT_MODEL, msg=0xb70706a0 "Element %s content does not follow the DTD, expecting %s, got %s\n", str1=0xb7adc4a4 "", str2=0xbfd63a20 "(li)+", str3=0xbfd62690 "()") at valid.c:152 #4 0xb6fe0763 in xmlValidateElementContent (ctxt=0x8a314fc, child=0x8ae0f38, elemDecl=0xbfd62690, warn=1, parent=0x8ae0ee8) at valid.c:5366 #5 0xb6fe15f6 in xmlValidateOneElement__internal_alias (ctxt=0x8a314fc, doc=0x8ae0f38, elem=0x8ae0ee8) at valid.c:6052 #6 0xb705b5d4 in xmlSAX2EndElementNs__internal_alias (ctx=0x8a31490, localname=0x8b06f4a "ul", prefix=0x0, URI=0x8b06ddf "http://www.w3.org/1999/xhtml";) at SAX2.c:2315 #7 0xb6fbf56e in xmlParseEndTag2 (ctxt=0x8a31490, prefix=0x0, URI=0x8b06ddf "http://www.w3.org/1999/xhtml";, line=28, nsNr=0, tlen=0) at parser.c:8207 #8 0xb6fbff9d in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8542 #9 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #10 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #11 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #12 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #13 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #14 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #15 0xb6fc1133 in xmlParseDocument__internal_alias (ctxt=0x8a31490) at parser.c:9129 #16 0xb75b8952 in domxml_document_parser (mode=144905360, loadtype=0, source=0x8ac77e4 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>\r\nhttp://www.w3.org/1999/xhtml\";>\r\nhttp://gmpg.org/x";..., data=0x0) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4006 #17 0xb75b8a46 in zif_xmldoc (ht=2, return_value=0x8a31264, this_ptr=0
#41346 [Fbk->Csd]: segmentation fault on domxml_document_parser
ID: 41346 User updated by: wouter at widexs dot nl Reported By: wouter at widexs dot nl -Status: Feedback +Status: Closed Bug Type: *XML functions Operating System: Linux PHP Version: 4.4.7 New Comment: Haven't seen a segmentation fault since the upgrade of libxml2. Still strange it didn't occur with PHP 4.4.6 Previous Comments: [2007-05-11 11:52:02] wouter at widexs dot nl I've updated libxml2 (2.6.28), so I'll monitor for a while if the segmentation faults still occur. However, still weird that 4.4.6 did never give these segmentation faults, and 4.4.7 is compiled against the same libxml2 version (2.6.23, bit old perhaps) [2007-05-10 13:22:00] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. You might want to try a newer libxml2 version as it looks like the crash might be caused there. (cant be sure without a reproduceable case though) [2007-05-10 07:53:07] wouter at widexs dot nl Description: PHP 4.4.7 as Apache 2.0.59 DSO module gives a segmentation fault when parsing specific xml code. I've been unable to locate the exact code as of yet that triggers this. (since multiple clients use the piece of code i found in the backtrace) A 'bt full' is also available, which might reveal more info for you. I've disabled any Zend + 3rd-party extensions, thus only PHP-only extensions built-in. Reproduce code: --- Don't have it, though it has to be something like this : #16 0xb75b8952 in domxml_document_parser (mode=144905360, loadtype=0, source=0x8ac77e4 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>\r\nhttp://www.w3.org/1999/xhtml\";>\r\nhttp://gmpg.org/x";..., data=0x0) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4006 Which is used in WordPress CMS if I'm correct. Expected result: No segmentation fault :) Actual result: -- backtrace : (gdb) bt #0 0xb7a21df3 in free () from /lib/libc.so.6 #1 0xb6faf788 in xmlResetError__internal_alias (err=0xbfd65360) at error.c:871 #2 0xb6faeb94 in __xmlRaiseError (schannel=0, channel=0xb75b2ebc , data=0xbfd651e0, ctx=0xbfd651e0, nod=0x8ae0ee8, domain=23, code=504, level=XML_ERR_ERROR, file=0x0, line=-2147483636, str1=0x8b247f8 "ul", str2=0x8b247f8 "ul", str3=0xbfd62690 "()", int1=35, col=1, msg=0xb70706a0 "Element %s content does not follow the DTD, expecting %s, got %s\n") at error.c:534 #3 0xb6fda6f8 in xmlErrValidNode (ctxt=0x23, node=0x8ae0ee8, error=XML_DTD_CONTENT_MODEL, msg=0xb70706a0 "Element %s content does not follow the DTD, expecting %s, got %s\n", str1=0xb7adc4a4 "", str2=0xbfd63a20 "(li)+", str3=0xbfd62690 "()") at valid.c:152 #4 0xb6fe0763 in xmlValidateElementContent (ctxt=0x8a314fc, child=0x8ae0f38, elemDecl=0xbfd62690, warn=1, parent=0x8ae0ee8) at valid.c:5366 #5 0xb6fe15f6 in xmlValidateOneElement__internal_alias (ctxt=0x8a314fc, doc=0x8ae0f38, elem=0x8ae0ee8) at valid.c:6052 #6 0xb705b5d4 in xmlSAX2EndElementNs__internal_alias (ctx=0x8a31490, localname=0x8b06f4a "ul", prefix=0x0, URI=0x8b06ddf "http://www.w3.org/1999/xhtml";) at SAX2.c:2315 #7 0xb6fbf56e in xmlParseEndTag2 (ctxt=0x8a31490, prefix=0x0, URI=0x8b06ddf "http://www.w3.org/1999/xhtml";, line=28, nsNr=0, tlen=0) at parser.c:8207 #8 0xb6fbff9d in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8542 #9 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #10 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #11 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #12 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #13 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #14 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #15 0xb6fc1133 in xmlParseDocument__internal_alias (ctxt=0x8a31490) at parser.c:9129 #16 0xb75b8952 in domxml_document_parser (mode=144905360, loadtype=0, source=0x8ac77e4 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\&q
