Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#1184 closed defect (fixed)

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

Reported by: met Owned by: martinl
Priority: critical Milestone: 6.4.2
Component: wxGUI Version: 6.4.0
Keywords: wingrass, d.vect Cc: grass-dev@…
CPU: Unspecified Platform: MSWindows XP

Description (last modified by hamish)

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'

Change History (13)

comment:1 Changed 9 years ago by hamish

Component: DisplaywxGUI
Keywords: wingrass added; display=attr removed
Priority: blockercritical

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

comment:2 in reply to:  1 Changed 9 years ago by 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

comment:3 Changed 8 years ago by met

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

comment:4 in reply to:  3 Changed 8 years ago by hamish

Milestone: 6.4.16.4.2

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

comment:5 Changed 8 years ago by hamish

Description: modified (diff)

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

comment:6 in reply to:  5 Changed 8 years ago by hamish

Keywords: d.vect added

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

comment:7 in reply to:  5 ; Changed 8 years ago by 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

comment:8 in reply to:  7 Changed 8 years ago by 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).

comment:9 Changed 8 years ago by martinl

Cc: grass-dev@… added
Owner: changed from grass-dev@… to martinl
Status: newassigned

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.

comment:10 in reply to:  9 Changed 8 years ago by 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.

comment:11 in reply to:  9 Changed 8 years ago by 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

comment:12 Changed 8 years ago by martinl

Resolution: fixed
Status: assignedclosed

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

comment:13 Changed 8 years ago by hamish

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

well spotted!

Hamish

Note: See TracTickets for help on using tickets.