[ python-Bugs-1557232 ] Parser crash
Bugs item #1557232, was opened at 2006-09-12 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 00:44 Message: Logged In: YES user_id=33168 I think patch v2 might fix both problems. I'm not sure it's correct. We really need a lot of tests for this stuff. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:22 Message: Logged In: YES user_id=33168 The attached patch seems to fix the x problem. I didn't run in debug mode, so I'm not positive the assert works as I expect. However now my test case below doesn't work, it puts in 5 UNPACK_SEQUENCES rather than 3. This looks like a different problem in compiler_complex_args(). Not sure how much farther I'll get tonight. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:00 Message: Logged In: YES user_id=33168 I guess what 2.4 does is the most reasonable behavior: >>> def f((x)),),),)): pass >>> dis.dis(f) 1 0 LOAD_FAST0 (.0) 3 UNPACK_SEQUENCE 1 6 UNPACK_SEQUENCE 1 9 UNPACK_SEQUENCE 1 12 STORE_FAST 1 (x) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-779460 ] plistlib should be moved out of plat-mac
Bugs item #779460, was opened at 2003-07-29 11:01 Message generated for change (Comment added) made by guidog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Sarwat Khan (sarwatfoo) Assigned to: Nobody/Anonymous (nobody) Summary: plistlib should be moved out of plat-mac Initial Comment: plistlib doesn't (I think, it shouldn't anyway) have any Mac dependancies and should be moved out of plat-mac so plists can be generated and parsed on non-Mac platforms. I intend to use it, for example, on a Linux web server in CGI scripts for basic XML handling. -- Comment By: Guido Guenther (guidog) Date: 2006-09-13 15:12 Message: Logged In: YES user_id=696207 Can this be done for python 2.5 please. It's need to run apple's caldav server on e.g. Linux. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779460&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557983 ] xlc 6 does not like bufferobject.c line22
Bugs item #1557983, was opened at 2006-09-13 15:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557983&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: prueba uno (pruebauno)
Assigned to: Nobody/Anonymous (nobody)
Summary: xlc 6 does not like bufferobject.c line22
Initial Comment:
The VisualAge 6 Compiler on AIX complains about the
extra comma on line 22 of bufferobject. Doing the
following change keeps the compiler happy.
enum buffer_t {
READ_BUFFER,
WRITE_BUFFER,
CHAR_BUFFER,
-ANY_BUFFER,
};
enum buffer_t {
READ_BUFFER,
WRITE_BUFFER,
CHAR_BUFFER,
+ANY_BUFFER
};
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557983&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557983 ] xlc 6 does not like bufferobject.c line22
Bugs item #1557983, was opened at 2006-09-13 17:32
Message generated for change (Comment added) made by sjoerd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557983&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: prueba uno (pruebauno)
Assigned to: Nobody/Anonymous (nobody)
Summary: xlc 6 does not like bufferobject.c line22
Initial Comment:
The VisualAge 6 Compiler on AIX complains about the
extra comma on line 22 of bufferobject. Doing the
following change keeps the compiler happy.
enum buffer_t {
READ_BUFFER,
WRITE_BUFFER,
CHAR_BUFFER,
-ANY_BUFFER,
};
enum buffer_t {
READ_BUFFER,
WRITE_BUFFER,
CHAR_BUFFER,
+ANY_BUFFER
};
--
>Comment By: Sjoerd Mullender (sjoerd)
Date: 2006-09-13 17:49
Message:
Logged In: YES
user_id=43607
That's a bug in the compiler, not in Python. The C standard
has:
enum-specifier:
enum identifieropt { enumerator-list }
enum identifieropt { enumerator-list , }
enum identifier
enumerator-list:
enumerator
enumerator-list , enumerator
enumerator:
enumeration-constant
enumeration-constant = constant-expression
From the first production you can see that the comma at the
end is allowed. This has been true since at least 1980.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557983&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557490 ] 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc
Bugs item #1557490, was opened at 2006-09-12 17:36 Message generated for change (Comment added) made by tony_bigbee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Bigbee (tony_bigbee) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Initial Comment: Building with gcc 4.1.1 SunOS 5.9 sun4u sparc SUNW,Sun-Fire-V490 LDFLAGS=-mcpu=v9 -m64 LDDFLAGS=-mcpu=v9 -m64 -G CC=gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1 ./configure --prefix=/projects/python make (many successful .c files omittted) gcc -mcpu Parser/pgenmain.o -lresolv -lsocket -lnsl -lrt -ldl -o Parser/pgen Parser/pgen ./Grammar/grammar ./Include/graminit.h ./Python/graminit.c *** Signal 11 -core dumped (ignored) compiling and linking continues until the new python executable is invoked to run setup.py and that fails. I previously built 2.5c1 without all the compile/link flags above as a vanilla 32-bit app without a problem. LD_LIBRARY=/usr/ccs/lib/:/usr/lib:/usr/local/lib the python executable will not start with any command line option. -- >Comment By: Tony Bigbee (tony_bigbee) Date: 2006-09-13 11:50 Message: Logged In: YES user_id=1478976 I have confirmed that gcc 3.4.2 also successfully builds an ELF 64-bit for 2.5c2 and the interpreter works. Putting the sparcv9 64-bit shared libraries first in LD_LIBRARY_PATH also fixes the extension building problem nnorwitz noted. Only a few extension modules fail to build (per the 2.5 Release Candidate 2 news item) because of dependence of 32-bit ELF class .sos: _tkinter (libtk8.4.so, libtcl8.4.so) _sqlite3 (libsqlite3.so) _ssl ((libcrypto.a(digest.o)) _hashlib (libcrypto.a(digest.o)) bz2 (libbz2.a(bzlib.o)) But this might be fixed by recompiling these libraries as 64-bit. LD_LIBRARY_PATH=/usr/lib/sparcv9:/usr/local/lib/sparcv9: ... Will report back results attempting 4.0.2 and LD_LIBRARY_PATH modification to see if extension modules can be built to mirror 3.4.2 results. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 01:47 Message: Logged In: YES user_id=33168 I was able to build with gcc 4.0.2 on Solaris sun4u system with the same flags as above. ./python: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped However, it couldn't build the extension modules because: ld.so.1: python: fatal: libgcc_s.so.1: open failed: No such file or directory That's a different problem though. The interpreter itself is just fine. You might want to try lowering the optimization level to -O1 or -O0 and see if you have the same problem. Or you could try building with a different C compiler. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1558072 ] 'setup.py install' crashes when installing python-bibtex
Bugs item #1558072, was opened at 2006-09-13 19:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558072&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matejcik (spektrum) Assigned to: Nobody/Anonymous (nobody) Summary: 'setup.py install' crashes when installing python-bibtex Initial Comment: when installing python-bibtex (http://sourceforge.net/project/showfiles.php?group_id=4825&package_id=93590&release_id=361584) , python crashes as follows: titan:/tmp/python-bibtex-1.2.2# python setup.py install running install running check running build running build_ext *** glibc detected *** python: munmap_chunk(): invalid pointer: 0xb7c530b0 *** === Backtrace: = /lib/libc.so.6[0xb7d379e2] /tmp/python-bibtex-1.2.2/build/lib.linux-i686-2.5/_bibtex.so[0xb7839f15] /usr/lib/libpython2.5.so.1.0[0xb7e737ea] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x473)[0xb7ecf393] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCode+0x63)[0xb7ecf763] /usr/lib/libpython2.5.so.1.0[0xb7ee7ad6] /usr/lib/libpython2.5.so.1.0(PyRun_FileExFlags+0x8e)[0xb7ee7b8e] /usr/lib/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0x198)[0xb7ee9218] /usr/lib/libpython2.5.so.1.0(PyRun_AnyFileExFlags+0x7a)[0xb7ee997a] /usr/lib/libpython2.5.so.1.0(Py_Main+0xa23)[0xb7ef2e13] python(main+0x32)[0x80485f2] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7ce987c] python[0x8048531] === Memory map: Neúspěšně ukončen (SIGABRT) (This is after 'python setup.py build' successfully finished) Machine is i386, python is compiled with -D_FORTIFY_SOURCE -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558072&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552892 ] ConfigParser converts option names to lower case on set()
Bugs item #1552892, was opened at 2006-09-05 11:35
Message generated for change (Comment added) made by suslik
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552892&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: daniel (suslik)
Assigned to: Nobody/Anonymous (nobody)
Summary: ConfigParser converts option names to lower case on set()
Initial Comment:
Python 2.4.2
Using set() in ConfigParser module converts all
characters in option names to lower case.
To reproduce:
>>> import ConfigParser
>>> cfg = ConfigParser.ConfigParser()
>>> cfg.add_section('SectioN')
>>> cfg.set('SectioN','OpTiOn","ValuE')
>>> cfg.items('SectioN')
[('option', 'ValuE')]
--
>Comment By: daniel (suslik)
Date: 2006-09-13 11:55
Message:
Logged In: YES
user_id=633916
Hmm, "broken" behavior by-design or not - it still makes it
impossible to use ConfigParser straight out in KDE, where
almost all option names are AaaaBbbbCccc.
I just went with a completely different parser.
http://wiki.python.org/moin/ConfigParserShootout
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-09-05 22:53
Message:
Logged In: YES
user_id=849994
Mark is correct. This is not a bug.
--
Comment By: Mark Roberts (mark-roberts)
Date: 2006-09-05 20:30
Message:
Logged In: YES
user_id=1591633
I can reproduce this on Win XP, Python 2.4, however, it
doesn't seem to be a bug.
In the docs
(http://docs.python.org/lib/module-ConfigParser.html), it
states that
"All option names used in interpolation will be passed
through the optionxform() method just like any other option
name reference. For example, using the default
implementation of optionxform() (which converts option names
to lower case), the values "foo %(bar)s" and "foo %(BAR)s"
are equivalent."
You might consider subclassing if this is an inconvenience
for you.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552892&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1558223 ] apache2 - mod_python - python2.4 core dump
Bugs item #1558223, was opened at 2006-09-14 00:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Nobody/Anonymous (nobody) Summary: apache2 - mod_python - python2.4 core dump Initial Comment: $ gdb bin/httpd GNU gdb 6.0 Copyright 2003 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 "sparc-sun-solaris2.8"... (gdb) core core Core was generated by `/usr/local/bin/httpd -k restart'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/local/lib/libssl.so.0.9.8 <... deleted the whole loaded libraries> #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 (gdb) bt #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 #1 0xfda6ac4c in PyString_FromString ( str=0xfef65ec0 "unexpected parser state - please send a bug report") at Objects/stringobject.c:106 #2 0xfdac9b50 in PyModule_AddStringConstant (m=0x594cd0, name=0xfe5a5478 "XML_ERROR_ENTITY_DECLARED_IN_PE", value=0x0) at Python/modsupport.c:589 #3 0xfe57cec4 in initpyexpat () at /usr/local/Python-2.4.3/Modules/pyexpat.c:1973 this happens when running moinmoin 1.5.4, and doing a gui-edit. mod_python-3.2.10, httpd-2.2.3, solaris 8, compile with gcc-3.4.6. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1558223 ] apache2 - mod_python - python2.4 core dump
Bugs item #1558223, was opened at 2006-09-13 15:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Nobody/Anonymous (nobody) Summary: apache2 - mod_python - python2.4 core dump Initial Comment: $ gdb bin/httpd GNU gdb 6.0 Copyright 2003 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 "sparc-sun-solaris2.8"... (gdb) core core Core was generated by `/usr/local/bin/httpd -k restart'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/local/lib/libssl.so.0.9.8 <... deleted the whole loaded libraries> #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 (gdb) bt #0 0xfebb3218 in strlen () from /usr/lib/libc.so.1 #1 0xfda6ac4c in PyString_FromString ( str=0xfef65ec0 "unexpected parser state - please send a bug report") at Objects/stringobject.c:106 #2 0xfdac9b50 in PyModule_AddStringConstant (m=0x594cd0, name=0xfe5a5478 "XML_ERROR_ENTITY_DECLARED_IN_PE", value=0x0) at Python/modsupport.c:589 #3 0xfe57cec4 in initpyexpat () at /usr/local/Python-2.4.3/Modules/pyexpat.c:1973 this happens when running moinmoin 1.5.4, and doing a gui-edit. mod_python-3.2.10, httpd-2.2.3, solaris 8, compile with gcc-3.4.6. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 20:34 Message: Logged In: YES user_id=33168 Please file this bug report with mod_python. That's typically the cause and it will likely be very hard for any Python developer to create this setup and much less try to reproduce the error. If you can provoke the same error without mod_python or other third party C extensions, please file a bug report with the minimal test case to reproduce. If you need a work-around, I would suggest changing to a different version of mod_python. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1558072 ] 'setup.py install' crashes when installing python-bibtex
Bugs item #1558072, was opened at 2006-09-13 10:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558072&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matejcik (spektrum) Assigned to: Nobody/Anonymous (nobody) Summary: 'setup.py install' crashes when installing python-bibtex Initial Comment: when installing python-bibtex (http://sourceforge.net/project/showfiles.php?group_id=4825&package_id=93590&release_id=361584) , python crashes as follows: titan:/tmp/python-bibtex-1.2.2# python setup.py install running install running check running build running build_ext *** glibc detected *** python: munmap_chunk(): invalid pointer: 0xb7c530b0 *** === Backtrace: = /lib/libc.so.6[0xb7d379e2] /tmp/python-bibtex-1.2.2/build/lib.linux-i686-2.5/_bibtex.so[0xb7839f15] /usr/lib/libpython2.5.so.1.0[0xb7e737ea] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x473)[0xb7ecf393] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x55bb)[0xb7ece03b] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x528e)[0xb7ecdd0e] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x7c4)[0xb7ecf6e4] /usr/lib/libpython2.5.so.1.0(PyEval_EvalCode+0x63)[0xb7ecf763] /usr/lib/libpython2.5.so.1.0[0xb7ee7ad6] /usr/lib/libpython2.5.so.1.0(PyRun_FileExFlags+0x8e)[0xb7ee7b8e] /usr/lib/libpython2.5.so.1.0(PyRun_SimpleFileExFlags+0x198)[0xb7ee9218] /usr/lib/libpython2.5.so.1.0(PyRun_AnyFileExFlags+0x7a)[0xb7ee997a] /usr/lib/libpython2.5.so.1.0(Py_Main+0xa23)[0xb7ef2e13] python(main+0x32)[0x80485f2] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7ce987c] python[0x8048531] === Memory map: Neúspěšně ukončen (SIGABRT) (This is after 'python setup.py build' successfully finished) Machine is i386, python is compiled with -D_FORTIFY_SOURCE -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-13 20:39 Message: Logged In: YES user_id=33168 I notice the second to last stack frame is in _bibtex.so. Please file a bug report with python-bibtex. If you can verify the problem doesn't occur with any third party C extensions, please create a bug with a minimal test case. This should be much easier for a python-bibtex developer to debug than a Python developer. It's typically also the case that these sorts of problems are in third party extensions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558072&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
