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

go to bug id or search bugs for

Bug #6375 php.exe Eception: access violation(0xc0000005), Address: 0x1007cefa
Submitted: 2000-08-27 07:35 UTC Modified: 2000-12-02 09:05 UTC
From: peter at helpnet dot com dot au Assigned:
Status: Closed Package: Session related
PHP Version: 4.0.1pl2 OS: NT 4.0 SP6a
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: peter at helpnet dot com dot au
New email:
PHP Version: OS:

 

 [2000-08-27 07:35 UTC] peter at helpnet dot com dot au 
I converted a PHP3 test site to PHP4 on my NT workstation.
Apache, PHP4 and MySQL ran for a week without error then started this access error today.

Using Opera 4.02, php.exe dumps then goes away and I can use the system. Using Netscape 4.08, NT goes in to a CPU loop. The index page uses frames so may work slightly different in Netscape and Opera. I looked in the task manager when NT was 100% CPU busy and found 2 php.exe tasks listed. I could not cancel either task and could not get NT to reboot. I had to do the "old big thumb on hardware reset button".

The only change to the system today was to delete StarOffice 5.1 and install 5.2.

Just before the error, I had the site successfully using PHP4 sessions based on MySQL and had deleted PHPLIB.

PHP4 is running as cgi.

The php.ini is almost 100% default as supplied. A week ago I added an include directory, changed error reporting to E_ALL, expanded script memory to 8Mb and changed session.save_handler to user.

Yesterday I added ldap.dll then took it out after the first few access errors.

The error is the same with dlls in winnt/system32 or in cgi-bin.

Although neither changed between PHP working and PHP failing, I will have a look for an updated Apache and an updated MySQL.

I will also try commenting out recent code. I had an access violation with PHP3 that turned out to be funny code in PHPLIB. It was writtten in an obtuse form so I clarrified the code then put in extra error checking (isset etc.). That made that error go away. I already have careful variable status checking in the new code so it is unlikely to be that sort of error.

I also tried with the Internet disconnected in case it was picking up something from a link to the production site. No change in the error.

Thats it. Everything else is installed straight out of the box with not extras turned on.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-08-27 20:12 UTC] peter at helpnet dot com dot au 
If I comment out session_start() and some variable registrations, the error does not happen.

Experimenting with commenting lines in and out suggests the problem is after the session read function and at about the point where the cookie would be written.
 [2000-08-27 23:33 UTC] peter at helpnet dot com dot au 
I found a possible cause. I used session_save_path() to pass the database name to the session functions. The result was a non string. session_save_path() would print correctly some times and failed others. In the end I found I could reliably access session_save_path() via strval(session_save_path()).

I threw out session_save_path and just set a global variable.

When session_save_path() printed, it always printed the right value. There were no mystery characters. Perhaps print performs the equivalent to strval().

Session_save_path() seemed to corrupt when passed as a value to a function or to another variable. Sometimes it would blow up the first function it passed to (in this case a generic db_read() function) and sometimes it would blow up a function inside the db_read() function, usually the mysql_select_db.

When I inserted diagnostic print statements, I could print the database name from session_save_path() but not the value received by db_read().

PS, if you edit this entry, please insert the x in Eception in the Short Desc. then remove this PS.
 [2000-10-11 06:38 UTC] jmoore@php.net 
Reassigning to Session Related according to user feedback
 [2000-12-02 09:05 UTC] sas@php.net 
PHP 4.0.1pl1 shipped with broken handling of all INI-related functions (i.e. session_save_path()). This has been fixed in PHP 4.0.3.

Thanks for using PHP.
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved. 		Last updated: Sat Mar 14 13:00:01 2026 UTC