Bug #53333 [Fbk->NoF]: Random crash

Edit report at https://bugs.php.net/bug.php?id=53333&edit=1 ID: 53333 Updated by: php-bugs@lists.php.net Reported by: pajoye@php.net Summary: Random crash -Status: Feedback +Status: No Feedback Type: Bug Package: MySQLi related Operating System: Windows PHP Version: 5.3.5 Assigned To: mysql New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: ------------------------------------------------------------------------ [2011-01-28 14:55:13] pajoye@php.net ok, can you please at least say if there is someone in your team able to deal with a dump? We can try to work together to solve it. This bug is preventing us to run daily automated QA tests. It is a stopping and is also filling our bugs databases from many users. ------------------------------------------------------------------------ [2011-01-26 12:41:16] pajoye@php.net On a shorter note, do you really have nobody able to deal with a dump? That's really the way to go with such bug and we spent already a fair amount of time to get all the possible details. The next step should really be a mysql developer sitting down and analyze the dump to see the condition where it happens. Please note that this bug is not really random as it happens on a regular basis, I got a couple of users reporting it as well. Is there anything else that you need to begin to work on it? Except a small reproduce script, can't produce one at this stage. ------------------------------------------------------------------------ [2011-01-22 04:31:35] kriscraig@php.net I believe it would also be helpful to allow the mysqlnd debug setting to be used on a non-debug PHP build as well. ------------------------------------------------------------------------ [2011-01-22 04:28:47] kriscraig@php.net Sorry for not keeping these comments up-to-date. I've had my head buried triaging this for the last two months now. Anyway, there's a few things to cover. First, I was able to get your mysqlnd debug to work. However, because you have it outputting the debug to a file on each and every PHP run, this filesystem stress is creating a major bottleneck, bringing PHP's perf understress down from around 50 tps (transactions per second) to about 1 or 2 tps. As a result, I am unable to repro this crash with this enabled as you specified in your comment. I would recommend that you perhaps find a way to store this data as an object or whatever and only output to a file in the event of a crash or other error. In any case, I spent some time backtracing this and I believe what we're dealing with is a classic double-free and/or corruption. I have no explanation as to what's causing the corruption to begin with though. I also investigated whether or not this is a threading issue. Contrary to what common sense would suggest, this does not appear to be the case, either. I ran the stress test again on Apache with the -X option (Debug mode), which forces httpd.exe to run as a single process. The crash still occured. No relevant change in the repro. I have also confirmed that this bug is still present in the latest release of 5.3.5. Finally, given the difficulty in reproducing this bug, not to mention the general difficulty in tracking down memory corruption issues in ANSI C in general, I'm now trying a bandaid approach. I added an ifcheck to _zend_mm_free_int in zend_alloc.c at the spot of the top of the crash stack, forcing it to skip the free attempt if the variable in question (next_block) is NULL. I then added some exception handling (using setjmp.h) code to mysqli_result_free_storage in mysqli.c at a spot earlier in the stack, forcing it to throw a PHP warning error (which is set to output to a log file) if there's an exception. I've never tried this in ANSI C before but I think I've got it right. The test is running now and may take awhile to yield a result. I will post a patch early next week. If successful, this won't fix whatever the underlying cause of the corruption is, but it will at least throw an error and spare us a crash, which will allow me to start generating PHP perf results under stress conditions along with the standard perf data. I'll post again when I have the results of this latest test run. ------------------------------------------------------------------------ [2010-12-02 11:26:33] pajoye@php.net You need a debug build to get it working. ------------------------------------------------------------------------ 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=53333 -- Edit this bug report at https://bugs.php.net/bug.php?id=53333&edit=1