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

go to bug id or search bugs for

Bug #54918 browscap issues
Submitted: 2011-05-24 17:01 UTC Modified: 2011-06-03 02:49 UTC
Votes:4
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: neweracracker at gmail dot com Assigned: cataphract (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.3SVN-2011-05-24 (snap) OS: Windows 7
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2011-05-24 17:01 UTC] neweracracker at gmail dot com 
Description:
------------
Hello,

I've downloaded PHP 5.3 revision 311383 TS from windows.php.net/snapshots/ I have managed to reproduce a crash using nginx and php fcgi related to browscap.

It works flawless prior to this commit svn.php.net/viewvc?view=revision&revision=310691 but new versions crash

How to reproduce.
1. Use php.ini-production as your php.ini
2. Uncomment browscap in php.ini
3. Set it to a valid ini file ( for example: lite_php_browscap.ini from browsers.garykeith.com/downloads.asp )
4. Run the test script
5. Enjoy the crash ;)

Please reproduce and fix.
Thank you.

Test script:
---------------
<?php
phpinfo();
?>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-25 00:09 UTC] felipe@php.net
-Status: Open +Status: Feedback
 [2011-05-25 00:09 UTC] felipe@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
 [2011-05-25 01:26 UTC] neweracracker at gmail dot com 
I tried reproducing this in CLI and it didn't reproduced. Trying with CGI sapi did cause a crash. (using revision 311390)

Thread 0 - System ID 5276
Entry point	  php_cgi!mainCRTStartup
Create time	  25-05-2011 00:18:58
Time spent in user mode	  0 Days 0:0:0.31
Time spent in kernel mode	  0 Days 0:0:0.78



Function	    Arg 1	    Arg 2	    Arg 3	  Source
php5ts!zm_deactivate_browscap+11	    00000001	    00000013	    01372998	  
php5ts!zm_deactivate_basic+15e	    00000001	    00000013	    01372998	  
php5ts!module_registry_cleanup+1b	    00ce41a0	    01372998	    01372998	  
php5ts!zend_hash_reverse_apply+3f	    5f97d580	    5f3f66c0	    01372998	  
php5ts!zend_deactivate_modules+61	    01372998	    00000005	    01372998	  
php5ts!php_request_shutdown+235	    00000000	    013ca4c8	    00000001	  
php_cgi!main+e89	    00000005	    01372878	    01371cd8	  
php_cgi!memset+160	    7ffd8000	    008df9b4	    77c7b459	  
kernel32!BaseThreadInitThunk+e	    7ffd8000	    779f3b4d	    00000000	  
ntdll!__RtlUserThreadStart+70	    013c6a7a	    7ffd8000	    00000000	  
ntdll!_RtlUserThreadStart+1b	    013c6a7a	    7ffd8000	    00000000	  



 PHP5TS!ZM_DEACTIVATE_BROWSCAP+11In php-cgi__PID__3272__Date__05_25_2011__Time_12_21_19AM__599__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5ts!zm_deactivate_browscap+11 in J:\server\bin\php53\php5ts.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x080049a4 on thread 0
 [2011-05-25 01:35 UTC] neweracracker at gmail dot com
-Status: Feedback +Status: Open
 [2011-05-25 01:35 UTC] neweracracker at gmail dot com 
Changing status to open
 [2011-05-25 13:02 UTC] cataphract@php.net
-Assigned To: +Assigned To: cataphract
 [2011-05-25 13:02 UTC] cataphract@php.net 
I'm assigning to me; it's likely related to the changes I've made recently.
 [2011-06-01 12:59 UTC] cataphract@php.net
-Status: Assigned +Status: Feedback
 [2011-06-01 12:59 UTC] cataphract@php.net 
I can't reproduce this.

I've tried 5.3.7-dev (after svn update) on Linux both as a CGI (non-TS) ran under mod_fcgid and Apache module (TS) with worker MPM. I tried setting the browscap ini directive on php.ini, on httpd.conf and on both simultaneously.

I've also tried the latest PHP 5.3.7-dev snapshot binaries (311680) on Windows, TS version, with fcgi and nginx. Setting browscap in php.ini worked as expected; no crash.

Could you please try the latest SVN and/or give more details on your setup?
 [2011-06-01 16:09 UTC] neweracracker at gmail dot com
-Status: Feedback +Status: Assigned
 [2011-06-01 16:09 UTC] neweracracker at gmail dot com 
I can still reproduce the bug so I'll give details about configuration.

nginx.conf: http://pastebin.com/raw.php?i=iv0tvMjA
fastcgi_params: http://pastebin.com/raw.php?i=DZzhi3q2
php.ini: http://pastebin.com/raw.php?i=1betfPER
lite_php_browscap.ini: http://pastebin.com/raw.php?i=M0P1WUuk
 [2011-06-02 22:22 UTC] neweracracker at gmail dot com 
I've found why this happens. 

lite_php_browscap.ini is not in php.ini dir. I've also looked at php_errors.log and it says.

[02-Jun-2011 17:17:30] PHP Warning:  Cannot open 'lite_php_browscap.ini' for reading in Unknown on line 0

And after that it crashes with backtrace above.
 [2011-06-02 22:26 UTC] neweracracker at gmail dot com 
If I put the full path to lite_php_browscap.ini it no longer crashes.
 [2011-06-03 02:42 UTC] scottmac@php.net 
Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=311745
Log: Fix Bug #54918 - Crash when there is a failure to read the browscap file
 [2011-06-03 02:49 UTC] scottmac@php.net
-Status: Assigned +Status: Closed
 [2011-06-03 02:49 UTC] scottmac@php.net 
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 [2011-06-03 03:44 UTC] scottmac@php.net 
Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=311748
Log: Further fix for #54918 - We attach a bunch of submodules loading to the basic MINIT, but if an error occurs during their MINIT we still call the MSHUTDOWN()

Other possible fix is that we should halt execution entirely when this happens but this feels a little drastic.

Committing to trunk for now
 [2011-06-03 11:39 UTC] cataphract@php.net 
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=311764
Log: Merge of fix for bug #54918 (r311745, scottmac) to 5.3.
 [2012-04-18 09:50 UTC] laruence@php.net 
Automatic comment on behalf of scottmac
Revision: http://git.php.net/?p=php-src.git;a=commit;h=974c3b49818ef161ef213599c72afccff9f40867
Log: Fix Bug #54918 - Crash when there is a failure to read the browscap file
 [2012-07-24 23:41 UTC] rasmus@php.net 
Automatic comment on behalf of scottmac
Revision: http://git.php.net/?p=php-src.git;a=commit;h=974c3b49818ef161ef213599c72afccff9f40867
Log: Fix Bug #54918 - Crash when there is a failure to read the browscap file
 [2013-11-17 09:37 UTC] laruence@php.net 
Automatic comment on behalf of scottmac
Revision: http://git.php.net/?p=php-src.git;a=commit;h=974c3b49818ef161ef213599c72afccff9f40867
Log: Fix Bug #54918 - Crash when there is a failure to read the browscap file
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Apr 28 21:01:29 2024 UTC