Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

I've got here a strange case of find dying on me with SIGSEGV after printing
one line of output. I've located the following factors that seem to play a
role:

- LC_MESSAGES=C and LANG=de_DE.utf8
- Compiled with -O2
- --prefix=/usr so it can find installed files
- find called with arguments -type f -ls
- at least two files in current directory

The problem does not occur if I set either LC_MESSAGES or LC_CTYPE to de_DE, or
when I compile with -O0, or when I configure without arguments and don't
install that build, or when I drop either argument to find.

I've tryed to debug the issue. I traced the actual pagefault to an scenario
where due to a wrong address a function pointer gets incremented instead of a
simple integer counter. The address is four bytes off suggesting another
off-by-one error, but I couldn't trace that. It's very difficult to trace the
actual source of the error. Might possibly have security implications.

Created an attachment (id=127373) [details]
emerge --info

These might be steps to reproduce this issue:

tar xf /usr/portage/distfiles/findutils-4.3.8.tar.gz
cd findutils-4.3.8
./configure --prefix=/usr CFLAGS="-O2 -g"
make
cd ..
mkdir sandbox
cd sandbox
touch a b
env -i LANG=de_DE.utf8 LC_MESSAGES=C ../findutils-4.3.8/find/find -type f -ls

Please tell mewhether these steps work for you as well, at least if your arch
and gcc is the same I'd expect they should, but I'm not sure.

The expression will be parsed to a binary tree that looks like this in prefix
notation: "-a" ( "-a" ( NULL, "-type f" ( NULL, NULL ) ), "-ls" ( NULL, NULL )
)
You can get this from "find -D tree -type f -ls". My primary breakpoint while
debuggung this issue was apply_predicate. There you have a pointer p denoting
the current predicate, and from its elements you can get the whole subtree.

I found out that after prrinting ./a the expression "++(p->perf.successes);" in
apply_predicate used a wrong address and instead of incrementing that counter
incremented pred_ls which is the first element of struct predicate. The problem
is that the pointer p used to address this counter is stored in ebx in
apply_predicate, and somewhere in that register saving stuff I got lost.

Next I tried the other direction, to find out in what way the factors described
above influence the problem. I ltraced two calls and replaced all hexadecimal
numbers (which includes all those addresses that change with each run) so they
match. Diffing the result showed a difference in the setlocale result string,
in one bsearch call which I don't understand yet and then the SIGSEGV itself
caused by an fprintf(NULL, ...). So I guess it's going on somewhere in the
library itself, perhaps somewhere where the results from localeconv are used.

Could you please try editing lib/listfile.c and in the function list_file
change modebuf's size from 11 to 12? strmode as provided by gnulib initialises
elements 0 through 11, so a buffer of size 11 is insufficient. I'm not sure
this is what's causing your specific problem though.

Created an attachment (id=127395) [details]
findutils-4.3.8-overflow.patch

Works here as well. Did you find the impact of my environment, or was I just
unlucky enough to hit this, and there is no real connection?

How about this line "modebuf[10] = '\0';"? In the gnulib sources in that
tarball that character will always be a space, corresponding to the space added
by the fprintf in list file. So right now it doesn't make a difference. I'm not
sure about the relation between findutils and gnulib, whether they will stay in
touch and if not which one is more likely to introduce a + for files with ACLs.

Should this issue be reported upstream as well? Will you do so?

(In reply to comment #5)
> Works here as well.

I'm assuming you mean it still doesn't work :)

> Did you find the impact of my environment, or was I just
> unlucky enough to hit this, and there is no real connection?

It's very likely that you were just unlucky enough to hit this.

> How about this line "modebuf[10] = '\0';"? In the gnulib sources in that
> tarball that character will always be a space, corresponding to the space added
> by the fprintf in list file. So right now it doesn't make a difference.

By calling strmode, an extra byte on the stack will be set to zero, which could
with a specific compiler version and a specific optimisation level and specific
versions of all used headers be an important byte. The problem is often enough
something as simple as that, and as hard to trace as your own problem.

> I'm not
> sure about the relation between findutils and gnulib, whether they will stay in
> touch and if not which one is more likely to introduce a + for files with ACLs.
> 
> Should this issue be reported upstream as well?

If it is a bug in findutils, then yes, but it's good to rule out a rare bug in
the compiler and other parts of the environment first.

> Will you do so?

I'm not one of the maintainers of the Gentoo findutils package (I just have an
interest in it); normally, for system packages, the issue will be reported
upstream if/when the bug can be confirmed.

(In reply to comment #6)
> I'm assuming you mean it still doesn't work :)

???
That patch works as it fixes my local build, and with that fix find works as it
doesn't crash any more. So why would I mean it doesn't work?

> If it is a bug in findutils, then yes, but it's good to rule out a rare bug in
> the compiler and other parts of the environment first.

I guess we can be pretty sure that's a bug in findutils. Once you've looked at
it, it's pretty obvious that's going to break one day, and you only wonder why
it didn't do so earlier.

> I'm not one of the maintainers of the Gentoo findutils package (I just have an
> interest in it); normally, for system packages, the issue will be reported
> upstream if/when the bug can be confirmed.

On the other hand, you found the solution (and pretty quick at that,
considering how long I debugged that trying to write a better report. How did
you do it?), so the honour of presenting that fix to the upstream devs should
imho be yours. :-)

I thought you were saying your findutils still segfaulted in the rest of your
message, but I must have been misreading. I'm glad it's working.

> How did you do it?

I did little more than check how it ran when compiled with -fmudflap.

@base-system: I'd really prefer it if one of you would contact upstream about
this.

upstream has this fixed and ive merged that into 4.3.8-r1

*** Bug 187241 has been marked as a duplicate of this bug. ***