Project

General

Profile

Actions

Bug #5135

closed

Ruby 1.9.3-preview1 tests fails in Fedora Rawhide

Added by vo.x (Vit Ondruch) over 12 years ago. Updated over 12 years ago.

Status:
Closed
Target version:
ruby -v:
-
Backport:
[ruby-core:38653]

Description

It would be nice if all test are green before release.

https://gist.github.com/1118196


Files

ruby-fstest.out (1015 Bytes) ruby-fstest.out ruby fstest.rb > ruby-fstest.out vo.x (Vit Ondruch), 08/08/2011 05:27 PM
strace-fstest.out (110 KB) strace-fstest.out strace -v -o strace-fstest.out ruby fstest.rb vo.x (Vit Ondruch), 08/08/2011 05:27 PM
fstab (914 Bytes) fstab fstab vo.x (Vit Ondruch), 08/08/2011 05:27 PM
ruby-1.9.3-webrick-test-fix.patch (820 Bytes) ruby-1.9.3-webrick-test-fix.patch Anonymous, 11/10/2011 05:19 PM
ruby-1.9.3-webrick-test-fix.patch (812 Bytes) ruby-1.9.3-webrick-test-fix.patch Anonymous, 11/10/2011 05:37 PM

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

  • Status changed from Open to Assigned
  • Assignee set to kosaki (Motohiro KOSAKI)
  • Target version set to 1.9.3

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

Firstly, can you please run test after 'make install'?
Now some tests depend on it unfortunately.

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

  • Status changed from Assigned to Feedback

Fedora15 don't make any test failure. Can you please elaborate your platform change in rawhide?
I suspect about half of them are false positive failure. example, your test machine failed to find ps command
and made one test error (see below), but I don't think newest fedora don't have ps.

  1. Error:
    test_set_program_name(TestRubyOptions):
    Errno::ENOENT: No such file or directory - ps -p 20829 -o command

Updated by vo.x (Vit Ondruch) over 12 years ago

Actually I am building Ruby 1.9.3 from SRPM [1] in mock, i.e. using Koji [2]. Here [3] you can see the build output and the build failures (note that the output slightly differs, since the test are not stable for some reason I don't understand).

Also note that I am actually executing the test suite after "make install" as you can see either from the log [3] or from spec file [4], however it does not mean that the newly installed Ruby becomes available in the $PATH, which is probably what you expect.

[1] http://people.redhat.com/vondruch/ruby-1.9.3.review1-1.fcf17.src.rpm
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=3251502
[3] http://koji.fedoraproject.org/koji/getfile?taskID=3251503&name=build.log
[4] http://people.redhat.com/vondruch/ruby.spec

Updated by vo.x (Vit Ondruch) over 12 years ago

Motohiro KOSAKI wrote:

Fedora15 don't make any test failure. Can you please elaborate your platform change in rawhide?
I suspect about half of them are false positive failure. example, your test machine failed to find ps command
and made one test error (see below), but I don't think newest fedora don't have ps.

  1. Error:
    test_set_program_name(TestRubyOptions):
    Errno::ENOENT: No such file or directory - ps -p 20829 -o command

It is obvious from [1] that the minimal build root, which is used by mock, does not contain the 'procps' package, so adding BuildRequires: procps should fix this issue.

[1] http://koji.fedoraproject.org/koji/getfile?taskID=3251503&name=root.log

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

  • ruby -v changed from ruby 1.9.3dev (2011-07-31 revision 32789) [x86_64-linux] to -

2011/8/4 Vit Ondruch :

Issue #5135 has been updated by Vit Ondruch.

Motohiro KOSAKI wrote:

Fedora15 don't make any test failure. Can you please elaborate your platform change in rawhide?
I suspect about half of them are false positive failure.  example, your test machine failed to find ps command
and made one test error (see below), but I don't think newest fedora don't have ps.

  1. Error:
    test_set_program_name(TestRubyOptions):
    Errno::ENOENT: No such file or directory - ps -p 20829 -o command

It is obvious from [1] that the minimal build root, which is used by mock, does not contain the 'procps' package, so adding BuildRequires: procps should fix this issue.

[1] http://koji.fedoraproject.org/koji/getfile?taskID251503&name

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

And, below is rest comments.

  1. Failure:
    test_noctty(TestIO_Console) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/io/console/test_io_console.rb:183]:
    <["nil"]> expected but was
    <["#File:/dev/tty"]>.

Please confirm two points. 1) does your system have /dev/tty? 2) Does your SELinux policy disallow to access it?

  1. Failure:
    test_jobs_status(TestParallel::TestParallel) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/testunit/test_parallel.rb:174]:
  2. Failure:
    test_no_retry_option(TestParallel::TestParallel) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/testunit/test_parallel.rb:168]:
  3. Failure:
    test_should_retry_failed_on_workers(TestParallel::TestParallel) [/builddir/build/BUILD/ruby-1.9.3- 32) Failure:
  4. Failure:
    test_should_run_all_without_any_leaks(TestParallel::TestParallel) [/builddir/build/BUILD/ruby-1.9.3->
    preview1/test/testunit/test_parallel.rb:155]:

This four failure has already been fixed. see [Bug #5132]

DB->del: attempt to modify a read-only database

This is DB4 false positive warnings. Our test case intentionally try to modiry read-only database and check error code.
And DB4 makes annoying warnings everytimes. We don't have any idea to fix it.

Because of, ext/dbm support following dbm families.
db, db1, db2, db3, db4, db5, dbm, gdbm, qdbm,

Therefore we can only use common api sets in them. IOW, db4 specific hack is hard to be merged.
Do you have any idea?

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

Actually I am building Ruby 1.9.3 from SRPM [1] in mock, i.e. using Koji [2]. Here [3] you can see the build output and the build failures (note that the output slightly differs, since the test are not stable for some reason I don't understand).

Also note that I am actually executing the test suite after "make install" as you can see either from the log [3] or from spec file [4], however it does not mean that the newly installed Ruby becomes available in the $PATH, which is probably what you expect.

Yup, I expected.
I think following two test failure indicate such issue. This is hard
to fix properly because Webrick is micro web server. and adding
careless knob for loading another executable files
might make security issue in future.

Therefore I hope you avoid this issue by your test environment craft.

  1. Failure:
    test_cgi(TestWEBrickCGI)
    [/builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/test_cgi.rb:33]:
    webrick log start:
    [2011-08-04 08:47:33] INFO WEBrick 1.3.1
    [2011-08-04 08:47:33] INFO ruby 1.9.3 (2011-07-31) [x86_64-linux]
    [2011-08-04 08:47:33] INFO WEBrick::HTTPServer#start: pid'133 portR289
    [2011-08-04 08:47:33] ERROR CGIHandler:
    /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi:
    /builddir/build/BUILD/ruby-1.9.3-preview1/ruby: error while loading
    shared libraries: libruby.so.1.9: cannot open shared object file: No
    such file or directory
    [2011-08-04 08:47:33] ERROR CGIHandler:
    /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi
    exit with 127
    [2011-08-04 08:47:33] ERROR Premature end of script headers:
    /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi

webrick log end.
<"/webrick.cgi"> expected but was
<"\n\n

<TITLE>Internal Server Error</TITLE>\n \n

Internal Server Error

\n Premature end of script headers: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi\n
\n \n WEBrick/1.3.1 (Ruby/1.9.3/2011-07-31) OpenSSL/1.0.0d at\n 127.0.0.1:52289\n \n \n\n">. 52) Failure: test_script_disclosure(WEBrick::TestFileHandler) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/test_filehandler.rb:264]: webrick log start: [2011-08-04 08:47:47] INFO WEBrick 1.3.1 [2011-08-04 08:47:47] INFO ruby 1.9.3 (2011-07-31) [x86_64-linux] [2011-08-04 08:47:47] INFO WEBrick::HTTPServer#start: pid'133 portR263 [2011-08-04 08:47:47] ERROR CGIHandler: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi: /builddir/build/BUILD/ruby-1.9.3-preview1/ruby: error while loading shared libraries: libruby.so.1.9: cannot open shared object file: No such file or directory [2011-08-04 08:47:47] ERROR CGIHandler: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi exit with 127 [2011-08-04 08:47:47] ERROR Premature end of script headers: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi

webrick log end.
<"200"> expected but was
<"500">.

Updated by vo.x (Vit Ondruch) over 12 years ago

Motohiro KOSAKI wrote:

And, below is rest comments.

  1. Failure:
    test_noctty(TestIO_Console) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/io/console/test_io_console.rb:183]:
    <["nil"]> expected but was
    <["#File:/dev/tty"]>.

Please confirm two points. 1) does your system have /dev/tty? 2) Does your SELinux policy disallow to access it?

mock-chroot> ls -lZ /dev/tty
crw-rw-rw-. root tty unconfined_u:object_r:mock_var_lib_t:s0 /dev/tty

  1. Failure:
    test_jobs_status(TestParallel::TestParallel) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/testunit/test_parallel.rb:174]:
  2. Failure:
    test_no_retry_option(TestParallel::TestParallel) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/testunit/test_parallel.rb:168]:
  3. Failure:
    test_should_retry_failed_on_workers(TestParallel::TestParallel) [/builddir/build/BUILD/ruby-1.9.3- 32) Failure:
  4. Failure:
    test_should_run_all_without_any_leaks(TestParallel::TestParallel) [/builddir/build/BUILD/ruby-1.9.3->
    preview1/test/testunit/test_parallel.rb:155]:

This four failure has already been fixed. see [Bug #5132]

Great! I'll test them later.

DB->del: attempt to modify a read-only database

This is DB4 false positive warnings. Our test case intentionally try to modiry read-only database and check error code.
And DB4 makes annoying warnings everytimes. We don't have any idea to fix it.

Because of, ext/dbm support following dbm families.
db, db1, db2, db3, db4, db5, dbm, gdbm, qdbm,

Therefore we can only use common api sets in them. IOW, db4 specific hack is hard to be merged.
Do you have any idea?

I'll try to contact Fedora DB4 maintainer. May be he will have some idea ... Anyway that is just annoying notification, not test failure.

Updated by vo.x (Vit Ondruch) over 12 years ago

Vit Ondruch wrote:

Motohiro KOSAKI wrote:

DB->del: attempt to modify a read-only database

This is DB4 false positive warnings. Our test case intentionally try to modiry read-only database and check error code.
And DB4 makes annoying warnings everytimes. We don't have any idea to fix it.

Because of, ext/dbm support following dbm families.
db, db1, db2, db3, db4, db5, dbm, gdbm, qdbm,

Therefore we can only use common api sets in them. IOW, db4 specific hack is hard to be merged.
Do you have any idea?

I'll try to contact Fedora DB4 maintainer. May be he will have some idea ... Anyway that is just annoying notification, not test failure.

I was suggested by Jindrich Novy, the Fedora db4 maintainer, to implement own error handler, something along the lines:

dbp->set_errcall(dbp, my_error_handler);

void
my_error_handler(const char *error_prefix, char *msg)
{}

i.e. all errors will be suppressed.

Updated by naruse (Yui NARUSE) over 12 years ago

Motohiro KOSAKI wrote:

Actually I am building Ruby 1.9.3 from SRPM [1] in mock, i.e. using Koji [2]. Here [3] you can see the build output and the build failures (note that the output slightly differs, since the test are not stable for some reason I don't understand).

Also note that I am actually executing the test suite after "make install" as you can see either from the log [3] or from spec file [4], however it does not mean that the newly installed Ruby becomes available in the $PATH, which is probably what you expect.

Yup, I expected.
I think following two test failure indicate such issue.

Set environment variable like
RUBY=/builddir/build/BUILDROOT/ruby-1.9.3.review1-1.fc17.x86_64/usr/bin/ruby

This is hard
to fix properly because Webrick is micro web server. and adding
careless knob for loading another executable files
might make security issue in future.

Therefore I hope you avoid this issue by your test environment craft.

Some platform has the way to get the path of executing binary
even if I doubt that ruby should do it.

--
NARUSE, Yui

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

I was suggested by Jindrich Novy, the Fedora db4 maintainer, to implement own error handler, something along the lines:

dbp->set_errcall(dbp, my_error_handler);

void
my_error_handler(const char *error_prefix, char *msg)
{}

i.e. all errors will be suppressed.

I suspect this will break old dbm support. ;-)

Updated by vo.x (Vit Ondruch) over 12 years ago

Motohiro KOSAKI wrote:

I was suggested by Jindrich Novy, the Fedora db4 maintainer, to implement own error handler, something along the lines:

dbp->set_errcall(dbp, my_error_handler);

void
my_error_handler(const char *error_prefix, char *msg)
{}

i.e. all errors will be suppressed.

I suspect this will break old dbm support. ;-)

May be something conditional for DB4?

Updated by vo.x (Vit Ondruch) over 12 years ago

Yui NARUSE wrote:

Motohiro KOSAKI wrote:

Actually I am building Ruby 1.9.3 from SRPM [1] in mock, i.e. using Koji [2]. Here [3] you can see the build output and the build failures (note that the output slightly differs, since the test are not stable for some reason I don't understand).

Also note that I am actually executing the test suite after "make install" as you can see either from the log [3] or from spec file [4], however it does not mean that the newly installed Ruby becomes available in the $PATH, which is probably what you expect.

Yup, I expected.
I think following two test failure indicate such issue.

Set environment variable like
RUBY=/builddir/build/BUILDROOT/ruby-1.9.3.review1-1.fc17.x86_64/usr/bin/ruby

This is hard
to fix properly because Webrick is micro web server. and adding
careless knob for loading another executable files
might make security issue in future.

Therefore I hope you avoid this issue by your test environment craft.

Some platform has the way to get the path of executing binary
even if I doubt that ruby should do it.

--
NARUSE, Yui

I still can't find the way :/

mock-chroot> /builddir/build/BUILDROOT/ruby-1.9.3.review1-1.fc17.x86_64/usr/bin/ruby
/builddir/build/BUILDROOT/ruby-1.9.3.review1-1.fc17.x86_64/usr/bin/ruby: error while loading shared libraries: libruby.so.1.9: cannot open shared object file: No such file or directory

Lets specify the LD_LIBRARY_PATH for libruby.so.1.9:

mock-chroot> LD_LIBRARY_PATH=/builddir/build/BUILDROOT/ruby-1.9.3.review1-1.fc17.x86_64/usr/lib64/ /builddir/build/BUILDROOT/ruby-1.9.3.review1-1.fc17.x86_64/usr/bin/ruby
internal:gem_prelude:1:in require': cannot load such file -- rubygems.rb (LoadError) from <internal:gem_prelude>:1:in

Still fails but differently. So trying to execute the test if I moved forward a bit:

mock-chroot> LD_LIBRARY_PATH=/builddir/build/BUILDROOT/ruby-1.9.3.review1-1.fc17.x86_64/usr/lib64/ make test-all TESTS="-v test/webrick/*"

But it fails again:

  1. Failure:
    test_cgi(TestWEBrickCGI) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/test_cgi.rb:33]:
    webrick log start:
    [2011-08-04 14:17:57] INFO WEBrick 1.3.1
    [2011-08-04 14:17:57] INFO ruby 1.9.3 (2011-07-31) [x86_64-linux]
    [2011-08-04 14:17:57] INFO WEBrick::HTTPServer#start: pid=5774 port=49281
    [2011-08-04 14:17:57] ERROR CGIHandler: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi:
    /builddir/build/BUILD/ruby-1.9.3-preview1/ruby: error while loading shared libraries: libruby.so.1.9: cannot open shared object file: No such file or directory
    [2011-08-04 14:17:57] ERROR CGIHandler: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi exit with 127
    [2011-08-04 14:17:57] ERROR Premature end of script headers: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi

So the environment is not respected. I also tried the $RUBY but with no luck :/

Updated by nobu (Nobuyoshi Nakada) over 12 years ago

Hi,

At Thu, 4 Aug 2011 20:00:34 +0900,
Vit Ondruch wrote in [ruby-core:38786]:

  1. Failure:
    test_noctty(TestIO_Console) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/io/console/test_io_console.rb:183]:
    <["nil"]> expected but was
    <["#File:/dev/tty"]>.

Please confirm two points. 1) does your system have /dev/tty? 2) Does your SELinux policy disallow to access it?

mock-chroot> ls -lZ /dev/tty
crw-rw-rw-. root tty unconfined_u:object_r:mock_var_lib_t:s0 /dev/tty

That tests if a daemon process has no control tty. Maybe If
noclose is zero, daemon() on OpenBSD doesn't detach the ctty?

Can you try this patch?


diff --git a/test/io/console/test_io_console.rb
b/test/io/console/test_io_console.rb
index 233f57b..0945697 100644
--- a/test/io/console/test_io_console.rb
+++ b/test/io/console/test_io_console.rb
@@ -182,25 +182,32 @@ class TestIO_Console < Test::Unit::TestCase

case
when Process.respond_to?(:daemon)
  • def test_noctty
  •  assert_in_out_err(["-rio/console"],
    
  •                    "Process.daemon(true, true); p IO.console",
    
  •                    ["nil"])
    
  • end
  • noctty

Updated by vo.x (Vit Ondruch) over 12 years ago

Nobuyoshi Nakada wrote:

Can you try this patch?

mock-chroot> make test-all TESTS="test/io/console/test_io_console.rb"
./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems "./test/runner.rb" --ruby="./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" test/io/console/test_io_console.rb
Run options: "--ruby=./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems"

Running tests:

.............

Finished tests in 1.131890s, 11.4852 tests/s, 30.0383 assertions/s.

13 tests, 34 assertions, 0 failures, 0 errors, 0 skips

Updated by Anonymous over 12 years ago

Dne 4.8.2011 11:55, KOSAKI Motohiro napsal(a):

2011/8/4 Vit Ondruch:

Issue #5135 has been updated by Vit Ondruch.

Motohiro KOSAKI wrote:

Fedora15 don't make any test failure. Can you please elaborate your platform change in rawhide?
I suspect about half of them are false positive failure. example, your test machine failed to find ps command
and made one test error (see below), but I don't think newest fedora don't have ps.

  1. Error:
    test_set_program_name(TestRubyOptions):
    Errno::ENOENT: No such file or directory - ps -p 20829 -o command
    It is obvious from [1] that the minimal build root, which is used by mock, does not contain the 'procps' package, so adding BuildRequires: procps should fix this issue.

[1] http://koji.fedoraproject.org/koji/getfile?taskID=3251503&name=root.log
Hmm..

I suspect "adding BuildRequires" mean you plan to change SRPM build
information, right?
If so, I don't think this is good idea. Actually, now ruby's test
suite depend on procps, but ruby itself doesn't depend on it.

The best way is, you skip this test or send us a patch to fix the test script.

Thanks.

BuildRequires are just dependencies required for build, they do not
usually propagates into runtime dependencies. The typical example of
BuildRequires packages are the -devel packages, which contains header
files, but you don't need them for runtime.

Vit

Actions #18

Updated by nobu (Nobuyoshi Nakada) over 12 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 0 to 100

This issue was solved with changeset r32848.
Vit, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • test/io/console/test_io_console.rb (test_noctty): daemon() on
    OpenBSD seems not to detach the controlling terminal, when the
    argument noclose is non-zero. ref: [Bug #5135]

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

BuildRequires are just dependencies required for build, they do not usually
propagates into runtime dependencies. The typical example of BuildRequires
packages are the -devel packages, which contains header files, but you don't
need them for runtime.

Yes, I mean, ruby building process don't need procps. Only koji env require it.

Updated by vo.x (Vit Ondruch) over 12 years ago

Nobuyoshi Nakada wrote:

This issue was solved with changeset r32848.
Vit, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • test/io/console/test_io_console.rb (test_noctty): daemon() on
    OpenBSD seems not to detach the controlling terminal, when the
    argument noclose is non-zero. ref: [Bug #5135]

Nobu, you closed the issue but I am still fighting with four failed tests: https://gist.github.com/1127698

Updated by nobu (Nobuyoshi Nakada) over 12 years ago

  • Status changed from Closed to Feedback
  • % Done changed from 100 to 50

Sorry, "reference without close" seems not working since previous update of redmine.r.o.

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

Hi Vit

  • test/io/console/test_io_console.rb (test_noctty): daemon() on
      OpenBSD seems not to detach the controlling terminal, when the
      argument noclose is non-zero.  ref: [Bug #5135]

Nobu, you closed the issue but I am still fighting with four failed tests: https://gist.github.com/1127698

Following two failures seems point out a kernel issue. Can you please
elaborate your filesystem,
mount option, et al?
Also, please show us your kernel and glibc version.

  1. Failure:
    test_seek(TestDir)
    [/builddir/build/BUILD/ruby-1.9.3-preview1/test/ruby/test_dir.rb:39]:
    <".."> expected but was
    <"a">.
  2. Failure:
    test_set_pos(TestDir)
    [/builddir/build/BUILD/ruby-1.9.3-preview1/test/ruby/test_dir.rb:81]:
    <".."> expected but was
    <"a">.

And can you please try run following minimum script by using strace.


require 'fileutils'

setup

@root (cui_root cui)

Updated by vo.x (Vit Ondruch) over 12 years ago

mock-chroot> uname -a
Linux dhcp-25-40.brq.redhat.com 2.6.38.8-35.fc15.x86_64 #1 SMP Wed Jul 6 13:58:54 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -q kernel
kernel-2.6.38.8-35.fc15.x86_64

I am running on BTRFS filesystem.

Btw I have tried the build on Koji (official Fedora build system) and this two errors did not appeared there, but unfortunately there are others.
x86_64: http://koji.fedoraproject.org/koji/getfile?taskID=3257666&name=build.log
i686: http://koji.fedoraproject.org/koji/getfile?taskID=3257667&name=build.log

Interestingly, there appear again the bug fixed by Nobu in http://redmine.ruby-lang.org/projects/ruby-19/repository/revisions/32848

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

$ rpm -q kernel
kernel-2.6.38.8-35.fc15.x86_64

I am running on BTRFS filesystem.

[pos=0, name=.]
[pos=2, name=..]
[pos=2, name=a]

BTRFS IS buggy. ".." and "a" have the same offset. Sigh.
Of course, POSIX and linux vfs require every dir entry have unique offset.

The following function in btrfs is wrong.


static int btrfs_real_readdir(struct file *filp, void dirent,
filldir_t filldir)
{
(snip)
/
FIXME, use a real flag for deciding about the key type */
if (root->fs_info->tree_root == root)
key_type = BTRFS_DIR_ITEM_KEY;

     /* special case for "." */
     if (filp->f_pos == 0) {
             over = filldir(dirent, ".", 1, 1, btrfs_ino(inode), DT_DIR);
             if (over)
                     return 0;
             filp->f_pos = 1;
     }
     /* special case for .., just use the back ref */
     if (filp->f_pos == 1) {
             u64 pino = parent_ino(filp->f_path.dentry);
             over = filldir(dirent, "..", 2,
                            2, pino, DT_DIR);       /// HERE
             if (over)
                     return 0;
             filp->f_pos = 2;
     }

The correct parameter is

             over = filldir(dirent, "..", 2, 1, pino, DT_DIR);

If doubt, please read procfs code.

fs/proc/base.c

static int proc_readfd_common(struct file * filp, void * dirent,
filldir_t filldir, instantiate_t instantiate)
{
(snip)
switch (fd) {
case 0:
if (filldir(dirent, ".", 1, 0, inode->i_ino, DT_DIR) <
0)
goto out;
filp->f_pos++;
case 1:
ino = parent_ino(dentry);
if (filldir(dirent, "..", 2, 1, ino, DT_DIR) < 0)
goto out;
filp->f_pos++;

Thus, I'd like to switch this discussion to LKML. I'll make a patch soon.
See you again if you subscribe LKML.

Btw I have tried the build on Koji (official Fedora build system) and this two errors did not appeared there, but unfortunately there are others.
x86_64: http://koji.fedoraproject.org/koji/getfile?taskID=3257666&name=build.log
i686: http://koji.fedoraproject.org/koji/getfile?taskID=3257667&name=build.log

Interestingly, there appear again the bug fixed by Nobu in http://redmine.ruby-lang.org/projects/ruby-19/repository/revisions/32848

I'm sure it's unrelated.

Actions #25

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

  • Status changed from Feedback to Assigned
Actions #26

Updated by nobu (Nobuyoshi Nakada) over 12 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 50 to 100

This issue was solved with changeset r32848.
Vit, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • test/io/console/test_io_console.rb (test_noctty): daemon() on
    OpenBSD seems not to detach the controlling terminal, when the
    argument noclose is non-zero. ref: [Bug #5135]

Updated by vo.x (Vit Ondruch) over 12 years ago

Motohiro KOSAKI wrote:

Actually I am building Ruby 1.9.3 from SRPM [1] in mock, i.e. using Koji [2]. Here [3] you can see the build output and the build failures (note that the output slightly differs, since the test are not stable for some reason I don't understand).

Also note that I am actually executing the test suite after "make install" as you can see either from the log [3] or from spec file [4], however it does not mean that the newly installed Ruby becomes available in the $PATH, which is probably what you expect.

Yup, I expected.
I think following two test failure indicate such issue. This is hard
to fix properly because Webrick is micro web server. and adding
careless knob for loading another executable files
might make security issue in future.

Therefore I hope you avoid this issue by your test environment craft.

  1. Failure:
    test_cgi(TestWEBrickCGI)
    [/builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/test_cgi.rb:33]:
    webrick log start:
    [2011-08-04 08:47:33] INFO WEBrick 1.3.1
    [2011-08-04 08:47:33] INFO ruby 1.9.3 (2011-07-31) [x86_64-linux]
    [2011-08-04 08:47:33] INFO WEBrick::HTTPServer#start: pid'133 portR289
    [2011-08-04 08:47:33] ERROR CGIHandler:
    /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi:
    /builddir/build/BUILD/ruby-1.9.3-preview1/ruby: error while loading
    shared libraries: libruby.so.1.9: cannot open shared object file: No
    such file or directory
    [2011-08-04 08:47:33] ERROR CGIHandler:
    /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi
    exit with 127
    [2011-08-04 08:47:33] ERROR Premature end of script headers:
    /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi

webrick log end.
<"/webrick.cgi"> expected but was
<"\n\n

<TITLE>Internal Server Error</TITLE>\n \n

Internal Server Error

\n Premature end of script headers: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi\n
\n \n WEBrick/1.3.1 (Ruby/1.9.3/2011-07-31) OpenSSL/1.0.0d at\n 127.0.0.1:52289\n \n \n\n">. 52) Failure: test_script_disclosure(WEBrick::TestFileHandler) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/test_filehandler.rb:264]: webrick log start: [2011-08-04 08:47:47] INFO WEBrick 1.3.1 [2011-08-04 08:47:47] INFO ruby 1.9.3 (2011-07-31) [x86_64-linux] [2011-08-04 08:47:47] INFO WEBrick::HTTPServer#start: pid'133 portR263 [2011-08-04 08:47:47] ERROR CGIHandler: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi: /builddir/build/BUILD/ruby-1.9.3-preview1/ruby: error while loading shared libraries: libruby.so.1.9: cannot open shared object file: No such file or directory [2011-08-04 08:47:47] ERROR CGIHandler: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi exit with 127 [2011-08-04 08:47:47] ERROR Premature end of script headers: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi

webrick log end.
<"200"> expected but was
<"500">.

No matter what I am trying, the environment LD_LIBRARY_PATH environment variable is not propagated deep enough and I still get the error. Could help me please?

Updated by Anonymous over 12 years ago

Vit Ondruch wrote:

Motohiro KOSAKI wrote:

Actually I am building Ruby 1.9.3 from SRPM [1] in mock, i.e. using Koji [2]. Here [3] you can see the build output and the build failures (note that the output slightly differs, since the test are not stable for some reason I don't understand).

Also note that I am actually executing the test suite after "make install" as you can see either from the log [3] or from spec file [4], however it does not mean that the newly installed Ruby becomes available in the $PATH, which is probably what you expect.

Yup, I expected.
I think following two test failure indicate such issue. This is hard
to fix properly because Webrick is micro web server. and adding
careless knob for loading another executable files
might make security issue in future.

Therefore I hope you avoid this issue by your test environment craft.

  1. Failure:
    test_cgi(TestWEBrickCGI)
    [/builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/test_cgi.rb:33]:
    webrick log start:
    [2011-08-04 08:47:33] INFO WEBrick 1.3.1
    [2011-08-04 08:47:33] INFO ruby 1.9.3 (2011-07-31) [x86_64-linux]
    [2011-08-04 08:47:33] INFO WEBrick::HTTPServer#start: pid'133 portR289
    [2011-08-04 08:47:33] ERROR CGIHandler:
    /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi:
    /builddir/build/BUILD/ruby-1.9.3-preview1/ruby: error while loading
    shared libraries: libruby.so.1.9: cannot open shared object file: No
    such file or directory
    [2011-08-04 08:47:33] ERROR CGIHandler:
    /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi
    exit with 127
    [2011-08-04 08:47:33] ERROR Premature end of script headers:
    /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi

webrick log end.
<"/webrick.cgi"> expected but was
<"\n\n

<TITLE>Internal Server Error</TITLE>\n \n

Internal Server Error

\n Premature end of script headers: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi\n
\n \n WEBrick/1.3.1 (Ruby/1.9.3/2011-07-31) OpenSSL/1.0.0d at\n 127.0.0.1:52289\n \n \n\n">. 52) Failure: test_script_disclosure(WEBrick::TestFileHandler) [/builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/test_filehandler.rb:264]: webrick log start: [2011-08-04 08:47:47] INFO WEBrick 1.3.1 [2011-08-04 08:47:47] INFO ruby 1.9.3 (2011-07-31) [x86_64-linux] [2011-08-04 08:47:47] INFO WEBrick::HTTPServer#start: pid'133 portR263 [2011-08-04 08:47:47] ERROR CGIHandler: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi: /builddir/build/BUILD/ruby-1.9.3-preview1/ruby: error while loading shared libraries: libruby.so.1.9: cannot open shared object file: No such file or directory [2011-08-04 08:47:47] ERROR CGIHandler: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi exit with 127 [2011-08-04 08:47:47] ERROR Premature end of script headers: /builddir/build/BUILD/ruby-1.9.3-preview1/test/webrick/webrick.cgi

webrick log end.
<"200"> expected but was
<"500">.

No matter what I am trying, the environment LD_LIBRARY_PATH environment variable is not propagated deep enough and I still get the error. Could help me please?

I believe that I have found a solution to this problem. The proposed patch is in the attached file.

Updated by Anonymous over 12 years ago

Bohuslav Kabrda wrote:

I believe that I have found a solution to this problem. The proposed patch is in the attached file.
And here is maybe a bit more systematic solution.

Updated by nobu (Nobuyoshi Nakada) over 12 years ago

You should use RbConfig::CONFIG["LIBPATHENV"] instead of hardcoded "LD_LIBRARY_PATH".

Updated by Anonymous over 12 years ago

Nobuyoshi Nakada wrote:

You should use RbConfig::CONFIG["LIBPATHENV"] instead of hardcoded "LD_LIBRARY_PATH".

Sorry, didn't notice I can use that, here is the proposed patch: https://gist.github.com/1357452

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

  • Status changed from Closed to Assigned

Sorry, didn't notice I can use that, here is the proposed patch: https://gist.github.com/1357452

If nobody put objection, I'll commit it. I'm waiting awhile.

Actions #33

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

  • Status changed from Assigned to Closed

This issue was solved with changeset r33730.
Vit, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • test/webrick/test_cgi.rb (class TestWEBrickCGI): respect
    RbConfig::CONFIG["LIBPATHENV"]. [Bug #5135] [ruby-core:38653]
  • test/webrick/test_filehandler.rb (class WEBrick): ditto.
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0