[Xitami] SSI crash under WinXP

[Thomas J. Hruska]

At 02:36 PM 10/30/2004 -0500, Gord Tanner writeth:
>I include the section of code from xixssi.c surrounding line 570. (and
>attach the whole file)
>I don't know much C,

But I do.  That's why I asked you to post the source.

>Also, this is the exact SSI command that causes the failure.
><!--#include file="../cgi-bin/last_post.txt" -->
>
>If I change it to:
>
><!--#include file="last_post.txt" -->
>
>and make sure the last_post.txt file is located in the webroot
>directory, it no longer causes a crash, but it doesn't include the
>file.
>
>/*****************************   OPEN SSI FILE
*****************************/
>
>MODULE open_ssi_file (THREAD *thread)
>{
>    time_t
>        file_time;
>        
>    tcb = thread-> tcb;                 /*  Point to thread's context
  */
>
>    ASSERT (tcb-> file_name);                          <<<----------- 
>Line 570  ----------------

This will fire if "file_name" in the tcb is NULL.

What happens if you use:

<!--#include file="..\cgi-bin\last_post.txt" -->
or
<!--#include file="..\\cgi-bin\\last_post.txt" -->
or
<!--#include file="/cgi-bin/last_post.txt" -->
or
<!--#include file="\cgi-bin\last_post.txt" -->
or
<!--#include file="\\cgi-bin\\last_post.txt" -->

Instead?

The information you gave here says that the real error is somewhere up the
stack and may have something to do with the relative path information (..)
and/or the forward or backslash.  You may be able to hack around the bug by
using one of the options above, switching to absolute paths, or something
equivalent.

>    /* Check if file is not already open
  */
>    if (sym_get_value (tcb-> open_file, tcb-> file_name, NULL) != NULL)

This is where the crash will likely happen.  sym_get_value will likely try
to dereference file_name, which is NULL, and throw the exception all the
way back to the OS, where the kernel will kill the program that tried to
blue-screen the OS.  If running as a NT service, the NT service manager
will note that Xitami stopped/died and restart it automatically up to 3
times in any session.

If it doesn't crash here, then fopen() will surely crash.  I've not seen a
library implementation that defended against NULL filenames.

What I was doing above is having you try different combinations of file
names as a workaround to ultimately get tcb->file_name to not be NULL and
therefore not crash in this function.


Thomas J. Hruska
Shining Light Productions
http://www.slproweb.com/