GNU bug report logs - #6500
rm 8.1

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jim Meyering <jim <at> meyering.net>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#6500: closed (rm 8.1)
Date: Fri, 25 Jun 2010 05:18:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Fri, 25 Jun 2010 07:17:15 +0200
with message-id <876317u1wk.fsf <at> meyering.net>
and subject line Re: rm 8.1
has caused the GNU bug report #6500,
regarding rm 8.1
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
6500: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6500
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jim Meyering <jim <at> meyering.net>
To: Brad <b.mells <at> outwild.net>
Cc: bug-coreutils <at> gnu.org
Subject: Re: rm 8.1
Date: Wed, 23 Jun 2010 21:58:14 +0200

Brad wrote:
> Hi Jim:

Hi Brad,

I've Cc'd the bug-reporting address.
It's better to report problems to that address than to my personal one.

> Are you sure this is fixed?

How could I be sure it is fixed, considering
that this is the first I've heard of this failure?

> I get these errors:
> rm: ../../coreutils-8.5/lib/xfts.c:41: xfts_open: Assertion
> (*__errno_location ()) != 22' failed.
> Aborted
>
> chmod: ../../coreutils-8.5/lib/xfts.c:41: xfts_open: Assertion
> (*__errno_location ()) != 22' failed.
> Aborted
>
> du: ../../coreutils-8.5/lib/xfts.c:41: xfts_open: Assertion
> (*__errno_location ()) != 22' failed.
> Aborted
>
> It appears that the call to fts_open is failing but I do not
> understand the reason. All of the other utilities that don't use this
> function are still working fine.
>
> The system is running kernel 2.6.34 and the binaries are linked to
> glibc-2.11.2. I had to use slackware binaries for rm and chmod in
> order to get the system to boot. Clearly this is not right.
>
> If you have any ideas what might be wrong I would be glad to help fix
> this. I look forward to your input.

You seem to be hitting this assertion:

FTS *
xfts_open (char * const *argv, int options,
           int (*compar) (const FTSENT **, const FTSENT **))
{
  FTS *fts = fts_open (argv, options | FTS_CWDFD, compar);
  if (fts == NULL)
    {
      /* This can fail in two ways: out of memory or with errno==EINVAL,
         which indicates it was called with invalid bit_flags.  */
      assert (errno != EINVAL);
      xalloc_die ();
    }

  return fts;
}

Did you build the failing rm yourself?
From unmodified sources?
If so, please provide the precise ./configure and "make"
commands you used and tell us more about your system.

As far as I know, this is the first report of such a problem,
so I suspect something about your environment is at least "unusual".

There are only a few ways fts_open can return with errno
set to EINVAL, and none should be possible from coreutils programs:

FTS *
fts_open (char * const *argv,
          register int options,
          int (*compar) (FTSENT const **, FTSENT const **))
{
        register FTS *sp;
        register FTSENT *p, *root;
        register size_t nitems;
        FTSENT *parent = NULL;
        FTSENT *tmp = NULL;     /* pacify gcc */
        bool defer_stat;

        /* Options check. */
        if (options & ~FTS_OPTIONMASK) {
                __set_errno (EINVAL);
                return (NULL);
        }
        if ((options & FTS_NOCHDIR) && (options & FTS_CWDFD)) {
                __set_errno (EINVAL);
                return (NULL);
        }
        if ( ! (options & (FTS_LOGICAL | FTS_PHYSICAL))) {
                __set_errno (EINVAL);
                return (NULL);
        }

Can you debug it and tell us which one it is?

[Message part 3 (message/rfc822, inline)]

From: Jim Meyering <jim <at> meyering.net>
To: Brad <b.mells <at> outwild.net>
Cc: 6500-done <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
Subject: Re: rm 8.1
Date: Fri, 25 Jun 2010 07:17:15 +0200

Brad wrote:
> Hi Jim:
>
> After learning a little more about the debugger I was able to solve
> the problem.

Good.

> It is clear that the option test is not failing. However only one of
> three tests are being run because the code is linking to the new
> glibc. Therefore the program is calling the fts_open function defined

Think of this as a warning about your compiler and linker options.

> in glibc-2.11.2/io/fts.c rather than lib/fts.c (which does three
> options checks).
>
> 	/* Options check. */
> 	if (options & ~FTS_OPTIONMASK) {
> 		__set_errno (EINVAL);
> 		return (NULL);
> 	}
>
> 	/* Allocate/initialize the stream */
> 	if ((sp = malloc((u_int)sizeof(FTS))) == NULL)
> 		return (NULL);
>
> So the code is failing at the subsequent call to malloc. A
> segmentation fault is occurring because the glibc version of fts_open
> is incompatible with the new coreutils.
>
> I fixed this on my system by redefining fts_open() as
> _fts_open(). That way there is no pollution of the namespace.

Be careful.  That may well be insufficient,
in merely papering over the most apparent problem.

> Here are the diffs:
...
> I think that's it. It's probably not a good idea to redefine a
> function that's already defined in a linked library.

Actually, that's fine.

> The behavior is
> undefined in C because it depends upon the linkage order that is
> determined by the compiler.

This is the problem.
Don't link the C library (-lc) before a projects' own library
(lib/libcoreutils.a).

I'm marking this bug as resolved, but you're welcome
to reply if you have anything to add.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.