You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by lhommesc <lh...@hotmail.com> on 2006/04/02 10:01:50 UTC
Re: PHP Servlet Fails in Tomcat 5.5.15-SOLVED
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: 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
>>
> -----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: 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
Re: PHP Servlet Fails in Tomcat 5.5.15-SOLVED
Posted by Gregg Leichtman <gs...@erols.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Given the experience I have had with getting this to work, the
complexity involved in making it work, and the apparent abandonment of
this approach in the latest 5.x version of PHP, I would agree. Due to
my inexperience I initially approached the problem of running PHP and
a Java webapp together by placing both inside Tomcat. The better
solution appears to be, correct me if I'm wrong, to use Apache to run
PHP scripts and mod_jk to run Tomcat which can then be used to run any
Java webapps under the same web domain.
My desire to run PHP stems from my need to run a forum package with a
very specific feature set that the client has made a requirement. Very
few packages written in any language support these features. Of those
available after several weeks of searching the net, only PHP-based
forums seem to offer what I need, thus, the desire to use PHP at all.
Given a choice I would opt for nothing but Java, but the customer is
always right.
-=> Gregg <=-
Nikola Milutinovic wrote:
> Hi all.
>
> Just one opinion, if it hasn't been said before. Do not mix Java
> and PHP.
>
> PHP is inherently thread un-safe. Basically the PHP code itself is,
> AFAIK, OK (thread safe), but all those myriads of 3rd-party
> libraries providing needed functionality to the myriads of PHP
> extensions can, and some are thread un-safe.
>
> In case you haven't noticed, most decent Linux distros disable
> multi-threaded MPMs in Apache, if you enable PHP in them. Well, if
> Apache feels unsafe with PHP around, how should you feel in Tomcat?
>
>
> I can understand why you would want to run PHP, a lot of freeware
> projects out there were written in PHP. Or, should I be more
> precise, in PHP+MySQL glued together. Perhaps you cannot afford to
> rewrite it all. But sometimes, it is worth it.
>
> Decision remains yours, but I would run PHP separately from TC, if
> at all possible.
>
> 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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFENyp0McSsEtbyA2cRArfHAJ9N21+fZqXlkfPXDu4/lMJ2eLPJlgCeIorS
QGVOkf9QOmYb4Rg7r/qXvIQ=
=Ry48
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PHP Servlet Fails in Tomcat 5.5.15-SOLVED
Posted by Nikola Milutinovic <al...@yahoo.com>.
Hi all.
Just one opinion, if it hasn't been said before. Do not mix Java and PHP.
PHP is inherently thread un-safe. Basically the PHP code itself is, AFAIK, OK
(thread safe), but all those myriads of 3rd-party libraries providing needed
functionality to the myriads of PHP extensions can, and some are thread
un-safe.
In case you haven't noticed, most decent Linux distros disable multi-threaded
MPMs in Apache, if you enable PHP in them. Well, if Apache feels unsafe with
PHP around, how should you feel in Tomcat?
I can understand why you would want to run PHP, a lot of freeware projects out
there were written in PHP. Or, should I be more precise, in PHP+MySQL glued
together. Perhaps you cannot afford to rewrite it all. But sometimes, it is
worth it.
Decision remains yours, but I would run PHP separately from TC, if at all
possible.
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
Re: PHP Servlet Fails in Tomcat 5.5.15-SOLVED
Posted by Gregg Leichtman <gs...@erols.com>.
-----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