php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #17591 segfault when trying to access a global variable
Submitted: 2002-06-04 06:12 UTC Modified: 2002-10-14 19:39 UTC
From: dschmidt at informationsgesellschaft dot com Assigned:
Status: No Feedback Package: Scripting Engine problem
PHP Version: 4.2.1 OS: Linux (Suse 7.3)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
36 - 35 = ?
Subscribe to this entry?

 
 [2002-06-04 06:12 UTC] dschmidt at informationsgesellschaft dot com
After the Upgrade from php 4.0.6 to php 4.2.1 our Application crashes (httpd segmentation fault)

We used the dgb Debugger (dd.cron.ru) to figure out where it happens:
Inside a function when trying to make a global variable available with the global statement (global $xyz;).

We were not able to reproduce that error inside a short script. It only occurs in our (complex) Application (with a lot of classes) and only under certain circumstances.

after that, we tried to get a backtrace (we followed the guide in http://bugs.php.net/bugs-generating-backtrace.php).
After compiling php with --enable-debug we were not able to reproduce the error. Instead we got a lot of messages in 
the httpd-error_log:
-------------------------
zend_language_scanner.c(4363) :  Freeing 0x0825CDC4 (1 bytes), script=/usr/local/httpd/htdocs/AdditorDev/Website/page.php
Last leak repeated 1 time
./zend_execute.c(1999) :  Freeing 0x081EF674 (12 bytes), script=/usr/local/httpd/htdocs/AdditorDev/Website/page.php
Last leak repeated 3 times
./zend_execute.c(2002) :  Freeing 0x081EF454 (25 bytes), script=/usr/local/httpd/htdocs/AdditorDev/Website/page.php
zend_variables.c(106) : Actual location (location was relayed)
Last leak repeated 1 time
zend_hash.c(260) :  Freeing 0x08493A7C (48 bytes), script=/usr/local/httpd/htdocs/AdditorDev/Website/Additor/XmlConnect.php                   
Last leak repeated 597 times
--------------------------
I don't know what this means.

Our configure-line: 

./configure --enable-sockets --enable-memory-limit --with-mysql --with-apxs --with-xslt-sablot --with-sablot=/usr/local/lib --with-expat=/usr/local/lib --with-ldap --with-debugger --with-ftp --with-config-file-path=/etc/ --enable-trans-sid --enable-track-vars --enable-trans-sid --with-zlib-dir=/usr/lib --with-ming --with-oci8=/opt/oracle/OraHome1 --enable-xslt -enable-debug

thanx

Dirk Schmidt

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-04 06:30 UTC] mfischer@php.net
Are you using objects and circular references?
 [2002-06-04 07:22 UTC] dschmidt at informationsgesellschaft dot com
yes, we use both. We have objects with attributes pointing to other objects. These other objects may have an attribute pointing back to the first object.
 [2002-06-04 08:57 UTC] mfischer@php.net
The zend engine doesn't support circular refereing and never will (hence the memory leaks you see with the debug build). This won't get fixed.

Seems that accessing the global var in your example as you described it is a very negative side effect.

I guess unless you can post a reproduceable example there's nothing we can do about it.
 [2002-06-05 11:15 UTC] dschmidt at informationsgesellschaft dot com
Shouldn't that restriction be documented somewhere?

Can these circular references cause any other problems or errors than in the garbage collection? Would it be a solution to cut off these references in a destructor method before the script ends?

Does the garbage collector call a destructor method for objects?
 [2002-09-09 11:21 UTC] stas@php.net
Circular refernces _are_ supported (meaning, they will work, etc.) but indeed cause 'memory leak' messages. This is not real leaks, because they are cleaned at the end of the request. 
As for the crash - please try to produce some short code that reproduces the problem, or at least refine the circumstances when it happens. Also, you may want to try latest version (4.2.3) or latest CVS snapshot (snaps.php.net). 
 [2002-09-26 20:09 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-10-14 19:39 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 24 11:01:30 2024 UTC