php-windows Digest 6 Jan 2014 03:19:43 -0000 Issue 4180
Topics (messages 31242 through 31249):
Re: Opcache crashes. Was: [PHP-WIN] 64 bit platform improvements
31242 by: Jan Ehrhardt
31243 by: Pierre Joye
31244 by: Pierre Joye
31245 by: Jan Ehrhardt
31246 by: Jan Ehrhardt
31247 by: Jan Ehrhardt
31248 by: Jan Ehrhardt
Re: 64 bit platform improvements
31249 by: Jan Ehrhardt
Administrivia:
To subscribe to the digest, e-mail:
php-windows-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-windows-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-wind...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Pierre Joye in php.windows (Sun, 5 Jan 2014 13:25:25 +0100):
>On Thu, Jan 2, 2014 at 5:16 PM, Jan Ehrhardt <php...@ehrhardt.nl> wrote:
>> With the debugging tools I cannot even get a backtrace. There are no
>> segfaults just an end of script before the headers. So any tool that is
>> monitoring segfaults does not notice anything. Do you have any tips how
>> I can get a backtrace anyway?
...
>See https://bugs.php.net/bugs-generating-backtrace-win32.php to at
>least generate a backtrace :)
Neither VS (2008, 2010 and 2012 installed here) nor DebugDiag 'fired',
because there were no segfaults. No crash, no core dumps, nothing to
analyze. Just a server error 500 :(
Jan
--- End Message ---
--- Begin Message ---
On Sun, Jan 5, 2014 at 2:15 PM, Jan Ehrhardt <php...@ehrhardt.nl> wrote:
> Pierre Joye in php.windows (Sun, 5 Jan 2014 13:25:25 +0100):
>>On Thu, Jan 2, 2014 at 5:16 PM, Jan Ehrhardt <php...@ehrhardt.nl> wrote:
>>> With the debugging tools I cannot even get a backtrace. There are no
>>> segfaults just an end of script before the headers. So any tool that is
>>> monitoring segfaults does not notice anything. Do you have any tips how
>>> I can get a backtrace anyway?
> ...
>>See https://bugs.php.net/bugs-generating-backtrace-win32.php to at
>>least generate a backtrace :)
>
> Neither VS (2008, 2010 and 2012 installed here) nor DebugDiag 'fired',
> because there were no segfaults. No crash, no core dumps, nothing to
> analyze. Just a server error 500 :(
hm? So there should be some log.
Which webserver do you use?
--
Pierre
@pierrejoye | http://www.libgd.org
--- End Message ---
--- Begin Message ---
On Sun, Jan 5, 2014 at 3:16 PM, Pierre Joye <pierre....@gmail.com> wrote:
> On Sun, Jan 5, 2014 at 2:15 PM, Jan Ehrhardt <php...@ehrhardt.nl> wrote:
>> Pierre Joye in php.windows (Sun, 5 Jan 2014 13:25:25 +0100):
>>>On Thu, Jan 2, 2014 at 5:16 PM, Jan Ehrhardt <php...@ehrhardt.nl> wrote:
>>>> With the debugging tools I cannot even get a backtrace. There are no
>>>> segfaults just an end of script before the headers. So any tool that is
>>>> monitoring segfaults does not notice anything. Do you have any tips how
>>>> I can get a backtrace anyway?
>> ...
>>>See https://bugs.php.net/bugs-generating-backtrace-win32.php to at
>>>least generate a backtrace :)
>>
>> Neither VS (2008, 2010 and 2012 installed here) nor DebugDiag 'fired',
>> because there were no segfaults. No crash, no core dumps, nothing to
>> analyze. Just a server error 500 :(
>
> hm? So there should be some log.
>
> Which webserver do you use?
btw you can still hook into a process and save a dump, allowing the
same analysis than a crash dump.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--- End Message ---
--- Begin Message ---
Pierre Joye in php.windows (Sun, 5 Jan 2014 15:16:30 +0100):
>On Sun, Jan 5, 2014 at 2:15 PM, Jan Ehrhardt <php...@ehrhardt.nl> wrote:
>> Neither VS (2008, 2010 and 2012 installed here) nor DebugDiag 'fired',
>> because there were no segfaults. No crash, no core dumps, nothing to
>> analyze. Just a server error 500 :(
>
>hm? So there should be some log.
No segfaults, no firing of VS, nothing with DebugDiag (looking for
crashes), nothing in the Windows event log, nothing in the PHP error
log. Only in the Apache log: "End of script output before headers". It
even happens with only two extensions loaded: php_pdo_mysql.dll and
php_opcache.dll.
>Which webserver do you use?
Apache 2.4.7, does not matter if it is the VC9 or VC11 version. php-cgi
called either trough mod_fcgid or directly.
It just looks like php-cgi.exe flips out with no output at all, not even
the headers.
Jan
--- End Message ---
--- Begin Message ---
Pierre Joye in php.windows (Sun, 5 Jan 2014 15:17:38 +0100):
>On Sun, Jan 5, 2014 at 3:16 PM, Pierre Joye <pierre....@gmail.com> wrote:
>> hm? So there should be some log.
>>
>> Which webserver do you use?
>
>btw you can still hook into a process and save a dump, allowing the
>same analysis than a crash dump.
How do I do that? The php-cgi.exe process stops instantly as soon as the
internal server error occurs. I just checked in the Windows Task
Manager. Before the error a php-cgi.exe *32 with PID 41408. At the
moment of the error it vanishes.
Jan
--- End Message ---
--- Begin Message ---
Jan Ehrhardt in php.windows (Sun, 05 Jan 2014 17:07:46 +0100):
>Pierre Joye in php.windows (Sun, 5 Jan 2014 15:17:38 +0100):
>>btw you can still hook into a process and save a dump, allowing the
>>same analysis than a crash dump.
>
>How do I do that? The php-cgi.exe process stops instantly as soon as the
>internal server error occurs. I just checked in the Windows Task
>Manager. Before the error a php-cgi.exe *32 with PID 41408. At the
>moment of the error it vanishes.
OK, got a ZwTerminateProcess.dmp by tracking the php-cgi.exe PID on
memory leaks and the like. No debug symbols yet, so I will run another
analysis.
Jan
--- End Message ---
--- Begin Message ---
Jan Ehrhardt in php.windows (Sun, 05 Jan 2014 17:25:31 +0100):
>OK, got a ZwTerminateProcess.dmp by tracking the php-cgi.exe PID on
>memory leaks and the like. No debug symbols yet, so I will run another
>analysis.
I cannot get DebugDiag to find the correct symbols. And I do not know
how to do the same in WinDbg. At the moment I have this result. I can
provide more for Dmitry when he returns from his holiday.
Type of Analysis Performed Hang Analysis
Operating System Windows 7Service Pack 1
Process ID 5128
Process Image D:\phpdev\php55pgo.x32\php-cgi.exe
System Up-Time 01:59:56
Process Up-Time 00:02:08
Processor Type X86
Process Bitness 32-Bit
Top 5 Threads by CPU time
Note - Times include both user mode and kernel mode for each thread
Thread ID: 0 Total CPU Time: 00:00:00.452 Entry Point for Thread:
php_cgi+4284
Thread ID: 1 Total CPU Time: 00:00:00.000 Entry Point for Thread:
php_cgi+5490
Thread ID: 2 Total CPU Time: 00:00:00.000 Entry Point for Thread:
msvcr110!_endthreadex+86
Thread ID: 3 Total CPU Time: 00:00:00.000 Entry Point for Thread:
ntdll!TppWaiterpThread
Thread ID: 4 Total CPU Time: 00:00:00.000 Entry Point for Thread:
LeakTrack+e4f0
Thread report
Thread 0 - System ID 5360
Entry point php_cgi+4284
Create time 05/01/14 23:16:18
Time spent in user mode 0 Days 00:00:00.312
Time spent in kernel mode 0 Days 00:00:00.140
This thread is not fully resolved and may or may not be a problem.
Further analysis of these threads may be required.
Function
ntdll!ZwTerminateProcess
ntdll!RtlExitUserProcess+41
kernel32!ExitProcessStub+12
msvcr110!__crtExitProcess+15
msvcr110!_unlockexit+15d
msvcr110!exit+f
php5!zend_mm_get_storage+95
php5!emalloc+609
php_opcache+34e8
Thread 1 - System ID 5972
Entry point php_cgi+5490
Create time 05/01/14 23:16:18
Time spent in user mode 0 Days 00:00:00.000
Time spent in kernel mode 0 Days 00:00:00.000
This thread is not fully resolved and may or may not be a problem.
Further analysis of these threads may be required.
Function
ntdll!ZwWaitForSingleObject+15
KERNELBASE!WaitForSingleObjectEx+98
kernel32!WaitForSingleObjectExImplementation+75
kernel32!WaitForSingleObject+12
php_cgi+549c
ntdll!__RtlUserThreadStart+70
ntdll!_RtlUserThreadStart+1b
Jan
--- End Message ---
--- Begin Message ---
Jan Ehrhardt in php.windows (Thu, 26 Dec 2013 00:58:34 +0100):
>Ontopic again: the bad news is that I am now getting segfaults with the
>experimental builds in Drupal7. I do not know what caused the change
>(might be the upgrade of some Drupal modules). Anyway: opcache in the
>experimental builds now fails for Drupal (not for Wordpress), even if I
>use only 1 opcache. I tried it with your 64-bit build, my 64-bit build
>and my x86 NTS build: all are a no-go now.
A new year, time for the good news. I had the same 'End of script output
before headers' error 500 with PHP 5.7.0-dev (even in the x86 TS
version). Then I applied the same reverse patch on block_pass.c as I did
on the 5.5 and 5.4 sources. And gone was the error. Dmitry now knows
what to do when he is back from his holiday ;-)
I wil test it with the PHP 5.7.0-dev x86 NTS version and for both the
x64 versions as well.
Jan
--- End Message ---
