[imp] Errors in loging into Imp.

[Eric Rostetter]

Quoting robert sand <rsand@d.umn.edu>:
 
> The cookie path didn't chage anything.

Okay, so what is your cookie path set to in horde and in php.ini?  Also,
what are your aliases and/or RootDirectory paths in your web server config?
Did you follow the information in the admin FAQ about how to set this 
stuff up correctly? (See http://www.horde.org/faq/admin/config/index.php#c3
for more info).

> If I knew what part of horde or imp was
> causing the segmentation fault I would fix it but nothing is reporting any
> porblems.  The /tmp/horde.log file is empty even though I have the level all
> the way down to debug.

Well, it may be unrelated to your login problems also. But surely a seg
fault is a bad thing and should be looked at.  Also, the seg fault could
be coming from somewhere else (like hackers trying to exploit your web
server, etc).

Okay, so you say you can't login, right?  If using Horde authentication,
that means the seg fault is likely being produced from a call to either
the index page (index.php) or the login page (login.php), right?
If using IMP authentication, then in addition to the above you need to
look at IMP's index.php, login.php, and redirect.php files which are
involved in login.  So that limits your set to basically 2-3 files.

Anyway, you probably don't even need to know that.  Looking at your log
files from the web server, you should see a timestamp for the seg fault.
You should then correlate that to the web server access log to see which 
access was right before that (same time, or very small delta before it).
That should tell you which file produced the seg fault.

Or, run your web server in the foreground rather than detached/backrounded.
Watch your web logs.  Enable the web server debugging.  Maybe even run the
web server in a debugger.  Then hit the pages.  Should clear things up.

Most useful is something like this from
http://www.php.net/manual/sv/print/faq.installation.php#faq.installation.nodata

    * Stop your httpd processes
    * gdb httpd
    * Stop your httpd processes
    * > run -X -f /path/to/httpd.conf
    * Then fetch the URL causing the problem with your browser
    * > run -X -f /path/to/httpd.conf
    * If you are getting a core dump, gdb should inform you of this now
    * type: bt

If you have a standalone php command, you may be able to test pages with
it and find the crash that way also.

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

"Can you hear me now? ... Good!"
"Can you hear me now? ... Good!"