thanks again, yeah Ive logged it using fprintf statements upto the 
return(HTTP_REDIRECT) point of code at which point I assume it exits the code. 
Its also pretty much the last module being added as part of the LoadModule line 
of statements in the http. Is there anyway to make sure that no other module is 
interfering with this modules memory space. I am trying to recompile from 
scratch on Solaris in this case. If there is any other stategy (other than an 
so) that  I can use, do let me know, as long as it dosent involve recompiling 
apache etc.. since this will one day find its way to production and recompiling 
production apache aint gonna happen :-)

----- Original Message -----
From: Joe Lewis <modules-dev@httpd.apache.org>
To: modules-dev@httpd.apache.org
At: 12/10  9:40:16

SAILESH KRISHNAMURTI, BLOOMBERG/ 731 LEXIN wrote:
> Hi Joe, Appreciate the response. thanks  This is similar to what someone else 
told me too (that it may be a non-null terminated string issue). The point is 
how can I debug it further.I currently am printing all the character portions of
the request rec including the headers_out and err_headers_out to log using 
fprintf statements to stderr. I think I tried breifly with ap_log_rerror too... 
Will try again, but the basic redirection string seems to be getting properly 
from what I can see visually in the logs.

Are you saying that once it leaves your module, it is correct?  That
would mean a separate module is corrupting the string.  If the
ap_log_lines show (right before your module exits) the correct
redirection header, then your module is working.

If the log messages in your module are showing the header corrupted,
then between the log line that prints the correct header and the log
line that prints the bad header is where you will find the problem in
the code.  You can narrow this down by adding more lines.

(I know you have thought of this already, but for the sake of the
archives, any time someone ports from a 64 bit environment to a 32 bit
environment, no .so files should be copied.  Never mix and match -
always recompile any 3rd party modules on the target system if an issue
is found, as copied .so's can cause more trouble than they are worth.)

Joe
-- 
Joseph Lewis <http://sharktooth.org/>
"Divide the fire, and you will sooner put it out." - Publius Syrus

Reply via email to