[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Raymond Toy (RT/EUS)]

Carl Shapiro wrote:

This turns out to be a problem with CMUCL.  I have just committed a
change which resolves this issue.  With the change in place, I have
been able to run and rebuild CMUCL on an FC9 virtual machine I am
running locally.  This change, along with the others I have made for
FC9 compatibility, will be down-integrated into the 19e release
branch.


The 19e branch now has this change.  I will tag this soon, pending a 
note from Carl about another issue that seems to affect his Ubuntu and 
FC9 system but not on my SuSE 10.3 system, Mac OS X system, or the RH 
system at work.


Ray

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Christophe Rhodes]

"Carl Shapiro" <[EMAIL PROTECTED]> writes:

> Rex,
>
> On Sat, Mar 15, 2008 at 6:58 PM, Rex Dieter <[EMAIL PROTECTED]> wrote:
>>  I would be tempted to say "on any gcc43-derived linux system", but I'm
>>  not convinced that gcc43 is the (sole, if at all) culprit.
>
> This turns out to be a problem with CMUCL.  I have just committed a
> change which resolves this issue.  With the change in place, I have
> been able to run and rebuild CMUCL on an FC9 virtual machine I am
> running locally.  This change, along with the others I have made for
> FC9 compatibility, will be down-integrated into the 19e release
> branch.

For your information: I believe that this is (was) not a problem with
CMUCL, though the changes you have made to clear the direction flag
close to where you set it will work around most of the problem.

The problem is in fact a kernel bug, which was masked until gcc-4.3 by
a conservative treatment of the ABI.  The kernel failed to clear the
direction flag before running a signal handler, but this didn't matter
because the compiler cleared it for you in various circumstances,
including across function call boundaries; a libc6 compiled with
gcc-4.3, with its signals/ directory compiled with gcc-4.2, will
eliminate the observed problem.

Even with your changes to the assembly routines, there is a small
window wherein a signal (such as SIGINT) will cause trouble; if the
signal is received when the direction flag is set, then handlers will
run with the wrong flag.  The only way to fix these is to clear the
direction flag within signal handlers before calling sigemptyset() or
memset() or similar; as far as I know, this would need to be done for
the *BSDs and Linux, but not for Solaris (though of course it is
harmless to do so).

For more information, see the discussion of this on sbcl-devel and
linux-kernel, or a LWN summary at .

Best,

Christophe

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Christophe Rhodes]

"Carl Shapiro" <[EMAIL PROTECTED]> writes:

> On Tue, Apr 1, 2008 at 1:50 AM, Christophe Rhodes <[EMAIL PROTECTED]> wrote:
>>  For your information: I believe that this is (was) not a problem with
>>  CMUCL, though the changes you have made to clear the direction flag
>>  close to where you set it will work around most of the problem.
>
> For your information this bug has nothing to do with the Linux kernel
> and everything to do with a failure to abide by the x86 calling
> convention.  Any foreign call which makes use of a string instruction
> assuming the direction flag is clear runs the risk of corrupting
> memory.  To reproduce this bug all you need to do is make a foreign
> call memcpy.  You do not need to execute a signal handler and you do
> not need to be running on a Linux system either.

Oh, many apologies; I assumed that bugs related to the direction flag
on a foreign call would have been fixed long ago; obeying the platform
ABI is of course required, and I'm sorry that I assumed that the bug
you were fixing was a different one.  For what it's worth, a change
substantially the same as yours was recently made to SBCL in order to
minimize the window of vulnerability to the kernel bug I referred to
in my message.

Please then take my message as a heads-up to tell you that the changes
you have made are not sufficient because of kernel bugs, and that to
work around bugs in current and historical versions of the Linux and
BSD kernels you may wish to clear the direction flag in signal
handlers on those platforms; I apologise once again for my
misunderstanding.

Best,

Christophe

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Carl Shapiro]

On Tue, Apr 1, 2008 at 1:50 AM, Christophe Rhodes <[EMAIL PROTECTED]> wrote:
>  For your information: I believe that this is (was) not a problem with
>  CMUCL, though the changes you have made to clear the direction flag
>  close to where you set it will work around most of the problem.

For your information this bug has nothing to do with the Linux kernel
and everything to do with a failure to abide by the x86 calling
convention.  Any foreign call which makes use of a string instruction
assuming the direction flag is clear runs the risk of corrupting
memory.  To reproduce this bug all you need to do is make a foreign
call memcpy.  You do not need to execute a signal handler and you do
not need to be running on a Linux system either.

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Carl Shapiro]

Rex,

On Sat, Mar 15, 2008 at 6:58 PM, Rex Dieter <[EMAIL PROTECTED]> wrote:
>  I would be tempted to say "on any gcc43-derived linux system", but I'm
>  not convinced that gcc43 is the (sole, if at all) culprit.

This turns out to be a problem with CMUCL.  I have just committed a
change which resolves this issue.  With the change in place, I have
been able to run and rebuild CMUCL on an FC9 virtual machine I am
running locally.  This change, along with the others I have made for
FC9 compatibility, will be down-integrated into the 19e release
branch.

Carl

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Raymond Toy (RT/EUS)]

Carl Shapiro wrote:

On Tue, Mar 25, 2008 at 4:59 AM, Raymond Toy <[EMAIL PROTECTED]> wrote:

Sounds great!  Do you think those changes will be available for the release?


Sure.  I think it is important that these changes go into the release
for 19e to be generally useful.


Great.  19e will wait until these things go in.




I also found another, simpler, way of causing the error.  Using a new
build (skipping over the errors from the libraries), just press C-c in
the repl.  Then enter 0 to select the continue restart.  You get a segv
at address 0.


Is this also on the FC9 machine?

Yes.  I'm pretty sure it works on older OSes.  I don't recall ever 
seeing this on my Suse 9 or 10.3 box.


Ray

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Carl Shapiro]

On Tue, Mar 25, 2008 at 4:59 AM, Raymond Toy <[EMAIL PROTECTED]> wrote:
> Sounds great!  Do you think those changes will be available for the release?

Sure.  I think it is important that these changes go into the release
for 19e to be generally useful.

> I also found another, simpler, way of causing the error.  Using a new
> build (skipping over the errors from the libraries), just press C-c in
> the repl.  Then enter 0 to select the continue restart.  You get a segv
> at address 0.

Is this also on the FC9 machine?

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Raymond Toy]

Carl Shapiro wrote:

On Mon, Mar 24, 2008 at 11:08 PM, Carl Shapiro <[EMAIL PROTECTED]> wrote:
  

On Mon, Mar 24, 2008 at 6:52 PM, Raymond Toy <[EMAIL PROTECTED]> wrote:
 >  (run-program "/bin/cat" '("/etc/issue") :output "/tmp/foo")
 >
 >  causes a segv at address 0.  Not sure why yet, but it explains why I see
 >  the segvs after cmucl prints out messages that foo-library.x86f is out
 >  of date.



OK, I have reproduced this on the FC9 system.

It looks like the memset call in sigemptyset is corrupting memory.  I
have attached a patch which may be sufficient to work around the
segmentation fault in spawn but this is not sufficient overall.  I
have a more thorough patch queued up that resolves this issue
entirely.  I will check in those changes as soon as I can.

  

Sounds great!  Do you think those changes will be available for the release?

I also found another, simpler, way of causing the error.  Using a new 
build (skipping over the errors from the libraries), just press C-c in 
the repl.  Then enter 0 to select the continue restart.  You get a segv 
at address 0.


Based on your patch and your comments, I think your full patch will be 
needed to fix this.


Ray

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Carl Shapiro]

On Mon, Mar 24, 2008 at 11:08 PM, Carl Shapiro <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 24, 2008 at 6:52 PM, Raymond Toy <[EMAIL PROTECTED]> wrote:
>  >  (run-program "/bin/cat" '("/etc/issue") :output "/tmp/foo")
>  >
>  >  causes a segv at address 0.  Not sure why yet, but it explains why I see
>  >  the segvs after cmucl prints out messages that foo-library.x86f is out
>  >  of date.

OK, I have reproduced this on the FC9 system.

It looks like the memset call in sigemptyset is corrupting memory.  I
have attached a patch which may be sufficient to work around the
segmentation fault in spawn but this is not sufficient overall.  I
have a more thorough patch queued up that resolves this issue
entirely.  I will check in those changes as soon as I can.

--- runprog.c~  2005-09-15 13:26:52.0 -0500
+++ runprog.c   2008-03-25 03:22:00.0 -0500
@@ -29,6 +29,7 @@
 setsid();

 /* Unblock all signals. */
+__asm__ __volatile__ ("cld");
 sigemptyset(&set);
 sigprocmask(SIG_SETMASK, &set, NULL);

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Carl Shapiro]

On Mon, Mar 24, 2008 at 6:52 PM, Raymond Toy <[EMAIL PROTECTED]> wrote:
>  (run-program "/bin/cat" '("/etc/issue") :output "/tmp/foo")
>
>  causes a segv at address 0.  Not sure why yet, but it explains why I see
>  the segvs after cmucl prints out messages that foo-library.x86f is out
>  of date.

I take it that run-program never returns?  Does this happen on your
SuSE machine or some other Linux?  I cannot reproduce this on my
Ubuntu machine using the latest snapshot.

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Raymond Toy]

Carl Shapiro wrote:

On Fri, Mar 14, 2008 at 7:00 PM, Rex Dieter <[EMAIL PROTECTED]> wrote:
  

 Yes, that seemed to help.  Now I'm seeing some bits not building (but it's
 better)



Great!

It looks like your build is failing look for the following output

"target:clx/clx-library.x86f" out of date.
interrupt_handle_now: No handler for signal 1486158303?
  

FWIW, it appears that run-program is broken.

(run-program "/bin/cat" '("/etc/issue") :output "/tmp/foo")

causes a segv at address 0.  Not sure why yet, but it explains why I see 
the segvs after cmucl prints out messages that foo-library.x86f is out 
of date.


Ray

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Rex Dieter]

Rex Dieter wrote:

> Carl Shapiro wrote:
>> On Sat, Mar 15, 2008 at 6:11 AM, Rex Dieter <[EMAIL PROTECTED]> wrote:
>>>  Unlikely, I'm using clean/minimal chroot for each build.The failure
>>>  is occurring trying to build for fedira9 (development) that uses gcc43.
>>>   Fwiw, this same build works fine on fedora8 (using gcc41).
>> 
>> Is there an easy way I can reproduce your build environment locally?
> 
> I would be tempted to say "on any gcc43-derived linux system", but I'm
> not convinced that gcc43 is the (sole, if at all) culprit.
> 
> In the meantime, I'll see about whipping up a hosted fedora-9-i386 VM,
> to help debugging. (I personally only have a single f9/x86_64 box atm).
>   I will give access to any cmucl dev's wiling to help out here.

OK, got the VM up and running, offer for remote login/shell still stands. 
Any takers?  (contact me here, or privately, either ok with me).

-- Rex

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Rex Dieter]

Carl Shapiro wrote:

On Sat, Mar 15, 2008 at 6:11 AM, Rex Dieter <[EMAIL PROTECTED]> wrote:

 Unlikely, I'm using clean/minimal chroot for each build.The failure
 is occurring trying to build for fedira9 (development) that uses gcc43.
  Fwiw, this same build works fine on fedora8 (using gcc41).


Is there an easy way I can reproduce your build environment locally?


I would be tempted to say "on any gcc43-derived linux system", but I'm 
not convinced that gcc43 is the (sole, if at all) culprit.


In the meantime, I'll see about whipping up a hosted fedora-9-i386 VM, 
to help debugging. (I personally only have a single f9/x86_64 box atm). 
 I will give access to any cmucl dev's wiling to help out here.


-- Rex

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Carl Shapiro]

On Sat, Mar 15, 2008 at 6:11 AM, Rex Dieter <[EMAIL PROTECTED]> wrote:
>  Unlikely, I'm using clean/minimal chroot for each build.The failure
>  is occurring trying to build for fedira9 (development) that uses gcc43.
>   Fwiw, this same build works fine on fedora8 (using gcc41).

Is there an easy way I can reproduce your build environment locally?

In the mean time, I will check-in the -iquote and assembly code changes.

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Rex Dieter]

Carl Shapiro wrote:

On Fri, Mar 14, 2008 at 7:00 PM, Rex Dieter <[EMAIL PROTECTED]> wrote:

 Yes, that seemed to help.  Now I'm seeing some bits not building (but it's
 better)


Great!

It looks like your build is failing look for the following output

"target:clx/clx-library.x86f" out of date.
interrupt_handle_now: No handler for signal 1486158303?
LDB monitor
ldb>

Is there any chance that some stale object code is in your build directory?


Unlikely, I'm using clean/minimal chroot for each build.The failure 
is occurring trying to build for fedira9 (development) that uses gcc43. 
 Fwiw, this same build works fine on fedora8 (using gcc41).


/me keeps digging.


 Else, get "unistd_32.h" not found errors.


OK.  So, will the problem be solved if we start using -iquote in the
Linux build files?


Yes, I can confirm that using -iquote solves this particular problem.

-- Rex

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Carl Shapiro]

On Fri, Mar 14, 2008 at 7:00 PM, Rex Dieter <[EMAIL PROTECTED]> wrote:
>  Yes, that seemed to help.  Now I'm seeing some bits not building (but it's
>  better)

Great!

It looks like your build is failing look for the following output

"target:clx/clx-library.x86f" out of date.
interrupt_handle_now: No handler for signal 1486158303?
LDB monitor
ldb>

Is there any chance that some stale object code is in your build directory?

>  Else, get "unistd_32.h" not found errors.

OK.  So, will the problem be solved if we start using -iquote in the
Linux build files?

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Rex Dieter]

Carl Shapiro wrote:

> Hi Rex,
> 
> On Fri, Mar 14, 2008 at 12:37 PM, Rex Dieter <[EMAIL PROTECTED]> wrote:
>> Tried out cmucl-19e-pre1, and this works better (than cmucl-19d) and
>> gets further, but fails in some asm in
>> ../../src/lisp/x86-assem.S
>> ../../src/lisp/x86-assem.S: Assembler messages:
>> ../../src/lisp/x86-assem.S:84: Error: suffix or operands invalid for
>> `fnstsw'
> 
> Can you change that line to "fnstsw %ax" and running the compile again?

Yes, that seemed to help.  Now I'm seeing some bits not building (but it's
better)
http://koji.fedoraproject.org/koji/getfile?taskID=517448&name=build.log
excerpt:
install: cannot stat `i386-redhat-linux-gnu-4/hemlock/hemlock-library.x86f':
No such file or directory
install: cannot stat `i386-redhat-linux-gnu-4/hemlock/spell-dictionary.bin':
No such file or directory
install: cannot stat `i386-redhat-linux-gnu-4/interface/clm-library.x86f':
No such file or directory
install: cannot stat `i386-redhat-linux-gnu-4/motif/server/motifd': No such
file or directory

I'll keep digging.

>> Further, attached is a quick-n-dirty patch I needed to make it not choke
>> on
>> #include 
>> ->
>> #include 
>> which contains
>> #ifdef __i386__
>> #include "unistd_32.h"
>> #else
>> #include "unistd_64.h"
>> #endif
>> on recent kernel-headers.  In short, translating -I- to use -iquote
>> instead (and have the build respect our rpm optflags)
> 
> I committed a change to the FreeBSD and Darwin configuration files
> which switch to using -iquote when the compiler is not GCC 2 or 3.  I
> can make a change to the Linux configuration file as well.  However, I
> do not understand how this problem relates to the kernel header files.
>  Is the underlying problem that the wrong header file is being found
> when an -iquote is not used?

Else, get "unistd_32.h" not found errors.

-- Rex

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Carl Shapiro]

Hi Rex,

On Fri, Mar 14, 2008 at 12:37 PM, Rex Dieter <[EMAIL PROTECTED]> wrote:
> Tried out cmucl-19e-pre1, and this works better (than cmucl-19d) and
> gets further, but fails in some asm in
> ../../src/lisp/x86-assem.S
> ../../src/lisp/x86-assem.S: Assembler messages:
> ../../src/lisp/x86-assem.S:84: Error: suffix or operands invalid for
> `fnstsw'

Can you change that line to "fnstsw %ax" and running the compile again?

> Further, attached is a quick-n-dirty patch I needed to make it not choke on
> #include 
> ->
> #include 
> which contains
> #ifdef __i386__
> #include "unistd_32.h"
> #else
> #include "unistd_64.h"
> #endif
> on recent kernel-headers.  In short, translating -I- to use -iquote instead
> (and have the build respect our rpm optflags)

I committed a change to the FreeBSD and Darwin configuration files
which switch to using -iquote when the compiler is not GCC 2 or 3.  I
can make a change to the Linux configuration file as well.  However, I
do not understand how this problem relates to the kernel header files.
 Is the underlying problem that the wrong header file is being found
when an -iquote is not used?

Carl

[cmucl-help] Re: cmucl-19e + gcc43 better, not quite there

[Rex Dieter]

Rex Dieter wrote:


Further, attached is a quick-n-dirty patch I needed to make it not choke on
#include 

...

-- Binary/unsupported file stripped by Listar --


Arg, how about this then,
http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/cmucl/cmucl-19e-optflags.patch?rev=1.1

-- Rex