Bug 58890 - retreiving package header breaks down
retreiving package header breaks down
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
7.2
i686 Linux
high Severity high
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-26 17:10 EST by Hans Christian Studt
Modified: 2015-01-07 18:54 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-21 11:11:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans Christian Studt 2002-01-26 17:10:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221

Description of problem:
I'm using RedHat's System Update agent.
After selecting which server to update, it does som package processing, then it
display "removing ...something", the it display "retreiving package header ..."
and break down approx. around the 50% mark.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Maun menu
2. System
3. Update Agent
	

Additional info:

Also submitted to submit@bugs.gnome.org

Subject: retreiving package header breaks down

Package: gnome-python
Severity: normal
Version: 0.0
Synopsis: retreiving package header breaks down
Bugzilla-Product: gnome-python
Bugzilla-Component: general

Description:
I'm using RedHat's System Update agent.
After selecting which server to update, it does som package processing, then it
display "removing ...something", the it display "retreiving package header ..."
and break down approx. around the 50% mark.
The update agent worked when I used it a week ago.
The same problem occured every time a tried today.
I had to reboot my system in the same process yesterday, which may have left
something in a unknown state, but the update process should be able to recover
or clean up.

Debugging Information:

(no debugging symbols found)...[New Thread 1024 (LWP 1284)]
0x40127ca9 in __wait4 ()
   from /lib/i686/libc.so.6
#0  0x40127ca9 in __wait4 () from /lib/i686/libc.so.6
#1  0x401a36b4 in __DTOR_END__ () from /lib/i686/libc.so.6
#2  0x400406f3 in waitpid (pid=1289, stat_loc=0xbfffd9bc, options=0)
    at wrapsyscall.c:172
#3  0x40813e88 in gnome_segv_handle () from /usr/lib/libgnomeui.so.32
#4  0x4003ea85 in pthread_sighandler (signo=11, ctx=
      {gs = 7, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh
= 0, edi = 3221216640, esi = 139327028, ebp = 3221216712, esp = 3221216612, ebx
= 1075847848, edx = 3221216640, ecx = 16, eax = 3221216640, trapno = 14, err =
4, eip = 1074749564, cs = 35, __csh = 0, eflags = 66183, esp_at_signal =
3221216612, ss = 43, __ssh = 0, fpstate = 0xbfffdae8, oldmask = 2147483648, cr2
= 139327028}) at signals.c:97
#5  <signal handler called>
#6  0x400f607c in memcpy () from /lib/i686/libc.so.6
#7  0x00000010 in ?? ()
#8  0x4001f721 in hdrLoad () from /usr/lib/python1.5/site-packages/rpmmodule.so
#9  0x08055752 in PyEval_CallObjectWithKeywords ()
#10 0x0805562e in PyEval_CallObjectWithKeywords ()
#11 0x0805445c in PyEval_EvalCode ()
#12 0x08054329 in PyEval_EvalCode ()
#13 0x08054329 in PyEval_EvalCode ()
#14 0x08055afa in PyEval_CallObjectWithKeywords ()
#15 0x0805561e in PyEval_CallObjectWithKeywords ()
#16 0x08081084 in PyTuple_Fini ()
#17 0x08055752 in PyEval_CallObjectWithKeywords ()
#18 0x0805562e in PyEval_CallObjectWithKeywords ()
#19 0x0805445c in PyEval_EvalCode ()
#20 0x08054329 in PyEval_EvalCode ()
#21 0x08054329 in PyEval_EvalCode ()
#22 0x08054329 in PyEval_EvalCode ()
#23 0x08055afa in PyEval_CallObjectWithKeywords ()
#24 0x0805561e in PyEval_CallObjectWithKeywords ()
#25 0x08081084 in PyTuple_Fini ()
#26 0x08055752 in PyEval_CallObjectWithKeywords ()
#27 0x0805562e in PyEval_CallObjectWithKeywords ()
#28 0x0805445c in PyEval_EvalCode ()
#29 0x08055afa in PyEval_CallObjectWithKeywords ()
#30 0x0805561e in PyEval_CallObjectWithKeywords ()
#31 0x0806d4e4 in PyObject_CallObject ()
#32 0x4044fe88 in PyGtk_CallbackMarshal ()
   from /usr/lib/python1.5/site-packages/_gtkmodule.so
#33 0x405533fb in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#34 0x4055276d in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#35 0x40550525 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#36 0x407fb018 in gnome_druid_page_next () from /usr/lib/libgnomeui.so.32
#37 0x407f96b4 in gnome_druid_next_callback () from /usr/lib/libgnomeui.so.32
#38 0x4051fde1 in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0
#39 0x40553436 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#40 0x4055276d in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#41 0x40550525 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#42 0x404b7e2d in gtk_button_clicked () from /usr/lib/libgtk-1.2.so.0
#43 0x404b95ed in gtk_real_button_released () from /usr/lib/libgtk-1.2.so.0
#44 0x4051fde1 in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0
#45 0x405525f1 in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#46 0x40550525 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#47 0x404b7d5d in gtk_button_released () from /usr/lib/libgtk-1.2.so.0
#48 0x404b8ed7 in gtk_button_button_release () from /usr/lib/libgtk-1.2.so.0
#49 0x4051faec in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0
#50 0x405527ad in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#51 0x40550525 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#52 0x4058ab89 in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0
#53 0x4051fa45 in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0
#54 0x4051ea6f in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0
#55 0x405cfd7f in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0
#56 0x40605773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#57 0x40605d39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#58 0x40605eec in g_main_run () from /usr/lib/libglib-1.2.so.0
#59 0x4051e333 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#60 0x404512b4 in _wrap_gtk_main ()
   from /usr/lib/python1.5/site-packages/_gtkmodule.so
#61 0x08055752 in PyEval_CallObjectWithKeywords ()
#62 0x0805562e in PyEval_CallObjectWithKeywords ()
#63 0x0805445c in PyEval_EvalCode ()
#64 0x08054329 in PyEval_EvalCode ()
#65 0x08054329 in PyEval_EvalCode ()
#66 0x08054329 in PyEval_EvalCode ()
#67 0x08052155 in PyEval_EvalCode ()
#68 0x080655c7 in PyRun_File ()
#69 0x08064b40 in PyRun_SimpleFile ()
#70 0x0806473b in PyRun_AnyFile ()
#71 0x08050284 in Py_Main ()
#72 0x0804fc33 in main ()
#73 0x40089627 in __libc_start_main (main=0x804fc14 <main>, argc=3, 
    ubp_av=0xbffffe54, init=0x804f1b0 <_init>, fini=0x8096590 <_fini>, 
    rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbffffe4c)
    at ../sysdeps/generic/libc-start.c:129
#0  0x40127ca9 in __wait4 () from /lib/i686/libc.so.6
No locals.
#1  0x401a36b4 in __DTOR_END__ () from /lib/i686/libc.so.6
No symbol table info available.
#2  0x400406f3 in waitpid (pid=1289, stat_loc=0xbfffd9bc, options=0)
    at wrapsyscall.c:172
	in wrapsyscall.c
stat_loc = (int *) 0xbfffd9bc
options = 0
result = 0
oldtype = 0
#3  0x40813e88 in gnome_segv_handle () from /usr/lib/libgnomeui.so.32
No symbol table info available.
#4  0x4003ea85 in pthread_sighandler (signo=11, ctx=
      {gs = 7, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh
= 0, edi = 3221216640, esi = 139327028, ebp = 3221216712, esp = 3221216612, ebx
= 1075847848, edx = 3221216640, ecx = 16, eax = 3221216640, trapno = 14, err =
4, eip = 1074749564, cs = 35, __csh = 0, eflags = 66183, esp_at_signal =
3221216612, ss = 43, __ssh = 0, fpstate = 0xbfffdae8, oldmask = 2147483648, cr2
= 139327028}) at signals.c:97
	in signals.c
signo = 0
__value = 0xfffffe00 <Address 0xfffffe00 out of bounds>
#5  <signal handler called>
No locals.
#6  0x400f607c in memcpy () from /lib/i686/libc.so.6
No locals.
#7  0x00000010 in ?? ()
No symbol table info available.
Comment 1 Need Real Name 2002-01-31 18:42:17 EST
same problem here.  this should really be a high severity bug since many people 
use up2date for security fixes.

partial strace below...

...
open("/var/spool/up2date", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
getdents64(4, /* 59 entries */, 4096)   = 3144
getdents64(4, /* 0 entries */, 4096)    = 0
close(4)                                = 0
stat64("/var/spool/up2date/kernel-source-2.4.9-21.i386.hdr", 
{st_mode=S_IFREG|0644, st_size=376832, ...}) = 0
access("/var/spool/up2date/kernel-source-2.4.9-21.i386.hdr", R_OK) = 0
stat64("/var/spool/up2date/kernel-source-2.4.9-21.i386.hdr", 
{st_mode=S_IFREG|0644, st_size=376832, ...}) = 0
open("/var/spool/up2date/kernel-source-2.4.9-21.i386.hdr", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=376832, ...}) = 0
lseek(4, 0, SEEK_CUR)                   = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=376832, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x4002a000
_llseek(4, 0, [0], SEEK_CUR)            = 0
old_mmap(NULL, 380928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x40484000
read(4, "\0\0\0?\0\n\214\225\0\0\0?\0\0\0\7\0\n\2140\0\0\0\20\0\0\0d\0\0\0\10\0
\0\0\0\0\0\0\1\0\0\3\350\0\0\0\6\0\0\0\2\0\0\0\1\0\0\3\351\0\0\0\6\0\0\0\20\0\0
\0"..., 376832) = 376832
read(4, "", 4096)                       = 0
mremap(0x40484000, 380928, 380928, MREMAP_MAYMOVE) = 0x40484000
old_mmap(NULL, 380928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x404e1000
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

Comment 2 Need Real Name 2002-01-31 19:03:36 EST
I saved my header files and then did a:

rm -f /var/spool/up2date/*.hdr

That seems to have solved the problem.  This is probably a bug in up2date.  If 
you seem to abort up2date in the middle of "Getting header files" (even on just 
a -l) it doesn't remove the file and chokes forever.
Comment 3 Hans Christian Studt 2002-02-01 06:36:59 EST
I too saved my /var/spool/up2date/* files and then did a:

rm -f /var/spool/up2date/*

That too seems to have solved the problem (corrupted/incomplete hdr files ???).

One problem is that the man pages to up2date, does not make any reference to the
/var/spool/up2date/ directory e.g. in the FILES section.

On the other hand the up2date might be enhanced to detect corrupted/incomplete
hdr files at provide some way to refresh them.

I have come to relay heavily on up2date to keep up with security and other bug
fixes (thank you to the guys behind up2date).
Comment 4 Jeff Johnson 2002-02-01 17:28:19 EST
Back to up2date, as the fix (in progress) will be there.
Comment 5 Adrian Likins 2002-03-06 18:38:26 EST
The next version of the client should be considerbly more robust in
the case of incomplete or corrupt headers in the cache. So this
should no longer be an issue. 

Also, I'll add the spool directory and a couple of the other files
that we've added recently into the FILES section of the man page.
Comment 6 Matt Jamison 2003-05-21 11:11:28 EDT
issue is resolved.  closing bug.

Note You need to log in before you can comment on or make changes to this bug.