Thread: pgAdmin crashes on DDL

Ever since I started using pgAdmin (in 2006 or so) it has always crashed
about once an hour of active usage. I finally decided to report this.

Here's one way to reproduce the problem with the latest pgAdmin (1.16.1):
- connect to a database, go to the public schema
- right-click "Tables", choose "New Table"
- use the GUI to create a table called "foo" with a single column called
"bar", of type integer (ignore the no primary keys warning)
- just to double-check, clicking "foo" in the tree now shows the create
table statement which looks something like this: -- Table: foo -- DROP TABLE foo; CREATE TABLE foo (   bar integer )
WITH(   OIDS=FALSE ); ALTER TABLE foo   OWNER TO postgres;
 
- right-click "foo" in the tree, choose "Scripts -> CREATE Script"
- in the query window, uncomment "DROP TABLE foo;", change integer to
serial, then run the query
- close the query window, without saving changes

At this point, pgAdmin instantly crashes with a segmentation fault.

Some more information about my environment:
- The operating system and version details -- Gentoo Linux
- The version of pgAdmin you are running. -- pgadmin3-1.16.1-r1 (about
window reports 1.16.1)
- The configure options used (if compiled from source) -- for now I can
provide the Gentoo USE flags: databasedesigner -debug
- The wxWidgets version and configure options used (if compiled from source)
-- I believe the answer is wxGTK-2.8.12.1, USE flags: X opengl sdl tiff
-aqua -debug -doc -gnome -gstreamer -odbc -pch

P.S. I suggest setting up a proper bug tracker instead of this medieval
mailing list system



--
View this message in context: http://postgresql.1045698.n5.nabble.com/pgAdmin-crashes-on-DDL-tp5754991.html
Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com.

Hi

On Fri, May 10, 2013 at 11:35 AM, aditsu <aditsu@yahoo.com> wrote:
> Ever since I started using pgAdmin (in 2006 or so) it has always crashed
> about once an hour of active usage. I finally decided to report this.
>
> Here's one way to reproduce the problem with the latest pgAdmin (1.16.1):
> - connect to a database, go to the public schema
> - right-click "Tables", choose "New Table"
> - use the GUI to create a table called "foo" with a single column called
> "bar", of type integer (ignore the no primary keys warning)
> - just to double-check, clicking "foo" in the tree now shows the create
> table statement which looks something like this:
>   -- Table: foo
>   -- DROP TABLE foo;
>   CREATE TABLE foo
>   (
>     bar integer
>   )
>   WITH (
>     OIDS=FALSE
>   );
>   ALTER TABLE foo
>     OWNER TO postgres;
> - right-click "foo" in the tree, choose "Scripts -> CREATE Script"
> - in the query window, uncomment "DROP TABLE foo;", change integer to
> serial, then run the query
> - close the query window, without saving changes
>
> At this point, pgAdmin instantly crashes with a segmentation fault.
>
> Some more information about my environment:
> - The operating system and version details -- Gentoo Linux
> - The version of pgAdmin you are running. -- pgadmin3-1.16.1-r1 (about
> window reports 1.16.1)
> - The configure options used (if compiled from source) -- for now I can
> provide the Gentoo USE flags: databasedesigner -debug
> - The wxWidgets version and configure options used (if compiled from source)
> -- I believe the answer is wxGTK-2.8.12.1, USE flags: X opengl sdl tiff
> -aqua -debug -doc -gnome -gstreamer -odbc -pch

I finally managed to track this down I think. It only seems to go
wrong on Linux, only when browser refresh is set to "Refresh on
click", and only when an object can't be automatically refreshed
(usually because it's OID changed). What I believe happens is that on
GTK when the treeview node is removed, the parent node isn't
automatically selected, whereas on other platforms it is. Simple fix
seems to be to explicitly select the parent node before dropping the
original one.

Akshay, can you please test and see if you agree the fix is appropriate?

> P.S. I suggest setting up a proper bug tracker instead of this medieval
> mailing list system

We have one, but as probably 75% of the issues raised here are not
pgAdmin bugs, we use it to track triaged issues that we're not
immediately working on, to save having to keep updating/closing
non-issues.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, May 20, 2013 at 11:24 AM, Akshay Joshi
<akshay.joshi@enterprisedb.com> wrote:
>
>
>
> On Fri, May 17, 2013 at 9:55 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> On Fri, May 10, 2013 at 11:35 AM, aditsu <aditsu@yahoo.com> wrote:
>> > Ever since I started using pgAdmin (in 2006 or so) it has always crashed
>> > about once an hour of active usage. I finally decided to report this.
>> >
>> > Here's one way to reproduce the problem with the latest pgAdmin
>> > (1.16.1):
>> > - connect to a database, go to the public schema
>> > - right-click "Tables", choose "New Table"
>> > - use the GUI to create a table called "foo" with a single column called
>> > "bar", of type integer (ignore the no primary keys warning)
>> > - just to double-check, clicking "foo" in the tree now shows the create
>> > table statement which looks something like this:
>> >   -- Table: foo
>> >   -- DROP TABLE foo;
>> >   CREATE TABLE foo
>> >   (
>> >     bar integer
>> >   )
>> >   WITH (
>> >     OIDS=FALSE
>> >   );
>> >   ALTER TABLE foo
>> >     OWNER TO postgres;
>> > - right-click "foo" in the tree, choose "Scripts -> CREATE Script"
>> > - in the query window, uncomment "DROP TABLE foo;", change integer to
>> > serial, then run the query
>> > - close the query window, without saving changes
>> >
>> > At this point, pgAdmin instantly crashes with a segmentation fault.
>> >
>> > Some more information about my environment:
>> > - The operating system and version details -- Gentoo Linux
>> > - The version of pgAdmin you are running. -- pgadmin3-1.16.1-r1 (about
>> > window reports 1.16.1)
>> > - The configure options used (if compiled from source) -- for now I can
>> > provide the Gentoo USE flags: databasedesigner -debug
>> > - The wxWidgets version and configure options used (if compiled from
>> > source)
>> > -- I believe the answer is wxGTK-2.8.12.1, USE flags: X opengl sdl tiff
>> > -aqua -debug -doc -gnome -gstreamer -odbc -pch
>>
>> I finally managed to track this down I think. It only seems to go
>> wrong on Linux, only when browser refresh is set to "Refresh on
>> click", and only when an object can't be automatically refreshed
>> (usually because it's OID changed). What I believe happens is that on
>> GTK when the treeview node is removed, the parent node isn't
>> automatically selected, whereas on other platforms it is. Simple fix
>> seems to be to explicitly select the parent node before dropping the
>> original one.
>>
>> Akshay, can you please test and see if you agree the fix is appropriate?
>
>
>    I am not able to reproduce the issue on my machine. Is there any
> particular steps to reproduce it?

The steps above worked for me, though you may need to click "Tables"
and then "foo" again after closing the query tool. I also found that
it needed to be on Linux, and needed to have the "Refresh on click"
option set on the Options dialogue ("None" and "Refresh object and
children" didn't crash).



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Dave Page-7 wrote
>>> > [...]
>>> > - close the query window, without saving changes
>>> >
>>> > At this point, pgAdmin instantly crashes with a segmentation fault.
> 
> The steps above worked for me, though you may need to click "Tables"
> and then "foo" again after closing the query tool. I also found that
> it needed to be on Linux, and needed to have the "Refresh on click"
> option set on the Options dialogue ("None" and "Refresh object and
> children" didn't crash).

After closing the query tool I can't click on anything because pgadmin is
already dead.
"Refresh on click" is set to None.

Adrian



--
View this message in context: http://postgresql.1045698.n5.nabble.com/pgAdmin-crashes-on-DDL-tp5754991p5756192.html
Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com.

Dave Page-7 wrote

[...]

- close the query window, without saving changes

At this point, pgAdmin instantly crashes with a segmentation fault.

The steps above worked for me, though you may need to click "Tables"

and then "foo" again after closing the query tool. I also found that

it needed to be on Linux, and needed to have the "Refresh on click"

option set on the Options dialogue ("None" and "Refresh object and

children" didn't crash).

After closing the query tool I can't click on anything because pgadmin is
already dead.
"Refresh on click" is set to None.

Adrian



--
View this message in context: http://postgresql.1045698.n5.nabble.com/pgAdmin-crashes-on-DDL-tp5754991p5756192.html
Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com.


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

Dave Page-7 wrote
> I definitely can't reproduce that then. :-/
> 
>> After closing the query tool I can't click on anything because pgadmin is
>> already dead.
>> "Refresh on click" is set to None.
>> 
>> Adrian

Is this helpful? https://397921.bugs.gentoo.org/attachment.cgi?id=298223
I'll try to obtain a new backtrace under the exact conditions I described in
this report.

Adrian



--
View this message in context: http://postgresql.1045698.n5.nabble.com/pgAdmin-crashes-on-DDL-tp5754991p5756198.html
Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com.

aditsu wrote
> 
> Dave Page-7 wrote
>> I definitely can't reproduce that then. :-/
>> 
>>> After closing the query tool I can't click on anything because pgadmin
>>> is
>>> already dead.
>>> "Refresh on click" is set to None.
>>> 
>>> Adrian
> Is this helpful? https://397921.bugs.gentoo.org/attachment.cgi?id=298223
> I'll try to obtain a new backtrace under the exact conditions I described
> in this report.
> 
> Adrian

Ok, first time I tried to reproduce it running from gdb it didn't crash,
then I tried again outside of gdb and it crashed. Then I ran it from gdb
again, the last version of foo was still there (with the serial column), I
just did the "create script" thing and changed it back to integer, and this
time it crashed as expected. Backtrace attached (hopefully, not sure how
upload works on nabble).

backtrace <http://postgresql.1045698.n5.nabble.com/file/n5756202/backtrace>  



--
View this message in context: http://postgresql.1045698.n5.nabble.com/pgAdmin-crashes-on-DDL-tp5754991p5756202.html
Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com.

Ashesh Vashi wrote
>> aditsu wrote
>> Ok, first time I tried to reproduce it running from gdb it didn't crash,
>> then I tried again outside of gdb and it crashed. Then I ran it from gdb
>> again, the last version of foo was still there (with the serial column),
>> I
>> just did the "create script" thing and changed it back to integer, and
>> this
>> time it crashed as expected. Backtrace attached
>>
> Can you please share the script or sample of script? (Is it pgScript?)

Well, as I said, I went to "create script" on the "foo" table. The script
looked like this when I opened it:


Then I changed it to:


and ran it, and closed the query window. Crash followed instantly.



--
View this message in context: http://postgresql.1045698.n5.nabble.com/pgAdmin-crashes-on-DDL-tp5754991p5756222.html
Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com.

On Mon, May 20, 2013 at 3:00 PM, aditsu <aditsu@yahoo.com> wrote:
> aditsu wrote
>>
>> Dave Page-7 wrote
>>> I definitely can't reproduce that then. :-/
>>>
>>>> After closing the query tool I can't click on anything because pgadmin
>>>> is
>>>> already dead.
>>>> "Refresh on click" is set to None.
>>>>
>>>> Adrian
>> Is this helpful? https://397921.bugs.gentoo.org/attachment.cgi?id=298223
>> I'll try to obtain a new backtrace under the exact conditions I described
>> in this report.
>>
>> Adrian
>
> Ok, first time I tried to reproduce it running from gdb it didn't crash,
> then I tried again outside of gdb and it crashed. Then I ran it from gdb
> again, the last version of foo was still there (with the serial column), I
> just did the "create script" thing and changed it back to integer, and this
> time it crashed as expected. Backtrace attached (hopefully, not sure how
> upload works on nabble).
>
> backtrace <http://postgresql.1045698.n5.nabble.com/file/n5756202/backtrace>

Well that's just bizzarre Had you used the query builder at all?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Dave Page-7 wrote
>> Ok, first time I tried to reproduce it running from gdb it didn't crash,
>> then I tried again outside of gdb and it crashed. Then I ran it from gdb
>> again, the last version of foo was still there (with the serial column),
>> I
>> just did the "create script" thing and changed it back to integer, and
>> this
>> time it crashed as expected. Backtrace attached (hopefully, not sure how
>> upload works on nabble).
>>
>> backtrace http://postgresql.1045698.n5.nabble.com/file/n5756202/backtrace
> 
> Well that's just bizzarre Had you used the query builder at all?

The "Graphical Query Builder" tab in the query window? No I don't remember
using it. Ever.

Adrian



--
View this message in context: http://postgresql.1045698.n5.nabble.com/pgAdmin-crashes-on-DDL-tp5754991p5756262.html
Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com.

aditsu wrote
> Ok, first time I tried to reproduce it running from gdb it didn't crash,
> then I tried again outside of gdb and it crashed. Then I ran it from gdb
> again, the last version of foo was still there (with the serial column), I
> just did the "create script" thing and changed it back to integer, and
> this time it crashed as expected. Backtrace attached (hopefully, not sure
> how upload works on nabble).
> backtrace
> <http://postgresql.1045698.n5.nabble.com/file/n5756202/backtrace>  

Any update on this? It looks like I get the exact same backtrace every time,
in slightly different circumstances. Sometimes even after opening and
closing a blank query window (from the toolbar sql button).



--
View this message in context: http://postgresql.1045698.n5.nabble.com/pgAdmin-crashes-on-DDL-tp5754991p5757647.html
Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com.

On Sat, Jun 1, 2013 at 11:38 AM, aditsu <aditsu@yahoo.com> wrote:
> aditsu wrote
>> Ok, first time I tried to reproduce it running from gdb it didn't crash,
>> then I tried again outside of gdb and it crashed. Then I ran it from gdb
>> again, the last version of foo was still there (with the serial column), I
>> just did the "create script" thing and changed it back to integer, and
>> this time it crashed as expected. Backtrace attached (hopefully, not sure
>> how upload works on nabble).
>> backtrace
>> <http://postgresql.1045698.n5.nabble.com/file/n5756202/backtrace>
>
> Any update on this? It looks like I get the exact same backtrace every time,
> in slightly different circumstances. Sometimes even after opening and
> closing a blank query window (from the toolbar sql button).

No, I haven't had a chance to look again yet, though it is on my TODO
list. I'm not sure what I can do though, as it's pretty clear you're
suffering a problem that the rest of us aren't.

It might help if you can provide the config.log files from your
pgAdmin and wxWidgets builds, so at least we can see how Gentoo built
everything.

My only other suggestion would be to use
Fedora/CentOS/RHEL/Debian/Ubuntu for which you can get pre-built
packages that we know work. Portage does create a lot of possible
variability in the build which may mean there are unusual builds of
just about any library we use that we may never have seen elsewhere.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Dave Page-7 wrote
>>> <http://postgresql.1045698.n5.nabble.com/file/n5756202/backtrace>
>>
>> Any update on this? It looks like I get the exact same backtrace every
>> time,
>> in slightly different circumstances. Sometimes even after opening and
>> closing a blank query window (from the toolbar sql button).
> 
> No, I haven't had a chance to look again yet, though it is on my TODO
> list. I'm not sure what I can do though, as it's pretty clear you're
> suffering a problem that the rest of us aren't.

Well, I'd think the backtrace should provide a clear indication of where the
problem is.


> It might help if you can provide the config.log files from your
> pgAdmin and wxWidgets builds, so at least we can see how Gentoo built
> everything.

Ok, I'm attaching the config.log files:
pgadmin3_config.log
<http://postgresql.1045698.n5.nabble.com/file/n5758129/pgadmin3_config.log>  
wxgtk_config.log
<http://postgresql.1045698.n5.nabble.com/file/n5758129/wxgtk_config.log>  


> My only other suggestion would be to use
> Fedora/CentOS/RHEL/Debian/Ubuntu for which you can get pre-built
> packages that we know work.

Haha




--
View this message in context: http://postgresql.1045698.n5.nabble.com/pgAdmin-crashes-on-DDL-tp5754991p5758129.html
Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com.

aditsu wrote
> 
> Dave Page-7 wrote
>> No, I haven't had a chance to look again yet, though it is on my TODO
>> list. I'm not sure what I can do though, as it's pretty clear you're
>> suffering a problem that the rest of us aren't.
> Well, I'd think the backtrace should provide a clear indication of where
> the problem is.

Oh well, if you want something done, you have to do it yourself.

--- frmQuery.cpp    2012-11-08 23:22:01.000000000 +0800
+++ frmQuery1.cpp    2013-06-07 15:39:14.453599679 +0800
@@ -1451,7 +1451,7 @@    if (allowUpdateModelSize)    {
-        canSaveGQB = controller->getView()->canSaveAsImage();
+        canSaveGQB = controller->getView() != NULL &&
controller->getView()->canSaveAsImage();    }    toolBar->EnableTool(MNU_UNDO, canUndo);

Solves world hunger, Middle East conflict and the constant pgadmin crashes.
(or at least one of the above)



--
View this message in context: http://postgresql.1045698.n5.nabble.com/pgAdmin-crashes-on-DDL-tp5754991p5758265.html
Sent from the PostgreSQL - pgadmin support mailing list archive at Nabble.com.

On Fri, Jun 7, 2013 at 9:45 AM, aditsu <aditsu@yahoo.com> wrote:
> aditsu wrote
>>
>> Dave Page-7 wrote
>>> No, I haven't had a chance to look again yet, though it is on my TODO
>>> list. I'm not sure what I can do though, as it's pretty clear you're
>>> suffering a problem that the rest of us aren't.
>> Well, I'd think the backtrace should provide a clear indication of where
>> the problem is.
>
> Oh well, if you want something done, you have to do it yourself.

Sometimes, unfortunately, that is the case with Open Source :-(.

Thanks, patch applied to the 1.16 and master branches.


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company