Description of problem: I have packages with crazy chars in description pushed into the channel on SW14 on PostgreSQL and when I try to export the channel, I'm getting python core. Version-Release number of selected component (if applicable): spacewalk-backend-tools-1.4.21-1.el5 python-2.4.3-43.el5 How reproducible: always Steps to Reproduce: 1. create channel and push packages with crazy chars in their description 2. try to dump that channel Actual results: # rhn-satellite-exporter --dir=/tmp/jhutar-dump --channel=jhutar-test 18:24:14 Gathering channel info... Appending channels ['jhutar-test'] 18:24:14 Gathering binary RPM info... python: Modules/gcmodule.c:275: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. Aborted (core dumped) Expected results: Should work as for other channels Additional info: This might be issue in python. Please switch it to a correct product/component in that case.
# rpm -qa | grep debuginfo glibc-debuginfo-2.5-58 glibc-debuginfo-common-2.5-58 python-debuginfo-2.4.3-43.el5 # gdb `type -p rhn-satellite-exporter` core.3523 GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... "/usr/bin/rhn-satellite-exporter": not in executable format: File format not recognized Core was generated by `python /usr/bin/rhn-satellite-exporter --dir=/tmp/jhutar-dump --channel=jhutar-'. Program terminated with signal 6, Aborted. #0 0x00b4c410 in __kernel_vsyscall () (gdb) bt #0 0x00b4c410 in __kernel_vsyscall () #1 0x00921df0 in ?? () (gdb) quit
What does the description of the problematic package look like?
(In reply to comment #1) > # rpm -qa | grep debuginfo > glibc-debuginfo-2.5-58 > glibc-debuginfo-common-2.5-58 > python-debuginfo-2.4.3-43.el5 > > # gdb `type -p rhn-satellite-exporter` core.3523 You need to gdb python, not the script: # gdb `type -p python` core.13765 GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5) [...] #0 0x00956410 in __kernel_vsyscall () (gdb) bt #0 0x00956410 in __kernel_vsyscall () #1 0x00138df0 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x0013a701 in abort () at abort.c:88 #3 0x0013226b in __assert_fail (assertion=0xc33649 "gc->gc.gc_refs != 0", file=0xc33624 "Modules/gcmodule.c", line=275, function=0xc33ae7 "visit_decref") at assert.c:78 #4 0x00c0651d in visit_decref (op=0x94e61bc, data=0x0) at Modules/gcmodule.c:275 #5 0x00bb45ba in tupletraverse (o=0x9500dac, visit=0xc06470 <visit_decref>, arg=0x0) at Objects/tupleobject.c:444 #6 0x00c06aba in subtract_refs (generation=0) at Modules/gcmodule.c:294 #7 collect (generation=0) at Modules/gcmodule.c:776 #8 0x00c07378 in collect_generations (basicsize=20) at Modules/gcmodule.c:872 #9 _PyObject_GC_Malloc (basicsize=20) at Modules/gcmodule.c:1263 #10 0x00c073b9 in _PyObject_GC_NewVar (tp=0xc5a340, nitems=2) at Modules/gcmodule.c:1283 #11 0x00bb50c4 in PyTuple_New (size=2) at Objects/tupleobject.c:69 #12 0x00bfafab in do_mktuple (p_format=0xbfc94b50, p_va=0xbfc94b4c, endchar=0, n=2) at Python/modsupport.c:256 #13 0x00bfb685 in Py_VaBuildValue (format=0x93d66a "s#O", va=0xbfc94ba8 "x{S\t\003") at Python/modsupport.c:496 #14 0x00b79ba2 in PyObject_CallFunction (callable=0x9501ca4, format=0x6 <Address 0x6 out of bounds>) at Objects/abstract.c:1818 #15 0x00930d88 in typecast_cast (obj=0x94e61bc, str=0x9537b78 "349", len=13765, curs=0x94e93ac) at psycopg/typecast.c:598 #16 0x00936fbe in _psyco_curs_buildrow_fill (self=0x94e93ac, res=0x953a3ec, row=65, n=2, istuple=1) at psycopg/cursor_type.c:708 #17 0x009370fb in _psyco_curs_buildrow (self=0x94e93ac, row=65) at psycopg/cursor_type.c:747 #18 0x00937355 in psyco_curs_fetchall (self=0x94e93ac, args=0xb7f5102c) at psycopg/cursor_type.c:925 #19 0x00ba39bd in PyCFunction_Call (func=0x950896c, arg=0xb7f5102c, kw=0x0) at Objects/methodobject.c:108 #20 0x00bdf5ad in call_function (f=0x94c045c) at Python/ceval.c:3563 #21 PyEval_EvalFrame (f=0x94c045c) at Python/ceval.c:2163 #22 0x00bdf11f in call_function (f=0x9253bac) at Python/ceval.c:3645 #23 PyEval_EvalFrame (f=0x9253bac) at Python/ceval.c:2163 #24 0x00be0856 in PyEval_EvalCodeEx (co=0xb7f203e0, globals=0xb7f164f4, locals=0x0, args=0xb7f70b50, argcount=4, kws=0x95284b0, kwcount=3, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #25 0x00b91199 in function_call (func=0x94df374, arg=0xb7f70b44, kw=0x94e5f0c) at Objects/funcobject.c:548 #26 0x00b79087 in PyObject_Call (func=0x35c5, arg=0xb7f70b44, kw=0x94e5f0c) at Objects/abstract.c:1795 #27 0x00b7f718 in instancemethod_call (func=0xb7cded4c, arg=0xb7f70b44, kw=0x94e5f0c) at Objects/classobject.c:2447 #28 0x00b79087 in PyObject_Call (func=0x35c5, arg=0xb7f70414, kw=0x94e5f0c) at Objects/abstract.c:1795 #29 0x00bda07c in PyEval_CallObjectWithKeywords (func=0xb7cded4c, arg=0xb7f70414, kw=0x94e5f0c) at Python/ceval.c:3430 #30 0x00b834c0 in PyInstance_New (klass=0x94d4c5c, arg=0xb7f70414, kw=0x94e5f0c) at Objects/classobject.c:575 #31 0x00b79087 in PyObject_Call (func=0x35c5, arg=0xb7f70414, kw=0x94e5f0c) at Objects/abstract.c:1795 #32 0x00bdd138 in call_function (f=0x92449a4) at Python/ceval.c:3771 #33 PyEval_EvalFrame (f=0x92449a4) at Python/ceval.c:2163 #34 0x00be0856 in PyEval_EvalCodeEx (co=0xb7f20e20, globals=0xb7f164f4, locals=0x0, args=0xb7f2b6b8, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #35 0x00b910aa in function_call (func=0x94df844, arg=0xb7f2b6ac, kw=0x0) at Objects/funcobject.c:548 #36 0x00b79087 in PyObject_Call (func=0x35c5, arg=0xb7f2b6ac, kw=0x0) at Objects/abstract.c:1795 #37 0x00b7f718 in instancemethod_call (func=0xb7cd7d9c, arg=0xb7f2b6ac, kw=0x0) at Objects/classobject.c:2447 #38 0x00b79087 in PyObject_Call (func=0x35c5, arg=0xb7f5102c, kw=0x0) at Objects/abstract.c:1795 #39 0x00bda07c in PyEval_CallObjectWithKeywords (func=0xb7cd7d9c, arg=0xb7f5102c, kw=0x0) at Python/ceval.c:3430 #40 0x00b834c0 in PyInstance_New (klass=0x94d4c8c, arg=0xb7f5102c, kw=0x0) at Objects/classobject.c:575 #41 0x00b79087 in PyObject_Call (func=0x35c5, arg=0xb7f5102c, kw=0x0) at Objects/abstract.c:1795 #42 0x00bdd138 in call_function (f=0x92402a4) at Python/ceval.c:3771 #43 PyEval_EvalFrame (f=0x92402a4) at Python/ceval.c:2163 #44 0x00be0856 in PyEval_EvalCodeEx (co=0xb7f15b60, globals=0xb7f68824, locals=0xb7f68824, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #45 0x00be08e3 in PyEval_EvalCode (co=0xb7f15b60, globals=0xb7f68824, locals=0xb7f68824) at Python/ceval.c:484 #46 0x00bfd708 in run_node (n=<value optimized out>, filename=<value optimized out>, globals=0xb7f68824, locals=0xb7f68824, flags=0xbfc95e34) at Python/pythonrun.c:1265 #47 0x00bfee18 in PyRun_SimpleFileExFlags (fp=0x9235008, filename=0xbfc97b15 "/usr/bin/rhn-satellite-exporter", closeit=1, flags=0xbfc95e34) at Python/pythonrun.c:860 #48 0x00bff4fa in PyRun_AnyFileExFlags (fp=0x9235008, filename=0xbfc97b15 "/usr/bin/rhn-satellite-exporter", closeit=1, flags=0xbfc95e34) at Python/pythonrun.c:664 #49 0x00c05fb8 in Py_Main (argc=3, argv=0xbfc95f04) at Modules/main.c:493 ---Type <return> to continue, or q <return> to quit---q
(In reply to comment #4) > You need to gdb python, not the script: Thanks!
(In reply to comment #3) > What does the description of the problematic package look like? I was not able to come to some exact package which is causing this. I was iteratively creating clones of original channel and removing packages from it and checking if it still fails to export. Export works, if I remove first 50 or last 50 packages for a clone. Channel have 101 packages. So the issue might be caused by some combination of packages in a channel. Or, might there be some delayed taskomatic process fixing something when I'm testing it?
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
Aligning under space16.
Fixed in spacewalk master by commit dfde40630a2fbf1933a09c4228824a3da1287446 fixing python: Modules/gcmodule.c:275: visit_decref: Assertion `gc-> gc.gc_refs != 0' failed. Aborted (core dumped)
Spacewalk 1.6 has been released.