#32614 [Opn]: Crash occured in function fread from module /usr/lib/libc.so.1
ID: 32614 User updated by: Oscar dot Castillo at jpl dot nasa dot gov Reported By: Oscar dot Castillo at jpl dot nasa dot gov Status: Open Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 5CVS-2005-04-07 (dev) Assigned To: thetaphi New Comment: By default, iPlanet is not configured to core dump. Some special flags must be enabled to allow core dumping. I do not know the specific syntax to enable core dumping and I must then open a trouble ticket with Sun. I am attempting your suggestion from bug report #32491 to enable PHP as a CGI/Fastcgi via your cgibytex CGI enabler. As of the last 7 hours, PHP is working perfectly. I shall keep you posted. Previous Comments: [2005-04-08 17:30:37] [EMAIL PROTECTED] Something other: can you load the "core" file the crashing server produces into dbx or gdb and send me the output? [2005-04-08 09:48:00] [EMAIL PROTECTED] Info about the solaris "bug": http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr5q?a=view (see under "USAGE") In 64bit solaris it would work, but SunONE is a 32 bit server. [2005-04-08 09:37:01] [EMAIL PROTECTED] I found the reason for the bug. The problem is not the file upload here that works now. The problem is now the same stdio related bug which leads to the segmentation fault. I fixed the CVS now not to crash the webserver in this error condition (missing an errorchecking at fdopen() which works on all platform without errors, on solaris fails when the filedescriptor>255). But the problem should still be there but you should get a message in your PHP script. Looking into your code I exspect the "execute" functions to fail because they need to cast a stream from posix to stdio. Please test the new CVS and tell me when the further handling of your uploaded file fails. [2005-04-07 18:27:43] Oscar dot Castillo at jpl dot nasa dot gov I also forgot to mention that I am running PHP 5.0.5-dev on 2 other web servers that are used for testing and development of Java, PERL and PHP applications prior to being delivered to the production environment. All flavors of PHP have always worked in the test and development environments, but never in the production environment. The only difference between the 3 environments is that the production environment has a much heavier load than the test and development environments put together. The OS, OS patches, iPlanet version and PHP version are all exactly the same in all 3 web server environments. The fact that you cannot produce the crash in your environment can be related to the light load on your test set up. As mentioned in my last bug report (#32491), I have Java enabled (Very memory intensive) on the web server and our production environment mostly uses JSP and Java servlets. [2005-04-07 18:16:32] Oscar dot Castillo at jpl dot nasa dot gov I installed the latest CVS as of Tuesday 4/5/2005 which was php5-STABLE-200504052230. A php_info() function call shows the version as 5.0.5-dev. When I recycle the web server daemon, PHP runs fine. Before I upgraded to this CVS it usually took about 4 hours to begin failing depending on the load on my production web server. It used to say "File upload error - unable to create a temporary file in Unknown on line 0" after the maximum number of file descriptors limit was reached which took about 4 - 24 hours after recycling the web server daemon. After I upgraded to PHP 5.0.5-dev, the PHP environment works fine for about 4 - 24 hours. The functioning time varies with the load on the web server and the web server crashes while when any PHP script is accessed once this "limit" is reached. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32614 -- Edit this bug report at http://bugs.php.net/?id=32614&edit=1
#32614 [Opn]: Crash occured in function fread from module /usr/lib/libc.so.1
ID: 32614 User updated by: Oscar dot Castillo at jpl dot nasa dot gov Reported By: Oscar dot Castillo at jpl dot nasa dot gov Status: Open Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 5CVS-2005-04-07 (dev) New Comment: I also forgot to mention that I am running PHP 5.0.5-dev on 2 other web servers that are used for testing and development of Java, PERL and PHP applications prior to being delivered to the production environment. All flavors of PHP have always worked in the test and development environments, but never in the production environment. The only difference between the 3 environments is that the production environment has a much heavier load than the test and development environments put together. The OS, OS patches, iPlanet version and PHP version are all exactly the same in all 3 web server environments. The fact that you cannot produce the crash in your environment can be related to the light load on your test set up. As mentioned in my last bug report (#32491), I have Java enabled (Very memory intensive) on the web server and our production environment mostly uses JSP and Java servlets. Previous Comments: [2005-04-07 18:16:32] Oscar dot Castillo at jpl dot nasa dot gov I installed the latest CVS as of Tuesday 4/5/2005 which was php5-STABLE-200504052230. A php_info() function call shows the version as 5.0.5-dev. When I recycle the web server daemon, PHP runs fine. Before I upgraded to this CVS it usually took about 4 hours to begin failing depending on the load on my production web server. It used to say "File upload error - unable to create a temporary file in Unknown on line 0" after the maximum number of file descriptors limit was reached which took about 4 - 24 hours after recycling the web server daemon. After I upgraded to PHP 5.0.5-dev, the PHP environment works fine for about 4 - 24 hours. The functioning time varies with the load on the web server and the web server crashes while when any PHP script is accessed once this "limit" is reached. [2005-04-07 08:20:19] [EMAIL PROTECTED] Crahes it always when trying to access a PHP or only when it uploads a file? On my servers here it worked, but I have not latest cvs - only a patched 5.0.4 - and: [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 - fread is not used anywhere in the changed code. [2005-04-07 00:45:38] Oscar dot Castillo at jpl dot nasa dot gov Description: As instructed by BUG#32491, I installed PHP 5.0.5 to fix my "File upload error" problem. Previously, the iPlanet 6.0 SP5 web server would simply produce a "File upload error" message. Now the web server crashes and the following message is output to the web server's error log file: [06/Apr/2005:10:13:01] catastrophe (13578): Server crash detected (signal SIGSEGV) [06/Apr/2005:10:13:01] info (13578): Crash occurred in NSAPI SAF php5_execute [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 [06/Apr/2005:10:13:01] failure (13576): Child process admin thread is shutting down [06/Apr/2005:10:13:02] info (19023): Installing a new configuration [06/Apr/2005:10:13:02] info (19023): [LS ls1] https://128.149.147.181, port 443 ready to accept requests [06/Apr/2005:10:13:02] info (19023): A new configuration was successfully installed Reproduce code: --- Please see the Reproduce code for BUG#32491 Expected result: Successful file upload Actual result: -- [06/Apr/2005:10:13:01] catastrophe (13578): Server crash detected (signal SIGSEGV) [06/Apr/2005:10:13:01] info (13578): Crash occurred in NSAPI SAF php5_execute [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 [06/Apr/2005:10:13:01] failure (13576): Child process admin thread is shutting down [06/Apr/2005:10:13:02] info (19023): Installing a new configuration [06/Apr/2005:10:13:02] info (19023): [LS ls1] https://128.149.147.181, port 443 ready to accept requests [06/Apr/2005:10:13:02] info (19023): A new configuration was successfully installed -- Edit this bug report at http://bugs.php.net/?id=32614&edit=1
#32614 [Opn]: Crash occured in function fread from module /usr/lib/libc.so.1
ID: 32614 User updated by: Oscar dot Castillo at jpl dot nasa dot gov Reported By: Oscar dot Castillo at jpl dot nasa dot gov Status: Open Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 5CVS-2005-04-07 (dev) New Comment: I installed the latest CVS as of Tuesday 4/5/2005 which was php5-STABLE-200504052230. A php_info() function call shows the version as 5.0.5-dev. When I recycle the web server daemon, PHP runs fine. Before I upgraded to this CVS it usually took about 4 hours to begin failing depending on the load on my production web server. It used to say "File upload error - unable to create a temporary file in Unknown on line 0" after the maximum number of file descriptors limit was reached which took about 4 - 24 hours after recycling the web server daemon. After I upgraded to PHP 5.0.5-dev, the PHP environment works fine for about 4 - 24 hours. The functioning time varies with the load on the web server and the web server crashes while when any PHP script is accessed once this "limit" is reached. Previous Comments: [2005-04-07 08:20:19] [EMAIL PROTECTED] Crahes it always when trying to access a PHP or only when it uploads a file? On my servers here it worked, but I have not latest cvs - only a patched 5.0.4 - and: [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 - fread is not used anywhere in the changed code. [2005-04-07 00:45:38] Oscar dot Castillo at jpl dot nasa dot gov Description: As instructed by BUG#32491, I installed PHP 5.0.5 to fix my "File upload error" problem. Previously, the iPlanet 6.0 SP5 web server would simply produce a "File upload error" message. Now the web server crashes and the following message is output to the web server's error log file: [06/Apr/2005:10:13:01] catastrophe (13578): Server crash detected (signal SIGSEGV) [06/Apr/2005:10:13:01] info (13578): Crash occurred in NSAPI SAF php5_execute [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 [06/Apr/2005:10:13:01] failure (13576): Child process admin thread is shutting down [06/Apr/2005:10:13:02] info (19023): Installing a new configuration [06/Apr/2005:10:13:02] info (19023): [LS ls1] https://128.149.147.181, port 443 ready to accept requests [06/Apr/2005:10:13:02] info (19023): A new configuration was successfully installed Reproduce code: --- Please see the Reproduce code for BUG#32491 Expected result: Successful file upload Actual result: -- [06/Apr/2005:10:13:01] catastrophe (13578): Server crash detected (signal SIGSEGV) [06/Apr/2005:10:13:01] info (13578): Crash occurred in NSAPI SAF php5_execute [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 [06/Apr/2005:10:13:01] failure (13576): Child process admin thread is shutting down [06/Apr/2005:10:13:02] info (19023): Installing a new configuration [06/Apr/2005:10:13:02] info (19023): [LS ls1] https://128.149.147.181, port 443 ready to accept requests [06/Apr/2005:10:13:02] info (19023): A new configuration was successfully installed -- Edit this bug report at http://bugs.php.net/?id=32614&edit=1
#32614 [Opn]: Crash occured in function fread from module /usr/lib/libc.so.1
ID: 32614 Updated by: [EMAIL PROTECTED] Reported By: Oscar dot Castillo at jpl dot nasa dot gov Status: Open Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 5CVS-2005-04-07 (dev) Assigned To: thetaphi New Comment: Something other: can you load the "core" file the crashing server produces into dbx or gdb and send me the output? Previous Comments: [2005-04-08 09:48:00] [EMAIL PROTECTED] Info about the solaris "bug": http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr5q?a=view (see under "USAGE") In 64bit solaris it would work, but SunONE is a 32 bit server. [2005-04-08 09:37:01] [EMAIL PROTECTED] I found the reason for the bug. The problem is not the file upload here that works now. The problem is now the same stdio related bug which leads to the segmentation fault. I fixed the CVS now not to crash the webserver in this error condition (missing an errorchecking at fdopen() which works on all platform without errors, on solaris fails when the filedescriptor>255). But the problem should still be there but you should get a message in your PHP script. Looking into your code I exspect the "execute" functions to fail because they need to cast a stream from posix to stdio. Please test the new CVS and tell me when the further handling of your uploaded file fails. [2005-04-07 18:27:43] Oscar dot Castillo at jpl dot nasa dot gov I also forgot to mention that I am running PHP 5.0.5-dev on 2 other web servers that are used for testing and development of Java, PERL and PHP applications prior to being delivered to the production environment. All flavors of PHP have always worked in the test and development environments, but never in the production environment. The only difference between the 3 environments is that the production environment has a much heavier load than the test and development environments put together. The OS, OS patches, iPlanet version and PHP version are all exactly the same in all 3 web server environments. The fact that you cannot produce the crash in your environment can be related to the light load on your test set up. As mentioned in my last bug report (#32491), I have Java enabled (Very memory intensive) on the web server and our production environment mostly uses JSP and Java servlets. [2005-04-07 18:16:32] Oscar dot Castillo at jpl dot nasa dot gov I installed the latest CVS as of Tuesday 4/5/2005 which was php5-STABLE-200504052230. A php_info() function call shows the version as 5.0.5-dev. When I recycle the web server daemon, PHP runs fine. Before I upgraded to this CVS it usually took about 4 hours to begin failing depending on the load on my production web server. It used to say "File upload error - unable to create a temporary file in Unknown on line 0" after the maximum number of file descriptors limit was reached which took about 4 - 24 hours after recycling the web server daemon. After I upgraded to PHP 5.0.5-dev, the PHP environment works fine for about 4 - 24 hours. The functioning time varies with the load on the web server and the web server crashes while when any PHP script is accessed once this "limit" is reached. [2005-04-07 08:20:19] [EMAIL PROTECTED] Crahes it always when trying to access a PHP or only when it uploads a file? On my servers here it worked, but I have not latest cvs - only a patched 5.0.4 - and: [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 - fread is not used anywhere in the changed code. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32614 -- Edit this bug report at http://bugs.php.net/?id=32614&edit=1
#32614 [Opn]: Crash occured in function fread from module /usr/lib/libc.so.1
ID: 32614 Updated by: [EMAIL PROTECTED] Reported By: Oscar dot Castillo at jpl dot nasa dot gov Status: Open Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 5CVS-2005-04-07 (dev) Assigned To: thetaphi New Comment: Info about the solaris "bug": http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr5q?a=view (see under "USAGE") In 64bit solaris it would work, but SunONE is a 32 bit server. Previous Comments: [2005-04-08 09:37:01] [EMAIL PROTECTED] I found the reason for the bug. The problem is not the file upload here that works now. The problem is now the same stdio related bug which leads to the segmentation fault. I fixed the CVS now not to crash the webserver in this error condition (missing an errorchecking at fdopen() which works on all platform without errors, on solaris fails when the filedescriptor>255). But the problem should still be there but you should get a message in your PHP script. Looking into your code I exspect the "execute" functions to fail because they need to cast a stream from posix to stdio. Please test the new CVS and tell me when the further handling of your uploaded file fails. [2005-04-07 18:27:43] Oscar dot Castillo at jpl dot nasa dot gov I also forgot to mention that I am running PHP 5.0.5-dev on 2 other web servers that are used for testing and development of Java, PERL and PHP applications prior to being delivered to the production environment. All flavors of PHP have always worked in the test and development environments, but never in the production environment. The only difference between the 3 environments is that the production environment has a much heavier load than the test and development environments put together. The OS, OS patches, iPlanet version and PHP version are all exactly the same in all 3 web server environments. The fact that you cannot produce the crash in your environment can be related to the light load on your test set up. As mentioned in my last bug report (#32491), I have Java enabled (Very memory intensive) on the web server and our production environment mostly uses JSP and Java servlets. [2005-04-07 18:16:32] Oscar dot Castillo at jpl dot nasa dot gov I installed the latest CVS as of Tuesday 4/5/2005 which was php5-STABLE-200504052230. A php_info() function call shows the version as 5.0.5-dev. When I recycle the web server daemon, PHP runs fine. Before I upgraded to this CVS it usually took about 4 hours to begin failing depending on the load on my production web server. It used to say "File upload error - unable to create a temporary file in Unknown on line 0" after the maximum number of file descriptors limit was reached which took about 4 - 24 hours after recycling the web server daemon. After I upgraded to PHP 5.0.5-dev, the PHP environment works fine for about 4 - 24 hours. The functioning time varies with the load on the web server and the web server crashes while when any PHP script is accessed once this "limit" is reached. [2005-04-07 08:20:19] [EMAIL PROTECTED] Crahes it always when trying to access a PHP or only when it uploads a file? On my servers here it worked, but I have not latest cvs - only a patched 5.0.4 - and: [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 - fread is not used anywhere in the changed code. [2005-04-07 00:45:38] Oscar dot Castillo at jpl dot nasa dot gov Description: As instructed by BUG#32491, I installed PHP 5.0.5 to fix my "File upload error" problem. Previously, the iPlanet 6.0 SP5 web server would simply produce a "File upload error" message. Now the web server crashes and the following message is output to the web server's error log file: [06/Apr/2005:10:13:01] catastrophe (13578): Server crash detected (signal SIGSEGV) [06/Apr/2005:10:13:01] info (13578): Crash occurred in NSAPI SAF php5_execute [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 [06/Apr/2005:10:13:01] failure (13576): Child process admin thread is shutting down [06/Apr/2005:10:13:02] info (19023): Installing a new configuration [06/Apr/2005:10:13:02] info (19023): [LS ls1] https://128.149.147.181, port 443 ready to accept requests [06/Apr/2005:10:13:02] info (19023): A new configuration was successfully installed Reproduce code: --- Please see the Reproduce code for BUG#32491 Expected result: Successful file upload Actual result: -- [06/Apr/2005:10:13:01] catastrophe (13578): Server crash detected (signal SIGSEGV) [06/Apr/
#32614 [Opn]: Crash occured in function fread from module /usr/lib/libc.so.1
ID: 32614 Updated by: [EMAIL PROTECTED] Reported By: Oscar dot Castillo at jpl dot nasa dot gov Status: Open Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 5CVS-2005-04-07 (dev) -Assigned To: +Assigned To: thetaphi New Comment: I found the reason for the bug. The problem is not the file upload here that works now. The problem is now the same stdio related bug which leads to the segmentation fault. I fixed the CVS now not to crash the webserver in this error condition (missing an errorchecking at fdopen() which works on all platform without errors, on solaris fails when the filedescriptor>255). But the problem should still be there but you should get a message in your PHP script. Looking into your code I exspect the "execute" functions to fail because they need to cast a stream from posix to stdio. Please test the new CVS and tell me when the further handling of your uploaded file fails. Previous Comments: [2005-04-07 18:27:43] Oscar dot Castillo at jpl dot nasa dot gov I also forgot to mention that I am running PHP 5.0.5-dev on 2 other web servers that are used for testing and development of Java, PERL and PHP applications prior to being delivered to the production environment. All flavors of PHP have always worked in the test and development environments, but never in the production environment. The only difference between the 3 environments is that the production environment has a much heavier load than the test and development environments put together. The OS, OS patches, iPlanet version and PHP version are all exactly the same in all 3 web server environments. The fact that you cannot produce the crash in your environment can be related to the light load on your test set up. As mentioned in my last bug report (#32491), I have Java enabled (Very memory intensive) on the web server and our production environment mostly uses JSP and Java servlets. [2005-04-07 18:16:32] Oscar dot Castillo at jpl dot nasa dot gov I installed the latest CVS as of Tuesday 4/5/2005 which was php5-STABLE-200504052230. A php_info() function call shows the version as 5.0.5-dev. When I recycle the web server daemon, PHP runs fine. Before I upgraded to this CVS it usually took about 4 hours to begin failing depending on the load on my production web server. It used to say "File upload error - unable to create a temporary file in Unknown on line 0" after the maximum number of file descriptors limit was reached which took about 4 - 24 hours after recycling the web server daemon. After I upgraded to PHP 5.0.5-dev, the PHP environment works fine for about 4 - 24 hours. The functioning time varies with the load on the web server and the web server crashes while when any PHP script is accessed once this "limit" is reached. [2005-04-07 08:20:19] [EMAIL PROTECTED] Crahes it always when trying to access a PHP or only when it uploads a file? On my servers here it worked, but I have not latest cvs - only a patched 5.0.4 - and: [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 - fread is not used anywhere in the changed code. [2005-04-07 00:45:38] Oscar dot Castillo at jpl dot nasa dot gov Description: As instructed by BUG#32491, I installed PHP 5.0.5 to fix my "File upload error" problem. Previously, the iPlanet 6.0 SP5 web server would simply produce a "File upload error" message. Now the web server crashes and the following message is output to the web server's error log file: [06/Apr/2005:10:13:01] catastrophe (13578): Server crash detected (signal SIGSEGV) [06/Apr/2005:10:13:01] info (13578): Crash occurred in NSAPI SAF php5_execute [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 [06/Apr/2005:10:13:01] failure (13576): Child process admin thread is shutting down [06/Apr/2005:10:13:02] info (19023): Installing a new configuration [06/Apr/2005:10:13:02] info (19023): [LS ls1] https://128.149.147.181, port 443 ready to accept requests [06/Apr/2005:10:13:02] info (19023): A new configuration was successfully installed Reproduce code: --- Please see the Reproduce code for BUG#32491 Expected result: Successful file upload Actual result: -- [06/Apr/2005:10:13:01] catastrophe (13578): Server crash detected (signal SIGSEGV) [06/Apr/2005:10:13:01] info (13578): Crash occurred in NSAPI SAF php5_execute [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 [06/Apr/2005:10:13:01] failure (13576): Child process admin thread is shutting down [06/Apr/2005:
#32614 [Opn]: Crash occured in function fread from module /usr/lib/libc.so.1
ID: 32614 Updated by: [EMAIL PROTECTED] Reported By: Oscar dot Castillo at jpl dot nasa dot gov Status: Open Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 5CVS-2005-04-07 (dev) New Comment: Crahes it always when trying to access a PHP or only when it uploads a file? On my servers here it worked, but I have not latest cvs - only a patched 5.0.4 - and: [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 - fread is not used anywhere in the changed code. Previous Comments: [2005-04-07 00:45:38] Oscar dot Castillo at jpl dot nasa dot gov Description: As instructed by BUG#32491, I installed PHP 5.0.5 to fix my "File upload error" problem. Previously, the iPlanet 6.0 SP5 web server would simply produce a "File upload error" message. Now the web server crashes and the following message is output to the web server's error log file: [06/Apr/2005:10:13:01] catastrophe (13578): Server crash detected (signal SIGSEGV) [06/Apr/2005:10:13:01] info (13578): Crash occurred in NSAPI SAF php5_execute [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 [06/Apr/2005:10:13:01] failure (13576): Child process admin thread is shutting down [06/Apr/2005:10:13:02] info (19023): Installing a new configuration [06/Apr/2005:10:13:02] info (19023): [LS ls1] https://128.149.147.181, port 443 ready to accept requests [06/Apr/2005:10:13:02] info (19023): A new configuration was successfully installed Reproduce code: --- Please see the Reproduce code for BUG#32491 Expected result: Successful file upload Actual result: -- [06/Apr/2005:10:13:01] catastrophe (13578): Server crash detected (signal SIGSEGV) [06/Apr/2005:10:13:01] info (13578): Crash occurred in NSAPI SAF php5_execute [06/Apr/2005:10:13:01] info (13578): Crash occurred in function fread from module /usr/lib/libc.so.1 [06/Apr/2005:10:13:01] failure (13576): Child process admin thread is shutting down [06/Apr/2005:10:13:02] info (19023): Installing a new configuration [06/Apr/2005:10:13:02] info (19023): [LS ls1] https://128.149.147.181, port 443 ready to accept requests [06/Apr/2005:10:13:02] info (19023): A new configuration was successfully installed -- Edit this bug report at http://bugs.php.net/?id=32614&edit=1
