You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@worldgate.com> on 1997/09/13 00:49:50 UTC
erm.... 1.3 is messed up?
.htaccess file:
AuthType Basic
AuthUserFile /home/marcs/public_html/lim/.htpasswd
AuthName this
require user marcs
.htpasswd:
joe:G1DXYIw.oqfow
marcs:G1DXYIw.oqfow
marcs0123456789:G1DXYIw.oqfow
aaaaaaaa:G1DXYIw.oqfow
aaaaaaa:G1DXYIw.oqfow
aaaaaa:G1DXYIw.oqfow
The directory properly requires authentication, but if I authenticate
as joe (or any other user) it accepts it! 1.2 doesn't.
A quick test on taz didn't produce the same problem. Perhaps
related to the Windows thing Alexei posted about the other day?
Am I loosing my mind?
Re: erm.... 1.3 is messed up?
Posted by Dean Gaudet <dg...@arctic.org>.
On Wed, 1 Oct 1997, Martin Kraemer wrote:
> In the meantime, I have a suspicion, but not enough internal knowledge
> to decide if it is sensible:
> Is it possible that _after_ destroy_subpool(), there are still dangling
> references to things which were stored in the subrequest? That would
> explain why the crashes never occur at the same code location (depending
> on the server's request history) and why it can be several different core
> stuctures which are trashed by apparently new request info.
This has been my suspicion for a while too -- either that or a module
calling get_module_config with the wrong struct module. But since I got
that "Ouch! Freeing already free block" error today I think it's less
likely to be a get_module_config problem.
> What do you guys think, could it be possible? If yes, then _very_many_
> functions' pool arguments would have to be checked, right?! :-(
Well given that I got the problem today with a very small set of modules I
think we can start by finding out just how small that set of modules needs
to be. I had:
AddModule modules/standard/mod_env.o
# this is non-standard, but I don't suspect it
AddModule modules/hotwired/mod_log_hotwired.o
AddModule modules/standard/mod_mime.o
AddModule modules/standard/mod_negotiation.o
AddModule modules/standard/mod_status.o
AddModule modules/standard/mod_dir.o
AddModule modules/standard/mod_asis.o
AddModule modules/standard/mod_imap.o
AddModule modules/standard/mod_actions.o
AddModule modules/standard/mod_alias.o
AddModule modules/standard/mod_access.o
AddModule modules/standard/mod_auth.o
AddModule modules/standard/mod_expires.o
AddModule modules/standard/mod_headers.o
AddModule modules/standard/mod_setenvif.o
Dean
Re: erm.... 1.3 is messed up?
Posted by Martin Kraemer <Ma...@mch.sni.de>.
Hi, I'm back again, buried under hundreds of new-httpd mails....
On Sun, Sep 28, 1997 at 02:28:58PM -0700, Dean Gaudet wrote:
> No I've never claimed to have fixed the corruption problem. I'm still
> waiting for something that I can reproduce... or more data from Martin, I
> forget what I asked him for though.
>
> Dean
On Fri, 12 Sep 1997 16:12:43 -0700, Dean had written...
>> To: new-httpd@apache.org
>> Subject: Re: Huh? Windows oddness (long dbxtrace)
>>
>> I wonder if these are all related to the SEGVs that I started seeing when
>> I did a "cvs update" after I got back from burning man (tuesday sept 2).
>> Can you folks try doing a few 'cvs -D "a week ago"' checkouts and see
>> when it started happening?
>>
>> I think core_dir->opts is buried under a macro or function call.
I tried to look through the sources (and within the debugger) for clues
to nail down this bug. But neither checking source references to "->opts"
nor selectively tracing central routines (directory_walk etc) helped me
any further.
In the meantime, I have a suspicion, but not enough internal knowledge
to decide if it is sensible:
Is it possible that _after_ destroy_subpool(), there are still dangling
references to things which were stored in the subrequest? That would
explain why the crashes never occur at the same code location (depending
on the server's request history) and why it can be several different core
stuctures which are trashed by apparently new request info.
What do you guys think, could it be possible? If yes, then _very_many_
functions' pool arguments would have to be checked, right?! :-(
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: erm.... 1.3 is messed up?
Posted by Dean Gaudet <dg...@arctic.org>.
No I've never claimed to have fixed the corruption problem. I'm still
waiting for something that I can reproduce... or more data from Martin, I
forget what I asked him for though.
Dean
On Sat, 27 Sep 1997, Alexei Kosut wrote:
> On Sat, 27 Sep 1997, Dean Gaudet wrote:
>
> > You posted on sep 12th, the windows bug I think you're referring to was
> > "fixed" on the 8th, http_request.c rev 1.80 and really fixed on the 11th,
> > rev 1.82.
>
> Doubtful. Although the syymptoms I was having (corruption of the
> per-dir config entry) are the same as a problem we supposedly
> "fixed" earlier, AFAIK, it still has not been. And people keep
> mentioning it, on both Windows and Unix.
>
> Unless I missed something, it's quite conceivable that Marc's problem
> could be related to this.
>
> -- Alexei Kosut <ak...@nueva.pvt.k12.ca.us>
>
>
>
>
>
>
Re: erm.... 1.3 is messed up?
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Sat, 27 Sep 1997, Dean Gaudet wrote:
> You posted on sep 12th, the windows bug I think you're referring to was
> "fixed" on the 8th, http_request.c rev 1.80 and really fixed on the 11th,
> rev 1.82.
Doubtful. Although the syymptoms I was having (corruption of the
per-dir config entry) are the same as a problem we supposedly
"fixed" earlier, AFAIK, it still has not been. And people keep
mentioning it, on both Windows and Unix.
Unless I missed something, it's quite conceivable that Marc's problem
could be related to this.
-- Alexei Kosut <ak...@nueva.pvt.k12.ca.us>
Re: erm.... 1.3 is messed up?
Posted by Dean Gaudet <dg...@arctic.org>.
FWIW I can't reproduce this with the current HEAD. All I tried though was
taking default config and adding "AllowOverride all" to the docroot and to
/home/*/public_html. Then I tried a .htaccess in the docroot and in
~dgaudet/lim. In both cases joe was restricted.
You posted on sep 12th, the windows bug I think you're referring to was
"fixed" on the 8th, http_request.c rev 1.80 and really fixed on the 11th,
rev 1.82.
Dean
On Fri, 12 Sep 1997, Marc Slemko wrote:
> .htaccess file:
>
> AuthType Basic
> AuthUserFile /home/marcs/public_html/lim/.htpasswd
> AuthName this
> require user marcs
>
>
> .htpasswd:
>
> joe:G1DXYIw.oqfow
> marcs:G1DXYIw.oqfow
> marcs0123456789:G1DXYIw.oqfow
> aaaaaaaa:G1DXYIw.oqfow
> aaaaaaa:G1DXYIw.oqfow
> aaaaaa:G1DXYIw.oqfow
>
> The directory properly requires authentication, but if I authenticate
> as joe (or any other user) it accepts it! 1.2 doesn't.
>
> A quick test on taz didn't produce the same problem. Perhaps
> related to the Windows thing Alexei posted about the other day?
> Am I loosing my mind?
>
>