From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 Description of problem: I'm trying to run up2date on my freshly installed RHEL WS Beta2 system. I've installed the new certificate (via the new-cert script), and my rhn-applet seems to be working correctly (I have 126 updates to apply). When I run up2date -l from a root shell, I get a segv after 3/4 or so through the "Fetching rpm headers" action. When I run the GUI version, it disappears while going through the rpm headers list (the last name I saw in the list was xterm-179-4). There's quite a pause during the "fetching headers" section. I then downloaded up2date*-3.9.23-1 from RHN, installed the RPMs, and I get the same results. I see the beta1 in the channel name, which surprises me, since this system was definitely installed from the beta2 CD's, and my RHN channel listing via the web site shows my channel as Beta2. Version-Release number of selected component (if applicable): up2date-3.9.23-1 How reproducible: Always Steps to Reproduce: 1. up2date -l Actual Results: [root@WesternAve zoo]# time up2date -l Fetching package list for channel: rhel3-beta1-ws-i386... ######################################## Fetching Obsoletes list for channel: rhel3-beta1-ws-i386... Fetching rpm headers... ######################################## Segmentation fault real 0m24.665s user 0m8.950s sys 0m1.090s Expected Results: I expected to see a list of packages that I could update. Additional info:
can you try: strace -f up2date -l and: up2date -v -v -v -l And attach the results to this bug report?
Created attachment 94205 [details] output from strace -o up2date.strace -f up2date -l
Created attachment 94206 [details] output from up2date -v -v -v -l > up2date.verbose 2>&1
I've just booted the machine again, and when I run 'up2date -l' now, it does not segv. I didn't get a list of packages that I could update. And the GUI version still vanishes at the same poiont. But no segv. The segv's were completely repeatable yesterday, and the lack of them is repeatable now.
Problm (or at least symptoms) appear to be resolved. Please reopen if you can reproduce the problem.
What symptoms have gone away? The program doesn't segv anymore, but I can't run up2date on my machine because the program silently exits. rhn-appnet says that I have 171 updates available for my system, but neither the text nor the GUI version of up2date will run past "fetching RPM headers". The only change from the original bug report is the lack of a segv notification.
I've just tried the latest up2date (3.9.24-2) without any change in the behavior of this bug.
This looks like an up2date, not rpm, problem to me because it is occuring while fetching headers, which is behavior (at least mostly) outside of rpm-python bindings. If you reassign to rpm, please include a description of why you think this is an rpm problem.
I've updated to rhnlib 1.3-12 and up2date{,-gnome}-3.9.25-1, and this also has no change in the behavior of this bug.
I'm not sure I follow what the status is. If I read the bug report correctly, it no longer segfaults, but exits on startup? If the latter is the case, I need strace and `-v -v -v ` output again since it looks like a different issue. Also, could I get the output of `ls -al /var/spool/up2date` ? Looks like possible data corruption in headers.
Created attachment 94494 [details] output from strace -o up2date.strace -f up2date -l
Created attachment 94495 [details] output from up2date -v -v -v -l > up2date.verbose 2>&1
Created attachment 94496 [details] output of ls -al /var/spool/up2date The current state of the bug is that the problem remains as stated earlier (the same sequence of actions occurs, the programs fails in the same place). The only difference noted is that while at the time of the first bug report, the program would also segv, it no longer does. It still terminates, but no segv notification.
Created attachment 94498 [details] Two different copies of the dev-*.hdr file. Based on the data corruption comment, I moved /var/spool/up2date out of the way, created a new directory, and started over. After downloading all of the RPM headers, I got a list of packages to update (as expected). After doing a comparison of the directory contents, I found that all the .hdr files were identical, except for the dev-3.3.7-1 file. The file under save/bad was in the directory I moved away from /var/spool/up2date, save/good/* is the file that's there now, where I'm able to get things done. So I appear to be back in operation, with a workaround. But how did this occur in the first place, and why a silent crash rather than a useful error?
current code includes more code to detect headers that might be corrupt. In addition, rpm should be more robust in the face of corrupt headers, so closing this "currentrelease"