[Python-Dev] Tests failing in MacPython 2.2.2

[Barry A. Warsaw]

>>>>> "BAW" == Barry A Warsaw <barry@python.org> writes:

    BAW> Oops, looks like I'm also getting a segfault in test_re.

Let's see if cut-n-paste works.  This is under gdb on OSX 10.2 with a
simple "configure; make".  Jack, you're not seeing this are you?
-Barry

@freewill[~/Desktop/src/python22:217]% gdb python.exe
GNU gdb 5.1-20020408 (Apple version gdb-231) (Tue Aug 13 21:37:39 GMT 2002)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-macos10".
Reading symbols for shared libraries .... done
(gdb) run Lib/test/test_re.py
Starting program: /Users/barry/Desktop/src/python22/python.exe Lib/test/test_re.py
[Switching to process 5135 thread 0xb03]
Reading symbols for shared libraries ............. done
Reading symbols for shared libraries . done
Running tests on re.search and re.match
Running tests on re.sub
Running tests on symbolic references
Running tests on re.subn
Running tests on re.split
Running tests on re.findall
Running tests on re.match
Running tests on re.escape
Pickling a RegexObject instance
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Test engine limitations

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0009cfb8 in mark_save (state=0xbffff1c0, lo=1, hi=1) at Modules/_sre.c:290
290     {
(gdb) where
#0  0x0009cfb8 in mark_save (state=0xbffff1c0, lo=1, hi=1) at Modules/_sre.c:290
#1  0x0009c168 in sre_match (state=0xbffff240, pattern=0x3ea47a, level=4068) at Modules/_sre.c:1070
[... lots of frames in sre_match ... ]
#4067 0x0009c0b8 in sre_match (state=0xbffff240, pattern=0x3ea466, level=1) at Modules/_sre.c:1026
#4068 0x0009e928 in pattern_match (self=0x3ea440, args=0x0, kw=0x1) at Modules/_sre.c:1694
#4069 0x000591c0 in PyObject_Call (func=0xbffff240, arg=0x0, kw=0x1) at Objects/abstract.c:1688
#4070 0x00074c4c in do_call (func=0x3ea050, pp_stack=0xbffff6b4, na=1, nk=1528) at Python/ceval.c:3271
#4071 0x000725e0 in eval_frame (f=0x3ba3b0) at Python/ceval.c:2009
#4072 0x00073a50 in PyEval_EvalCodeEx (co=0x386cb0, globals=0x0, locals=0x1, args=0x3ba50c, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=1, closure=0x0) at Python/ceval.c:2595
#4073 0x00074b30 in fast_function (func=0xbffff240, pp_stack=0x54, n=1, na=4104272, nk=1) at Python/ceval.c:3170
#4074 0x000726fc in eval_frame (f=0x3ba3b0) at Python/ceval.c:2034
#4075 0x00073a50 in PyEval_EvalCodeEx (co=0x386cb0, globals=0x0, locals=0x1, args=0x3ba50c, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595
#4076 0x00076574 in PyEval_EvalCode (co=0xbffff240, globals=0x0, locals=0x1) at Python/ceval.c:481
#4077 0x0002a650 in run_node (n=0x3ba50c, filename=0x0, globals=0x39bab2, locals=0x1, flags=0x9bad0) at Python/pythonrun.c:1079
#4078 0x00029dfc in PyRun_SimpleFileExFlags (fp=0xa0006950, filename=0xbffffcd5 "Lib/test/test_re.py", closeit=1, flags=0x386cb0) at Python/pythonrun.c:685
#4079 0x00006344 in Py_Main (argc=-2013265336, argv=0xbffffbe8) at Modules/main.c:364
#4080 0x00002254 in _start (argc=2, argv=0xbffffbe8, envp=0xbffffbf4) at /SourceCache/Csu/Csu-45/crt.c:267
#4081 0x000020d4 in start ()

Yes, that stack trace is that deep.
-Barry