Re: bug#25463: guile-2.0.13 Check errors

2017-03-06 Thread Ludovic Courtès 
Manolis Ragkousis  skribis:

> Hello Ludo, welcome back!
>
> On 03/06/2017 06:00 PM, Ludovic Courtès wrote:
>
>> Is it 100% reproducible if you run:
>> 
>>   ./check-guile 00-repl-server.test
>> 
>> from Guile’s build tree?
>> 
>> This test uses a Unix-domain socket, which on the Hurd means that
>> /servers/socket/3 (I think?) must have the right translator on it.
>> 
>> 00-socket.test also uses Unix-domain sockets.  Does it pass?
>> 
>> Looking more closely, it might be that one of the hunks of the patch
>> below solves the problem.  Could you try and report back?
>> 
>> (Looking at
>> , I
>> think ECONNRESET is more appropriate than ENOTCONN in the second case.)
>> 
>> HTH,
>> Ludo’.
>> 
>
> Since the last email I sent, I found out that I was getting ENOTCONN
> only after the second time I was running the test, and every time after
> that, unless I delete /tmp/repl-server.

Oh, interesting.

> The error you get the first time you run the test is
>
> FAIL: 00-repl-server.test: repl-server: simple expression - arguments:
> (expected-value "scheme@(repl-server)> $1 = 42\n" actual-value
> "scheme@(repl-server)> While reading expression:\nERROR: In procedure
> fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily
> unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
> procedure fport_fill_input: Resource temporarily unavailable\n$1 = 42\n")

Hmm!

> I am testing with "GUILE_LOAD_PATH=. ./guile-test

You mean ./check-guile, right?

> tests/00-initial-env.test tests/00-repl-server.test" and it's 100%
> reproducible if you delete /tmp/repl-server after each run.
> 00-socket.test passes each time successfully. Your patch doesn't solve
> the first error.

OK.

> Trying to debug the problem using rpctrace causes both tests to end with
> unresolved test cases. I am attaching the rpc-trace output.

[...]

> task192(pid5107)->mach_port_mod_refs (pn{ 46} 1 -1) = 0 
>   169<--197(pid5107)->io_write ("guile: ./pthread/pt-create.c:186: 
> __pthread_create_internal: Assertion `({ mach_" -1) = 0 225

This is the problem.  ↑

>   100<--196(pid5107)->dir_lookup ("servers/crash" 0 0) = 0 1 ""
> 207<--202(pid5107)
> task192(pid5107)->mach_port_mod_refs (pn{ 10} 0 1) = 0 
>   77<--147(pid5107)->dir_mkfile (18 384) = 0220<--210(pid5107)
>   207<--202(pid5107)->crash_dump_task ( task192(pid5107)
> 220<--210(pid5107) 4 0 0 2 13 0118<--281(pid5107)) ...238

It leads to a core dump…

> task133(pid5084)->mach_port_destroy (pn{ 49}) = 0 
> 238... = 0 
>   225<--265(pid-1)->msg_sig_post (20 1  task133(pid5084));
>   100<--250(pid5084)->dir_lookup ("tmp/repl-server" 0 0) ...238
> task133(pid5084)->mach_port_deallocate (pn{  1}) ...167
> 238... = 0 1 ""192<--221(pid5084)
> 167... = 0 
>   192<--221(pid5084)->ifsock_getsockaddr () = 0280<--220(pid5084)
> task133(pid5084)->mach_port_deallocate (pn{ 49}) = 0 
>   287<--266(pid5084)->socket_connect (   280<--220(pid5084)) = 0x403d 
> (Connection refused) 

… and subsequent connection attempts fail, hence “unresolved” test cases
I think.

Could you report the assertion failure to the Hurd folks?

Thanks for investigating!

Ludo’.

Re: bug#25463: guile-2.0.13 Check errors

2017-03-06 Thread Ludovic Courtès 
Hi Manolis,

Manolis Ragkousis  skribis:

> On 02/11/2017 11:03 PM, Ludovic Courtès wrote:
>> Hello!
>> 
>> ren...@openmailbox.org skribis:
>> 
>>> I am trying to build guile version 2.0.13 in GNU Hurd through Guix
>>> package manager, in the 'Check' phase I have 4 errors; I am attaching
>>> the build log(config.zip), environment
>>> variables(environment-variables) and test log(check-guile.zip).
>>>
>>> This is a grep of errors, any idea how I can deal with this?
>>>
>>> /*-*/
>>> ERROR: 00-repl-server.test: repl-server: simple expression -
>>> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
>>> is not connected") (1073741881)))
>>> ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
>>> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
>>> is not connected") (1073741881)))
>> 
>> The Guix package for Guile incorporates a patch that corresponds to
>> Guile commit 2fbde7f02adb8c6585e9baf6e293ee49cd23d4c4, which fixes a
>> race condition for these tests.
>> 
>
> While using guile 2.0.14, which has commit 2fbde7f02adb8c6, the bug is
> still present. Any ideas on what could be causing this Ludo?

Is it 100% reproducible if you run:

  ./check-guile 00-repl-server.test

from Guile’s build tree?

This test uses a Unix-domain socket, which on the Hurd means that
/servers/socket/3 (I think?) must have the right translator on it.

00-socket.test also uses Unix-domain sockets.  Does it pass?

Looking more closely, it might be that one of the hunks of the patch
below solves the problem.  Could you try and report back?

(Looking at
, I
think ECONNRESET is more appropriate than ENOTCONN in the second case.)

HTH,
Ludo’.

diff --git a/test-suite/tests/00-repl-server.test b/test-suite/tests/00-repl-server.test
index 4b5ec0cb3..0b4d0c6b0 100644
--- a/test-suite/tests/00-repl-server.test
+++ b/test-suite/tests/00-repl-server.test
@@ -62,7 +62,7 @@ socket connected to that server."
  (connect client-socket sockaddr))
(lambda args
  (when (memv (system-error-errno args)
- (list ENOENT ECONNREFUSED))
+ (list ENOENT ECONNREFUSED ENOTCONN))
(when (> tries 30)
  (throw 'unresolved))
(usleep 100)
@@ -139,7 +139,7 @@ reached."
   (loop (+ 1 n))
 (lambda args
   (->bool (memv (system-error-errno args)
-(list ECONNRESET EPIPE
+(list ECONNRESET EPIPE ENOTCONN
 
 ;;; Local Variables:
 ;;; eval: (put 'with-repl-server 'scheme-indent-function 1)

Re: bug#25463: guile-2.0.13 Check errors

2017-02-19 Thread Manolis Ragkousis 
Hello,

On 02/11/2017 11:03 PM, Ludovic Courtès wrote:
> Hello!
> 
> ren...@openmailbox.org skribis:
> 
>> I am trying to build guile version 2.0.13 in GNU Hurd through Guix
>> package manager, in the 'Check' phase I have 4 errors; I am attaching
>> the build log(config.zip), environment
>> variables(environment-variables) and test log(check-guile.zip).
>>
>> This is a grep of errors, any idea how I can deal with this?
>>
>> /*-*/
>> ERROR: 00-repl-server.test: repl-server: simple expression -
>> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
>> is not connected") (1073741881)))
>> ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
>> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
>> is not connected") (1073741881)))
> 
> The Guix package for Guile incorporates a patch that corresponds to
> Guile commit 2fbde7f02adb8c6585e9baf6e293ee49cd23d4c4, which fixes a
> race condition for these tests.
> 

While using guile 2.0.14, which has commit 2fbde7f02adb8c6, the bug is
still present. Any ideas on what could be causing this Ludo?

Manolis



export 
BASH_LOADABLES_PATH="/gnu/store/yp9sv3bxqmfs6ccwqpgrh4b1xgwfmgby-bash-4.4.11/lib/bash"
export 
CPLUS_INCLUDE_PATH="/gnu/store/kv1fll5g4d8i7fw6lpnfmvh0bpqx63xr-gcc-5.4.0/include:/gnu/store/f24mf0bhal2cq2d3gcmndc0q5vldm55z-glibc-2.23/include:/gnu/store/xv680p7pyv2cdx36asjy2vzwv71yxipc-file-boot0-5.28/include:/gnu/store/7iwm17i5fax2as55niv85rbwyx8ncyan-libffi-3.2.1/include:/gnu/store/lww8qzam6v020h7ln8b44c0k62dgprjq-readline-7.0/include:/gnu/store/l572k641i8416abxwnzrpmdp9rwx13gc-libunistring-0.9.7/include:/gnu/store/a4jvbp8c1y9jisr2xs4wjwshq76j11yr-libltdl-2.4.6/include:/gnu/store/ydf34bv6gw92nwhjg35clxchp72s4wj5-libgc-7.4.2/include:/gnu/store/x1rq5mdlbccsrdss6k4r9v00j8zbkp95-gmp-6.1.2/include:/gnu/store/s6578zzds1sksfxm78mdlwmvgizf5w3p-hurd-core-headers-0.9/include:/gnu/store/1qinaapzsx7ldf7pnlqrd9lmj5cwhz75-ncurses-6.0/include"
export 
C_INCLUDE_PATH="/gnu/store/kv1fll5g4d8i7fw6lpnfmvh0bpqx63xr-gcc-5.4.0/include:/gnu/store/f24mf0bhal2cq2d3gcmndc0q5vldm55z-glibc-2.23/include:/gnu/store/xv680p7pyv2cdx36asjy2vzwv71yxipc-file-boot0-5.28/include:/gnu/store/7iwm17i5fax2as55niv85rbwyx8ncyan-libffi-3.2.1/include:/gnu/store/lww8qzam6v020h7ln8b44c0k62dgprjq-readline-7.0/include:/gnu/store/l572k641i8416abxwnzrpmdp9rwx13gc-libunistring-0.9.7/include:/gnu/store/a4jvbp8c1y9jisr2xs4wjwshq76j11yr-libltdl-2.4.6/include:/gnu/store/ydf34bv6gw92nwhjg35clxchp72s4wj5-libgc-7.4.2/include:/gnu/store/x1rq5mdlbccsrdss6k4r9v00j8zbkp95-gmp-6.1.2/include:/gnu/store/s6578zzds1sksfxm78mdlwmvgizf5w3p-hurd-core-headers-0.9/include:/gnu/store/1qinaapzsx7ldf7pnlqrd9lmj5cwhz75-ncurses-6.0/include"
export 
GUILE_SYSTEM_COMPILED_PATH="/gnu/store/5bgjirxr6qgs8bpa3mn9j86x7nr6z652-guile-bootstrap-2.0/lib/guile/2.0/ccache"
export 
GUILE_SYSTEM_PATH="/gnu/store/5bgjirxr6qgs8bpa3mn9j86x7nr6z652-guile-bootstrap-2.0/share/guile/2.0"
export HOME="/homeless-shelter"
export LD_ORIGIN_PATH="/gnu/store"
export 
LIBRARY_PATH="/gnu/store/yp9sv3bxqmfs6ccwqpgrh4b1xgwfmgby-bash-4.4.11/lib:/gnu/store/f24mf0bhal2cq2d3gcmndc0q5vldm55z-glibc-2.23/lib:/gnu/store/xv680p7pyv2cdx36asjy2vzwv71yxipc-file-boot0-5.28/lib:/gnu/store/7iwm17i5fax2as55niv85rbwyx8ncyan-libffi-3.2.1/lib:/gnu/store/lww8qzam6v020h7ln8b44c0k62dgprjq-readline-7.0/lib:/gnu/store/l572k641i8416abxwnzrpmdp9rwx13gc-libunistring-0.9.7/lib:/gnu/store/a4jvbp8c1y9jisr2xs4wjwshq76j11yr-libltdl-2.4.6/lib:/gnu/store/ydf34bv6gw92nwhjg35clxchp72s4wj5-libgc-7.4.2/lib:/gnu/store/x1rq5mdlbccsrdss6k4r9v00j8zbkp95-gmp-6.1.2/lib:/gnu/store/s6578zzds1sksfxm78mdlwmvgizf5w3p-hurd-core-headers-0.9/lib:/gnu/store/1qinaapzsx7ldf7pnlqrd9lmj5cwhz75-ncurses-6.0/lib"
export NIX_BUILD_CORES="1"
export NIX_BUILD_TOP="/tmp/guix-build-guile-2.0.14.drv-0"
export NIX_STORE="/gnu/store"
export OLDPWD
export 
PATH="/gnu/store/0rqa4ls1g8m8km4nfqcsyadgw6jqqnsj-pkg-config-0.29.1/bin:/gnu/store/yp9sv3bxqmfs6ccwqpgrh4b1xgwfmgby-bash-4.4.11/bin:/gnu/store/kv1fll5g4d8i7fw6lpnfmvh0bpqx63xr-gcc-5.4.0/bin:/gnu/store/rpsm2lfadm8pl7cgyfkdw8dygvx2rdb2-ld-wrapper-boot3-0/bin:/gnu/store/f24mf0bhal2cq2d3gcmndc0q5vldm55z-glibc-2.23/bin:/gnu/store/f24mf0bhal2cq2d3gcmndc0q5vldm55z-glibc-2.23/sbin:/gnu/store/wn2z27fd0zzdyya5fq5si6q2j4ckjgzq-ld-wrapper-boot0-0/bin:/gnu/store/0d6x5r6vn48dr265krm83dsavhk5bs9m-binutils-cross-boot0-2.27/bin:/gnu/store/w570h7qvhd3qllm4wxrnrpjrxqwlflgb-make-boot0-4.2.1/bin:/gnu/store/5nznhj7fcv8whv1n24srmg0pcdf8d6qk-diffutils-boot0-3.5/bin:/gnu/store/1zvidsd4ynws9dc19g9drbzfmkv0gqas-findutils-boot0-4.6.0/bin:/gnu/store/xv680p7pyv2cdx36asjy2vzwv71yxipc-file-boot0-5.28/bin:/gnu/store/2vzzgpdpch9y2yqk257v6bq4yyszxi43-bootstrap-binaries-0/bin:/gnu/store/lww8qzam6v020h7ln8b44c0k62dgprjq-readline-7.0/bin:/gnu/store/s6578zzds1sksfxm78mdlwmvgizf5w3p-hurd-core-headers-0.9/bin:/gnu/store/1qinaapzsx7ldf7pnlqrd9lmj5cwhz75-ncurses-6.0/bin"
export 
PKG_CONFI

Re: bug#25463: guile-2.0.13 Check errors

2017-02-13 Thread Richard Braun 
On Sun, Feb 12, 2017 at 10:18:02PM +0100, Ludovic Courtès wrote:
> Manolis Ragkousis  skribis:
> 
> > Locally on Hurd I am using this patch
> > http://paste.lisp.org/display/338954 on the glibc/hurd package to work
> > around that test failure. Ideally we need to modify the way guile
> > handles time.[1]
> 
> Does ‘glibc/hurd’ have this patch in ‘core-updates’?  Should it?
> 
> Would it make sense to address this issue in Guile instead of libc,
> Richard?  I guess the answer depends on how many programs make this
> assumption besides Guile.

I'd say applications shouldn't be concerned with that, this problem
should remain solved by the system components, and libc (or procfs or
whatever) are the right places to deal with it.

See https://lists.gnu.org/archive/html/bug-hurd/2013-06/msg00089.html.

-- 
Richard Braun

Re: bug#25463: guile-2.0.13 Check errors

2017-02-12 Thread Ludovic Courtès 
Hello!

Manolis Ragkousis  skribis:

> Locally on Hurd I am using this patch
> http://paste.lisp.org/display/338954 on the glibc/hurd package to work
> around that test failure. Ideally we need to modify the way guile
> handles time.[1]

Does ‘glibc/hurd’ have this patch in ‘core-updates’?  Should it?

Would it make sense to address this issue in Guile instead of libc,
Richard?  I guess the answer depends on how many programs make this
assumption besides Guile.

Thanks,
Ludo’.

Re: bug#25463: guile-2.0.13 Check errors

2017-02-12 Thread Manolis Ragkousis 
Hello Renes,

On 02/12/17 10:37, ren...@openmailbox.org wrote:
> Now the following error is left:
> 
> Running time.test
> FAIL: time.test: internal-time-units-per-second: versus times and sleep
> Running tree-il.test
> 
> Totals for this test run:
> passes: 39537
> failures:   1
> unexpected passes:  0
> expected failures:  9
> unresolved test cases:  582
> untested test cases:1
> unsupported test cases: 10
> errors: 0
> 
> 

Locally on Hurd I am using this patch
http://paste.lisp.org/display/338954 on the glibc/hurd package to work
around that test failure. Ideally we need to modify the way guile
handles time.[1]

Manolis


[1]
https://lists.gnu.org/archive/html/bug-hurd/2015-10/msg00019.html

Re: bug#25463: guile-2.0.13 Check errors

2017-02-11 Thread Ludovic Courtès 
Hello!

ren...@openmailbox.org skribis:

> I am trying to build guile version 2.0.13 in GNU Hurd through Guix
> package manager, in the 'Check' phase I have 4 errors; I am attaching
> the build log(config.zip), environment
> variables(environment-variables) and test log(check-guile.zip).
>
> This is a grep of errors, any idea how I can deal with this?
>
> /*-*/
> ERROR: 00-repl-server.test: repl-server: simple expression -
> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
> is not connected") (1073741881)))
> ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
> arguments: ((system-error "fport_fill_input" "~A" ("Transport endpoint
> is not connected") (1073741881)))

The Guix package for Guile incorporates a patch that corresponds to
Guile commit 2fbde7f02adb8c6585e9baf6e293ee49cd23d4c4, which fixes a
race condition for these tests.

Could you check that this patch is really being used?

> ERROR: statprof.test: return values - arguments: ((system-error
> "setitimer" "~A" ("Function not implemented") (1073741902)))
> ERROR: statprof.test: statistical sample counts within expected range
> - 
> arguments: ((misc-error #f "~A" ("Can't reset profiler while profiler
> is running.") #f))
> ERROR: statprof.test: accurate call counting - arguments: ((misc-error
> #f "~A" ("Can't reset profiler while profiler is running.") #f))

This file uses a ‘when-implemented’ macro to skip tests upon ENOSYS
(“Function not implemented”).

The first of these 3 tests lacked it though, so I’ve added it in commit
f2764cb1031379c47a17c02fef3f8164a6ce9cda.

Could you run these tests manually to see what’s going on?  From the
top-level build tree of Guile, run:

  ./check-guile statprof.test

and see if it fails similarly.  If it does, you can add ‘display’ or
‘pk’ calls in the tests to see what’s going on.

HTH!

Ludo’.