... as the subject indicate: any objections to change to wxGUI as default?
Make this change from 6.4.0 to 6.4.1 isn't much policy compliant.
And I would like to avoid to publish a 6.5 rather than focusing on 7...
Markus
yes PLEASE!
Helena
as Mike has said we still need tcltk for nviz
On Feb 11, 2010, at 11:36 AM, Markus Neteler wrote:
... as the subject indicate: any objections to change to wxGUI as default?
Make this change from 6.4.0 to 6.4.1 isn't much policy compliant.
And I would like to avoid to publish a 6.5 rather than focusing on 7...Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus wrote:
... as the subject indicate: any
objections to change to wxGUI as default?
I have been thinking about this since it last came up.
I came to the conclusion that we should ask for the Mac
package to use wx, as the deps are already included and controlled.
The Windows package already defaults to wx by way of the desktop
icon. In the Start->menu you get a choice. And the way the
icons are set up means that the user's default is reset every
time they start with one gui or the other. So nothing to do
for WinGrass.
But I'm still not convinced about what to do in the source
release and on linux. My general feeling was that wx and python
is still immature and changing a lot in distros, so we should
stay with tcl and let packagers decide if they want to use wx
or not.
we'd also have to change --with-python to --without-python etc.
:-/
Make this change from 6.4.0 to 6.4.1 isn't much policy
compliant.
do you mean from the POV of keeping documentation and tutorials
relevant/versioned?
(it is irrelevant from the POV of backwards compatibility in
scripts)
And I would like to avoid to publish a 6.5 rather than
focusing on 7...
I don't see why the switch would necessitate another x.y.0 point
release. I too would like to avoid a 6.5.
so my +1 would be to make wx the default on mac, and my +0.5 would
be to wait for 6.4.1 before making it the default in the source
(and so linux).
[for the source, the changes are in init.sh and g.gui/main.c]
Hamish
Markus Neteler wrote:
... as the subject indicate: any objections to change to wxGUI as default?
Make this change from 6.4.0 to 6.4.1 isn't much policy compliant.
And I would like to avoid to publish a 6.5 rather than focusing on 7...
My main concern is that there should be some way to prevent the GUI
from loading the vdigit and nviz modules.
AFAIK, it handles the case where these modules don't exist. But if
they do exist and there's something wrong with them (binary
compatibility issues), the whole GUI is toast.
For 7.0, I'm inclined to simply leave them disabled until they have
been re-implemented as programs. I'm not so sure that we shouldn't be
doing likewise for 6.x. Their eventual form will be somewhat different
to the existing implementation, so it may be better if they weren't
offered before then.
--
Glynn Clements <glynn@gclements.plus.com>
On Fri, Feb 12, 2010 at 7:22 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
... as the subject indicate: any objections to change to wxGUI as default?
I am still MUCH in favour of this change.
Make this change from 6.4.0 to 6.4.1 isn't much policy compliant.
And I would like to avoid to publish a 6.5 rather than focusing on 7...My main concern is that there should be some way to prevent the GUI
from loading the vdigit and nviz modules.
I agree. Is that hard to accomplish?
My brute-force method is (in GRASS):
rm -rf $GISBASE/etc/wxpython/nviz $GISBASE/etc/wxpython/vdigit
then 'g.gui wxpython' works.
AFAIK, it handles the case where these modules don't exist. But if
they do exist and there's something wrong with them (binary
compatibility issues), the whole GUI is toast.
... which is unacceptable and currently the case on my laptop.
So a functionality test (or whatever) before loading the vdigit and
nviz modules would be needed. Since the tcl versions of both are
accessible, I don't see it as showstopper to have the wxGUI as
default GUI *if the test was added* and wxnviz and wxvdigit fail.
Markus
It seems that vector display is still causing problems when GRASS is installed under C:\Program Files
see below:
Helena
computers and systems:
personal laptop:
cpu:AMD Turion x2 ultra dual core mobile zm-82 2.2Ghz
windows 7 professional 64 bit
office dekstop:
cpu:Intel Core 2 Quad Q6600 2.4Ghz
Windows 7 professional 64 bit)
I tested the latest - they still crash when installed in the default installation folder (C:\Program Files (x86)\GRASS-64-SVN) - both work good when I install them in a folder that does not contain any spaces in the path name (C:\GRASS64). So no change since I last tested both versions.
previous message
I was able to display vectors 1 - 2 times then it starts crashing (in both 64 and 65 - It used to crash every time I used d.vect)
when I say d.vect - it is not command line, I am using the GUI.
the error message from windows syas that python.exe crashes.
in the msys it says: "bad file descriptor"
Helena Mitasova
Associate Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
Raleigh, NC 27695
hmitaso@unity.ncsu.edu
On Feb 26, 2010, at 10:04 AM, Markus Neteler wrote:
On Fri, Feb 12, 2010 at 7:22 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:Markus Neteler wrote:
... as the subject indicate: any objections to change to wxGUI as default?
I am still MUCH in favour of this change.
Make this change from 6.4.0 to 6.4.1 isn't much policy compliant.
And I would like to avoid to publish a 6.5 rather than focusing on 7...My main concern is that there should be some way to prevent the GUI
from loading the vdigit and nviz modules.I agree. Is that hard to accomplish?
My brute-force method is (in GRASS):
rm -rf $GISBASE/etc/wxpython/nviz $GISBASE/etc/wxpython/vdigit
then 'g.gui wxpython' works.
AFAIK, it handles the case where these modules don't exist. But if
they do exist and there's something wrong with them (binary
compatibility issues), the whole GUI is toast.... which is unacceptable and currently the case on my laptop.
So a functionality test (or whatever) before loading the vdigit and
nviz modules would be needed. Since the tcl versions of both are
accessible, I don't see it as showstopper to have the wxGUI as
default GUI *if the test was added* and wxnviz and wxvdigit fail.Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus wrote:
>> any objections to change to wxGUI as default?
I am still MUCH in favour of this change.
I don't feel too strongly about it, but I've gone a little lukewarm on
the idea, as e.g.
https://trac.osgeo.org/grass/ticket/728
tcl v.digit and nviz are available from the wxGUI menus, the only way
to georectify on wingrass is to switch to gis.m.
I don't mind if the Mac OSX package switches default gui, as it's a known
& self-provided environment.
shrug,
Hamish
Markus Neteler wrote:
> My main concern is that there should be some way to prevent the GUI
> from loading the vdigit and nviz modules.I agree. Is that hard to accomplish?
My brute-force method is (in GRASS):
rm -rf $GISBASE/etc/wxpython/nviz $GISBASE/etc/wxpython/vdigit
then 'g.gui wxpython' works.
In 6.4 and 6.5, you can just omit --with-wxwidgets; that will disable
the vdigit and nviz modules (the main GUI is installed regardless).
In 7.0, it will also disable xganim and wximgview.
> AFAIK, it handles the case where these modules don't exist. But if
> they do exist and there's something wrong with them (binary
> compatibility issues), the whole GUI is toast.... which is unacceptable and currently the case on my laptop.
So a functionality test (or whatever) before loading the vdigit and
nviz modules would be needed.
This would need to be a separate program. If you "import vdigit" (or
nviz), failure typically means that the program performing the import
crashes; it cannot be trapped.
It would be simpler to conditionalise the import on an environment
variable.
But the only long-term solution is to remove those modules from the
GUI and make vdigit and nviz separate programs. The main GUI shouldn't
be importing any binary module which isn't part of either Python
itself or of a well-tested, mainstream package (e.g. wxPython, NumPy),
and definitely shouldn't be importing anything linked against GRASS
libraries (with G_fatal_error() and memory leaks and innumerable
static variables).
I keep meaning to do this (the "remove" part) for 7.0, but I always
end up getting lost in the code and giving up.
On a related note: it would really help if wxGUI authors would add
paramter type information to methods, i.e.:
assert isinstance(arg1, str)
assert isinstance(arg2, (int,long,float))
etc. Without type information, it's extremely difficult to get a
handle on what the code is supposed to be doing, or where to look for
the code behind e.g. "arg1.foo()".
--
Glynn Clements <glynn@gclements.plus.com>
Helena Mitasova wrote:
I tested the latest - they still crash when installed in the default
installation folder (C:\Program Files (x86)\GRASS-64-SVN)
The folder is actually called "Program Files (x86)"? It's within the
realms of possibility that something doesn't like parentheses in
filenames.
--
Glynn Clements <glynn@gclements.plus.com>
On Fri, Feb 26, 2010 at 4:04 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Fri, Feb 12, 2010 at 7:22 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:Markus Neteler wrote:
... as the subject indicate: any objections to change to wxGUI as default?
..
AFAIK, it handles the case where these modules don't exist. But if
they do exist and there's something wrong with them (binary
compatibility issues), the whole GUI is toast.... which is unacceptable and currently the case on my laptop.
Good news: on a newly installed machine, same Mandriva distro, 64bit
all *works*. I must have some bad libs or cruft on my laptop.
Markus
On Sat, Feb 27, 2010 at 9:14 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Fri, Feb 26, 2010 at 4:04 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Fri, Feb 12, 2010 at 7:22 AM, Glynn Clements wrote:
Markus Neteler wrote:
... as the subject indicate: any objections to change to wxGUI as default?
..
AFAIK, it handles the case where these modules don't exist. But if
they do exist and there's something wrong with them (binary
compatibility issues), the whole GUI is toast.... which is unacceptable and currently the case on my laptop.
Good news: on a newly installed machine, same Mandriva distro, 64bit
all *works*. I must have some bad libs or cruft on my laptop.
Looking further into this, I understand that "g.gui wxpython" calls effectively
python $GISBASE/etc/wxpython/wxgui.py
Doing so, I get a segmentation fault after the popup of the old map screen:
strace python $GISBASE/etc/wxpython/wxgui.py
fstat(10, {st_mode=S_IFREG|0644, st_size=1248, ...}) = 0
open("/usr/lib64/python2.6/encodings/ascii.pyc", O_RDONLY) = 11
fstat(11, {st_mode=S_IFREG|0644, st_size=2281, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f1831c26000
read(11, "\321\362\r\n\0\307GKc\0\0\0\0\0\0\0\0\4\0\0\0@\0\0\0s\273\0\0\0d\0"...,
4096) = 2281
fstat(11, {st_mode=S_IFREG|0644, st_size=2281, ...}) = 0
read(11, "", 4096) = 0
close(11) = 0
munmap(0x7f1831c26000, 4096) = 0
close(10) = 0
brk(0x2ec6000) = 0x2ec6000
brk(0x2ee7000) = 0x2ee7000
brk(0x2f08000) = 0x2f08000
brk(0x2f29000) = 0x2f29000
read(9, "M. Either A: exact sun position "..., 32768) = 32768
brk(0x2f4a000) = 0x2f4a000
brk(0x2f6b000) = 0x2f6b000
brk(0x2f8c000) = 0x2f8c000
read(9, "ce</command>\n\t</menuitem>\n\t<menu"..., 32768) = 23999
read(9, "", 8192) = 0
brk(0x2fad000) = 0x2fad000
brk(0x2fce000) = 0x2fce000
brk(0x2fef000) = 0x2fef000
read(9, "", 32768) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault
Unfortunately I have no idea how to debug this (gdb and ddd refuse to do so).
Pointers welcome,
Markus
Markus Neteler wrote:
Unfortunately I have no idea how to debug this (gdb and ddd refuse to do so).
Pointers welcome,
gdb python
start /path/to/etc/wxpython/wxgui.py
If Python was compiled without debug support, the backtrace may not be
much use if the segfault is occuring within Python itself.
--
Glynn Clements <glynn@gclements.plus.com>
it still crashes when adding vector, but I don't see anybody else complaining
about this (as I said there is no problem when winGRASS is installed
under the previous path that did not have spaces).
I am not sure whether this should delay RC6
Helena
I removed the parentheses from the default installation path to:
C:\Program Files x86\GRASS-64-SVN
it was
C:\Program Files (x86)\GRASS-64-SVN
before.
It crashed. It is not the parentheses - the spaces cause the problem.
On Feb 26, 2010, at 4:01 PM, Glynn Clements wrote:
Helena Mitasova wrote:
I tested the latest - they still crash when installed in the default
installation folder (C:\Program Files (x86)\GRASS-64-SVN)The folder is actually called "Program Files (x86)"? It's within the
realms of possibility that something doesn't like parentheses in
filenames.--
Glynn Clements <glynn@gclements.plus.com>
On Sat, Feb 27, 2010 at 10:10 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
Unfortunately I have no idea how to debug this (gdb and ddd refuse to do so).
Pointers welcome,gdb python start /path/to/etc/wxpython/wxgui\.pyIf Python was compiled without debug support, the backtrace may not be
much use if the segfault is occuring within Python itself.
I have installed python-debug now.
Using the graphical frontend "ddd" to gdb, it fails in glibc, malloc/hooks.c.
Using gdb, I get this:
GRASS 6.4.0svn (nc_spm_08):~ > gdb python
GNU gdb 6.8-7mdv2010.0 (Mandriva Linux release 2010.0)
...
(gdb) r /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py
Starting program: /usr/bin/python
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py
[Thread debugging using libthread_db enabled]
[New Thread 0x7f034db846f0 (LWP 11517)]
Detaching after fork from child process 11528.
Detaching after fork from child process 11529.
Detaching after fork from child process 11530.
Detaching after fork from child process 11531.
Detaching after fork from child process 11532.
Detaching after fork from child process 11533.
[New Thread 0x7f0330a7c910 (LWP 11539)]
Program received signal SIGSEGV, Segmentation fault.
mem2chunk_check (mem=0x7f032d40a000, magic_p=0x0) at hooks.c:156
156 if (!chunk_is_mmapped(p)) {
Missing debug package(s), you should install:
GConf2-debug-2.28.0-1mdv2010.0.x86_64
ORBit2-debug-2.14.17-1mdv2010.0.x86_64
[...]
(gdb) bt
#0 mem2chunk_check (mem=0x7f032d40a000, magic_p=0x0) at hooks.c:156
#1 0x00007f034d30633c in free_check (mem=0x7f032d40a000,
caller=<value optimized out>) at hooks.c:280
#2 0x00007f033bde9cf2 in XML_ParserFree () from
/usr/lib64/libexpat.so.1
#3 0x00007f032d4113fb in ?? ()
from /usr/lib64/python2.6/site-packages/_xmlplus/parsers/pyexpat.so
#4 0x00007f034d66af37 in PyDict_DelItem (op=0x165f690,
key=<value optimized out>) at Objects/dictobject.c:755
#5 0x00007f034d645824 in instance_setattr (inst=0x7f03373bf7a0,
name=0x7f033ee09690, v=0x0) at Objects/classobject.c:794
#6 0x00007f034d66ec97 in PyObject_SetAttr (v=0x7f03373bf7a0,
name=0x7f033ee09690, value=0x0) at Objects/object.c:1252
#7 0x00007f034d6c2cb9 in PyEval_EvalFrameEx (f=0x175f660,
throwflag=<value optimized out>) at Python/ceval.c:1850
#8 0x00007f034d6c6e1b in PyEval_EvalFrameEx (f=0x165f1f0,
throwflag=<value optimized out>) at Python/ceval.c:3792
#9 0x00007f034d6c8305 in PyEval_EvalCodeEx (co=0x7f033ee05378,
globals=<value optimized out>, locals=<value optimized out>,
args=0x165efc0,
argcount=<value optimized out>, kws=<value optimized out>,
kwcount=0,
defs=0x7f033ee0f628, defcount=1, closure=0x0) at
Python/ceval.c:2968
#10 0x00007f034d6c65eb in PyEval_EvalFrameEx (f=0x165ee30,
throwflag=<value optimized out>) at Python/ceval.c:3802
#11 0x00007f034d6c8305 in PyEval_EvalCodeEx (co=0x7f033ee05c60,
globals=<value optimized out>, locals=<value optimized out>,
args=0x1,
argcount=<value optimized out>, kws=<value optimized out>,
kwcount=0,
defs=0x7f033ee0f828, defcount=1, closure=0x0) at
Python/ceval.c:2968
#12 0x00007f034d6c65eb in PyEval_EvalFrameEx (f=0x165ec50,
throwflag=<value optimized out>) at Python/ceval.c:3802
#13 0x00007f034d6c8305 in PyEval_EvalCodeEx (co=0x7f033f31ae40,
globals=<value optimized out>, locals=<value optimized out>,
args=0x1,
argcount=<value optimized out>, kws=<value optimized out>,
kwcount=0,
defs=0x7f033ee04a68, defcount=1, closure=0x0) at
Python/ceval.c:2968
#14 0x00007f034d65b7ff in function_call (func=0x7f033ee01cf8,
arg=0x7f03373d09d0, kw=0x0) at Objects/funcobject.c:524
#15 0x00007f034d635023 in PyObject_Call (func=0x7f033ee01cf8, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#16 0x00007f034d6475cf in instancemethod_call (func=0x7f033ee01cf8,
arg=0x7f03373d09d0, kw=0x0) at Objects/classobject.c:2579
#17 0x00007f034d635023 in PyObject_Call (func=0x7f03373bee60, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#18 0x00007f034d6c0a03 in PyEval_CallObjectWithKeywords
(func=0x7f03373bee60,
arg=0x7f034db44050, kw=0xffffffffffffff90) at Python/ceval.c:3575
#19 0x00007f034d646d56 in PyInstance_New (klass=<value optimized out>,
arg=0x7f034db44050, kw=0x0) at Objects/classobject.c:568
#20 0x00007f034d635023 in PyObject_Call (func=0x7f033ede67d0, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#21 0x00007f034d6c6312 in PyEval_EvalFrameEx (f=0x165bb80,
throwflag=<value optimized out>) at Python/ceval.c:3924
#22 0x00007f034d6c6e1b in PyEval_EvalFrameEx (f=0x14ecc30,
throwflag=<value optimized out>) at Python/ceval.c:3792
#23 0x00007f034d6c8305 in PyEval_EvalCodeEx (co=0x7f034dab7210,
globals=<value optimized out>, locals=<value optimized out>,
args=0x3,
argcount=<value optimized out>, kws=<value optimized out>,
kwcount=3,
defs=0x7f033788c9c8, defcount=3, closure=0x0) at
Python/ceval.c:2968
#24 0x00007f034d65b8fb in function_call (func=0x7f03378a8e60,
arg=0x7f033ef98a90, kw=0x14b7970) at Objects/funcobject.c:524
#25 0x00007f034d635023 in PyObject_Call (func=0x7f03378a8e60, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#26 0x00007f034d6475cf in instancemethod_call (func=0x7f03378a8e60,
arg=0x7f033ef98a90, kw=0x14b7970) at Objects/classobject.c:2579
#27 0x00007f034d635023 in PyObject_Call (func=0x7f033eebef50, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#28 0x00007f034d6866fe in slot_tp_init (self=<value optimized out>,
args=0x7f034db44050, kwds=0x14b7970) at Objects/typeobject.c:5638
#29 0x00007f034d6852d8 in type_call (type=<value optimized out>,
args=0x7f034db44050, kwds=0x14b7970) at Objects/typeobject.c:747
#30 0x00007f034d635023 in PyObject_Call (func=0x13b2ef0, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#31 0x00007f034d6c6312 in PyEval_EvalFrameEx (f=0x14c3010,
throwflag=<value optimized out>) at Python/ceval.c:3924
#32 0x00007f034d6c8305 in PyEval_EvalCodeEx (co=0x7f034c7aa210,
globals=<value optimized out>, locals=<value optimized out>,
args=0x7f033ef98a28, argcount=<value optimized out>,
kws=<value optimized out>, kwcount=0, defs=0x0, defcount=0,
closure=0x0)
at Python/ceval.c:2968
#33 0x00007f034d65b7ff in function_call (func=0x7f03378b5b18,
arg=0x7f033ef98a10, kw=0x0) at Objects/funcobject.c:524
#34 0x00007f034d635023 in PyObject_Call (func=0x7f03378b5b18, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#35 0x00007f034d6475cf in instancemethod_call (func=0x7f03378b5b18,
arg=0x7f033ef98a10, kw=0x0) at Objects/classobject.c:2579
#36 0x00007f034d635023 in PyObject_Call (func=0x7f033eed71e0, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#37 0x00007f034d6c0a03 in PyEval_CallObjectWithKeywords
(func=0x7f033eed71e0,
arg=0x7f034db44050, kw=0xffffffffffffff90) at Python/ceval.c:3575
#38 0x00007f034b3fc63e in wxPyApp::_BootstrapApp ()
from /usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core_.so
---Type <return> to continue, or q <return> to quit---
#39 0x00007f034b485c93 in ?? ()
from /usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core_.so
#40 0x00007f034d6c6761 in PyEval_EvalFrameEx (f=0x13ebd80,
throwflag=<value optimized out>) at Python/ceval.c:4016
#41 0x00007f034d6c8305 in PyEval_EvalCodeEx (co=0x7f034c8c2468,
globals=<value optimized out>, locals=<value optimized out>,
args=0x13c6380,
argcount=<value optimized out>, kws=<value optimized out>,
kwcount=0,
defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2968
#42 0x00007f034d6c65eb in PyEval_EvalFrameEx (f=0x13c61d0,
throwflag=<value optimized out>) at Python/ceval.c:3802
#43 0x00007f034d6c8305 in PyEval_EvalCodeEx (co=0x7f034c8c6648,
globals=<value optimized out>, locals=<value optimized out>,
args=0x4,
argcount=<value optimized out>, kws=<value optimized out>,
kwcount=0,
defs=0x7f03425fe5e8, defcount=4, closure=0x0) at
Python/ceval.c:2968
#44 0x00007f034d65b7ff in function_call (func=0x7f0342602aa0,
arg=0x7f033787f200, kw=0x0) at Objects/funcobject.c:524
#45 0x00007f034d635023 in PyObject_Call (func=0x7f0342602aa0, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#46 0x00007f034d6475cf in instancemethod_call (func=0x7f0342602aa0,
arg=0x7f033787f200, kw=0x0) at Objects/classobject.c:2579
#47 0x00007f034d635023 in PyObject_Call (func=0x7f033eebefa0, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#48 0x00007f034d6c6312 in PyEval_EvalFrameEx (f=0x13ffdc0,
throwflag=<value optimized out>) at Python/ceval.c:3924
#49 0x00007f034d6c8305 in PyEval_EvalCodeEx (co=0x7f034c7aa120,
globals=<value optimized out>, locals=<value optimized out>,
args=0x7f0337435b60, argcount=<value optimized out>,
kws=<value optimized out>, kwcount=0, defs=0x7f033ef987e8,
defcount=1,
closure=0x0) at Python/ceval.c:2968
#50 0x00007f034d65b7ff in function_call (func=0x7f03378b5aa0,
arg=0x7f0337435b48, kw=0x0) at Objects/funcobject.c:524
#51 0x00007f034d635023 in PyObject_Call (func=0x7f03378b5aa0, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#52 0x00007f034d6475cf in instancemethod_call (func=0x7f03378b5aa0,
arg=0x7f0337435b48, kw=0x0) at Objects/classobject.c:2579
#53 0x00007f034d635023 in PyObject_Call (func=0x7f033eed70a0, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#54 0x00007f034d6866fe in slot_tp_init (self=<value optimized out>,
args=0x7f033ef98890, kwds=0x0) at Objects/typeobject.c:5638
#55 0x00007f034d6852d8 in type_call (type=<value optimized out>,
args=0x7f033ef98890, kwds=0x0) at Objects/typeobject.c:747
#56 0x00007f034d635023 in PyObject_Call (func=0x141fc50, arg=0x0,
kw=0xffffffffffffff90) at Objects/abstract.c:2492
#57 0x00007f034d6c6312 in PyEval_EvalFrameEx (f=0x13840e0,
throwflag=<value optimized out>) at Python/ceval.c:3924
#58 0x00007f034d6c8305 in PyEval_EvalCodeEx (co=0x7f034c7aa8a0,
globals=<value optimized out>, locals=<value optimized out>,
args=0x1,
argcount=<value optimized out>, kws=<value optimized out>,
kwcount=0,
defs=0x7f033ef98868, defcount=1, closure=0x0) at
Python/ceval.c:2968
#59 0x00007f034d6c65eb in PyEval_EvalFrameEx (f=0xa11100,
throwflag=<value optimized out>) at Python/ceval.c:3802
#60 0x00007f034d6c8305 in PyEval_EvalCodeEx (co=0x7f034c7aa990,
globals=<value optimized out>, locals=<value optimized out>, args=0x0,
argcount=<value optimized out>, kws=<value optimized out>, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2968
#61 0x00007f034d6c83d2 in PyEval_EvalCode (co=0x7f032d40a000, globals=0x0,
locals=0xffffffffffffff90) at Python/ceval.c:522
#62 0x00007f034d6e280c in run_mod (mod=<value optimized out>,
---Type <return> to continue, or q <return> to quit---
filename=<value optimized out>, globals=0x993640, locals=0x993640,
flags=<value optimized out>, arena=<value optimized out>)
at Python/pythonrun.c:1335
#63 0x00007f034d6e28e0 in PyRun_FileExFlags (fp=0x9e7610,
filename=0x7fff99280d5f
"/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py",
start=<value optimized out>,
globals=<value optimized out>, locals=0x993640, closeit=1,
flags=0x7fff9927ec50) at Python/pythonrun.c:1321
#64 0x00007f034d6e3cec in PyRun_SimpleFileExFlags (fp=<value optimized out>,
filename=0x7fff99280d5f
"/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py",
closeit=1, flags=0x7fff9927ec50) at Python/pythonrun.c:931
#65 0x00007f034d6f03c9 in Py_Main (argc=1303400576, argv=<value optimized out>)
at Modules/main.c:599
#66 0x00007f034d2b191d in __libc_start_main (main=<value optimized out>,
argc=<value optimized out>, ubp_av=<value optimized out>,
init=<value optimized out>, fini=<value optimized out>,
rtld_fini=<value optimized out>, stack_end=0x7fff9927ed68)
at libc-start.c:220
#67 0x0000000000400629 in _start () at ../sysdeps/x86_64/elf/start.S:113
The "bt full" output I have put here:
http://osgeo.pastebin.com/gj75Ywyg
I see that there is some pyexpat trouble (since it seems to fail to
read menudata.xml
properly).
Markus
Markus Neteler wrote:
Using gdb, I get this:
GRASS 6.4.0svn (nc_spm_08):~ > gdb python
GNU gdb 6.8-7mdv2010.0 (Mandriva Linux release 2010.0)
...
(gdb) r /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py
Starting program: /usr/bin/python
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py
[Thread debugging using libthread_db enabled]
[New Thread 0x7f034db846f0 (LWP 11517)]
Detaching after fork from child process 11528.
Detaching after fork from child process 11529.
Detaching after fork from child process 11530.
Detaching after fork from child process 11531.
Detaching after fork from child process 11532.
Detaching after fork from child process 11533.
[New Thread 0x7f0330a7c910 (LWP 11539)]Program received signal SIGSEGV, Segmentation fault.
mem2chunk_check (mem=0x7f032d40a000, magic_p=0x0) at hooks.c:156
156 if (!chunk_is_mmapped(p)) {
Missing debug package(s), you should install:
GConf2-debug-2.28.0-1mdv2010.0.x86_64
ORBit2-debug-2.14.17-1mdv2010.0.x86_64
[...]
(gdb) bt
#0 mem2chunk_check (mem=0x7f032d40a000, magic_p=0x0) at hooks.c:156
#1 0x00007f034d30633c in free_check (mem=0x7f032d40a000,
caller=<value optimized out>) at hooks.c:280
#2 0x00007f033bde9cf2 in XML_ParserFree () from
Something (presumably in vdigit or nviz) is corrupting the heap,
causing a crash in an unrelated free().
I have no idea where to go from here.
--
Glynn Clements <glynn@gclements.plus.com>
On Sun, Feb 28, 2010 at 6:10 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
Using gdb, I get this:
GRASS 6.4.0svn (nc_spm_08):~ > gdb python
GNU gdb 6.8-7mdv2010.0 (Mandriva Linux release 2010.0)
...
(gdb) r /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py
...
[...]
(gdb) bt
#0 mem2chunk_check (mem=0x7f032d40a000, magic_p=0x0) at hooks.c:156
#1 0x00007f034d30633c in free_check (mem=0x7f032d40a000,
caller=<value optimized out>) at hooks.c:280
#2 0x00007f033bde9cf2 in XML_ParserFree () fromSomething (presumably in vdigit or nviz) is corrupting the heap,
causing a crash in an unrelated free().
Here some valgrind tests:
CMD="python /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py"
valgrind --tool=massif $CMD
==14220== Massif, a heap profiler
==14220== Copyright (C) 2003-2009, and GNU GPL'd, by Nicholas Nethercote
==14220== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==14220== Command: python
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py
==14220==
==14220== Process terminating with default action of signal 11 (SIGSEGV)
==14220== Access not within mapped region at address 0x9
==14220== at 0x17C5EC2B: ??? (in /usr/lib64/libexpat.so.1.5.2)
==14220== by 0x17C5FCFD: XML_ParserFree (in /usr/lib64/libexpat.so.1.5.2)
==14220== by 0x26BAF3FA: ??? (in
/usr/lib64/python2.6/site-packages/_xmlplus/parsers/pyexpat.so)
==14220== by 0x4E9DF36: PyDict_DelItem (dictobject.c:755)
==14220== by 0x4E78823: instance_setattr (classobject.c:794)
==14220== by 0x4EA1C96: PyObject_SetAttr (object.c:1252)
==14220== by 0x4EF5CB8: PyEval_EvalFrameEx (ceval.c:1850)
==14220== by 0x4EF9E1A: PyEval_EvalFrameEx (ceval.c:3792)
==14220== by 0x4EFB304: PyEval_EvalCodeEx (ceval.c:2968)
==14220== by 0x4EF95EA: PyEval_EvalFrameEx (ceval.c:3802)
==14220== by 0x4EFB304: PyEval_EvalCodeEx (ceval.c:2968)
==14220== by 0x4EF95EA: PyEval_EvalFrameEx (ceval.c:3802)
==14220== If you believe this happened as a result of a stack
==14220== overflow in your program's main thread (unlikely but
==14220== possible), you can try to increase the size of the
==14220== main thread stack using the --main-stacksize= flag.
==14220== The main thread stack size used in this run was 8388608.
==14220==
Killed
and
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD 2>
valgrind_memorytest.log
660k.gz:
http://gis.fem-environment.eu/download/valgrind_memorytest.log.gz
Not sure if that would give any insights... I hope so!
Markus
On Sun, Feb 28, 2010 at 6:10 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
...
Something (presumably in vdigit or nviz) is corrupting the heap,
causing a crash in an unrelated free().I have no idea where to go from here.
I have seen that some G_free() statements are followed by a
var = NULL;
some aren't. Attached a diff for the missing ones. It does not
seem to have a positive effect but I wonder about this inconsistency.
Markus
(attachments)
wxgui_free.diff (1.29 KB)
Markus Neteler wrote:
On Sun, Feb 28, 2010 at 6:10 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
> Markus Neteler wrote:
>
>> Using gdb, I get this:
>>
>> GRASS 6.4.0svn (nc_spm_08):~ > gdb python
>> GNU gdb 6.8-7mdv2010.0 (Mandriva Linux release 2010.0)
>> ...
>> (gdb) r /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py
...
>> [...]
>> (gdb) bt
>> #0 mem2chunk_check (mem=0x7f032d40a000, magic_p=0x0) at hooks.c:156
>> #1 0x00007f034d30633c in free_check (mem=0x7f032d40a000,
>> caller=<value optimized out>) at hooks.c:280
>> #2 0x00007f033bde9cf2 in XML_ParserFree () from
>
> Something (presumably in vdigit or nviz) is corrupting the heap,
> causing a crash in an unrelated free().Here some valgrind tests:
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD 2>
valgrind_memorytest.log660k.gz:
http://gis.fem-environment.eu/download/valgrind_memorytest.log.gzNot sure if that would give any insights... I hope so!
This looks very suspicious:
==15942== by 0x9043DB4: XML_ParseBuffer (in /usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0)
On my system, libexpat contains a function named XML_ParseBuffer.
Aha. wxWidgets includes a copy of expat, which it will use if
configured --with-expat=builtin. That's likely to cause problems if
both wxWidgets and the system's expat are loaded into Python.
Incidentally, I would expect this to be problematic regardless of
whether you use the vdigit module.
The only solution is to use a version of wxWidgets built with
--with-expat=sys.
--
Glynn Clements <glynn@gclements.plus.com>
On Mon, Mar 1, 2010 at 4:53 PM, Glynn Clements <glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
On Sun, Feb 28, 2010 at 6:10 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
> Markus Neteler wrote:
>
>> Using gdb, I get this:
>>
>> GRASS 6.4.0svn (nc_spm_08):~ > gdb python
>> GNU gdb 6.8-7mdv2010.0 (Mandriva Linux release 2010.0)
>> ...
>> (gdb) r /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py
...
>> [...]
>> (gdb) bt
>> #0 mem2chunk_check (mem=0x7f032d40a000, magic_p=0x0) at hooks.c:156
>> #1 0x00007f034d30633c in free_check (mem=0x7f032d40a000,
>> caller=<value optimized out>) at hooks.c:280
>> #2 0x00007f033bde9cf2 in XML_ParserFree () from
>
> Something (presumably in vdigit or nviz) is corrupting the heap,
> causing a crash in an unrelated free().Here some valgrind tests:
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD 2>
valgrind_memorytest.log660k.gz:
http://gis.fem-environment.eu/download/valgrind_memorytest.log.gzNot sure if that would give any insights... I hope so!
This looks very suspicious:
==15942== by 0x9043DB4: XML_ParseBuffer (in /usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0)
Thanks for your forensic analysis in the 14MB log!
Sidenote: the strange thing for me is that it works on one machine
while on the other
not (while using the same distro with same updates; only CPU and video card are
different; both 64bit).
On my system, libexpat contains a function named XML_ParseBuffer.
Yes, same here:
grep -i XML_ParseBuffer /usr/src/debug/expat-2.0.1/lib/*
...
/usr/src/debug/expat-2.0.1/lib/xmlparse.c:XML_ParseBuffer(XML_Parser
parser, int len, int isFinal)
Aha. wxWidgets includes a copy of expat, which it will use if
configured --with-expat=builtin. That's likely to cause problems if
both wxWidgets and the system's expat are loaded into Python.Incidentally, I would expect this to be problematic regardless of
whether you use the vdigit module.The only solution is to use a version of wxWidgets built with
--with-expat=sys.
The changelog says:
lib64wxgtku2.8
* Sun Aug 23 2009 Oden Eriksson <oeriksson mandriva.com> 2.8.10-3mdv2010.0
+ Revision: 419407
- try to build against system expat
[root@north neteler]# ldd
/usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0 | grep pat
[root@north neteler]#
Interestingly, no reference 
But:
for i in /usr/lib64/libwx_gtk2u_* ; do echo "$i:" ; ldd $i | grep expat; done
...
/usr/lib64/libwx_gtk2u_xrc-2.8.so.0.6.0:
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f7c44b84000)
Indeed, the file mentioned above comes from a different RPM:
rpm -qf /usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0
lib64wxPythonGTK2.8-2.8.9.2-3mdv2010.0
So, got now the original wxPythonGTK-2.8.9.2-3mdv2010.0.src.rpm now, there is
an expat copy inside as you state. Indeed, no trace of --with-expat=sys in the
SPEC file! This is opposite to what they do for lib64wxgtku2.8.
Ok, SPEC file enriched with --with-expat=sys, recompiled, installed and
...MUSIC.... it works!! After 9 months or so wxNVIZ and wxVDIGIT are back
on my laptop.
Great job, Glynn.
Bug report files with the RPM maintainer.
Thanks so much,
Markus
On Tue, Mar 2, 2010 at 11:53 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Mon, Mar 1, 2010 at 4:53 PM, Glynn Clements <glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
On Sun, Feb 28, 2010 at 6:10 PM, Glynn Clements
...
>> (gdb) r /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/wxpython/wxgui.py
...
>> [...]
>> (gdb) bt
>> #0 mem2chunk_check (mem=0x7f032d40a000, magic_p=0x0) at hooks.c:156
>> #1 0x00007f034d30633c in free_check (mem=0x7f032d40a000,
>> caller=<value optimized out>) at hooks.c:280
>> #2 0x00007f033bde9cf2 in XML_ParserFree () from
...
This looks very suspicious:
==15942== by 0x9043DB4: XML_ParseBuffer (in /usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0)
...
Ok, SPEC file enriched with --with-expat=sys, recompiled, installed and
...MUSIC.... it works!! After 9 months or so wxNVIZ and wxVDIGIT are back
on my laptop.Great job, Glynn.
Bug report files with the RPM maintainer.
s/files/filed/
The new RPM is in "testing".
The Mandriva maintainer told me:
"I can only push this as an official update if there is a simple
instruction to
for the QA team to reproduce the bug."
Do you have a suggestion to make a simple test case for above problem?
Thanks
Markus