Hello,
I found a problem while creating e2fsprogs rpms. Few of the tests
fail with segfault during make check. The tests are d_loaddump, f_dup4,
f_imagic_fs and r_resize_inode. This failure is only seen on rhel5,
x86_64.
On further searching I found that this error can reproduced when
e2fsprogs is configured with shared elf libraries. For example,
configure --enable-elf-shlibs, make; make check
And this problem is seen from 1.41.7 version onwards.
Any ideas/comments ?
Thanks,
Girish
The test failures from make check:
d_loaddump: debugfs load/dump test: ./d_loaddump/script: line 22: 12573
Segmentation fault $DEBUGFS -R "write $TEST_DATA test_data" -w
$TMPFILE >> $OUT.new 2>&1
./d_loaddump/script: line 34: 12577 Segmentation fault $DEBUGFS -R "dump test_data $VERIFY_DATA" $TMPFILE >> $OUT.new 2>&1
f_dup4: find all directory pathnames: ./f_dup4/script: line 41: 13359 Segmentation fault $DEBUGFS -w $TMPFILE > /dev/null 2>&1 <<EOF
f_imagic_fs: imagic filesystem with imagic inodes: ./run_e2fsck: line 48: 14602 Segmentation fault $DEBUGFS -w -R "feature imagic_inodes" $TMPFILE > /dev/null 2>&1
failed
_resize_inode: filesystem resize with a resize_inode present: ./r_resize_inode/script: line 101: 16093 Segmentation fault $DEBUGFS -R "set_super_value lastcheck 0" -w $TMPFILE > /dev/null 2>&1
./r_resize_inode/script: line 101: 16094 Segmentation fault $DEBUGFS -R "set_super_value hash_seed null" -w $TMPFILE > /dev/null 2>&1
./r_resize_inode/script: line 101: 16095 Segmentation fault $DEBUGFS -R "set_super_value mkfs_time 0" -w $TMPFILE > /dev/null 2>&1
ok
On Mon, Feb 08, 2010 at 01:01:26PM +0530, Girish Shilamkar wrote:
> Hello,
> I found a problem while creating e2fsprogs rpms. Few of the tests
> fail with segfault during make check. The tests are d_loaddump, f_dup4,
> f_imagic_fs and r_resize_inode. This failure is only seen on rhel5,
> x86_64.
> On further searching I found that this error can reproduced when
> e2fsprogs is configured with shared elf libraries. For example,
> configure --enable-elf-shlibs, make; make check
> And this problem is seen from 1.41.7 version onwards.
>
> Any ideas/comments ?
Well, I run "make check" all the time during the course of my
development, so it must be something unique with RHEL5.
#1) Does it show up if you just unpack a source tree, and do a
"configure; make; make check" run in RHEL 5?
#2) In the build directory, cd to tests, and then run the command:
(. $(srcdir)/tests/test_config; debugfs)
.. and see if you get a core dump. (Replace $(srcdir) with the top
level source tree directory. If you are building in the source tree,
you can just do "(. test_config ; debugfs)"; if you are building with
the build directory located in a "build" subdirectory under the source
tree, you could do "(. ../tests/test_config ; debugfs)", etc.
If you do get a core dump, run it under gdb and get a stack trace,
and/or see if anything is showing up in stderr that might be help
explain what's going on.
#3) Try downloading:
http://master.kernel.org/~tytso/e2fsprogs_1.41.10-rc1.tar.gz
... and see if you can see the problem there.
Thanks,
- Ted
On Mon, 2010-02-08 at 07:16 -0500, [email protected] wrote:
> Well, I run "make check" all the time during the course of my
> development, so it must be something unique with RHEL5.
That is the surprising part, no other distros had problem. Even
rhel5/i686 passes all the tests.
> #1) Does it show up if you just unpack a source tree, and do a
> "configure; make; make check" run in RHEL 5?
No, it doesn't show up. Problem appears when it is configured with
--enable-elf-shlibs !!
> #2) In the build directory, cd to tests, and then run the command:
>
> (. $(srcdir)/tests/test_config; debugfs)
>
> .. and see if you get a core dump. (Replace $(srcdir) with the top
> level source tree directory. If you are building in the source tree,
> you can just do "(. test_config ; debugfs)"; if you are building with
> the build directory located in a "build" subdirectory under the source
> tree, you could do "(. ../tests/test_config ; debugfs)", etc.
>
> If you do get a core dump, run it under gdb and get a stack trace,
> and/or see if anything is showing up in stderr that might be help
> explain what's going on.
Tried that before but there were no segfaults seen.
> #3) Try downloading:
>
> http://master.kernel.org/~tytso/e2fsprogs_1.41.10-rc1.tar.gz
>
> ... and see if you can see the problem there.
The problem is not seen for this version. Any tentative dates for 1.41.10 release ?
Thanks,
Girish
On Mon, Feb 08, 2010 at 07:50:17PM +0530, Girish Shilamkar wrote:
> > #3) Try downloading:
> >
> > http://master.kernel.org/~tytso/e2fsprogs_1.41.10-rc1.tar.gz
> >
> > ... and see if you can see the problem there.
> The problem is not seen for this version.
OK, so I'll treat this as "fixed in 1.41.10".
> Any tentative dates for 1.41.10 release ?
I'm working on the release notes right now. :-)
- Ted
[email protected] wrote:
> On Mon, Feb 08, 2010 at 01:01:26PM +0530, Girish Shilamkar wrote:
>> Hello,
>> I found a problem while creating e2fsprogs rpms. Few of the tests
>> fail with segfault during make check. The tests are d_loaddump, f_dup4,
>> f_imagic_fs and r_resize_inode. This failure is only seen on rhel5,
>> x86_64.
>> On further searching I found that this error can reproduced when
>> e2fsprogs is configured with shared elf libraries. For example,
>> configure --enable-elf-shlibs, make; make check
>> And this problem is seen from 1.41.7 version onwards.
>>
>> Any ideas/comments ?
>
> Well, I run "make check" all the time during the course of my
> development, so it must be something unique with RHEL5.
FWIW, it was make check segfaulting that led me to run valgrind
and find that array problem.
It's probably the flags that rpm builds with by default, doing
a better job at catching this sort of thing?
Girish Shilamkar wrote:
>> #3) Try downloading:
>> >
>> > http://master.kernel.org/~tytso/e2fsprogs_1.41.10-rc1.tar.gz
>> >
>> > ... and see if you can see the problem there.
> The problem is not seen for this version. Any tentative dates for 1.41.10 release ?
I'm guessing the problem was fixed by the resize2fs array
indexing patch.
-Eric