guile-1.8.1 - problems on AMD64

guile-1.8.1 - problems on AMD64

[Stanislav Ievlev]

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

--
$ guile
Backtrace:
In unknown file:
   ?: 130* [syntmp-gen-syntax-1074 #(syntax-object # #) #(syntax-object #
#) ...
]
   ?: 131  (if (syntmp-id?-115 syntmp-e-1110) (let* (#) (let* # #)) ...)
     ...
   ?: 132  [call-with-values #<procedure #f ()> #<procedure #f #>]
   ?: 133  (@call-with-values (producer consumer))
   ?: 134* [#<procedure #f ()>]
   ?: 135* [syntmp-gen-syntax-1074 #(syntax-object # #) #(syntax-object
begin #)
 ...]
   ?: 136  (if (syntmp-id?-115 syntmp-e-1110) (let* (#) (let* # #)) ...)
     ...
   ?: 137  (if # # #)
   ?: 138* [syntmp-ellipsis?-160 #(syntax-object begin (# # # #))]
   ?: 139  (and # #)
     ...
   ?: 140  [syntmp-free-id=?-138 #(syntax-object begin #) #(syntax-object
... #)
]
   ?: 141  (and (eq? # #) (eq? # #))
   ?: 142* [eq? ...
   ?: 143*  (let* ((syntmp-x-885 syntmp-i-883)) (let* (#) (if # #
syntmp-e-886))
)
   ?: 144   (let* (#) (if # # syntmp-e-886))
   ?: 145*  (if # # syntmp-x-885)
   ?: 146*  [syntmp-syntax-object?-101 #(syntax-object begin (# # # #))]
   ?: 147   (and (vector? syntmp-x-1008) (= (vector-length syntmp-x-1008)
3) ...
)
   ?: 148*  [= ...
   ?: 149*   (vector-length syntmp-x-1008)

<unnamed port>: In expression (vector-length syntmp-x-1008):
<unnamed port>: Stack overflow

--

Previous version I see (1.7.91) was work well.

There is also a build log from our build system in attach.

--
With best regards
Stanislav Ievlev.

ALT Linux Team.



[-- Attachment #2: build.log.bz2 --]
[-- Type: application/x-bzip2, Size: 17010 bytes --]

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Ludovic Courtès]

Hi,

Stanislav Ievlev <inger@altlinux.org> writes:

> <unnamed port>: In expression (vector-length syntmp-x-1008):
> <unnamed port>: Stack overflow

Did you compile with `-O0'?  If so, make sure you compile at least with
`-O1'.

Hope this helps,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Stanislav Ievlev]

On Tue, Oct 10, 2006 at 10:23:31AM +0200, Ludovic Court?s wrote:
> Hi,
> 
> Stanislav Ievlev <inger@altlinux.org> writes:
> 
> > <unnamed port>: In expression (vector-length syntmp-x-1008):
> > <unnamed port>: Stack overflow
> 
> Did you compile with `-O0'?  If so, make sure you compile at least with
> `-O1'.
You have problems with optimization disabled?

However, guile does not build with glibc >=2.4 when -D_FORTIFY_SOURCE=2 is
added to CFLAGS:
--
i586-alt-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -pthread -pipe
-Wall -O2 -march=i586 -mtune=pentium4 -Wall -Wmissing-prototypes -Werror -c async.c  -fPIC -DPIC -o .libs/libguile_la-async.o                                       
cc1: warnings being treated as errors                                                                                  
async.c: In function 'scm_i_queue_async_cell':                                                                         
async.c:250: warning: ignoring return value of 'write', declared with attribute warn_unused_result                     
make[3]: *** [libguile_la-async.lo] Error 1                                                                            
make[3]: Leaving directory `/usr/src/RPM/BUILD/guile-1.8.1/libguile'                                                   
--



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Kevin Ryde]

Stanislav Ievlev <inger@altlinux.org> writes:
>
> You have problems with optimization disabled?

We don't, but gcc 4 does :).  (Bloated stack usage in the code gcc
generates for the guile eval func.)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Ludovic Courtès]

Hi,

Stanislav Ievlev <inger@altlinux.org> writes:

> On Tue, Oct 10, 2006 at 10:23:31AM +0200, Ludovic Court?s wrote:
>> Hi,
>> 
>> Stanislav Ievlev <inger@altlinux.org> writes:
>> 
>> > <unnamed port>: In expression (vector-length syntmp-x-1008):
>> > <unnamed port>: Stack overflow
>> 
>> Did you compile with `-O0'?  If so, make sure you compile at least with
>> `-O1'.
> You have problems with optimization disabled?

Personally, no.  ;-)  But Guile eats up a lot of stack space when
compiled with `-O0', to the point that you can't get to the REPL (with
the default stack limit), hence my suggestion to use `-O1'.

> However, guile does not build with glibc >=2.4 when -D_FORTIFY_SOURCE=2 is
> added to CFLAGS:

I was unaware of that flag.  Is it documented somewhere?

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Stanislav Ievlev]

On Thu, Oct 12, 2006 at 02:58:58PM +0200, Ludovic Court?s wrote:
> Hi,
> 
> Stanislav Ievlev <inger@altlinux.org> writes:
> 
> > On Tue, Oct 10, 2006 at 10:23:31AM +0200, Ludovic Court?s wrote:
> >> Hi,
> >> 
> >> Stanislav Ievlev <inger@altlinux.org> writes:
> >> 
> >> > <unnamed port>: In expression (vector-length syntmp-x-1008):
> >> > <unnamed port>: Stack overflow
> >> 
> >> Did you compile with `-O0'?  If so, make sure you compile at least with
> >> `-O1'.
> > You have problems with optimization disabled?
> 
> Personally, no.  ;-)  But Guile eats up a lot of stack space when
> compiled with `-O0', to the point that you can't get to the REPL (with
> the default stack limit), hence my suggestion to use `-O1'.
> 
> > However, guile does not build with glibc >=2.4 when -D_FORTIFY_SOURCE=2 is
> > added to CFLAGS:
> 
> I was unaware of that flag.  Is it documented somewhere?
As I understand, this is one of security features from RedHat gcc branch.
http://www.redhat.com/magazine/006apr05/features/security/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Ludovic Courtès]

Hi,

Stanislav Ievlev <inger@altlinux.org> writes:

> As I understand, this is one of security features from RedHat gcc branch.
> http://www.redhat.com/magazine/006apr05/features/security/

I see.  I found a more technical post on this matter:

  http://lkml.org/lkml/2005/5/25/46

This looks like a potentially useful tool and we'll probably investigate
its results once it's available in the main GCC branch.

As for this:

  async.c: In function 'scm_i_queue_async_cell':
  async.c:250: warning: ignoring return value of 'write', declared with attribute warn_unused_result

I don't really understand what this code does, but I have the feeling
that line 250 could be rewritten this way:

  SCM_SYSCALL ((void)write (sleep_fd, &dummy, 1));

Can somebody familiar with this comment?

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> As for this:
>
>   async.c: In function 'scm_i_queue_async_cell':
>   async.c:250: warning: ignoring return value of 'write', declared with attribute warn_unused_result
>
> I don't really understand what this code does, but I have the feeling
> that line 250 could be rewritten this way:
>
>   SCM_SYSCALL ((void)write (sleep_fd, &dummy, 1));
>
> Can somebody familiar with this comment?

Agreed.  Stanislav, can you try this and confirm whether it removes
the warning you are getting?

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Stanislav Ievlev]

On Sat, Oct 14, 2006 at 02:13:38PM +0100, Neil Jerram wrote:
> ludovic.courtes@laas.fr (Ludovic Court?s) writes:
> 
> > As for this:
> >
> >   async.c: In function 'scm_i_queue_async_cell':
> >   async.c:250: warning: ignoring return value of 'write', declared with attribute warn_unused_result
> >
> > I don't really understand what this code does, but I have the feeling
> > that line 250 could be rewritten this way:
> >
> >   SCM_SYSCALL ((void)write (sleep_fd, &dummy, 1));
> >
> > Can somebody familiar with this comment?
> 
> Agreed.  Stanislav, can you try this and confirm whether it removes
> the warning you are getting?

New compiller is a too smart for it ;)
--
$ make
...
 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -pthread -pipe -Wall -O2
 -march=i686 -mtune=pentium4 -Wall -Wmissing-prototypes -Werror -c async.c
 -fPIC -DPIC -o .libs/libguile_la-async.o
 cc1: warnings being treated as errors
 async.c: In function 'scm_i_queue_async_cell':
 async.c:250: warning: ignoring return value of 'write', declared with
 attribute warn_unused_result
 make[1]: *** [libguile_la-async.lo] Ошибка 1
 make[1]: Leaving directory `/mnt/archive/RPM/BUILD/guile-1.8.1/libguile'
 make: *** [all] Ошибка 2

$ grep SCM_SYSCALL async.c
       SCM_SYSCALL((void)write (sleep_fd, &dummy, 1));
-- 

I think, you will have to create an explicit tests:
--
$ gcc-4.1  -O1  l.c 
l.c: In function 'main':
l.c:6: warning: ignoring return value of 'write', declared with attribute
warn_unused_result
$ cat l.c 
#include <unistd.h>

int main()
{
     char c;
     (void)write(1,&c,1);
     return 0;
}
			

$ gcc-4.1  -O1  l0.c 
$ cat l0.c 
#include <unistd.h>

int main()
{
       char c;
       if(write(1,&c,1));
       return 0;
}

$ gcc-4.1  -O1  l1.c 
$ cat l1.c 
#include <unistd.h>

void ignore(int retcode)
{
}

int main()
{
        char c;
        ignore(write(1,&c,1));
        return 0;
}
			

The best solution is to create a simple wrapper like this:
--
$ gcc -O1 l2.c 
[stas@stas zzz]$ cat l2.c 
#include <stdlib.h>
#include <unistd.h>

#include <error.h>
#include <errno.h>

#define CHECK_OR_IGNORE(x) if (x) error(EXIT_FAILURE,errno,#x)

int main()
{
        char c;
        CHECK_OR_IGNORE(write(1,&c,1));
        return 0;
}
			

--

--
With best regards
Stanislav Ievlev;



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Ludovic Courtès]

Hi,

Stanislav Ievlev <inger@altlinux.org> writes:

> On Sat, Oct 14, 2006 at 02:13:38PM +0100, Neil Jerram wrote:
>> ludovic.courtes@laas.fr (Ludovic Court?s) writes:
>> 
>> > As for this:
>> >
>> >   async.c: In function 'scm_i_queue_async_cell':
>> >   async.c:250: warning: ignoring return value of 'write', declared with attribute warn_unused_result
>> >
>> > I don't really understand what this code does, but I have the feeling
>> > that line 250 could be rewritten this way:
>> >
>> >   SCM_SYSCALL ((void)write (sleep_fd, &dummy, 1));
>> >
>> > Can somebody familiar with this comment?
>> 
>> Agreed.  Stanislav, can you try this and confirm whether it removes
>> the warning you are getting?
>
> New compiller is a too smart for it ;)

I guess the point of this `_FORTIFY_SOURCE' thing is to help catch
errors related to interactions with the kernel (among others).  The idea
is that when performing a system call, one _should_ be concerned about
its result.

In the case of async.c:250, I don't understand whether/how failure of
the `write ()' call should be handled.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> I guess the point of this `_FORTIFY_SOURCE' thing is to help catch
> errors related to interactions with the kernel (among others).  The idea
> is that when performing a system call, one _should_ be concerned about
> its result.
>
> In the case of async.c:250, I don't understand whether/how failure of
> the `write ()' call should be handled.

I think it's writing a byte as an inter-thread signaling mechanism.
It's pretty unlikely that a single byte write will be interrupted, but
if it is then a retry will be needed, so I think the use of
SCM_SYSCALL is correct in principle here.

How about this, which is more similarly to the other uses of
SCM_SYSCALL in the code?

      SCM_SYSCALL (rv = write (sleep_fd, &dummy, 1));

(Whole patch is below.)

Regards,
     Neil


Index: async.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/async.c,v
retrieving revision 1.86
diff -u -r1.86 async.c
--- async.c	17 Apr 2006 00:05:37 -0000	1.86
+++ async.c	19 Oct 2006 18:46:32 -0000
@@ -241,13 +241,14 @@
   if (sleep_fd >= 0)
     {
       char dummy = 0;
+      int rv;
       /* Likewise, T might already been done with sleeping here, but
 	 interrupting it once too often does no harm.  T might also
 	 not yet have started sleeping, but this is no problem either
 	 since the data written to a pipe will not be lost, unlike a
 	 condition variable signal.
       */
-      write (sleep_fd, &dummy, 1);
+      SCM_SYSCALL (rv = write (sleep_fd, &dummy, 1));
     }
 
   /* This is needed to protect sleep_mutex.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile-1.8.1 - problems on AMD64

[Ludovic Courtès]

Hi,

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

> I think it's writing a byte as an inter-thread signaling mechanism.
> It's pretty unlikely that a single byte write will be interrupted, but
> if it is then a retry will be needed, so I think the use of
> SCM_SYSCALL is correct in principle here.

Ok.

> How about this, which is more similarly to the other uses of
> SCM_SYSCALL in the code?
>
>       SCM_SYSCALL (rv = write (sleep_fd, &dummy, 1));

Looks good.  How about also checking whether RV is actually equal to 1
then (and loop if it's lower than 1)?

(I know it is unlikely that RV will be different from 1 but the API
specification leaves this possibility open and it's certainly not
impossible.)

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel