The following occurs for me on all three of my gentoo systems: python >> import anydbm # or dbhash, same thing happens >> f=anydbm.open('goo', 'c') >> f['do it to me']='ha' Segmentation fault
So far, the best information I have on this is that it might be the bsd db, and not python specifically. I will continue investigating. (gdb) jnelson@host jnelson $ gdb /usr/bin/python GNU gdb 5.1.1 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 "i686-pc-linux-gnu"... (gdb) run Starting program: /usr/bin/python Python 2.2.1 (#1, May 2 2002, 20:50:43) [GCC 2.95.3 20010315 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import anydbm >>> f=anydbm.open('foo', 'c') >>> f['do it to me'] = 'ha' Program received signal SIGSEGV, Segmentation fault. 0x40249b77 in __db185_open () from /usr/lib/libdb-3.2.so (gdb) bt #0 0x40249b77 in __db185_open () from /usr/lib/libdb-3.2.so #1 0x400275ea in bsddb_ass_sub (dp=0x818f8e0, key=0x8179cc8, value=0x8179c58) at /tmp/portage/python-2.2.1/work/Python-2.2.1/Modules/bsddbmodule.c:363 #2 0x080a61cc in PyObject_SetItem (o=0x818f8e0, key=0x8179cc8, value=0x8179c58) at Objects/abstract.c:124 #3 0x0807540c in eval_frame (f=0x811613c) at Python/ceval.c:1309 #4 0x080778be in PyEval_EvalCodeEx (co=0x8179cf0, globals=0x810f1dc, locals=0x810f1dc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #5 0x08079940 in PyEval_EvalCode (co=0x8179cf0, globals=0x810f1dc, locals=0x810f1dc) at Python/ceval.c:483 #6 0x080943a1 in run_node (n=0x8164998, filename=0x80cc715 "<stdin>", globals=0x810f1dc, locals=0x810f1dc, flags=0xbffff6d8) at Python/pythonrun.c:1079 #7 0x0809297f in PyRun_InteractiveOneFlags (fp=0x4018dbc0, filename=0x80cc715 "<stdin>", flags=0xbffff6d8) at Python/pythonrun.c:590 #8 0x08093cf1 in PyRun_InteractiveLoopFlags (fp=0x4018dbc0, filename=0x80cc715 "<stdin>", flags=0xbffff6d8) at Python/pythonrun.c:526 #9 0x08093aeb in PyRun_AnyFileExFlags (fp=0x4018dbc0, filename=0x80cc715 "<stdin>", closeit=0, flags=0xbffff6d8) at Python/pythonrun.c:489 #10 0x08053572 in Py_Main (argc=1, argv=0xbffff764) at Modules/main.c:364 #11 0x08052e26 in main (argc=1, argv=0xbffff764) at Modules/python.c:10 ---Type <return> to continue, or q <return> to quit---' #12 0x400823bd in __libc_start_main () from /lib/libc.so.6 (gdb)
After much investigation, I determined that the problem lies not with python, but with the db-3 package. The current db package is 3.2.3h. I tried the 3.2.9 ebuild and everything works fine so far (incl. python). Additionally, I modified the 3.3.11 ebuild somewhat, although *that* is far outside the scope of the bugreport. In short, I believe, but cannot prove, that there is a bug in the 3.2.3h version of db. As handling that is far outside the scope of my authority, I defer to others.
Jon: I think we can close this one?
I'm hesitant to close it while 3.2.9 remains masked in the profile (default-1.0), despite being *unmasked* in the profile.mask. I haven't heard back from veriwilst yet.
Hmm.. 3.2.3h is the one that was available for a long time now, with 3.2.9 being masked all along... When i talked to you Jon, he said it was safe to unmask it, but then some guys came telling 3.2.9 broke an ebuild.. So i don't know.. should 3.2.9 be unmasked or not? In gentoo 1.3, db 4.0.14 is default, and i haven't seen any problems yet..
Bart - your web browser of choice didn't wrap that reply (icky!) As for 3.2.9 breaking some ebuilds -- I'd like more details if possible. Regarding "breaking" rpm, rpm just has broken depends (bug filed), but 3.2.9 should be 100% compatible with 3.2.3h, except for the bugs, of course. As for 4.x, I don't know of any distros that are using it, so it's a bit risky, but other than that I don't know anything about it. I'd like to know more about these supposed problems with 3.2.9 Thanks!
This should be fixed as of today's commit of packages for default-1.0
