Bug#802593: gcl: FTBFS on hurd-i386

[Camm Maguire]

Greetings!  One other datum -- commands run fine under rpctrace, but not
without.

Take care,

Svante Signell  writes:

> On Thu, 2015-10-22 at 11:30 +0200, Svante Signell wrote:
>> Hi,
>> Cc: bug-hurd
>> 
>
>>  Running your test program at
>> https://lists.debian.org/debian-hurd/2013/07/msg00038.html
>> on a recent kernel gives an even lower limit for memory fragmentation.
>> 0x7000 fails now, and I used 0x6b00 in the latest build. The
>> acl2 assertion still happens. Builds of maxima, hol88 will be tried
>> next.
>
> Update:
> hol88 builds with one manual interrupt:
>
> Error: UNDEFINED-FUNCTION :NAME |CONTEXT_name|
> Fast links are on: do (si::use-fast-links nil) for debugging
> Signalled by %AP.
> UNDEFINED-FUNCTION :NAME |CONTEXT_name|
>
> Broken at %AP.  Type :H for Help.
> 1  Return to top level. 
>>>
> Error: UNBOUND-VARIABLE :NAME QUIT
> Fast links are on: do (si::use-fast-links nil) for debugging
> Signalled by %AP.
> UNBOUND-VARIABLE :NAME QUIT
>
> Broken at %AP.
> 1 (abort) Return to debug level 1. 
> 2  Return to top level. 

> NIL
 
> Makefile:36: recipe for target 'latex_type_pp.ml' failed
> make[4]: *** [latex_type_pp.ml] Error 255
> make[4]: Leaving directory
> '/home/srs/DEBs/hol88/hol88-2.02.19940316/Library/latex-hol'
>
> maxima still FTBFS at the same place.
>
> Seems like there are errors when running gcl for both packages:
> task(9610) decreasing a bogus port 1701869637 by 1, most probably a bug.
>
> For maxima:
> /bin/bash -c gcl -batch -eval '(progn (load
> "../lisp-utils/defsystem.lisp") (funcall (intern
> (symbol-name :operate-on-system) :mk) "maxima" :load :verbose t) (when
> (fboundp (quote si::sgc-on))(si::sgc-on t)) (si:save-system
> "binary-gcl/maxima"))'
>
> I tried to issue that command manually but it fails. How to run gcl from
> the commandline?
>
>
>
>
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#802593: gcl: FTBFS on hurd-i386

[Camm Maguire]

Greetings!  Are you still working on hurd?  The problem appears to have
shifted with recent hurd updates.  GCL no longer builds.  There is an
untrappable segfault on running gcc via system() which I cannot isolate
in gdb.  Suggestions?

Take care,

Svante Signell  writes:

> On Thu, 2015-10-22 at 11:30 +0200, Svante Signell wrote:
>> Hi,
>> Cc: bug-hurd
>> 
>
>>  Running your test program at
>> https://lists.debian.org/debian-hurd/2013/07/msg00038.html
>> on a recent kernel gives an even lower limit for memory fragmentation.
>> 0x7000 fails now, and I used 0x6b00 in the latest build. The
>> acl2 assertion still happens. Builds of maxima, hol88 will be tried
>> next.
>
> Update:
> hol88 builds with one manual interrupt:
>
> Error: UNDEFINED-FUNCTION :NAME |CONTEXT_name|
> Fast links are on: do (si::use-fast-links nil) for debugging
> Signalled by %AP.
> UNDEFINED-FUNCTION :NAME |CONTEXT_name|
>
> Broken at %AP.  Type :H for Help.
> 1  Return to top level. 
>>>
> Error: UNBOUND-VARIABLE :NAME QUIT
> Fast links are on: do (si::use-fast-links nil) for debugging
> Signalled by %AP.
> UNBOUND-VARIABLE :NAME QUIT
>
> Broken at %AP.
> 1 (abort) Return to debug level 1. 
> 2  Return to top level. 

> NIL
 
> Makefile:36: recipe for target 'latex_type_pp.ml' failed
> make[4]: *** [latex_type_pp.ml] Error 255
> make[4]: Leaving directory
> '/home/srs/DEBs/hol88/hol88-2.02.19940316/Library/latex-hol'
>
> maxima still FTBFS at the same place.
>
> Seems like there are errors when running gcl for both packages:
> task(9610) decreasing a bogus port 1701869637 by 1, most probably a bug.
>
> For maxima:
> /bin/bash -c gcl -batch -eval '(progn (load
> "../lisp-utils/defsystem.lisp") (funcall (intern
> (symbol-name :operate-on-system) :mk) "maxima" :load :verbose t) (when
> (fboundp (quote si::sgc-on))(si::sgc-on t)) (si:save-system
> "binary-gcl/maxima"))'
>
> I tried to issue that command manually but it fails. How to run gcl from
> the commandline?
>
>
>
>
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#802593: gcl: FTBFS on hurd-i386

[Svante Signell]

On Fri, 2015-10-23 at 12:00 +0200, Svante Signell wrote:
> On Thu, 2015-10-22 at 10:59 -0400, Camm Maguire wrote:
> > Greetings, and thanks again for your work on this!
> > 
> > Svante Signell  writes:
> > 

> > > maxima still FTBFS at the same place.
> > >
> > > Seems like there are errors when running gcl for both packages:
> > > task(9610) decreasing a bogus port 1701869637 by 1, most probably a bug.
> > 
> > Interesting.  My general experience has been lockups almost impossible
> > to debug and do anything but a kill -9.

> I managed to create a batch version, see attached maxima_commandline,
> and got an rpctrace (not attached, too big) and a gdb backtrace
> (maxima_gdb.txt). Seems like the bugs are in the memory protection
> parts.

Here is what the gnumach kernel debugger gave:
With the kernel debugger enabled for mach_port_deallocate_debug in
ipc/mach_port.c:
static volatile boolean_t mach_port_deallocate_debug = TRUE;

ps -feMw|grep 1125
 srs  1125  1113
0:12.19 
/home/srs/DEBs/gcl/gcl-2.6.12/debian/ansi/usr/lib/gcl-2.6.12/unixport/saved_ansi_gcl

Copied freely from the console output:
task ...nixport/saved_ansi_gcl(1125) decreasing a bogus port 877799456,
most probably a bug.
Debugger invoked: mach_port_mod_refs
Kernel Breakpoint trap, eip 0x801208f4
Stopped at softDebugger+0x13: int $3
SoftDebugger(801db7a3,1,f5f47ef4,8024834c)+0x13
mach_port_mod_refs(f5c99210,34522820,1,,f60c0e40)+0xc5
device_pager_server(f5d2c010,f5cc8010,1,0,1)+0x7bb
ipc_kobject_server(f5d2c000,1,0,0)+0x92
mach_msg_trap(1536a24,3,30,20,9b)+0x79c

trace/tu gave the same result.

Bug#802593: gcl: FTBFS on hurd-i386

[Svante Signell]

On Thu, 2015-10-22 at 10:59 -0400, Camm Maguire wrote:
> Greetings, and thanks again for your work on this!
> 
> Svante Signell  writes:
> 

> > Update:
> > hol88 builds with one manual interrupt:
> >
>> Makefile:36: recipe for target 'latex_type_pp.ml' failed
..
> 
> I think you might be using an older gcl, as the symbols have recently
> moved among different packages.  If you try the latest versions in
> debian sid with your sysconf patch for gcl, that should work.
>
> Otherwise, pleast let me know.

I do use the latest version of gcl.
I tried to issue the broken parts manually but failed with setting the
library_pathname():
source ../hol88_commandline
-bash: set_library_search_path
[`/home/srs/DEBs/hol88/hol88-2.02.19940316/Library`];;: No such file or
directory

cat hol88_commandline
#!/bin/sh
#set -x
#echo 'set_flag(`abort_when_fail`,true);;'\
'set_library_search_path
[`/home/srs/DEBs/hol88/hol88-2.02.19940316/Library`];;'\
'loadf(library_pathname() ^ `/prettyp/PP_printer`);;'\
'loadf(library_pathname() ^ `/prettyp/PP_parser`);;'\
'PP_to_ML false `latex_type` ``;;'\
'quit();;' | /home/srs/DEBs/hol88/hol88-2.02.19940316/hol

>From the build log and Library/latex-hol/Makefile 
##echo 'set_flag(`abort_when_fail`,true);;'\
#'loadf(library_pathname() ^ `/prettyp/PP_printer`);;'\
#'loadf(library_pathname() ^ `/prettyp/PP_parser`);;'\
#'PP_to_ML false `latex_type` ``;;'\
#'quit();;' | /home/srs/DEBs/hol88/hol88-2.02.19940316/hol

> > maxima still FTBFS at the same place.
> >
> > Seems like there are errors when running gcl for both packages:
> > task(9610) decreasing a bogus port 1701869637 by 1, most probably a bug.
> 
> Interesting.  My general experience has been lockups almost impossible
> to debug and do anything but a kill -9.

> From the maxima source tree you can do
> cd src
> GCL_ANSI=t gcl
> >(progn (load "../lisp-utils/defsystem.lisp") (funcall (intern (symbol-name 
> >:operate-on-system) :mk) "maxima" :load :verbose t) (when (fboundp (quote 
> >si::sgc-on))(si::sgc-on t)) (si:save-system "binary-gcl/maxima"))
> 
> You can also precede with (si::use-fast-links nil) if you want lisp
> debugging.

I managed to create a batch version, see attached maxima_commandline,
and got an rpctrace (not attached, too big) and a gdb backtrace
(maxima_gdb.txt). Seems like the bugs are in the memory protection
parts.

Interactively:
cd src
GCL_ANSI=t gcl
>(progn (load "../lisp-utils/defsystem.lisp") (funcall (intern (symbol-name 
>:operate-on-system) :mk) "maxima" :load :verbose t) (when (fboundp (quote 
>si::sgc-on))(si::sgc-on t)) (si:save-system "binary-gcl/maxima"))

Batch:
(cd src; GCL_ANSI=t gcl -batch -eval '(progn (load 
"../lisp-utils/defsystem.lisp") (funcall (intern (symbol-name 
:operate-on-system) :mk) "maxima" :load :verbose t) (when (fboundp (quote 
si::sgc-on))(si::sgc-on t)) (si:save-system "binary-gcl/maxima"))'; )

(cd src; GCL_ANSI=t rpctrace /usr/bin/gcl -batch -eval '(progn (load 
"../lisp-utils/defsystem.lisp") (funcall (intern (symbol-name 
:operate-on-system) :mk) "maxima" :load :verbose t) (when (fboundp (quote 
si::sgc-on))(si::sgc-on t)) (si:save-system "binary-gcl/maxima"))'; ) 2>&1 | 
tee rpctrace.out
In another window: kill -9 10895
ps -feM|grep srs
 srs 10894  9822  0:01.73 tee standard output rpctrace.out QUILT_REFRESH_AR
 srs 10895 10893  0:07.32 rpctrace /usr/bin/gcl -batch -eval (progn (load "
 srs 10896 10895  0:01.03 /usr/lib/gcl-2.6.12/unixport/saved_ansi_gcl -dir

gdb ~/DEBs/gcl/gcl-2.6.12/debian/ansi/usr/lib/gcl-2.6.12/unixport/saved_ansi_gcl
(gdb) run
Error: 
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by EVAL.
Condition in EVAL [or a callee]: INTERNAL-SIMPLE-UNBOUND-VARIABLE: Cell error 
on RUN: Unbound variable: 

Broken at EVAL.  Type :H for Help.
1  Return to top level. 
>>(progn (load "../lisp-utils/defsystem.lisp") (funcall (intern (symbol-name 
>>:operate-on-system) :mk) "maxima" :load :verbose t) (when (fboundp (quote 
>>si::sgc-on))(si::sgc-on t)) (si:save-system "binary-gcl/maxima"))
...
;  - Providing system maxima
[New Thread 1126.6]

Program received signal SIGSEGV, Segmentation fault.
0x080d94df in memprotect_test () at sgbc.c:425
425 for (;f1

Bug#802593: gcl: FTBFS on hurd-i386

[Svante Signell]

On Thu, 2015-10-22 at 11:30 +0200, Svante Signell wrote:
> Hi,
> Cc: bug-hurd
> 

>  Running your test program at
> https://lists.debian.org/debian-hurd/2013/07/msg00038.html
> on a recent kernel gives an even lower limit for memory fragmentation.
> 0x7000 fails now, and I used 0x6b00 in the latest build. The
> acl2 assertion still happens. Builds of maxima, hol88 will be tried
> next.

Update:
hol88 builds with one manual interrupt:

Error: UNDEFINED-FUNCTION :NAME |CONTEXT_name|
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by %AP.
UNDEFINED-FUNCTION :NAME |CONTEXT_name|

Broken at %AP.  Type :H for Help.
1  Return to top level. 
>>
Error: UNBOUND-VARIABLE :NAME QUIT
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by %AP.
UNBOUND-VARIABLE :NAME QUIT

Broken at %AP.
1 (abort) Return to debug level 1. 
2  Return to top level. 
>>>
NIL
>>> 
Makefile:36: recipe for target 'latex_type_pp.ml' failed
make[4]: *** [latex_type_pp.ml] Error 255
make[4]: Leaving directory
'/home/srs/DEBs/hol88/hol88-2.02.19940316/Library/latex-hol'

maxima still FTBFS at the same place.

Seems like there are errors when running gcl for both packages:
task(9610) decreasing a bogus port 1701869637 by 1, most probably a bug.

For maxima:
/bin/bash -c gcl -batch -eval '(progn (load
"../lisp-utils/defsystem.lisp") (funcall (intern
(symbol-name :operate-on-system) :mk) "maxima" :load :verbose t) (when
(fboundp (quote si::sgc-on))(si::sgc-on t)) (si:save-system
"binary-gcl/maxima"))'

I tried to issue that command manually but it fails. How to run gcl from
the commandline?

Bug#802593: gcl: FTBFS on hurd-i386

[Svante Signell]

Hi,
Cc: bug-hurd

On Wed, 2015-10-21 at 10:57 -0400, Camm Maguire wrote:
> Greetings, and thanks for your note!  Patch will be included in next
> upload.
> 
> Do you work on Hurd?  There are several FTBFS errors in gcl dependencies
> (maxima,hol88,axiom,acl2) which I have been unable to resolve and appear
> to point to bugs in system libraries (as did the old FTBFS for gcl in
> which calls to system() would fail.)  The general symptom appears to be
> a lockup of some sort in the rpc system (see maxima).  Can this be
> fixed, or must it wait on deeper forthcoming fixes in the core Hurd
> system libraries?

All the above packages (except axiom) FTBFS, even with the latest gcl
(2.6.12). The build of acl2 fails with an assertion on the MAX_BRK limit
for mini-proveall, defined in gcl/h/386-gnu.h. Removing that limitation
makes the build fail earlier. Running your test program at
https://lists.debian.org/debian-hurd/2013/07/msg00038.html
on a recent kernel gives an even lower limit for memory fragmentation.
0x7000 fails now, and I used 0x6b00 in the latest build. The
acl2 assertion still happens. Builds of maxima, hol88 will be tried
next.

Bug#802593: gcl: FTBFS on hurd-i386

[Camm Maguire]

Greetings, and thanks for following up on this!  Almost forgot about
that old post.

I suppose if this issue is intractable at the kernel level, we could
always emulate brk as we do on windows and macosx.  Not knowing where
the fragmentation occurs, its not clear this would get us true dynamic
probing of all the available memory at runtime which has proven so
helpful in optimizing gc performance.  If all else fails, we could just
hardcode a big allocation and make all instances run with that, as is
done on windows.  On the other hand, I'm loathe to put in the effort to
do this if brk can be fixed.  If you have any suggestions as to the best
path forward, that would be helpful.

Take care,

Svante Signell  writes:

> Hi,
> Cc: bug-hurd
>
> On Wed, 2015-10-21 at 10:57 -0400, Camm Maguire wrote:
>> Greetings, and thanks for your note!  Patch will be included in next
>> upload.
>> 
>> Do you work on Hurd?  There are several FTBFS errors in gcl dependencies
>> (maxima,hol88,axiom,acl2) which I have been unable to resolve and appear
>> to point to bugs in system libraries (as did the old FTBFS for gcl in
>> which calls to system() would fail.)  The general symptom appears to be
>> a lockup of some sort in the rpc system (see maxima).  Can this be
>> fixed, or must it wait on deeper forthcoming fixes in the core Hurd
>> system libraries?
>
> All the above packages (except axiom) FTBFS, even with the latest gcl
> (2.6.12). The build of acl2 fails with an assertion on the MAX_BRK limit
> for mini-proveall, defined in gcl/h/386-gnu.h. Removing that limitation
> makes the build fail earlier. Running your test program at
> https://lists.debian.org/debian-hurd/2013/07/msg00038.html
> on a recent kernel gives an even lower limit for memory fragmentation.
> 0x7000 fails now, and I used 0x6b00 in the latest build. The
> acl2 assertion still happens. Builds of maxima, hol88 will be tried
> next.
>
>
>
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#802593: gcl: FTBFS on hurd-i386

[Camm Maguire]

Greetings, and thanks again for your work on this!

Svante Signell  writes:

> On Thu, 2015-10-22 at 11:30 +0200, Svante Signell wrote:
>> Hi,
>> Cc: bug-hurd
>> 
>
>>  Running your test program at
>> https://lists.debian.org/debian-hurd/2013/07/msg00038.html
>> on a recent kernel gives an even lower limit for memory fragmentation.
>> 0x7000 fails now, and I used 0x6b00 in the latest build. The
>> acl2 assertion still happens. Builds of maxima, hol88 will be tried
>> next.
>
> Update:
> hol88 builds with one manual interrupt:
>
> Error: UNDEFINED-FUNCTION :NAME |CONTEXT_name|
> Fast links are on: do (si::use-fast-links nil) for debugging
> Signalled by %AP.
> UNDEFINED-FUNCTION :NAME |CONTEXT_name|
>
> Broken at %AP.  Type :H for Help.
> 1  Return to top level. 
>>>
> Error: UNBOUND-VARIABLE :NAME QUIT
> Fast links are on: do (si::use-fast-links nil) for debugging
> Signalled by %AP.
> UNBOUND-VARIABLE :NAME QUIT
>

I think you might be using an older gcl, as the symbols have recently
moved among different packages.  If you try the latest versions in
debian sid with your sysconf patch for gcl, that should work.
Otherwise, pleast let me know.

> Broken at %AP.
> 1 (abort) Return to debug level 1. 
> 2  Return to top level. 

> NIL
 
> Makefile:36: recipe for target 'latex_type_pp.ml' failed
> make[4]: *** [latex_type_pp.ml] Error 255
> make[4]: Leaving directory
> '/home/srs/DEBs/hol88/hol88-2.02.19940316/Library/latex-hol'
>
> maxima still FTBFS at the same place.
>
> Seems like there are errors when running gcl for both packages:
> task(9610) decreasing a bogus port 1701869637 by 1, most probably a bug.

Interesting.  My general experience has been lockups almost impossible
to debug and do anything but a kill -9.

>
> For maxima:
> /bin/bash -c gcl -batch -eval '(progn (load
> "../lisp-utils/defsystem.lisp") (funcall (intern
> (symbol-name :operate-on-system) :mk) "maxima" :load :verbose t) (when
> (fboundp (quote si::sgc-on))(si::sgc-on t)) (si:save-system
> "binary-gcl/maxima"))'
>
> I tried to issue that command manually but it fails. How to run gcl from
> the commandline?
>

>From the maxima source tree you can do
cd src
GCL_ANSI=t gcl
>(progn (load "../lisp-utils/defsystem.lisp") (funcall (intern (symbol-name 
>:operate-on-system) :mk) "maxima" :load :verbose t) (when (fboundp (quote 
>si::sgc-on))(si::sgc-on t)) (si:save-system "binary-gcl/maxima"))

You can also precede with (si::use-fast-links nil) if you want lisp
debugging.

Take care,
-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#802593: gcl: FTBFS on hurd-i386

[Camm Maguire]

Greetings, and thanks for your note!  Patch will be included in next
upload.

Do you work on Hurd?  There are several FTBFS errors in gcl dependencies
(maxima,hol88,axiom,acl2) which I have been unable to resolve and appear
to point to bugs in system libraries (as did the old FTBFS for gcl in
which calls to system() would fail.)  The general symptom appears to be
a lockup of some sort in the rpc system (see maxima).  Can this be
fixed, or must it wait on deeper forthcoming fixes in the core Hurd
system libraries?

Take care,
-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#802593: gcl: FTBFS on hurd-i386

[Svante Signell]

Source: gcl
Version: 2.6.12-25
Severity: important
Tags: patch
Usertags: hurd
User: debian-h...@lists.debian.org

Hello,

Currently gcl FTBFS on GNU/Hurd due to a missing #ifdef statement for
__GNU__ The attached patch solves this problem.

Thanks!

Index: gcl-2.6.12/o/main.c
===
--- gcl-2.6.12.orig/o/main.c
+++ gcl-2.6.12/o/main.c
@@ -179,7 +179,7 @@ get_phys_pages_no_malloc(char n) {
 
 }
 
-#elif defined(__sun__)
+#elif defined(__sun__) || defined(__GNU__)
 
 static ufixnum
 get_phys_pages_no_malloc(char n) {