"d.vect display=attr" imply grass open process but doesn't close them.

[met]

Using version 6.4.0 or 6.4.0 RC7 the defect shows up, instead of RC6 in which not, operative system Windows XP professional.

When you are using a PAN or ZOOM command, or simply adding a layers, (looking from windows taskmanager)map display start a "cmd.exe" process. This process disappear after few seconds but if the option display=attr is active, doesn't shut down properly:

-at every zoom/pan on map the Map display open a new cmd.exe process that will never be closed.

-this trend (adding process) go ahead until the Grass doesn't work and stop following comand .

-even closing Grass before or after its block those process don't disappear.

-the only way in which a user could shut down those process is the windows task manager.

example: d.vect map=reteF display=shape,attr

type=point,area,centroid attrcol='id'

[hamish]

Hi,

I can reproduce this using a brand new nightly build of wingrass 6.4 and 6.5 with the wxGUI and spearfish dataset.

• ctrl-alt-del to open the process monitor, click the Image name column in the Processes tab to sort by process name.

• in the wxgui layer manager add the roads vector map, then tick disp=attr and set attrcol to 'label' in the d.vect Labels tab.

• then zoom, pan around and watch the number of cmd.exe and dbf.exe processes grow. exiting grass does not kill them, and they are not visible on the task bar.

in 6.4 it just leaves orphaned processes behind, in 6.5svn it is worse, using d.vect attrcol= locks the entire GUI and Windows XP taskbar until you type exit in the MSys rxvt terminal (which is still fully responsive).

cleanup: killing the dbf.exe processes makes the cmd.exe ones go away too.

Hamish

[hellik]

Replying to hamish:

Hi,

I can reproduce this using a brand new nightly build of wingrass 6.4 and 6.5 with the wxGUI and spearfish dataset.

• ctrl-alt-del to open the process monitor, click the Image name column in the Processes tab to sort by process name.

• in the wxgui layer manager add the roads vector map, then tick disp=attr and set attrcol to 'label' in the d.vect Labels tab.

• then zoom, pan around and watch the number of cmd.exe and dbf.exe processes grow. exiting grass does not kill them, and they are not visible on the task bar.

in 6.4 it just leaves orphaned processes behind, in 6.5svn it is worse, using d.vect attrcol= locks the entire GUI and Windows XP taskbar until you type exit in the MSys rxvt terminal (which is still fully responsive).

cleanup: killing the dbf.exe processes makes the cmd.exe ones go away too.

Hamish

still there in WinGRASS-6.4.SVN-r45671-1-Setup.exe

Helmut

[met]

is this problem fixed in the new version? or the last 6.4.1 still has this bug?

[hamish]

Replying to met:

is this problem fixed in the new version? or the last 6.4.1 still has this bug?

I haven't tested 6.4.1 WinGrass so can't say for sure, but AFAIK the bug remains. -> Do you see it?

Hamish

[hamish]

dbf.exes still piling up in the process manager with latest 6.4.svn native wingrass nightly build. what's more if you select disp=attr attrcol=label the wxGUI locks up with an endless hourglass. the "this program is not responding" dialog helps you kill it and get back to the working msys prompt where you can restart it with g.gui. (but the dbf.exes remain running)

Hamish

[hamish]

Replying to hamish:

what's more if you select disp=attr attrcol=label the wxGUI locks up with an endless hourglass. the "this program is not responding" dialog helps you kill it and get back to the working msys prompt where you can restart it with g.gui. (but the dbf.exes remain running)

see also #1331

Hamish

[mmetz]

Replying to hamish:

dbf.exes still piling up in the process manager with latest 6.4.svn native wingrass nightly build. what's more if you select disp=attr attrcol=label the wxGUI locks up with an endless hourglass. the "this program is not responding" dialog helps you kill it and get back to the working msys prompt where you can restart it with g.gui. (but the dbf.exes remain running)

Non-display commands that do very similar things to d.vect disp=shape,attr attrcol=col run just fine through the wxGUI, finish successfully and do not leave stray dbf.exe processes behind.

Display commands are run through gcmd.RunCommand() which in turn calls grass.script.core.start_command() which in turn calls grass.script.core.Popen(). Non-display commands invoked through wxGUI are run through gcmd.Popen().

The endless hourglass goes away if ps.communicate() is replaced with ps.wait() in gcmd.RunCommand(), d.vect finishes successfully and labels are drawn. But it leaves a stray dbf.exe process behind.

Interestingly, the grass.script.core.*_command() functions and thus grass.script.core.Popen() are successfully used very often by the wxGUI, e.g. every time a column option field is populated. That does not leave stray dbf.exe processes behind.

It seems that gcmd.RunCommand() is doing something that prevents dbf.exe from finishing, or prevents G_wait() from properly waiting for dbf.exe to finish, whereas gcmd.Popen() runs fine.

This affects all branches.

Markus M

[martinl]

Replying to mmetz:

Display commands are run through gcmd.RunCommand() which in turn calls grass.script.core.start_command() which in turn calls grass.script.core.Popen(). Non-display commands invoked through wxGUI are run through gcmd.Popen().

it's not a question of display or non-display commands. gcmd.!RunCommand() is used when the GUI waits for command termination. In opposite gcmd.Popen() is used through gcmd.CommandThread which is basically reserved for the commands running on the background (eg. those launched from wxGUI command prompt).

[martinl]

The real problem was that db_close_database_shutdown_driver() hasn't been called in display_attr() when there was at least one feature to read. Hopefully fixed in r49171 (devbr6). Testing highly welcomed.

[martinl]

Replying to martinl:

The real problem was that db_close_database_shutdown_driver() hasn't been called in display_attr() when there was at least one feature to read. Hopefully fixed in r49171 (devbr6). Testing highly welcomed.

Backported to relbr64 in r49173.

[mmetz]

Replying to martinl:

The real problem was that db_close_database_shutdown_driver() hasn't been called in display_attr() when there was at least one feature to read. Hopefully fixed in r49171 (devbr6). Testing highly welcomed.

Nice spotting! That was it. Ported to trunk in r49172.

Markus M

[martinl]

Tested with last winGRASS 6.4 build. Seems to work. Closing.

[hamish]

tested with WinGRASS-6.4.SVN-r49173-1-Setup.exe, confirmed fixed.

well spotted!

Hamish