
Evening all, This is my first time posting to the dev list so, as the email instructed, I'll introduce myself. My name is Geoffrey Biggs and I'm a PhD student at the University of Auckland in New Zealand working on some specialised programming language concepts. I'm implementing my ideas in Python to prove they work (or don't work, as the case may be). Apologies in advance for posting something to the python-dev list that isn't directly about improving the standard Python, but I figured this is the place where the people who know what I'm asking about and might know the answer would best be found and it doesn't seem to fit in python-help's description. I'm trying to add a new built-in number data type to Python with its own syntax, so I'm working directly with the interpreter rather than creating my own extension module (side note: I've appended something extra to the version thing in the Makefile - I doubt this is relevant to the problem but it's probably best you have all the info). The complex data type is similar to what I'm trying to do so I've been following that as an example. I've successfully extended the tokenizer and the parsenumber() function in compile.c to do what I want and written the data type in my two new files Objects/mynewobject.c and Include/mynewobject.h. I've included mynewobject.h in Python.h and added the two files to the Makefile. However, when I tried to run the code by typing in the syntax to produce my data type, Python suffers a segmentation fault. I traced this to an attempt to get the hash of a null pointer when adding the new instance of my type after parsenumber() was called. For completeness, here's the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x08080e9a in PyObject_Hash (v=0x81486c0) at Objects/object.c:1162 1162 if (tp->tp_hash != NULL) (gdb) bt #0 0x08080e9a in PyObject_Hash (v=0x81486c0) at Objects/object.c:1162 #1 0x0808e199 in tuplehash (v=0x40324574) at Objects/tupleobject.c:244 #2 0x08080eae in PyObject_Hash (v=0x40324574) at Objects/object.c:1163 #3 0x0807b46c in PyDict_GetItem (op=0x40319c14, key=0x40324574) at Objects/dictobject.c:492 #4 0x080c72c7 in com_add (c=0xbfffed60, list=0x40326114, dict=0x40319c14, v=0x40326290) at Python/compile.c:975 #5 0x080c74ac in com_addconst (c=0xbfffed60, v=0x40326290) at Python/compile.c:1001 #6 0x080c90e3 in com_atom (c=0xbfffed60, n=0x4028d500) at Python/compile.c:1689 The crash appears to be caused because while v exists, v's members are all 0 and so tp becomes 0 and you get a NULL pointer exception. As far as I can tell, this v is the second object in the tuple created in com_add() and is supposed to be the type of the object being added to the dictionary in a tuple. Not knowing why it was coming out as zero, I did some more poking around (been doing a lot of that over the past 5 days...) and found that there is a file called bltinmodule.c with a bunch of lines, one of which mentions the complex data type that I am using as a guide: SETBUILTIN("complex", &PyComplex_Type); So I made one of these for mynewobject and added it. I figured from this bit of code that the reason I was getting NULL pointer exceptions was because my type hadn't been initialised in some way and that this would do it. But here's the problem: despite trying for longer than I've slept in the past week, I can't get it to compile. It always produces the following error (after the linker step that produces the python executable completes): case $MAKEFLAGS in \ *-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-g -Wall -Wstrict-prototypes -D__SAMMY_EXT__' ./python -E ./setup.py -q build;; \ *) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-g -Wall -Wstrict-prototypes -D__SAMMY_EXT__' ./python -E ./setup.py build;; \ esac make: *** [sharedmods] Error 139 Running the python executable doesn't work either, it starts and then segfaults immediatly with the backtrace indicating it dies trying to build the os module (which probably didn't get built). I haven't been able to figure out why this is happening. If I comment out the SETBUILTIN line I added it will compile fine but then I go back to the first problem. The only thing I found in google with this error was someone who was having trouble with a raw python source, and in that case it was a problem trying to build the ssl extension. I have structured my object identically to the complex object, which works. So the question (finally) is, what's broken? What have I missed? My best guess is only that I've broken the interpreter somehow by missing something with my object implementation and this is affecting that step of the make process. (This mess is all happening on Linux tillinshir 2.6.7-gentoo-r11-gb #1 Wed Aug 4 11:13:14 NZST 2004 i686 mobile AMD Athlon(tm) XP 2000+ AuthenticAMD GNU/Linux, if that matters.) Thanks in advance, Geoff Biggs

On Thu, Aug 19, 2004, Geoffrey Biggs wrote:
I'm trying to add a new built-in number data type to Python with its own syntax, so I'm working directly with the interpreter rather than creating my own extension module (side note: I've appended something extra to the version thing in the Makefile - I doubt this is relevant to the problem but it's probably best you have all the info). The complex data type is similar to what I'm trying to do so I've been following that as an example. I've successfully extended the tokenizer and the parsenumber() function in compile.c to do what I want and written the data type in my two new files Objects/mynewobject.c and Include/mynewobject.h. I've included mynewobject.h in Python.h and added the two files to the Makefile. However, when I tried to run the code by typing in the syntax to produce my data type, Python suffers a segmentation fault.
Unless you're planning to attempt pushing this into the core at some point in the future, you're best off asking on comp.lang.python; although some of the core developers no longer have time for c.l.py, they're also not likely to answer your questions here, either. ;-) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --reddy@lion.austin.ibm.com
participants (2)
-
Aahz
-
Geoffrey Biggs