Phil Pennock | 8 Nov 2006 22:22

innfeed segfaults on NULL buffer in getBanner()

Hi,

I've checked archives and not seen anything about this.  I'm using
FreeBSD 6.1 on amd64, inn-2.4.3 and problem also present in
stable-20061024; gdb stack traces (with debugging information present)
and variable examinations below.

This is my first innd setup, so I fully accept that there may be a
misconfiguration somewhere; however, an innfeed coredump on attempting
to dereference a NULL pointer is why I'm posting to a workers list
anyway.

innfeed crashes on startup after connecting to the one current feed.
tcpdump confirms that the connection is made and the banner presented.
So I'm seeing coredumps every couple of seconds.

There are no articles to present, as there have been no posts to a
shared newsgroup yet.

If I post an article to alt.test, then innfeed is briefly stable, for 30
seconds, and logs that something happened, but my peer doesn't carry
alt.test, so it won't be accepted.  Sorry, trying to find a test group
on a public network which my peer carries.  ;^)

Is it likely that I'm doing something very silly?  Any debugging I can
do?  No secret passwords are present, I'm willing to provide innfeed and
coredump for further analysis.

Thanks,
-Phil
(Continue reading)

Adam J. Richter | 19 Nov 2006 10:13

Patch: include/paths.h --> include/inn/paths.h in inn-CURRENT

install /usr/include/paths.h, which conflicts with a file by the same
name installed by glibc.
	After installing inn, attempts to build many programs that
expect glibc's symbols in /usr/include/paths.h fail to compile,
including WorkBone, apmd, autofs, dosfstools, e2fsprogs, fileutils,
finger, fuse, gdm, gnome-vfs, inetutils, kdebase, kdemultimedia,
libgtop, libsdl, libzvt, libzvt2, lynx, magicdev, ncpfs, ntalk, ppp,
procps, routed, rpm, rusers, rwall, rwho, sessreg, sh-utils,
sliplogin, sysklogd, tcsh, vacation, vte, xine-lib, and zsh.

	At least in the case of inn-2.4.3, attempting to work around
the problem with "./configure --includedir=/usr/include/inn" results
in command syntax errors when "make install" is run, although I
suspect that this misbehavior might be related to the newly released
version of GNU sed, which I think may be stricter about regular
expression substitution than previous versions.

	This problem is acknowledged in the TODO file in the top level
of the inn distributions, and in a 2003 message on the inn-workers
mailing list at the following URL:

http://marc.10east.com/?l=inn-workers&m=105639025312796&w=2

	Given that this trivial problem has been around for years and
breaks the build of so many other program, I suggest that the following
patch or some refinement thereof be integrated promptly rather than
waiting for who knows how many more years for inn-2.5.

	This patch to inn-CURRENT moves include/paths.h to
include/inn/paths.h to avoid conflicts with glibc.  The changes were
(Continue reading)

Adam J. Richter | 19 Nov 2006 10:19

Patch: include/paths.h --> include/inn/paths.h in inn-STABLE

On Sun, Nov 19, 2006 at 05:13:36PM +0800, I wrote:
[...]
> 	This patch to inn-CURRENT moves include/paths.h to
> include/inn/paths.h to avoid conflicts with glibc. [...]
> 	I will also post a version of this patch against
> inn-STABLE-20061118 in a separate message to make it easier to
> extract the patches separately.

	Here is the version of the patch for inn-STABLE-20061118.

Adam Richter

Adam J. Richter | 19 Nov 2006 10:32

Re: Patch: include/paths.h --> include/inn/paths.h in inn-CURRENT

http://marc.10east.com/?l=inn-workers&m=105639025312796&w=2

	Given that this trivial problem has been around for years and
breaks the build of so many other program, I suggest that the following
patch or some refinement thereof be integrated promptly rather than
waiting for who knows how many more years for inn-2.5.

	This patch to inn-CURRENT moves include/paths.h to
include/inn/paths.h to avoid conflicts with glibc.  The changes were
made by manually editing the TODO file, and then running the following
shell commands from the top of the inn source tree:

mv include/paths.h.in include/inn/ 
for file in $(find . -type f | xargs grep -l paths.h) ; do
	ed $file << DONE
1,\$s|paths.h|inn/paths.h|g
w
q
DONE
done

	Because I do not run a news server at the moment, I have only
verified that inn with a default configuration on still compiles with
the patch applied, and with the glibc version of /usr/include/paths.h
installed, on x86 + linux-2.6.18 + glibc-2.5.  On the other hand, it's
an include file whose contents are not modified by the patch, so I
imagine you should be able to look it over, and check it in with few
modifications to the development branch at least.

	I will also post a version of this patch against
(Continue reading)

Adam J. Richter | 19 Nov 2006 10:35

Re: Patch: include/paths.h --> include/inn/paths.h in inn-STABLE

[]
	[Resending with the patch in the message body instead of a
MIME attachment so that the mail transfer agent or mail list software
at isc.org does not remove it.  --Adam]

On Sun, Nov 19, 2006 at 05:13:36PM +0800, I wrote:
[...]
> 	This patch to inn-CURRENT moves include/paths.h to
> include/inn/paths.h to avoid conflicts with glibc. [...]

> 	I will also post a version of this patch against
> inn-STABLE-20061118 in a separate message to make it easier to
> extract the patches separately.

	Here is the version of the patch for inn-STABLE-20061118.

Adam Richter

diff -u -r inn-STABLE-20061118/HACKING inn-STABLE/HACKING
--- inn-STABLE-20061118/HACKING	2006-11-18 18:07:18.000000000 +0800
+++ inn-STABLE/HACKING	2006-11-19 15:35:36.000000000 +0800
 <at>  <at>  -362,7 +362,7  <at>  <at> 
     generally always be used instead of the regular C versions.  libinn.h
     also provides various other utility functions that are frequently used.
 
-    paths.h includes a wide variety of paths determined at configure time,
+    inn/paths.h includes a wide variety of paths determined at configure time,
     both default paths to various parts of INN and paths to programs.  Don't
     just use the default paths, though, if they're also configurable in
     inn.conf; instead, call ReadInnConf() and use the global innconf
(Continue reading)

Adam J. Richter | 19 Nov 2006 10:46

Re: Patch: include/paths.h --> include/inn/paths.h in inn-CURRENT

	Grr.  Now the inn-workers mail list has chopped the beginning of
my message twice.  I am going to resend just the begining text, but this
time I'm going to use mailx instead of mutt, so that the message body
will not be encapsulated in MIME at all.  (By the way, I have been using
mutt for years with no problem like what I'm experiencing with the
isc.org mail servers, and I see that the copies of the messages that
I have bcc'ed myself are fine.)

	Here is the begining of the message, hopefully isc.org will not
chop it this time.

Adam Richter

|        [Is isc.org going to eat this line too?]
|
|        [It seems that isc.org's mail list handler ate the first line
|of the body of my message and removed the attached patch.  So, here is
|the message again, this time with the patch included in the message body.]
|
|        inn-2.4.3, inn-STABLE-20061118 and inn-CURRENT-20061118 each
|install /usr/include/paths.h, which conflicts with a file by the same
|name installed by glibc.
|
|        After installing inn, attempts to build many programs that
|expect glibc's symbols in /usr/include/paths.h fail to compile,
|including WorkBone, apmd, autofs, dosfstools, e2fsprogs, fileutils,
|finger, fuse, gdm, gnome-vfs, inetutils, kdebase, kdemultimedia,
|libgtop, libsdl, libzvt, libzvt2, lynx, magicdev, ncpfs, ntalk, ppp,
|procps, routed, rpm, rusers, rwall, rwho, sessreg, sh-utils,
|sliplogin, sysklogd, tcsh, vacation, vte, xine-lib, and zsh.
(Continue reading)

Adam J. Richter | 19 Nov 2006 13:29

script to move most of include/*.h to include/inn/*.h

	The following shell script, if executed in the top level of
the inn-CURRENT-20061118 source tree, moves all but one of the header
files currently in include/ to include/nntp/, and updates references to
these files.  The exception is include/nntp.h, since there is already
a different include/nntp/nntp.h.

	In the case of inn-CURRENT-20061118, I have verified that
if I build a source tree modified by this script and a pristine
source tree, and then strip all of the .o files in both trees, that
all of the .o files are unchanged.  I've also checked that
"./configure --prefix=/usr && make all && make install" still succeeds
after running this script.

	I suggest running it on the inn-CURRENT tree after applying
my patch to move include/paths.h.  (You could also just skip my
patch to move include/paths.h, as this will pick it up, but you
should still apply the minor manual update to inn/TODO that it
includes.)

	I imagine you could do the same thing to inn-CURRENT, but
I guess that is more of a policy question, as I am not sure that
there are any other conflicts currently caused by inn installing
files directly in /usr/include/, although it would not surprise
me to find something else also clobbering /usr/include/config.h.
Then again, since this change apparently compiles to the same
binaries, maybe that is good enough to get into inn-STABLE just
to minimize differences between STABLE and CURRENT.

Adam Richter

(Continue reading)

Jeffrey M. Vinocur | 19 Nov 2006 20:25

Re: script to move most of include/*.h to include/inn/*.h

On Sun, 19 Nov 2006, Adam J. Richter wrote:

> [...] any other conflicts currently caused by inn installing
> files directly in /usr/include/ [...]

Are you specifically configuring your INN to have this behavior?  Or 
perhaps using a distribution that has done so?  Our recommended 
configuration does not install anything into /usr/include.

--

-- 
Jeffrey M. Vinocur
jeff <at> litech.org

Russ Allbery | 19 Nov 2006 20:50
Picon
Favicon
Gravatar

Re: Patch: include/paths.h --> include/inn/paths.h in inn-CURRENT

Adam J Richter <adam <at> yggdrasil.com> writes:

> install /usr/include/paths.h, which conflicts with a file by the same
> name installed by glibc.

Don't install INN with a prefix of /usr or don't install INN's development
headers.

I'm not going to just move paths.h into an inn subdirectory
unconditionally; the header itself is broken in a lot of ways and the
whole concept needs to be redone.  When that's done, it will move into an
inn subdirectory.  In the meantime, I recommend simply not installing
INN's headers if you're packaging for a distribution; this has never been
really supported and there's more work that has to be done for it to be
supported than just this.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Russ Allbery | 19 Nov 2006 20:53
Picon
Favicon
Gravatar

Re: script to move most of include/*.h to include/inn/*.h

Adam J Richter <adam <at> yggdrasil.com> writes:

> 	The following shell script, if executed in the top level of
> the inn-CURRENT-20061118 source tree, moves all but one of the header
> files currently in include/ to include/nntp/, and updates references to
> these files.  The exception is include/nntp.h, since there is already
> a different include/nntp/nntp.h.

Same comment here -- many of those headers don't export clean interfaces
and need far more work than this.  Like proper shared library versioning,
this is one of those things that I'm holding off on doing something simple
and partial with because it doesn't solve the real underlying problems and
just gives the impression that something that isn't really supported
should work.

For example, the current nntp.h header needs to go away completely and be
replaced with the one in inn/nntp.h.

I'm sorry with the lack of progress on this; my free time to work on INN
has been seriously reduced of late and many things that I thought would be
done long ago are sadly still undone.  But even in that situation, giving
the impression that it's a good idea to package the INN development
environment and use it for other programs is not something I want to do;
there are a bunch of more subtle problems waiting to bite you.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
(Continue reading)


Gmane