php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #18963 Reproducable crash with simple string functions.
Submitted: 2002-08-19 08:44 UTC Modified: 2002-11-13 01:00 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: si at darkness dot nu Assigned:
Status: No Feedback Package: Scripting Engine problem
PHP Version: 4.3.0-dev OS: IRIX64 6.5.16f IP25
Private report: No CVE-ID: None
View Developer Edit
 [2002-08-19 08:44 UTC] si at darkness dot nu 
I submitted a problem a while ago, which we closed as we attributed it to a bug inside imap c-client.  The results of the crash being very similar to this (often ending in _doprnt() in mdbm.c, indicating bad data being passed into print functions).  I'm now running into this again, this time i'm not touching imap at all however, and the errors are appearing pretty readily in the backtrace as a zend engine error specific to IRIX64 maybe?



#0 0x0fa7bd18 in _doprnt () at mdbm.c:1204
1204 mdbm.c: No such file or directory.
in mdbm.c
(gdb) bt
#0 0x0fa7bd18 in _doprnt () at mdbm.c:1204
#1 0x0faef350 in vsnprintf () at mq_open.c:220
#2 0x1006416c in php_error_cb (type=8,
error_filename=0x104e1150 "/u01/servers/test.darkness.nu/lang/en/lang_post.php", error_lineno=5, format=0x7ffe07d0 "", args=0x7ffe10f0 "") at main.c:414
#3 0x100719e8 in zend_error (type=8,
format=0x102b1238 "Use of undefined constant %s - assumed '%s'")
at zend.c:682
#4 0x100e64f4 in execute (op_array=0x104e1050) at zend_execute.c:1958
#5 0x100e6f8c in execute (op_array=0x10597a68) at zend_execute.c:2141
#6 0x100e4c68 in execute (op_array=0x1054d2b0) at zend_execute.c:1638
#7 0x100e4c68 in execute (op_array=0x104dd1a8) at zend_execute.c:1638
#8 0x100e4c68 in execute (op_array=0x104d9588) at zend_execute.c:1638
#9 0x100e6f8c in execute (op_array=0x10437778) at zend_execute.c:2141
#10 0x10071bc0 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at zend.c:810
#11 0x10066944 in php_execute_script (primary_file=0x7fff2930) at main.c:1381
#12 0x100dea34 in apache_php_module_main (r=0x7fff2930,
display_source_mode=2147428680) at sapi_apache.c:90
#13 0x10062e6c in php_restore_umask ()
#14 0x0fa3a6f4 in fopen64 () at aio.c:317

the first 15  lines of lang_post.en

<?php

$lang = array (

ibf_code_txt => "Roll your mouse over the button for more information.<br>Hitting 'ALT' and 'c' closes current tag",

'unreg_namestuff' => "Unregistered User Info",

mod_options => "After posting...",

mod_close => "Close this topic",
mod_pin   => "Pin this topic",
mod_nowt  => "Don't pin or close",

'msg_no_title' => "You must enter a message title",

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-08-19 08:47 UTC] si at darkness dot nu 
er, en/lang_post.php, not lang_post.en
 [2002-08-19 08:55 UTC] si at darkness dot nu 
# ./configure  --with-mysql=/usr/local/mysql --with-apache=../apache_1.3.26 --with-imap=/usr/freeware --disable-ctype --with-openssl=/usr/freeware/lib/openssl

Configure options.  PHP 4.2.2, Apache 1.3.26, MySQL 3.23.52, IRIX 6.5.16F

Problem manifests itself intermittently, suggestive of heap corruption, so doesn't allow for a simple script which causes the problem to manifest, does occur across multiple machines.
 [2002-08-19 12:58 UTC] rasmus@php.net 
There are a number of 64-bit fixes in current CVS.  Any chance you could grab the latest unstable snapshot from snaps.php.net and try with that?
 [2002-08-19 16:29 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip
 [2002-08-20 00:12 UTC] si at darkness dot nu 
(gdb) bt
#0  0x100f622c in zend_fetch_var_address (opline=0x0, Ts=0x1, type=2147422752)
    at /u02/tardists/apache/php4-200208191500/Zend/zend_execute.c:527
#1  0x10103dfc in execute (op_array=0x10555c10)
    at /u02/tardists/apache/php4-200208191500/Zend/zend_execute.c:1232
#2  0x100ff2d8 in execute (op_array=0x10555808)
    at /u02/tardists/apache/php4-200208191500/Zend/zend_execute.c:1632
#3  0x10101d50 in execute (op_array=0x1055c0e0)
    at /u02/tardists/apache/php4-200208191500/Zend/zend_execute.c:2144
#4  0x10076818 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /u02/tardists/apache/php4-200208191500/Zend/zend.c:812
#5  0x1006a628 in php_execute_script (primary_file=0x7fff2850)
    at /u02/tardists/apache/php4-200208191500/main/main.c:1509
#6  0x100f2c64 in apache_php_module_main (r=0x7fff2850,
    display_source_mode=2147428456)
    at /u02/tardists/apache/php4-200208191500/sapi/apache/sapi_apache.c:55
#7  0x100667a0 in php_restore_umask ()
#8  0x0fa3a6f4 in fopen64 () at aio.c:317

This is using the latest PHP4 snapshot.  I had a few problems compiling it, but I think I got a clean build.

# ./configure  --with-mysql=/usr/local/mysql --with-apache=../apache_1.3.26 --with-imap=/usr/freeware --disable-ctype --with-openssl=/usr/freeware/lib/openssl

Server: Apache/1.3.26 (Unix) PHP/4.3.0-dev mod_ssl/2.8.9 OpenSSL/0.9.6e
 [2002-08-20 10:21 UTC] si at darkness dot nu 
A note from another IRIX admin who looked at this problem:

I note that the problemic address is not null.  It resembles a stack address. In that case, the most frequent cause of the problem is a miscoded procedure that is called and it returns the address of a variable with is on the stack and that stack frame is then released.  If the stack shortens by enough, then the address may become invalid as the kernel releases under some circumstances unneeded stack frames.

Randolph J. Herber, herber@fnal.gov, +1 630 840 2966, CD/CDFTF PK-149F,Mail Stop 318, Fermilab, Kirk & Pine Rds., PO Box 500, Batavia, IL 60510-0500,USA.  (Speaking for myself and not for US, US DOE, FNAL nor URA.)  (Product,trade, or service marks herein belong to their respective owners.)
 [2002-08-20 22:12 UTC] kalowsky@php.net 
what sort of problems did you have compiling this?

Also updating version
 [2002-08-20 23:02 UTC] si at darkness dot nu 
I had problems with a number of apache includes, I had to edit some headers and put in the explicit paths, it didn't seem able to find the proper paths for some headers "os.h, ap_*.h, etc"
 [2002-08-20 23:09 UTC] kalowsky@php.net 
Sounds very suspicious of a bad install of Apache on the headers part.
 [2002-08-21 01:13 UTC] si at darkness dot nu 
I didn't have any problems compiling 4.2.2 or 4.2.1, just the latest snap version gave the problems.  It was easily resolved by putting some full paths in.
 [2002-10-28 11:02 UTC] iliaa@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip
 [2002-11-13 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over 2 weeks, 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".
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 24 10:00:01 2025 UTC