Korry,
I used EDB graphic installer.
Sincerely,
Stefan
>-------- Оригинално писмо --------
>От: Korry Douglas korry.doug...@enterprisedb.com
>Относно: Re: [pgadmin-support] Debugger freeze
>До: Stefan Stefanov
>Изпратено на: 15.02.2016 23:30
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.doug...@enterprisedb.com
>Относно: Re: [pgadmin-support] Debugger freeze
>До: Dave Page
>Изпратено на: 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...@abv.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 dp...@pgadmin.org
>Относно: Re: [pgadmin-support] Debugger freeze
>До: Stefan Stefanov stefanov...@abv.bg >
>Изпратено на: 12.02.2016 15:45
Hi
On Thu, Feb 11, 2016 at 6:36 PM, Stefan Stefanov
stefanov...@abv.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
