Summary: | sendfile broken with LFS support on HP-UX/PA-RISC32 | ||
---|---|---|---|
Product: | APR | Reporter: | destroyedlolo <laurent.faillie> |
Component: | APR | Assignee: | Apache Portable Runtime bugs mailinglist <bugs> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | cm, hanno.borns |
Priority: | P2 | ||
Version: | 1.2.8 | ||
Target Milestone: | --- | ||
Hardware: | HP | ||
OS: | HP-UX | ||
URL: | intranet web site. | ||
Attachments: | define the _HPUX_SOURCE feature test macro to obtain maximum functionality |
Description
destroyedlolo
2007-04-26 02:43:42 UTC
Put "EnableSendfile Off" in httpd.conf, restart, and try again. I haven't been able to get sendfile to work on HP-UX/PA-RISC32 (11iv1 or 11iv2) with large file support enabled (like Apache 2.2 has by default). Brillant : it's working. Thanks a lot. Have you any other clues about apache 2.2 and HP-UX on 32b machines ? Because it creates a core dump if I start it with some configuration files enabled (i.e. extra/httpd-autoindex.conf ... quite strange because if I include only this module it's working). Is 2.2 stable enough under HP-UX for a quite important server ? Thanks Laurent >Is 2.2 stable enough under HP-UX for a quite important server?
In general, 2.2 is plenty stable. I haven't done any stress testing of 2.2 on
HP-UX, but I have done a fair amount of functional testing on HP-UX 11iv1 and
some on 11iv2; the only issue I noticed was the sendfile mess. I wouldn't
consider a sendfile issue (which can occur on a number of platforms in varying
circumstances) an implication that there are other problems to worry about.
moving to APR, which owns the interface to the failing sendfile syscall... The core dump at httpd startup sounds bad though - can you file a separate bug on that, running httpd under gdb to get a backtrace? I vaguely recall that there was some issue with the HP-UX sendfile64 which I never resolved - the return value was the wrong type or something? Hi Joe, I'm on holiday next week so I'll create a new bug report at my return. But, to be short, apache crashes when I enable extra/httpd-manual.conf. It seems it's when reading the configuration, because if I run bin/apachectl restart apachectl crashes and the previously running httpd is still running. I have also another problem with database authentication (bug #40582). Unfortunately, my 2 systems lost their system disks ... the same day (black day isn't it), and I was too busy to reinstall. Now I'm restarting to work on it. Bye Laurent I have created a bug report for the starting problem (#42368) Bye Laurent No crash anymore w/ 2.2.4 Oups, I made a mistake. This bug is not yet solved. Created attachment 20389 [details]
define the _HPUX_SOURCE feature test macro to obtain maximum functionality
The sendfile function was being used without being declared, because the
_XOPEN_SOURCE_EXTENDED macro doesn't bring sendfile (and fixups) into the
namespace.
Tested and passes sendfile tests on:
HP HP-UX 11i 11.11 PA-RISC 8700
HP HP-UX 11i v3 Itanium II
* After applying the patch, execute ./buildconf
gosh Davi, I guess the real problem for me was that historically I never took the time to find an HP C compiler option to warn about missing prototypes, and all the recent staring at the sendfile() prototype myself didn't mean the compiler had even glanced at it :( thanks! (I assume that your apache.org account is working by now ;) ) (In reply to comment #11) > gosh Davi, I guess the real problem for me was that historically I never took > the time to find an HP C compiler option to warn about missing prototypes Lucky enough, I had gcc. Also, we could avoid this happening again in future by with a simple compile-time assertion: (void)(0 && sendfile); > > (I assume that your apache.org account is working by now ;) ) > Not yet, it seems to take some time.. there's no hurry. Committed to trunk as r550877 and backported to 1.2.x in r550989. http://svn.apache.org/viewvc?view=rev&revision=550877 http://svn.apache.org/viewvc?view=rev&revision=550989 *** Bug 43189 has been marked as a duplicate of this bug. *** *** Bug 40497 has been marked as a duplicate of this bug. *** |