Re: Debugger freeze

Like Dave, I am not able to replicate the problem. However, I tested
with a Linux version of the database server and a Linux version of pgAdmin.

Dave, did you test on Windows or Linux?

Stefan - did you compile these packages (the database server and
pgAdmin) yourself? Or did you download and install a pre-built installer?

-- Korry

> Hi,
>
> This function and any other function work as usual outside of the
> debugger. Actually I found the problem when debugging a 'real'
> function. This one is just for the sake of a clean test.
> It seems that the delay causes the failure. I did this: start a debug
> session and loop quickly through the function body a hundred times
> step by step. It finished normally. Then started again then looped ten
> times then left it for about 3 minutes (the debug window did not lose
> focus) and then it froze with (2016-02-15 21:35:06 EET ERROR
> could not find block containing chunk 0000000001357490) in the log.
>
> I am not sure whether the problem first appeared on 9.5 or before.
> Please allow for some time to test on another server instance.
>
> Sincerely, Stefan
>
>
>
> >-------- Оригинално писмо --------
> >От: Korry Douglas korry(dot)douglas(at)enterprisedb(dot)com
> >Относно: Re: [pgadmin-support] Debugger freeze
> >До: Dave Page <dpage(at)pgadmin(dot)org>
> >Изпратено на: 15.02.2016 18:01
>
> As Dave mentioned, the interesting error message is probably this one:
>
> could not find block containing chunk 0000000001176B70
>
> That error occurs when the database server is trying to free a chunk
> of memory from a MemoryContext, but can't find the chunk within the
> context that owns the chunk.
>
> There is no legitimate reason that this can happen (in other words,
> it's a bug).
>
> In you description you say:
>
> Step a few times through the loop then take some time doing other
> things in pgadmin iii
>
> Do you think it's the delay that makes it fail? Or is it perhaps the
> other activity (browsing other data, running queries)? What happens
> if you let the debug session sit idle for a few minutes and then try
> stepping through your code?
>
> And (apologies if you've already answered these questions), can you
> run the sample function (dbg_test()) without the debugger? Can you
> debug other functions? Is this failure new with PG 9.5?
>
> Thanks.
>
>
> -- Korry
>
>
>
> The intriguing error message here is "could not find block
> containing chunk 0000000001176B70", which is coming from either
> the server or more likely, the debugger plugin.
>
> Korry - you're far more familiar with that code than me; any idea
> what could be causing this?
>
> On Sat, Feb 13, 2016 at 2:13 PM, Stefan Stefanov
> <stefanov(dot)sm(at)abv(dot)bg> wrote:
>
> Hi Dave, this part of pg_log/postgresql-2016-02-13_000000.log
> might help.
>
> 2016-02-13 16:05:23 EET ERROR: select() failed waiting for
> target
> 2016-02-13 16:05:23 EET STATEMENT: SELECT
> p.func, p.targetName, p.linenumber,
> pldbg_get_source($1::INTEGER, p.func) AS src,
> (SELECT
> s.args
> FROM pldbg_get_stack($1::INTEGER) s
> WHERE s.func = p.func) AS args
> FROM pldbg_step_over($1::INTEGER) p
> 2016-02-13 16:05:26 EET WARNING: unrecognized message
>
> 2016-02-13 16:05:26 EET CONTEXT: PL/pgSQL function
> playground.dbg_test() line 8 at RAISE
> 2016-02-13 16:05:26 EET ERROR: could not find block
> containing chunk 0000000001176B70
> 2016-02-13 16:05:26 EET CONTEXT: PL/pgSQL function
> playground.dbg_test() line 8 at RAISE
> 2016-02-13 16:05:26 EET STATEMENT: SELECT * FROM
> playground.dbg_test()
> 2016-02-13 16:06:02 EET LOG: could not receive data from
> client: No connection could be made because the target machine
> actively refused it.
>
>
> 2016-02-13 16:06:02 EET LOG: could not receive data from
> client: No connection could be made because the target machine
> actively refused it.
>
>
> 2016-02-13 16:06:02 EET LOG: could not receive data from
> client: No connection could be made because the target machine
> actively refused it.
>
>
> 2016-02-13 16:06:02 EET ERROR: debugger connection(client
> side) terminated
> 2016-02-13 16:06:02 EET STATEMENT: SELECT * FROM
> pldbg_abort_target(1)
> 2016-02-13 16:06:02 EET LOG: could not send data to client:
> No connection could be made because the target machine
> actively refused it.
>
>
> 2016-02-13 16:06:02 EET STATEMENT: SELECT * FROM
> pldbg_abort_target(1)
> 2016-02-13 16:06:02 EET FATAL: connection to client lost
> 2016-02-13 16:06:02 EET LOG: could not receive data from
> client: No connection could be made because the target machine
> actively refused it.
>
>
>
> Sincerely, Stefan
>
>
>
> >-------- Оригинално писмо --------
> >От: Dave Page dpage(at)pgadmin(dot)org
> >Относно: Re: [pgadmin-support] Debugger freeze
> >До: Stefan Stefanov <stefanov(dot)sm(at)abv(dot)bg>
> >Изпратено на: 12.02.2016 15:45
>
> Hi
>
> On Thu, Feb 11, 2016 at 6:36 PM, Stefan Stefanov
> <stefanov(dot)sm(at)abv(dot)bg> wrote:
>
> Dear Sir or Madam,
> I am writing to report a bug in pgadmin III 1.22.0 running
> on Windows 7 x64 connected to PostgreSQL 9.5.0 VC++ build
> 1800, 64 bit.
> To reproduce the bug create this trivial function using
> SQL query editor. The example is in "playground" schema.
>
> create function playground.dbg_test() returns void as
> $$
> declare
> i integer;
> t text;
> begin
> for i in 1 .. 100 loop
> t := 'XYZ' || to_char(i, '999');
> raise notice 'Round %', t;
> end loop;
> end;
> $$ language plpgsql;
>
> Right-click the function in Object browser then debug.
> Step a few times through the loop then take some time
> doing other things in pgadmin iii (browse data, run
> queries etc.) then return to the debug window and step
> again a few times. The debug window usually freezes
> (debug.png).
> Two locks remain (server status.png). The server may be
> cleared by cancelling the query of the global listener
> (pid 7748 in the example) but then pgadmin windows stop
> responding.
>
> This is preventing me from using the debugger and I need
> it badly.
>
>
> I've tried to reproduce this but am unable, even letting my
> machine go into powersave mode while the function is running.
>
> Can anyone else reproduce?
>
> Stefan, could it be that you're suffering from network
> disconnections? pgAdmin 3 really doesn't like them, and
> unfortunately it's a hard problem to fix given the current
> code structure (it's one of the things we're fixing in pgAdmin
> 4 which is completely new).
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>