Bug 7218 - How do I diagnose a Linuxconf Segmentation Fault
Summary: How do I diagnose a Linuxconf Segmentation Fault
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: linuxconf
Version: 6.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-22 06:56 UTC by George J. Johnson
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-12-07 15:27:04 UTC
Embargoed:


Attachments (Terms of Use)

Description George J. Johnson 1999-11-22 06:56:41 UTC
Linuxconf is consistantly giving a Segmentation Fault at startup.  This
occurs if it is executed as an app inside X or if it is executed from the
command line.

What information can I provide to help diagnose the problem?

Comment 1 Michael K. Johnson 1999-11-22 20:42:59 UTC
A backtrace is the first thing to try:
  su
  gdb /bin/linuxconf
  r
  bt

It's probably one of the modules broken; you can edit the /etc/conf.linuxconf
files and change, one at a time, the
module.list 1 <foo>
lines to
module.list 0 <foo>
Note: I suggest not modifying the treemenu or redhatppp lines, as I do
not think that they are implicated.  I would start by looking at samba,
wuftpd, apache, and dnsconf.  (You may not have all of those modules
listed, depending on what software you have installed.)

Comment 2 George J. Johnson 1999-11-23 06:49:59 UTC
I found that Linuxconf is abending when SAMBA = 1.  Attempted to use gdb to find
problem -- program exits with code 0377 and when I type "bt" the debugger
responds "no stack".

Comment 3 jack 1999-11-30 16:36:59 UTC
The treemenu build can be tought as a raw regression test. It is indeed
walking a lot of code in Linuxconf. Unfortunatly, when it fails, it is not
that helpful. In 1.16r10, the file /var/run/treemenu.log will be produced.
One line is appended (and flushed) to that file for every meny entry
processed. So if linuxconf fails while building its tree, we should have a clue
just by looking at that file. then we can disable the treemenu

	linuxconf --unsetmod treemenu

and access linuxconf is visit the offending menu, run a debugger or contact
the mailing list or me se we can track this problem.

Comment 4 Michael K. Johnson 1999-12-02 19:15:59 UTC
We'll be doing an official errata update based on 1.16r10 (or later)
after doing testing here, so we'll be able to use the treemenu.log
file to help figure out what's going wrong.

Comment 5 George J. Johnson 1999-12-06 21:34:59 UTC
It looks like Linuxconf embedded binary in the configuration files at some point
in time.  I am in the process of cleaning up the configuration files by hand --
is there a quick 'n' easy way to unpack just the configuration files to get a
clean copy?

I think that will be the easiest way for me to recover from this.

Comment 6 Michael K. Johnson 1999-12-06 22:43:59 UTC
I'm sorry, but I don't know what "the configuration files" are in this
context.

If you are talking about files like /etc/smb.conf, just remove them and
then reinstall the package (e.g. samba) with the --force option.  It
won't hurt that you'll be overwriting the other files as well.

Comment 7 George J. Johnson 1999-12-06 22:54:59 UTC
Thanks!  I'll go ahead with that solution.  I don't know what caused the
original corruption on the *.conf files -- if it happens again, I will document
what I was doing when the problem occurred and forward it to Bugzilla.

Go ahead and close out this problem.

Comment 8 Michael K. Johnson 1999-12-07 15:27:59 UTC
OK, sounds good.  If it happens again, particularly with the errata
release that we'll make Real Soon Now[tm] (I expect this week some
time), re-open this bug with as much information as you can find.
Thanks very much!

Comment 9 erik 1999-12-10 23:43:59 UTC
I had the problem that linuxconf would segv every time I ran it.  After getting
the source from the rpm and compiling it, I found that it was simply missing a
configuration file, /usr/lib/linuxconf/redhat/conf.daemons.  I copied it from
the source tree and it finally came up, although it was missing many daemon
locations.


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