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

[ME]

Richard Crawford said:
> 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
[chop]
> 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

Fail after a pwrite? Hmm. Would you mind running this again, but instead try:
# strace -f rpm --rebuilddb
? The -f also does the strace on child processes spawned by the first. I
am betting that "rpm --rebuilddb" actually calls a different program that
is segfaulting and the strace is not contintuing to the next app being
called.
(Just guessing)

If the output of the lines just preceeding the SIGSEGV is the same, you
dont need to paste it in again, just let us know. If the output leading up
to the Segfault is different, could you include the new run/output like
you did this time? :-)

> 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?

I dont run RedHat, but would guess you could. You might want to check to
see if the actual "rpm" program has even changed. Compare the md5sum of
your rmp with that of one that works on another system of same version. if
the sums are the same, re-installing that app will likely have no effect.

On the topic of "time". After you run the program, does it immediately
return the message "segfault" or does it take a while and occur after lots
of disk activity?

> 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
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
>