#34032 [Opn->Bgs]: Iteration Bug?
ID: 34032 Updated by: [EMAIL PROTECTED] Reported By: rsauqi at yahoo dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: WIndows XP Pro PHP Version: 5.0.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2005-08-08 07:05:33] rsauqi at yahoo dot com Description: I am using PHP 5.0.4 from XAMPP 1.4.14 Apache/2.0.54 (Win32) mod_ssl/2.0.54 OpenSSL/0.9.7g PHP/5.0.4 When I tried to create an iteration using for / foreach (quite long iteration, 1 to 1), unexpected result appear and its make my program 'error'. Reproduce code: --- "; } ?> Expected result: 0 until Actual result: -- 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766
#34033 [Opn->Csd]: strtotime doesn't parse "Sept."
ID: 34033
Updated by: [EMAIL PROTECTED]
Reported By: evanchaney at mac dot com
-Status: Open
+Status: Closed
Bug Type: Date/time related
Operating System: Mac OS X 10.4.2
PHP Version: 5.0.4
New Comment:
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.
Previous Comments:
[2005-08-08 08:37:44] evanchaney at mac dot com
Description:
The strtotime() function understands the month of September
when it is written "Sep.", "Sep" or "Sept", but not "Sept.".
Other months like October can be written with a period after
the month's abbreviation and parse just fine.
Reproduce code:
---
echo(strtotime('24 Sept. 72'));
Expected result:
86166000
Actual result:
--
-1
--
Edit this bug report at http://bugs.php.net/?id=34033&edit=1
#34030 [Opn->Fbk]: a pg_fetch_row result doesnt make string comparisons
ID: 34030 Updated by: [EMAIL PROTECTED] Reported By: mansilla_g at yahoo dot com -Status: Open +Status: Feedback Bug Type: PostgreSQL related Operating System: linux PHP Version: 4.3.11 New Comment: Instead of that echo $row[0]; do this: var_dump($row[0]); Previous Comments: [2005-08-08 04:26:22] mansilla_g at yahoo dot com i forgot, using "===" doenst work either but the most interesting if that you compare numbers it works, for example, lets suppose $Row[1] = 34030 then you compare, if ( $Row[1] == 34030) , it returns true :S [2005-08-08 03:54:44] mansilla_g at yahoo dot com Description: when you get a string from a pg_fetch_row function it cant be compared with other string correctly, but if you use odbc_fetch_row it works, note that i compare ($row[0] == "Guille"), even if i assign $a = "Guille" and then i try to compare ($row[0] == $a) i get a wrong result, but it i use odbc_fetch_row or odbc_fetch_array instead it works. Reproduce code: --- Expected result: Guille Guille is = Guille Actual result: -- Guille Guille is not Guille -- Edit this bug report at http://bugs.php.net/?id=34030&edit=1
#33995 [Opn->Bgs]: wrong WARNING message
ID: 33995 Updated by: [EMAIL PROTECTED] Reported By: zxc at zmail dot ru -Status: Open +Status: Bogus Bug Type: FTP related Operating System: Win2000 SP4 PHP Version: 4.4.0 New Comment: This isn't getting anywhere and as neither me or Tony can reproduce this with latest CVS -> bogus. Previous Comments: [2005-08-08 08:18:23] zxc at zmail dot ru sniper, how I show this WARNING again, I tell you FTP server software. I don't tell you it now because LAN has many different FTP server softwares. [2005-08-07 14:25:09] [EMAIL PROTECTED] Can you at least tell us WHAT ftp server software is it?! [2005-08-07 14:06:41] zxc at zmail dot ru Tony, it's very hard because all ftp servers are in private LAN. [2005-08-05 19:42:55] [EMAIL PROTECTED] What FTP server do you use? (software name, version etc.) Is it a public server? Can you give us it's IP/hostname? And probably we'll need an account there too, if it rejects anonymous logins. [2005-08-05 19:34:59] zxc at zmail dot ru sniper, I use 3 parameters: I have WARNING message (from "ftp_login()" function) if remote FTP server is FULL (many users etc.) But I must have boolean FALSE only from ftp_login() function in this case (without WARNING message), because I use prefix "@" before "ftp_login()". 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/33995 -- Edit this bug report at http://bugs.php.net/?id=33995&edit=1
#34008 [Opn->Fbk]: Make file error - make install does not work
ID: 34008 Updated by: [EMAIL PROTECTED] Reported By: ljanda at checkstop dot com -Status: Open +Status: Feedback Bug Type: *Compile Issues Operating System: SCO 5.05 PHP Version: 4.4.0 New Comment: Put that Makefile somewhere where I can see it. Previous Comments: [2005-08-08 01:16:48] ljanda at checkstop dot com [activating module `php4' in /usr/local/apache2/conf/httpd.conf] Installing PHP CLI binary:/usr/local/php/bin/ Installing PHP CLI man page: /usr/local/php/man/man1/ OVERALL_TARGET += /u/leroy/php4-STABLE-200508060247/ext/informix/ifx.c /bin/ksh: OVERALL_TARGET: not found gmake: *** [install-cli] Error 1 # gmake -v GNU Make version 3.78.1, by Richard Stallman and Roland McGrath. Built for i686-pc-sco3.2v5.0.5 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to . [2005-08-06 20:09:48] [EMAIL PROTECTED] No, the line does NOT need a tab. Install working 'make', such as the GNU Make.. [2005-08-06 05:52:30] ljanda at checkstop dot com The problem still exists. That line should have a tab. I can fix that but the stopping point is the "make install". make install OVERALL_TARGET += /u/leroy/php4-STABLE-200508060247/ext/informix/ifx.c sh: OVERALL_TARGET: not found *** Error code 1 (bu21) # [2005-08-05 22:28:47] [EMAIL PROTECTED] 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. Sometimes simple things cause big problems. It was actually just one missing empty line in the beginning of ext/informix/Makefile.frag [2005-08-05 20:48:46] ljanda at checkstop dot com OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c Also the above is supposed to be a directory?? failing in make install 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/34008 -- Edit this bug report at http://bugs.php.net/?id=34008&edit=1
#33995 [Fbk->Opn]: wrong WARNING message
ID: 33995 User updated by: zxc at zmail dot ru Reported By: zxc at zmail dot ru -Status: Feedback +Status: Open Bug Type: FTP related Operating System: Win2000 SP4 PHP Version: 4.4.0 New Comment: sniper, how I show this WARNING again, I tell you FTP server software. I don't tell you it now because LAN has many different FTP server softwares. Previous Comments: [2005-08-07 14:25:09] [EMAIL PROTECTED] Can you at least tell us WHAT ftp server software is it?! [2005-08-07 14:06:41] zxc at zmail dot ru Tony, it's very hard because all ftp servers are in private LAN. [2005-08-05 19:42:55] [EMAIL PROTECTED] What FTP server do you use? (software name, version etc.) Is it a public server? Can you give us it's IP/hostname? And probably we'll need an account there too, if it rejects anonymous logins. [2005-08-05 19:34:59] zxc at zmail dot ru sniper, I use 3 parameters: I have WARNING message (from "ftp_login()" function) if remote FTP server is FULL (many users etc.) But I must have boolean FALSE only from ftp_login() function in this case (without WARNING message), because I use prefix "@" before "ftp_login()". [2005-08-04 22:12:22] [EMAIL PROTECTED] You have to provide a working script. The one here can not work: ftp_login() expects 3 parameters, not 2.. (and I can't reproduce this with a proper script, even if the server shows errors) 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/33995 -- Edit this bug report at http://bugs.php.net/?id=33995&edit=1
#34033 [NEW]: strtotime doesn't parse "Sept."
From: evanchaney at mac dot com
Operating system: Mac OS X 10.4.2
PHP version: 5.0.4
PHP Bug Type: Date/time related
Bug description: strtotime doesn't parse "Sept."
Description:
The strtotime() function understands the month of September
when it is written "Sep.", "Sep" or "Sept", but not "Sept.".
Other months like October can be written with a period after
the month's abbreviation and parse just fine.
Reproduce code:
---
echo(strtotime('24 Sept. 72'));
Expected result:
86166000
Actual result:
--
-1
--
Edit bug report at http://bugs.php.net/?id=34033&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34033&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34033&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34033&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34033&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34033&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34033&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34033&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34033&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34033&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34033&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34033&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34033&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34033&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34033&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34033&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34033&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34033&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34033&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34033&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34033&r=mysqlcfg
#33876 [Com]: PDO misquotes/miscasts bool(false)
ID: 33876
Comment by: php dot net at sharpdreams dot com
Reported By: php at sagi dot org
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-07-27 (dev)
Assigned To: wez
New Comment:
I "fixed" this by binding the parameters as integers:
$bool = false;
$st = $db->prepare( "insert into foo ( bar ) values ( :bar )" );
$st->bindParam( ":bar", $boo, PDO_PARAM_INT );
$st->execute();
Add the following to your pgsql:
-- begin
CREATE OR REPLACE FUNCTION int_to_bool(int4)
RETURNS bool AS
$BODY$
select case
when $1 <> 0 then TRUE
else FALSE
end;
$BODY$
LANGUAGE 'sql' VOLATILE;
CREATE CAST (int4 AS bool)
WITH FUNCTION int_to_bool(int4)
AS ASSIGNMENT;
-- end
PDO converts true/false to 1/0 which pass into the cast function.
Couldn't get an implicit ''::bool cast working.
e.g.,
CREATE OR REPLACE FUNCTION text_to_bool(text)
RETURNS bool AS
$BODY$
select case
when $1 <> '' then TRUE
else FALSE
end;
$BODY$
LANGUAGE 'sql' VOLATILE;
CREATE CAST (text AS bool)
WITH FUNCTION text_to_bool(text)
AS ASSIGNMENT;
And then doing "select ''::bool;" didn't work. Doin "select
''::text::bool" did work, though, so you could factor that into your
PDO statements, too:
insert into foo(bar) values(:bar::text);
which will call the above cast ('' -> text -> bool).
Previous Comments:
[2005-07-27 17:15:10] php at sagi dot org
For what it's worth, its seems like the pgsql _client_ library that my
installation is compiled against is v7.4.7, even though the server is
running v8.0.
So I guess it never used native prepared statements and the workaround
that you suggested had no affect - they're already disabled.
[2005-07-27 16:40:54] php at sagi dot org
Nope, still get the same exception and the same query is being executed
according to the server log.
Still using the same php5-200507261230 snapshot.
The exact code:
$res = $db->prepare(
'SELECT id,name,trial FROM shops WHERE trial = ?',
array(PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT =>
true)
);
$res->execute(array(false));
And the result:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input
syntax for type boolean: ""' in /home/shopy/dev/tmp/test.php:12
Stack trace:
#0 /home/shopy/dev/tmp/test.php(12): PDOStatement->execute(Array)
#1 {main}
thrown in /home/shopy/dev/tmp/test.php on line 12
[2005-07-27 16:25:22] [EMAIL PROTECTED]
Try this as a workaround for now:
$res = $db->prepare('SELECT ...', array(
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT => true
));
You can blame the pretty poor native prepared statement API in pgsql
for this one; it just doesn't tell PDO anything about the parameter
types so it can't make an informed decision about how to treat the
parameters.
[2005-07-27 15:56:26] php at sagi dot org
I know how string casting works, but this is not a string.
PDO knows, for example, how to convert PHP NULL to SQL NULL and not
string('') (like string casting does). Why can't it cast bool values to
an integer instead?
This behavior is bad. PDO knows how to cast the value to real php bool
when selecting, but cannot cast it back when inserting/updating, which
means a simple attempt to re-insert a row that has just been selected,
using the same object, fails.
[2005-07-27 15:16:02] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected behaviour, when cast to a string bool false is
converted to "" while bool true converted to "1".
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/33876
--
Edit this bug report at http://bugs.php.net/?id=33876&edit=1
#34030 [Opn]: a pg_fetch_row result doesnt make string comparisons
ID: 34030 User updated by: mansilla_g at yahoo dot com Reported By: mansilla_g at yahoo dot com Status: Open Bug Type: PostgreSQL related Operating System: linux PHP Version: 4.3.11 New Comment: i forgot, using "===" doenst work either but the most interesting if that you compare numbers it works, for example, lets suppose $Row[1] = 34030 then you compare, if ( $Row[1] == 34030) , it returns true :S Previous Comments: [2005-08-08 03:54:44] mansilla_g at yahoo dot com Description: when you get a string from a pg_fetch_row function it cant be compared with other string correctly, but if you use odbc_fetch_row it works, note that i compare ($row[0] == "Guille"), even if i assign $a = "Guille" and then i try to compare ($row[0] == $a) i get a wrong result, but it i use odbc_fetch_row or odbc_fetch_array instead it works. Reproduce code: --- Expected result: Guille Guille is = Guille Actual result: -- Guille Guille is not Guille -- Edit this bug report at http://bugs.php.net/?id=34030&edit=1
#34030 [NEW]: a pg_fetch_row result doesnt make string comparisons
From: mansilla_g at yahoo dot com Operating system: linux PHP version: 4.3.11 PHP Bug Type: PostgreSQL related Bug description: a pg_fetch_row result doesnt make string comparisons Description: when you get a string from a pg_fetch_row function it cant be compared with other string correctly, but if you use odbc_fetch_row it works, note that i compare ($row[0] == "Guille"), even if i assign $a = "Guille" and then i try to compare ($row[0] == $a) i get a wrong result, but it i use odbc_fetch_row or odbc_fetch_array instead it works. Reproduce code: --- Expected result: Guille Guille is = Guille Actual result: -- Guille Guille is not Guille -- Edit bug report at http://bugs.php.net/?id=34030&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34030&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34030&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34030&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34030&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34030&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34030&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34030&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34030&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34030&r=support Expected behavior: http://bugs.php.net/fix.php?id=34030&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34030&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34030&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34030&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34030&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34030&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34030&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34030&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34030&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34030&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34030&r=mysqlcfg
#34008 [Bgs->Opn]: Make file error - make install does not work
ID: 34008 User updated by: ljanda at checkstop dot com -Summary: Make file error Reported By: ljanda at checkstop dot com -Status: Bogus +Status: Open Bug Type: *Compile Issues Operating System: SCO 5.05 PHP Version: 4.4.0 New Comment: [activating module `php4' in /usr/local/apache2/conf/httpd.conf] Installing PHP CLI binary:/usr/local/php/bin/ Installing PHP CLI man page: /usr/local/php/man/man1/ OVERALL_TARGET += /u/leroy/php4-STABLE-200508060247/ext/informix/ifx.c /bin/ksh: OVERALL_TARGET: not found gmake: *** [install-cli] Error 1 # gmake -v GNU Make version 3.78.1, by Richard Stallman and Roland McGrath. Built for i686-pc-sco3.2v5.0.5 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to . Previous Comments: [2005-08-06 20:09:48] [EMAIL PROTECTED] No, the line does NOT need a tab. Install working 'make', such as the GNU Make.. [2005-08-06 05:52:30] ljanda at checkstop dot com The problem still exists. That line should have a tab. I can fix that but the stopping point is the "make install". make install OVERALL_TARGET += /u/leroy/php4-STABLE-200508060247/ext/informix/ifx.c sh: OVERALL_TARGET: not found *** Error code 1 (bu21) # [2005-08-05 22:28:47] [EMAIL PROTECTED] 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. Sometimes simple things cause big problems. It was actually just one missing empty line in the beginning of ext/informix/Makefile.frag [2005-08-05 20:48:46] ljanda at checkstop dot com OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c Also the above is supposed to be a directory?? failing in make install [2005-08-05 20:47:13] ljanda at checkstop dot com Have no access to other servers 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/34008 -- Edit this bug report at http://bugs.php.net/?id=34008&edit=1
#31618 [Asn->Opn]: is_readable() results based on ownership of calling script, not file
ID: 31618
Updated by: [EMAIL PROTECTED]
Reported By: kibab at icehouse dot net
-Status: Assigned
+Status: Open
Bug Type: Filesystem function related
Operating System: redhat enterprise
PHP Version: 5CVS-2005-03-14
Assigned To: wez
Previous Comments:
[2005-05-19 06:14:33] kibab at icehouse dot net
>From memory, all files were mode 664 and all directories
had permissions of 775 being owned by root:root. However,
I no longer have that same structure to prove that. If
you like, I can setup an almost identical test case using
the code that I included below (but using my new
structure).
[2005-05-17 17:18:48] [EMAIL PROTECTED]
What are the permissions of all the directories in that path?
(/var/lib/php_packages/)
[2005-01-20 22:32:24] kibab at icehouse dot net
Maybe this isn't directly related, but
fopen($myfilename,"r") also fails, even though
include($myfilename) works. Again, $myfilename is in the
safe_mode_include_dir, so fopen should be able to open it.
[2005-01-19 23:05:35] kibab at icehouse dot net
Description:
is_readable($myfilename) in the repro code returns true if
the script calling it is owned by root, but false if it is
owned by someone else.
Permissions are:
-rw-r--r--1 root root 5452 Jan 13
13:02 /var/lib/php_packages/test_templ2.php
drwxr-xr-x4 root root 4096 Jan 19
08:19 /var/lib/php_packages
drwxr-xr-x 27 root root 4096 Jan 12
09:27 /var/lib
drwxr-xr-x 24 root root 4096 Sep 22
13:06 /var
drwxr-xr-x 20 root root 4096 Oct 29 09:48 /
Relevant Settings:
include_path =
".:/var/lib/php_packages:/var/lib/php_packages/pear"
safe_mode = On
safe_mode_gid = On
safe_mode_include_dir = /var/lib/php_packages
Reproduce code:
---
test.php ###
$myfilename = '/var/lib/php_packages/test_templ2.php';
if (is_readable($myfilename)) {
echo "is_readable: $myfilename (true)";
} else {
echo "is_readable: $myfilename (false)";
}
include($myfilename);
### test_templ2.php ###
TESTING!
Expected result:
I would expect is_readable() to return true in both
instances. The uid/gid check shouldn't matter despite
safe mode, as the file is in safe_mode_include_dir, and
even if it wasn't, the is_readable documentation says that
it does NOT take into account safe_mode restrictions.
Actual result:
--
// When test.php has the following ownership:
$ ls -l test.php
-rw-rw-r--1 root root 278 Jan 19 13:16
test.php
// I get the following output:
is_readable: /var/lib/php_packages/test_templ2.php (true)
TESTING!
// When test.php has the following permissions:
$ ls -l test.php
-rw-rw-r--1 dschlegel79 undergradadmiss 278 Jan
19 13:16 test.php
// I get the following output:
is_readable: /var/lib/php_packages/test_templ2.php (false)
TESTING!
--
Edit this bug report at http://bugs.php.net/?id=31618&edit=1
#31618 [Opn->Asn]: is_readable() results based on ownership of calling script, not file
ID: 31618
Updated by: [EMAIL PROTECTED]
Reported By: kibab at icehouse dot net
-Status: Open
+Status: Assigned
Bug Type: Filesystem function related
Operating System: redhat enterprise
PHP Version: 5CVS-2005-03-14
-Assigned To:
+Assigned To: wez
Previous Comments:
[2005-06-12 14:47:35] [EMAIL PROTECTED]
yet-another-streams-issue
[2005-05-19 06:14:33] kibab at icehouse dot net
>From memory, all files were mode 664 and all directories
had permissions of 775 being owned by root:root. However,
I no longer have that same structure to prove that. If
you like, I can setup an almost identical test case using
the code that I included below (but using my new
structure).
[2005-05-17 17:18:48] [EMAIL PROTECTED]
What are the permissions of all the directories in that path?
(/var/lib/php_packages/)
[2005-01-20 22:32:24] kibab at icehouse dot net
Maybe this isn't directly related, but
fopen($myfilename,"r") also fails, even though
include($myfilename) works. Again, $myfilename is in the
safe_mode_include_dir, so fopen should be able to open it.
[2005-01-19 23:05:35] kibab at icehouse dot net
Description:
is_readable($myfilename) in the repro code returns true if
the script calling it is owned by root, but false if it is
owned by someone else.
Permissions are:
-rw-r--r--1 root root 5452 Jan 13
13:02 /var/lib/php_packages/test_templ2.php
drwxr-xr-x4 root root 4096 Jan 19
08:19 /var/lib/php_packages
drwxr-xr-x 27 root root 4096 Jan 12
09:27 /var/lib
drwxr-xr-x 24 root root 4096 Sep 22
13:06 /var
drwxr-xr-x 20 root root 4096 Oct 29 09:48 /
Relevant Settings:
include_path =
".:/var/lib/php_packages:/var/lib/php_packages/pear"
safe_mode = On
safe_mode_gid = On
safe_mode_include_dir = /var/lib/php_packages
Reproduce code:
---
test.php ###
$myfilename = '/var/lib/php_packages/test_templ2.php';
if (is_readable($myfilename)) {
echo "is_readable: $myfilename (true)";
} else {
echo "is_readable: $myfilename (false)";
}
include($myfilename);
### test_templ2.php ###
TESTING!
Expected result:
I would expect is_readable() to return true in both
instances. The uid/gid check shouldn't matter despite
safe mode, as the file is in safe_mode_include_dir, and
even if it wasn't, the is_readable documentation says that
it does NOT take into account safe_mode restrictions.
Actual result:
--
// When test.php has the following ownership:
$ ls -l test.php
-rw-rw-r--1 root root 278 Jan 19 13:16
test.php
// I get the following output:
is_readable: /var/lib/php_packages/test_templ2.php (true)
TESTING!
// When test.php has the following permissions:
$ ls -l test.php
-rw-rw-r--1 dschlegel79 undergradadmiss 278 Jan
19 13:16 test.php
// I get the following output:
is_readable: /var/lib/php_packages/test_templ2.php (false)
TESTING!
--
Edit this bug report at http://bugs.php.net/?id=31618&edit=1
#31594 [Opn->Fbk]: virtual(): Unable to include 'xxx' - error finding URI
ID: 31594 Updated by: [EMAIL PROTECTED] Reported By: per at computer dot org -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: linux 2.4.26 -PHP Version: 5.0.4, 4.3.11 +PHP Version: 5.*, 4.* New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-06-19 11:33:09] per at computer dot org Just checked 4.4.0RC1 - problem still exists. [2005-06-06 20:07:36] per at computer dot org And equally obvious - to me at least - the answer can't be "don't do that" when it works just fine in 4.3.8, but not in the later releases ... [2005-06-06 20:01:04] [EMAIL PROTECTED] Well, obviously we can't remove set_locale. [2005-06-06 19:58:43] per at computer dot org Also, I must point out that it worked perfectly well in 4.3.8, so something was quite obviously regressed. [2005-06-06 19:57:20] per at computer dot org If the answer is "don't do that", what is the setlocale() doing in php in the first place? If it doesn't work, setlocale() should be _disabled_ when used under Apache (but perhaps not in CLI mode). 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/31594 -- Edit this bug report at http://bugs.php.net/?id=31594&edit=1
#29955 [Ana->Asn]: mb_strtoupper() / lower() broken with some locale
ID: 29955 Updated by: [EMAIL PROTECTED] Reported By: jan at horde dot org -Status: Analyzed +Status: Assigned Bug Type: mbstring related Operating System: Linux PHP Version: 5CVS, 4CVS (2004-09-02) -Assigned To: +Assigned To: moriyoshi New Comment: Are you going to fix this or not? If not, change the status to 'wont fix'. Previous Comments: [2005-05-13 08:00:26] [EMAIL PROTECTED] Turkish locale would need complete overhaul on the entire extension because the locale's character properties and required case folding behaviour are very special. PHP-ICU extension could support anything, but that's just an ongoing work by l0t3k. [2005-05-13 02:26:18] mustafa at deu dot edu dot tr I get the same results like jan. I need to get UTF-8 output for consuming a web service and I configured my php 5.0.4 with --enable-mbstring=all parameter (on linux that has been set with Turkish locale) I see that mbstring extension has limited language support in source code. (German, English, Japanese, Korean, Russian, Chinese) Is there a way to add our (Turkish) language to source code? Any references about this extension's source? [2005-02-22 11:10:06] [EMAIL PROTECTED] It turned out this is because mbstring doesn't take the locale into consideration. [2005-02-21 20:51:07] jan at horde dot org No, this didn't change anything. [2005-02-21 11:02:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 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/29955 -- Edit this bug report at http://bugs.php.net/?id=29955&edit=1
#28038 [Asn]: Sent incorrect RCPT TO commands to SMTP server
ID: 28038 Updated by: [EMAIL PROTECTED] Reported By: jordi at jcanals dot net Status: Assigned Bug Type: Mail related Operating System: win32 PHP Version: 5CVS, 4CVS (2005-08-08) Assigned To: wez New Comment: See also: #32600 (rpath set wrong too) Previous Comments: [2005-01-25 00:26:34] [EMAIL PROTECTED] The above patch is wrong. Only acceptable form for RCPT TO: is: RCPT TO:<[EMAIL PROTECTED]> Notice the brackets. Do not confuse yourself with RFC2822.. It does not obsolete 2821 as it talks about different thing. So the fix is to drop the outside brackets stuff out of the addresses. [2004-08-06 01:59:45] papercrane at reversefold dot com Here's a possible patch for it. It's pretty simplistic, bit it should work: http://www.reversefold.com/sendmail.c.patch Full file: http://www.reversefold.com/sendmail.c NOTE: I haven't actually *tested* this, it may not even compile. If it doesn't, please send me a note and I'll try to fix it. [2004-04-17 19:14:01] jordi at jcanals dot net Description: In windows, and using an SMTP server, when you try to send a mail using the mail function the SMTP transaction will fail if you include recipient names. When including any recipient header in the following format (wich follows the RFC 2822), the mail function does not handle it properly: To: User Name <[EMAIL PROTECTED]> Cc: Other User <[EMAIL PROTECTED]> Bcc: Third User <[EMAIL PROTECTED]> Loking at the SMTP transaction, the PHP mail layer sends this RCPT commands wich do not folow the SMTP standard stated on RFC 2821: RCPT TO:> RCPT TO:> RCPT TO:> Fails always with this environments: Tested on Windows XP, Apache 2.0.49, PHP 4.3.6 (Also in 4.3.4) Tested also on Windows 2000, IIS, PHP 4.3.6 Tested Using SMTP servers on Linux with Exim and Sendmail. Tested also using the default Windows 2000 SMTP server. Reproduce code: --- // SAMPLE 1: $to_recipient = "User Name <[EMAIL PROTECTED]>"; $header = "Cc: Other User <[EMAIL PROTECTED]>\r\n"; $header .= "Bcc: Third User <[EMAIL PROTECTED]>\r\n"; mail($to_recipient, $subject, $body, $header); // FAILS with SMTP errors for all three recipients. SAMPLE 2: $to_recipient = "[EMAIL PROTECTED]"; $header = "To: User Name <[EMAIL PROTECTED]>\r\n"; $header .= "Cc: Other User <[EMAIL PROTECTED]>\r\n"; $header .= "Bcc: Third User <[EMAIL PROTECTED]>\r\n"; mail($to_recipient, $subject, $body, $header); FAILS on with SMTP error on the three recipients passed on the $header field. Expected result: Expected that the mail layer exctracts only the mail address from recipients to send the SMTP commands: As seen on the RFC's 2821 and 2822, when sending a mail with the recipient headers formed like above, it is expected the mail layer to extract ONLY the email address to send the RCPT commands, and pass the headers without any change in the DATA command during the SMTP transaction. Example of the correct SMTP transaction for the above headers: RCPT TO:<[EMAIL PROTECTED]> RCPT TO:<[EMAIL PROTECTED]> RCPT TO:<[EMAIL PROTECTED]> DATA To: User Name <[EMAIL PROTECTED]> Cc: Other User <[EMAIL PROTECTED]> Bcc: Third User <[EMAIL PROTECTED]> Actual result: -- You get that error for all recipients with the recipient name: Warning: mail(): SMTP server response: 501 >: "@" or "." expected after "SomeOne" in mail.class.php on line 333 This error is produced when the mail layer is sending a wrong formed RCPT TO: command in the SMTP transaction. -- Edit this bug report at http://bugs.php.net/?id=28038&edit=1
#32600 [Opn->Bgs]: PHP sets return-path incorrectly
ID: 32600 Updated by: [EMAIL PROTECTED] Reported By: freddie at vbulletin dot com -Status: Open +Status: Bogus Bug Type: Mail related Operating System: Win32 PHP Version: 5.0.4 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Same as bug #28038 (It's a general problem with address formatting) Previous Comments: [2005-04-06 01:07:49] freddie at vbulletin dot com Correction: RPath should be set to "[EMAIL PROTECTED]", not "<[EMAIL PROTECTED]>" [2005-04-06 01:03:55] freddie at vbulletin dot com Description: A new bug has been introduced with the bug fix listed at http://bugs.php.net/bug.php?id=28976 The above fix attempts to set a reverse-path based on the From: header if sendmail_from is undefined. The problem with this is that the From: header is taken verbatim and not formatted to the RFC 2822 specification. This results in the email being rejected by the server. Reproduce code: --- Example: $headers .= "From: \"Example User\" <[EMAIL PROTECTED]>"; PHP will then set the RPath to "\"Example User\" <[EMAIL PROTECTED]>" when it should be "<[EMAIL PROTECTED]>" Expected result: Line 440 win32/sendmail.c: snprintf(Buffer, MAIL_BUFFER_SIZE, "MAIL FROM:<[EMAIL PROTECTED]>\r\n", RPath); Actual result: -- Line 440 win32/sendmail.c: snprintf(Buffer, MAIL_BUFFER_SIZE, "MAIL FROM:>\r\n", RPath); -- Edit this bug report at http://bugs.php.net/?id=32600&edit=1
#33997 [Opn->Asn]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Assigned Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 5CVS, 4CVS (2005-08-04) -Assigned To: +Assigned To: derick New Comment: Assigning to Derick who's comment about my patch was "It's funny" and other comment about the iconv code "this is a mess" :) Previous Comments: [2005-08-07 23:47:31] RVaughn at pheedo dot com The patch Sniper referred to: http://www.php.net/~jani/patches/bug33997.patch Does fix the bug properly and completely, we've tested it thoroughly, so I won't close this bug but I do think you can roll that patch forward into 4.4.1 as a fix and close this once that's done? Please let me know if there's anything else I can provide? Do you really need the .out and .exp if I can assure you the patch fixes the bug? Or do you want to see the results from the patched install? Thanks, Rob [2005-08-07 14:42:23] [EMAIL PROTECTED] Please provide a location where we can download your failed test's .out and .exp file. [2005-08-05 22:15:08] [EMAIL PROTECTED] Well, the patch is not approved/applied to CVS yet so keep this report open. We'll close this once the bug is really fixed. [2005-08-05 01:18:33] RVaughn at pheedo dot com Works perfectly! Hopefully this patch can be rolled into PHP 4.4.1? This one can be closed, that was the fix. Thanks much! Cheers! [2005-08-05 00:39:44] [EMAIL PROTECTED] This seems to fix the problem: http://www.php.net/~jani/patches/bug33997.patch I now get the correct result which I also got with the command line iconv tool. 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/33997 -- Edit this bug report at http://bugs.php.net/?id=33997&edit=1
#29334 [Opn->Csd]: mail() provides incorrect message time header
ID: 29334
Updated by: [EMAIL PROTECTED]
Reported By: php dot time dot bug at aaronoff dot com
-Status: Open
+Status: Closed
Bug Type: Mail related
Operating System: win32
PHP Version: 5CVS, 4CVS (2005-02-05)
New Comment:
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.
Fixed in PHP 5. Make sure you set "date.timezone" properly in your
php.ini or by using date_default_timezone_set() function.
The mail() function under win32 now uses same function as date("r");
does.
Previous Comments:
[2005-04-21 23:14:44] jbrady at sbccd dot cc dot ca dot us
We have 2 windows 2003 IIS6 servers with php 5.0.2 (build date Sep 24
2004 01:24:24) and php 5.0.3 (build date Dec 15 2004 08:06:41). We have
this same problem.
[2005-04-06 16:20:10] mike-php at emerge2 dot com
Interestingly, a call to date( 'r' ) returns the expected string, and
even pays attention to the setting in the Date Control Panel. Perhaps
mail() could simply call PHP's own date( 'r' ) function to create the
Date Header?
[2004-07-22 18:25:19] php dot time dot bug at aaronoff dot com
Description:
I'm using the mail() function to send a message from my home SMTP
server to my domain's SMTP server via my installation of MS IIS 5.0
SMTP under W2K SP4.
The time zone for my home PC is GMT +0200 in summer (with DST), +0100
in winter (w/o DST). In Windows Control Panel, Date/Time Properties,
Time Zone tab, the time zone shows as +0100 and "Automatically adjust
time for daylight saving changes" is checked. DST, then, increases the
offset on my PC from +0100 to +0200.
The e-mail message retrieved by my e-mail client from my domain's SMTP
server has a message header Date field set to the right hour but at GMT
offset +0100 -- this is the wrong time. Since my e-mail client displays
messages with time sent corrected to my local time, it adds an hour and
the message shows with a time one hour *ahead* of the time it was
actually sent.
Ex: message sent by mail() at 16:10 +0200
Date field in message header on home SMTP server shows 16:10 +0100
<-- this is the wrong time!
message sent by home SMTP server at 16:10 +0200
message received by e-mail client from domain at 16:11 +0200
e-mail client shows sent message time of 17:10 +0200
If a text message with just From:, To: and Subject: headers is dropped
into the home SMTP "Queue" folder, the home SMTP server adds the local
time with the correct GMT offset to the message header Date field. This
shows that the problem is not coming from the home SMTP server itself,
but from the program that's providing it with date information.
IMHO, mail() is not using the correcting the GMT offset for DST.
I've been unable to find any mention of an INI-file parameter for this,
Googling results were meager, and I found no open bugs.
HTH.
regards, Andy
Reproduce code:
---
mail($dest,$subject,$body)
Expected result:
The Date: field in the message's header should show the correct hour
and GMT offset.
Actual result:
--
The Date: field in the message's header shows the correct hour but the
wrong GMT offset -- it's not corrected for DST.
--
Edit this bug report at http://bugs.php.net/?id=29334&edit=1
#33997 [Fbk->Opn]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com -Status: Feedback +Status: Open Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 5CVS, 4CVS (2005-08-04) New Comment: The patch Sniper referred to: http://www.php.net/~jani/patches/bug33997.patch Does fix the bug properly and completely, we've tested it thoroughly, so I won't close this bug but I do think you can roll that patch forward into 4.4.1 as a fix and close this once that's done? Please let me know if there's anything else I can provide? Do you really need the .out and .exp if I can assure you the patch fixes the bug? Or do you want to see the results from the patched install? Thanks, Rob Previous Comments: [2005-08-07 14:42:23] [EMAIL PROTECTED] Please provide a location where we can download your failed test's .out and .exp file. [2005-08-05 22:15:08] [EMAIL PROTECTED] Well, the patch is not approved/applied to CVS yet so keep this report open. We'll close this once the bug is really fixed. [2005-08-05 01:18:33] RVaughn at pheedo dot com Works perfectly! Hopefully this patch can be rolled into PHP 4.4.1? This one can be closed, that was the fix. Thanks much! Cheers! [2005-08-05 00:39:44] [EMAIL PROTECTED] This seems to fix the problem: http://www.php.net/~jani/patches/bug33997.patch I now get the correct result which I also got with the command line iconv tool. [2005-08-04 23:34:18] RVaughn at pheedo dot com Do let me know if you want me to put the output somewhere on our site where it can be downloaded, the code itself is just the PHP-provided test: bug16069.phpt. Thanks! Cheers! 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/33997 -- Edit this bug report at http://bugs.php.net/?id=33997&edit=1
#34029 [Opn->Bgs]: Segmentation Fault when using Objects
ID: 34029
Updated by: [EMAIL PROTECTED]
Reported By: marhi at unix dot si
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: FreeBSD 5.4-STABLE
PHP Version: 5.0.4
New Comment:
The only result I can get with your code is an endless loop.
Not PHP bug.
Previous Comments:
[2005-08-07 23:32:31] marhi at unix dot si
I can't post all of the fpdf code here,
I'll paste a link:
http://www.fpdf.org/en/dl.php?v=153&f=tgz
[2005-08-07 23:27:16] [EMAIL PROTECTED]
Please provide a short but *complete* reproduce script so we can
copy/paste it and reproduce the problem. Thank you.
[2005-08-07 23:22:15] marhi at unix dot si
sety(-10); // <- segv?
$this->SetFont('arial','',8);
$this->Cell(0,10,'Toma\xbe Marhat s.p. / Brda 15 / 2383
\xa9martno pri Slovenj Gradcu / 051 350 234 / [EMAIL PROTECTED]','B',1,
'C');
}
}
class someClass {
public $doc;
function __construct() {
$this->doc =& new PDF(); }
public function make() {
$pdf = $this->doc;
$pdf->AddPage();
}
public function save() {
$pdf = $this->doc;
$pdf->output(); // <- segv?
}
}
$pdf = new someClass();
$pdf->make();
$pdf->save(); // <- segv? (output)
?>
[2005-08-07 22:58:27] [EMAIL PROTECTED]
This looks like a bug in your script, due to infinite recursion. Please
provide a short reproducable script that creates this segfault (10-20
lines max).
[2005-08-07 22:53:36] marhi at unix dot si
Description:
I'm writing a script that outputs an invoice in pdf.
I'm using FPDF for that. I had this sitem on php 4.4 before, but now it
doesn't work on php5, even more, it segvfaults.
I turned off all of the extentionts too. No luck.
Options:
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php'
'--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local'
'--enable-spl' '--with-regex=php' '--disable-cli'
'--with-apxs=/usr/local/sbin/apxs' '--prefix=/usr/local'
'i386-portbld-freebsd5.4'
Reproduce code:
---
http://gaming.si/billing/racun.phps
http://gaming.si/billing/test.phps
($bill->outp(); <- segvfault)
Expected result:
Dowload a PDF document.
Actual result:
--
Segmentation fault.
Backtrace:
#0 0x08134cc1 in execute ()
#1 0x08143d93 in zend_do_fcall_common_helper ()
#2 0x08134cce in execute ()
#3 0x08143d93 in zend_do_fcall_common_helper ()
#4 0x08134cce in execute ()
#5 0x08143d93 in zend_do_fcall_common_helper ()
#6 0x08134cce in execute ()
#7 0x08143d93 in zend_do_fcall_common_helper ()
#8 0x08134cce in execute ()
#9 0x08143d93 in zend_do_fcall_common_helper ()
#10 0x08134cce in execute ()
#11 0x08143d93 in zend_do_fcall_common_helper ()
#12 0x08134cce in execute ()
#13 0x08143d93 in zend_do_fcall_common_helper ()
#14 0x08134cce in execute ()
#15 0x08143d93 in zend_do_fcall_common_helper ()
#16 0x08134cce in execute ()
#17 0x08143d93 in zend_do_fcall_common_helper ()
#18 0x08134cce in execute ()
#19 0x08143d93 in zend_do_fcall_common_helper ()
#20 0x08134cce in execute ()
#21 0x08143d93 in zend_do_fcall_common_helper ()
#22 0x08134cce in execute ()
#23 0x08143d93 in zend_do_fcall_common_helper ()
#24 0x08134cce in execute ()
#25 0x08143d93 in zend_do_fcall_common_helper ()
#26 0x08134cce in execute ()
#27 0x08143d93 in zend_do_fcall_common_helper ()
#28 0x08134cce in execute ()
#29 0x08143d93 in zend_do_fcall_common_helper ()
#30 0x08134cce in execute ()
#31 0x08143d93 in zend_do_fcall_common_helper ()
#32 0x08134cce in execute ()
#33 0x08143d93 in zend_do_fcall_common_helper ()
#34 0x08134cce in execute ()
#35 0x08143d93 in zend_do_fcall_common_helper ()
#36 0x08134cce in execute ()
#37 0x08143d93 in zend_do_fcall_common_helper ()
#38 0x08134cce in execute ()
#39 0x08143d93 in zend_do_fcall_common_helper ()
#40 0x08134cce in execute ()
#41 0x08143d93 in zend_do_fcall_common_helper ()
#42 0x08134cce in execute ()
#43 0x08143d93 in zend_do_fcall_common_helper ()
#44 0x08134cce in execute ()
#45 0x08143d93 in zend_do_fcall_common_helper ()
#46 0x08134cce in execute ()
#47 0x08143d93 in zend_do_fcall_common_helper ()
#48 0x08134cce in execute ()
#49 0x08143d93 in zend_do_fcall_common_helper ()
#50 0x08134cce in execute ()
#51 0x08143d93 in zend_do_fcall_common_helper ()
#52 0x08134cce in execute ()
#53 0x08143d93 in zend_do_fcall_common_helper ()
#54 0x08134cce in execute ()
#55 0x08143d93
#34029 [Fbk->Opn]: Segmentation Fault when using Objects
ID: 34029
User updated by: marhi at unix dot si
Reported By: marhi at unix dot si
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD 5.4-STABLE
PHP Version: 5.0.4
New Comment:
I can't post all of the fpdf code here,
I'll paste a link:
http://www.fpdf.org/en/dl.php?v=153&f=tgz
Previous Comments:
[2005-08-07 23:27:16] [EMAIL PROTECTED]
Please provide a short but *complete* reproduce script so we can
copy/paste it and reproduce the problem. Thank you.
[2005-08-07 23:22:15] marhi at unix dot si
sety(-10); // <- segv?
$this->SetFont('arial','',8);
$this->Cell(0,10,'Toma\xbe Marhat s.p. / Brda 15 / 2383
\xa9martno pri Slovenj Gradcu / 051 350 234 / [EMAIL PROTECTED]','B',1,
'C');
}
}
class someClass {
public $doc;
function __construct() {
$this->doc =& new PDF(); }
public function make() {
$pdf = $this->doc;
$pdf->AddPage();
}
public function save() {
$pdf = $this->doc;
$pdf->output(); // <- segv?
}
}
$pdf = new someClass();
$pdf->make();
$pdf->save(); // <- segv? (output)
?>
[2005-08-07 22:58:27] [EMAIL PROTECTED]
This looks like a bug in your script, due to infinite recursion. Please
provide a short reproducable script that creates this segfault (10-20
lines max).
[2005-08-07 22:53:36] marhi at unix dot si
Description:
I'm writing a script that outputs an invoice in pdf.
I'm using FPDF for that. I had this sitem on php 4.4 before, but now it
doesn't work on php5, even more, it segvfaults.
I turned off all of the extentionts too. No luck.
Options:
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php'
'--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local'
'--enable-spl' '--with-regex=php' '--disable-cli'
'--with-apxs=/usr/local/sbin/apxs' '--prefix=/usr/local'
'i386-portbld-freebsd5.4'
Reproduce code:
---
http://gaming.si/billing/racun.phps
http://gaming.si/billing/test.phps
($bill->outp(); <- segvfault)
Expected result:
Dowload a PDF document.
Actual result:
--
Segmentation fault.
Backtrace:
#0 0x08134cc1 in execute ()
#1 0x08143d93 in zend_do_fcall_common_helper ()
#2 0x08134cce in execute ()
#3 0x08143d93 in zend_do_fcall_common_helper ()
#4 0x08134cce in execute ()
#5 0x08143d93 in zend_do_fcall_common_helper ()
#6 0x08134cce in execute ()
#7 0x08143d93 in zend_do_fcall_common_helper ()
#8 0x08134cce in execute ()
#9 0x08143d93 in zend_do_fcall_common_helper ()
#10 0x08134cce in execute ()
#11 0x08143d93 in zend_do_fcall_common_helper ()
#12 0x08134cce in execute ()
#13 0x08143d93 in zend_do_fcall_common_helper ()
#14 0x08134cce in execute ()
#15 0x08143d93 in zend_do_fcall_common_helper ()
#16 0x08134cce in execute ()
#17 0x08143d93 in zend_do_fcall_common_helper ()
#18 0x08134cce in execute ()
#19 0x08143d93 in zend_do_fcall_common_helper ()
#20 0x08134cce in execute ()
#21 0x08143d93 in zend_do_fcall_common_helper ()
#22 0x08134cce in execute ()
#23 0x08143d93 in zend_do_fcall_common_helper ()
#24 0x08134cce in execute ()
#25 0x08143d93 in zend_do_fcall_common_helper ()
#26 0x08134cce in execute ()
#27 0x08143d93 in zend_do_fcall_common_helper ()
#28 0x08134cce in execute ()
#29 0x08143d93 in zend_do_fcall_common_helper ()
#30 0x08134cce in execute ()
#31 0x08143d93 in zend_do_fcall_common_helper ()
#32 0x08134cce in execute ()
#33 0x08143d93 in zend_do_fcall_common_helper ()
#34 0x08134cce in execute ()
#35 0x08143d93 in zend_do_fcall_common_helper ()
#36 0x08134cce in execute ()
#37 0x08143d93 in zend_do_fcall_common_helper ()
#38 0x08134cce in execute ()
#39 0x08143d93 in zend_do_fcall_common_helper ()
#40 0x08134cce in execute ()
#41 0x08143d93 in zend_do_fcall_common_helper ()
#42 0x08134cce in execute ()
#43 0x08143d93 in zend_do_fcall_common_helper ()
#44 0x08134cce in execute ()
#45 0x08143d93 in zend_do_fcall_common_helper ()
#46 0x08134cce in execute ()
#47 0x08143d93 in zend_do_fcall_common_helper ()
#48 0x08134cce in execute ()
#49 0x08143d93 in zend_do_fcall_common_helper ()
#50 0x08134cce in execute ()
#51 0x08143d93 in zend_do_fcall_common_helper ()
#52 0x08134cce in execute ()
#53 0x08143d93 in zend_do_fcall_common_helper ()
#54 0x08134cce in execute ()
#55 0x08143d93 in zend_do_fcall_common_helper ()
same stuf
#35640 0x08134cce in execute ()
#35641 0x08143d93 in zend_do_fcall_common_helper ()
#35642 0x08134cce in execute ()
#35643 0x08143d93
#34029 [Opn->Fbk]: Segmentation Fault when using Objects
ID: 34029
Updated by: [EMAIL PROTECTED]
Reported By: marhi at unix dot si
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: FreeBSD 5.4-STABLE
PHP Version: 5.0.4
New Comment:
Please provide a short but *complete* reproduce script so we can
copy/paste it and reproduce the problem. Thank you.
Previous Comments:
[2005-08-07 23:22:15] marhi at unix dot si
sety(-10); // <- segv?
$this->SetFont('arial','',8);
$this->Cell(0,10,'Toma\xbe Marhat s.p. / Brda 15 / 2383
\xa9martno pri Slovenj Gradcu / 051 350 234 / [EMAIL PROTECTED]','B',1,
'C');
}
}
class someClass {
public $doc;
function __construct() {
$this->doc =& new PDF(); }
public function make() {
$pdf = $this->doc;
$pdf->AddPage();
}
public function save() {
$pdf = $this->doc;
$pdf->output(); // <- segv?
}
}
$pdf = new someClass();
$pdf->make();
$pdf->save(); // <- segv? (output)
?>
[2005-08-07 22:58:27] [EMAIL PROTECTED]
This looks like a bug in your script, due to infinite recursion. Please
provide a short reproducable script that creates this segfault (10-20
lines max).
[2005-08-07 22:53:36] marhi at unix dot si
Description:
I'm writing a script that outputs an invoice in pdf.
I'm using FPDF for that. I had this sitem on php 4.4 before, but now it
doesn't work on php5, even more, it segvfaults.
I turned off all of the extentionts too. No luck.
Options:
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php'
'--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local'
'--enable-spl' '--with-regex=php' '--disable-cli'
'--with-apxs=/usr/local/sbin/apxs' '--prefix=/usr/local'
'i386-portbld-freebsd5.4'
Reproduce code:
---
http://gaming.si/billing/racun.phps
http://gaming.si/billing/test.phps
($bill->outp(); <- segvfault)
Expected result:
Dowload a PDF document.
Actual result:
--
Segmentation fault.
Backtrace:
#0 0x08134cc1 in execute ()
#1 0x08143d93 in zend_do_fcall_common_helper ()
#2 0x08134cce in execute ()
#3 0x08143d93 in zend_do_fcall_common_helper ()
#4 0x08134cce in execute ()
#5 0x08143d93 in zend_do_fcall_common_helper ()
#6 0x08134cce in execute ()
#7 0x08143d93 in zend_do_fcall_common_helper ()
#8 0x08134cce in execute ()
#9 0x08143d93 in zend_do_fcall_common_helper ()
#10 0x08134cce in execute ()
#11 0x08143d93 in zend_do_fcall_common_helper ()
#12 0x08134cce in execute ()
#13 0x08143d93 in zend_do_fcall_common_helper ()
#14 0x08134cce in execute ()
#15 0x08143d93 in zend_do_fcall_common_helper ()
#16 0x08134cce in execute ()
#17 0x08143d93 in zend_do_fcall_common_helper ()
#18 0x08134cce in execute ()
#19 0x08143d93 in zend_do_fcall_common_helper ()
#20 0x08134cce in execute ()
#21 0x08143d93 in zend_do_fcall_common_helper ()
#22 0x08134cce in execute ()
#23 0x08143d93 in zend_do_fcall_common_helper ()
#24 0x08134cce in execute ()
#25 0x08143d93 in zend_do_fcall_common_helper ()
#26 0x08134cce in execute ()
#27 0x08143d93 in zend_do_fcall_common_helper ()
#28 0x08134cce in execute ()
#29 0x08143d93 in zend_do_fcall_common_helper ()
#30 0x08134cce in execute ()
#31 0x08143d93 in zend_do_fcall_common_helper ()
#32 0x08134cce in execute ()
#33 0x08143d93 in zend_do_fcall_common_helper ()
#34 0x08134cce in execute ()
#35 0x08143d93 in zend_do_fcall_common_helper ()
#36 0x08134cce in execute ()
#37 0x08143d93 in zend_do_fcall_common_helper ()
#38 0x08134cce in execute ()
#39 0x08143d93 in zend_do_fcall_common_helper ()
#40 0x08134cce in execute ()
#41 0x08143d93 in zend_do_fcall_common_helper ()
#42 0x08134cce in execute ()
#43 0x08143d93 in zend_do_fcall_common_helper ()
#44 0x08134cce in execute ()
#45 0x08143d93 in zend_do_fcall_common_helper ()
#46 0x08134cce in execute ()
#47 0x08143d93 in zend_do_fcall_common_helper ()
#48 0x08134cce in execute ()
#49 0x08143d93 in zend_do_fcall_common_helper ()
#50 0x08134cce in execute ()
#51 0x08143d93 in zend_do_fcall_common_helper ()
#52 0x08134cce in execute ()
#53 0x08143d93 in zend_do_fcall_common_helper ()
#54 0x08134cce in execute ()
#55 0x08143d93 in zend_do_fcall_common_helper ()
same stuf
#35640 0x08134cce in execute ()
#35641 0x08143d93 in zend_do_fcall_common_helper ()
#35642 0x08134cce in execute ()
#35643 0x08143d93 in zend_do_fcall_common_helper ()
#35644 0x08134cce in execute ()
#35645 0x08143d93 in zend_do_fcall_common_helper ()
#35646 0x08134cce in execute ()
#35647 0x08113648 in zend_execute_scripts ()
#35648 0x080da83f in php_
#34029 [Fbk->Opn]: Segmentation Fault when using Objects
ID: 34029
User updated by: marhi at unix dot si
Reported By: marhi at unix dot si
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD 5.4-STABLE
PHP Version: 5.0.4
New Comment:
sety(-10); // <- segv?
$this->SetFont('arial','',8);
$this->Cell(0,10,'Toma\xbe Marhat s.p. / Brda 15 / 2383
\xa9martno pri Slovenj Gradcu / 051 350 234 / [EMAIL PROTECTED]','B',1,
'C');
}
}
class someClass {
public $doc;
function __construct() {
$this->doc =& new PDF(); }
public function make() {
$pdf = $this->doc;
$pdf->AddPage();
}
public function save() {
$pdf = $this->doc;
$pdf->output(); // <- segv?
}
}
$pdf = new someClass();
$pdf->make();
$pdf->save(); // <- segv? (output)
?>
Previous Comments:
[2005-08-07 22:58:27] [EMAIL PROTECTED]
This looks like a bug in your script, due to infinite recursion. Please
provide a short reproducable script that creates this segfault (10-20
lines max).
[2005-08-07 22:53:36] marhi at unix dot si
Description:
I'm writing a script that outputs an invoice in pdf.
I'm using FPDF for that. I had this sitem on php 4.4 before, but now it
doesn't work on php5, even more, it segvfaults.
I turned off all of the extentionts too. No luck.
Options:
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php'
'--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local'
'--enable-spl' '--with-regex=php' '--disable-cli'
'--with-apxs=/usr/local/sbin/apxs' '--prefix=/usr/local'
'i386-portbld-freebsd5.4'
Reproduce code:
---
http://gaming.si/billing/racun.phps
http://gaming.si/billing/test.phps
($bill->outp(); <- segvfault)
Expected result:
Dowload a PDF document.
Actual result:
--
Segmentation fault.
Backtrace:
#0 0x08134cc1 in execute ()
#1 0x08143d93 in zend_do_fcall_common_helper ()
#2 0x08134cce in execute ()
#3 0x08143d93 in zend_do_fcall_common_helper ()
#4 0x08134cce in execute ()
#5 0x08143d93 in zend_do_fcall_common_helper ()
#6 0x08134cce in execute ()
#7 0x08143d93 in zend_do_fcall_common_helper ()
#8 0x08134cce in execute ()
#9 0x08143d93 in zend_do_fcall_common_helper ()
#10 0x08134cce in execute ()
#11 0x08143d93 in zend_do_fcall_common_helper ()
#12 0x08134cce in execute ()
#13 0x08143d93 in zend_do_fcall_common_helper ()
#14 0x08134cce in execute ()
#15 0x08143d93 in zend_do_fcall_common_helper ()
#16 0x08134cce in execute ()
#17 0x08143d93 in zend_do_fcall_common_helper ()
#18 0x08134cce in execute ()
#19 0x08143d93 in zend_do_fcall_common_helper ()
#20 0x08134cce in execute ()
#21 0x08143d93 in zend_do_fcall_common_helper ()
#22 0x08134cce in execute ()
#23 0x08143d93 in zend_do_fcall_common_helper ()
#24 0x08134cce in execute ()
#25 0x08143d93 in zend_do_fcall_common_helper ()
#26 0x08134cce in execute ()
#27 0x08143d93 in zend_do_fcall_common_helper ()
#28 0x08134cce in execute ()
#29 0x08143d93 in zend_do_fcall_common_helper ()
#30 0x08134cce in execute ()
#31 0x08143d93 in zend_do_fcall_common_helper ()
#32 0x08134cce in execute ()
#33 0x08143d93 in zend_do_fcall_common_helper ()
#34 0x08134cce in execute ()
#35 0x08143d93 in zend_do_fcall_common_helper ()
#36 0x08134cce in execute ()
#37 0x08143d93 in zend_do_fcall_common_helper ()
#38 0x08134cce in execute ()
#39 0x08143d93 in zend_do_fcall_common_helper ()
#40 0x08134cce in execute ()
#41 0x08143d93 in zend_do_fcall_common_helper ()
#42 0x08134cce in execute ()
#43 0x08143d93 in zend_do_fcall_common_helper ()
#44 0x08134cce in execute ()
#45 0x08143d93 in zend_do_fcall_common_helper ()
#46 0x08134cce in execute ()
#47 0x08143d93 in zend_do_fcall_common_helper ()
#48 0x08134cce in execute ()
#49 0x08143d93 in zend_do_fcall_common_helper ()
#50 0x08134cce in execute ()
#51 0x08143d93 in zend_do_fcall_common_helper ()
#52 0x08134cce in execute ()
#53 0x08143d93 in zend_do_fcall_common_helper ()
#54 0x08134cce in execute ()
#55 0x08143d93 in zend_do_fcall_common_helper ()
same stuf
#35640 0x08134cce in execute ()
#35641 0x08143d93 in zend_do_fcall_common_helper ()
#35642 0x08134cce in execute ()
#35643 0x08143d93 in zend_do_fcall_common_helper ()
#35644 0x08134cce in execute ()
#35645 0x08143d93 in zend_do_fcall_common_helper ()
#35646 0x08134cce in execute ()
#35647 0x08113648 in zend_execute_scripts ()
#35648 0x080da83f in php_execute_script ()
#35649 0x in ?? ()
#35650 0x0003 in ?? ()
#35651 0x in ?? ()
#35652 0xbfbfec20 in ?? ()
#35653 0x in ?? ()
#35654 0x0002 in ?? ()
#35655 0xc61333af in ?? ()
#35656 0x in ?? ()
#34029 [Opn->Fbk]: Segmentation Fault when using Objects
ID: 34029 Updated by: [EMAIL PROTECTED] Reported By: marhi at unix dot si -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 5.4-STABLE PHP Version: 5.0.4 New Comment: This looks like a bug in your script, due to infinite recursion. Please provide a short reproducable script that creates this segfault (10-20 lines max). Previous Comments: [2005-08-07 22:53:36] marhi at unix dot si Description: I'm writing a script that outputs an invoice in pdf. I'm using FPDF for that. I had this sitem on php 4.4 before, but now it doesn't work on php5, even more, it segvfaults. I turned off all of the extentionts too. No luck. Options: './configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-spl' '--with-regex=php' '--disable-cli' '--with-apxs=/usr/local/sbin/apxs' '--prefix=/usr/local' 'i386-portbld-freebsd5.4' Reproduce code: --- http://gaming.si/billing/racun.phps http://gaming.si/billing/test.phps ($bill->outp(); <- segvfault) Expected result: Dowload a PDF document. Actual result: -- Segmentation fault. Backtrace: #0 0x08134cc1 in execute () #1 0x08143d93 in zend_do_fcall_common_helper () #2 0x08134cce in execute () #3 0x08143d93 in zend_do_fcall_common_helper () #4 0x08134cce in execute () #5 0x08143d93 in zend_do_fcall_common_helper () #6 0x08134cce in execute () #7 0x08143d93 in zend_do_fcall_common_helper () #8 0x08134cce in execute () #9 0x08143d93 in zend_do_fcall_common_helper () #10 0x08134cce in execute () #11 0x08143d93 in zend_do_fcall_common_helper () #12 0x08134cce in execute () #13 0x08143d93 in zend_do_fcall_common_helper () #14 0x08134cce in execute () #15 0x08143d93 in zend_do_fcall_common_helper () #16 0x08134cce in execute () #17 0x08143d93 in zend_do_fcall_common_helper () #18 0x08134cce in execute () #19 0x08143d93 in zend_do_fcall_common_helper () #20 0x08134cce in execute () #21 0x08143d93 in zend_do_fcall_common_helper () #22 0x08134cce in execute () #23 0x08143d93 in zend_do_fcall_common_helper () #24 0x08134cce in execute () #25 0x08143d93 in zend_do_fcall_common_helper () #26 0x08134cce in execute () #27 0x08143d93 in zend_do_fcall_common_helper () #28 0x08134cce in execute () #29 0x08143d93 in zend_do_fcall_common_helper () #30 0x08134cce in execute () #31 0x08143d93 in zend_do_fcall_common_helper () #32 0x08134cce in execute () #33 0x08143d93 in zend_do_fcall_common_helper () #34 0x08134cce in execute () #35 0x08143d93 in zend_do_fcall_common_helper () #36 0x08134cce in execute () #37 0x08143d93 in zend_do_fcall_common_helper () #38 0x08134cce in execute () #39 0x08143d93 in zend_do_fcall_common_helper () #40 0x08134cce in execute () #41 0x08143d93 in zend_do_fcall_common_helper () #42 0x08134cce in execute () #43 0x08143d93 in zend_do_fcall_common_helper () #44 0x08134cce in execute () #45 0x08143d93 in zend_do_fcall_common_helper () #46 0x08134cce in execute () #47 0x08143d93 in zend_do_fcall_common_helper () #48 0x08134cce in execute () #49 0x08143d93 in zend_do_fcall_common_helper () #50 0x08134cce in execute () #51 0x08143d93 in zend_do_fcall_common_helper () #52 0x08134cce in execute () #53 0x08143d93 in zend_do_fcall_common_helper () #54 0x08134cce in execute () #55 0x08143d93 in zend_do_fcall_common_helper () same stuf #35640 0x08134cce in execute () #35641 0x08143d93 in zend_do_fcall_common_helper () #35642 0x08134cce in execute () #35643 0x08143d93 in zend_do_fcall_common_helper () #35644 0x08134cce in execute () #35645 0x08143d93 in zend_do_fcall_common_helper () #35646 0x08134cce in execute () #35647 0x08113648 in zend_execute_scripts () #35648 0x080da83f in php_execute_script () #35649 0x in ?? () #35650 0x0003 in ?? () #35651 0x in ?? () #35652 0xbfbfec20 in ?? () #35653 0x in ?? () #35654 0x0002 in ?? () #35655 0xc61333af in ?? () #35656 0x in ?? () #35657 0x0007 in ?? () #35658 0x in ?? () #35659 0x0080 in ?? () #35660 0x0818a260 in _CurrentRuneLocale () #35661 0x in ?? () #35662 0xbfbfd618 in ?? () #35663 0x2844a02a in ldexp () from /lib/libc.so.5 Previous frame inner to this frame (corrupt stack?) -- Edit this bug report at http://bugs.php.net/?id=34029&edit=1
#34029 [NEW]: Segmentation Fault when using Objects
From: marhi at unix dot si Operating system: FreeBSD 5.4-STABLE PHP version: 5.0.4 PHP Bug Type: Reproducible crash Bug description: Segmentation Fault when using Objects Description: I'm writing a script that outputs an invoice in pdf. I'm using FPDF for that. I had this sitem on php 4.4 before, but now it doesn't work on php5, even more, it segvfaults. I turned off all of the extentionts too. No luck. Options: './configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-spl' '--with-regex=php' '--disable-cli' '--with-apxs=/usr/local/sbin/apxs' '--prefix=/usr/local' 'i386-portbld-freebsd5.4' Reproduce code: --- http://gaming.si/billing/racun.phps http://gaming.si/billing/test.phps ($bill->outp(); <- segvfault) Expected result: Dowload a PDF document. Actual result: -- Segmentation fault. Backtrace: #0 0x08134cc1 in execute () #1 0x08143d93 in zend_do_fcall_common_helper () #2 0x08134cce in execute () #3 0x08143d93 in zend_do_fcall_common_helper () #4 0x08134cce in execute () #5 0x08143d93 in zend_do_fcall_common_helper () #6 0x08134cce in execute () #7 0x08143d93 in zend_do_fcall_common_helper () #8 0x08134cce in execute () #9 0x08143d93 in zend_do_fcall_common_helper () #10 0x08134cce in execute () #11 0x08143d93 in zend_do_fcall_common_helper () #12 0x08134cce in execute () #13 0x08143d93 in zend_do_fcall_common_helper () #14 0x08134cce in execute () #15 0x08143d93 in zend_do_fcall_common_helper () #16 0x08134cce in execute () #17 0x08143d93 in zend_do_fcall_common_helper () #18 0x08134cce in execute () #19 0x08143d93 in zend_do_fcall_common_helper () #20 0x08134cce in execute () #21 0x08143d93 in zend_do_fcall_common_helper () #22 0x08134cce in execute () #23 0x08143d93 in zend_do_fcall_common_helper () #24 0x08134cce in execute () #25 0x08143d93 in zend_do_fcall_common_helper () #26 0x08134cce in execute () #27 0x08143d93 in zend_do_fcall_common_helper () #28 0x08134cce in execute () #29 0x08143d93 in zend_do_fcall_common_helper () #30 0x08134cce in execute () #31 0x08143d93 in zend_do_fcall_common_helper () #32 0x08134cce in execute () #33 0x08143d93 in zend_do_fcall_common_helper () #34 0x08134cce in execute () #35 0x08143d93 in zend_do_fcall_common_helper () #36 0x08134cce in execute () #37 0x08143d93 in zend_do_fcall_common_helper () #38 0x08134cce in execute () #39 0x08143d93 in zend_do_fcall_common_helper () #40 0x08134cce in execute () #41 0x08143d93 in zend_do_fcall_common_helper () #42 0x08134cce in execute () #43 0x08143d93 in zend_do_fcall_common_helper () #44 0x08134cce in execute () #45 0x08143d93 in zend_do_fcall_common_helper () #46 0x08134cce in execute () #47 0x08143d93 in zend_do_fcall_common_helper () #48 0x08134cce in execute () #49 0x08143d93 in zend_do_fcall_common_helper () #50 0x08134cce in execute () #51 0x08143d93 in zend_do_fcall_common_helper () #52 0x08134cce in execute () #53 0x08143d93 in zend_do_fcall_common_helper () #54 0x08134cce in execute () #55 0x08143d93 in zend_do_fcall_common_helper () same stuf #35640 0x08134cce in execute () #35641 0x08143d93 in zend_do_fcall_common_helper () #35642 0x08134cce in execute () #35643 0x08143d93 in zend_do_fcall_common_helper () #35644 0x08134cce in execute () #35645 0x08143d93 in zend_do_fcall_common_helper () #35646 0x08134cce in execute () #35647 0x08113648 in zend_execute_scripts () #35648 0x080da83f in php_execute_script () #35649 0x in ?? () #35650 0x0003 in ?? () #35651 0x in ?? () #35652 0xbfbfec20 in ?? () #35653 0x in ?? () #35654 0x0002 in ?? () #35655 0xc61333af in ?? () #35656 0x in ?? () #35657 0x0007 in ?? () #35658 0x in ?? () #35659 0x0080 in ?? () #35660 0x0818a260 in _CurrentRuneLocale () #35661 0x in ?? () #35662 0xbfbfd618 in ?? () #35663 0x2844a02a in ldexp () from /lib/libc.so.5 Previous frame inner to this frame (corrupt stack?) -- Edit bug report at http://bugs.php.net/?id=34029&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34029&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34029&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34029&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34029&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34029&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34029&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34029&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34029&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34029&r=support Expected behavior: http://bugs.php.net/fix.php?id=34029&r=notwrong Not enough info: http
#34028 [Opn->Fbk]: socket_create_listen doesn't listen on all interfaces
ID: 34028 Updated by: [EMAIL PROTECTED] Reported By: alex at cedevices dot com -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: Windows 2000 PHP Version: 5.0.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2005-08-07 20:43:15] alex at cedevices dot com Description: Standard latest xampp setup (including PHP 5.0.4). When using socket_create_listen(port), it does not listen on all interfaces as the docs indicate that it would. I was unable to connect to the machine using anything other than localhost (127.0.0.1). The workaround is to use socket_create, socket_bind (with 0.0.0.0 as the address) and socket_listen to accomplish the same task. -- Edit this bug report at http://bugs.php.net/?id=34028&edit=1
#34028 [NEW]: socket_create_listen doesn't listen on all interfaces
From: alex at cedevices dot com Operating system: Windows 2000 PHP version: 5.0.4 PHP Bug Type: Sockets related Bug description: socket_create_listen doesn't listen on all interfaces Description: Standard latest xampp setup (including PHP 5.0.4). When using socket_create_listen(port), it does not listen on all interfaces as the docs indicate that it would. I was unable to connect to the machine using anything other than localhost (127.0.0.1). The workaround is to use socket_create, socket_bind (with 0.0.0.0 as the address) and socket_listen to accomplish the same task. -- Edit bug report at http://bugs.php.net/?id=34028&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34028&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34028&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34028&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34028&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34028&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34028&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34028&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34028&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34028&r=support Expected behavior: http://bugs.php.net/fix.php?id=34028&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34028&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34028&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34028&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34028&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34028&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34028&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34028&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34028&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34028&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34028&r=mysqlcfg
#34022 [Bgs->Csd]: prepared statement using blobs doesnt function
ID: 34022
User updated by: mike dot norton at ultisearch dot co dot uk
Reported By: mike dot norton at ultisearch dot co dot uk
-Status: Bogus
+Status: Closed
Bug Type: MySQLi related
Operating System: Fedora Core 3
PHP Version: 5.0.4
New Comment:
Seems to work with that function correctly
Previous Comments:
[2005-08-07 01:39:00] [EMAIL PROTECTED]
RTFM:
http://www.php.net/manual/en/function.mysqli-stmt-send-long-data.php
[2005-08-07 00:54:16] mike dot norton at ultisearch dot co dot uk
Description:
When using mysql with bind_params on blob data only the first 4 bytes
of data get included.
Reproduce code:
---
stmt_init();
$stmt->prepare("insert into user_image (image) values (?)");
$data = fread(fopen($filename, "rb"), filesize($filename));
$stmt->bind_param('b',$data); /* Prove that the $data variable
contains the correct data */
print $data;
$stmt->execute();
$stmt->close();
$mysqli->close();
?>
Expected result:
Image is displayed and image data is inserted into database
Actual result:
--
First 4K of image is inserted into database rest seems to be discarded
--
Edit this bug report at http://bugs.php.net/?id=34022&edit=1
#34027 [Opn->Bgs]: new line unix "\n" in hidden html are not recorded
ID: 34027
Updated by: [EMAIL PROTECTED]
Reported By: test2 at nicolap dot lautre dot net
-Status: Open
+Status: Bogus
Bug Type: Safe Mode/open_basedir
Operating System: linux
PHP Version: 5.0.4
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
.
Previous Comments:
[2005-08-07 17:05:24] test2 at nicolap dot lautre dot net
Description:
Hello,
run the following script and enter in the text area the
value :
line 1
line 2
';
$out .= '';
if (isset($_POST['body'])) {
$out .= $_POST['body'];
$out .= ''."\n";
} else {
$out .= ''."\n";
}
if (isset($_POST['body2']) && !empty($_POST['body2'])) {
if (strcmp($body, $body2)) {
$out .= "strings are the same !";
} else {
$out .= "strings are not the same !".
$_POST['body']."".
$_POST['body2']."";
}
} else {
$out .= ''."\n";
}
$out .= '';
$out .= "";
echo $out;
?>
It always shows the same thing : "strings are not the
same !" . The character new line "\n" is not recorded when
it is coming from a hidden tag in html form.
I am using safe_mode and php 5.0.4.
Nicolas
Reproduce code:
---
';
$out .= '';
if (isset($_POST['body'])) {
$out .= $_POST['body'];
$out .= ''."\n";
} else {
$out .= ''."\n";
}
if (isset($_POST['body2']) && !empty($_POST['body2'])) {
if (strcmp($body, $body2)) {
$out .= "strings are the same !";
} else {
$out .= "strings are not the same !".
$_POST['body']."".
$_POST['body2']."";
}
} else {
$out .= ''."\n";
}
$out .= '';
$out .= "";
echo $out;
?>
Expected result:
If you enter the 2 following lines in the text area :
line1
line2
The result of the script always shows :
strings are not the same !
line1 line2
line1 line2
Out that should show this :
strings are the same !
--
Edit this bug report at http://bugs.php.net/?id=34027&edit=1
#34027 [NEW]: new line unix "\n" in hidden html are not recorded
From: test2 at nicolap dot lautre dot net
Operating system: linux
PHP version: 5.0.4
PHP Bug Type: Safe Mode/open_basedir
Bug description: new line unix "\n" in hidden html are not recorded
Description:
Hello,
run the following script and enter in the text area the
value :
line 1
line 2
';
$out .= '';
if (isset($_POST['body'])) {
$out .= $_POST['body'];
$out .= ''."\n";
} else {
$out .= ''."\n";
}
if (isset($_POST['body2']) && !empty($_POST['body2'])) {
if (strcmp($body, $body2)) {
$out .= "strings are the same !";
} else {
$out .= "strings are not the same !".
$_POST['body']."".
$_POST['body2']."";
}
} else {
$out .= ''."\n";
}
$out .= '';
$out .= "";
echo $out;
?>
It always shows the same thing : "strings are not the
same !" . The character new line "\n" is not recorded when
it is coming from a hidden tag in html form.
I am using safe_mode and php 5.0.4.
Nicolas
Reproduce code:
---
';
$out .= '';
if (isset($_POST['body'])) {
$out .= $_POST['body'];
$out .= ''."\n";
} else {
$out .= ''."\n";
}
if (isset($_POST['body2']) && !empty($_POST['body2'])) {
if (strcmp($body, $body2)) {
$out .= "strings are the same !";
} else {
$out .= "strings are not the same !".
$_POST['body']."".
$_POST['body2']."";
}
} else {
$out .= ''."\n";
}
$out .= '';
$out .= "";
echo $out;
?>
Expected result:
If you enter the 2 following lines in the text area :
line1
line2
The result of the script always shows :
strings are not the same !
line1 line2
line1 line2
Out that should show this :
strings are the same !
--
Edit bug report at http://bugs.php.net/?id=34027&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34027&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34027&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34027&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34027&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34027&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34027&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34027&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34027&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34027&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34027&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34027&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34027&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34027&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34027&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34027&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34027&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34027&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34027&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34027&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34027&r=mysqlcfg
#34024 [Opn->Fbk]: PHP has encountered an Access Violation at 019382DF (ISAPI)
ID: 34024 Updated by: [EMAIL PROTECTED] Reported By: andrey at cherezov dot koenig dot su -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: Just install them? Try google for the how-to, I don't know.. Previous Comments: [2005-08-07 15:15:10] andrey at cherezov dot koenig dot su How to run PHP with these pdb files? (non interactive, to write logs...) [2005-08-07 13:08:17] [EMAIL PROTECTED] Grab the debug pack: http://snaps.php.net/win32/php5-dbgpack-win32-latest.zip Install it and try see if you get more meaningful traces. [2005-08-07 11:47:50] [EMAIL PROTECTED] Actually, if you insist on using PHP with IIS, I suggest to use the FastCGI modules instead. Much more stable (no threading required, can never crash your full webserver) and just as fast as the ISAPI module. [2005-08-07 04:46:44] andrey at cherezov dot koenig dot su I can't use Apache2 on this site - there a lot of virtual hosts on this server depending of exact configuration, not supported by Apache at all. This address 019382DF not gives a pointer to a problem function? I can run on the my server any debug PHP version and send its trace log (or how you explore such bugs) to you, if you need. Any PHP variant, but not Apache, sorry. [2005-08-07 04:30:45] [EMAIL PROTECTED] Does this happen if you use Apache2 instead? (if you haven't tried, try it) 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/34024 -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1
#34024 [Fbk->Opn]: PHP has encountered an Access Violation at 019382DF (ISAPI)
ID: 34024 User updated by: andrey at cherezov dot koenig dot su Reported By: andrey at cherezov dot koenig dot su -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: How to run PHP with these pdb files? (non interactive, to write logs...) Previous Comments: [2005-08-07 13:08:17] [EMAIL PROTECTED] Grab the debug pack: http://snaps.php.net/win32/php5-dbgpack-win32-latest.zip Install it and try see if you get more meaningful traces. [2005-08-07 11:47:50] [EMAIL PROTECTED] Actually, if you insist on using PHP with IIS, I suggest to use the FastCGI modules instead. Much more stable (no threading required, can never crash your full webserver) and just as fast as the ISAPI module. [2005-08-07 04:46:44] andrey at cherezov dot koenig dot su I can't use Apache2 on this site - there a lot of virtual hosts on this server depending of exact configuration, not supported by Apache at all. This address 019382DF not gives a pointer to a problem function? I can run on the my server any debug PHP version and send its trace log (or how you explore such bugs) to you, if you need. Any PHP variant, but not Apache, sorry. [2005-08-07 04:30:45] [EMAIL PROTECTED] Does this happen if you use Apache2 instead? (if you haven't tried, try it) [2005-08-07 02:03:42] andrey at cherezov dot koenig dot su Description: Thank you for fixing the previous critical bug (double cookies)! Next one: The search engine (Yandex.ru) scanning our PhpBB forum. All pages processed OK, but 1-2 times per day PHP 5.1 gives error 500 and terminates all its threads, and I forced to restart the web-server. The current snap was installed morning today (because the previous one is also failing, but with other exceptions address). Here is a debug dump of failed request: ThreadId=7 /forum/viewtopic.php ::GET:: ::p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f:: ::/forum/viewtopic.php:: ::c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php:: >>SCRIPT_NAME=/forum/viewtopic.php Map logical path: [c:\web\new\mdaemon.ru\wwwroot\forum\viewtopic.php] >>HTTP_COOKIE= >>ALL_HTTP=HTTP_HOST: www.mdaemon.ru HTTP_CONNECTION: Keep-Alive HTTP_ACCEPT: text/html, application/pdf;q=0.1, application/rtf;q=0.1, text/rtf;q=0.1, application/msword;q=0.1, application/x-shockwave-flash;q=0.1, application/vnd.ms-excel;q=0.1, application/vnd.ms-powerpoint;q=0.1 HTTP_ACCEPT_LANGUAGE: ru, uk, be, en, *;q=0.01 HTTP_IF_MODIFIED_SINCE: Thu, 14 Jul 2005 19:49:31 GMT HTTP_USER_AGENT: Yandex/1.01.001 (compatible; Win16; I) HTTP_FROM: [EMAIL PROTECTED] >>HTTPS= >>SCRIPT_NAME=/forum/viewtopic.php >>AUTH_PASSWORD= >>AUTH_TYPE= >>AUTH_USER= >>CONTENT_LENGTH=0 >>CONTENT_TYPE= >>PATH_TRANSLATED=c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php >>QUERY_STRING=p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f >>REMOTE_ADDR=213.180.216.167 >>REMOTE_HOST=213.180.216.167 >>REMOTE_USER= >>REQUEST_METHOD=GET >>SERVER_NAME=www.mdaemon.ru >>SERVER_PORT=80 >>SERVER_PROTOCOL=HTTP/1.0 >>SERVER_SOFTWARE=acWEB/3.0.6678 >>APPL_MD_PATH= >>APPL_PHYSICAL_PATH= >>INSTANCE_ID= >>INSTANCE_META_PATH= >>LOGON_USER= >>REQUEST_URI=/forum/viewtopic.php?p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f >>URL= >>SCRIPT_NAME=/forum/viewtopic.php >>PATH_INFO=/forum/viewtopic.php >>PATH_TRANSLATED=c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php Map logical path:<> Map logical path: >>HTTP_AUTHORIZATION= Exactly the same as for all successfull request, but result: Sat, 06 Aug 2005 18:25:20 -0500 www.mdaemon.ru/forum/viewtopic.php HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 019382DF HttpExtensionProc() returned 1 IsapiRunExtension RETURNED (ThreadId=7) Reproduce code: --- None. Seems, this is an ISAPI or session related problem. Expected result: Page load. Actual result: -- PHP has encountered an Access Violation at 019382DF -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1
#33997 [Asn->Fbk]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Assigned +Status: Feedback Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 5CVS, 4CVS (2005-08-04) Assigned To: yohgaki New Comment: Please provide a location where we can download your failed test's .out and .exp file. Previous Comments: [2005-08-05 22:15:08] [EMAIL PROTECTED] Well, the patch is not approved/applied to CVS yet so keep this report open. We'll close this once the bug is really fixed. [2005-08-05 01:18:33] RVaughn at pheedo dot com Works perfectly! Hopefully this patch can be rolled into PHP 4.4.1? This one can be closed, that was the fix. Thanks much! Cheers! [2005-08-05 00:39:44] [EMAIL PROTECTED] This seems to fix the problem: http://www.php.net/~jani/patches/bug33997.patch I now get the correct result which I also got with the command line iconv tool. [2005-08-04 23:34:18] RVaughn at pheedo dot com Do let me know if you want me to put the output somewhere on our site where it can be downloaded, the code itself is just the PHP-provided test: bug16069.phpt. Thanks! Cheers! [2005-08-04 23:32:57] RVaughn at pheedo dot com OK, here's the diff output from the test results, please note that the output is the same until part way through, and the ultimate length is different: === /usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt === EXPECTED OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) ACTUAL OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) FAILED 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/33997 -- Edit this bug report at http://bugs.php.net/?id=33997&edit=1
#34009 [Bgs]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch Status: Bogus Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 4.4.0 New Comment: 1. Do we agree that PHP 4.4.0 should not show a notice in this case? 2. I know that it's nearly impossible to debug a problem if you can't reproduce it on your own machine. So I understand your point of view. But I see 3 different hosts, all different providers, that show the bug in PHP 4.4.0. I come to the conclusion that something must be really wrong. I hope we can get one of the providers to install the current CVS version of PHP 4.x. But maybe we can only offer you SSH access to a PHP 4.4.0 installation that shows the bug. Previous Comments: [2005-08-07 14:24:24] [EMAIL PROTECTED] Your failure to try the snapshots is not our problem. It works like it should work on all the servers I've tried it on. [2005-08-07 14:02:23] ast at gmx dot ch I've contacted one of the users which can reproduce the bug. He will ask his provider to give you an ssh account for debugging. We will update this bug tracker ASAP. [2005-08-05 20:08:32] [EMAIL PROTECTED] Please try CVS snapshot first (I've given the link to it). I have no idea how to look into something that is not reproducible, so I'd appreciate if you give some guidelines (an account on a machine would be fine). [2005-08-05 20:02:42] ast at gmx dot ch That's my point. It doesn't work on all systems. It works on two of my systems, both running PHP 4.4.0. It doesn't work on 3 other systems I have access to test the reproduce code. I've listed the PHPinfo links and some systems specs of systems that pass the test and systems that don't pass the test. All of them are running PHP 4.4.0. I'd really appreciate if you could look into the issue with your indepth knowledge of PHP. [2005-08-05 19:56:47] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Works fine here. 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/34009 -- Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34018 [Opn->Bgs]: Wrong private method virtual behaviour
ID: 34018
Updated by: [EMAIL PROTECTED]
Reported By: stochnagara at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: *
PHP Version: 5CVS-2005-08-07
New Comment:
Try turn on the E_STRICT errors and you'll see why this doesn't work..
Previous Comments:
[2005-08-06 13:58:03] stochnagara at hotmail dot com
Description:
When a private method is overriden and the visibility is increased to
public or protected, then this method loses its non-virtual behaviour
in methods of classes where the method is private.
So in the example bellow ext2::abc is called instead of base::abc and
ext::abc. Also when the function prototype is different warning appear.
Reproduce code:
---
class base {
public function test() { $this->abc(); }
public function test2() { $this->abc(); }
private function abc() { echo "base::abc"; }
}
class ext extends base {
public function test2() { $this->abc(null); }
private function abc ($param1) { echo "ext::abc"; }
}
class ext2 extends ext {
protected function abc ($param1, $param2) { echo "ext2::abc"; }
}
$base = new base();
$base->test(); $base->test2();
$ext = new ext();
$ext->test(); $ext->test2();
$ext2 = new ext2();
$ext2->test(); $ext2->test2();
Expected result:
base::abc
base::abc
base::abc
ext::abc
base::abc
ext::abc
Actual result:
--
base::abc
base::abc
base::abc
ext::abc
Warning: Missing argument 1 for ext2::abc() in c:\program files\apache
group\Apache\htdocs\php5\pproject4\test.php on line 12
Warning: Missing argument 2 for ext2::abc() in c:\program files\apache
group\Apache\htdocs\php5\pproject4\test.php on line 12
ext2::abc
Warning: Missing argument 2 for ext2::abc() in c:\program files\apache
group\Apache\htdocs\php5\pproject4\test.php on line 12
ext2::abc
--
Edit this bug report at http://bugs.php.net/?id=34018&edit=1
#32486 [Opn->Fbk]: odbc_fetch_into returns wrong data
ID: 32486
Updated by: [EMAIL PROTECTED]
Reported By: tho at e-dict dot net
-Status: Open
+Status: Feedback
Bug Type: Adabas-D related
Operating System: Linux
PHP Version: 4CVS-2005-05-17
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
And try with the new PDO ODBC driver.
Previous Comments:
[2005-06-14 14:39:51] tho at e-dict dot net
Seems like database is not causing the problem. The tcpdump looks okay.
[2005-06-08 18:01:50] tho at e-dict dot net
We're using Adabas with kernel version 12.01.26. What the script
basicly does is
$dbhandle = odbc_pconnect();
odbc_autocommit($dbhandle, 0);
odbc_rollback( $dbhandle );
$queryid = odbc_exec($dbhandle, $sql);
while (odbc_fetch_into( $queryid, $row )) {
}
odbc_commit($dbhandle);
The overflow occours once in 2-10 days with abound 50 seeks a day. And
of course the database itself could be responsible - I just started
tcpdump to see whether the db or php causes the problem.
[2005-06-08 16:05:53] nick dot telford at gmail dot com
Also, since it's ODBC, we'll need to know the database you're using and
the version. It's quite possible that the database itself is returning
invalid data and PHP isn't compensating for it.
[2005-06-08 16:03:33] nick dot telford at gmail dot com
Can you provide more information on how this is occuring? The script
that is causing it would be helpful, along with a guess at roughly how
often this problem occurs.
I have so far failed to replicate this bug on PHP4.3.11, i've written a
script to get some test data from a local ODBC db 100 times and detect
if the overflow is present. Running it now.
[2005-06-06 18:12:27] tho at e-dict dot net
still happens with php4-STABLE-200505171238
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/32486
--
Edit this bug report at http://bugs.php.net/?id=32486&edit=1
#33995 [Opn->Fbk]: wrong WARNING message
ID: 33995 Updated by: [EMAIL PROTECTED] Reported By: zxc at zmail dot ru -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Win2000 SP4 PHP Version: 4.4.0 New Comment: Can you at least tell us WHAT ftp server software is it?! Previous Comments: [2005-08-07 14:06:41] zxc at zmail dot ru Tony, it's very hard because all ftp servers are in private LAN. [2005-08-05 19:42:55] [EMAIL PROTECTED] What FTP server do you use? (software name, version etc.) Is it a public server? Can you give us it's IP/hostname? And probably we'll need an account there too, if it rejects anonymous logins. [2005-08-05 19:34:59] zxc at zmail dot ru sniper, I use 3 parameters: I have WARNING message (from "ftp_login()" function) if remote FTP server is FULL (many users etc.) But I must have boolean FALSE only from ftp_login() function in this case (without WARNING message), because I use prefix "@" before "ftp_login()". [2005-08-04 22:12:22] [EMAIL PROTECTED] You have to provide a working script. The one here can not work: ftp_login() expects 3 parameters, not 2.. (and I can't reproduce this with a proper script, even if the server shows errors) [2005-08-04 19:59:47] zxc at zmail dot ru Tony, I has tried change a FTP server to something, but I show WARNING still. 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/33995 -- Edit this bug report at http://bugs.php.net/?id=33995&edit=1
#34009 [Opn->Bgs]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009
Updated by: [EMAIL PROTECTED]
Reported By: ast at gmx dot ch
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 4.4.0
New Comment:
Your failure to try the snapshots is not our problem. It works like it
should work on all the servers I've tried it on.
Previous Comments:
[2005-08-07 14:02:23] ast at gmx dot ch
I've contacted one of the users which can reproduce the bug. He will
ask his provider to give you an ssh account for debugging.
We will update this bug tracker ASAP.
[2005-08-05 20:08:32] [EMAIL PROTECTED]
Please try CVS snapshot first (I've given the link to it).
I have no idea how to look into something that is not reproducible, so
I'd appreciate if you give some guidelines (an account on a machine
would be fine).
[2005-08-05 20:02:42] ast at gmx dot ch
That's my point. It doesn't work on all systems.
It works on two of my systems, both running PHP 4.4.0.
It doesn't work on 3 other systems I have access to test the reproduce
code.
I've listed the PHPinfo links and some systems specs of systems that
pass the test and systems that don't pass the test. All of them are
running PHP 4.4.0.
I'd really appreciate if you could look into the issue with your
indepth knowledge of PHP.
[2005-08-05 19:56:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Works fine here.
[2005-08-05 19:50:05] ast at gmx dot ch
Here's the reproduce code:
foo();
class Bug {
var $_flag;
function Bug() {
$this->_flag = 0;
}
function &foo() {
if (!$this->_flag) {
$false = false;
return $false; /* this is line 18 */
}
$false = false;
return $false;
}
}
?>
Expected result:
no NOTICEs
Actual result:
--
Notice: Only variable references should be returned by reference in
reproduce.php on line 18
I've added the two other methods in the original reproduce code just to
show that very slight modifications of the code do not give a PHP
Notice.
And please remember that I can't reproduce it on all systems.
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/34009
--
Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#33995 [Fbk->Opn]: wrong WARNING message
ID: 33995 User updated by: zxc at zmail dot ru Reported By: zxc at zmail dot ru -Status: Feedback +Status: Open Bug Type: FTP related Operating System: Win2000 SP4 PHP Version: 4.4.0 New Comment: Tony, it's very hard because all ftp servers are in private LAN. Previous Comments: [2005-08-05 19:42:55] [EMAIL PROTECTED] What FTP server do you use? (software name, version etc.) Is it a public server? Can you give us it's IP/hostname? And probably we'll need an account there too, if it rejects anonymous logins. [2005-08-05 19:34:59] zxc at zmail dot ru sniper, I use 3 parameters: I have WARNING message (from "ftp_login()" function) if remote FTP server is FULL (many users etc.) But I must have boolean FALSE only from ftp_login() function in this case (without WARNING message), because I use prefix "@" before "ftp_login()". [2005-08-04 22:12:22] [EMAIL PROTECTED] You have to provide a working script. The one here can not work: ftp_login() expects 3 parameters, not 2.. (and I can't reproduce this with a proper script, even if the server shows errors) [2005-08-04 19:59:47] zxc at zmail dot ru Tony, I has tried change a FTP server to something, but I show WARNING still. [2005-08-04 19:56:42] zxc at zmail dot ru Example of WARNING: -- Warning: ftp_login(): Too many users - please try again later. in /pub/home/hissite/ftpconnect.php on line 73 -- Why shows a WARNING message? I use a "@" prefix before "ftp_login()" function. >>> I must have boolean FALSE only, without this WARNING. 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/33995 -- Edit this bug report at http://bugs.php.net/?id=33995&edit=1
#34009 [Fbk->Opn]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009
User updated by: ast at gmx dot ch
Reported By: ast at gmx dot ch
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 4.4.0
New Comment:
I've contacted one of the users which can reproduce the bug. He will
ask his provider to give you an ssh account for debugging.
We will update this bug tracker ASAP.
Previous Comments:
[2005-08-05 20:08:32] [EMAIL PROTECTED]
Please try CVS snapshot first (I've given the link to it).
I have no idea how to look into something that is not reproducible, so
I'd appreciate if you give some guidelines (an account on a machine
would be fine).
[2005-08-05 20:02:42] ast at gmx dot ch
That's my point. It doesn't work on all systems.
It works on two of my systems, both running PHP 4.4.0.
It doesn't work on 3 other systems I have access to test the reproduce
code.
I've listed the PHPinfo links and some systems specs of systems that
pass the test and systems that don't pass the test. All of them are
running PHP 4.4.0.
I'd really appreciate if you could look into the issue with your
indepth knowledge of PHP.
[2005-08-05 19:56:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Works fine here.
[2005-08-05 19:50:05] ast at gmx dot ch
Here's the reproduce code:
foo();
class Bug {
var $_flag;
function Bug() {
$this->_flag = 0;
}
function &foo() {
if (!$this->_flag) {
$false = false;
return $false; /* this is line 18 */
}
$false = false;
return $false;
}
}
?>
Expected result:
no NOTICEs
Actual result:
--
Notice: Only variable references should be returned by reference in
reproduce.php on line 18
I've added the two other methods in the original reproduce code just to
show that very slight modifications of the code do not give a PHP
Notice.
And please remember that I can't reproduce it on all systems.
[2005-08-05 19:39:34] [EMAIL PROTECTED]
Please provide an exact reproduce code (the URL you've given contains a
lot of code snippets and I can't understand which one of them is the
reproduce case).
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/34009
--
Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#33909 [Opn->Asn]: fread of a pipe hang after opening a pipe with a < entry
ID: 33909
Updated by: [EMAIL PROTECTED]
Reported By: phil at adigital dot com dot mx
-Status: Open
+Status: Assigned
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5CVS-2005-07-29
Assigned To: wez
New Comment:
Wez, feedback given!
Previous Comments:
[2005-08-07 09:04:43] phil at adigital dot com dot mx
Reproduce code (again):
---
For linux code example :
http://www.thomassigny.org/bugpipe/linux/
For windows code example :
http://www.thomassigny.org/bugpipe/windows/
[2005-07-29 07:39:31] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-07-29 02:05:50] [EMAIL PROTECTED]
Yet another streams issue.
[2005-07-28 18:55:33] phil at adigital dot com dot mx
Description:
Opening a pipe for read , for example for a cgi (in this example) will
block on the fread AFTER a call to a call with an entry file
I got the error on Windows, Linux, from PHP 5.0.2, PHP 5.0.4, PHP5.1 on
CVS (did not try on other versions either)
For example:
Call 1: popen("/usr/bin/php5"); with SCRIPT_FILENAME=info.phpWORKS
perfectly, and is repeatible X times
Call 2: popen("/usr/bin/php5"); with SCRIPT_FILENAME=info.phphttp://www.thomassigny.org/bugpipe/linux/
For windows code example :
http://www.thomassigny.org/bugpipe/windows/
Expected result:
i expect the code does not hang...
Actual result:
--
no backtrace, the running code hang
--
Edit this bug report at http://bugs.php.net/?id=33909&edit=1
#34024 [Opn->Fbk]: PHP has encountered an Access Violation at 019382DF (ISAPI)
ID: 34024 Updated by: [EMAIL PROTECTED] Reported By: andrey at cherezov dot koenig dot su -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: Grab the debug pack: http://snaps.php.net/win32/php5-dbgpack-win32-latest.zip Install it and try see if you get more meaningful traces. Previous Comments: [2005-08-07 11:47:50] [EMAIL PROTECTED] Actually, if you insist on using PHP with IIS, I suggest to use the FastCGI modules instead. Much more stable (no threading required, can never crash your full webserver) and just as fast as the ISAPI module. [2005-08-07 04:46:44] andrey at cherezov dot koenig dot su I can't use Apache2 on this site - there a lot of virtual hosts on this server depending of exact configuration, not supported by Apache at all. This address 019382DF not gives a pointer to a problem function? I can run on the my server any debug PHP version and send its trace log (or how you explore such bugs) to you, if you need. Any PHP variant, but not Apache, sorry. [2005-08-07 04:30:45] [EMAIL PROTECTED] Does this happen if you use Apache2 instead? (if you haven't tried, try it) [2005-08-07 02:03:42] andrey at cherezov dot koenig dot su Description: Thank you for fixing the previous critical bug (double cookies)! Next one: The search engine (Yandex.ru) scanning our PhpBB forum. All pages processed OK, but 1-2 times per day PHP 5.1 gives error 500 and terminates all its threads, and I forced to restart the web-server. The current snap was installed morning today (because the previous one is also failing, but with other exceptions address). Here is a debug dump of failed request: ThreadId=7 /forum/viewtopic.php ::GET:: ::p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f:: ::/forum/viewtopic.php:: ::c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php:: >>SCRIPT_NAME=/forum/viewtopic.php Map logical path: [c:\web\new\mdaemon.ru\wwwroot\forum\viewtopic.php] >>HTTP_COOKIE= >>ALL_HTTP=HTTP_HOST: www.mdaemon.ru HTTP_CONNECTION: Keep-Alive HTTP_ACCEPT: text/html, application/pdf;q=0.1, application/rtf;q=0.1, text/rtf;q=0.1, application/msword;q=0.1, application/x-shockwave-flash;q=0.1, application/vnd.ms-excel;q=0.1, application/vnd.ms-powerpoint;q=0.1 HTTP_ACCEPT_LANGUAGE: ru, uk, be, en, *;q=0.01 HTTP_IF_MODIFIED_SINCE: Thu, 14 Jul 2005 19:49:31 GMT HTTP_USER_AGENT: Yandex/1.01.001 (compatible; Win16; I) HTTP_FROM: [EMAIL PROTECTED] >>HTTPS= >>SCRIPT_NAME=/forum/viewtopic.php >>AUTH_PASSWORD= >>AUTH_TYPE= >>AUTH_USER= >>CONTENT_LENGTH=0 >>CONTENT_TYPE= >>PATH_TRANSLATED=c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php >>QUERY_STRING=p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f >>REMOTE_ADDR=213.180.216.167 >>REMOTE_HOST=213.180.216.167 >>REMOTE_USER= >>REQUEST_METHOD=GET >>SERVER_NAME=www.mdaemon.ru >>SERVER_PORT=80 >>SERVER_PROTOCOL=HTTP/1.0 >>SERVER_SOFTWARE=acWEB/3.0.6678 >>APPL_MD_PATH= >>APPL_PHYSICAL_PATH= >>INSTANCE_ID= >>INSTANCE_META_PATH= >>LOGON_USER= >>REQUEST_URI=/forum/viewtopic.php?p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f >>URL= >>SCRIPT_NAME=/forum/viewtopic.php >>PATH_INFO=/forum/viewtopic.php >>PATH_TRANSLATED=c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php Map logical path:<> Map logical path: >>HTTP_AUTHORIZATION= Exactly the same as for all successfull request, but result: Sat, 06 Aug 2005 18:25:20 -0500 www.mdaemon.ru/forum/viewtopic.php HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 019382DF HttpExtensionProc() returned 1 IsapiRunExtension RETURNED (ThreadId=7) Reproduce code: --- None. Seems, this is an ISAPI or session related problem. Expected result: Page load. Actual result: -- PHP has encountered an Access Violation at 019382DF -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1
#34016 [Opn->Csd]: GD Library DLL is missing
ID: 34016 Updated by: [EMAIL PROTECTED] Reported By: stochnagara at hotmail dot com -Status: Open +Status: Closed Bug Type: GD related Operating System: windows xp PHP Version: 5CVS-2005-08-06 (dev) Assigned To: edink New Comment: Your PHP version mismatches the extension version or you didn't install the GD libraries (from dlls/) Previous Comments: [2005-08-07 07:05:15] stochnagara at hotmail dot com Thanks for the fix. Since I don't want to post another bug, I will mention there that now GD2 library cannot be loaded. The error message is "Unable to load dynamic library '...php_gd2.dll' - The specified procedure cannot be found. It's not my configuration fault because 5.0.4 works perfectly well with the same php.ini file and also dll location is the same. [2005-08-07 00:20:55] [EMAIL PROTECTED] Yessir! Task accomplished, sir! (Will appear in the next snap) [2005-08-06 23:59:51] [EMAIL PROTECTED] Edin, FIX! [2005-08-06 07:35:25] stochnagara at hotmail dot com Description: The binary distribution for Windows from 6.August comes without php_gd2.dll. Reproduce code: --- no Expected result: no Actual result: -- no -- Edit this bug report at http://bugs.php.net/?id=34016&edit=1
#34024 [Opn]: PHP has encountered an Access Violation at 019382DF (ISAPI)
ID: 34024 Updated by: [EMAIL PROTECTED] Reported By: andrey at cherezov dot koenig dot su Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: Actually, if you insist on using PHP with IIS, I suggest to use the FastCGI modules instead. Much more stable (no threading required, can never crash your full webserver) and just as fast as the ISAPI module. Previous Comments: [2005-08-07 11:44:09] andrey at cherezov dot koenig dot su > So it comes that you can provide some info in addition to > this address,right? :) This address is provided by php5isapi.dll. I hope _it_ can additionally provide more info - print entire exception record, memory dump, stack trace. Just like Dr.Watson on Windows does. In reply to my bugreport #33958 Sniper posted fragment of PHP trace log "[Switching to Thread 46912528940992 (LWP 2360)] 0x2aaab000aec1 in _mem_block_check (ptr=0x55b3a081, silent=0, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", ... This means, PHP able write such debug log? When exception occured, the last record in this log points to the faulting code, right? > I doubt I can use it on Linux to get a backtrace or > something useful, so please do provide more info yourself. With pleasure, but PHP should dump it first, and I will send this dump ;) What can I do more? The log of my web-server with the sequence of PHP calls to ISAPI interface I've provided in my first message. In past (bug#33958) such log definitely helped to locate problem - cookies, because the last call from PHP was for HTTP_COOKIE. But in this new bug PHP fetched all ISAPI variables from server w/o exception, so bug is somewhere in the code executing script, and the server can't give more information what happens inside php5isapi.dll code :( Only PHP can do this. [2005-08-07 11:14:17] [EMAIL PROTECTED] So it comes that you can provide some info in addition to this address, right? I doubt I can use it on Linux to get a backtrace or something useful, so please do provide more info yourself. >If you're not interested in ISAPI, just say it. Yes, we are. But in most cases users do not understand that just stating that something is wrong doesn't help. If you can provide more info about it - please do so. >I will switch back to CGI and forget about these bugs. This way you won't get a stable ISAPI module ever. [2005-08-07 10:53:25] andrey at cherezov dot koenig dot su 1. The address of exception is not meaningless. When exception happens in my own programs I can easily locate the faulting function because the exception record structure have all required pointers for it, and the call stack is also available to dump at exception moment. Learn from Microsoft ;) 2. And I offered a way to 'catch' any info related to this exception by turn on runtime tracing: I can run the debug version of php5isapi.dll, if you provide one, and I will send you its log when next exception occured. It is obviously and pretty easy to implement. If you'll continue to wave aside such 'unreproducible' issues, you'll never release the stable enough ISAPI module. If you're not interested in ISAPI, just say it. I will switch back to CGI and forget about these bugs. Thank you for help, Good luck, [2005-08-07 10:25:32] [EMAIL PROTECTED] So how do you expect us to fix an issue that is not reproducible and all you can provide about it is a meaningless memory address? [2005-08-07 10:14:13] andrey at cherezov dot koenig dot su Tony, this is a random multithreading issue, it is impossible to make 'reproduce script' for this kind of bugs. It requires reproducing the same threads and memory state. 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/34024 -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1
#34024 [Fbk->Opn]: PHP has encountered an Access Violation at 019382DF (ISAPI)
ID: 34024 User updated by: andrey at cherezov dot koenig dot su Reported By: andrey at cherezov dot koenig dot su -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: > So it comes that you can provide some info in addition to > this address,right? :) This address is provided by php5isapi.dll. I hope _it_ can additionally provide more info - print entire exception record, memory dump, stack trace. Just like Dr.Watson on Windows does. In reply to my bugreport #33958 Sniper posted fragment of PHP trace log "[Switching to Thread 46912528940992 (LWP 2360)] 0x2aaab000aec1 in _mem_block_check (ptr=0x55b3a081, silent=0, __zend_filename=0x2aaab02538a0 "/usr/src/php/php5/main/php_variables.c", ... This means, PHP able write such debug log? When exception occured, the last record in this log points to the faulting code, right? > I doubt I can use it on Linux to get a backtrace or > something useful, so please do provide more info yourself. With pleasure, but PHP should dump it first, and I will send this dump ;) What can I do more? The log of my web-server with the sequence of PHP calls to ISAPI interface I've provided in my first message. In past (bug#33958) such log definitely helped to locate problem - cookies, because the last call from PHP was for HTTP_COOKIE. But in this new bug PHP fetched all ISAPI variables from server w/o exception, so bug is somewhere in the code executing script, and the server can't give more information what happens inside php5isapi.dll code :( Only PHP can do this. Previous Comments: [2005-08-07 11:14:17] [EMAIL PROTECTED] So it comes that you can provide some info in addition to this address, right? I doubt I can use it on Linux to get a backtrace or something useful, so please do provide more info yourself. >If you're not interested in ISAPI, just say it. Yes, we are. But in most cases users do not understand that just stating that something is wrong doesn't help. If you can provide more info about it - please do so. >I will switch back to CGI and forget about these bugs. This way you won't get a stable ISAPI module ever. [2005-08-07 10:53:25] andrey at cherezov dot koenig dot su 1. The address of exception is not meaningless. When exception happens in my own programs I can easily locate the faulting function because the exception record structure have all required pointers for it, and the call stack is also available to dump at exception moment. Learn from Microsoft ;) 2. And I offered a way to 'catch' any info related to this exception by turn on runtime tracing: I can run the debug version of php5isapi.dll, if you provide one, and I will send you its log when next exception occured. It is obviously and pretty easy to implement. If you'll continue to wave aside such 'unreproducible' issues, you'll never release the stable enough ISAPI module. If you're not interested in ISAPI, just say it. I will switch back to CGI and forget about these bugs. Thank you for help, Good luck, [2005-08-07 10:25:32] [EMAIL PROTECTED] So how do you expect us to fix an issue that is not reproducible and all you can provide about it is a meaningless memory address? [2005-08-07 10:14:13] andrey at cherezov dot koenig dot su Tony, this is a random multithreading issue, it is impossible to make 'reproduce script' for this kind of bugs. It requires reproducing the same threads and memory state. [2005-08-07 09:43:51] [EMAIL PROTECTED] >This address 019382DF not gives a pointer to a problem function? It gives nothing. Please generate a backtrace and provide a short but complete reproduce script. 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/34024 -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1
#34024 [Opn->Fbk]: PHP has encountered an Access Violation at 019382DF (ISAPI)
ID: 34024 Updated by: [EMAIL PROTECTED] Reported By: andrey at cherezov dot koenig dot su -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: So it comes that you can provide some info in addition to this address, right? I doubt I can use it on Linux to get a backtrace or something useful, so please do provide more info yourself. >If you're not interested in ISAPI, just say it. Yes, we are. But in most cases users do not understand that just stating that something is wrong doesn't help. If you can provide more info about it - please do so. >I will switch back to CGI and forget about these bugs. This way you won't get a stable ISAPI module ever. Previous Comments: [2005-08-07 10:53:25] andrey at cherezov dot koenig dot su 1. The address of exception is not meaningless. When exception happens in my own programs I can easily locate the faulting function because the exception record structure have all required pointers for it, and the call stack is also available to dump at exception moment. Learn from Microsoft ;) 2. And I offered a way to 'catch' any info related to this exception by turn on runtime tracing: I can run the debug version of php5isapi.dll, if you provide one, and I will send you its log when next exception occured. It is obviously and pretty easy to implement. If you'll continue to wave aside such 'unreproducible' issues, you'll never release the stable enough ISAPI module. If you're not interested in ISAPI, just say it. I will switch back to CGI and forget about these bugs. Thank you for help, Good luck, [2005-08-07 10:25:32] [EMAIL PROTECTED] So how do you expect us to fix an issue that is not reproducible and all you can provide about it is a meaningless memory address? [2005-08-07 10:14:13] andrey at cherezov dot koenig dot su Tony, this is a random multithreading issue, it is impossible to make 'reproduce script' for this kind of bugs. It requires reproducing the same threads and memory state. [2005-08-07 09:43:51] [EMAIL PROTECTED] >This address 019382DF not gives a pointer to a problem function? It gives nothing. Please generate a backtrace and provide a short but complete reproduce script. [2005-08-07 04:46:44] andrey at cherezov dot koenig dot su I can't use Apache2 on this site - there a lot of virtual hosts on this server depending of exact configuration, not supported by Apache at all. This address 019382DF not gives a pointer to a problem function? I can run on the my server any debug PHP version and send its trace log (or how you explore such bugs) to you, if you need. Any PHP variant, but not Apache, sorry. 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/34024 -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1
#34024 [Fbk->Opn]: PHP has encountered an Access Violation at 019382DF (ISAPI)
ID: 34024 User updated by: andrey at cherezov dot koenig dot su Reported By: andrey at cherezov dot koenig dot su -Status: Feedback +Status: Open -Bug Type: Other web server +Bug Type: Scripting Engine problem Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: 1. The address of exception is not meaningless. When exception happens in my own programs I can easily locate the faulting function because the exception record structure have all required pointers for it, and the call stack is also available to dump at exception moment. Learn from Microsoft ;) 2. And I offered a way to 'catch' any info related to this exception by turn on runtime tracing: I can run the debug version of php5isapi.dll, if you provide one, and I will send you its log when next exception occured. It is obviously and pretty easy to implement. If you'll continue to wave aside such 'unreproducible' issues, you'll never release the stable enough ISAPI module. If you're not interested in ISAPI, just say it. I will switch back to CGI and forget about these bugs. Thank you for help, Good luck, Previous Comments: [2005-08-07 10:25:32] [EMAIL PROTECTED] So how do you expect us to fix an issue that is not reproducible and all you can provide about it is a meaningless memory address? [2005-08-07 10:14:13] andrey at cherezov dot koenig dot su Tony, this is a random multithreading issue, it is impossible to make 'reproduce script' for this kind of bugs. It requires reproducing the same threads and memory state. [2005-08-07 09:43:51] [EMAIL PROTECTED] >This address 019382DF not gives a pointer to a problem function? It gives nothing. Please generate a backtrace and provide a short but complete reproduce script. [2005-08-07 04:46:44] andrey at cherezov dot koenig dot su I can't use Apache2 on this site - there a lot of virtual hosts on this server depending of exact configuration, not supported by Apache at all. This address 019382DF not gives a pointer to a problem function? I can run on the my server any debug PHP version and send its trace log (or how you explore such bugs) to you, if you need. Any PHP variant, but not Apache, sorry. [2005-08-07 04:30:45] [EMAIL PROTECTED] Does this happen if you use Apache2 instead? (if you haven't tried, try it) 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/34024 -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1
#34024 [Opn->Fbk]: PHP has encountered an Access Violation at 019382DF (ISAPI)
ID: 34024 Updated by: [EMAIL PROTECTED] Reported By: andrey at cherezov dot koenig dot su -Status: Open +Status: Feedback Bug Type: Other web server Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: So how do you expect us to fix an issue that is not reproducible and all you can provide about it is a meaningless memory address? Previous Comments: [2005-08-07 10:14:13] andrey at cherezov dot koenig dot su Tony, this is a random multithreading issue, it is impossible to make 'reproduce script' for this kind of bugs. It requires reproducing the same threads and memory state. [2005-08-07 09:43:51] [EMAIL PROTECTED] >This address 019382DF not gives a pointer to a problem function? It gives nothing. Please generate a backtrace and provide a short but complete reproduce script. [2005-08-07 04:46:44] andrey at cherezov dot koenig dot su I can't use Apache2 on this site - there a lot of virtual hosts on this server depending of exact configuration, not supported by Apache at all. This address 019382DF not gives a pointer to a problem function? I can run on the my server any debug PHP version and send its trace log (or how you explore such bugs) to you, if you need. Any PHP variant, but not Apache, sorry. [2005-08-07 04:30:45] [EMAIL PROTECTED] Does this happen if you use Apache2 instead? (if you haven't tried, try it) [2005-08-07 02:03:42] andrey at cherezov dot koenig dot su Description: Thank you for fixing the previous critical bug (double cookies)! Next one: The search engine (Yandex.ru) scanning our PhpBB forum. All pages processed OK, but 1-2 times per day PHP 5.1 gives error 500 and terminates all its threads, and I forced to restart the web-server. The current snap was installed morning today (because the previous one is also failing, but with other exceptions address). Here is a debug dump of failed request: ThreadId=7 /forum/viewtopic.php ::GET:: ::p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f:: ::/forum/viewtopic.php:: ::c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php:: >>SCRIPT_NAME=/forum/viewtopic.php Map logical path: [c:\web\new\mdaemon.ru\wwwroot\forum\viewtopic.php] >>HTTP_COOKIE= >>ALL_HTTP=HTTP_HOST: www.mdaemon.ru HTTP_CONNECTION: Keep-Alive HTTP_ACCEPT: text/html, application/pdf;q=0.1, application/rtf;q=0.1, text/rtf;q=0.1, application/msword;q=0.1, application/x-shockwave-flash;q=0.1, application/vnd.ms-excel;q=0.1, application/vnd.ms-powerpoint;q=0.1 HTTP_ACCEPT_LANGUAGE: ru, uk, be, en, *;q=0.01 HTTP_IF_MODIFIED_SINCE: Thu, 14 Jul 2005 19:49:31 GMT HTTP_USER_AGENT: Yandex/1.01.001 (compatible; Win16; I) HTTP_FROM: [EMAIL PROTECTED] >>HTTPS= >>SCRIPT_NAME=/forum/viewtopic.php >>AUTH_PASSWORD= >>AUTH_TYPE= >>AUTH_USER= >>CONTENT_LENGTH=0 >>CONTENT_TYPE= >>PATH_TRANSLATED=c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php >>QUERY_STRING=p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f >>REMOTE_ADDR=213.180.216.167 >>REMOTE_HOST=213.180.216.167 >>REMOTE_USER= >>REQUEST_METHOD=GET >>SERVER_NAME=www.mdaemon.ru >>SERVER_PORT=80 >>SERVER_PROTOCOL=HTTP/1.0 >>SERVER_SOFTWARE=acWEB/3.0.6678 >>APPL_MD_PATH= >>APPL_PHYSICAL_PATH= >>INSTANCE_ID= >>INSTANCE_META_PATH= >>LOGON_USER= >>REQUEST_URI=/forum/viewtopic.php?p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f >>URL= >>SCRIPT_NAME=/forum/viewtopic.php >>PATH_INFO=/forum/viewtopic.php >>PATH_TRANSLATED=c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php Map logical path:<> Map logical path: >>HTTP_AUTHORIZATION= Exactly the same as for all successfull request, but result: Sat, 06 Aug 2005 18:25:20 -0500 www.mdaemon.ru/forum/viewtopic.php HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 019382DF HttpExtensionProc() returned 1 IsapiRunExtension RETURNED (ThreadId=7) Reproduce code: --- None. Seems, this is an ISAPI or session related problem. Expected result: Page load. Actual result: -- PHP has encountered an Access Violation at 019382DF -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1
#34024 [Fbk->Opn]: PHP has encountered an Access Violation at 019382DF (ISAPI)
ID: 34024 User updated by: andrey at cherezov dot koenig dot su Reported By: andrey at cherezov dot koenig dot su -Status: Feedback +Status: Open Bug Type: Other web server Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: Tony, this is a random multithreading issue, it is impossible to make 'reproduce script' for this kind of bugs. It requires reproducing the same threads and memory state. Previous Comments: [2005-08-07 09:43:51] [EMAIL PROTECTED] >This address 019382DF not gives a pointer to a problem function? It gives nothing. Please generate a backtrace and provide a short but complete reproduce script. [2005-08-07 04:46:44] andrey at cherezov dot koenig dot su I can't use Apache2 on this site - there a lot of virtual hosts on this server depending of exact configuration, not supported by Apache at all. This address 019382DF not gives a pointer to a problem function? I can run on the my server any debug PHP version and send its trace log (or how you explore such bugs) to you, if you need. Any PHP variant, but not Apache, sorry. [2005-08-07 04:30:45] [EMAIL PROTECTED] Does this happen if you use Apache2 instead? (if you haven't tried, try it) [2005-08-07 02:03:42] andrey at cherezov dot koenig dot su Description: Thank you for fixing the previous critical bug (double cookies)! Next one: The search engine (Yandex.ru) scanning our PhpBB forum. All pages processed OK, but 1-2 times per day PHP 5.1 gives error 500 and terminates all its threads, and I forced to restart the web-server. The current snap was installed morning today (because the previous one is also failing, but with other exceptions address). Here is a debug dump of failed request: ThreadId=7 /forum/viewtopic.php ::GET:: ::p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f:: ::/forum/viewtopic.php:: ::c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php:: >>SCRIPT_NAME=/forum/viewtopic.php Map logical path: [c:\web\new\mdaemon.ru\wwwroot\forum\viewtopic.php] >>HTTP_COOKIE= >>ALL_HTTP=HTTP_HOST: www.mdaemon.ru HTTP_CONNECTION: Keep-Alive HTTP_ACCEPT: text/html, application/pdf;q=0.1, application/rtf;q=0.1, text/rtf;q=0.1, application/msword;q=0.1, application/x-shockwave-flash;q=0.1, application/vnd.ms-excel;q=0.1, application/vnd.ms-powerpoint;q=0.1 HTTP_ACCEPT_LANGUAGE: ru, uk, be, en, *;q=0.01 HTTP_IF_MODIFIED_SINCE: Thu, 14 Jul 2005 19:49:31 GMT HTTP_USER_AGENT: Yandex/1.01.001 (compatible; Win16; I) HTTP_FROM: [EMAIL PROTECTED] >>HTTPS= >>SCRIPT_NAME=/forum/viewtopic.php >>AUTH_PASSWORD= >>AUTH_TYPE= >>AUTH_USER= >>CONTENT_LENGTH=0 >>CONTENT_TYPE= >>PATH_TRANSLATED=c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php >>QUERY_STRING=p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f >>REMOTE_ADDR=213.180.216.167 >>REMOTE_HOST=213.180.216.167 >>REMOTE_USER= >>REQUEST_METHOD=GET >>SERVER_NAME=www.mdaemon.ru >>SERVER_PORT=80 >>SERVER_PROTOCOL=HTTP/1.0 >>SERVER_SOFTWARE=acWEB/3.0.6678 >>APPL_MD_PATH= >>APPL_PHYSICAL_PATH= >>INSTANCE_ID= >>INSTANCE_META_PATH= >>LOGON_USER= >>REQUEST_URI=/forum/viewtopic.php?p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f >>URL= >>SCRIPT_NAME=/forum/viewtopic.php >>PATH_INFO=/forum/viewtopic.php >>PATH_TRANSLATED=c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php Map logical path:<> Map logical path: >>HTTP_AUTHORIZATION= Exactly the same as for all successfull request, but result: Sat, 06 Aug 2005 18:25:20 -0500 www.mdaemon.ru/forum/viewtopic.php HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 019382DF HttpExtensionProc() returned 1 IsapiRunExtension RETURNED (ThreadId=7) Reproduce code: --- None. Seems, this is an ISAPI or session related problem. Expected result: Page load. Actual result: -- PHP has encountered an Access Violation at 019382DF -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1
#34024 [Opn->Fbk]: PHP has encountered an Access Violation at 019382DF (ISAPI)
ID: 34024 Updated by: [EMAIL PROTECTED] Reported By: andrey at cherezov dot koenig dot su -Status: Open +Status: Feedback Bug Type: Other web server Operating System: Windows 2003 PHP Version: 5CVS-2005-08-07 (dev) New Comment: >This address 019382DF not gives a pointer to a problem function? It gives nothing. Please generate a backtrace and provide a short but complete reproduce script. Previous Comments: [2005-08-07 04:46:44] andrey at cherezov dot koenig dot su I can't use Apache2 on this site - there a lot of virtual hosts on this server depending of exact configuration, not supported by Apache at all. This address 019382DF not gives a pointer to a problem function? I can run on the my server any debug PHP version and send its trace log (or how you explore such bugs) to you, if you need. Any PHP variant, but not Apache, sorry. [2005-08-07 04:30:45] [EMAIL PROTECTED] Does this happen if you use Apache2 instead? (if you haven't tried, try it) [2005-08-07 02:03:42] andrey at cherezov dot koenig dot su Description: Thank you for fixing the previous critical bug (double cookies)! Next one: The search engine (Yandex.ru) scanning our PhpBB forum. All pages processed OK, but 1-2 times per day PHP 5.1 gives error 500 and terminates all its threads, and I forced to restart the web-server. The current snap was installed morning today (because the previous one is also failing, but with other exceptions address). Here is a debug dump of failed request: ThreadId=7 /forum/viewtopic.php ::GET:: ::p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f:: ::/forum/viewtopic.php:: ::c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php:: >>SCRIPT_NAME=/forum/viewtopic.php Map logical path: [c:\web\new\mdaemon.ru\wwwroot\forum\viewtopic.php] >>HTTP_COOKIE= >>ALL_HTTP=HTTP_HOST: www.mdaemon.ru HTTP_CONNECTION: Keep-Alive HTTP_ACCEPT: text/html, application/pdf;q=0.1, application/rtf;q=0.1, text/rtf;q=0.1, application/msword;q=0.1, application/x-shockwave-flash;q=0.1, application/vnd.ms-excel;q=0.1, application/vnd.ms-powerpoint;q=0.1 HTTP_ACCEPT_LANGUAGE: ru, uk, be, en, *;q=0.01 HTTP_IF_MODIFIED_SINCE: Thu, 14 Jul 2005 19:49:31 GMT HTTP_USER_AGENT: Yandex/1.01.001 (compatible; Win16; I) HTTP_FROM: [EMAIL PROTECTED] >>HTTPS= >>SCRIPT_NAME=/forum/viewtopic.php >>AUTH_PASSWORD= >>AUTH_TYPE= >>AUTH_USER= >>CONTENT_LENGTH=0 >>CONTENT_TYPE= >>PATH_TRANSLATED=c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php >>QUERY_STRING=p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f >>REMOTE_ADDR=213.180.216.167 >>REMOTE_HOST=213.180.216.167 >>REMOTE_USER= >>REQUEST_METHOD=GET >>SERVER_NAME=www.mdaemon.ru >>SERVER_PORT=80 >>SERVER_PROTOCOL=HTTP/1.0 >>SERVER_SOFTWARE=acWEB/3.0.6678 >>APPL_MD_PATH= >>APPL_PHYSICAL_PATH= >>INSTANCE_ID= >>INSTANCE_META_PATH= >>LOGON_USER= >>REQUEST_URI=/forum/viewtopic.php?p=9851&sid=47a888dbfb6bd5c2d8159ac179514a5f >>URL= >>SCRIPT_NAME=/forum/viewtopic.php >>PATH_INFO=/forum/viewtopic.php >>PATH_TRANSLATED=c:/web/new/mdaemon.ru/wwwroot/forum/viewtopic.php Map logical path:<> Map logical path: >>HTTP_AUTHORIZATION= Exactly the same as for all successfull request, but result: Sat, 06 Aug 2005 18:25:20 -0500 www.mdaemon.ru/forum/viewtopic.php HTTP/1.0 500 Internal Server Error Content-Type: text/html PHP has encountered an Access Violation at 019382DF HttpExtensionProc() returned 1 IsapiRunExtension RETURNED (ThreadId=7) Reproduce code: --- None. Seems, this is an ISAPI or session related problem. Expected result: Page load. Actual result: -- PHP has encountered an Access Violation at 019382DF -- Edit this bug report at http://bugs.php.net/?id=34024&edit=1
#33909 [NoF->Opn]: fread of a pipe hang after opening a pipe with a < entry
ID: 33909 User updated by: phil at adigital dot com dot mx Reported By: phil at adigital dot com dot mx -Status: No Feedback +Status: Open Bug Type: Filesystem function related Operating System: * PHP Version: 5CVS-2005-07-29 Assigned To: wez New Comment: Reproduce code (again): --- For linux code example : http://www.thomassigny.org/bugpipe/linux/ For windows code example : http://www.thomassigny.org/bugpipe/windows/ Previous Comments: [2005-08-06 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-07-29 07:39:31] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-07-29 02:05:50] [EMAIL PROTECTED] Yet another streams issue. [2005-07-28 19:25:14] phil at adigital dot com dot mx I just tried both snapshots on windows and linux, same problem happens - Phil [2005-07-28 19:03:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip 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/33909 -- Edit this bug report at http://bugs.php.net/?id=33909&edit=1
