[GRASS-dev] Re: [grass-code I][354] v.digit freeze after "Display attributes" --> "New feature"

On Wed, Apr 25, 2007 at 07:05:30PM +0200, grass-codei@wald.intevation.org wrote:
...

>Comment By: Maciej Sieczka (msieczka)
Date: 2007-04-25 19:05

Message:
Hi

There've been numerous issues with v.digit until recent fixes by
Glynn et all in GRASS 6.3 CVS. I've been bitten by your problem
too. In 6.3 CVS v.digit is still not perfectly stable, but definitely
more reliable than in GRASS 6.2.1.

Sadly, there are low chances the new code will be backported to
the planned 6.2.2 release.

Glynn,

how complicated/risky do you see the backport of v.digit/tcl?

Markus

> >Comment By: Maciej Sieczka (msieczka)
> There've been numerous issues with v.digit until recent fixes by
> Glynn et all in GRASS 6.3 CVS. I've been bitten by your problem
> too. In 6.3 CVS v.digit is still not perfectly stable, but
> definitely more reliable than in GRASS 6.2.1.

I accept that others have had problems with it, but for me the old 6.2
v.digit has always worked very well.

Can anyone point to **specific bug reports that cause a crash or data
loss, and are fixed in the 6.3-CVS version**?

https://intevation.de/rt/webrt?q_status=open&q_queue=grass&q_subject=v.digit

Markus:

> Sadly, there are low chances the new code will be backported to
> the planned 6.2.2 release.

..

how complicated/risky do you see the backport of v.digit/tcl?

related: how bad really are the problems with 6.2.1's v.digit? What are
they specifically? Do they warrant the risk of releasing lightly tested
code as a replacement for a core module?

Hamish

Hamish wrote:

Comment By: Maciej Sieczka (msieczka)

There've been numerous issues with v.digit until recent fixes by
Glynn et all in GRASS 6.3 CVS. I've been bitten by your problem
too. In 6.3 CVS v.digit is still not perfectly stable, but
definitely more reliable than in GRASS 6.2.1.

I accept that others have had problems with it, but for me the old 6.2
v.digit has always worked very well.

Can anyone point to **specific bug reports that cause a crash or data
loss, and are fixed in the 6.3-CVS version**?

https://intevation.de/rt/webrt?q_status=open&q_queue=grass&q_subject=v.digit

Issues resolved in 6.3 CVS but present in 6.2, AFAIK, [1],[2],[3]:

Present in both in 6.2 and 6.3 are, AFAIK, [4],[5].

related: how bad really are the problems with 6.2.1's v.digit? What are
they specifically?

1. One can't use encodings besides ISO-8859-1 in data tables [1].
2. One can't digitize areas [3].

[1]https://intevation.de/rt/webrt?serial_num=4110&display=History
[2]https://intevation.de/rt/webrt?serial_num=4454&display=History
[3]http://grass.itc.it/pipermail/grassuser/2007-February/038176.html
[4]https://intevation.de/rt/webrt?serial_num=5127&display=History
[5]https://intevation.de/rt/webrt?serial_num=2962&display=History

The issue [3] was never reported in the tracker but it's present in 6.2
and fixed in 6.3, AFAICT.

I might have missed something!

Maciek

Markus Neteler wrote:

> >Comment By: Maciej Sieczka (msieczka)
> Date: 2007-04-25 19:05
>
> Message:
> Hi
>

> There've been numerous issues with v.digit until recent fixes by
> Glynn et all in GRASS 6.3 CVS. I've been bitten by your problem
> too. In 6.3 CVS v.digit is still not perfectly stable, but definitely
> more reliable than in GRASS 6.2.1.

> Sadly, there are low chances the new code will be backported to
> the planned 6.2.2 release.

how complicated/risky do you see the backport of v.digit/tcl?

I suppose it would have to be at least "medium risk" due to the total
amount of change; try "diff -ru" on the 6.2.1/6.3 versions.

OTOH, it's now completely detached from the graphics libraries. It
uses lib/display, but only for the stuff in cnversions.c, which is
completely isolated from the rest of lib/{display,raster} (that file
could even be moved into libgis).

Also, it no longer depends upon lib/form; it has a private version of
the form code. As v.digit is already a C+Tcl/Tk hybrid, there was no
reason to use a seperate etc/form process.

IOW, backporting v.digit shouldn't require any library changes to be
backported; that would have made it "extreme risk".

--
Glynn Clements <glynn@gclements.plus.com>

Maciej Sieczka wrote:

I might have missed something!

Now, regarding this very bug report, I confirm it exists in 6.2 CVS.
Such locks when editing attributes in v.digit happen. Fixed in 6.3.

This also reminds me of an issue with corrupted "d.what.vect -e" tcl/tk
windows [1] - fixed in 6.3, but still present in 6.2.

[1]https://intevation.de/rt/webrt?serial_num=4429

Hamish wrote:
> Can anyone point to **specific bug reports that cause a crash or
> data loss, and are fixed in the 6.3-CVS version**?
>
> https://intevation.de/rt/webrt?q_status=open&q_queue=grass&q_subject=v.digit

Maciej wrote:

Issues resolved in 6.3 CVS but present in 6.2, AFAIK, [1],[2],[3]:

[1]https://intevation.de/rt/webrt?serial_num=4110
1. One can't use encodings besides ISO-8859-1 in data tables [1].

Certainly annoying for non-English folks, but this is a feature enhancement
- not a critical bug - so not a backport candidate.
Does the same issue exist for "d.what.vect -e"?

[2]https://intevation.de/rt/webrt?serial_num=4454

"v.digit: 'Digitize new point' tool is activated by default"
"It shouldn't. None other tool should either."

This is more of a wish/annoyance than a bug, certainly not a serious bug.
Not a backport candidate.

[3]http://grass.itc.it/pipermail/grassuser/2007-February/038176.html
2. One can't digitize areas [3].
The issue [3] was never reported in the tracker but it's present in
6.2 and fixed in 6.3, AFAICT.

Ok, this one is a backport candidate if we can isolate it & fix it.
But I can't reproduce it. I tried:

#spearfish60 + DBF driver
g.region rast=roads

v.digit -n new_map1
digitize 5 new boundaries
use move vertex tool to close the 5 boxes
choose add centroid tool
for Mode select "No category"
put a centroid in each box
remove all centroids with the delete feature tool
put a centroid in each box
remove all centroids with the delete feature tool
change Mode to "Manual Entry" (1)
put a centroid in each box
remove all centroids with the delete feature tool
change Mode to "Next not used"
put a centroid in each box
remove all centroids with the delete feature tool
remove all boundaries with the delete feature tool
add a bunch of centroids into empty space
remove them
add them again
remove them again

all works as expected. shrug. maybe need to add 100+ centroids? (hours of
work lost; new user never uses grass again)

Jarek says in the OP "This is my first digitizing task", so maybe the
problem is related to a default DB not yet being chosen??? trying in
a new mapset without a "VAR" file, I still can't reproduce it.

I see in a new post you say it happens when *editing attributes*.
I didn't try that as it wasn't mentioned in the parent post. I'll
try that now & report back in a followup post.

Present in both in 6.2 and 6.3 are, AFAIK, [4],[5].

Thus not reasons to backport the full 6.3 version; but while we are here,
a quick look anyway:

[4]https://intevation.de/rt/webrt?serial_num=5127

Was this mentioned on the mailing list in just the last day or two?

[5]https://intevation.de/rt/webrt?serial_num=2962

[v.digit changes the WIND file instead of setting up a WIND_OVERRIDE
setting or similar] Also might not use "g.region -a" alignment during
zooming/panning so underlayed raster at coarse res may appear to shift
about under the vector line leading to inexact digitization.
from the bug report:
"Hamish: This bug should be kept open as the v.digit code should a) not
be changing the WIND file (if that's possible with mixed Tcl + C) and
b) use "g.region -a" like code when zooming so as not to corrupt
background raster resampling."
Note that it now restores the startup region upon clean exit.

So it boils down to issue [3] "can't digitize centroids".
But this works fine for me in 6.2.1, so .....?

what's more, v.digit in GRASS 6.3 segfaults on startup for me currently.
Not an encouraging sign for the 6.3 version being mature enough to
backport.

g.region rast=roads
v.digit -n test_dig_area
New empty map created.
###wish gui flashes up then disappears###
Segmentation fault

gdb:
G63> gdb `which v.digit`
..
(gdb) run -n test_map1
Starting program: /usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/bin/v.digit -n test_map1
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 9024)]
New empty map created.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9024)]
0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1

(gdb) where
#0 0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1
#1 0x406e5a77 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
#2 0x406e5967 in Tcl_EvalTokens () from /usr/lib/libtcl8.3.so.1
#3 0x406e5ad8 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
#4 0x406e5ead in Tcl_Eval () from /usr/lib/libtcl8.3.so.1
#5 0x0805074f in get_window (t=0xbfffdddc, b=0xbfffddd8, l=0xbfffddd4, r=0xbfffddd0) at driver.c:58
#6 0x08050811 in setup () at driver.c:73
#7 0x0805091c in driver_open () at driver.c:101
#8 0x0804f9cd in tool_centre () at centre.c:50
#9 0x0804e9b7 in c_tool_centre (cdata=0x0, interp=0x8069248, argc=1, argv=0xbfffdf40) at c_face.c:159
#10 0x406ad7ab in TclInvokeStringCommand () from /usr/lib/libtcl8.3.so.1
#11 0x406e529c in TclExpandTokenArray () from /usr/lib/libtcl8.3.so.1
#12 0x406e5b3d in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
#13 0x406dca0e in Tcl_EvalFile () from /usr/lib/libtcl8.3.so.1
#14 0x40609774 in Tk_MainEx () from /usr/lib/libtk8.3.so.1
#15 0x08055102 in main (argc=3, argv=0xbffff6b4) at main.c:171

same thing starting with:
G63> GRASS_WISH=wish8.4 v.digit -n test_map2

[as Glynn stated in an earlier thread, debugging C+Tcl mixed code is a
real pain]

We seem to have agreed (yes?) that backporting the new EPSG code search
tool in violation of the "fixes for serious bugs only" rule is ok, as
it is a non-critical component and the new version is really really nice.
So I hope I'm not seeming to be unfair in playing conservative with
v.digit while at the same time pushing for the new EPSG picker.

regards,
Hamish

Maciej Sieczka wrote:

> I might have missed something!

Now, regarding this very bug report, I confirm it exists in 6.2 CVS.
Such locks when editing attributes in v.digit happen. Fixed in 6.3.

Hey, I was just able to reproduce the bug!
(created new table in the settings menu with a varchar(15) column)

More tries to get it to lock up: (all unsucessful)

- create a new table from the v.digit settings menu
    [Create new table] (only cat)
- digitize boundary box [No category]
- move vertex to close boundary (turns green)
- switch to digitize centroid tool
- create a centroid (edit form pops up; nothing to edit)
- click submit

at which point in red letters at the bottom of the edit form is this:
Cannot update table:
DBMI-DBF driver error:
SQL parser error in statement:
update testmap3 set where cat = 1
Error in db_execute_immediate()

and in the terminal:
G63> v.digit -n testmap3
New empty map created.
### [before create new table]
cat integer
### [after create new table]
D0/0: Name = cat
D0/0: Name = _grass_internal_database_encoding
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
DBMI-DBF driver error:
SQL parser error in statement:
update testmap3 set where cat = 1
Error in db_execute_immediate()

WARNING: Cannot update table

######
v.digit is alive, I can hit the exit/door icon to leave and close the map.

trying again, new map, this time create a new table with a second int
column. Everything works (still get above debug messages).

try again, new map, this time add a new varchar() column. No problems.
try again, new map, this time add new int and varchar() columns.
   No problems.

... and now I can't reproduce it at all no matter what I try ...
shrug.

the driver and encoding errors seem like a good place to start looking for a
fix. I'd rather fix a bug in dead-end code than hope the lightly tested new
version is less buggy.

This also reminds me of an issue with corrupted "d.what.vect -e"
tcl/tk windows [1] - fixed in 6.3, but still present in 6.2.

[1]https://intevation.de/rt/webrt?serial_num=4429

I can't reproduce this in 6.2.1, but:
G6.2.1:spearfish60 > g.copy v=bugsites,test_bugs
COPY [bugsites@PERMANENT] to current mapset as [test_bugs]
WARNING: Default driver / database set to:
         driver: dbf
         database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/

G621> d.vect test_bugs

G621> d.what.vect -e
[encoding is left as the default utf-8]
every time I hit submit, I get the following printed in the terminal, but no
other ill effects.

D0/0: Name = cat
D0/0: Name = str1
D0/0: Name = _grass_internal_database_encoding
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to

the extra debug messages are from lib/form/form.c line 180
  G_debug ( 0, "Name = %s", Cols[i].name );

"Could not set Tcl system encoding to <blank>" is a bit suspicious.

interesting, selecting different encodings show it looping through the
encode types, ie ascii is 2nd on list, iso8859-1 is 3rd. utf-8 doesn't
get printed, the other three do, in order:

D0/0: Name = cat
D0/0: Name = str1
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to ascii
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to

D0/0: Name = cat
D0/0: Name = str1
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to iso8859-1
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to

D0/0: Name = cat
D0/0: Name = str1
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to
D0/0: Name = _grass_internal_database_encoding
Could not set Tcl system encoding to koi8-r

still not convinced that backporting the new v.digit is a good idea,
(also a complete non-issue until the 6.3 v.digit opens without
seg-faulting)

Hamish

Hamish wrote:

Hamish wrote:

Can anyone point to **specific bug reports that cause a crash or
data loss, and are fixed in the 6.3-CVS version**?

https://intevation.de/rt/webrt?q_status=open&q_queue=grass&q_subject=v.digit

Maciej wrote:

Issues resolved in 6.3 CVS but present in 6.2, AFAIK, [1],[2],[3]:

[1]https://intevation.de/rt/webrt?serial_num=4110
1. One can't use encodings besides ISO-8859-1 in data tables [1].

Certainly annoying for non-English folks, but this is a feature enhancement

No. It's a bug. v.digit provides UTF-8 encoding but it does not work -
when I enter non-English characters, I get garbage symbols in v.digit
attribute editor window. However, the national characters *are* stored
in the table in spite of this - eg. v.db.select in terminal properly
returns the national chars which I entered in v.digit; only that I
can't see in v.digit what I enter :).

- not a critical bug - so not a backport candidate.
Does the same issue exist for "d.what.vect -e"?

Yes.

[2]https://intevation.de/rt/webrt?serial_num=4454

"v.digit: 'Digitize new point' tool is activated by default"
"It shouldn't. None other tool should either."

This is more of a wish/annoyance than a bug, certainly not a serious bug.
Not a backport candidate.

OK.

[3]http://grass.itc.it/pipermail/grassuser/2007-February/038176.html
2. One can't digitize areas [3].
The issue [3] was never reported in the tracker but it's present in
6.2 and fixed in 6.3, AFAICT.

Ok, this one is a backport candidate if we can isolate it & fix it.
But I can't reproduce it. I tried:

You are correct. I can't reproduce it anymore myself. Great. Must have
been a fix commited. The last time I tried (and before), ie. until Feb
2 2007 the bug was present in 6.2 CVS.

On a related note - I have thought that bug
http://intevation.de/rt/webrt?serial_num=4429 was fixed only for 6.3
CVS. After playing around with d.what.vect -e I can see now it is OK in
6.2 CVS too.

[4]https://intevation.de/rt/webrt?serial_num=5127

Was this mentioned on the mailing list in just the last day or two?

Yes, and I provided a link to this bug report in the thread.

[5]https://intevation.de/rt/webrt?serial_num=2962

[v.digit changes the WIND file instead of setting up a WIND_OVERRIDE
setting or similar] Also might not use "g.region -a" alignment during
zooming/panning so underlayed raster at coarse res may appear to shift
about under the vector line leading to inexact digitization.
from the bug report:
"Hamish: This bug should be kept open as the v.digit code should a) not
be changing the WIND file (if that's possible with mixed Tcl + C) and
b) use "g.region -a" like code when zooming so as not to corrupt
background raster resampling."
Note that it now restores the startup region upon clean exit.

Anyway this is a long standing and serious bug.

So it boils down to issue [3] "can't digitize centroids".
But this works fine for me in 6.2.1, so .....?

Same for me now, as I explain above. In that case if the encoding issue
could be fixed in 6.2, v.digit in 6.2 and 6.3 would be on a par.

what's more, v.digit in GRASS 6.3 segfaults on startup for me currently.

Oh. For me it works OK in 6.3.

Not an encouraging sign for the 6.3 version being mature enough to
backport.

g.region rast=roads
v.digit -n test_dig_area
New empty map created.
###wish gui flashes up then disappears###
Segmentation fault

gdb:
G63> gdb `which v.digit`
..
(gdb) run -n test_map1
Starting program: /usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/bin/v.digit -n test_map1
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 9024)]
New empty map created.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9024)]
0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1

(gdb) where
#0 0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1
#1 0x406e5a77 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
#2 0x406e5967 in Tcl_EvalTokens () from /usr/lib/libtcl8.3.so.1
#3 0x406e5ad8 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
#4 0x406e5ead in Tcl_Eval () from /usr/lib/libtcl8.3.so.1
#5 0x0805074f in get_window (t=0xbfffdddc, b=0xbfffddd8, l=0xbfffddd4, r=0xbfffddd0) at driver.c:58
#6 0x08050811 in setup () at driver.c:73
#7 0x0805091c in driver_open () at driver.c:101
#8 0x0804f9cd in tool_centre () at centre.c:50
#9 0x0804e9b7 in c_tool_centre (cdata=0x0, interp=0x8069248, argc=1, argv=0xbfffdf40) at c_face.c:159
#10 0x406ad7ab in TclInvokeStringCommand () from /usr/lib/libtcl8.3.so.1
#11 0x406e529c in TclExpandTokenArray () from /usr/lib/libtcl8.3.so.1
#12 0x406e5b3d in Tcl_EvalEx () from /usr/lib/libtcl8.3.so.1
#13 0x406dca0e in Tcl_EvalFile () from /usr/lib/libtcl8.3.so.1
#14 0x40609774 in Tk_MainEx () from /usr/lib/libtk8.3.so.1
#15 0x08055102 in main (argc=3, argv=0xbffff6b4) at main.c:171

same thing starting with:
G63> GRASS_WISH=wish8.4 v.digit -n test_map2

FWIW I build and run against tcl/tk 8.4.12. No crashes here.

We seem to have agreed (yes?) that backporting the new EPSG code search
tool in violation of the "fixes for serious bugs only" rule is ok, as
it is a non-critical component and the new version is really really nice.
So I hope I'm not seeming to be unfair in playing conservative with
v.digit while at the same time pushing for the new EPSG picker.

I don't have a strong position on this.

Maciek

Maciej Sieczka wrote:

Hamish wrote:

So it boils down to issue [3] "can't digitize centroids".
But this works fine for me in 6.2.1, so .....?

Same for me now, as I explain above. In that case if the encoding issue
could be fixed in 6.2, v.digit in 6.2 and 6.3 would be on a par.

Oopsy! I *do* can reproduce the bug that v.digit freezes when
digitizing centroids and editing attributes in 6.2 CVS. Pretty much
like the report says [1]:

1. start v.digit

2. create a table with one 50 chars varchar column

3. choose "Digitize new centroid" tool, digitize 1 centroid, enter
label, submit

4. choose "Display attributes" tool, select a vector feature, edit
label, submit

5. goto 3

After 2-4 such repeats v.digit freezes for me. Have to kill -9 it.

[1]http://wald.intevation.org/tracker/?func=detail&atid=204&aid=354&group_id=21

Maciej Sieczka wrote:

> what's more, v.digit in GRASS 6.3 segfaults on startup for me
> currently.

Oh. For me it works OK in 6.3.

> Not an encouraging sign for the 6.3 version being mature enough to
> backport.

> g.region rast=roads
> v.digit -n test_dig_area
> New empty map created.
> ###wish gui flashes up then disappears###
> Segmentation fault
>
> gdb:
> G63> gdb `which v.digit`
> ..
> (gdb) run -n test_map1
> Starting program:
> /usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/bin/v.digit -n
> test_map1 [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 9024)]
> New empty map created.
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 9024)]
> 0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1

..

> same thing starting with:
> G63> GRASS_WISH=wish8.4 v.digit -n test_map2

FWIW I build and run against tcl/tk 8.4.12. No crashes here.

Now I recall this is C+Tcl, so the runtime wish doesn't matter as much,
it's the version of the tcltk compile time headers that matter.
Most likely a feature new for tcltk 8.4 being used?

Hamish

Hamish wrote:

> > what's more, v.digit in GRASS 6.3 segfaults on startup for me
> > currently.
>
> Oh. For me it works OK in 6.3.
>
> > Not an encouraging sign for the 6.3 version being mature enough to
> > backport.
>
> > g.region rast=roads
> > v.digit -n test_dig_area
> > New empty map created.
> > ###wish gui flashes up then disappears###
> > Segmentation fault
> >
> > gdb:
> > G63> gdb `which v.digit`
> > ..
> > (gdb) run -n test_map1
> > Starting program:
> > /usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/bin/v.digit -n
> > test_map1 [Thread debugging using libthread_db enabled]
> > [New Thread 16384 (LWP 9024)]
> > New empty map created.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 16384 (LWP 9024)]
> > 0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1
..
> > same thing starting with:
> > G63> GRASS_WISH=wish8.4 v.digit -n test_map2
>
> FWIW I build and run against tcl/tk 8.4.12. No crashes here.

Now I recall this is C+Tcl, so the runtime wish doesn't matter as much,

FWIW, the runtime "wish" doesn't matter *at all*.

I don't get a crash here (Tcl/Tk 8.4), so unless someone who does get
a crash can provide a backtrace, there isn't much that we can do about
it.

It might be worth checking programs which use the form library, e.g.
d.what.vect and v.what.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn Clements wrote:

Hamish wrote:

> > > what's more, v.digit in GRASS 6.3 segfaults on startup for me
> > > currently.
> >
> > Oh. For me it works OK in 6.3.
> >
> > > Not an encouraging sign for the 6.3 version being mature enough
> > > to backport.
> >
> > > g.region rast=roads
> > > v.digit -n test_dig_area
> > > New empty map created.
> > > ###wish gui flashes up then disappears###
> > > Segmentation fault
> > >
> > > gdb:
> > > G63> gdb `which v.digit`
> > > ..
> > > (gdb) run -n test_map1
> > > Starting program:
> > > /usr/local/src/grass/grass63/dist.i686-pc-linux-gnu/bin/v.digit
> > > -n test_map1 [Thread debugging using libthread_db enabled]
> > > [New Thread 16384 (LWP 9024)]
> > > New empty map created.
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > [Switching to Thread 16384 (LWP 9024)]
> > > 0x406e4a02 in Tcl_ParseCommand () from /usr/lib/libtcl8.3.so.1
> ..
> > > same thing starting with:
> > > G63> GRASS_WISH=wish8.4 v.digit -n test_map2
> >
> > FWIW I build and run against tcl/tk 8.4.12. No crashes here.
>
> Now I recall this is C+Tcl, so the runtime wish doesn't matter as
> much,

FWIW, the runtime "wish" doesn't matter *at all*.

I don't get a crash here (Tcl/Tk 8.4), so unless someone who does get
a crash can provide a backtrace, there isn't much that we can do about
it.

backtrace is here:
  http://grass.itc.it/pipermail/grass-dev/2007-April/030641.html

driver.c line 58, in get_window():
    Tcl_Eval(Toolbox, "list 0 [winfo height .screen.canvas] 0 [winfo width .screen.canvas]");

after that, I'm not sure where to look.

It might be worth checking programs which use the form library, e.g.
d.what.vect and v.what.

d.what.vect is working fine. v.what segfaulted, but that was another
issue which I've just fixed in CVS. Now v.what works ok.

Hamish

On Fri, Apr 27, 2007 at 04:24:06PM +1200, Hamish wrote:

v.what segfaulted, but that was another
issue which I've just fixed in CVS. Now v.what works ok.

It doesn't yet since it only reports on the first coordinate
pair even if multiple are given.

Markus

Markus Neteler wrote:

On Fri, Apr 27, 2007 at 04:24:06PM +1200, Hamish wrote:
> v.what segfaulted, but that was another
> issue which I've just fixed in CVS. Now v.what works ok.

It doesn't yet since it only reports on the first coordinate
pair even if multiple are given.

So it does(n't) ... (both 6.2 and 6.3-cvs)

it works in 6.3 if coords are taken from stdin:
(is the -s flag really needed? couldn't it just test if the east_north=
answer was NULL?)

g.region v=fields
d.vect -c fields type=area

v.what -s << EOF
591672,4919071
594353,4923539
601742,4924260
EOF

# but only the first coord if taken from the command line:
v.what east=591672,4919071,594353,4923539,601742,4924260

Hamish

Hamish wrote:

> I don't get a crash here (Tcl/Tk 8.4), so unless someone who does get
> a crash can provide a backtrace, there isn't much that we can do about
> it.

backtrace is here:
  http://grass.itc.it/pipermail/grass-dev/2007-April/030641.html

driver.c line 58, in get_window():
    Tcl_Eval(Toolbox, "list 0 [winfo height .screen.canvas] 0 [winfo width .screen.canvas]");

after that, I'm not sure where to look.

I'm not entirely sure how Tcl_Eval() can cause a segfault unless the
interpreter state has been corrupted, and this is occurring very early
in the startup, before hardly any C code has been called.

You could try "g.gisenv set=DEBUG=5" to see if that produces any
clues.

The only other thing which I can suggest is to build Tcl/Tk with debug
info (or are there separate debug packages available?).

--
Glynn Clements <glynn@gclements.plus.com>

Hamish:

> > v.what segfaulted, but that was another
> > issue which I've just fixed in CVS. Now v.what works ok.

Markus:

> It doesn't yet since it only reports on the first coordinate
> pair even if multiple are given.

Hamish:

So it does(n't) ... (both 6.2 and 6.3-cvs)

fixed in 6.3-cvs and 6.2 release branch.

Hamish