Bug 157274 - misc/findutils: gfind segmentation fault: 11 (core dumped)
Summary: misc/findutils: gfind segmentation fault: 11 (core dumped)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-23 17:50 UTC by Fabian Wenk
Modified: 2011-06-04 20:10 UTC (History)
0 users

See Also:


Attachments
patch-gnulib__lib__fdopendir.c (352 bytes, text/x-csrc; charset=us-ascii)
2011-05-30 22:47 UTC, Klaus Aehlig
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Wenk 2011-05-23 17:50:11 UTC
After a portupgrade done yesterday gfind core dumps, previous version findutils-4.5.9_1 worked just fin.

FreeBSD find does work:
root@batman:~# which find
/usr/bin/find
root@batman:~# find . -name .profile
./.profile
root@batman:~#

findutils find core dumps:
root@batman:~# which gfind
/usr/local/bin/gfind
root@batman:~# gfind . -name .profile
Segmentation fault: 11 (core dumped)
root@batman:~# 

root@batman:~# gfind
Comment 1 Fabian Wenk 2011-05-23 18:05:45 UTC
The part after the . at the starting of the line got cut away, 
here it is:

root@batman:~# gfind
.
Segmentation fault: 11 (core dumped)
root@batman:~# ls -l gfind.core
-rw-------  1 root  wheel  2236416 May 23 18:34 gfind.core
root@batman:~#

root@batman:~# gdb /usr/local/bin/gfind -core gfind.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, 
and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging 
symbols found)...
Core was generated by `gfind'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libintl.so.9...(no debugging 
symbols found)...done.
Loaded symbols for /usr/local/lib/libintl.so.9
Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging 
symbols found)...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libm.so.5...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libc.so.7...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0000000800b5a620 in telldir () from /lib/libc.so.7
(gdb) bt
#0  0x0000000800b5a620 in telldir () from /lib/libc.so.7
#1  0x000000000041a5da in fts_open ()
#2  0x000000000041b1fb in fts_read ()
#3  0x000000000040386f in ?? ()
#4  0x0000000000403fc3 in ?? ()
#5  0x00000000004032de in ?? ()
#6  0x0000000800565000 in ?? ()
#7  0x0000000000000000 in ?? ()
#8  0x0000000000000000 in ?? ()
#9  0x0000000000000001 in ?? ()
#10 0x00007fffffffed30 in ?? ()
#11 0x0000000000000000 in ?? ()
#12 0x00007fffffffed36 in ?? ()
#13 0x00007fffffffed50 in ?? ()
#14 0x00007fffffffed61 in ?? ()
#15 0x00007fffffffed98 in ?? ()
#16 0x00007fffffffedab in ?? ()
#17 0x00007fffffffedb5 in ?? ()
#18 0x00007fffffffede3 in ?? ()
#19 0x00007fffffffedee in ?? ()
#20 0x00007fffffffee03 in ?? ()
#21 0x00007fffffffee23 in ?? ()
#22 0x00007fffffffee7a in ?? ()
#23 0x00007fffffffee8e in ?? ()
#24 0x00007fffffffee9a in ?? ()
#25 0x00007fffffffeea4 in ?? ()
#26 0x00007fffffffeeb4 in ?? ()
#27 0x00007fffffffeebc in ?? ()
#28 0x00007fffffffeec7 in ?? ()
#29 0x00007fffffffeed4 in ?? ()
#30 0x00007fffffffef22 in ?? ()
#31 0x00007fffffffef70 in ?? ()
#32 0x00007fffffffef87 in ?? ()
#33 0x0000000000000000 in ?? ()
#34 0x0000000000000003 in ?? ()
#35 0x0000000000400040 in ?? ()
#36 0x0000000000000004 in ?? ()
#37 0x0000000000000038 in ?? ()
#38 0x0000000000000005 in ?? ()
#39 0x0000000000000007 in ?? ()
#40 0x0000000000000006 in ?? ()
#41 0x0000000000001000 in ?? ()
#42 0x0000000000000008 in ?? ()
#43 0x0000000000000000 in ?? ()
#44 0x0000000000000009 in ?? ()
#45 0x0000000000403250 in ?? ()
#46 0x0000000000000007 in ?? ()
#47 0x000000080053a000 in ?? ()
#48 0x000000000000000f in ?? ()
#49 0x00007fffffffffab in ?? ()
#50 0x0000000000000000 in ?? ()
#51 0x0000000000000000 in ?? ()
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) quit
root@batman:~#
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2011-05-30 00:58:13 UTC
Hi,
Fabian: Would it be possible for you to build the port with debugging
symbols (WITH_DEBUG="yes" in /etc/make.conf or -DWITH_DEBUG as an
argument to make) in order to get a useful backtrace? We are unable to
reproduce the problem and this would help us to fix the issue.

Klaus: the automailer didn't kick in, but this PR relates to your
port: misc/findutils.


-- 
Eitan Adler
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2011-05-30 01:43:24 UTC
State Changed
From-To: open->feedback
Comment 4 Klaus Aehlig 2011-05-30 15:33:37 UTC
Hi,

I finally managed to reproduce the bug. It seems to be
base-system specific; at least, all my attempts to reproduce
it on my 8.2-STABLE amd64 machine failed. 

However, the following "worked". I took a fresh virtual machine
and installed a minimal 7.3-RELEASE amd64[1]. Taking an up-to-date
ports tree (as of this morning[2]) and installing misc/findutils from 
there produced a /usr/local/bin/gfind that would core dump.

I got the following stack backtrace.

# gdb /usr/local/bin/gfind gfind.core 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `gfind'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libintl.so.9...done.
Loaded symbols for /usr/local/lib/libintl.so.9
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0000000800b6f620 in telldir () from /lib/libc.so.7
(gdb) where
#0  0x0000000800b6f620 in telldir () from /lib/libc.so.7
#1  0x000000000042467d in fts_build (sp=0x800d0e080, type=3) at fts.c:1356
#2  0x000000000042338f in fts_read (sp=0x800d0e080) at fts.c:891
#3  0x000000000040420a in find (arg=0x7fffffffeb40 ".") at ftsfind.c:567
#4  0x000000000040431f in process_all_startpoints (argc=0, argv=0x7fffffffebe8) at ftsfind.c:632
#5  0x000000000040448a in main (argc=1, argv=0x7fffffffebe0) at ftsfind.c:725
(gdb) 

I'll investigate further.

Best,
Klaus



[1] Using FreeBSD-7.3-RELEASE-amd64-disc1.iso
MD5 (FreeBSD-7.3-RELEASE-amd64-disc1.iso) = 7c5049d15a95d9e0dd5eca013d1086b8

[2] ctm cvs-cur 17507
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2011-05-30 16:11:36 UTC
State Changed
From-To: feedback->open

feedback received
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2011-05-30 16:13:37 UTC
---------- Forwarded message ----------
From: Klaus T. Aehlig <aehlig@linta.de>
Date: Mon, May 30, 2011 at 2:33 PM
Subject: Re: ports/157274: misc/finutils: gfind segmentation fault: 11
(core dumped)
To: Eitan Adler <lists@eitanadler.com>
Cc: bug-followup@freebsd.org, fabian@wenks.ch



Hi,

I finally managed to reproduce the bug. It seems to be
base-system specific; at least, all my attempts to reproduce
it on my 8.2-STABLE amd64 machine failed.

However, the following "worked". I took a fresh virtual machine
and installed a minimal 7.3-RELEASE amd64[1]. Taking an up-to-date
ports tree (as of this morning[2]) and installing misc/findutils from
there produced a /usr/local/bin/gfind that would core dump.

I got the following stack backtrace.

# gdb /usr/local/bin/gfind gfind.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you ar=
e
welcome to change it and/or distribute copies of it under certain condition=
s.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. =C2=A0Type "show warranty" for det=
ails.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `gfind'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libintl.so.9...done.
Loaded symbols for /usr/local/lib/libintl.so.9
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 =C2=A00x0000000800b6f620 in telldir () from /lib/libc.so.7
(gdb) where
#0 =C2=A00x0000000800b6f620 in telldir () from /lib/libc.so.7
#1 =C2=A00x000000000042467d in fts_build (sp=3D0x800d0e080, type=3D3) at ft=
s.c:1356
#2 =C2=A00x000000000042338f in fts_read (sp=3D0x800d0e080) at fts.c:891
#3 =C2=A00x000000000040420a in find (arg=3D0x7fffffffeb40 ".") at ftsfind.c=
:567
#4 =C2=A00x000000000040431f in process_all_startpoints (argc=3D0,
argv=3D0x7fffffffebe8) at ftsfind.c:632
#5 =C2=A00x000000000040448a in main (argc=3D1, argv=3D0x7fffffffebe0) at ft=
sfind.c:725
(gdb)

I'll investigate further.

Best,
Klaus



[1] Using FreeBSD-7.3-RELEASE-amd64-disc1.iso
MD5 (FreeBSD-7.3-RELEASE-amd64-disc1.iso) =3D 7c5049d15a95d9e0dd5eca013d108=
6b8

[2] ctm cvs-cur 17507



--=20
Eitan Adler
Comment 7 Klaus Aehlig 2011-05-30 18:46:12 UTC
Hi,

further investigations (thanks to Helmut Grohne who helped me) on my
7.3-RELEASE virtual machine showed that gfind does the following sequence
of libc-calls, which seg faults on 7.3-RELEASE, but not on 8.2-STABLE:
open, fdopendir, readdir.

I could construct the following minimal example, which I belive should
not cause a segmentation fault, but does on 7.3-RELEASE.

# uname -a
FreeBSD  7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 05:25:24 UTC 2010     root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
# cat testfdopendir.c 
#include <fcntl.h>
#include <sys/types.h>
#include <dirent.h>

int main(int argc, char **argv) {
        DIR *dirp;
        int fd;

        fd = open(".",  O_RDONLY);
        dirp = fdopendir(fd);
        (void) readdir(dirp);

}

# cc testfdopendir.c 
testfdopendir.c: In function 'main':
testfdopendir.c:10: warning: assignment makes pointer from integer without a cast
# ./a.out
Segmentation fault (core dumped)
# 

Also note the compiler warning, that suggests that including <sys/types.h>
and <dirent.h> does not seem to suffice---as opposed what the man page
tells---to get the fdopendir prototype. I believe that is a bug in 
RELENG_7_3_0.

Eitan: can you please inform the appropriate maintainer about this 
bug (if it is not fixed already in an errata for 7.3-RELEASE)?

Unfortunately, the obvious patch does not yet solve the problem, so I
have to investigate further. But I thought, I'd still report back 
the problem with the libc headers.

Best,
Klaus
Comment 8 Klaus Aehlig 2011-05-30 22:47:23 UTC
Hi again,

the misssing prototype _was_ the problem. I just got confused
by the various #ifdef's in that file. On my 7.3-RELEASE
adding the attached patch to the files directory (and bumping
PORTREVISION) solves the problem.

Fabian: can you please verify that this solves the problem
for you as well?

Eitan: can you please assign this PR to someone so that the
change gets committed (or commit it yourself)?

Best,
Klaus

PS:
The incomplete header on 7.3-RELEASE should be fixed
nevertheless. Whom to forward this observation?
Comment 9 Fabian Wenk 2011-05-31 20:18:51 UTC
Hello Klaus

On 30.05.11 23:47, Klaus T. Aehlig wrote:
> Fabian: can you please verify that this solves the problem
> for you as well?

Yes, this solves it on both my 7.3-RELEASE-p4 / amd64, and also on 
my friends 7.3-RELEASE-p2 / amd64 and on his 8.1-RELEASE / i386.


bye
Fabian
Comment 10 Eitan Adler freebsd_committer freebsd_triage 2011-06-01 03:25:14 UTC
Hi,

I'm sorry I did not see this conversation until now.

Firstly, great job on debugging this problem!

Secondly, FreeBSD doesn't "assign" bugs, rather comitters take them.

Thirdly, this patch appears to fix the issue for me as well on my
virtual machine just add to the "verified" list :-)

Fourthly, At this point you have a patch in the PR and it appears to
be fix the issue. My understanding is that you would like added to the
files/ directory of the port. If that is the case leave the PR as is
and I will set it to the appropriate state. It may take a bit of time
before a committer sees this patch. I will do what I can to
facilitate. Unfortunately I can not commit this patch, as I am not a
ports committer.

> Eitan: can you please assign this PR to someone so that the
> change gets committed (or commit it yourself)?
>
> Best,
> Klaus
>
> PS:
> The incomplete header on 7.3-RELEASE should be fixed
> nevertheless. Whom to forward this observation?
>



-- 
Eitan Adler
Comment 11 dfilter service freebsd_committer freebsd_triage 2011-06-04 20:02:56 UTC
arved       2011-06-04 19:02:48 UTC

  FreeBSD ports repository

  Modified files:
    misc/findutils       Makefile 
  Added files:
    misc/findutils/files patch-gnulib-lib-fdopendir.c 
  Log:
  Fix a segfault on 7.x amd64
  
  PR:             157274
  Reported by:    Fabian Wenk
  Submitted by:   maintainer
  
  Revision  Changes    Path
  1.46      +1 -1      ports/misc/findutils/Makefile
  1.1       +15 -0     ports/misc/findutils/files/patch-gnulib-lib-fdopendir.c (new)
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 12 Tilman Keskinoz freebsd_committer freebsd_triage 2011-06-04 20:03:07 UTC
State Changed
From-To: open->closed

Committed, thanks