#34024 [Opn]: PHP has encountered an Access Violation at 019382DF (ISAPI)

From: Date: Sun, 07 Aug 2005 09:47:51 +0000
Subject: #34024 [Opn]: PHP has encountered an Access Violation at 019382DF (ISAPI)
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-83122@lists.php.net to get a copy of this message
ID: 34024 Updated by: derick@php.net Reported By: andrey at cherezov dot koenig dot su Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: Actually, if you insist on using PHP with IIS, I suggest to use the FastCGI modules instead. Much more stable (no threading required, can never crash your full webserver) and just as fast as the ISAPI module. Previous Comments: ------------------------------------------------------------------------ [2005-08-07 11:44:09] andrey at cherezov dot koenig dot su > So it comes that you can provide some info in addition to > this address,right? :) This address is provided by php5isapi.dll. I hope _it_ can additionally provide more info - print entire exception record, memory dump, stack trace. Just like Dr.Watson on Windows does. In reply to my bugreport #33958 Sniper posted fragment of PHP trace log "[Switching to Thread 46912528940992 (LWP 2360)] 0x00002aaab000aec1 in _mem_block_check (ptr=0x555555b3a081, silent=0, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", ... This means, PHP able write such debug log? When exception occured, the last record in this log points to the faulting code, right? > I doubt I can use it on Linux to get a backtrace or > something useful, so please do provide more info yourself. With pleasure, but PHP should dump it first, and I will send this dump ;) What can I do more? The log of my web-server with the sequence of PHP calls to ISAPI interface I've provided in my first message. In past (bug#33958) such log definitely helped to locate problem - cookies, because the last call from PHP was for HTTP_COOKIE. But in this new bug PHP fetched all ISAPI variables from server w/o exception, so bug is somewhere in the code executing script, and the server can't give more information what happens inside php5isapi.dll code :( Only PHP can do this. ------------------------------------------------------------------------ [2005-08-07 11:14:17] tony2001@php.net So it comes that you can provide some info in addition to this address, right? I doubt I can use it on Linux to get a backtrace or something useful, so please do provide more info yourself. >If you're not interested in ISAPI, just say it. Yes, we are. But in most cases users do not understand that just stating that something is wrong doesn't help. If you can provide more info about it - please do so. >I will switch back to CGI and forget about these bugs. This way you won't get a stable ISAPI module ever. ------------------------------------------------------------------------ [2005-08-07 10:53:25] andrey at cherezov dot koenig dot su 1. The address of exception is not meaningless. When exception happens in my own programs I can easily locate the faulting function because the exception record structure have all required pointers for it, and the call stack is also available to dump at exception moment. Learn from Microsoft ;) 2. And I offered a way to 'catch' any info related to this exception by turn on runtime tracing: I can run the debug version of php5isapi.dll, if you provide one, and I will send you its log when next exception occured. It is obviously and pretty easy to implement. If you'll continue to wave aside such 'unreproducible' issues, you'll never release the stable enough ISAPI module. If you're not interested in ISAPI, just say it. I will switch back to CGI and forget about these bugs. Thank you for help, Good luck, ------------------------------------------------------------------------ [2005-08-07 10:25:32] tony2001@php.net So how do you expect us to fix an issue that is not reproducible and all you can provide about it is a meaningless memory address? ------------------------------------------------------------------------ [2005-08-07 10:14:13] andrey at cherezov dot koenig dot su Tony, this is a random multithreading issue, it is impossible to make 'reproduce script' for this kind of bugs. It requires reproducing the same threads and memory state. ------------------------------------------------------------------------ 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/34024 -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1

« previous php.bugs (#83122) next »