stack overflow

stack overflow

[Rainer Tammer]

Hello,
I tried to build GUILE 1.8.3 on AIX 6.1 with the IBM XL C/C++ 9.0 compiler.
During the build I get the following error:


./guile_filter_doc_snarfage --filter-snarfage) > regex-posix.doc || { rm 
regex-posix.doc; false; }
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc 
continuations.doc  debug.doc \
    deprecation.doc deprecated.doc discouraged.doc dynl.doc dynwind.doc 
environments.doc eq.doc \
    error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc 
fports.doc futures.doc \
    gc.doc goops.doc gsubr.doc gc-mark.doc gc-segment.doc gc-malloc.doc 
gc-card.doc guardians.doc hash.doc \
    hashtab.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc 
lang.doc list.doc load.doc macros.doc \
    mallocs.doc modules.doc numbers.doc objects.doc objprop.doc 
options.doc pairs.doc ports.doc print.doc \
    procprop.doc procs.doc properties.doc random.doc rdelim.doc read.doc 
root.doc rw.doc scmsigs.doc \
    script.doc simpos.doc smob.doc sort.doc srcprop.doc stackchk.doc 
stacks.doc stime.doc strings.doc \
    srfi-4.doc srfi-13.doc srfi-14.doc strorder.doc strports.doc 
struct.doc symbols.doc threads.doc \
    throw.doc values.doc variable.doc vectors.doc version.doc vports.doc 
weaks.doc ramap.doc unif.doc \
    dynl.doc filesys.doc posix.doc net_db.doc socket.doc regex-posix.doc \
    | GUILE="/daten/source/test/guile-1.8.3/pre-inst-guile" \
    ../scripts/snarf-check-and-output-texi          > \
    guile-procedures.texi || { rm guile-procedures.texi; \ false; }
ERROR: Stack overflow
gmake[3]: *** [guile-procedures.texi] Error 1

the stack overflow is caused by the "pre-inst-guile"

# ./pre-inst-guile
Backtrace:
In unknown file:
   ?: 65* [#<procedure #f ()>]
   ?: 66* (let* ((file #)) (cond (# => #) (# => #)))
   ?: 67  [#<procedure #f (full)> 
"/daten/source/test/guile-1.8.3/ice-9/null.scm"]
   ?: 68  [with-fluid* #<fluid 7> #f #<procedure #f ()>]
   ?: 69* [#<procedure #f ()>]
   ?: 70* [load-file #<primitive-procedure primitive-load> ...]
   ?: 71* [save-module-excursion #<procedure #f ()>]
   ?: 72  (let (# #) (dynamic-wind # thunk #))
   ?: 73  [dynamic-wind #<procedure #f ()> #<procedure #f ()> 
#<procedure #f ()>]
   ?: 74* [#<procedure #f ()>]
   ?: 75* [primitive-load "/daten/source/test/guile-1.8.3/ice-9/null.scm"]
In /daten/source/test/guile-1.8.3/ice-9/null.scm:
  20: 76* (define-module (ice-9 null) :use-module ...)
In unknown file:
   ?: 77* [copy-tree ...
   ?: 78* [apply #<procedure #f args> ((ice-9 null) :use-module (ice-9 
syncase) ...)]
   ?: 79  [#<procedure #f args> (ice-9 null) :use-module ...]
   ?: 80  (quasiquote (eval-case (# #) (else #)))
   ?: 81* [compile-define-module-args ((ice-9 null) :use-module (ice-9 
syncase) ...)]
   ?: 82  ((letrec ((loop #)) loop) (quasiquote ((quote #))) (cdr args))
   ?: 83* (letrec ((loop (lambda # #))) loop)
   ?: 84* (lambda (compiled-args args) (cond (# #) (# #) (# #) ...))

<unnamed port>: In expression (lambda (compiled-args args) (cond # # ...)):
<unnamed port>: Stack overflow

Bye
  Rainer

Re: stack overflow

[Ludovic Courtès]

Hi Rainer,

Rainer Tammer <tammer@tammer.net> writes:

> I tried to build GUILE 1.8.3 on AIX 6.1 with the IBM XL C/C++ 9.0 compiler.
> During the build I get the following error:
>
>
> ./guile_filter_doc_snarfage --filter-snarfage) > regex-posix.doc || {

[...]

> In /daten/source/test/guile-1.8.3/ice-9/null.scm:
>  20: 76* (define-module (ice-9 null) :use-module ...)
> In unknown file:
>   ?: 77* [copy-tree ...
>   ?: 78* [apply #<procedure #f args> ((ice-9 null) :use-module (ice-9 
> syncase) ...)]
>   ?: 79  [#<procedure #f args> (ice-9 null) :use-module ...]
>   ?: 80  (quasiquote (eval-case (# #) (else #)))
>   ?: 81* [compile-define-module-args ((ice-9 null) :use-module (ice-9 
> syncase) ...)]
>   ?: 82  ((letrec ((loop #)) loop) (quasiquote ((quote #))) (cdr args))
>   ?: 83* (letrec ((loop (lambda # #))) loop)
>   ?: 84* (lambda (compiled-args args) (cond (# #) (# #) (# #) ...))
>
> <unnamed port>: In expression (lambda (compiled-args args) (cond # # ...)):
> <unnamed port>: Stack overflow

A couple of ideas:

  1. What `CFLAGS' are you using?  In particular, are optimizations
     enabled?

     With GCC, compiling without optimizations usually yields a Guile
     that stack-overflows because the evaluator would use so much stack
     space that the default stack limit is quickly hit.  You could have
     the same problem with IBM's xlc, so make sure to enable
     optimizations.

     Actually, `configure' only adds `-O2' when GCC is being used, so
     I'm pretty sure it's up to you to pass `configure' or `make' the
     right CFLAGS, e.g.,

       CFLAGS="-the-option-that-enables-optimizations" ./configure

     If that fixes the problem, then we can change `configure' to use,
     e.g., `AX_COMPILER_VENDOR' [0] to automatically add optimization
     options that correspond to the compiler being used.

  2. Is it a 64-bit platform?

     If so, it may be the case that the default stack limit (see
     `debug-options') is about two times smaller than what you need.

Thanks,
Ludovic.

[0] http://autoconf-archive.cryp.to/ax_compiler_vendor.html

Re: stack overflow

[Ludovic Courtès]

Hi,

ludo@gnu.org (Ludovic Courtès) writes:

>        CFLAGS="-the-option-that-enables-optimizations" ./configure

It seems that `-qtune=auto' would make it.

Best of all, we could directly use `AX_CC_MAXOPT' to solve this:

  http://autoconf-archive.cryp.to/ax_cc_maxopt.html

Thanks,
Ludovic.

Re: stack overflow

[Rainer Tammer]

Hello,

Ludovic Courtès wrote:
> Hi,
>
> ludo@gnu.org (Ludovic Courtès) writes:
>
>   
>>        CFLAGS="-the-option-that-enables-optimizations" ./configure
>>     
>
> It seems that `-qtune=auto' would make it.
>
>   
I added -qtune=auto but this did not solve the problem...
I will try other optimization settings...
> Best of all, we could directly use `AX_CC_MAXOPT' to solve this:
>
>   http://autoconf-archive.cryp.to/ax_cc_maxopt.html
>
> Thanks,
> Ludovic.
>
>
>
>   
Bye
  Rainer

Re: stack overflow

[Ludovic Courtès]

Hi,

Rainer Tammer <tammer@tammer.net> writes:

> I added -qtune=auto but this did not solve the problem...
> I will try other optimization settings...

You did "make clean all" after reconfiguring with your `CFLAGS', right?
Also, do the actual compilation command lines show that your `CFLAGS'
settings were taken into account?

Besides, you can try adding "(debug-set! stack 40000)" to your
`~/.guile' and see if that makes a difference, and increase it until it
works, just to get an idea.

Thanks,
Ludovic.

Re: stack overflow / partial success

[Rainer Tammer]

[-- Attachment #1: Type: text/plain, Size: 6470 bytes --]

Hello,
I managed to compile GUILE 1.8.3+ fixes on AIX 6.1 with IBM XL C/C++ 9.0.

Compiler settings:

export CONFIG_SHELL=/usr/bin/bash
export CONFIG_ENV_ARGS=/usr/bin/bash
export CC=cc_r
export CXX=xlC_r
export PATH=/opt/freeware/bin:$PATH
export LDFLAGS="-Wl,-brtl -L/opt/freeware/lib"
export CFLAGS="-D_USE_IRS -Dinline=__inline__ -qtune=auto -O2
-I/opt/freeware/include"

./configure --enable-dynamic-linking --prefix=/opt/freeware
--enable-shared --disable-static


.guile
(debug-set! stack 40000)

Test results:

gmake  check-TESTS
gmake[4]: Entering directory
`/daten/source/test/guile-1.8.3/test-suite/standalone'
PASS: test-system-cmds
PASS: test-require-extension
PASS: test-num2integral
PASS: test-round
PASS: test-gh
PASS: test-asmobs
PASS: test-list
PASS: test-unwind
PASS: test-conversion
PASS: test-use-srfi
===================
All 10 tests passed
===================

Testing /daten/source/test/guile-1.8.3/pre-inst-guile ...
with GUILE_LOAD_PATH=/daten/source/test/guile-1.8.3/test-suite
Running alist.test
Running and-let-star.test
Running arbiters.test
Running bit-operations.test
Running c-api.test
Running chars.test
Running common-list.test
Running continuations.test
Running elisp.test
Running environments.test
UNRESOLVED: environments.test: leaf-environments: observe-weak: weak
observer gets collected
UNRESOLVED: environments.test: leaf-environment based eval-environments:
observe-weak: weak observer gets collected
Running eval.test

;;; (foo-pws)
UNRESOLVED: eval.test: promises: basic promise behaviour: a forced
promise does not reference its environment
Running exceptions.test
Running filesys.test
Running format.test
Running fractions.test
Running ftw.test
Running gc.test
Running getopt-long.test
Running goops.test
Running guardians.test
UNRESOLVED: guardians.test: standard guardian functionality: guarding
independent objects: re-guarding non-immediates
UNRESOLVED: guardians.test: standard guardian functionality: guarding
weakly referenced objects: guarded weak vector element gets returned
from guardian
UNRESOLVED: guardians.test: standard guardian functionality: guarding
weakly referenced objects: guarded element of weak vector gets
eventually removed from weak vector
UNRESOLVED: guardians.test: standard guardian functionality: guarding
weak containers: element of guarded weak vector gets collected
Running hash.test
Running hooks.test
Running import.test
Running interp.test
Running list.test
Running load.test
Running modules.test
Running numbers.test
Running optargs.test
Running options.test
Running poe.test
Running popen.test
Running ports.test
UNRESOLVED: ports.test: port-for-each: passing freed cell
Running posix.test
Running q.test
Running r4rs.test
Running r5rs_pitfall.test
Running ramap.test
Running reader.test
Running receive.test
Running regexp.test
Running socket.test
Running alist.test
Running and-let-star.test
Running arbiters.test
Running bit-operations.test
Running c-api.test
Running chars.test
Running common-list.test
Running continuations.test
Running elisp.test
Running environments.test
UNRESOLVED: environments.test: leaf-environments: observe-weak: weak
observer gets collected
UNRESOLVED: environments.test: leaf-environment based eval-environments:
observe-weak: weak observer gets collected
Running eval.test

;;; (foo-pws)
UNRESOLVED: eval.test: promises: basic promise behaviour: a forced
promise does not reference its environment
Running exceptions.test
Running filesys.test
Running format.test
Running fractions.test
Running ftw.test
Running gc.test
Running getopt-long.test
Running goops.test
Running guardians.test
UNRESOLVED: guardians.test: standard guardian functionality: guarding
independent objects: re-guarding non-immediates
UNRESOLVED: guardians.test: standard guardian functionality: guarding
weakly referenced objects: guarded weak vector element gets returned
from guardian
UNRESOLVED: guardians.test: standard guardian functionality: guarding
weakly referenced objects: guarded element of weak vector gets
eventually removed from weak vector
UNRESOLVED: guardians.test: standard guardian functionality: guarding
weak containers: element of guarded weak vector gets collected
Running hash.test
Running hooks.test
Running import.test
Running interp.test
Running list.test
Running load.test
Running modules.test
Running numbers.test
Running optargs.test
Running options.test
Running poe.test
Running popen.test
Running ports.test
UNRESOLVED: ports.test: port-for-each: passing freed cell
Running posix.test
Running q.test
Running r4rs.test
Running r5rs_pitfall.test
Running ramap.test
Running reader.test
Running receive.test
Running regexp.test
Running socket.test
Running srcprop.test
Running srfi-1.test
Running srfi-10.test
Running srfi-11.test
Running srfi-13.test
Running srfi-14.test
UNRESOLVED: srfi-14.test: Latin-1 (8-bit charset): char-set:letter
(membership)
UNRESOLVED: srfi-14.test: Latin-1 (8-bit charset): char-set:letter (size)
UNRESOLVED: srfi-14.test: Latin-1 (8-bit charset): char-set:lower-case
(size)
UNRESOLVED: srfi-14.test: Latin-1 (8-bit charset): char-set:upper-case
(size)
UNRESOLVED: srfi-14.test: Latin-1 (8-bit charset): char-set:punctuation
(membership)
Running srfi-19.test
Running srfi-26.test
Running srfi-31.test
Running srfi-34.test
Running srfi-35.test
Running srfi-37.test
Running srfi-39.test
Running srfi-4.test
Running srfi-6.test
Running srfi-60.test
Running srfi-9.test
Running strings.test
Running structs.test
Running symbols.test
Running syncase.test
Running syntax.test
UNRESOLVED: syntax.test: while: in empty environment: empty body
UNRESOLVED: syntax.test: while: in empty environment: initially false
UNRESOLVED: syntax.test: while: in empty environment: iterating
Running threads.test
Running time.test
FAIL: time.test: strftime: C99 %z format: GMT
FAIL: time.test: strftime: C99 %z format: EST+5
Running unif.test
Running version.test
Running weaks.test

Totals for this test run:
passes:                 11856
failures:               2
unexpected passes:      0
expected failures:      25
unresolved test cases:  16
untested test cases:    0
unsupported test cases: 11
errors:                 0

FAIL: check-guile
==================================
1 of 1 tests failed
Please report to bug-guile@gnu.org
==================================

The detailed logs are attached.


Do you like me to prepare a diff of my current source tree against the
1.8.3 release tree ??

> Thanks,
> Ludovic.
>
>
>   
Bye
   Rainer



[-- Attachment #2: logs.tar.gz --]
[-- Type: application/x-gzip, Size: 99512 bytes --]

Re: stack overflow / partial success

[Ludovic Courtès]

Hi Rainer,

Rainer Tammer <tammer@tammer.net> writes:

> I managed to compile GUILE 1.8.3+ fixes on AIX 6.1 with IBM XL C/C++ 9.0.

Good news!

> export LDFLAGS="-Wl,-brtl -L/opt/freeware/lib"
> export CFLAGS="-D_USE_IRS -Dinline=__inline__ -qtune=auto -O2
> -I/opt/freeware/include"

Isn't it the `inline' thing that made it work?  You did not include
`config.log' and `config.h': normally, these should already define
`inline' as `__inline__'.

And isn't `-O2' ignored by xlc?

Besides, can you explain what `_USE_IRS' is about and whether it's
needed?  Same for `-brtl'.

> FAIL: time.test: strftime: C99 %z format: GMT
> FAIL: time.test: strftime: C99 %z format: EST+5

These are the only two failures!  ;-)

Can you show the result of the following Scheme expressions in Guile:

  1. (strftime "%z" (gmtime 0))

  2. (begin
       (putenv "TZ=GMT+0")
       (tzset)
       (let ((tm (localtime 86400)))
	 (strftime "%z" tm)))

  3. (begin
       (putenv "TZ=EST+5")
       (tzset)
       (let ((tm (localtime 86400)))
	 (strftime "%z" tm)))

Thanks a lot for your help and perseverance!

Ludo'.

Re: stack overflow / partial success

[Rainer Tammer]

Hello,
Ludovic Courtès wrote:
> Hi Rainer,
>
> Rainer Tammer <tammer@tammer.net> writes:
>
>   
>> I managed to compile GUILE 1.8.3+ fixes on AIX 6.1 with IBM XL C/C++ 9.0.
>>     
>
> Good news!
>
>   
>> export LDFLAGS="-Wl,-brtl -L/opt/freeware/lib"
>> export CFLAGS="-D_USE_IRS -Dinline=__inline__ -qtune=auto -O2
>> -I/opt/freeware/include"
>>     
>
> Isn't it the `inline' thing that made it work?  You did not include
> `config.log' and `config.h': normally, these should already define
> `inline' as `__inline__'.
>
>   
the inline to __inline__  mapping is needed for IBM XL C/C++. It is not 
needed with gcc 4.2.2.
> And isn't `-O2' ignored by xlc?
>
>   
It is used if I specify it. I will try if configure finds this by itself.
> Besides, can you explain what `_USE_IRS' is about and whether it's
> needed?  Same for `-brtl'.
>   

-brtl is for runtime linking of the executable.

This is from netdb.h AIX 6.1:

void            freehostent(struct hostent *);  /* RFC 2553 */
#ifdef _USE_IRS
void            herror(const char *);
const char *    hstrerror(int);
#endif /* _USE_IRS */
struct hostent  *gethostbyname2(const char *, int);

So if I need herror() / hsterror() I need to define _USE_IRS ...

>   
>> FAIL: time.test: strftime: C99 %z format: GMT
>> FAIL: time.test: strftime: C99 %z format: EST+5
>>     
>
> These are the only two failures!  ;-)
>
> Can you show the result of the following Scheme expressions in Guile:
>
>   1. (strftime "%z" (gmtime 0))
>
>   
guile> "GMT"

>   2. (begin
>        (putenv "TZ=GMT+0")
>        (tzset)
>        (let ((tm (localtime 86400)))
> 	 (strftime "%z" tm)))
>
>   
guile> "GMT"

>   3. (begin
>        (putenv "TZ=EST+5")
>        (tzset)
>        (let ((tm (localtime 86400)))
> 	 (strftime "%z" tm)))
>
>   
guile> "EST"

and this is TZ:

# echo $TZ
NFT-1DFT,M3.5.0/2:00:00,M10.5.0/3:00:00

> Thanks a lot for your help and perseverance!
>
> Ludo'.
>
>
>
>   
Bye
  Rainer
>   

Re: stack overflow / partial success

[Ludovic Courtès]

Hi,

Rainer Tammer <tammer@tammer.net> writes:

> Ludovic Courtès wrote:

>> Isn't it the `inline' thing that made it work?  You did not include
>> `config.log' and `config.h': normally, these should already define
>> `inline' as `__inline__'.
>>   
> the inline to __inline__  mapping is needed for IBM XL C/C++. It is
> not needed with gcc 4.2.2.

Right, but doesn't `configure' detect this?  The output of
"grep inline config.log" should show it.

>> And isn't `-O2' ignored by xlc?
>>
> It is used if I specify it. I will try if configure finds this by itself.

But what's its meaning then?  I thought `-qtune=auto' was roughly
equivalent to GCC's `-O2'.

> -brtl is for runtime linking of the executable.

So what does it do precisely?  :-)

> So if I need herror() / hsterror() I need to define _USE_IRS ...

There's only one place where `hstrerror ()' is used, and it's enclosed
in `#if HAVE_STRERROR'.  Thus, if Guile is compiled without `_USE_IRS',
the offending bit will be compiled out and no compilation error will
occur I suppose.  IOW, you should be able to compile Guile without
`_USE_IRS', right?

>>   1. (strftime "%z" (gmtime 0))
>>   
> guile> "GMT"

The results you show here are vastly different from what we expect,
which shows that AIX' `strftime' is not C99-compliant in its treatment
of `%z' [0].  (Actually, it doesn't seem to be documented at all [1].)

We'll have to update `have-strftime-%z' accordingly in `time.test'.

Thanks,
Ludovic.

[0] http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html
[1] http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.basetechref/doc/basetrf2/strftime.htm

Re: stack overflow / partial success

[Rainer Tammer]

Hello,

Ludovic Courtès wrote:
> Hi,
> [...]
>   
>>> Isn't it the `inline' thing that made it work?  You did not include
>>> `config.log' and `config.h': normally, these should already define
>>> `inline' as `__inline__'.
>>>   
>>>       
>> the inline to __inline__  mapping is needed for IBM XL C/C++. It is
>> not needed with gcc 4.2.2.
>>     
>
> Right, but doesn't `configure' detect this?  The output of
> "grep inline config.log" should show it.
>
>   
Unfortunately no ...
>>> And isn't `-O2' ignored by xlc?
>>>
>>>       
>> It is used if I specify it. I will try if configure finds this by itself.
>>     
>
> But what's its meaning then?  I thought `-qtune=auto' was roughly
> equivalent to GCC's `-O2'.
>
>   
Not really:

-qtune=<option> Specifies the architecture system for which the 
executable program is optimized.
Possible values: 403, 604, auto, balanced, ppc970, pwr3, pwr4, pwr5, 
pwr6, rs64a, rs64b, rs64c

auto is: Object code optimized for the hardware platform on which the 
program is compiled.
So this option only specifies the platform.

-O<level> specifies the optimizations used:

0 = quick
2 = Performs optimizations that the compiler developers considered the 
best combination for compilation speed and runtime performance.
3... 5 are potentially dangerous as the have the potential to change the 
semantics of the program
>> -brtl is for runtime linking of the executable.
>>     
> So what does it do precisely?  :-)
>   
OK, you want to know:

The -brtl dos the following:

Enables run-time linking for the output file. This option implies the 
rtllib and symbolic options.
When dynamic mode is in effect, the rtl option allows input files 
specified with the -l flag to end
 in .so as well as in .a. All input files that are shared objects are 
listed as dependents of your
program in the output files loader section. The shared objects are 
listed in the same order as
they were specified on the command line.

If you like more information I can send you a couple documents with 
detailed explanations.

>> So if I need herror() / hsterror() I need to define _USE_IRS ...
>>     
>
> There's only one place where `hstrerror ()' is used, and it's enclosed
> in `#if HAVE_STRERROR'. 
Unfortunately HAVE_STRERROR is defined to 1 ...
> Thus, if Guile is compiled without `_USE_IRS', the offending bit will be compiled out and no compilation error will
> occur I suppose.  IOW, you should be able to compile Guile without `_USE_IRS', right?
>
>   
No, because HAVE_STRERROR gets defined. The easiest solution wold be to 
define _USE_IRS if  HAVE_STRERROR and AIX is defined.
>>>   1. (strftime "%z" (gmtime 0))
>>>   
>>>       
>> guile> "GMT"
>>     
>
> The results you show here are vastly different from what we expect,
> which shows that AIX' `strftime' is not C99-compliant in its treatment
> of `%z' [0].  (Actually, it doesn't seem to be documented at all [1].)
>
> We'll have to update `have-strftime-%z' accordingly in `time.test'.
>
>   
OK
> Thanks,
> Ludovic.
>
> [0] http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html
> [1] http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.basetechref/doc/basetrf2/strftime.htm
>
>
>
>   
Bye
  Rainer

Re: stack overflow / partial success

[Ludovic Courtès]

Rainer Tammer <tammer@tammer.net> writes:

> Ludovic Courtès wrote:

>> Right, but doesn't `configure' detect this?  The output of
>> "grep inline config.log" should show it.
>>   
> Unfortunately no ...

So what does "grep inline config.log" show?!

> Not really:
>
> -qtune=<option> Specifies the architecture system for which the
> executable program is optimized.
> Possible values: 403, 604, auto, balanced, ppc970, pwr3, pwr4, pwr5,
> pwr6, rs64a, rs64b, rs64c
>
> auto is: Object code optimized for the hardware platform on which the
> program is compiled.
> So this option only specifies the platform.
>
> -O<level> specifies the optimizations used:

OK.

> The -brtl dos the following:

OK, that's something Guile's `configure' should not worry about, I
guess.

>> There's only one place where `hstrerror ()' is used, and it's enclosed
>> in `#if HAVE_STRERROR'. 
> Unfortunately HAVE_STRERROR is defined to 1 ...

Sorry, I really meant `HAVE_HSTRERROR' (with `H'), which must be
undefined on AIX, right?

Thanks,
Ludovic.

Re: stack overflow / partial success

[Rainer Tammer]

Hello,

Ludovic Courtès wrote:
> Rainer Tammer <tammer@tammer.net> writes:
> [...]
>   
>> Unfortunately no ...
>>     
>
> So what does "grep inline config.log" show?!
>
>   
There is a "inline" but this version is not compatible...

The "inline" produces the following error:

"strings.c", line 132.10: 1506-780 (S) Reference to "scm_double_cell" 
with internal linkage is not allowed within inline definition of 
"scm_i_take_stringbufn".

The inline keyword is only recognized under compilation with c99 or with 
the -qlanglvl=stdc99 or -qlanglvl=extc99 options (or equivalent pragmas) or
-qkeyword=inline. Note that the latter option is enabled by default for 
xlc in the configuration file that is shipped with the compiler. The 
__inline__ keyword is
recognized at all language levels.
>   
>> The -brtl dos the following:
>>     
>
> OK, that's something Guile's `configure' should not worry about, I
> guess.
>
>   
Yes,
the setting a "export LDFLAGS=-Wl,-brtl" before you call configure is 
sufficient (and documented in the latest libtool 1.5.26 readme).
>>> There's only one place where `hstrerror ()' is used, and it's enclosed
>>> in `#if HAVE_STRERROR'. 
>>>       
>> Unfortunately HAVE_STRERROR is defined to 1 ...
>>     
>
> Sorry, I really meant `HAVE_HSTRERROR' (with `H'), which must be
> undefined on AIX, right?
>
>   
/* Define to 1 if you have the `hstrerror' function. */
#define HAVE_HSTRERROR 1

No, this is defined...
> Thanks,
> Ludovic.
>
>   
Bye
  Rainer
>
>   

Re: stack overflow / partial success

[Ludovic Courtès]

Hi,

Rainer Tammer <tammer@tammer.net> writes:

> Ludovic Courtès wrote:

>> So what does "grep inline config.log" show?!
>>
> There is a "inline" but this version is not compatible...

Note that this does not answer my question.  :-)

> The "inline" produces the following error:
>
> "strings.c", line 132.10: 1506-780 (S) Reference to "scm_double_cell"
> with internal linkage is not allowed within inline definition of
> "scm_i_take_stringbufn".

Yes, this is fixed in the forthcoming 1.8.4 (hopefully released later
today).

> /* Define to 1 if you have the `hstrerror' function. */
> #define HAVE_HSTRERROR 1

Then you should only get a warning at compilation-time about
`hstrerror ()' being undeclared, but the build process should continue
and Guile should link fine.

I'm reluctant to adding a `#define _USE_IRS' without any compelling
reason, since (i) the leading underscore makes it look like an internal
macro, and (ii) I don't know what it's really supposed to do.

Thanks,
Ludovic.

Re: stack overflow / partial success

[Rainer Tammer]

Hello,

Ludovic Courtès wrote:
> Hi,
> [...]
>   
>
>>> So what does "grep inline config.log" show?!
>>>
>>>       
>> There is a "inline" but this version is not compatible...
>>     
>
> Note that this does not answer my question.  :-)
>
>   
I know...
>> The "inline" produces the following error:
>>
>> "strings.c", line 132.10: 1506-780 (S) Reference to "scm_double_cell"
>> with internal linkage is not allowed within inline definition of
>> "scm_i_take_stringbufn".
>>     
>
> Yes, this is fixed in the forthcoming 1.8.4 (hopefully released later
> today).
>
>   
This sounds great, then it should work without the __inline__ hack.
>> /* Define to 1 if you have the `hstrerror' function. */
>> #define HAVE_HSTRERROR 1
>>     
>
> Then you should only get a warning at compilation-time about
> `hstrerror ()' being undeclared, but the build process should continue
> and Guile should link fine.
>
> I'm reluctant to adding a `#define _USE_IRS' without any compelling
> reason, since (i) the leading underscore makes it look like an internal
> macro, and (ii) I don't know what it's really supposed to do.
>
>   
Yes and no,
IBM XL C/C++ continues but gcc 4.2.2 stops due to the -Wall switch...

gmake[3]: Entering directory `/daten/source/guile-1.8.3/libguile'
/usr/bin/bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H 
-I. -I.. -I.. -I..    -fno-strict-aliasing -Wall -Wmissing-prototypes 
-Werror -MT net_db.lo -MD -MP -MF .deps/net_db.Tpo -c -o net_db.lo net_db.c
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -fno-strict-aliasing -Wall 
-Wmissing-prototypes -Werror -MT net_db.lo -MD -MP -MF .deps/net_db.Tpo 
-c net_db.c  -DPIC -o .libs/net_db.o
cc1: warnings being treated as errors
net_db.c: In function 'scm_resolv_error':
net_db.c:112: warning: implicit declaration of function 'hstrerror'

The easiest solution wold be an AIX note in the INSTALL:

n.1. AIX with IBM Compiler
...

n.2. AIX with gcc 4.x
...

and the setting for the extended stack "(debug-set! stack 80000)" should 
also be mention.
> Thanks,
> Ludovic.
>
>
>   
Bye
  Rainer

Re: stack overflow / partial success

[Ludovic Courtès]

Hi Rainer,

Rainer Tammer <tammer@tammer.net> writes:

> Ludovic Courtès wrote:

>> Then you should only get a warning at compilation-time about
>> `hstrerror ()' being undeclared, but the build process should continue
>> and Guile should link fine.
>>
>> I'm reluctant to adding a `#define _USE_IRS' without any compelling
>> reason, since (i) the leading underscore makes it look like an internal
>> macro, and (ii) I don't know what it's really supposed to do.
>>   
> Yes and no,
> IBM XL C/C++ continues but gcc 4.2.2 stops due to the -Wall switch...

I know for GCC but you said you were using xlc, right?  :-)

When compiling with GCC, you'd have to run `configure' with
`--disable-error-on-warning' to avoid this problem---I'm wondering
whether we should make it the default.

> and the setting for the extended stack "(debug-set! stack 80000)"
> should also be mention.

Ah, so setting it fixed some problem?

BTW, hopefully some of your problems are addressed by the newly-released
1.8.4.  We'll look into the others (e.g., `strftime') for the next
release.

Thanks for your report!

Ludovic.

Re: stack overflow / partial success

[Rainer Tammer]

Hello,

Ludovic Courtès wrote:
> Hi Rainer,
> [...}
>   
>> Yes and no,
>> IBM XL C/C++ continues but gcc 4.2.2 stops due to the -Wall switch...
>>     
>
> I know for GCC but you said you were using xlc, right?  :-)
>   
I have tested the build with both compilers gcc 4.2.2 and IBM XL C/C++ 
9.0 on AIX 6.1.
I am planing to release a rpm package of GUILE for AIX so I have to test 
the build with
different compilers to decide which produces the best result :-))

> When compiling with GCC, you'd have to run `configure' with
> `--disable-error-on-warning' to avoid this problem---I'm wondering
> whether we should make it the default.
>
>   
This could avoid some warnings but ... with the warning on the code 
tends to be cleaner.
>> and the setting for the extended stack "(debug-set! stack 80000)"
>> should also be mention.
>>     
>
> Ah, so setting it fixed some problem?
>
> BTW, hopefully some of your problems are addressed by the newly-released
> 1.8.4.  We'll look into the others (e.g., `strftime') for the next
> release.
>
>   
I will test the new 1.8.4 release and I will make detailed notes about 
all (still ?) needed changes
for AIX 6.1. When I have finished this I will try this on AIX 5.3.

I also can provide build notes for the AIX platform.
> Thanks for your report!
>
> Ludovic.
>
>
>   
Bye
  Rainer

Re: stack overflow / partial success

[Rainer Tammer]

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

Hello Ludovic,

Ludovic Courtès wrote:
> Hi Rainer,
> [...]
>   
> BTW, hopefully some of your problems are addressed by the newly-released
> 1.8.4.  We'll look into the others (e.g., `strftime') for the next
> release.
>
>   
The 1.8.4 release looks good but I had to tweak two little things:

1. guile-readline

./guile-readline/config.guess -> this file was not refreshed ...
./guile-readline/config.sub -> this file was not refreshed ...

I solved this by copying the two files from the ./guile-1.8.4 base dir 
to guile-libreadline

2. gc_os_dep.c

*** gc_os_dep.c    2008-02-20 09:42:18.000000000 +0100
--- /daten/source/guile-1.8.4/libguile/gc_os_dep.c    2008-02-16 
19:50:24.000000000 +0100
***************
*** 1159,1165 ****
  #   endif
  # endif
 
! # if defined(IA64) && !defined(RS6000)
  #   define MACH_TYPE "IA64"
  #   define ALIGN_DOUBLE
      /* Requires 16 byte alignment for malloc */
--- 1159,1165 ----
  #   endif
  # endif
 
! # ifdef IA64
  #   define MACH_TYPE "IA64"
  #   define ALIGN_DOUBLE
      /* Requires 16 byte alignment for malloc */

This avoids some redefinitions (MACH_TYPE, ..).

I have used the following compiler settings with IBM XL C/C++:

.guile
(debug-set! stack 160000)

configure.aix
#!/usr/bin/bash

export CONFIG_SHELL=/usr/bin/bash
export CONFIG_ENV_ARGS=/usr/bin/bash

export CC=cc_r
export CXX=xlC_r
export PATH=/opt/freeware/bin:$PATH
export LDFLAGS="-Wl,-brtl -L/opt/freeware/lib"
export CFLAGS="-D_USE_IRS -Dinline=__inline__ -qtune=auto -O2 
-I/opt/freeware/include"

./configure --enable-dynamic-linking --prefix=/opt/freeware 
--enable-shared --disable-static
gmake > make.log
gmake check > check.log

I have attached the check results to this post.

> Thanks for your report!
>
> Ludovic.
>
>
>   
Bye
  Rainer


[-- Attachment #2: check-log-aix-1.8.4.zip --]
[-- Type: application/zip, Size: 99981 bytes --]

GUILE 1.8.4 on AIX 6.1

[Rainer Tammer]

Hello,
one small addition...

The "-Dinline=__inline__" is no longer needed with IBM XL C/C++ 9.0.
I forgot to delete this from the configure script. The -qarch=auto is
needed. Without it the make check fails with a segfault.

PASS: test-conversion
./test-use-srfi[22]: 323820 Segmentation fault(coredump)
guile --use-srfi=1,10 fails to run


The gcc 4.2.2 build is working too.

The is the gcc 4.2.2 config for AIX 6.1:

#!/usr/bin/bash

export CONFIG_SHELL=/usr/bin/bash
export CONFIG_ENV_ARGS=/usr/bin/bash

export CC=gcc
export CXX=g++
export PATH=/opt/freeware/bin:$PATH
export LDFLAGS="-Wl,-brtl -L/opt/freeware/lib"
export CFLAGS="-D_USE_IRS -O2 -I/opt/freeware/include"

./configure --enable-dynamic-linking \
 --disable-error-on-warning \
 --prefix=/opt/freeware --enable-shared  --disable-static
gmake


Bye
  Rainer

Re: stack overflow

[Neil Jerram]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

"Mikael Djurfeldt" <mikael@djurfeldt.com> writes:

> I was thinking about inserting code which actually *measures* the size
> of frames during startup.  This could be done, for example, by
> introducing a primitive which uses the internal stack measuring
> functions.  One could use this primitive to measure how much stack
> space some code sample uses.  By our knowledge of how many evaluator
> stack frames this code sample uses, we can compute a reliable estimate
> for the running instance of Guile.

Below is a proposed patch to do this.  When and if this gets deployed,
the third arg to %calibrate-stack-depth would be removed, so that it
doesn't generate any output.  But for now it's interesting to see what
results people on various OSs get.

Could people who've being getting "Stack overflow" errors try this
out, and also report (for interest) the ";; Stack calibration" line
that they get?

Thanks,
     Neil



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: new-stack-overflow.patch --]
[-- Type: text/x-diff, Size: 5003 bytes --]

Index: ice-9/boot-9.scm
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/ice-9/boot-9.scm,v
retrieving revision 1.356.2.10
diff -u -r1.356.2.10 boot-9.scm
--- ice-9/boot-9.scm	1 Sep 2007 17:11:00 -0000	1.356.2.10
+++ ice-9/boot-9.scm	25 Feb 2008 21:45:44 -0000
@@ -2289,6 +2289,14 @@
    (print-options print-enable print-disable)
    (print-set!)))
 
+;;; Stack depth calibration, for the 'stack debug option.
+
+(let ((x (%get-stack-depth)))
+  (let loop ((count 10))
+    (if (zero? count)
+	(%calibrate-stack-depth x (%get-stack-depth) 'report)
+	(cons count (loop (- count 1))))))
+
 \f
 
 ;;; {Running Repls}
Index: libguile/debug.h
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/debug.h,v
retrieving revision 1.58
diff -u -r1.58 debug.h
--- libguile/debug.h	4 Nov 2005 21:20:24 -0000	1.58
+++ libguile/debug.h	25 Feb 2008 21:45:44 -0000
@@ -75,6 +75,7 @@
     && scm_is_true (SCM_EXIT_FRAME_HDLR);\
   scm_debug_mode_p = SCM_DEVAL_P\
     || scm_check_entry_p || scm_check_apply_p || scm_check_exit_p;\
+  scm_calculate_stack_limit ();\
 } while (0)
 
 /* {Evaluator}
Index: libguile/stackchk.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/stackchk.c,v
retrieving revision 1.28.2.1
diff -u -r1.28.2.1 stackchk.c
--- libguile/stackchk.c	12 Feb 2006 13:42:51 -0000	1.28.2.1
+++ libguile/stackchk.c	25 Feb 2008 21:45:44 -0000
@@ -30,6 +30,13 @@
 
 #ifdef STACK_CHECKING
 int scm_stack_checking_enabled_p;
+int scm_stack_limit;
+
+/* As in y = mx + c.  These numbers define a linear transformation
+   from the stack depth specified as the 'stack debug option, to the
+   actual max stack depth that we allow. */
+static double calibrated_m = 1;
+static double calibrated_c = 0;
 
 SCM_SYMBOL (scm_stack_overflow_key, "stack-overflow");
 
@@ -44,6 +51,58 @@
 	     SCM_BOOL_F);
 }
 
+/* Stack depth calibration. */
+
+SCM_DEFINE (scm_sys_get_stack_depth, "%get-stack-depth", 0, 0, 0,
+	    (),
+	    "Return current stack depth.")
+#define FUNC_NAME s_scm_sys_get_stack_depth
+{
+  SCM_STACKITEM stack;
+  return scm_from_int (SCM_STACK_DEPTH (&stack));
+}
+#undef FUNC_NAME
+
+SCM_DEFINE (scm_sys_calibrate_stack_depth, "%calibrate-stack-depth", 2, 1, 0,
+	    (SCM d1, SCM d2, SCM debugp),
+	    "Calibrate linear transformation for stack depth limit checking.")
+#define FUNC_NAME s_scm_sys_calibrate_stack_depth
+{
+  /* x1 and x2 are the stack depth values that we get on a Debian
+     GNU/Linux ia32 system - which we take as our canonical system.
+     y1 and y2 are the values measured on the system where Guile is
+     currently running. */
+  int x1 = 170, x2 = 690, y1, y2;
+
+  SCM_VALIDATE_INT_COPY (1, d1, y1);
+  SCM_VALIDATE_INT_COPY (2, d2, y2);
+
+  calibrated_m = ((double) (y2 - y1)) / (x2 - x1);
+  calibrated_c = ((double) y2) - calibrated_m * x2;
+
+  if (scm_is_true (debugp) && !SCM_UNBNDP (debugp))
+    {
+      scm_puts (";; Stack calibration: (x1 x2 y1 y2 m c) = ",
+		scm_current_output_port ());
+      scm_write (scm_list_n (scm_from_int (x1), scm_from_int (x2),
+			     d1, d2,
+			     scm_from_double (calibrated_m),
+			     scm_from_double (calibrated_c),
+			     SCM_UNDEFINED),
+		 SCM_UNDEFINED);
+      scm_newline (SCM_UNDEFINED);
+    }
+
+  return SCM_UNSPECIFIED;
+}
+#undef FUNC_NAME
+
+void
+scm_calculate_stack_limit ()
+{
+  scm_stack_limit = (int) (calibrated_m * SCM_STACK_LIMIT + calibrated_c);
+}
+
 #endif
 
 long
Index: libguile/stackchk.h
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/stackchk.h,v
retrieving revision 1.20.2.1
diff -u -r1.20.2.1 stackchk.h
--- libguile/stackchk.h	12 Feb 2006 13:42:51 -0000	1.20.2.1
+++ libguile/stackchk.h	25 Feb 2008 21:45:44 -0000
@@ -35,14 +35,11 @@
 
 #ifdef STACK_CHECKING
 # if SCM_STACK_GROWS_UP
-#  define SCM_STACK_OVERFLOW_P(s)\
-   (SCM_STACK_PTR (s) \
-    > (SCM_I_CURRENT_THREAD->base + SCM_STACK_LIMIT))
+#  define SCM_STACK_DEPTH(s) (SCM_STACK_PTR (s) - SCM_I_CURRENT_THREAD->base)
 # else
-#  define SCM_STACK_OVERFLOW_P(s)\
-   (SCM_STACK_PTR (s) \
-    < (SCM_I_CURRENT_THREAD->base - SCM_STACK_LIMIT))
+#  define SCM_STACK_DEPTH(s) (SCM_I_CURRENT_THREAD->base - SCM_STACK_PTR (s))
 # endif
+# define SCM_STACK_OVERFLOW_P(s) (SCM_STACK_DEPTH (s) > scm_stack_limit)
 # define SCM_CHECK_STACK\
     {\
        SCM_STACKITEM stack;\
@@ -54,10 +51,14 @@
 #endif /* STACK_CHECKING */
 
 SCM_API int scm_stack_checking_enabled_p;
+SCM_API int scm_stack_limit;
 
 \f
 
 SCM_API void scm_report_stack_overflow (void);
+SCM_API SCM scm_sys_get_stack_depth (void);
+SCM_API SCM scm_sys_calibrate_stack_depth (SCM d1, SCM d2, SCM debugp);
+SCM_API void scm_calculate_stack_limit (void);
 SCM_API long scm_stack_size (SCM_STACKITEM *start);
 SCM_API void scm_stack_report (void);
 SCM_API void scm_init_stackchk (void);

Re: stack overflow

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> Below is a proposed patch to do this.  When and if this gets deployed,
> the third arg to %calibrate-stack-depth would be removed, so that it
> doesn't generate any output.  But for now it's interesting to see what
> results people on various OSs get.
>
> Could people who've being getting "Stack overflow" errors try this
> out, and also report (for interest) the ";; Stack calibration" line
> that they get?

I think time has come to integrate this patch as it's proved to fix
things for various people.  I tried it on several platforms, always
compiling with the default flags, i.e., `-O2'.  Here's what I got[*]:

  * i686-pc-linux-gnu, GCC 4.2.4
    ;; Stack calibration: (x1 x2 y1 y2 m c) = (170 690 170 690 1.0 0.0)

  * x86_64-unknown-linux-gnu, GCC 4.1.2
    ;; Stack calibration: (x1 x2 y1 y2 m c) = (170 690 41 181 0.269230769230769 -4.76923076923077)

  * sparc64-unknown-linux-gnu, GCC 4.1.3
    ;; Stack calibration: (x1 x2 y1 y2 m c) = (170 690 178 498 0.615384615384615 73.3846153846154)

  * hppa2.0w-hp-hpux11.11,
    HP92453-01 B.11.X.36086-36089-36092.GP HP C Compiler (cc)
    ;; Stack calibration: (x1 x2 y1 y2 m c) = (170 690 352 1472 2.15384615384615 -14.1538461538462)

  * ia64-unknown-linux-gnu (itanium2), GCC 4.1.2
    ;; Stack calibration: (x1 x2 y1 y2 m c) = (170 690 10 50 0.0769230769230769 -3.07692307692308)

  * i386-unknown-freebsd6.2, GCC 3.4.6
    ;; Stack calibration: (x1 x2 y1 y2 m c) = (170 690 114 394 0.538461538461538 22.4615384615385)

`pre-inst-guile' reaches the REPL in all cases, except on IA64 where it
stack-overflows (further investigation needed).

I'll comment the patch itself later on.

Thanks,
Ludovic.

[*] I really need to find a way to automate this.  If anyone knows of
    existing tools that would facilitate it (connecting to each machine,
    running `configure', `make', etc.), please let me know.  Otherwise,
    I guess it wouldn't be too hard to write a script to do that.