php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #37635 parameter of pcntl signal handler is trashed
Submitted: 2006-05-30 03:16 UTC Modified: 2006-05-30 17:42 UTC
From: aeolianmeson at blitzeclipse dot com Assigned:
Status: Closed Package: PCNTL related
PHP Version: 5.1.4 OS: Fedora 5
Private report: No CVE-ID: None
View Developer Edit
 [2006-05-30 03:16 UTC] aeolianmeson at blitzeclipse dot com 
Description:
------------
There is a problem with the type of the parameter sent to a signal-handling function.

If everytime the signal-handler adds the signal to an array, all array keys and values will become corrupted. The total number of array elements will be correct, but the actual values will sporadically become arrays, etc...

This happens whereever the signal parameter was used. If the parameter is typecast to an integer, it works perfectly. This  happens when the handler is both a function and a method.

Reproduce code:
---------------
<?php
print("pid= " . posix_getpid() . "\n");
declare(ticks=1);
$arrtemp = array();

function handler($nsig)
{
	global $arrtemp;
	$arrtemp[] = $nsig;
	print("Signal caught and registered.\n");
	var_dump($arrtemp);
}

pcntl_signal(SIGTERM, 'handler');
$n = 15;
while($n)
{
	sleep(1);
	$n--;
}
print("terminated.\n\n");
var_dump($arrtemp);
?>

Expected result:
----------------
As the process receives SIGTERMs from the commandline, the handler adds each signal value to the global array. When the program terminates, the list is dumped, and should contain a list containing the correct number of integers depicting the signals that were sent. The keys are normal indexes.

Actual result:
--------------
A list of the correct number of elements exists, however the actual values become something else when dumped at program termination.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-05-30 07:59 UTC] tony2001@php.net 
>A list of the correct number of elements exists, however 
>the actual values become something else when dumped at program termination.
I guess var_dump()'s output would worth all these words..
 [2006-05-30 16:27 UTC] aeolianmeson at blitzeclipse dot com 
Here you go. The signals received were just kills from another term. Again, this only happens after a number of signals, usually (like fifteen).

[root@dustin done]# php testtrap.php
Setting signal handlers ... Done
Generating signal to self...
Got signal 15
in SignalHandler:
array(2) {
  [0]=>
  string(18) "some initial state"
  [1]=>
  int(15)
}
Got signal 15
in SignalHandler:
array(3) {
  [0]=>
  string(18) "some initial state"
  [1]=>
  int(15)
  [2]=>
  int(15)
}
Got signal 15
in SignalHandler:
array(4) {
  [0]=>
  string(18) "some initial state"
  [1]=>
  int(15)
  [2]=>
  int(15)
  [3]=>
  int(15)
}
Main execution, looking at $jm object:
array(4) {
  [0]=>
  string(18) "some initial state"
  [1]=>
  int(15)
  [2]=>
  NULL
  [3]=>
  int(15)
}
*** glibc detected *** php: free(): invalid next size (fast): 0x083eb760 ***
======= Backtrace: =========
/lib/libc.so.6[0x6dcf18]
/lib/libc.so.6(__libc_free+0x79)[0x6e041d]
php(shutdown_memory_manager+0x7c)[0x81b528c]
php(php_request_shutdown+0x3c1)[0x818eb31]
php(main+0x3e2)[0x8241342]
/lib/libc.so.6(__libc_start_main+0xdc)[0x68e7e4]
php[0x80751b1]
======= Memory map: ========
00449000-0045a000 r-xp 00000000 03:02 1509399    /lib/libnsl-2.4.so
0045a000-0045b000 r--p 00010000 03:02 1509399    /lib/libnsl-2.4.so
0045b000-0045c000 rw-p 00011000 03:02 1509399    /lib/libnsl-2.4.so
0045c000-0045e000 rw-p 0045c000 00:00 0
00460000-0046f000 r-xp 00000000 03:02 1509394    /lib/libresolv-2.4.so
0046f000-00470000 r--p 0000e000 03:02 1509394    /lib/libresolv-2.4.so
00470000-00471000 rw-p 0000f000 03:02 1509394    /lib/libresolv-2.4.so
00471000-00473000 rw-p 00471000 00:00 0
00475000-00477000 r-xp 00000000 03:02 1509395    /lib/libcom_err.so.2.1
00477000-00478000 rw-p 00001000 03:02 1509395    /lib/libcom_err.so.2.1
0047a000-00492000 r-xp 00000000 03:02 488361     /usr/lib/libgssapi_krb5.so.2.2
00492000-00493000 rw-p 00017000 03:02 488361     /usr/lib/libgssapi_krb5.so.2.2
00495000-00498000 r-xp 00000000 03:02 483060     /usr/lib/libkrb5support.so.0.0
00498000-00499000 rw-p 00002000 03:02 483060     /usr/lib/libkrb5support.so.0.0
0049b000-005ba000 r-xp 00000000 03:02 1509396    /lib/libcrypto.so.0.9.8a
005ba000-005cd000 rw-p 0011e000 03:02 1509396    /lib/libcrypto.so.0.9.8a
005cd000-005d0000 rw-p 005cd000 00:00 0
005d2000-00645000 r-xp 00000000 03:02 488360     /usr/lib/libkrb5.so.3.2
00645000-00647000 rw-p 00073000 03:02 488360     /usr/lib/libkrb5.so.3.2
0065c000-00675000 r-xp 00000000 03:02 1509364    /lib/ld-2.4.so
00675000-00676000 r--p 00018000 03:02 1509364    /lib/ld-2.4.so
00676000-00677000 rw-p 00019000 03:02 1509364    /lib/ld-2.4.so
00679000-007a5000 r-xp 00000000 03:02 1509386    /lib/libc-2.4.so
007a5000-007a8000 r--p 0012b000 03:02 1509386    /lib/libc-2.4.so
007a8000-007a9000 rw-p 0012e000 03:02 1509386    /lib/libc-2.4.so
007a9000-007ac000 rw-p 007a9000 00:00 0
007ae000-007d1000 r-xp 00000000 03:02 1509387    /lib/libm-2.4.so
007d1000-007d2000 r--p 00022000 03:02 1509387    /lib/libm-2.4.so
007d2000-007d3000 rw-p 00023000 03:02 1509387    /lib/libm-2.4.so
007d5000-007d7000 r-xp 00000000 03:02 1509388    /lib/libdl-2.4.so
007d7000-007d8000 r--p 00001000 03:02 1509388    /lib/libdl-2.4.so
007d8000-007d9000 rw-p 00002000 03:02 1509388    /lib/libdl-2.4.so
007db000-007ed000 r-xp 00000000 03:02 488328     /usr/lib/libz.so.1.2.3
007ed000-007ee000 rw-p 00011000 03:02 488328     /usr/lib/libz.so.1.2.3
007f0000-007f1000 r-xp 00000000 03:02 486046     /usr/lib/libpspell.so.15.1.3
007f1000-007f2000 rw-p 00000000 03:02 486046     /usr/lib/libpspell.so.15.1.3
00828000-0085f000 r-xp 00000000 03:02 465226     /usr/lib/libcurl.so.3.0.0
0085f000-00860000 rw-p 00037000 03:02 465226     /usr/lib/libcurl.so.3.0.0
00862000-00924000 r-xp 00000000 03:02 482884     /usr/lib/libaspell.so.15.1.3
00924000-00929000 rw-p 000c1000 03:02 482884     /usr/lib/libaspell.so.15.1.3
00929000-0092d000 rw-p 00929000 00:00 0
009a1000-009b1000 r-xp 00000000 03:02 1509390    /lib/libpthread-2.4.so
009b1000-009b2000 r--p 0000f000 03:02 1509390    /lib/libpthread-2.4.so
009b2000-009b3000 rw-p 00010000 03:02 1509390    /lib/libpthread-2.4.so
009b3000-009b5000 rw-p 009b3000 00:00 0
00c25000-00c54000 r-xp 00000000 03:02 488350     /usr/lib/libidn.so.11.5.16
00c54000-00c55000 rw-p 0002f000 03:02 488350     /usr/lib/libidn.so.11.5.16
00c57000-00d4b000 r-xp 00000000 03:02 1500135    /lib/libdb-4.3.so
00d4b000-00d4e000 rw-p 000f4000 03:02 1500135    /lib/libdb-4.3.so
06c4c000-06c70000 r-xp 00000000 03:02 488359     /usr/lib/libk5crypto.so.3.0
06c70000-06c71000 rw-p 00024000 03:02 488359     /usr/lib/libk5crypto.so.3.0
06c73000-06cb4000 r-xp 00000000 03:02 1509397    /lib/libssl.so.0.9.8a
06cb4000-06cb8000 rw-p 00040000 03:02 1509397    /lib/libssl.so.0.9.8a
06cba000-06cd1000 r-xp 00000000 03:02 484011     /usr/lib/libsasl2.so.2.0.21
06cd1000-06cd2000 rw-p 00016000 03:0Aborted
[root@dustin done]#
 [2006-05-30 16:32 UTC] aeolianmeson at blitzeclipse dot com 
A little more info: The primary problem is that the types are changed. Notice that after a couple signals, the values of the global aray (which were the signals added as they were received), become something else than the original integer signal number. They will be fine, if the incoming signal number is typecast, though.

A second smaller problem that has been submitted to the security group was that more than a couple signals ellicits a memory dump at the end of the var_dump, as a part of it.

Dustin
 [2006-05-30 17:42 UTC] mike@php.net 
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Apr 07 12:01:29 2025 UTC