Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
Topic: httpd on vista not as a service - asserts bad file handle |
|
Author |
|
samizdat
Joined: 21 May 2008 Posts: 2 Location: Silicon Valley California
|
Posted: Wed 21 May '08 7:50 Post subject: httpd on vista not as a service - asserts bad file handle |
|
|
I built apache from source for vista (details of what that took below) and it runs when installed as a system service. But when run from the command line or under the debugger it fails at startup in code that's trying to open stdout (file handle 1) - the C runtime asserts (this is a debug version)
stack trace shows these calls:
main()
ap_run_pre_config()
winnt_pre_config()
apr_file_dup2()
_commit(1/*stdout*/)
(C runtime asserts invalid file handle)
anyone else encounter problems running apache on vista not as a service?
I'm going to try the binary release next and see if it has this problem.
In the debug version I built I changed apr.hw as follows:
#define _WIN32_WINNT 0x0600
#define APR_HAVE_IPV6 1
per this previous post:
http://www.apachelounge.com/viewtopic.php?t=2095
which got rid of compile errors for multicast.c.
Also I had to do the cvtdsp.pl fixup to work around the rc.exe errors.
Other than that it was clean InstallBin build under VS2008 (MSVC++ 9.0) using its default windows platform sdk (6.0A)
I used the IDE to build it (not the command line) after going thru the conversion of Apache.dsw to Apache.sln.
It built with no errors, and as I say, it runs as a service. It just can't open stdout. |
|
Back to top |
|
tdonovan Moderator
Joined: 17 Dec 2005 Posts: 611 Location: Milford, MA, USA
|
Posted: Wed 21 May '08 15:03 Post subject: |
|
|
That's been a known problem with debug builds for a long time. It was discussed on the Apache developers mailing list back in 2005.
re: "trying to open stdout" - actually it is trying to commit to stdout (i.e. flush unwritten data to disk). The same usually happens with stderr too.
The most common practice is to comment out these _commit calls for stdout and stderr when building with VS2005 or VS2008.
You should not see the assertion errors with a Release build, and you should be able to click [OK] and continue from them when they appear in a Debug build.
-tom- |
|
Back to top |
|
samizdat
Joined: 21 May 2008 Posts: 2 Location: Silicon Valley California
|
Posted: Thu 22 May '08 3:25 Post subject: |
|
|
Thanks for your prompt reply! I guess I didn't search back far enough on the list, I thought it would be a recent Vista-related thing.
I did need to make debug builds run without asserts, so I can deploy them internally for testing, so I patched the source.
Commenting out the _commit() calls for stdout and stderr in filedup.c got me farther, but I was still getting one last assert, in the child process when it starts up. [Could not for the life of me figure out how to freeze it on start up in the vs2008 debugger to see what was happening - no process to attach to until after the CreateProcessW call, but after that is too late, it's off and running. Do you know a way to do that?]
Finally I commented out the _commit() for stdin as well, and that cured the last assert. Lucky guess.
So (for the record) to make debug builds assert-free at start-up when run not-as-a-service, patch this file:
httpd-2.2.8\srclib\apr\file_io\win32\filedup.c
to suppress these 3 calls in _DEBUG mode:
#ifndef _DEBUG
_commit(2 /* stderr */);
#endif
#ifndef _DEBUG
_commit(1 /* stdout */);
#endif
#ifndef _DEBUG
_commit(0 /* stdin */);
#endif
Thanks again for your hand-holding! |
|
Back to top |
|
tdonovan Moderator
Joined: 17 Dec 2005 Posts: 611 Location: Milford, MA, USA
|
Posted: Thu 22 May '08 7:54 Post subject: |
|
|
In practice the _commit calls are unnecessary for either debug or release builds.
Unlike Unix, Windows makes unwritten data visible to all other processes before the fflush call returns - and the _dup2 call a few lines down will trigger a physical disk write because it implies a _close call on the 2nd argument.
Simpler to just remove the _commit calls entirely.
-tom- |
|
Back to top |
|
|
|
|
|
|