l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2003 Jan 02 13:55

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Segmentation Fault with RPM --rebuilddb
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.