Bug 103757
Description
david d zuhn
2003-09-04 17:03:14 UTC
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" |