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 03 16:17

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

(Sorry, trying to get caught up on e-mail again)

Richard Crawford said:
> On Thu, 2003-01-02 at 11:58, ME wrote:
>> 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 ran,
> 	# strace -f rpm --rebuilddb
> and got exactly the same output.  Eerie.
> I should point out that other functions of rpm (-i, -e, -qa, etc.)
> function normally.  It's when I run it with --rebuilddb that it bombs.

Well, assuming we are seeing sync-ed output, then there is a problem with
the program as it is writing out its results. (more)

>> 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?
> It's immediate.  There's no hard drive activity at all.

Since it is immediate, and we see no other items in the trace, I would
expect it is not a path issue with symlinks. It is sounding more and more
like a file problem. Like there is an attempt to open a file (earlier)
that is assumed to allready be open (no checking) and now, as we are
getting to writing to the file descriptor, it is suddenly found to not be
valid, or ? I guess it could be cause by a filesystem problem at the point
on disk where one of the files it uses is stored (seems unlikely)

The suggestion made by Charles Polisher is a good one, and puts you on
what I would expect to be a good track. Try to find files used by this
process of "rpm --rebuilddb" and move them (backup) to a different
location. Then re-run the program to see if it segfaults.


Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(  ) !s !a   (-----) C  $(    ) U    $( $) P $>
L   $(  ) E W   $( ) N  o K w $>  >    O-@ M $ V-$>- !PS !PE Y  PGP
t@-(  ) 5 @ X@ R- tv- b   DI    D  G--@ e >  >     h(  )>  r*>? z?
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html
  Campus IT(/OS Security): Operating Systems Support Specialist Assistant

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.