Обсуждение: pgAdmin ver 1.10 freezing all too frequently

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time of
inactivity...
Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE

Reproducible by:
- - connect to a db
- - click on any of the db's objects
- - wait a while (1-3 minutes)
- - refresh the object

kaboom. it freezes. have to force termination.

Setting the log to "debug" offers no joy as to discover the cause...

I'm unsure as if it's a pgAdmin problem or rather a connection timeout...
At any rate... does pgAdmin make any attempt to KEEP_ALIVE (the
connection)?

Any insight highly appreciated as this is rather annoying ... ;)

Best regards,
Pedro Doria Meunier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrtaz0ACgkQ2FH5GXCfxAvyrgCeL7uYd7vbicUWxEQcqololsAm
wnwAnRJmDFaL0LFnhU1ntWmqT0WWBSDE
=khpI
-----END PGP SIGNATURE-----

On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
<pdoria@netmadeira.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time of
> inactivity...
> Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>
> Reproducible by:
> - - connect to a db
> - - click on any of the db's objects
> - - wait a while (1-3 minutes)
> - - refresh the object
>
> kaboom. it freezes. have to force termination.

I only have 64 bit CentOS 5 here at the moment, but I can't reproduce
on that. Anyone else?

> Setting the log to "debug" offers no joy as to discover the cause...
>
> I'm unsure as if it's a pgAdmin problem or rather a connection timeout...
> At any rate... does pgAdmin make any attempt to KEEP_ALIVE (the
> connection)?

No.

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start

----- Original Message -----
From: "Dave Page" <dpage@pgadmin.org>
To: "Pedro Doria Meunier" <pdoria@netmadeira.com>
Cc: "pgAdmin Support" <pgadmin-support@postgresql.org>
Sent: Sunday, November 1, 2009 6:07:39 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
Subject: Re: [pgadmin-support] pgAdmin ver 1.10 freezing all too frequently

On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
<pdoria@netmadeira.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time of
> inactivity...
> Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>
> Reproducible by:
> - - connect to a db
> - - click on any of the db's objects
> - - wait a while (1-3 minutes)
> - - refresh the object
>
> kaboom. it freezes. have to force termination.

I only have 64 bit CentOS 5 here at the moment, but I can't reproduce
on that. Anyone else?

I cannot reproduce the same on my Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE.
(I connected to a db which is running locally) Is it that you got that when you are connected with some remote server?


> Setting the log to "debug" offers no joy as to discover the cause...
>
> I'm unsure as if it's a pgAdmin problem or rather a connection timeout...
> At any rate... does pgAdmin make any attempt to KEEP_ALIVE (the
> connection)?

No.

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start

-- 
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

-- 
Regards,
Sachin Srivastava
www.enterprisedb.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Sorry forgot to tell it happens on a remote connection... :)

This is AFAICS is most probably a timeout problem.
It makes me wonder if my router isn't dropping idle connections...

Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl values
to see if it solves the problem.
btw:
tcp_keepalive_time = 75
tcp_keepalive_intvl = 60


I'll post my results.

BR,
Pedro Doria Meunier


On 11/01/2009 12:37 PM, Dave Page wrote:
> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
> <pdoria@netmadeira.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time of
>> inactivity...
>> Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>>
>> Reproducible by:
>> - - connect to a db
>> - - click on any of the db's objects
>> - - wait a while (1-3 minutes)
>> - - refresh the object
>>
>> kaboom. it freezes. have to force termination.
>
> I only have 64 bit CentOS 5 here at the moment, but I can't reproduce
> on that. Anyone else?
>
>> Setting the log to "debug" offers no joy as to discover the cause...
>>
>> I'm unsure as if it's a pgAdmin problem or rather a connection timeout...
>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE (the
>> connection)?
>
> No.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrto34ACgkQ2FH5GXCfxAsvuwCePKO950pHKcUx6OCmw5LVy3SM
xLAAn0YRPupAa0JqO8dHcR+0EfDcXyUX
=EIax
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying to self:
Altering the tcp_keepalive_time, tcp_keepalive_intvl values *didn't*
solve the problem.


On 11/01/2009 03:04 PM, Pedro Doria Meunier wrote:
>
> Sorry forgot to tell it happens on a remote connection... :)
>
> This is AFAICS is most probably a timeout problem. It makes me
> wonder if my router isn't dropping idle connections...
>
> Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl
> values to see if it solves the problem. btw: tcp_keepalive_time =
> 75 tcp_keepalive_intvl = 60
>
>
> I'll post my results.
>
> BR, Pedro Doria Meunier
>
>
> On 11/01/2009 12:37 PM, Dave Page wrote:
>> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
>> <pdoria@netmadeira.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Hi,
>>>
>>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time
>>> of inactivity... Fedora 11 - kernel 2.6.30.9-90.fc11.i686.PAE
>>>
>>> Reproducible by: - - connect to a db - - click on any of the
>>> db's objects - - wait a while (1-3 minutes) - - refresh the
>>> object
>>>
>>> kaboom. it freezes. have to force termination.
>
>> I only have 64 bit CentOS 5 here at the moment, but I can't
>> reproduce on that. Anyone else?
>
>>> Setting the log to "debug" offers no joy as to discover the
>>> cause...
>>>
>>> I'm unsure as if it's a pgAdmin problem or rather a connection
> timeout...
>>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE
>>> (the connection)?
>
>> No.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrtq3EACgkQ2FH5GXCfxAuPUQCdExxsfhj3pyrCXuK0MqB0Sm9w
xsIAoI3N5xHOiHlGQC6HfW2BtPXpTtlt
=gNcZ
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm "glad" :] I'm not alone in this...

It's definitely not the router. It's something else...

For instance:

- - One opens a table. leave it be for some time and the next operation
freezes pgAdmin, especially if one tries to open another database
object (or another database).

- - If the SAME object is closed and then re-opened, no matter what time
it takes, it opens without a problem.

I use pgAdmin *intensively* and it's becoming *inpractical* to work
with it to my great sorrow...

I sure hope the gurus come up with a fix for this... ;)

Best regards,
Pedro Doria Meunier





On 11/11/2009 03:20 PM, Michael Shapiro wrote:
> It just happened again. I ran a query in a window and after it
> completed I waited 10-15 minutes and ran it again. I got a
> connection error. I ran the query again (by hitting the green >
> icon) and it caused pgAdmin to crash.
>
> Moreover, I was simultaneously running another tool that was
> connected to a non-Postgres database. After PgAdmin crashed I ran a
> query in the other tool. It ran fine. This implies that the
> connection isn't being dropped by my router due to inactivity. It
> is probably happening within the Postgres server.
>
> I will try to run this test again using PgAdmin and a different
> tool that can connect to the same Postgres database.
>
>
> On Wed, Nov 11, 2009 at 8:32 AM, Michael Shapiro
> <mshapiro51@gmail.com <mailto:mshapiro51@gmail.com>> wrote:
>
> It happens to me quite a lot, as well. I will lose the contents of
> the SQL window as well when it happens.
>
> It would be good if PgAdmin would automatically try to reconnect
> (at least once) before giving up.
>
>
> On Wed, Nov 11, 2009 at 8:08 AM, Eugene Lisitsky
> <lisitsky@gmail.com <mailto:lisitsky@gmail.com>> wrote:
>
>
> I see such problem when remote servers replies slowly.
>
>
> 2009/11/1 Pedro Doria Meunier <pdoria@netmadeira.com
> <mailto:pdoria@netmadeira.com>>
>
> Replying to self: Altering the tcp_keepalive_time,
> tcp_keepalive_intvl values *didn't* solve the problem.
>
>
> On 11/01/2009 03:04 PM, Pedro Doria Meunier wrote:
>
>> Sorry forgot to tell it happens on a remote connection... :)
>
>> This is AFAICS is most probably a timeout problem. It makes me
>> wonder if my router isn't dropping idle connections...
>
>> Anyway I'm playing with tcp_keepalive_time, tcp_keepalive_intvl
>> values to see if it solves the problem. btw: tcp_keepalive_time
>> = 75 tcp_keepalive_intvl = 60
>
>
>> I'll post my results.
>
>> BR, Pedro Doria Meunier
>
>
>> On 11/01/2009 12:37 PM, Dave Page wrote:
>>> On Sun, Nov 1, 2009 at 11:04 AM, Pedro Doria Meunier
>>> <pdoria@netmadeira.com <mailto:pdoria@netmadeira.com>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> Hi,
>>>>
>>>> pgAdmin ver 1.10.0 rev. 7945:7946 freezes after a short time
>>>> of inactivity... Fedora 11 - kernel
>>>> 2.6.30.9-90.fc11.i686.PAE
>>>>
>>>> Reproducible by: - - connect to a db - - click on any of the
>>>> db's objects - - wait a while (1-3 minutes) - - refresh the
>>>> object
>>>>
>>>> kaboom. it freezes. have to force termination.
>
>>> I only have 64 bit CentOS 5 here at the moment, but I can't
>>> reproduce on that. Anyone else?
>
>>>> Setting the log to "debug" offers no joy as to discover the
>>>> cause...
>>>>
>>>> I'm unsure as if it's a pgAdmin problem or rather a
>>>> connection
>> timeout...
>>>> At any rate... does pgAdmin make any attempt to KEEP_ALIVE
>>>> (the connection)?
>
>>> No.
>

- --

Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org
<mailto:pgadmin-support@postgresql.org>)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support




> -- Yours, Eugene Lisitsky



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr62hAACgkQ2FH5GXCfxAtuIACbBJGfLn7Ohm9joY1t5UWBJ2Yp
ZMQAn1rfEXf4w3xTvYvayyuOtE53WXG7
=XkJO
-----END PGP SIGNATURE-----

On Wed, Nov 11, 2009 at 3:36 PM, Pedro Doria Meunier
<pdoria@netmadeira.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm "glad" :] I'm not alone in this...
>
> It's definitely not the router. It's something else...
>
> For instance:
>
> - - One opens a table. leave it be for some time and the next operation
> freezes pgAdmin, especially if one tries to open another database
> object (or another database).
>
> - - If the SAME object is closed and then re-opened, no matter what time
> it takes, it opens without a problem.
>
> I use pgAdmin *intensively* and it's becoming *inpractical* to work
> with it to my great sorrow...
>
> I sure hope the gurus come up with a fix for this... ;)

Being completely unable to reproduce the problem makes that extremely
unlikely I'm afraid.

Can you reproduce the problem with a debug-enabled build, and then
attach a debugger and get a backtrace?


-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dave

Did as you asked...

problem:
./pgadmin3: error while loading shared libraries:
libwx_gtk2ud_stc-2.8.so.0: cannot open shared object file: No such
file or directory
(on execution, after compilation)

This library is nowhere to be found...

Do you by any change have a debug-enable version of pgadmin3 on your
hands? ;)

BR,
Pedro Doria Meunier

On 11/11/2009 03:39 PM, Dave Page wrote:
> On Wed, Nov 11, 2009 at 3:36 PM, Pedro Doria Meunier
> <pdoria@netmadeira.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> I'm "glad" :] I'm not alone in this...
>>
>> It's definitely not the router. It's something else...
>>
>> For instance:
>>
>> - - One opens a table. leave it be for some time and the next
>> operation freezes pgAdmin, especially if one tries to open
>> another database object (or another database).
>>
>> - - If the SAME object is closed and then re-opened, no matter
>> what time it takes, it opens without a problem.
>>
>> I use pgAdmin *intensively* and it's becoming *inpractical* to
>> work with it to my great sorrow...
>>
>> I sure hope the gurus come up with a fix for this... ;)
>
> Being completely unable to reproduce the problem makes that
> extremely unlikely I'm afraid.
>
> Can you reproduce the problem with a debug-enabled build, and then
> attach a debugger and get a backtrace?
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr7CQAACgkQ2FH5GXCfxAuj8wCgkigdsRT7BK+Cy/JD91vNjn1+
IDYAn32nePEO0sJmLMfevV3a+U72DmfW
=D3I8
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok. please disregard that last one... :)

This is the last output of valgrind before I had to kill pgadmin:

==671== Thread 2:
==671== Syscall param write(buf) points to uninitialised byte(s)
==671==    at 0xBC4F4B: (within /lib/libpthread-2.10.1.so)
==671==    by 0x6149EE: BIO_write (in /usr/lib/libcrypto.so.0.9.8k)
==671==    by 0x742F93: ssl3_write_pending (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x743350: (within /usr/lib/libssl.so.0.9.8k)
==671==    by 0x743688: ssl3_write_bytes (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x7408A0: ssl3_write (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x7538B8: SSL_write (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x4B5995C: (within /usr/lib/libpq.so.5.1)
==671==    by 0x4B51316: (within /usr/lib/libpq.so.5.1)
==671==    by 0x4B4EBE7: PQsendQuery (in /usr/lib/libpq.so.5.1)
==671==    by 0x80D337B: pgQueryThread::execute() (pgQueryThread.cpp:104)
==671==    by 0x80D3A34: pgQueryThread::Entry() (pgQueryThread.cpp:210)
==671==  Address 0x933685d is 5 bytes inside a block of size 18,698
alloc'd
==671==    at 0x4006F3D: malloc (vg_replace_malloc.c:207)
==671==    by 0x6A05CD: (within /usr/lib/libcrypto.so.0.9.8k)
==671==    by 0x6A0C5B: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8k)
==671==    by 0x744BF8: ssl3_setup_buffers (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x73FDEF: ssl3_connect (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x753CA9: SSL_connect (in /usr/lib/libssl.so.0.9.8k)
==671==    by 0x4B59EFA: (within /usr/lib/libpq.so.5.1)
==671==    by 0x4B4A165: PQconnectPoll (in /usr/lib/libpq.so.5.1)
==671==    by 0x4B4AD67: (within /usr/lib/libpq.so.5.1)
==671==    by 0x4B4D342: PQconnectdb (in /usr/lib/libpq.so.5.1)
==671==    by 0x80CC832: pgConn::pgConn(wxString const&, wxString
const&, wxString const&, wxString const&, int, int, unsigned long)
(pgConn.cpp:175)
==671==    by 0x82F8778: pgServer::CreateConn(wxString, unsigned long)
(pgServer.cpp:140)
- --671-- memcheck GC: 131072 nodes, 114351 survivors ( 87.2%)
- --671-- memcheck GC: increase table size to 262144
Killed


At this point the app is irresponsive after I tried to access another
of the DB's objects..

Please tell me what more can I do on this end... ;)

BR,
Pedro Doria Meunier





On 11/11/2009 06:57 PM, Pedro Doria Meunier wrote:
> Hi Dave
>
> Did as you asked...
>
> problem: ./pgadmin3: error while loading shared libraries:
> libwx_gtk2ud_stc-2.8.so.0: cannot open shared object file: No such
> file or directory (on execution, after compilation)
>
> This library is nowhere to be found...
>
> Do you by any change have a debug-enable version of pgadmin3 on
> your hands? ;)
>
> BR, Pedro Doria Meunier
>
> On 11/11/2009 03:39 PM, Dave Page wrote:
>> On Wed, Nov 11, 2009 at 3:36 PM, Pedro Doria Meunier
>> <pdoria@netmadeira.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> I'm "glad" :] I'm not alone in this...
>>>
>>> It's definitely not the router. It's something else...
>>>
>>> For instance:
>>>
>>> - - One opens a table. leave it be for some time and the next
>>> operation freezes pgAdmin, especially if one tries to open
>>> another database object (or another database).
>>>
>>> - - If the SAME object is closed and then re-opened, no matter
>>> what time it takes, it opens without a problem.
>>>
>>> I use pgAdmin *intensively* and it's becoming *inpractical* to
>>> work with it to my great sorrow...
>>>
>>> I sure hope the gurus come up with a fix for this... ;)
>
>> Being completely unable to reproduce the problem makes that
>> extremely unlikely I'm afraid.
>
>> Can you reproduce the problem with a debug-enabled build, and
>> then attach a debugger and get a backtrace?
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr7F+IACgkQ2FH5GXCfxAu5NwCdFdY0s37PXJN4GkG4UEyYyzKD
IaEAn2zjsByg761rXDTF5u09zRU3em99
=fJnB
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok...

I've tried with valgrind and gdb attached ... no luck
with gdb alone and trying to get a stack trace ... no luck

whatever is happening with pgadmin3 under the beforementioned
conditions *freezes* everything ...

BR,
Pedro


On 11/11/2009 08:00 PM, Pedro Doria Meunier wrote:
> Ok. please disregard that last one... :)
>
> This is the last output of valgrind before I had to kill pgadmin:
>
> ==671== Thread 2: ==671== Syscall param write(buf) points to
> uninitialised byte(s) ==671==    at 0xBC4F4B: (within
> /lib/libpthread-2.10.1.so) ==671==    by 0x6149EE: BIO_write (in
> /usr/lib/libcrypto.so.0.9.8k) ==671==    by 0x742F93:
> ssl3_write_pending (in /usr/lib/libssl.so.0.9.8k) ==671==    by
> 0x743350: (within /usr/lib/libssl.so.0.9.8k) ==671==    by
> 0x743688: ssl3_write_bytes (in /usr/lib/libssl.so.0.9.8k) ==671==
> by 0x7408A0: ssl3_write (in /usr/lib/libssl.so.0.9.8k) ==671==
> by 0x7538B8: SSL_write (in /usr/lib/libssl.so.0.9.8k) ==671==    by
> 0x4B5995C: (within /usr/lib/libpq.so.5.1) ==671==    by 0x4B51316:
> (within /usr/lib/libpq.so.5.1) ==671==    by 0x4B4EBE7: PQsendQuery
> (in /usr/lib/libpq.so.5.1) ==671==    by 0x80D337B:
> pgQueryThread::execute() (pgQueryThread.cpp:104) ==671==    by
> 0x80D3A34: pgQueryThread::Entry() (pgQueryThread.cpp:210) ==671==
> Address 0x933685d is 5 bytes inside a block of size 18,698 alloc'd
> ==671==    at 0x4006F3D: malloc (vg_replace_malloc.c:207) ==671==
> by 0x6A05CD: (within /usr/lib/libcrypto.so.0.9.8k) ==671==    by
> 0x6A0C5B: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8k) ==671==
> by 0x744BF8: ssl3_setup_buffers (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x73FDEF: ssl3_connect (in
> /usr/lib/libssl.so.0.9.8k) ==671==    by 0x753CA9: SSL_connect (in
> /usr/lib/libssl.so.0.9.8k) ==671==    by 0x4B59EFA: (within
> /usr/lib/libpq.so.5.1) ==671==    by 0x4B4A165: PQconnectPoll (in
> /usr/lib/libpq.so.5.1) ==671==    by 0x4B4AD67: (within
> /usr/lib/libpq.so.5.1) ==671==    by 0x4B4D342: PQconnectdb (in
> /usr/lib/libpq.so.5.1) ==671==    by 0x80CC832:
> pgConn::pgConn(wxString const&, wxString const&, wxString const&,
> wxString const&, int, int, unsigned long) (pgConn.cpp:175) ==671==
> by 0x82F8778: pgServer::CreateConn(wxString, unsigned long)
> (pgServer.cpp:140) --671-- memcheck GC: 131072 nodes, 114351
> survivors ( 87.2%) --671-- memcheck GC: increase table size to
> 262144 Killed
>
>
> At this point the app is irresponsive after I tried to access
> another of the DB's objects..
>
> Please tell me what more can I do on this end... ;)
>
> BR, Pedro Doria Meunier
>
>
>
>
>
> On 11/11/2009 06:57 PM, Pedro Doria Meunier wrote:
>> Hi Dave
>
>> Did as you asked...
>
>> problem: ./pgadmin3: error while loading shared libraries:
>> libwx_gtk2ud_stc-2.8.so.0: cannot open shared object file: No
>> such file or directory (on execution, after compilation)
>
>> This library is nowhere to be found...
>
>> Do you by any change have a debug-enable version of pgadmin3 on
>> your hands? ;)
>
>> BR, Pedro Doria Meunier
>
>> On 11/11/2009 03:39 PM, Dave Page wrote:
>>> On Wed, Nov 11, 2009 at 3:36 PM, Pedro Doria Meunier
>>> <pdoria@netmadeira.com> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> I'm "glad" :] I'm not alone in this...
>>>>
>>>> It's definitely not the router. It's something else...
>>>>
>>>> For instance:
>>>>
>>>> - - One opens a table. leave it be for some time and the
>>>> next operation freezes pgAdmin, especially if one tries to
>>>> open another database object (or another database).
>>>>
>>>> - - If the SAME object is closed and then re-opened, no
>>>> matter what time it takes, it opens without a problem.
>>>>
>>>> I use pgAdmin *intensively* and it's becoming *inpractical*
>>>> to work with it to my great sorrow...
>>>>
>>>> I sure hope the gurus come up with a fix for this... ;)
>
>>> Being completely unable to reproduce the problem makes that
>>> extremely unlikely I'm afraid.
>
>>> Can you reproduce the problem with a debug-enabled build, and
>>> then attach a debugger and get a backtrace?
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr7MfgACgkQ2FH5GXCfxAub6QCdEabLsGFaBwUTrou2qANzXGFk
FV8AoKOBV5q0BjIgF/y6Yc/L5AZSOV59
=OEwJ
-----END PGP SIGNATURE-----

On Wed, Nov 11, 2009 at 6:57 PM, Pedro Doria Meunier
<pdoria@netmadeira.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Dave
>
> Did as you asked...
>
> problem:
> ./pgadmin3: error while loading shared libraries:
> libwx_gtk2ud_stc-2.8.so.0: cannot open shared object file: No such
> file or directory
> (on execution, after compilation)
>
> This library is nowhere to be found...

Looks like you're missing the wxSTC contrib module. That might be a
separate package on whatever OS you're using.

> Do you by any change have a debug-enable version of pgadmin3 on your
> hands? ;)

I have one for Mac OS X Snow Leopard, or Windows....

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Wed, Nov 11, 2009 at 8:00 PM, Pedro Doria Meunier
<pdoria@netmadeira.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ok. please disregard that last one... :)
>
> This is the last output of valgrind before I had to kill pgadmin:
>
> ==671== Thread 2:
> ==671== Syscall param write(buf) points to uninitialised byte(s)
> ==671==    at 0xBC4F4B: (within /lib/libpthread-2.10.1.so)
> ==671==    by 0x6149EE: BIO_write (in /usr/lib/libcrypto.so.0.9.8k)
> ==671==    by 0x742F93: ssl3_write_pending (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x743350: (within /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x743688: ssl3_write_bytes (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x7408A0: ssl3_write (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x7538B8: SSL_write (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x4B5995C: (within /usr/lib/libpq.so.5.1)
> ==671==    by 0x4B51316: (within /usr/lib/libpq.so.5.1)
> ==671==    by 0x4B4EBE7: PQsendQuery (in /usr/lib/libpq.so.5.1)
> ==671==    by 0x80D337B: pgQueryThread::execute() (pgQueryThread.cpp:104)
> ==671==    by 0x80D3A34: pgQueryThread::Entry() (pgQueryThread.cpp:210)
> ==671==  Address 0x933685d is 5 bytes inside a block of size 18,698
> alloc'd
> ==671==    at 0x4006F3D: malloc (vg_replace_malloc.c:207)
> ==671==    by 0x6A05CD: (within /usr/lib/libcrypto.so.0.9.8k)
> ==671==    by 0x6A0C5B: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8k)
> ==671==    by 0x744BF8: ssl3_setup_buffers (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x73FDEF: ssl3_connect (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x753CA9: SSL_connect (in /usr/lib/libssl.so.0.9.8k)
> ==671==    by 0x4B59EFA: (within /usr/lib/libpq.so.5.1)
> ==671==    by 0x4B4A165: PQconnectPoll (in /usr/lib/libpq.so.5.1)
> ==671==    by 0x4B4AD67: (within /usr/lib/libpq.so.5.1)
> ==671==    by 0x4B4D342: PQconnectdb (in /usr/lib/libpq.so.5.1)
> ==671==    by 0x80CC832: pgConn::pgConn(wxString const&, wxString
> const&, wxString const&, wxString const&, int, int, unsigned long)
> (pgConn.cpp:175)
> ==671==    by 0x82F8778: pgServer::CreateConn(wxString, unsigned long)
> (pgServer.cpp:140)
> - --671-- memcheck GC: 131072 nodes, 114351 survivors ( 87.2%)
> - --671-- memcheck GC: increase table size to 262144
> Killed
>

Can you reproduce the problem with SSL disabled?


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave,

With SSL disable it's the same thing...

BR,
Pedro.


On 11/12/2009 09:22 AM, Dave Page wrote:
> On Wed, Nov 11, 2009 at 8:00 PM, Pedro Doria Meunier
> <pdoria@netmadeira.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ok. please disregard that last one... :)
>>
>> This is the last output of valgrind before I had to kill pgadmin:
>>
>> ==671== Thread 2:
>> ==671== Syscall param write(buf) points to uninitialised byte(s)
>> ==671==    at 0xBC4F4B: (within /lib/libpthread-2.10.1.so)
>> ==671==    by 0x6149EE: BIO_write (in /usr/lib/libcrypto.so.0.9.8k)
>> ==671==    by 0x742F93: ssl3_write_pending (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x743350: (within /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x743688: ssl3_write_bytes (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x7408A0: ssl3_write (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x7538B8: SSL_write (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x4B5995C: (within /usr/lib/libpq.so.5.1)
>> ==671==    by 0x4B51316: (within /usr/lib/libpq.so.5.1)
>> ==671==    by 0x4B4EBE7: PQsendQuery (in /usr/lib/libpq.so.5.1)
>> ==671==    by 0x80D337B: pgQueryThread::execute() (pgQueryThread.cpp:104)
>> ==671==    by 0x80D3A34: pgQueryThread::Entry() (pgQueryThread.cpp:210)
>> ==671==  Address 0x933685d is 5 bytes inside a block of size 18,698
>> alloc'd
>> ==671==    at 0x4006F3D: malloc (vg_replace_malloc.c:207)
>> ==671==    by 0x6A05CD: (within /usr/lib/libcrypto.so.0.9.8k)
>> ==671==    by 0x6A0C5B: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8k)
>> ==671==    by 0x744BF8: ssl3_setup_buffers (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x73FDEF: ssl3_connect (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x753CA9: SSL_connect (in /usr/lib/libssl.so.0.9.8k)
>> ==671==    by 0x4B59EFA: (within /usr/lib/libpq.so.5.1)
>> ==671==    by 0x4B4A165: PQconnectPoll (in /usr/lib/libpq.so.5.1)
>> ==671==    by 0x4B4AD67: (within /usr/lib/libpq.so.5.1)
>> ==671==    by 0x4B4D342: PQconnectdb (in /usr/lib/libpq.so.5.1)
>> ==671==    by 0x80CC832: pgConn::pgConn(wxString const&, wxString
>> const&, wxString const&, wxString const&, int, int, unsigned long)
>> (pgConn.cpp:175)
>> ==671==    by 0x82F8778: pgServer::CreateConn(wxString, unsigned long)
>> (pgServer.cpp:140)
>> - --671-- memcheck GC: 131072 nodes, 114351 survivors ( 87.2%)
>> - --671-- memcheck GC: increase table size to 262144
>> Killed
>>
>
> Can you reproduce the problem with SSL disabled?
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr75lsACgkQ2FH5GXCfxAs7cwCfaoGfyuuiEXrV9EI6W0ABnhLk
BK8AoL5qz9GDkXbKCafMULl/IWtPElp6
=ZdL9
-----END PGP SIGNATURE-----

On Thu, Nov 12, 2009 at 10:41 AM, Pedro Doria Meunier
<pdoria@netmadeira.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dave,
>
> With SSL disable it's the same thing...

Can you get the trace please?


-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm sorry Dave.

I'm unable to... :(

Whenever I try to get a backtrace it's already frozen solid and
there's nothing to do other than kill it...

BR,
Pedro

On 11/12/2009 10:43 AM, Dave Page wrote:
> On Thu, Nov 12, 2009 at 10:41 AM, Pedro Doria Meunier
> <pdoria@netmadeira.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> Dave,
>>
>> With SSL disable it's the same thing...
>
> Can you get the trace please?
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr77DkACgkQ2FH5GXCfxAtPCgCdEm3vPmUl0Gqu86TN5bVf7aXJ
E74An17/Pt/ox0qxd+e2tlu33Jjbybwm
=6wvn
-----END PGP SIGNATURE-----

On Thu, Nov 12, 2009 at 11:06 AM, Pedro Doria Meunier
<pdoria@netmadeira.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm sorry Dave.
>
> I'm unable to... :(
>
> Whenever I try to get a backtrace it's already frozen solid and
> there's nothing to do other than kill it...

If you start it under gdb, doesn't gdb break when you kill pgAdmin?
Something like:

Program received signal SIGKILL, Killed.
0x943407da in mach_msg_trap ()
(gdb)
(gdb) bt
#0  0x943407da in mach_msg_trap ()
#1  0x94340f47 in mach_msg ()
#2  0x99006dbf in __CFRunLoopRun ()
#3  0x99005d34 in CFRunLoopRunSpecific ()
#4  0x99005b61 in CFRunLoopRunInMode ()
#5  0x919f3fec in RunCurrentEventLoopInMode ()
#6  0x919f3da3 in ReceiveNextEventCommon ()
#7  0x91b7bd91 in ReceiveNextEvent ()
#8  0x00e9d7e7 in wxApp::MacDoOneEvent ()
#9  0x00eb6fd3 in wxEventLoop::Dispatch ()
#10 0x00f5d708 in wxEventLoopManual::Run ()
#11 0x00f36bf3 in wxAppBase::MainLoop ()
#12 0x0136981a in wxEntry ()
#13 0x0003f548 in main ()

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dave,

I was thinking about Michael's observations and the fact that this
problem never happened if the server status window was opened.

So what I did was:
set the "tcp_keepalives_interval" = 75 and reloaded the server's
configuration.

No more freezes ever since! :)

IMHO, however, pgAdmin should better handle connection status or,
alternatively, check it and initiate a new connection if the previous
one stalled...

I have *some* C proficiency so if you point me in the right direction
I might start investigating it and try to come up with a solution ... ;)

BR,
Pedro.

On 11/12/2009 11:17 AM, Dave Page wrote:
> On Thu, Nov 12, 2009 at 11:06 AM, Pedro Doria Meunier
> <pdoria@netmadeira.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> I'm sorry Dave.
>>
>> I'm unable to... :(
>>
>> Whenever I try to get a backtrace it's already frozen solid and
>> there's nothing to do other than kill it...
>
> If you start it under gdb, doesn't gdb break when you kill
> pgAdmin? Something like:
>
> Program received signal SIGKILL, Killed. 0x943407da in
> mach_msg_trap () (gdb) (gdb) bt #0  0x943407da in mach_msg_trap ()
> #1  0x94340f47 in mach_msg () #2  0x99006dbf in __CFRunLoopRun ()
> #3  0x99005d34 in CFRunLoopRunSpecific () #4  0x99005b61 in
> CFRunLoopRunInMode () #5  0x919f3fec in RunCurrentEventLoopInMode
> () #6  0x919f3da3 in ReceiveNextEventCommon () #7  0x91b7bd91 in
> ReceiveNextEvent () #8  0x00e9d7e7 in wxApp::MacDoOneEvent () #9
> 0x00eb6fd3 in wxEventLoop::Dispatch () #10 0x00f5d708 in
> wxEventLoopManual::Run () #11 0x00f36bf3 in wxAppBase::MainLoop ()
> #12 0x0136981a in wxEntry () #13 0x0003f548 in main ()
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr79B8ACgkQ2FH5GXCfxAsqpgCdGaG/70MMclIByU9Z0vwD918s
vnEAoLceWLH7/y+RpLMl+UnWXvrsnvoZ
=F1nX
-----END PGP SIGNATURE-----

On Thu, Nov 12, 2009 at 1:08 PM, Michael Shapiro <mshapiro51@gmail.com> wrote:

> Note that if someone wants to replicate my problem, they could use these
> settings and run PgAdmin from a Windows box (since the settings don't mean
> anything for Unix connections).

It hangs on a Windows box?


-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael,

My postgresql.conf, tcp-related, bit:
tcp_keepalives_idle = 75                # TCP_KEEPIDLE, in seconds;                                       # 0 selects
thesystem default
 
tcp_keepalives_interval = 60            # TCP_KEEPINTVL, in seconds;                                       # 0 selects
thesystem default
 
#tcp_keepalives_count = 0               # TCP_KEEPCNT;                                       # 0 selects the system
default

BR,
Pedro.


On 11/12/2009 01:08 PM, Michael Shapiro wrote:
> My server's setting are:
>
> 'tcp_keepalives_count','9' 'tcp_keepalives_idle','7200'
> 'tcp_keepalives_interval','75'
>
> and I still get the problem. I just have to wait 20 minutes or so.
>
> (I don't really know how to predict how long it takes to lose a
> connection, even knowing these settings)
>
> Note that if someone wants to replicate my problem, they could use
> these settings and run PgAdmin from a Windows box (since the
> settings don't mean anything for Unix connections).
>
> Pedro, what are your setttings?
>
> On Thu, Nov 12, 2009 at 5:40 AM, Pedro Doria Meunier
> <pdoria@netmadeira.com <mailto:pdoria@netmadeira.com>> wrote:
>
> Hi Dave,
>
> I was thinking about Michael's observations and the fact that this
> problem never happened if the server status window was opened.
>
> So what I did was: set the "tcp_keepalives_interval" = 75 and
> reloaded the server's configuration.
>
> No more freezes ever since! :)
>
> IMHO, however, pgAdmin should better handle connection status or,
> alternatively, check it and initiate a new connection if the
> previous one stalled...
>
> I have *some* C proficiency so if you point me in the right
> direction I might start investigating it and try to come up with a
> solution ... ;)
>
> BR, Pedro.
>
> On 11/12/2009 11:17 AM, Dave Page wrote:
>> On Thu, Nov 12, 2009 at 11:06 AM, Pedro Doria Meunier
>> <pdoria@netmadeira.com <mailto:pdoria@netmadeira.com>> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> I'm sorry Dave.
>>>
>>> I'm unable to... :(
>>>
>>> Whenever I try to get a backtrace it's already frozen solid
>>> and there's nothing to do other than kill it...
>
>> If you start it under gdb, doesn't gdb break when you kill
>> pgAdmin? Something like:
>
>> Program received signal SIGKILL, Killed. 0x943407da in
>> mach_msg_trap () (gdb) (gdb) bt #0  0x943407da in mach_msg_trap
>> () #1  0x94340f47 in mach_msg () #2  0x99006dbf in __CFRunLoopRun
>> () #3  0x99005d34 in CFRunLoopRunSpecific () #4  0x99005b61 in
>> CFRunLoopRunInMode () #5  0x919f3fec in
>> RunCurrentEventLoopInMode () #6  0x919f3da3 in
>> ReceiveNextEventCommon () #7  0x91b7bd91 in ReceiveNextEvent ()
>> #8  0x00e9d7e7 in wxApp::MacDoOneEvent () #9 0x00eb6fd3 in
>> wxEventLoop::Dispatch () #10 0x00f5d708 in wxEventLoopManual::Run
>> () #11 0x00f36bf3 in wxAppBase::MainLoop () #12 0x0136981a in
>> wxEntry () #13 0x0003f548 in main ()
>

- --
Sent via pgadmin-support mailing list
(pgadmin-support@postgresql.org
<mailto:pgadmin-support@postgresql.org>)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr8DB0ACgkQ2FH5GXCfxAsNugCgqfajYwo0fuhw/BmH2elF9JlA
0zUAnA13I5GDbOytVkK+az2P/UcatjWs
=80sf
-----END PGP SIGNATURE-----

On Thu, Nov 12, 2009 at 1:15 PM, Michael Shapiro <mshapiro51@gmail.com> wrote:
> Yes, I am using Windows. I wouldn't describe what I see as hanging or
> freezing, just losing the connection and then crashing if I try to run the
> query again....

Let's try to keep these issues seperate then - they clearly have
different symptoms.

Can you reproduce the problem using a psql connection?


-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com