From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 Description of problem: Updated rpm to 4.0.4-7x. When using a %_topdir other than /usr/src/redhat (specified in ~/.rpmmacros), running rpm -bp on any specfile will cause an immediate Segmentation Fault. Backed out 4.0.4-7x to 4.0.3-1.03 and everything is AOK. Version-Release number of selected component (if applicable): 4.0.4-7x How reproducible: Always Steps to Reproduce: 1.create rpm subtree under ~/src (ie BUILD,RPMS,SOURCES etc etc) 2.echo "%_topdir ${HOME}/src" > ~/.rpmmacros 3.Install source rpm, oh.. say rpm-4.0.4-7x: rpm -ivh rpm-4.0.04-7x.src.rpm 4.Try to run prep stage of RPM build: cd ~/src/SPECS; rpm -bp rpm.spec Actual Results: Segmentation Fault Expected Results: rpm-4.0.4.tar.gz should have been expanded into ~/src/BUILD/rpm-4.0.4 Additional info: 1. When running as root, keeping default %_topdir, everything runs fine 2. This bug is pretty ugly under gdb. As root I compiled the RPM in /usr/src/redhat as root ( rpm -bc rpm.spec ) to get an executable with debug information. I then used this under gdb to try and find the bug. I get an error like 'Cannot find user-level thread for LWP 663: generic error' when the program fails. After this, any attempt to 'quit' out of gdb results in a 'Cannot find thread 1024: invalid thread handle'. At this point, I gave up and went back to 4.0.3
I use rpm with %{_topdir} configured daily without problem. What does "rpm --eval '%{_topdir}\n'" say?
AFAICT, you're trying to use a relative path with a "~" in topdir. Use an absolute path. Reopen if that was not the problem.
rpm --eval '%{_topdir}\n' results in "/home/audley/src\n". I am not using '~' in %_topdir and explicitly stated ${HOME} in my instructions instead of '~'. Anyway, since when is 'Segmentation Fault' under any circumstance "NOTABUG". Again, the rpm on the 7.2 cd works fine, the latest update does not. I'm running 7.2, installed on Saturday selecting that "Everything" be installed. I then run a perl script which grabs all RPM off of updates.redhat.com and lists those that are relevant to the machine. All updates were applied. I've attached two lists of RPMS, one called forward which updates the machine to the point where rpm -bp seg faults. The other lists RPMS from the original disk to restore the machine so rpm -bp works, called back. To be able to apply both sets of RPMS, I've removed up2date so that python-popt isn't necessary. My bother is getting married this weekend, I don't have time to answer your questions the second you ask them. How about giving me some time before you just dismiss the bug report and close it.
Created attachment 52225 [details] list of updates applied to system to cause error, assumes all other current updates (4/3/02)
Created attachment 52226 [details] after all current updates to 7.2 (4/3/02) are applied, restoring these rpms from the distribution disk clears the problem
No need to get huffy, just reopen the bug. I need a specific test case to try to reproduce your problem. AFAIK, *lots* of packages are being rebuilt daily, many with _topdir overridden, without seg faulting. That leads me to believe that there's something specific about your configuration and/or machine that is causing the problem. So, more specific details please.
The machine is a brand new installation of RH7.2, not an upgrade, with all of the updates from updates.redhat.com. There are three partitions, hda2 is /boot (32M), hda5 is swap (2 Gig), hda6 is /scratch (a work area, 8G) and hda8 is / (12G). The other partitions relate to other installations and are not mounted. The account being used is from LDAP, with a local /home created from the skel directory. However, placing the .rpmmacros in /root and trying to run rpm -bp as root also fails. The .rpmmacros is a very simple file as indicated above. The machine is a 1.3GHz Athlon with 512Mb, IDE drives. I'm not sure what other details could be relavent.
Bingo. There's a problem with the pam LDAP module that affects statically linked binaries like rpm. Fire up nscd and your segfault will go away.
OK. Thank you for looking into this. Cheers Chris
roblem appears solved.