I did find some discussion of old HP-UX patches that fixed problems with stat calls that some of HP's apps had. There are no particulars and none pertain to system libraries, so they were no help. The issue here may be that I'm a relative novice when it comes to C/C++ programming. For instance, where does the magic happen that masks all of perls stat calls to stat64 when you compile with LFS support? Some of the info out there may contain the answer, but I can't see it for lack of this knowledge.
I'm also wondering if the problem is not the actually call to stat64, which looks like it returns the requested info, but whatever comes next. That last line of the trace bothers me: [5889] In user-mode.................................................................................[running] Very uninformative. Any guesses as to the meaning? One of the other things that has been bothering me is that when I built MP2 with perl 5.8.2, I couldn't get it to work without useshrlib defined. For perl 5.6.2, perl won't even compile successfully if you define this option. It tries to run miniperl during the compile and that hangs with a trace ending in the same mysterious line. The frustration thing about that is that LFS does not seem to affect this particular problem. I'm left wondering if perhaps the real problem here is that these two scenarios are trying to dynamically load libraries that don't lend themselves to dynamic loading (e.g. libpthread.sl) I eliminated the usual culprits such as pthread and libcl.sl and of course there are no helpful messages to point at something else. I do see warnings about a symbol _attribute_ being defined again and internal linking will occur, but as I said before, I don't know enough about C to know if that has any significance at all. Any thought on these? --- Will Fulmer Database Administrator Northampton Community College Bethlehem, PA >>> Stas Bekman <[EMAIL PROTECTED]> 8/11/2004 10:29:05 PM >>> William Fulmer wrote: > We need to back up a bit. I tried something different just for giggles > because I thought we might be on the wrong track with setuid. I wrote a > little script that this > > #!/bin/bash > /usr/opt/httpd-2.0.49/bin/httpd -d t -f conf/httpd.conf -DAPACHE2 > -DONE_PROCESS -DNO_DETATCH > stdout 2>&1 & > tusc -p -f -v -o strace $! > > after running the script I went to a browser and hit > http://cars-l:8529/TestAPI__request_rec > > The strace looks quite different this way (and the process does not > exit). Turns out the setuid thing was the falt of my tusc command being > setuid. (Sorry. insert sheepish look here) > > Trace from this latest test is more what I expected to see: [...] > stat64("/opt/local/wrfopt/build/mod_perl-1.99_14/t/response/TestAPI/request_rec.pm", > 0x6ff66648) = 0 > st_dev: 64 0x000005 > st_ino: 171526 > st_mode: S_IFREG|0644 > st_nlink: 1 > st_rdev: 0 > st_size: 2503 > st_blksize: 8192 > st_blocks: 1 > st_uid: 1073741829 > st_gid: 27549760 > st_atime: Tue Aug 10 16:50:28 2004 > st_mtime: Fri Apr 18 02:18:58 2003 > st_ctime: Mon Aug 9 20:40:52 2004 > Hangs at this point. > > The compile with no LFS: [...] > Blows right by the call to stat no problem. Get output in the browser > say Ok to all 42 tests. > > The only notable difference being the call to stat as opposed to > stat64. Excellent. So you've almost nailed it, William! Now try to see if there are any discussions on the web re: stat vs. stat64, e.g.: http://www.google.ca/search?hl=fr&ie=UTF-8&q=stat+stat64+hangs&btnG=Rechercher&meta= may be some more keywords should be added, like your platform name... -- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
