Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix test failures on hurd-i386. #6

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

sebastic
Copy link

@sebastic sebastic commented Jul 2, 2016

The following changes were required to fix the test failures on the GNU/Hurd build systems for the libfile-map-perl Debian package:

  • Make madvise() no-op, not implemented on Hurd.
  • Skip threads tests, thread implementation problematic.

@Leont
Copy link
Owner

Leont commented Jul 2, 2016

Make madvise() no-op, not implemented on Hurd.

That sounds perfectly reasonable.

Skip threads tests, thread implementation problematic.

That doesn't, at least not without knowing more about it. Can you give me a paste that shows the observed behavior? It feels wrong to me to skip the tests without changing any of the code.

@sebastic
Copy link
Author

sebastic commented Jul 2, 2016

The buildlog show that only the first test succeeds:

t/20-threads.t ... 
1..7
ok 1 - Counter is 2
Dubious, test returned 78 (wstat 19968, 0x4e00)
Failed 6/7 subtests 

@sebastic
Copy link
Author

sebastic commented Jul 3, 2016

I've added some debug output to t/20-threads.t and it shows that
ok(1, "First notification worked"); is never reached:

t/20-threads.t ... 
1..7
thread1 = async
Going to sleep
thread1: lock_map
thread1: wait_until
Done sleeping
do: lock_map
do: notify
thread1->join
thread1: is
ok 1 - Counter is 2
Dubious, test returned 78 (wstat 19968, 0x4e00)
Failed 6/7 subtests

The patch used:

--- a/t/20-threads.t
+++ b/t/20-threads.t
@@ -5,6 +5,7 @@ use warnings;
 use Config;
 BEGIN {
        # Yes, this is really necessary
+       #if ($Config{useithreads} && $^O ne 'gnu') {
        if ($Config{useithreads}) {
                require threads;
                threads->import();
@@ -28,31 +29,48 @@ my $counter;

 alarm 5;

+print "thread1 = async\n";
 my $thread1 = async {
+       print "thread1: lock_map\n";
        lock_map $variable;
+       print "thread1: wait_until\n";
        wait_until { $counter++ } $variable;
+       print "thread1: is\n";
        is($counter, 2, 'Counter is 2');
 };

+print "Going to sleep\n";
 sleep .1;
+print "Done sleeping\n";
 do {
+       print "do: lock_map\n";
        lock_map $variable;
+       print "do: notify\n";
        notify $variable;
 };
+print "thread1->join\n";
 $thread1->join;

 ok(1, "First notification worked");

+print "thread2 = async\n";
 my $thread2 = async {
+       print "thread2: lock_map\n";
        lock_map $variable;
+       print "thread2: wait_until\n";
        wait_until { $counter++ } $variable;
 };

+print "Going to sleep\n";
 sleep .1;
+print "Done sleeping\n";
 {
+       print "lock_map\n";
        lock_map $variable;
+       print "notify\n";
        notify $variable;
 }
+print "thread2->join\n";
 $thread2->join;

 ok(1, "Second notification worked");

@Leont
Copy link
Owner

Leont commented Jul 5, 2016

Could you give me a stacktrace of the sigalrm? and preferably for the other thread too (bt, info threads and thread <number> in gdb should help for this)

@sebastic
Copy link
Author

sebastic commented Jul 6, 2016

No, I cannot:

$ gdb -args perl Build test --verbose 1 --test_files t/20-threads.t             
GNU gdb (Debian 7.10-1+b1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from perl...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/perl Build test --verbose 1 --test_files t/20-threads.t
[New Thread 14322.5]
t/20-threads.t .. 
1..7
ok 1 - Counter is 2
Could not sync: Function not implemented during global destruction.
Dubious, test returned 78 (wstat 19968, 0x4e00)
Failed 6/7 subtests 

Test Summary Report
-------------------
t/20-threads.t (Wstat: 19968 Tests: 1 Failed: 0)
  Non-zero exit status: 78
  Parse errors: Bad plan.  You planned 7 tests but ran 1.
Files=1, Tests=1,  0 wallclock secs ( 0.03 usr +  0.00 sys =  0.03 CPU)
Result: FAIL
Failed 1/1 test programs. 0/1 subtests failed.
[Inferior 1 (bogus thread id 0) exited with code 0116]
(gdb) bt
No stack.
(gdb) info threads
No threads.
(gdb) thread 0
Thread ID 0 not known.
(gdb) 

@sebastic
Copy link
Author

sebastic commented Jul 6, 2016

I don't expect any actual users of File::Map on GNU/Hurd, so I'm not looking for a comprehensive fix.

I suggest to just skip the thread tests on Hurd, and spend our time on more worthwhile endeavors.

@Leont
Copy link
Owner

Leont commented Jul 6, 2016

gdb -args perl Build test --verbose 1 --test_files t/20-threads.t

I guess I should have given more specific instructions; that runs the debugger on the harness not on the test. gdb --args perl -Mblib t/20-threads.t should give an actualy backtrace.

I don't expect any actual users of File::Map on GNU/Hurd, so I'm not looking for a comprehensive fix.

It may point to a genuine bug in my code or in the tests; it may be broken on more systems.

I suggest to just skip the thread tests on Hurd, and spend our time on more worthwhile endeavors.

That kind of defeats the point of testing, doesn't it?

@sebastic
Copy link
Author

sebastic commented Jul 6, 2016

gdb --args perl -Mblib t/20-threads.t

That gives the same results as via Build test. The perl debugger is somewhat more informative:

$ perl Build test --verbose 1 --test_files t/20-threads.t --debugger 1
t/20-threads.t .. 
Loading DB routines from perl5db.pl version 1.49
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.


1..7
main::(t/20-threads.t:23):      map_anonymous my $variable, 1024;
  DB<1> n
main::(t/20-threads.t:25):      substr $variable, 0, 5, "Horse";
  DB<1> n
main::(t/20-threads.t:27):      my $counter;
  DB<1> n
main::(t/20-threads.t:29):      alarm 5;
  DB<1> n
main::(t/20-threads.t:35):      };
  DB<1> n
main::(t/20-threads.t:37):      sleep .1;
Thread 1 terminated abnormally: Trying to wait on an unlocked map at t/20-threads.t line 33.
 at /usr/share/perl/5.22/perl5db.pl line 4220 thread 1.
  DB<1> n
main::(t/20-threads.t:38):      do {
  DB<1> n
main::(t/20-threads.t:39):              lock_map $variable;
  DB<1> n
main::(t/20-threads.t:40):              notify $variable;
  DB<1> n
ok 1 - no (unexpected) warnings (via END block)
Debugged program terminated.  Use q to quit or R to restart,
use o inhibit_exit to avoid stopping after program termination,
h q, h R or h o to get additional info.
  DB<1> Trying to notify on an unlocked map at t/20-threads.t line 40.
 at t/20-threads.t line 40.
# Looks like you planned 7 tests but ran 1.
# Looks like your test exited with 29 just after 1.
n
Use 'q' to quit or 'R' to restart.  'h q' for details.
  DB<1> n
Use 'q' to quit or 'R' to restart.  'h q' for details.
  DB<1> Failed 6/7 subtests 

Test Summary Report
-------------------
t/20-threads.t (Wstat: 14 Tests: 1 Failed: 0)
  Non-zero wait status: 14
  Parse errors: Bad plan.  You planned 7 tests but ran 1.
Files=1, Tests=1,  8 wallclock secs ( 0.02 usr +  0.01 sys =  0.03 CPU)
Result: FAIL
Failed 1/1 test programs. 0/1 subtests failed.

- Make madvise() no-op, not implemented on Hurd.
- Skip threads tests, thread implementation problematic.
@sebastic
Copy link
Author

This issue is still present in 0.68.

@Leont
Copy link
Owner

Leont commented Mar 27, 2023

I guess I should just skip the test after all then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants