[vox-tech] Segmentation Fault with RPM --rebuilddb

[Richard Crawford]

I ran "strace rpm --rebuilddb" and got a bunch of... gibberish.  The
only line that makes sense to me at all is 

--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

Here are the last few lines of output:

==================================================================
# strace rpm --rebuilddb
.
.
.
open("/var/lib/rpmrebuilddb.2932/__db.001", O_RDWR|O_LARGEFILE) = 14
fcntl64(0xe, 0x2, 0x1, 0)               = 0
fstat64(14, {st_mode=S_IFREG|0644, st_size=8192, ...}) = 0
close(14)                               = 0
open("/var/lib/rpmrebuilddb.2932/__db.001", O_RDWR|O_LARGEFILE) = 14
fcntl64(0xe, 0x2, 0x1, 0)               = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 14, 0) = 0x40732000
close(14)                               = 0
open("/var/lib/rpmrebuilddb.2932/__db.002", O_RDWR|O_LARGEFILE) = 14
fcntl64(0xe, 0x2, 0x1, 0)               = 0
mmap2(NULL, 655360, PROT_READ|PROT_WRITE, MAP_SHARED, 14, 0) =
0x40734000
close(14)                               = 0
open("/var/lib/rpmrebuilddb.2932/Sigmd5",
O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 14
fcntl64(0xe, 0x2, 0x1, 0)               = 0
fstat64(14, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
_llseek(14, 0, [0], SEEK_SET)           = 0
read(14, "", 256)                       = 0
stat64("/var/lib/rpmrebuilddb.2932/Sigmd5", {st_mode=S_IFREG|0644,
st_size=0, ...}) = 0
time(NULL)                              = 1041531377
close(14)                               = 0
open("/var/lib/rpmrebuilddb.2932/Sigmd5", O_RDWR|O_LARGEFILE) = 14
fcntl64(0xe, 0x2, 0x1, 0)               = 0
fstat64(14, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
brk(0x8202000)                          = 0x8202000
pread(14, "", 4096, 0)                  = 0
_llseek(14, 0, [0], SEEK_SET)           = 0
read(14, "", 4096)                      = 0
pwrite(14, "\0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0\0\0\10"...,
4096, 0) = 4096
pwrite(14, "\0\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\2\0"...,
4096, 8192) = 4096
brk(0x8204000)                          = 0x8204000
pwrite(14, "\0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0\0\0\10"...,
4096, 0) = 4096
pwrite(14, "\0\0\0\0\1\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\2\0\346\17\0\2"...,
4096, 8192) = 4096
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
#

===================================================================

I understand the principle behind a segfault now (thanks!), but I am
still not sure how to interpret these results, or how to proceed next. 
Can I reinstall the RPM rpm, so to speak?



On Thu, 2003-01-02 at 01:03, ME wrote:
> A simplification of a segfault is the event that happens when the ksystem
> kills a process as it tries to read or write data to a space in memory for
> which it wa not allocated/permitted to read/write.
> 
> It can happen when a coder does not consider that another user may provide
> information that is out of bounds of what is allocated for use by the
> program.
> 
> (Say, I have a char array with space for 8 chars, but you enter 9. Such an
> event can lead to a segfault.)
> 
> What is causing this? I dont have or use redhat, but some suggestions:
> Check the physical files that would be replaced or modified with an update
> to the db. Any of these files could be damaged, or have odd permissions,
> or be creating problems unexpected by the updatedb sufficient that it cant
> cleanup and/or recover.
> 
> If it takes a while for it to appear and your machine gets a little slow
> with some disk access, perhaps you have a case where it is passing through
> a series of symlinks that eventually loop back. Such can lead to problems
> when recursives searches build paths internally without consideration for
> simlink vs real-dirs as they are asked to recursively search.
> 
> Another useful tool, is "strace". It mostly will include "gibberish" to
> the non-coder, but even a good user who is not a coder can often get
> useful information front an strace of an app that is failing with a
> segfault. The last 50 or so lines can often be very revealing. If
> debugging symbols are included, then "gdb" is a great tool for traceing
> through the actual execution, but it has an even steeper curve for a non
> coder.
> 
> HTH,
> -ME
-- 
Slainte,
Richard S. Crawford

mailto:rscrawford@mossroot.com		http://www.mossroot.com
AIM:  Buffalo2K   ICQ: 11646404  Yahoo!: rscrawford
MSN:  underpope@hotmail.com

"It is only with the heart that we see rightly; what is essential is
invisible to the eye."  --Antoine de Saint Exupery

vi vi vi - the editor of the beast