Opened 13 years ago
Closed 13 years ago
#89 closed defect (worksforme)
crashing with upstream FASTCGI and keepalive (Windows)
Reported by: | joe-rice.myopenid.com | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | nginx-core | Version: | 1.1.x |
Keywords: | Cc: | ||
uname -a: | |||
nginx -V: | nginx version: nginx/1.1.13 |
Description
I set up nginx 1.1.13 to keep the connection to my backend server alive. I put this into production and nginx would only stay up for about 10 or 15 seconds. No errors were reported in the error log. I've attached my nginx.conf file.
Here's the info from the Event Viewer
Faulting application name: nginx.exe, version: 0.0.0.0, time stamp: 0x4f1442c0
Faulting module name: ntdll.dll, version: 6.1.7601.17514, time stamp: 0x4ce7ba58
Exception code: 0xc0000374
Fault offset: 0x000ce653
Faulting process id: 0x12c0
Faulting application start time: 0x01ccdac4bff11e83
Faulting application path: c:\nginx\nginx.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: 0a51b1e5-46b8-11e1-9eec-001999546962
Attachments (2)
Change History (8)
by , 13 years ago
comment:1 by , 13 years ago
Status: | new → accepted |
---|
Could you please provide debug log? Ideally I would also like to see backtrace, but it's not trivial to obtain one under windows.
And some more question:
- Do you see it working ok without upstream keepalive being used?
- Is it works without ssl enabled?
- Is it works if lower number in "keepalive" directive used, say 10? (Using 1000 as in your config isn't really good idea, as only 1024 connections are available in total, for both client connections and upstream ones.)
comment:2 by , 13 years ago
I will try to get this information to you as soon as possible. For the moment I have backed out to version 1.1.11 but I will try 1.1.13 today, without upstream keepalive.
by , 13 years ago
comment:3 by , 13 years ago
I switched back to 1.1.13 with the config file upstream keepalive commented out and it still crashed. I've attached the conf file as bug2.conf. I'm unable to attach the error log as it's 54 MB and there seems to be a 256k limit.
Unfortunately I can't turn off SSL as it's a requirement of the environment I'm working in.
comment:4 by , 13 years ago
Well, I tried it again with 1.1.13 with upstream keepalive disabled and it seems to be working fine now. The only difference from what I tried yesterday that crashed was disabling the debug option in the error log.
I'll try it again as soon as I can with the upstream keepalive stuff enabled but with the number of connections reduced. Since my backend is single-threaded, I'm assuming this won't be a problem, but I must admit, I'm a noob at all this stuff.
comment:5 by , 13 years ago
Is 1.1.11 works for you? Or you mean 1.0.11 instead? The major difference between 1.0.x and 1.1.x windows builds are different openssl versions used (nginx 1.1.x uses openssl 1.0.0x, while nginx 1.0.x still uses openssl 0.9.8x), so I suspect ssl may be a culprit. The r4415 may improve things (it's expected to appear in 1.1.14 soon).
Please make debug log with crash available for download and link it here.
Note well: under Windows 7 the Fault Tolerant Heap (FTH) may prevent crashes. It is necessary to make sure FTH workarounds aren't activated for nginx to make sure problem is really gone with some config.
comment:6 by , 13 years ago
Resolution: | → worksforme |
---|---|
Status: | accepted → closed |
Feedback timeout. Likely this is fixed by the mentioned commit.
Config file