I am getting this same exception due to a request URI for a non existent file. I am using Tomcat 5.5.15 and PHP 4.4.2 When this exception occurs, I also get a JVM dump do the zend engine.
# # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa889aa94, pid=30899, tid=2844183472 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode) # Problematic frame: # C [libphp4.so+0x130a94] zend_hash_copy+0xc # # An error report file with more information is saved as hs_err_pid30899.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # This is bad. Any suggestions? Are you seeing the same dump or just the exception? You might have already mentioned but what version of PHP are you using? I tried catching the exception in php's servlet class, just wrapped the call to send in try/catch, but it didn't help matters. Any help appreciated. Scott Gregg Leichtman wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This exception: > > java.io.IOException: null > net.php.servlet.send(Native Method) > net.php.servlet.service(servlet.java:207) > net.php.servlet.service(servlet.java:236) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > in my particular case, was generated by the following code in file > <php_src_distribution_root>/TSRM/tsrm_virtual_cwd.c in function > virtual_fopen where it attempts > > ... > f = fopen(new_state.cwd, mode); > CWD_STATE_FREE(&new_state); > fclose(outFile); > return f; > > The function takes a, not uncommon in C, minimalistic approach to > errors by passing a null for all failures. > > I had mistakenly placed my test.php file directly under the webapps > directory. It should have been placed under the .../webapps/ROOT > directory. Tomcat passed .../webapps/ROOT/test.php to the fopen > function. Since the file could not be found, fopen returned a null > pointer which bubbles up from here to the Java code as a thrown > IOException with no error info other than null. If I had been paying > attention, I would have caught this with the first post while I was > still debugging the Java code. Arghhh. > > Moving the test.php file containing: > > <?php phpinfo(); ?> > > to the proper directory caused a nicely formatted table of PHP info to > be displayed in the FireFox browser. > > Also, the code I mentioned below as initially suspect was not even > compiled into the library, since the VIRTUAL_DIR directive was defined > so that virtual functions would be compiled. > > Thanks again for the push in the right direction. > > -=> Gregg <=- > > Gregg Leichtman wrote: >> A review of the servlet.c send method shows the following code: >> >> /* * Parse the file */ SETSTRING( SG(request_info).path_translated, >> pathTranslated ); #ifdef VIRTUAL_DIR retval = >> php_fopen_primary_script(&file_handle TSRMLS_CC); #else /* * The >> java runtime doesn't like the working directory to be * changed, so >> save it and change it back as quickly as possible * in the hopes >> that Java doesn't notice. */ getcwd(cwd, MAXPATHLEN); retval = >> php_fopen_primary_script(&file_handle TSRMLS_CC); chdir(cwd); >> #endif >> >> if (retval == FAILURE) { php_request_shutdown((void *) 0); >> php_module_shutdown(TSRMLS_C); ThrowIOException(jenv, >> file_handle.filename); return; } >> >> Relying on timing to make something work is usually not a good >> practice and it looks like this code may not be working in my case >> due to bad timing. As previously posted I'll try an earlier version >> of PHP. >> >> -=> Gregg <=- >> >> Gregg Leichtman wrote: >>>> Thanks for the direction. >>>> >>>> This is pretty much what I thought. I'll try moving back to a >>>> previous version of PHP and see how it goes. >>>> >>>> -=> Gregg <=- >>>> >>>> Nikola Milutinovic wrote: >>>>>>> *exception* >>>>>>> >>>>>>> java.io.IOException: null net.php.servlet.send(Native >>>>>>> Method) net.php.servlet.service(servlet.java:207) >>>>>>> net.php.servlet.service(servlet.java:236) >>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:802) >>>>>>> >>>>>> This exception is not only generic, but it is also missing >>>>>> the cause. It is definitely generated in the JNI method, so >>>>>> you'd have to look in there. >>>>>> >>>>>>> I then altered the servlet class to include some >>>>>>> debugging info just prior to its invocation of the send >>>>>>> method: >>>>>>> >>>>>>> send(request.getMethod(), request.getQueryString(), >>>>>>> request.getRequestURI(), contextPath, >>>>>>> request.getContentType(), request.getContentLength(), >>>>>>> request.getRemoteUser(), display_source_mode ); >>>>>>> >>>>>>> Here is the result: request.getMethod() = >>>>>>> GET request.getQueryString() = null >>>>>>> request.getRequestURI() = /test.php contextPath = >>>>>>> /home/gsl/tomcat/apache-tomcat-5.5.15/webapps/ROOT/test.php >>>>>>> request.getContentType() = null >>>>>>> request.getContentLength() = -1 request.getRemoteUser() = >>>>>>> null display_source_mode = false >>>>>> This looks fine. >>>>>> >>>>>>> The corresponding native method appears to be in >>>>>>> servlet.c as: >>>>>>> >>>>>>> JNIEXPORT void JNICALL Java_net_php_servlet_send (JNIEnv >>>>>>> *jenv, jobject self, jstring requestMethod, jstring >>>>>>> queryString, jstring requestURI, jstring pathTranslated, >>>>>>> jstring contentType, jint contentLength, jstring >>>>>>> authUser, jboolean display_source_mode) >>>>>>> >>>>>>> I haven't written JNI code before, but I suspect that the >>>>>>> first two args are just hidden info. that is typically >>>>>>> passed to a native method, so I don't see a signature >>>>>>> mismatch or anything else wrong here. >>>>>> The error would have been much different, in case of a >>>>>> signature mismatch. >>>>>> >>>>>>> Alternatively, does anyone have any further ideas on what >>>>>>> I could do to debug this further? >>>>>>> >>>>>>> A few other individuals posted this null IOException on >>>>>>> the net, but no resolution was provided. Being such a >>>>>>> generic error, their problem might not even be related to >>>>>>> what I am experiencing. >>>>>> Well,... >>>>>> >>>>>> As I have said above, the exception is thrown in the native >>>>>> method, so you could go into the source of that method and >>>>>> see where it could throw an exception. Other than that, you >>>>>> could try building a different version of PHP, like 5.0 or >>>>>> 5.1 branch. Maybe they will fare better. >>>>>> >>>>>> Nix. >>>>>> >>>>>> __________________________________________________ Do You >>>>>> Yahoo!? Tired of spam? Yahoo! Mail has the best spam >>>>>> protection around http://mail.yahoo.com >>>>>> >>>>>> >> --------------------------------------------------------------------- >> >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: >>>>>> [EMAIL PROTECTED] >>>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] For >> additional commands, e-mail: [EMAIL PROTECTED] >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFELExGMcSsEtbyA2cRAnRWAJ9yIUHIXX/AJ3aYyNR63mP0H91kCACcDAvQ > 6cohwHXPQmSpnB0oYFAI9X0= > =PRHu > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/PHP-Servlet-Fails-in-Tomcat-5.5.15-t1346749.html#a3710746 Sent from the Tomcat - User forum at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
