Urgh, OK. Thanks, applied.
On Mon, Jul 8, 2013 at 4:55 PM, Ashesh Vashi <[email protected]>wrote: > On Mon, Jul 8, 2013 at 7:00 PM, Dave Page <[email protected]> wrote: > >> Hi >> >> >> On Fri, Jul 5, 2013 at 8:14 AM, Ashesh Vashi < >> [email protected]> wrote: >> >>> Hi Dave, >>> >>> During testing of the debugger, our (EnterpriseDB's) QA found an issue. >>> Please found the scenario: >>> >>> 1. Start a global (in-context) debugging session on a function (by >>> clicking on Debugging -> Set breakpoint) >>> 2. And, then start the direct debugging session on the same function (by >>> clicking on Debugging -> Debug) >>> >>> As the global debugging session is already waiting for this function, >>> the debugging will start in that environment. >>> Now - if we try to close the direct debugging session, pgAdmin will >>> throw an error saying pldbg_abort_target() does not exist. >>> >>> Because - the direct debugging session has not yet started, we do not >>> have the session-id in that environment. >>> Hence, we need to inform only the execution connection to get >>> terminated, and that resolved the issue. >>> >>> But - other problem came up, when we once again close the direct >>> debugging session. As we're already in the closing operation, >>> it once again try to close the execution connection, which is not write >>> and this time the pgAdmin became unresponsive. >>> >>> In order to resolve this problem, we need to introduce the flag to let >>> know the debugger frame that we're already in process of stopping >>> the session. >>> >>> Please find the patch, which will resolve this issue. >>> >> >> This has a really weird effect: >> > That's true and one of the reason earlier version debugger was crashing, > while debugging a function, on which a global break point has already been > setup. > As the direct session expects to raise the notice to handle the session, > but it never happened. > > This is a behaviour (or, bug) found during the debugger redesigning of the > debugger plugin, but as it had been there from long time, I had to design > the new debugger to handle this case too. > But - I missed few points, which I resolved in this patch. > >> >> - Set a global break point on a function. >> >> - Start to direct-debug the same function. >> >> - Enter the function parameters and start debugging. >> >> - The execution is captured by the global session. >> >> - Run the function to completion >> >> - The result is displayed in the direct session. >> > Because the function execution has started from the direct debugging > session. > >> >> > >> The attached screenshot shows what I mean (I hope). >> > I know.. :).. It's a bug in plugin, even we fix in plugin. This behaviour > is going to be there in older version of plugin. > Hence, we should check-in this patch in pgAdmin III debugger. > > In order to resolve this bug, we may also need to make changes in the > server (backend). Though - I am not completely sure. > Need to investigate more and I am short of time as usual. > >> >> Please also find an updated patch attached, that fixes spelling and >> language issues. >> > Looks good to me. > >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > > > > -- > -- > > Thanks & Regards, > > Ashesh Vashi > EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com> > > > > *http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi> > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
