Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at https://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: m at rtin dot so Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: Sorry the use () isn't relevant, I forgot to remove it when simplifying my test case Previous Comments: [2013-08-19 18:23:17] m at rtin dot so I ran into a similar issue, i'm sure it'll require the same patch as it's the backtrace causing the problem but worth noting it doesn't require an exception to trigger this, just a backtrace. $ cat usort.php $b; }); $ php usort.php string(4) "test" string(59) "usort(): Array was modified by the user comparison function" [2013-07-09 07:21:19] jakub dot lopuszanski at nasza-klasa dot pl I'd like to add, that you do not have to throw an exception to get this warning. Mere creating it, also triggers the warning, as in: PHP Warning: usort(): Array was modified by the user comparison function in /home/jlopuszanski/test.php on line 6 [2013-06-17 11:11:07] andrejs dot verza at gmail dot com Php 5.4.16 also fails with this. Still the same status for 3 and a half years old bug?! [2012-08-08 17:53:58] mbrowne83 at gmail dot com This will probably be obvious to most, but I just wanted to mention that you can always prefix the usort function with the @ symbol to prevent the warning...of course that would also suppress any other types of notices or warnings that might occcur anywhere within the sorting function... [2012-02-24 18:04:02] keith at breadvault dot com This same problem arises when using Mockery to mock the object whose method is being used by usort(), even though the method itself neither is mocked nor handles any exceptions. The proxy generated by Mockery must wrap the target class's methods with some exception-handling code. Unfortunately this forced me to code a workaround that would not use usort. My hack extracts from the objects in the array the values being sorted on, sorts that array of values using asort() (to preserve the keys), and finally rebuilds the list of objects using the keys in the order that they appear in the asorted list of values. Yuck. 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 https://bugs.php.net/bug.php?id=50688 -- Edit this bug report at https://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at https://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: m at rtin dot so Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: I ran into a similar issue, i'm sure it'll require the same patch as it's the backtrace causing the problem but worth noting it doesn't require an exception to trigger this, just a backtrace. $ cat usort.php $b; }); $ php usort.php string(4) "test" string(59) "usort(): Array was modified by the user comparison function" Previous Comments: [2013-07-09 07:21:19] jakub dot lopuszanski at nasza-klasa dot pl I'd like to add, that you do not have to throw an exception to get this warning. Mere creating it, also triggers the warning, as in: PHP Warning: usort(): Array was modified by the user comparison function in /home/jlopuszanski/test.php on line 6 [2013-06-17 11:11:07] andrejs dot verza at gmail dot com Php 5.4.16 also fails with this. Still the same status for 3 and a half years old bug?! [2012-08-08 17:53:58] mbrowne83 at gmail dot com This will probably be obvious to most, but I just wanted to mention that you can always prefix the usort function with the @ symbol to prevent the warning...of course that would also suppress any other types of notices or warnings that might occcur anywhere within the sorting function... [2012-02-24 18:04:02] keith at breadvault dot com This same problem arises when using Mockery to mock the object whose method is being used by usort(), even though the method itself neither is mocked nor handles any exceptions. The proxy generated by Mockery must wrap the target class's methods with some exception-handling code. Unfortunately this forced me to code a workaround that would not use usort. My hack extracts from the objects in the array the values being sorted on, sorts that array of values using asort() (to preserve the keys), and finally rebuilds the list of objects using the keys in the order that they appear in the asorted list of values. Yuck. [2012-02-21 22:56:31] eric_haney at yahoo dot com It took me a while to figure out that some code called from usort was throwing, catching, and (gracefully) handling an Exception. Then I found this post. Quite frustrating. I turned off warnings with ini_set before calling usort, then turned them on again after. This is an effective workaround for now, but I'd love to clean that nastiness out of my code. It is also my opinion that usort should be allowed to change the elements in the array. EG: an instance variable of an object may be lazy-loaded as a result of a method call from within a usort callback. Should a warning really be issued in that 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 https://bugs.php.net/bug.php?id=50688 -- Edit this bug report at https://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at https://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: jakub dot lopuszanski at nasza-klasa dot pl Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: I'd like to add, that you do not have to throw an exception to get this warning. Mere creating it, also triggers the warning, as in: PHP Warning: usort(): Array was modified by the user comparison function in /home/jlopuszanski/test.php on line 6 Previous Comments: [2013-06-17 11:11:07] andrejs dot verza at gmail dot com Php 5.4.16 also fails with this. Still the same status for 3 and a half years old bug?! [2012-08-08 17:53:58] mbrowne83 at gmail dot com This will probably be obvious to most, but I just wanted to mention that you can always prefix the usort function with the @ symbol to prevent the warning...of course that would also suppress any other types of notices or warnings that might occcur anywhere within the sorting function... [2012-02-24 18:04:02] keith at breadvault dot com This same problem arises when using Mockery to mock the object whose method is being used by usort(), even though the method itself neither is mocked nor handles any exceptions. The proxy generated by Mockery must wrap the target class's methods with some exception-handling code. Unfortunately this forced me to code a workaround that would not use usort. My hack extracts from the objects in the array the values being sorted on, sorts that array of values using asort() (to preserve the keys), and finally rebuilds the list of objects using the keys in the order that they appear in the asorted list of values. Yuck. [2012-02-21 22:56:31] eric_haney at yahoo dot com It took me a while to figure out that some code called from usort was throwing, catching, and (gracefully) handling an Exception. Then I found this post. Quite frustrating. I turned off warnings with ini_set before calling usort, then turned them on again after. This is an effective workaround for now, but I'd love to clean that nastiness out of my code. It is also my opinion that usort should be allowed to change the elements in the array. EG: an instance variable of an object may be lazy-loaded as a result of a method call from within a usort callback. Should a warning really be issued in that case? [2011-10-10 21:44:56] poehler at interworx dot com This bug is still present as of PHP 5.3.8, we ran into it today and spent most of a day trying to figure out what was causing the error message "Array was modified by the user comparison function", when CLEARLY, NOTHING was changing the array at all! The exception was not thrown/caught directly in the usort function but rather in a constructor of a class that was called about 3 or 4 functions deep from the usort, making it very difficult to track down. After finally figuring out the exception was somehow related, we searched google and found this bug report. I'm sure we can agree that the minor act of catching an exception should not result in usort throwing a warning message. This bug is a huge timewaster :( 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 https://bugs.php.net/bug.php?id=50688 -- Edit this bug report at https://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at https://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: andrejs dot verza at gmail dot com Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: Php 5.4.16 also fails with this. Still the same status for 3 and a half years old bug?! Previous Comments: [2012-08-08 17:53:58] mbrowne83 at gmail dot com This will probably be obvious to most, but I just wanted to mention that you can always prefix the usort function with the @ symbol to prevent the warning...of course that would also suppress any other types of notices or warnings that might occcur anywhere within the sorting function... [2012-02-24 18:04:02] keith at breadvault dot com This same problem arises when using Mockery to mock the object whose method is being used by usort(), even though the method itself neither is mocked nor handles any exceptions. The proxy generated by Mockery must wrap the target class's methods with some exception-handling code. Unfortunately this forced me to code a workaround that would not use usort. My hack extracts from the objects in the array the values being sorted on, sorts that array of values using asort() (to preserve the keys), and finally rebuilds the list of objects using the keys in the order that they appear in the asorted list of values. Yuck. [2012-02-21 22:56:31] eric_haney at yahoo dot com It took me a while to figure out that some code called from usort was throwing, catching, and (gracefully) handling an Exception. Then I found this post. Quite frustrating. I turned off warnings with ini_set before calling usort, then turned them on again after. This is an effective workaround for now, but I'd love to clean that nastiness out of my code. It is also my opinion that usort should be allowed to change the elements in the array. EG: an instance variable of an object may be lazy-loaded as a result of a method call from within a usort callback. Should a warning really be issued in that case? [2011-10-10 21:44:56] poehler at interworx dot com This bug is still present as of PHP 5.3.8, we ran into it today and spent most of a day trying to figure out what was causing the error message "Array was modified by the user comparison function", when CLEARLY, NOTHING was changing the array at all! The exception was not thrown/caught directly in the usort function but rather in a constructor of a class that was called about 3 or 4 functions deep from the usort, making it very difficult to track down. After finally figuring out the exception was somehow related, we searched google and found this bug report. I'm sure we can agree that the minor act of catching an exception should not result in usort throwing a warning message. This bug is a huge timewaster :( [2010-10-07 23:34:54] philipwhiuk at hotmail dot com I notice this is still affecting PHP 5.3.3 (Windows/Apache install). Is this likely to be fixed soon - is it a question of developer time and priority or is it too difficult to fix? It's quite irritating - I realise that the obvious solution is to avoid throwing the exception (ha-ha) but it's a useful function and exceptions are... inevitable. 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 https://bugs.php.net/bug.php?id=50688 -- Edit this bug report at https://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at https://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: mbrowne83 at gmail dot com Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: This will probably be obvious to most, but I just wanted to mention that you can always prefix the usort function with the @ symbol to prevent the warning...of course that would also suppress any other types of notices or warnings that might occcur anywhere within the sorting function... Previous Comments: [2012-02-24 18:04:02] keith at breadvault dot com This same problem arises when using Mockery to mock the object whose method is being used by usort(), even though the method itself neither is mocked nor handles any exceptions. The proxy generated by Mockery must wrap the target class's methods with some exception-handling code. Unfortunately this forced me to code a workaround that would not use usort. My hack extracts from the objects in the array the values being sorted on, sorts that array of values using asort() (to preserve the keys), and finally rebuilds the list of objects using the keys in the order that they appear in the asorted list of values. Yuck. [2012-02-21 22:56:31] eric_haney at yahoo dot com It took me a while to figure out that some code called from usort was throwing, catching, and (gracefully) handling an Exception. Then I found this post. Quite frustrating. I turned off warnings with ini_set before calling usort, then turned them on again after. This is an effective workaround for now, but I'd love to clean that nastiness out of my code. It is also my opinion that usort should be allowed to change the elements in the array. EG: an instance variable of an object may be lazy-loaded as a result of a method call from within a usort callback. Should a warning really be issued in that case? [2011-10-10 21:44:56] poehler at interworx dot com This bug is still present as of PHP 5.3.8, we ran into it today and spent most of a day trying to figure out what was causing the error message "Array was modified by the user comparison function", when CLEARLY, NOTHING was changing the array at all! The exception was not thrown/caught directly in the usort function but rather in a constructor of a class that was called about 3 or 4 functions deep from the usort, making it very difficult to track down. After finally figuring out the exception was somehow related, we searched google and found this bug report. I'm sure we can agree that the minor act of catching an exception should not result in usort throwing a warning message. This bug is a huge timewaster :( [2010-10-07 23:34:54] philipwhiuk at hotmail dot com I notice this is still affecting PHP 5.3.3 (Windows/Apache install). Is this likely to be fixed soon - is it a question of developer time and priority or is it too difficult to fix? It's quite irritating - I realise that the obvious solution is to avoid throwing the exception (ha-ha) but it's a useful function and exceptions are... inevitable. [2010-05-31 17:24:05] ajrattink at correct dot net I printed a debug line from my usort callback. It called debug_backtrace() to print the line and sourcefile in the debuglog. And therefor triggered the error. Even more, it did not sort. Maybe the phpmanual should state that usort() callbacks are not allowed to write loglines. I also think that usort() callbacks that DO change the array are perfectly legal, as long as they don't change the sort. Maybe your sorter code needs stackoverflow protection or whatever, but calling certain code 'invalid', because it causes your code to SEGV is a stupid way to solve a bug. 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 https://bugs.php.net/bug.php?id=50688 -- Edit this bug report at https://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at https://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: keith at breadvault dot com Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: This same problem arises when using Mockery to mock the object whose method is being used by usort(), even though the method itself neither is mocked nor handles any exceptions. The proxy generated by Mockery must wrap the target class's methods with some exception-handling code. Unfortunately this forced me to code a workaround that would not use usort. My hack extracts from the objects in the array the values being sorted on, sorts that array of values using asort() (to preserve the keys), and finally rebuilds the list of objects using the keys in the order that they appear in the asorted list of values. Yuck. Previous Comments: [2012-02-21 22:56:31] eric_haney at yahoo dot com It took me a while to figure out that some code called from usort was throwing, catching, and (gracefully) handling an Exception. Then I found this post. Quite frustrating. I turned off warnings with ini_set before calling usort, then turned them on again after. This is an effective workaround for now, but I'd love to clean that nastiness out of my code. It is also my opinion that usort should be allowed to change the elements in the array. EG: an instance variable of an object may be lazy-loaded as a result of a method call from within a usort callback. Should a warning really be issued in that case? [2011-10-10 21:44:56] poehler at interworx dot com This bug is still present as of PHP 5.3.8, we ran into it today and spent most of a day trying to figure out what was causing the error message "Array was modified by the user comparison function", when CLEARLY, NOTHING was changing the array at all! The exception was not thrown/caught directly in the usort function but rather in a constructor of a class that was called about 3 or 4 functions deep from the usort, making it very difficult to track down. After finally figuring out the exception was somehow related, we searched google and found this bug report. I'm sure we can agree that the minor act of catching an exception should not result in usort throwing a warning message. This bug is a huge timewaster :( [2010-10-07 23:34:54] philipwhiuk at hotmail dot com I notice this is still affecting PHP 5.3.3 (Windows/Apache install). Is this likely to be fixed soon - is it a question of developer time and priority or is it too difficult to fix? It's quite irritating - I realise that the obvious solution is to avoid throwing the exception (ha-ha) but it's a useful function and exceptions are... inevitable. [2010-05-31 17:24:05] ajrattink at correct dot net I printed a debug line from my usort callback. It called debug_backtrace() to print the line and sourcefile in the debuglog. And therefor triggered the error. Even more, it did not sort. Maybe the phpmanual should state that usort() callbacks are not allowed to write loglines. I also think that usort() callbacks that DO change the array are perfectly legal, as long as they don't change the sort. Maybe your sorter code needs stackoverflow protection or whatever, but calling certain code 'invalid', because it causes your code to SEGV is a stupid way to solve a bug. [2010-04-01 02:12:52] s...@php.net The reason seems to be that when making exception backtrace, debug_backtrace_get_args() uses SEPARATE_ZVAL_TO_MAKE_IS_REF() on arguments, which makes it look as if the argument was indeed modified (which usort is designed to protect against, since cmp callback is not supposed to modify the arguments) 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 https://bugs.php.net/bug.php?id=50688 -- Edit this bug report at https://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at https://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: eric_haney at yahoo dot com Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: It took me a while to figure out that some code called from usort was throwing, catching, and (gracefully) handling an Exception. Then I found this post. Quite frustrating. I turned off warnings with ini_set before calling usort, then turned them on again after. This is an effective workaround for now, but I'd love to clean that nastiness out of my code. It is also my opinion that usort should be allowed to change the elements in the array. EG: an instance variable of an object may be lazy-loaded as a result of a method call from within a usort callback. Should a warning really be issued in that case? Previous Comments: [2011-10-10 21:44:56] poehler at interworx dot com This bug is still present as of PHP 5.3.8, we ran into it today and spent most of a day trying to figure out what was causing the error message "Array was modified by the user comparison function", when CLEARLY, NOTHING was changing the array at all! The exception was not thrown/caught directly in the usort function but rather in a constructor of a class that was called about 3 or 4 functions deep from the usort, making it very difficult to track down. After finally figuring out the exception was somehow related, we searched google and found this bug report. I'm sure we can agree that the minor act of catching an exception should not result in usort throwing a warning message. This bug is a huge timewaster :( [2010-10-07 23:34:54] philipwhiuk at hotmail dot com I notice this is still affecting PHP 5.3.3 (Windows/Apache install). Is this likely to be fixed soon - is it a question of developer time and priority or is it too difficult to fix? It's quite irritating - I realise that the obvious solution is to avoid throwing the exception (ha-ha) but it's a useful function and exceptions are... inevitable. [2010-05-31 17:24:05] ajrattink at correct dot net I printed a debug line from my usort callback. It called debug_backtrace() to print the line and sourcefile in the debuglog. And therefor triggered the error. Even more, it did not sort. Maybe the phpmanual should state that usort() callbacks are not allowed to write loglines. I also think that usort() callbacks that DO change the array are perfectly legal, as long as they don't change the sort. Maybe your sorter code needs stackoverflow protection or whatever, but calling certain code 'invalid', because it causes your code to SEGV is a stupid way to solve a bug. [2010-04-01 02:12:52] s...@php.net The reason seems to be that when making exception backtrace, debug_backtrace_get_args() uses SEPARATE_ZVAL_TO_MAKE_IS_REF() on arguments, which makes it look as if the argument was indeed modified (which usort is designed to protect against, since cmp callback is not supposed to modify the arguments) [2010-03-05 17:41:30] bernie at dcbl dot ca affects gentoo builds after > 5.2.10 (5.2.11, 5.2.11-r1, and 5.2.12) 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 https://bugs.php.net/bug.php?id=50688 -- Edit this bug report at https://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at https://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: poehler at interworx dot com Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: This bug is still present as of PHP 5.3.8, we ran into it today and spent most of a day trying to figure out what was causing the error message "Array was modified by the user comparison function", when CLEARLY, NOTHING was changing the array at all! The exception was not thrown/caught directly in the usort function but rather in a constructor of a class that was called about 3 or 4 functions deep from the usort, making it very difficult to track down. After finally figuring out the exception was somehow related, we searched google and found this bug report. I'm sure we can agree that the minor act of catching an exception should not result in usort throwing a warning message. This bug is a huge timewaster :( Previous Comments: [2010-10-07 23:34:54] philipwhiuk at hotmail dot com I notice this is still affecting PHP 5.3.3 (Windows/Apache install). Is this likely to be fixed soon - is it a question of developer time and priority or is it too difficult to fix? It's quite irritating - I realise that the obvious solution is to avoid throwing the exception (ha-ha) but it's a useful function and exceptions are... inevitable. [2010-05-31 17:24:05] ajrattink at correct dot net I printed a debug line from my usort callback. It called debug_backtrace() to print the line and sourcefile in the debuglog. And therefor triggered the error. Even more, it did not sort. Maybe the phpmanual should state that usort() callbacks are not allowed to write loglines. I also think that usort() callbacks that DO change the array are perfectly legal, as long as they don't change the sort. Maybe your sorter code needs stackoverflow protection or whatever, but calling certain code 'invalid', because it causes your code to SEGV is a stupid way to solve a bug. [2010-04-01 02:12:52] s...@php.net The reason seems to be that when making exception backtrace, debug_backtrace_get_args() uses SEPARATE_ZVAL_TO_MAKE_IS_REF() on arguments, which makes it look as if the argument was indeed modified (which usort is designed to protect against, since cmp callback is not supposed to modify the arguments) [2010-03-05 17:41:30] bernie at dcbl dot ca affects gentoo builds after > 5.2.10 (5.2.11, 5.2.11-r1, and 5.2.12) [2010-01-20 10:22:01] j...@php.net This was caused by the fix for bug #50006 (there weren't such checks before :) Stas, can you check this out? Didn't expect anyone to use exceptions, did you? :D 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 https://bugs.php.net/bug.php?id=50688 -- Edit this bug report at https://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at http://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: philipwhiuk at hotmail dot com Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N New Comment: I notice this is still affecting PHP 5.3.3 (Windows/Apache install). Is this likely to be fixed soon - is it a question of developer time and priority or is it too difficult to fix? It's quite irritating - I realise that the obvious solution is to avoid throwing the exception (ha-ha) but it's a useful function and exceptions are... inevitable. Previous Comments: [2010-05-31 17:24:05] ajrattink at correct dot net I printed a debug line from my usort callback. It called debug_backtrace() to print the line and sourcefile in the debuglog. And therefor triggered the error. Even more, it did not sort. Maybe the phpmanual should state that usort() callbacks are not allowed to write loglines. I also think that usort() callbacks that DO change the array are perfectly legal, as long as they don't change the sort. Maybe your sorter code needs stackoverflow protection or whatever, but calling certain code 'invalid', because it causes your code to SEGV is a stupid way to solve a bug. [2010-04-01 02:12:52] s...@php.net The reason seems to be that when making exception backtrace, debug_backtrace_get_args() uses SEPARATE_ZVAL_TO_MAKE_IS_REF() on arguments, which makes it look as if the argument was indeed modified (which usort is designed to protect against, since cmp callback is not supposed to modify the arguments) [2010-03-05 17:41:30] bernie at dcbl dot ca affects gentoo builds after > 5.2.10 (5.2.11, 5.2.11-r1, and 5.2.12) [2010-01-20 10:22:01] j...@php.net This was caused by the fix for bug #50006 (there weren't such checks before :) Stas, can you check this out? Didn't expect anyone to use exceptions, did you? :D [2010-01-08 01:51:56] federico dot lebron at gmail dot com The problem seems to be that usort checks the amount of references before and after the function call to see if the user-provided function modified it, but inside the function call, debug_backtrace_get_args adds a reference to the passed variables to use in e.g. debug_backtrace's "arg" element. 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/bug.php?id=50688 -- Edit this bug report at http://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at http://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: ajrattink at correct dot net Reported by: jcampbell at remindermedia dot com Summary: Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package: Arrays related Operating System: Fedora Core 12 PHP Version: 5.*, 6 Assigned To: stas New Comment: I printed a debug line from my usort callback. It called debug_backtrace() to print the line and sourcefile in the debuglog. And therefor triggered the error. Even more, it did not sort. Maybe the phpmanual should state that usort() callbacks are not allowed to write loglines. I also think that usort() callbacks that DO change the array are perfectly legal, as long as they don't change the sort. Maybe your sorter code needs stackoverflow protection or whatever, but calling certain code 'invalid', because it causes your code to SEGV is a stupid way to solve a bug. Previous Comments: [2010-04-01 02:12:52] s...@php.net The reason seems to be that when making exception backtrace, debug_backtrace_get_args() uses SEPARATE_ZVAL_TO_MAKE_IS_REF() on arguments, which makes it look as if the argument was indeed modified (which usort is designed to protect against, since cmp callback is not supposed to modify the arguments) [2010-03-05 17:41:30] bernie at dcbl dot ca affects gentoo builds after > 5.2.10 (5.2.11, 5.2.11-r1, and 5.2.12) [2010-01-20 10:22:01] j...@php.net This was caused by the fix for bug #50006 (there weren't such checks before :) Stas, can you check this out? Didn't expect anyone to use exceptions, did you? :D [2010-01-08 01:51:56] federico dot lebron at gmail dot com The problem seems to be that usort checks the amount of references before and after the function call to see if the user-provided function modified it, but inside the function call, debug_backtrace_get_args adds a reference to the passed variables to use in e.g. debug_backtrace's "arg" element. [2010-01-07 19:42:30] jcampbell at remindermedia dot com Description: If the callback function used by usort handles an exception using a try/catch block, a warning is generated. The correct sorting is still done. This happens even when the exception & handling doesn't involve the variables. The example below is the usort example from the manual with only the try/catch block added. Reproducible in PHP 5.2.11 but not 5.2.9 Reproduce code: --- http://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at http://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: s...@php.net Reported by: jcampbell at remindermedia dot com Summary: Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package: Arrays related Operating System: Fedora Core 12 PHP Version: 5.*, 6 Assigned To: stas New Comment: The reason seems to be that when making exception backtrace, debug_backtrace_get_args() uses SEPARATE_ZVAL_TO_MAKE_IS_REF() on arguments, which makes it look as if the argument was indeed modified (which usort is designed to protect against, since cmp callback is not supposed to modify the arguments) Previous Comments: [2010-03-05 17:41:30] bernie at dcbl dot ca affects gentoo builds after > 5.2.10 (5.2.11, 5.2.11-r1, and 5.2.12) [2010-01-20 10:22:01] j...@php.net This was caused by the fix for bug #50006 (there weren't such checks before :) Stas, can you check this out? Didn't expect anyone to use exceptions, did you? :D [2010-01-08 01:51:56] federico dot lebron at gmail dot com The problem seems to be that usort checks the amount of references before and after the function call to see if the user-provided function modified it, but inside the function call, debug_backtrace_get_args adds a reference to the passed variables to use in e.g. debug_backtrace's "arg" element. [2010-01-07 19:42:30] jcampbell at remindermedia dot com Description: If the callback function used by usort handles an exception using a try/catch block, a warning is generated. The correct sorting is still done. This happens even when the exception & handling doesn't involve the variables. The example below is the usort example from the manual with only the try/catch block added. Reproducible in PHP 5.2.11 but not 5.2.9 Reproduce code: --- http://bugs.php.net/bug.php?id=50688&edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at http://bugs.php.net/bug.php?id=50688&edit=1 ID: 50688 Comment by: Reported by: jcampbell at remindermedia dot com Summary: Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package: Arrays related Operating System: Fedora Core 12 PHP Version: 5.*, 6 Assigned To: stas New Comment: affects gentoo builds after > 5.2.10 (5.2.11, 5.2.11-r1, and 5.2.12) Previous Comments: [2010-01-20 10:22:01] j...@php.net This was caused by the fix for bug #50006 (there weren't such checks before :) Stas, can you check this out? Didn't expect anyone to use exceptions, did you? :D [2010-01-08 01:51:56] federico dot lebron at gmail dot com The problem seems to be that usort checks the amount of references before and after the function call to see if the user-provided function modified it, but inside the function call, debug_backtrace_get_args adds a reference to the passed variables to use in e.g. debug_backtrace's "arg" element. [2010-01-07 19:42:30] jcampbell at remindermedia dot com Description: If the callback function used by usort handles an exception using a try/catch block, a warning is generated. The correct sorting is still done. This happens even when the exception & handling doesn't involve the variables. The example below is the usort example from the manual with only the try/catch block added. Reproducible in PHP 5.2.11 but not 5.2.9 Reproduce code: --- http://bugs.php.net/bug.php?id=50688&edit=1
