Server crashes when accessing any PHP Web page after upgrade to 8.5

hcl-bot · January 14, 2009, 3:38am

Since upgrading from Domino 8.0.2 to 8.5, we have been unable to access PHP pages without crashing the server. This crash happens as soon as any PHP page is accessed and happens on two different servers. The servers are running on Win 2003 SP2. This worked fine for years under previous versions of Domino.

PHP Version: 02 Nov 2006, PHP 5.2.0

Thanks for any guidance.

SteveDavis@eworldes.com

Following is some of the crash information from the fault analyzer and nsd file:

Name: ewWeb/Eworldes

Notes/Domino Version: Release 8.5 HF1 December 29, 2008

Machine Name: EWORLDES2010

OS Version: Windows/2003 5.2 [32-bit]

Start Time: 01/13/2009 05:53:29 PM

Crash Time: 01/13/2009 05:56:13 PM

Uptime: 0 day(s) 00:02:44

Outage Length: 0 day(s) 00:03:21

Error message: ACCESS_VIOLATION

Process: nHTTP

Process List:

E:\Lotus\Domino\nserver.exe

E:\Lotus\Domino\nevent.EXE

E:\Lotus\Domino\nUpdate.EXE

E:\Lotus\Domino\nReplica.EXE

E:\Lotus\Domino\nRouter.EXE

E:\Lotus\Domino\nAMgr.EXE

E:\Lotus\Domino\nAdminp.EXE

E:\Lotus\Domino\nHTTP.EXE

E:\Lotus\Domino\nprocmon.EXE

E:\Lotus\Domino\nAMgr.EXE

E:\Lotus\Domino\nmtc.EXE

E:\Lotus\Domino\nCldbdir.EXE

E:\Lotus\Domino\nClrepl.EXE

Callstack: strncpy

HTCgiScriptRequest::CreateEnvp

HTCgiScriptRequest::CreateContext

HTRequestExtContainer::ProcessRequest

HTRequest::ProcessRequest

HTSession::StartRequest

HTWorkerThread::CheckForWork

HTWorkerThread::ThreadMain

ThreadWrapper

############################################################

FATAL THREAD 22/61 [ nHTTP: 119c: 1880]

FP=0x0bb0f750, PC=0x7c3427cc, SP=0x0bb0c6d0

stkbase=0bb10000, total stksize=262144, used stksize=14640

EAX=0x00000000, EBX=0xffffffff, ECX=0x3ffe8ed9, EDX=0x00007068

ESI=0x08d23f28, EDI=0x08d81000, CS=0x0000001b, SS=0x00000023

DS=0x00000023, ES=0x00000023, FS=0x0000003b, GS=0x00000000 Flags=0x00010202

Exception code: c0000005 (ACCESS_VIOLATION)

############################################################

[ 1] 0x7c3427cc MSVCR71.strncpy+265 (0,0,1,8d23c10)

@[ 2] 0x100021d2 nhttpstack.HTCgiScriptRequest::CreateEnvp+34 (8d235e0,10003531,3,8d23748)

@[ 3] 0x100029c7 nhttpstack.HTCgiScriptRequest::CreateContext+39 (8d23748,8d235e0,0,bb0f9a4)

@[ 4] 0x10011a8a nhttpstack.HTRequestExtContainer::ProcessRequest+1050 (6,1,8d21fb4,0)

@[ 5] 0x10021f5f nhttpstack.HTRequest::ProcessRequest+1919 (0,1a82243,0,646e692f)

@[ 6] 0x10027971 nhttpstack.HTSession::StartRequest+897 (1a8224f,1a82243,0,5fc)

@[ 7] 0x1002ee9f nhttpstack.HTWorkerThread::CheckForWork+399 (1a22ee8,1a82243,3,1002b91a)

@[ 8] 0x1002f3f8 nhttpstack.HTWorkerThread::ThreadMain+88 (1a82243,0,0,0)

@[ 9] 0x600fe6ef nnotes.ThreadWrapper@4+175 (0)

[10] 0x77e64829 kernel32.GetModuleHandleA+223

############################################################

PASS 2 : FATAL THREAD with STACK FRAMES 22/61 [ nHTTP: 119c: 1880]

FP=0bb0f750, PC=7c3427cc, SP=0bb0c6d0

stkbase=0bb10000, total stksize=262144, used stksize=14640

Exception code: c0000005 (ACCESS_VIOLATION)

############################################################

Disassembly of c. 10 instructions before and after faulting address 7c3427cc:



    7c3427b2 81e2ff000000     and     edx,0xff

    7c3427b8 8917             mov     [edi],edx                 ds:08d81000=????????

    7c3427ba eb04             jmp     7c3427c0

    7c3427bc 33d2             xor     edx,edx

    7c3427be 8917             mov     [edi],edx                 ds:08d81000=????????

    7c3427c0 83c704           add     edi,0x4

    7c3427c3 33c0             xor     eax,eax

    7c3427c5 83e901           sub     ecx,0x1

    7c3427c8 740c             jz      7c3427d6

    7c3427ca 33c0             xor     eax,eax

FAULT ->7c3427cc 8907 mov [edi],eax ds:08d81000=???

    7c3427ce 83c704           add     edi,0x4

    7c3427d1 83e901           sub     ecx,0x1

    7c3427d4 75f6             jnz     7c3428cc

    7c3427d6 83e303           and     ebx,0x3

    7c3427d9 0f8577ffffff     jne     7c342756

    7c3427df 8b442410         mov     eax,[esp+0x10]            ss:0d257217=????????

    7c3427e3 5b               pop     ebx

    7c3427e4 5e               pop     esi

    7c3427e5 5f               pop     edi

    7c3427e6 c3               ret

    7c3427e7 2bd1             sub     edx,ecx

…

############################################################

PASS 3 : FATAL THREAD with PARAMETER DATA 22/61 [ nHTTP: 119c: 1880]

############################################################

[ 1] 0x7c3427cc MSVCR71.strncpy+265 (0)

@[ 2] 0x100021d2 nhttpstack.HTCgiScriptRequest::CreateEnvp+34 (8d235e0)

   Parameter 1:

        08d235e0 E80A0410 00000000 00000000 E035D208 | .... .... .... .5.. |

        08d235f0 00000000 209D2D05 B41FD208 743ED208 | ....  .-. .... t>.. |

@[ 3] 0x100029c7 nhttpstack.HTCgiScriptRequest::CreateContext+39 (8d23748)

   Parameter 1:

        08d23748 A0F10310 00000000 00000000 B41FD208 | .... .... .... .... |

        08d23758 8037D208 EC37D208 1038D208 EC39D208 | .7.. .7.. .8.. .9.. |

@[ 4] 0x10011a8a nhttpstack.HTRequestExtContainer::ProcessRequest+1050 (6)

@[ 5] 0x10021f5f nhttpstack.HTRequest::ProcessRequest+1919 (0)

@[ 6] 0x10027971 nhttpstack.HTSession::StartRequest+897 (1a8224f)

   Parameter 1:

        01a8224f 3CF103                              | <..                 |

        01a82252 10000000 00000000 00010000 00000000 | .... .... .... .... |

        01a82262 00000000 00000000 00000000 00       | .... .... .... .    |

@[ 7] 0x1002ee9f nhttpstack.HTWorkerThread::CheckForWork+399 (1a22ee8)

   Parameter 1:

        01a22ee8 9C110000 B80A0000 453A5C4C 6F747573 | .... .... E:\L otus |

        01a22ef8 5C446F6D 696E6F5C 6E485454 502E4558 | \Dom ino\ nHTT P.EX |

@[ 8] 0x1002f3f8 nhttpstack.HTWorkerThread::ThreadMain+88 (1a82243)

   Parameter 1:

        01a82243 3C2604                              | <&.                 |

        01a82246 10000000 00000000 003CF103 10000000 | .... .... .<.. .... |

        01a82256 00000000 00010000 00000000 00       | .... .... .... .    |

@[ 9] 0x600fe6ef nnotes.ThreadWrapper@4+175 (0)

[10] 0x77e64829 kernel32.GetModuleHandleA+223

hcl-bot · January 14, 2009, 9:39am

Subject: From Development

Thanks for your posting. From what you have given us, we can say this:

This looks like a bug in the cgi processor,

There are no meaningful code changes in the area of the crash between 8 and 85.
There is no call to strncpy from the last function in the stack, so the call stack does not look like it is complete.
The crash looks like an access to an unallocated memory page to the process, possibly an off by one bug.

The bottom line is that this does not look like a new problem. It looks like an existing bug that we now hit because of other memory alignments in the other new code.

Can you please raise a PMR?

hcl-bot · January 14, 2009, 11:52am

Subject: PMR Created

It’s PMR #48096,756 in case you would like to track it.

Thanks

Steve

hcl-bot · January 19, 2009, 5:57am

Subject: I have the same problem wiht PHP page crash domino 8.5

I have a php page on my website that works for months in domino 8.01 server.

I just upgraded my server to 8.5 and now the server crash instantly if you try to open the PHP page.

I also noticed I had 2 crash today wiht no reason.

I have also installed the Traveller module on Domino. Do you have also installed this?

hcl-bot · January 21, 2009, 1:38pm

Subject: Traveler

We do not have traveler installed on the server where we are running our PHP web site.

I also just posted that Lotus has no plans to fix this bug because PHP is not supported on Domino.

Steve

hcl-bot · January 21, 2009, 1:32pm

Subject: Response from Development… PHP is not Supported

Apparently PHP is not supported on Domino there are no plans for fix the bug.

This is quite disappointing because I have been trying to get my company to move more Web applications to Domino and I have been trying to convince other developers Domino can meet all of their needs. I guess I need to find another non-Domino server to run this on.

Steve

hcl-bot · January 23, 2009, 1:43pm

Subject: Pmr is still active

I checked the status of this pmr and we are requesting a sample that we can reproduce the problem with. We do want to fix this because it may not just be related to php. Please follow up with support, core dev wants to fix this. If we can reproduce this we will be able to track it down and fix it. Please have our l2 support re-escalate this issue with any samples that cause the issue

Thanks

hcl-bot · January 28, 2009, 3:51pm

Subject: Followed up with support.

I read you more recent post to the other thread () and am happy to see that this has been SPR’d.

Thanks again for the help.

Steve