tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Leichtman <g...@erols.com>
Subject Re: PHP Servlet Fails in Tomcat 5.5.15-SOLVED
Date Tue, 04 Apr 2006 00:59:06 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am using the same version of Tomcat and PHP. I did erratically get
JVM crashes which brought Tomcat down. Placing the PHP file that I was
trying to access under <tomcat home>/webapps/ROOT solved my problem
for the reason given. However, a null IOException is pretty generic
and your problem may or may not be the same. I had to put debug
statements into the PHP C code and debug down to the problem before I
solved it. I suggest you put some debug statements into the source
file I mentioned below and see if you can divine the cause of your
null IOException. You'll at least know if it is the same type of
problem or a different one. Just copy the rebuilt libphp4.so file to
<tomcat home>/common/lib and you should be able to test once you
restart Tomcat. Beware of the page cache in the browser of your
choice. It can get in the way of the debug analysis.

                                    -=> Gregg <=-

lhommesc wrote:
> 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: 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:
>>>>>>>> users-unsubscribe@tomcat.apache.org For additional
>>>>>>>> commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>
> ---------------------------------------------------------------------
>
>>>>>> To unsubscribe, e-mail:
>>>>>> users-unsubscribe@tomcat.apache.org For additional
>>>>>> commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>
> ---------------------------------------------------------------------
>
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For
> additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>> -- 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: users-unsubscribe@tomcat.apache.org For
>> additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEMcTYMcSsEtbyA2cRAqRzAJoCOXhrmRsjewwpig7hxZ1la7i/eACfc2WE
OCDVsiYFQOl7qN+Hv/e/NZw=
=PcLD
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message