Bug 20595 - rpm -qf "%{#SOMETAG}" core dumps on tag FSNAMES
rpm -qf "%{#SOMETAG}" core dumps on tag FSNAMES
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-09 11:53 EST by Denice
Modified: 2007-04-18 12:29 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-11-09 11:53:32 EST
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 Denice 2000-11-09 11:53:30 EST
I've been using %{#SOMETAG} to query rpms and find the array-like entries
in an rpm.
At rpm version 4 this query frequently causes rpm to core dump.  An example
script to
test this is:
#!/bin/sh

cmd=`basename $0`
if [ $# -ne 1 ] ; then
  echo "USAGE: $cmd /path/to/rpm/some-file.rpm"
  exit 1
fi

rpm --querytags | while read t ; do
  echo -n "Tag: $t "
  rpm -qp --queryformat  "%{#$t}\n"  $1
  if [ $? -ne 0 ] ; then
    echo "EEK\!\! Tag $t bombed\!"
  fi
done
### end of script

Most rpms (but not all) in the current 7.0 errata result in a core dump for
me.
For example this one core dumps:

 rpm -qp --queryformat "%{#FSNAMES}\n"  usermode-1.37-2.i386.rpm

but tmpwatch-2.6.2-1.6.2.i386.rpm does not.

My 7.0 system is fully patched.  I copied the rpm executable to a 6.2
system and
ran it.  It core dumps there too.

For what its worth, here is some ltrace output:

# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1              2016016   1354692    558912  71% /

# ltrace rpm -qp --queryformat "%{#FSNAMES}\n" usermode-1.37-2.i386.rpm 
__libc_start_main(0x08049fb0, 7, 0xbffffa94, 0x0804902c, 0x0804aa4c
<unfinished ...>
__register_frame_info(0x0804d5c4, 0x0804db34, 0xbffffa38, 0x4017c977,
0x4017c960) = 0x4003b3e0
mtrace(0x4015801c, 0x0804d5d8, 0, 0, 0)           = 0
strrchr("/usr/lib/rpm/rpmq", '/')                 = "/rpmq"
setlocale(6, "")                                  = "en_US"
bindtextdomain("rpm", "/usr/share/locale")        = "/usr/share/locale"
textdomain("rpm")                                 = "rpm"
rpmSetVerbosity(3, 0x40260d4f, 0xbffffa28, 0x08049fd6, 0x4015801c) = 3
poptGetContext(0xbffffbb4, 7, 0xbffffa94, 0x0804d324, 0) = 0x08050138
poptReadConfigFile(0x08050138, 0x0804bf3f, 0xbffffa28, 0x08049fd6,
0x4015801c) = 0
poptReadDefaultConfig(0x08050138, 1, 0xbffffa28, 0x08049fd6, 0x4015801c) =
0
poptSetExecPath(0x08050138, 0x0804bf58, 1, 0x08049fd6, 0x4015801c) = 1
poptGetNextOpt(0x08050138, 0x0804bf58, 1, 0x08049fd6, 0x4015801c) = -1
rpmReadConfigFiles(0, 0, 1, 0x08049fd6, 0x4015801c) = 0
rpmSetVerbosity(3, 0, 1, 0x08049fd6, 0x4015801c)  = 3
poptResetContext(0x08050138, 0, 1, 0x08049fd6, 0x4015801c) = 0
free(0x08050e88)                                  = <void>
poptGetNextOpt(0x08050138, 0, 1, 0x08049fd6, 0x4015801c) = -1
urlIsURL(0x0804aaa0, 0, 1, 0x08049fd6, 0x4015801c) = 0
poptPeekArg(0x08050138, 0, 1, 0x08049fd6, 0x4015801c) = 0xbffffbe5
poptGetArg(0x08050138, 0, 1, 0x08049fd6, 0x4015801c) = 0xbffffbe5
rpmQuery(0x0804d7a8, 3, 0xbffffbe5, 0x08049fd6, 0x4015801c4
) = 0
poptGetArg(0x08050138, 3, 0xbffffbe5, 0x08049fd6, 0x4015801c) = 0
poptFreeContext(0x08050138, 3, 0xbffffbe5, 0x08049fd6, 0x4015801c) =
0x08050b40
rpmFreeMacros(0, 3, 0xbffffbe5, 0x08049fd6, 0x4015801c) = 0x08059b60
rpmFreeMacros(0x0804dac8, 3, 0xbffffbe5, 0x08049fd6, 0x4015801c) = 0
rpmFreeRpmrc(0x0804dac8, 3, 0xbffffbe5, 0x08049fd6, 0x4015801c) =
0x08055538
freeNames(0x4015801c, 0xbffffbb4, 0, 0, 1)        = 0x08055538
freeFilesystems(0x4015801c, 0xbffffbb4, 0, 0, 1 <unfinished ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
Comment 1 Jeff Johnson 2000-11-15 10:29:39 EST
Fixed in rpm-{4.1,4.0.1,3.0.7} CVS. Thanks for reporting.

FWIW, there's little reason to query the fsnames tags as you have, as the
information is read from /etc/mtab rather than a package.

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