Man I'm glad you figured that out because even with the test case I can't figure out what's going on :)
On Fri, Aug 14, 2015 at 12:15 PM, Xinchen Hui <larue...@php.net> wrote: > Hey: > > > On Thu, Aug 13, 2015 at 8:36 PM, James Gilliland <neclim...@gmail.com> > wrote: > > So I've been trying for a couple days to narrow down this bug: > > https://bugs.php.net/bug.php?id=70242 > > > > I can consistently recreate it with a complex test, but I have thus far > not > > been able to find a pattern that helps me narrow down to a test script. I > > thought maybe I could reach out and see if I could get some help > > understanding what is happening in php and see if that has any clues. > > > > > > Seemingly important facts I've found digging through in gdb. > > 1) The connection related pointers on the stmt are already freed when the > > fault happens. It looks like the statement is being freed after the > > connection and the if (S->H->server) { surrounding the failing code is > not > > sufficient to catch this > > 2) The trace has a spl_iterator in it so it seems like that is holding on > > to the stmt pointer. There is a IteratorIterator used on a PDO stmt in > the > > code. But also in a lot of other non-triggering seemingly identical code > > and I haven't been able to get this to work. > > 3) The code in shutdown_executor that is triggering this is the 6th block > > of cleanups which seems to support 1). It is the block without any > > documentation which is sort of my luck in this. > > > > I'm guessing there is some way I need to trick a object to hold onto a > > reference through the other cleanups or something or trigger some sort of > > reference counter quirk but I just can't find it. Any help is > appreciated. > > thanks for the ssh access , I finally get the reason of this bug.. > > I get a simple reproduce script and quick fix. all listed in > https://bugs.php.net/bug.php?id=70272&thanks=1 > > @dmitry: do you see a better solution ? > > thanks > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ >
