Bug 689990
Summary: | python coredump when exporting channel with packages with crazy chars in description | ||
---|---|---|---|
Product: | [Community] Spacewalk | Reporter: | Jan Hutař <jhutar> |
Component: | Server | Assignee: | Michael Mráka <mmraka> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat Satellite QA List <satqe-list> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 1.4 | CC: | jpazdziora |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | rhnlib-2.5.42-1 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-12-22 16:48:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 723481 |
Description
Jan Hutař
2011-03-22 22:32:09 UTC
# 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. 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. |