[Python-Dev] Possible error in Python 2.4 garbage collector (original) (raw)
Moritz Mühlenhoff muehlenhoff at univention.de
Mon Nov 26 11:57:44 CET 2007
- Previous message: [Python-Dev] test_doctest failing
- Next message: [Python-Dev] Possible error in Python 2.4 garbage collector
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi, we're running into a problem with the Python interpreter, which we suspect triggers a bug in the garbage collector or a related part of the memory management. We are using Python 2.4.4 in the version from Debian 4.0.
Our C application imports various Python plugins using PyNode_Compile(). This used to work very well (it's a feature we've been using for years now), but if we import more than 23 modules we're running a segmentation fault with the backtrace below:
(gdb) bt #0 0xb7ee9cad in visit_decref (op=0xb7287ec0, data=0x0) at ../Modules/gcmodule.c:269 #1 0xb7e716d1 in list_traverse (o=0xb724e62c, visit=0xb7ee9ca0 , arg=0x0) at ../Objects/listobject.c:2280 #2 0xb7eea729 in collect (generation=0) at ../Modules/gcmodule.c:294 #3 0xb7eeb0a3 in _PyObject_GC_Malloc (basicsize=20) at ../Modules/gcmodule.c:872 #4 0xb7eeb0eb in _PyObject_GC_NewVar (tp=0xb7f25720, nitems=2) at ../Modules/gcmodule.c:1283 #5 0xb7e913e4 in PyTuple_New (size=2) at ../Objects/tupleobject.c:68 #6 0xb7e91bb5 in PyTuple_Pack (n=2) at ../Objects/tupleobject.c:143 #7 0xb7ebfded in com_add (c=0xbfc5d3ac, list=0x0, dict=0xb7ee9ca0, v=0xb770fc20) at ../Python/compile.c:1375 #8 0xb7ec4b1e in com_addop_varname (c=0xbfc5d3ac, kind=0, name=0xb71f9218 "new") at ../Python/compile.c:1410 #9 0xb7ecea53 in com_atom (c=0xbfc5d3ac, n=0xb71f8ca0) at ../Python/compile.c:2213 #10 0xb7ecefe0 in com_power (c=0x70732f72, n=0xb71fb5c0) at ../Python/compile.c:2587 #11 0xb7ecf4c3 in com_term (c=0x70732f72, n=0xb71fb590) at ../Python/compile.c:2727 #12 0xb7ecf639 in com_shift_expr (c=0xbfc5d3ac, n=0xb71fb560) at ../Python/compile.c:2762 #13 0xb7ecf924 in com_xor_expr (c=0x70732f72, n=0xb71fb530) at ../Python/compile.c:2814 #14 0xb7ec5064 in com_comparison (c=0x70732f72, n=0xb71fb2a8) at ../Python/compile.c:2858 #15 0xb7ec5e5a in com_test (c=0xbfc5d3ac, n=0xb71f8714) at ../Python/compile.c:2986 #16 0xb7eca88a in com_if_stmt (c=0xbfc5d3ac, n=0xb71fb278) at ../Python/compile.c:3844 #17 0xb7ec9101 in com_node (c=0xbfc5d3ac, n=0xb71f4d2c) at ../Python/compile.c:4181 #18 0xb7eca926 in com_if_stmt (c=0xbfc5d3ac, n=0xb71f7398) at ../Python/compile.c:3848 #19 0xb7ec9101 in com_node (c=0xbfc5d3ac, n=0xb720a688) at ../Python/compile.c:4181 #20 0xb7ecd1af in com_try_except (c=0xbfc5d3ac, n=0xb71f5728) at ../Python/compile.c:3998 #21 0xb7ec9101 in com_node (c=0xbfc5d3ac, n=0xb722ecdc) at ../Python/compile.c:4181 #22 0xb7eca926 in com_if_stmt (c=0xbfc5d3ac, n=0xb71dcb60) at ../Python/compile.c:3848 #23 0xb7ec9101 in com_node (c=0xbfc5d3ac, n=0xb71d8318) at ../Python/compile.c:4181 #24 0xb7ecac18 in com_if_stmt (c=0xbfc5d3ac, n=0xb71d4110) at ../Python/compile.c:3855 #25 0xb7ec9101 in com_node (c=0xbfc5d3ac, n=0xb737c610) at ../Python/compile.c:4181 #26 0xb7ec6d4c in compile_node (c=0xbfc5d3ac, n=) at ../Python/compile.c:4755 #27 0xb7ec7e80 in jcompile (n=0xb71d4098, filename=, base=0xbfc5d72c, flags=0x0) at ../Python/compile.c:5006 #28 0xb7ec8776 in com_funcdef (c=0xbfc5d72c, n=0xb71d4098) at ../Python/compile.c:4942 #29 0xb7ec6c8e in compile_node (c=0xbfc5d72c, n=) at ../Python/compile.c:4728 #30 0xb7ec7e80 in jcompile (n=0xb7341668, filename=, base=0x0, flags=0x0) at ../Python/compile.c:5006 #31 0xb7ec86ca in PyNode_Compile (n=0xb71a58f0,
filename=0x82d5aa0 "/usr/lib/univention-directory-listener/system/cyrus-sieve.py") at ../Python/compile.c:4913 #32 0x0804e5de in module_import (filename=0x82d5aa0 "/usr/lib/univention-directory-listener/system/cyrus-sieve.py") at handlers.c:98 #33 0x0804ec6e in handler_import (filename=0x82d5aa0 "/usr/lib/univention-directory-listener/system/cyrus-sieve.py") at handlers.c:184 #34 0x0804fb37 in handlers_load_path (path=0x8062130 "/usr/lib/univention-directory-listener/system") at handlers.c:472 #35 0x0804fbc0 in handlers_load_all_paths () at handlers.c:491 #36 0x0804fff0 in handlers_init () at handlers.c:568 #37 0x0804bfb9 in main (argc=16, argv=0xbfc5dce4) at main.c:489 (gdb)
Given the function names I would suspect a bug in the garbage collector? I'm not familiar with the internals of Python's memory managent, so I can't really tell for sure. It could also be that some default internal limits of the memory manager are triggered.
Shall I open a bug in the tracker for this does anyone suspect a different cause or even a workaround?
Cheers, Moritz
Moritz Muehlenhoff muehlenhoff at univention.de fon: +49 421 22 232- 0 Development Linux for Your Business fax: +49 421 22 232-99 Univention GmbH http://www.univention.de/ mobil: +49 175 22 999 23
- Previous message: [Python-Dev] test_doctest failing
- Next message: [Python-Dev] Possible error in Python 2.4 garbage collector
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]