Debugger hung on dummy function

CREATE FUNCTION onelinefunc() RETURNS void AS $$ begin null; end; $$
LANGUAGE plpgsql;

When I choose Debugging->debug on that function, pgAdmin hangs,
consuming 100% of CPU. This is on latest svn version of pgAdmin, running
on Debian linux with wxwidgets 2.8.10.

The same doesn't happen if the function takes an argument:

CREATE FUNCTION onelinefunc(i integer) RETURNS void AS $$ begin null;
end; $$ LANGUAGE plpgsql;

The same thing happens even if the function has more interesting
contents, when I step to the end of the function.

Attaching with gdb to the hung pgadmin process, I got a backtrace like this:

#0 0xb698ae3d in IA__g_type_check_instance_cast
(type_instance=0x8b12418, iface_type=145581776)
at
/build/buildd-glib2.0_2.20.0-2-i386-rcJiVy/glib2.0-2.20.0/gobject/gtype.c:372
#1 0xb775284c in wxWindow::DoSetSize (this=0x91d97d0, x=0, y=0,
width=25, height=18, sizeFlags=<value optimized out>)
at ../src/gtk/window.cpp:2754
#2 0xb7a06cdd in wxGrid::CalcWindowSizes (this=0x91d5ff0) at
../include/wx/window.h:225
#3 0xb7a12c1e in wxGrid::CalcDimensions (this=0x91d5ff0) at
../src/generic/grid.cpp:4653
#4 0xb7a12fc5 in wxGrid::OnSize (this=0x3) at ../src/generic/grid.cpp:6912
#5 0xb7475371 in wxAppConsole::HandleEvent (this=0x8a6d7f8,
handler=0x91d5ff0, func=&virtual table offset 918020,
event=(at)0xbfb54660) at ../src/common/appbase.cpp:320
#6 0xb7530dca in wxEvtHandler::ProcessEventIfMatches
(entry=(at)0xb7a758d8, handler=0x91d5ff0, event=(at)0xbfb54660)
at ../src/common/event.cpp:1225
#7 0xb75324c4 in wxEventHashTable::HandleEvent (this=0xb7a758a8,
event=(at)0xbfb54660, self=0x91d5ff0)
at ../src/common/event.cpp:898
#8 0xb7532616 in wxEvtHandler::ProcessEvent (this=0x91d5ff0,
event=(at)0xbfb54660) at ../src/common/event.cpp:1287
#9 0xb753259c in wxEvtHandler::ProcessEvent (this=0x91d6338,
event=(at)0xbfb54660) at ../src/common/event.cpp:1294
#10 0xb78a6b03 in wxScrollHelperEvtHandler::ProcessEvent
(this=0x91d6338, event=(at)0xbfb54660)
at ../src/generic/scrlwing.cpp:211
#11 0xb774a2fb in wxWindow::GTKProcessEvent (this=0x91d5ff0,
event=(at)0xbfb54660) at ../src/gtk/window.cpp:1399
#12 0xb77507f7 in gtk_window_size_callback (alloc=0xbfb54a0c,
win=0x91d5ff0) at ../src/gtk/window.cpp:2149
#13 0xb69798dc in IA__g_cclosure_marshal_VOID__BOXED (closure=0x91d72a8,
return_value=0x0, n_param_values=2,
param_values=0x91a2850, invocation_hint=0xbfb5484c,
marshal_data=0xb77506d0)
at
/build/buildd-glib2.0_2.20.0-2-i386-rcJiVy/glib2.0-2.20.0/gobject/gmarshal.c:566
#14 0xb696cb6b in IA__g_closure_invoke (closure=0x91d72a8,
return_value=0x0, n_param_values=2, param_values=0x91a2850,
invocation_hint=0xbfb5484c) at
/build/buildd-glib2.0_2.20.0-2-i386-rcJiVy/glib2.0-2.20.0/gobject/gclosure.c:767
#15 0xb6980ccf in signal_emit_unlocked_R (node=0x8a8e5c0, detail=0,
instance=0x908e008, emission_return=0x0,
instance_and_params=0x91a2850) at
/build/buildd-glib2.0_2.20.0-2-i386-rcJiVy/glib2.0-2.20.0/gobject/gsignal.c:3244
#16 0xb6982159 in IA__g_signal_emit_valist (instance=0x908e008,
signal_id=16, detail=0, var_args=0xbfb549f0 "\200�\b\t\001")
at
/build/buildd-glib2.0_2.20.0-2-i386-rcJiVy/glib2.0-2.20.0/gobject/gsignal.c:2977
#17 0xb69825b6 in IA__g_signal_emit (instance=0x908e008, signal_id=16,
detail=0)
...

I don't understand all the things that are going on, but this looks like
some kind of a infinite resizing loop. Dunno what useful functionality
this disables as a side-effect, but this patch fixes it for me:

--- debugger/dlgDirectDbg.cpp (revision 7789)
+++ debugger/dlgDirectDbg.cpp (working copy)
@@ -295,7 +295,7 @@
font.SetStyle( wxFONTSTYLE_ITALIC );
grdParams->SetCellFont( 0, COL_NAME, font );

- grdParams->AutoSizeColumns();
+ //grdParams->AutoSizeColumns();
activateDebugger();
}
else

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Hi Heikki

On Fri, Apr 3, 2009 at 4:43 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> CREATE FUNCTION onelinefunc() RETURNS void AS $$ begin null; end; $$
> LANGUAGE plpgsql;

Debugging that won't work terribly well anyway, as the plugin will
just skip the entire function iirc. For slightly saner testing, try
replacing null; with raise notice 'foo';. I'm not inclined to spend
the time fixing the first case at the moment as it seems unlikely to
ever cause anyone problems.

> When I choose Debugging->debug on that function, pgAdmin hangs, consuming
> 100% of CPU. This is on latest svn version of pgAdmin, running on Debian
> linux with wxwidgets 2.8.10.
>
> The same doesn't happen if the function takes an argument:
>
> CREATE FUNCTION onelinefunc(i integer) RETURNS void AS $$ begin null; end;
> $$ LANGUAGE plpgsql;
>
> The same thing happens even if the function has more interesting contents,
> when I step to the end of the function.

Hmm, that's pretty weird. I can't reproduce it here, however I'm on
CentOS 5.2 x86_64 which currently only has wxWidgets 2.8.9. The line
you've commented out simply sizes the grid so that the 'No arguments
required' text fits in the first column. Does the following change
work for you?

--- debugger/dlgDirectDbg.cpp (revision 7789)
+++ debugger/dlgDirectDbg.cpp (working copy)
@@ -295,7 +295,7 @@
font.SetStyle( wxFONTSTYLE_ITALIC );
grdParams->SetCellFont( 0, COL_NAME, font );

- grdParams->AutoSizeColumns();
+ grdParams->SetColSize( COL_NAME, 200 );
activateDebugger();
}
else

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

Dave Page wrote:
> Hi Heikki
>
> On Fri, Apr 3, 2009 at 4:43 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> CREATE FUNCTION onelinefunc() RETURNS void AS $$ begin null; end; $$
>> LANGUAGE plpgsql;
>
> Debugging that won't work terribly well anyway, as the plugin will
> just skip the entire function iirc. For slightly saner testing, try
> replacing null; with raise notice 'foo';. I'm not inclined to spend
> the time fixing the first case at the moment as it seems unlikely to
> ever cause anyone problems.

It's reproducible with any other function too, by stepping to the end of
the function. Which suggests that the problem occurs when the dialog is
displayed for the 2nd time.

>> When I choose Debugging->debug on that function, pgAdmin hangs, consuming
>> 100% of CPU. This is on latest svn version of pgAdmin, running on Debian
>> linux with wxwidgets 2.8.10.
>>
>> The same doesn't happen if the function takes an argument:
>>
>> CREATE FUNCTION onelinefunc(i integer) RETURNS void AS $$ begin null; end;
>> $$ LANGUAGE plpgsql;
>>
>> The same thing happens even if the function has more interesting contents,
>> when I step to the end of the function.
>
> Hmm, that's pretty weird. I can't reproduce it here, however I'm on
> CentOS 5.2 x86_64 which currently only has wxWidgets 2.8.9.

Probably some gtk/wxwidgets glitch. The backtrace suggests that theme
might make a difference too..

> The line
> you've commented out simply sizes the grid so that the 'No arguments
> required' text fits in the first column. Does the following change
> work for you?
>
> --- debugger/dlgDirectDbg.cpp (revision 7789)
> +++ debugger/dlgDirectDbg.cpp (working copy)
> @@ -295,7 +295,7 @@
> font.SetStyle( wxFONTSTYLE_ITALIC );
> grdParams->SetCellFont( 0, COL_NAME, font );
>
> - grdParams->AutoSizeColumns();
> + grdParams->SetColSize( COL_NAME, 200 );
> activateDebugger();
> }
> else

Yes! That fixes it.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas wrote:
> Dave Page wrote:
>> Hi Heikki
>>
>> On Fri, Apr 3, 2009 at 4:43 PM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> CREATE FUNCTION onelinefunc() RETURNS void AS $$ begin null; end; $$
>>> LANGUAGE plpgsql;
>>
>> Debugging that won't work terribly well anyway, as the plugin will
>> just skip the entire function iirc. For slightly saner testing, try
>> replacing null; with raise notice 'foo';. I'm not inclined to spend
>> the time fixing the first case at the moment as it seems unlikely to
>> ever cause anyone problems.
>
> It's reproducible with any other function too, by stepping to the end of
> the function.

Correction: not with *any* other function, but with any function with no
arguments.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Mon, Apr 6, 2009 at 9:20 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

> It's reproducible with any other function too, by stepping to the end of the
> function. Which suggests that the problem occurs when the dialog is
> displayed for the 2nd time.

What, the infinite loop happens the second time, or it ignores the
function entirely as I saw with the empty function? I had no problems
debugging a function with just a raise notice in the body multiple
times in a row.

>> Hmm, that's pretty weird. I can't reproduce it here, however I'm on
>> CentOS 5.2 x86_64 which currently only has wxWidgets 2.8.9.
>
> Probably some gtk/wxwidgets glitch. The backtrace suggests that theme might
> make a difference too..

Yeah, we've seen some themes cause crashes before :-(

>> The line
>> you've commented out simply sizes the grid so that the 'No arguments
>> required' text fits in the first column. Does the following change
>> work for you?
...
> Yes! That fixes it.
>

Great - I'll commit that then.

Thanks!

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

Dave Page wrote:
> On Mon, Apr 6, 2009 at 9:20 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
>> It's reproducible with any other function too, by stepping to the end of the
>> function. Which suggests that the problem occurs when the dialog is
>> displayed for the 2nd time.
>
> What, the infinite loop happens the second time, or it ignores the
> function entirely as I saw with the empty function? I had no problems
> debugging a function with just a raise notice in the body multiple
> times in a row.

When I choose "Debug" from the popup menu on the tree, on a functioon
with no args but with real content that the debugger can stop on, the
function execution is started and the debugger stops on the first line,
as it should. When I step through the function, all the way to the end,
it gets hung in the infinite loop.

>>> The line
>>> you've commented out simply sizes the grid so that the 'No arguments
>>> required' text fits in the first column. Does the following change
>>> work for you?
> ...
>> Yes! That fixes it.
>
> Great - I'll commit that then.

Thanks!

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Tue, Apr 7, 2009 at 8:45 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> When I choose "Debug" from the popup menu on the tree, on a functioon with
> no args but with real content that the debugger can stop on, the function
> execution is started and the debugger stops on the first line, as it should.
> When I step through the function, all the way to the end, it gets hung in
> the infinite loop.

Right, gotcha - but that's fixed by the patch I assume?

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

Dave Page wrote:
> On Tue, Apr 7, 2009 at 8:45 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> When I choose "Debug" from the popup menu on the tree, on a functioon with
>> no args but with real content that the debugger can stop on, the function
>> execution is started and the debugger stops on the first line, as it should.
>> When I step through the function, all the way to the end, it gets hung in
>> the infinite loop.
>
> Right, gotcha - but that's fixed by the patch I assume?

Yes.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Greenplum stores the number of rows per segmentDatabase (actually the max of any of the segDBs) in pg_class.reltuples, not the total number of tuples.

This causes the stats to display wrong values, and causes pgAdmin to warn that Analyze is needed when it is not.

This simple patch multiplies the reltuples x gp_segments, so that we get a better value.

Of course, it only does this for Greenplum connections.

Thanks, applied.

On Wed, Apr 15, 2009 at 3:24 AM, Chuck McDevitt <cmcdevitt(at)greenplum(dot)com> wrote:
> Greenplum stores the number of rows per segmentDatabase (actually the max of any of the segDBs) in pg_class.reltuples, not the total number of tuples.
>
> This causes the stats to display wrong values, and causes pgAdmin to warn that Analyze is needed when it is not.
>
> This simple patch multiplies the reltuples x gp_segments, so that we get a better value.
>
> Of course, it only does this for Greenplum connections.
>
>
>

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