GRC on OSX?

I’m trying to run ./Editor.py on the latest GRC SVN trunk on OSX
10.4.10 (checked out as of this morning). I’ve used MacPorts to
install python 2.5, python wx, python gtk2, and python xml (along
with their dependencies, and all of the GNU Radio dependencies).
When I run ./Editor.py, I get:

cannot import name numbersink2 in Numerical Sink! -> continuing…
Removing empty category “Custom”…
<<< Welcome to GRC 0.69 >>>

Error: Cannot load preferences file: “/Users/mlk/.grc.xml”
Bus error


I’ve never used or tried GRC before, so I have no idea what to
expect … but not a “bus error”. Any ideas or advice for using GRC
on OSX? - MLD

— Michael D. [email protected] wrote:

Bus error
I think it is best to address the erors in order. “bus error”
is surprising for an interpreted language but "Cannot load preferences
file: “/Users/mlk/.grc.xml” seems like it should be easy to address.
My gues the lack of a config file leaves some variables un-intialized
which leads to the bus error

Chris Albertson
Home: 310-376-1029 [email protected]
Office: 310-336-5189 [email protected]
KG6OMK


Need a vacation? Get great deals
to amazing places on Yahoo! Travel.

  1. I suppose numbersink2 is not in your particular gnuradio build.
    Checkout the trunk again.

  2. There is no config file when you first load GRC. When you close
    GRC, it will create the config file, and the error will be gone
    thereafter.

  3. Bus Error? I have no idea… There are no “un-intialized”
    variables. And the code that loads the preferences isnt printing this.
    It might be a weird GTK+OSX thing. Does GRC function otherwise?

-Josh

On 10/3/07, Michael D. [email protected] wrote:

Maybe it’s the use of python 2.5?

Has anyone (on this list, or if you know someone) ever used GRC on
OSX? As I said, I’ve never tried to until this morning.

This really isn’t my forte, but a quick search and I saw this page:

http://www.rexx.com/~dkuhlman/python_201/python_201.html#SECTION006600000000000000000

This seems to suggest that there may be a mismatch in what you have
installed versus what is running on the system? One thing is looking
for those source files where the source no longer comes with it.

Running gdb comes back with:

(gdb) run Editor.py
[snip]
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x0024ed8b in PyString_FromString (str=0x0) at Objects/stringobject.c:
108
108 Objects/stringobject.c: No such file or directory.
in Objects/stringobject.c

Brian

On 10/3/07, Michael D. [email protected] wrote:

Maybe it’s the use of python 2.5?

I think all of the ubuntu and fedora people have python 2.5.

Has anyone (on this list, or if you know someone) ever used GRC on
OSX? As I said, I’ve never tried to until this morning.

I have run GRC on a mac mini (x86), and used mac ports for the GNU
software. The only issue I had was getting the X server running.
Although, It has been a while since…

  1. I suppose numbersink2 is not in your particular gnuradio build.
    Checkout the trunk again.

Done. Nothing changed.

Maybe you have to make uninstall/rebuild or something, although it may
be an issue with the grc block def for number sink, I will check
later. At any rate, missing blocks are not a problem.

It might be a weird GTK+OSX thing. Does GRC function otherwise?

Running gdb comes back with:

(gdb) run Editor.py
[snip]

Yikes! I cant tell what that may be.

-Josh

On Wed, Oct 03, 2007 at 03:34:58PM -0400, Michael D. wrote:

  1. There is no config file when you first load GRC. When you close
    Running gdb comes back with:
    #0 0x0024ed8b in PyString_FromString (str=0x0) at Objects/
    fp=0x1b, buf=0xbfffa927 “/opt/local/lib/python2.5/site-packages/
    _xmlplus/parsers/pyexpat.so”, type=3, loader=0x0) at Python/import.c:
    1752

In the random stab in the dark department: I wonder if the problem is
in pyexpat.c, and whether it was compiled with -O1 optimization on the
PPC. (Somebody really ought to create a small test case for the gcc
guys and log a bug.)

Is there QA code for pyexpat and does it pass (make check?)

Eric

Maybe it’s the use of python 2.5?

Has anyone (on this list, or if you know someone) ever used GRC on
OSX? As I said, I’ve never tried to until this morning.

  1. I suppose numbersink2 is not in your particular gnuradio build.
    Checkout the trunk again.

Done. Nothing changed.

  1. There is no config file when you first load GRC. When you close
    GRC, it will create the config file, and the error will be gone
    thereafter.

OK. I went ahead and did “touch ~/.grc.xml”, which makes that
message go away. No change in execution.

  1. Bus Error? I have no idea… There are no “un-intialized”
    variables. And the code that loads the preferences isnt printing this.
    It might be a weird GTK+OSX thing. Does GRC function otherwise?

Running gdb comes back with:

(gdb) run Editor.py
[snip]
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x0024ed8b in PyString_FromString (str=0x0) at Objects/stringobject.c:
108
108 Objects/stringobject.c: No such file or directory.
in Objects/stringobject.c
(gdb) bt
#0 0x0024ed8b in PyString_FromString (str=0x0) at Objects/
stringobject.c:108
#1 0x002b8f84 in PyModule_AddStringConstant (m=0x9030490,
name=0x909a8d0 “XML_ERROR_UNBOUND_PREFIX”, value=0x0) at Python/
modsupport.c:630
#2 0x09092ea3 in initpyexpat () at extensions/pyexpat.c:1977
#3 0x002b40bb in _PyImport_LoadDynamicModule (name=0xbfffaddb
“xml.parsers.pyexpat”, pathname=0xbfffa927 "/opt/local/lib/python2.5/
site-packages/xmlplus/parsers/pyexpat.so", fp=0xa000bea8) at ./
Python/importdl.c:53
#4 0x002b1d9d in load_module (name=0xbfffaddb “xml.parsers.pyexpat”,
fp=0x1b, buf=0xbfffa927 "/opt/local/lib/python2.5/site-packages/
xmlplus/parsers/pyexpat.so", type=3, loader=0x0) at Python/import.c:
1752
#5 0x002b2267 in import_submodule (mod=0x90302f0, subname=0xbfffade7
“pyexpat”, fullname=0xbfffaddb “xml.parsers.pyexpat”) at Python/
import.c:2394
#6 0x002b24b5 in load_next (mod=0x90302f0, altmod=0x300aa0,
p_name=0xbfffade7, buf=0xbfffaddb “xml.parsers.pyexpat”,
p_buflen=0xbfffb1dc) at Python/import.c:2214
#7 0x002b2962 in import_module_level (name=0x0, globals=0x600120,
locals=0xffffffff, fromlist=0x9030370, level=-1) at Python/import.c:1995
#8 0x002b2e59 in PyImport_ImportModuleLevel (name=0x9030394
“pyexpat”, globals=0x90131e0, locals=0x90131e0, fromlist=0x9030370,
level=-1) at Python/import.c:2066
#9 0x0028dde3 in builtin___import
(self=0x0, args=0x902c7e0,
kwds=0x0) at Python/bltinmodule.c:47
#10 0x0020e744 in PyObject_Call (func=0xf4b8, arg=0x902c7e0, kw=0x0)
at Objects/abstract.c:1860
#11 0x00292a7e in PyEval_CallObjectWithKeywords (func=0xf4b8,
arg=0x902c7e0, kw=0x0) at Python/ceval.c:3433
#12 0x00296930 in PyEval_EvalFrameEx (f=0x91183d0, throwflag=0) at
Python/ceval.c:2063
#13 0x0029a1a8 in PyEval_EvalCodeEx (co=0x9031188, globals=0x90131e0,
locals=0x90131e0, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2831
#14 0x0029a35c in PyEval_EvalCode (co=0x9031188, globals=0x90131e0,
locals=0x90131e0) at Python/ceval.c:494
#15 0x002b118a in PyImport_ExecCodeModuleEx (name=0xbfffbf9b
“xml.parsers.expat”, co=0x9031188, pathname=0xbfffb68f "/opt/local/
lib/python2.5/site-packages/xmlplus/parsers/expat.pyc") at Python/
import.c:669
#16 0x002b15e0 in load_source_module (name=0xbfffbf9b
“xml.parsers.expat”, pathname=0xbfffb68f "/opt/local/lib/python2.5/
site-packages/xmlplus/parsers/expat.pyc", fp=0xa000be50) at Python/
import.c:953
#17 0x002b2267 in import_submodule (mod=0x90302f0, subname=0x901ced4
“expat”, fullname=0xbfffbf9b “xml.parsers.expat”) at Python/import.c:
2394
#18 0x002b2812 in ensure_fromlist (mod=0x90302f0, fromlist=0x7348af0,
buf=0xbfffbf9b “xml.parsers.expat”, buflen=11, recursive=0) at Python/
import.c:2305
#19 0x002b2be7 in import_module_level (name=0x0, globals=0x90302f0,
locals=0xffffffff, fromlist=0x7348af0, level=-1) at Python/import.c:2032
#20 0x002b2e59 in PyImport_ImportModuleLevel (name=0x902f50c
“xml.parsers”, globals=0x901b780, locals=0x901b780,
fromlist=0x7348af0, level=-1) at Python/import.c:2066
#21 0x0028dde3 in builtin___import
(self=0x0, args=0x902c780,
kwds=0x0) at Python/bltinmodule.c:47
#22 0x0020e744 in PyObject_Call (func=0xf4b8, arg=0x902c780, kw=0x0)
at Objects/abstract.c:1860
#23 0x00292a7e in PyEval_CallObjectWithKeywords (func=0xf4b8,
arg=0x902c780, kw=0x0) at Python/ceval.c:3433
#24 0x00296930 in PyEval_EvalFrameEx (f=0x9119060, throwflag=0) at
Python/ceval.c:2063
#25 0x0029a1a8 in PyEval_EvalCodeEx (co=0x9031140, globals=0x901b780,
locals=0x901b780, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2831
#26 0x0029a35c in PyEval_EvalCode (co=0x9031140, globals=0x901b780,
locals=0x901b780) at Python/ceval.c:494
#27 0x002b118a in PyImport_ExecCodeModuleEx (name=0xbfffd15b
“xml.dom.expatbuilder”, co=0x9031140, pathname=0xbfffc84f "/opt/local/
lib/python2.5/site-packages/xmlplus/dom/expatbuilder.pyc") at Python/
import.c:669
#28 0x002b15e0 in load_source_module (name=0xbfffd15b
“xml.dom.expatbuilder”, pathname=0xbfffc84f "/opt/local/lib/python2.5/
site-packages/xmlplus/dom/expatbuilder.pyc", fp=0xa000bdf8) at
Python/import.c:953
#29 0x002b2267 in import_submodule (mod=0x76d5f0, subname=0x444de1c
“expatbuilder”, fullname=0xbfffd15b “xml.dom.expatbuilder”) at Python/
import.c:2394
#30 0x002b2812 in ensure_fromlist (mod=0x76d5f0, fromlist=0x4450cd0,
buf=0xbfffd15b “xml.dom.expatbuilder”, buflen=7, recursive=0) at
Python/import.c:2305
#31 0x002b2be7 in import_module_level (name=0x0, globals=0x76d5f0,
locals=0xffffffff, fromlist=0x4450cd0, level=-1) at Python/import.c:2032
#32 0x002b2e59 in PyImport_ImportModuleLevel (name=0x4324af4
“xml.dom”, globals=0x443f5d0, locals=0x300aa0, fromlist=0x4450cd0,
level=-1) at Python/import.c:2066
#33 0x0028dde3 in builtin___import
(self=0x0, args=0x44601e0,
kwds=0x0) at Python/bltinmodule.c:47
#34 0x0020e744 in PyObject_Call (func=0xf4b8, arg=0x44601e0, kw=0x0)
at Objects/abstract.c:1860
#35 0x00292a7e in PyEval_CallObjectWithKeywords (func=0xf4b8,
arg=0x44601e0, kw=0x0) at Python/ceval.c:3433
#36 0x00296930 in PyEval_EvalFrameEx (f=0x9117fb0, throwflag=0) at
Python/ceval.c:2063
#37 0x0029a1a8 in PyEval_EvalCodeEx (co=0x4452188, globals=0x443f5d0,
locals=0x0, args=0x9117f90, argcount=1, kws=0x9117f94, kwcount=0,
defs=0x431c564, defcount=2, closure=0x0) at Python/ceval.c:2831
#38 0x00297a7d in PyEval_EvalFrameEx (f=0x9117e50, throwflag=0) at
Python/ceval.c:3660
#39 0x002999a4 in PyEval_EvalFrameEx (f=0x9117ce0, throwflag=0) at
Python/ceval.c:3650
#40 0x0029a1a8 in PyEval_EvalCodeEx (co=0x9018218, globals=0x9019e40,
locals=0x0, args=0x9102904, argcount=1, kws=0x9102908, kwcount=0,
defs=0x901c53c, defcount=1, closure=0x0) at Python/ceval.c:2831
#41 0x00297a7d in PyEval_EvalFrameEx (f=0x91027b0, throwflag=0) at
Python/ceval.c:3660
#42 0x0029a1a8 in PyEval_EvalCodeEx (co=0x8118e30, globals=0x818f9c0,
locals=0x0, args=0x734b0b4, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2831
#43 0x0022fa03 in function_call (func=0x9022030, arg=0x734b0a8,
kw=0x0) at Objects/funcobject.c:517
#44 0x0020e744 in PyObject_Call (func=0x9022030, arg=0x734b0a8,
kw=0x0) at Objects/abstract.c:1860
#45 0x002163b1 in instancemethod_call (func=0x9020f58, arg=0x4324670,
kw=0x0) at Objects/classobject.c:2497
#46 0x0020e744 in PyObject_Call (func=0x9020f58, arg=0x4324670,
kw=0x0) at Objects/abstract.c:1860
#47 0x0025bb2d in slot_tp_init (self=0x9020f30, args=0x4324670,
kwds=0x0) at Objects/typeobject.c:4862
#48 0x0025de4d in type_call (type=0x9102280, args=0x4324670,
kwds=0x0) at Objects/typeobject.c:436
#49 0x0020e744 in PyObject_Call (func=0x9102280, arg=0x4324670,
kw=0x0) at Objects/abstract.c:1860
#50 0x00295d1d in PyEval_EvalFrameEx (f=0x65a2ad0, throwflag=0) at
Python/ceval.c:3775
#51 0x0029a1a8 in PyEval_EvalCodeEx (co=0x433fe30, globals=0x734c420,
locals=0x0, args=0x73460dc, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2831
#52 0x0022fa03 in function_call (func=0x9022530, arg=0x73460d0,
kw=0x0) at Objects/funcobject.c:517
#53 0x0020e744 in PyObject_Call (func=0x9022530, arg=0x73460d0,
kw=0x0) at Objects/abstract.c:1860
#54 0x002163b1 in instancemethod_call (func=0x430fe68, arg=0x68150,
kw=0x0) at Objects/classobject.c:2497
#55 0x0020e744 in PyObject_Call (func=0x430fe68, arg=0x68150, kw=0x0)
at Objects/abstract.c:1860
#56 0x00292a7e in PyEval_CallObjectWithKeywords (func=0x430fe68,
arg=0x68150, kw=0x0) at Python/ceval.c:3433
#57 0x00218892 in PyInstance_New (klass=0x9021570, arg=0x68150,
kw=0x0) at Objects/classobject.c:560
#58 0x0020e744 in PyObject_Call (func=0x9021570, arg=0x68150, kw=0x0)
at Objects/abstract.c:1860
#59 0x00295d1d in PyEval_EvalFrameEx (f=0x60ed60, throwflag=0) at
Python/ceval.c:3775
#60 0x0029a1a8 in PyEval_EvalCodeEx (co=0x44f50, globals=0x20d20,
locals=0x20d20, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2831
#61 0x0029a35c in PyEval_EvalCode (co=0x44f50, globals=0x20d20,
locals=0x20d20) at Python/ceval.c:494
#62 0x002bd5cc in PyRun_FileExFlags (fp=0xa000bda0,
filename=0xbffff2d3 “Editor.py”, start=257, globals=0x20d20,
locals=0x20d20, closeit=1, flags=0xbffff0ec) at Python/pythonrun.c:1271
#63 0x002bd966 in PyRun_SimpleFileExFlags (fp=0xa000bda0,
filename=0xbffff2d3 “Editor.py”, closeit=1, flags=0xbffff0ec) at
Python/pythonrun.c:877
#64 0x002cb082 in Py_Main (argc=1, argv=0xbffff16c) at Modules/main.c:
523
#65 0x00001f8e in ?? ()
#66 0x00001eb5 in ?? ()

On Oct 3, 2007, at 4:11 PM, Eric B. wrote:

In the random stab in the dark department: I wonder if the problem is
in pyexpat.c, and whether it was compiled with -O1 optimization on the
PPC. (Somebody really ought to create a small test case for the gcc
guys and log a bug.)

Indeed that would be useful, but I don’t think it’s the issue here.
There’s something else going on. I can run python then do “import
xml.parsers.expat” and that works just fine (as does “import
xml.parsers.pyexpat” and the others in that directory).

Is there QA code for pyexpat and does it pass (make check?)

No idea.

It is annoying that Python 2.5 contains the expat library, version
2.0.0. latest release if installed separately is 2.0.1. There is no
reason why Python needs to contain the source for this library unless
they changed it … anyway, that’s a bit OT.

Michael D. wrote:

I downloaded grc-0.65 (stable) and grc-0.69 (stable). The former (using
Run.py) brings up a window and looks to be working; there are no "bus
error"s. The latter (using Editor.py, and after removing the “gtk”
check) works as well. Both of these were tested using the exact same
Python install. Thus the bug seems to be in GRC itself, not in my
MacPorts install. - MLD

The test import of gtk (in 0.69) was also a problem on a debian system
(no bus error, just some import issues). I removed the “gtk” check from
the GRC trunk a week or so ago.

In your initial email, you had the bus error, but the test “gtk” import
would not have been present because the trunk was checked out that
morning.

Can you confirm this, that the trunk still “bus errors” without the gtk
test import? Maybe there is a “new” error prone thing that has been
introduced into GRC between the release of 0.69 and the current trunk.

-Josh

I downloaded grc-0.65 (stable) and grc-0.69 (stable). The former
(using Run.py) brings up a window and looks to be working; there are
no "bus error"s. The latter (using Editor.py, and after removing the
“gtk” check) works as well. Both of these were tested using the
exact same Python install. Thus the bug seems to be in GRC itself,
not in my MacPorts install. - MLD

grc-0.69 does NOT work using “./Editor.py” … I had bypassed the
checking incorrectly. My bad.

Here is something that might help. In the latest trunk, if I do:

cd src
python

from ActionHandler import ActionHandler
ActionHandler ("")

WX is only used with the wxgui stuff. GRC can would function fine
without WX, or the wxgui blocks. And flow graphs can be run in a non
graphical mode.

Basically, the test imports are all things that the Editor uses. gtk,
pyxml… and wx for running the flow graphs. I decided on the “import
tests” after many emails of error verbose because something like pyxml
was not installed. Thoughts?


I dont know how to just inspect the python environment to “see” if a
module exists, without importing it (or possibly doing something messy
with PYTHONPATH).

Perhaps we can still fix this situation by deleting the module from
sys.modules after each test import. With the GRC trunk, as is: can you
try and change Editor.py and see if it runs:

try: import(module)

------to--------

try:
import(module)
sys.modules.pop(module) #of course, import sys at the top

Improvement?
-Josh

Michael D. wrote:

import xml.parsers.pyexpat


Good lord…

On Oct 4, 2007, at 12:35 AM, Josh B. wrote:

Basically, the test imports are all things that the Editor uses.
gtk, pyxml… and wx for running the flow graphs. I decided on the
“import tests” after many emails of error verbose because something
like pyxml was not installed. Thoughts?

I’m 100% with you on these import checks. It’s “easier” on the user
to hear that “such and such module isn’t installed” instead of
getting some whacky Python error that doesn’t really help.

try:
import(module)
sys.modules.pop(module) #of course, import sys at the top

No difference. I also tried just “del” as well as “del sys.modules
(module)”, neither of which worked.

I’m using WX 2.8.4 currently, so I’m trying downgrading to 2.6.3 as
well as upgrading to 2.8.6. I’m open to any other suggestions as
well. - MLD

Does GRC using WX for anything until running a flow-graph? I assume
it’s included because of the scopes and such in gr-wxgui? I tried
running some of the examples, and they bring up the WX GUI scopes
just fine.

If I remove ‘wx’ from the modules check list in Editor.py, then GRC
brings up its GUI. Quite strange. If I try:

python

import wx
import xml.parsers.pyexpat


then I get the bus error. Obviously Python has issues with the
combined WX and xml.parsers.pyexpat, but I truly know not why. This
doesn’t happen with any other modules that are used by GRC, at least
in my quick checking.

Thus I retract my belief that it’s a GRC issue … 0.65 didn’t do the
import modules check, which is why it “works”.

I’m using WX 2.8.4 currently, so I’m trying downgrading to 2.6.3 as
well as upgrading to 2.8.6. I’m open to any other suggestions as
well.

2.6.3 and 2.8.6 work. So it was something to do with WX 2.8.4. Go
figure … !@#$% OSS !} Thanks for all of the help. Now on to the
“real” work. - MLD