[: GaB :]

I tried to debug a Java WebApp deployed into GlassFish 3 via NetBeans. When tried to start the application server in debug mode, I received the immediate error of:

FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:690]

First this site suggested to change the JVM options in the GlassFish admin console for debugging instead of

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n

to

-Xdebug -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8787

but didn't solved anything.

Then I just changed the server properties in NetBeans: Services->Server->right click on the server, Properties->Java address to use, and changed the port number to an arbitrary one (eg. 8878). It works fine now.

My friends Horde and Imp are back again! Now I tried Horde3 with IMP4 from the Debian Etch repository.

After my last appointment with Horde, I decided to install it on another server, as a replacement for the unmaintained IlohaMail. Everything worked fine, until I didn't wish to log in the first time into IMP, to check how it works.

Logging in into Horde does work fine, but logging in into IMP doesn't. If I try, I  get a download window pointed in my face with the file named redirect.php.

First I guess this is a problem with the session handling. I had such an issue upon installing a Moodle onto this server, because Apache is chrooted. Then I start debugging...

/usr/share/horde3/imp/redirect.php runs fine, until line 149, where a call for IMP_Session::createSession return false, and it returns false also.

Then I checked lib/Session.php where a call at line 308 $GLOBALS['imp_search']->sessionSetup(); not just fails, it crashes. That's why I'm getting a download window instead of a blank page or any kind of error messages: the login script doesn't fail, it crashes.

Back to debugging: the last call I mentioned crashes because in Search.php at line 109 the line $this->createVINBOXFolder(); crashes. If I comment it out, it works! But no reason to stop here...

This function (defined at line 398) is present to create virtual INBOX folders. And it does hang at line 402 $imptree = &IMP_Tree::singleton();

This is utterly bad. Why the hell does such a call hang? Single instances of IMP_Tree might be system wide used.

In lib/IMAP/Tree.php I found that in fact I have to debug IMAP_Tree::singleton() in lib/Horde/IMAP/Tree.php, because Imp's IMP_Tree extends Horde's IMAP_Tree, and here at line 272 the call $instance[$app] = &new IMP_Tree(true, imaptree); fails.

The constructor of IMP_Tree breaks when it calls it's parent's constructor, that again fails when it calls $this->init($init); at line 288.

Init fails at line 474 with $this->_addLevel($boxes);, _addLevel fails at line 1037 with  $elt = $this->_makeMailboxTreeElt($val);, and here at line 389 $this->_initSubscribed(); crashes.

And finally here throws $tmp = @imap_lsub($this->_getStream(), $this->_server, $val['name'] . '*'); at line 1498 a SEGFAULT.

Function imap_lsub (a standardized PHP system call) would list all the subscribed mailboxes, but WTF - I ask my self - that means this is a SEGAFAULT in the PHP environment itself.

A fast syslog check reveals that exactly this is happening:
Mar 19 01:07:13 * *: imap-login: Login: user=<*>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured
Mar 19 01:07:13 * apache2[24918]: IMAP toolkit crash: Unable to look up user name
Mar 19 01:07:13 *: IMAP(*): Disconnected

Apache's IMAP PHP module is crashing, with a very uninformative but googleable message.

So I find more people facing this problem:
http://bugs.horde.org/ticket/?id=711
groups.google.com/group/mailing.www.horde-imp/browse_thread/thread/...

It comes out, that the whole misbehavior is caused by the attempt of Apache's IMAP engine to read /etc/passwd, and because Apache is running in a chroot such a file does not exists. It does only need the line with the UID Apache is running with, so this need is easy to satisfy, without any security concern: I just copied the line of www-data from /etc/passwd into /etc/passwd inside the chroot.