text: On Apache 1.3.31 on amd64 running linux 2.6.8.1, adding:
  <FilesMatch "\.(gif|jpg|mp3|css|js|png)$">
  Options All -Indexes
  AllowOverride All
  deny from all
  </FilesMatch>
  is causing Apache to match files with any extension.
  To reproduce, I used a stock 1.3.31 and did:
  ./configure --prefix=/tmp/apache
  make
  make install
  add the above conf to the end of the default httpd.conf. Then point your browser to:
  which will give a 403 forbidden. I also get a forbidden for:.
  but I get a 404 for:
  If I remove the FilesMatch, then index.html shows up as expected. Also, oddly,
  if I change the filesmatch to:
  <FilesMatch "\.(gif|jpg|mp3|css|js)$">
  everything also works as expected.
  This only happens on our amd64 systems. x86 works fine.
  If you need any more info, please let me know.
  Thanks!
  I've been looking into this issue tonight. Havn't uncovered much except it's not
  an issue with the system's regex library. I created this simple test which is
  pretty much what apache seems to be trying to do:
  #include <stdio.h>
  #include <sys/types.h>
  #include <regex.h>
  int main(int argc, char *argv[])
  {
  int ret;
  regex_t *r;
  const char *regex="\\.(gif|jpg|mp3|css|js|png)$";
  int flags = REG_EXTENDED;
  r = malloc(sizeof(regex_t));
  if (regcomp(r, regex, flags)) {
  printf("Error compiling regex\n");
  return 1;
  }
  ret = regexec(r, "index.html", 0, NULL, 0);
  printf("match: %d\n", ret == 0);
  return 0;
  }
  This works as it should. I added some printf() debugging into
  src/main/http_core.c looks like this:
  printf("compiled '%s' into %p at %d\n", cmd->path, r, __LINE__);
  That's at line 1760 after it compiles the regex. I also added a printf() in
  src/main/http_request.c:
  printf("regex match on %s [%p]\n", test_file, entry_core->r);
  on line 704 before it does the ap_regexec() call and a couple of prints to see
  if it matches or not.
  All of this is with a download of apache_1.3.31 non-patched, I compiled it
  myself with the only options being --prefix=/tmp/test_apache. I didn't change
  the conf file except to remove the other match on .htaccess and set the port to
  8080. Here is the output I get:
  gossamer test_apache # ./bin/httpd -X
  compiled '\.(gif|jpg|mp3|css|js|png)$' into 0x58ae98 at 1760
  compiled '\.(gif|jpg|mp3|css|js|png)$' into 0x58dd18 at 1760
  Then when I make a request for / on that server:
  regex match on htdocs [0x58dd18]
  no match!
  regex match on index.html [0x58dd18]
  match!
  regex match on favicon.ico [0x58dd18]
  match!
  As you can see index.html is matching the precompiled regex that it shouldn't.
  I'm going to continue to investigate this. If anyone has any suggestions I'd
  love to hear them.
  Cheers,
  Scott
  I notice the hsregex test suite segfaults in on amd64 whereas it passes on i386,
  so that might be a good place to start looking: cd src/regex && make r
  Thanks Joe. I've been messing with that code for the last day and found a
  solution. The version of the engine.c functions for "small" op regexs does not
  work with 64 bit integers. A simple fix is to change regexec.c line 137 from:
  if (g->nstates <= CHAR_BIT*sizeof(states1) && !(eflags®_LARGE))
  to:
  if (g->nstates <= CHAR_BIT*4 && !(eflags®_LARGE))
  On an opteron sizeof(states1) is always 8 but the smatcher function, for some
  unknown reason, will not handle a regex with more than 32 states. A better fix
  would be to find the reason why smatcher will not work with more than 32 states
  on a opteron but this fix is fine for me.
  Cheers,
  Scott
  *** Bug 32067 has been marked as a duplicate of this bug. ***
  Very weird that this code survives how ever many years then two people hit it in
  a week, it's not like people don't use 1.3 on 64-bit platforms already... the
  only thing different is that amd64 is little-endian I suppose.
  But that change does look like a workaround than a fix. From googling around,
  is intesting it looks like MySQL have made some 64-bit-cleanliness changes, e.g.
  #define onestate long /* Changed from int by Monty */
  but that alone doesn't fix the segfaults.
  Created attachment 13336 [details]
  amd64 safety for regex code
  Created attachment 13337 [details]
  amd64 safety for regex code (take 2)
  The second patch above is a bit more pedantic than the first since the return
  value of ISSETBACK() is stored into an (int) and used as a boolean in the step()
  function in src/regex/engine.c. Patch passes tests in src/regex (`make r`) on a
  dual Opteron.
  *** Bug 33478 has been marked as a duplicate of this bug. ***
  Something is still wrong here. I applied the patch and recompiled and was quite
  delighted to see some of my regexp's come back online, however, some of them are
  still showing signs of problems.
  RewriteRule ^/guides/([^/]*)/Titles/([A-Z]).html$
  /jax/index.php/enotes/lookup/type=$1/sort=Titles/letter=$2 [L]
  The above rule loads the page, but continues to show about 2% left on the
  progress bar in Mozilla (while apache goes nuts in top). Restarting apache fixes
  the problem (until you go to that URL again). However, other rules work fine,
  like the following:
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^/([a-z0-9|-]+)/s([0-9]+)$
  /jax/index.php/enotes/works/notes=$1/sectionID=$2
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^/([a-z0-9|-]+)/?([a-z0-9]+)?/?([a-z|-]+)?/?$
  /jax/index.php/enotes/works/notes=$1/id=$2/tail=$3 [L]
  Oddly enough, these work despite the first rewrite rule being placed above these
  working ones. The problem only arises on a match of the rewrite rule.
  --Joe
  Nevermind my early reply. I figured out that the issue is resolved in Apache
  2.0.x on my AMD64 box. The problem was I was running a patched 1.3.33 Apache
  with PHP5 and my PHP code isn't ready for PHP5 yet.
  At any rate the patch appears to work fine.
  *** Bug 34010 has been marked as a duplicate of this bug. ***
  *** Bug 34172 has been marked as a duplicate of this bug. ***
  This is being patched by downstream vendors like Gentoo:
  The 2nd patch seems to work for them. Consider committing it?
  Apache consistently hangs (apparently in a tight loop) on our Linux 2.6 amd64
  machines without this patch (rewrite rules, I'm guessing); with it everything
  appears fine.
  *** Bug 35151 has been marked as a duplicate of this bug. ***