segmentation fault with map in Pure 0.38

[Cleverton Hentz]

Hi,

I'm testing simple exemples in Pure 0.38 (Macports), but I get segmentation fault. This code cause error:

> map id (1..5);

(This I get from "The Pure Library Manual", section 1.1)

or

> f a = a+1;

> map f [1,2,3];

In two cases the error is raised. I code some wrong ?

My configurations is :

Max OS X (10.6.2)

MacPort 1.8.1

LLVM 2.6.1

Pure 0.38

Thanks,

Cleverton Hentz

[Albert Graef]

Cleverton Hentz wrote:
> I'm testing simple exemples in Pure 0.38 (Macports), but I get
> segmentation fault. This code cause error:
>
>> map id (1..5);

Not sure, but this usually indicates either a miscompiled LLVM or a lack
of tail call support. What cpu do you have (ppc/x86, 32/64 bit)?

--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag

[Ryan Schmidt]

On Dec 6, 2009, at 03:25, Albert Graef wrote:

> Cleverton Hentz wrote:
>
>> I'm testing simple exemples in Pure 0.38 (Macports), but I get segmentation fault. This code cause error:
>>
>> > map id (1..5);
>>

>> (This I get from "The Pure Library Manual", section 1.1)
>>
>> or
>>
>> > f a = a+1;
>> > map f [1,2,3];
>>
>> In two cases the error is raised. I code some wrong ?
>>
>> My configurations is :
>> Max OS X (10.6.2)
>> MacPort 1.8.1
>> LLVM 2.6.1
>> Pure 0.38
>

> Not sure, but this usually indicates either a miscompiled LLVM or a lack
> of tail call support. What cpu do you have (ppc/x86, 32/64 bit)?

If he's running Mac OS X 10.6.x, he can only be using an i386 or x86_64 CPU. Apple dropped PowerPC support with the release of Snow Leopard.

There is no LLVM 2.6.1. 2.6 is the latest version, which is what we have in MacPorts. In llvm @2.6_1 we enabled position-independent code by default again, which pure requires, and in @2.6_2, I fixed it so it builds x86_64 code again on x86_64 CPUs. So if he got pure to compile using llvm @2.6_1, he's got a 32-bit (Intel Core) processor. If he's got a 64-bit processor, he must be using llvm @2.6_2.

I am able to reproduce the problem on my MacBookPro3,1 (which has a 2.2-GHz Intel Core 2 Duo processor) running Mac OS X 10.6.2, pure 0.38_0 and llvm 2.6_2, using the code above.

Half the test suite still fails on Snow Leopard with x86_64, as I noted before, which might be a place to start:

http://groups.google.com/group/pure-lang/browse_thread/thread/71f69104c7113342

Attached are the test directory after running the test suite for pure 0.38, and the crash reports Mac OS X recorded.

[Albert Graef]

Ryan Schmidt wrote:
> If he's running Mac OS X 10.6.x, he can only be using an i386 or x86_64 CPU. Apple dropped PowerPC support with the release of Snow Leopard.

Ok, I see.

> There is no LLVM 2.6.1.

So I guess that Cleverton meant 2.6_1 which would indicate x86.

> Half the test suite still fails on Snow Leopard with x86_64, as I noted before, which might be a place to start:

Yes, I remember this. But you suspected a 64 bit problem, so I assumed
that x86-32 was working ok. Apparently it has the same problems?

It would be nice if you could file a bug report at
http://code.google.com/p/pure-lang/issues/list so that we can keep an
eye on this.

> Attached are the test directory after running the test suite for pure 0.38, and the crash reports Mac OS X recorded.

Well, it seems that it segfaults when calling a function, which would
indicate that the LLVM JIT either generates wrong code for function
calls or returns bad pointers for JITed functions. That's weird, because
I'd expect the JIT to work the same as on other x86 systems, and it's
working fine on Linux, FreeBSD, NetBSD and Windows.

One thing that you can try to rule out TCO issues would be to run the
tests as:

PURE_FLAGS=--notc make check

(This needs Pure >= 0.38.) Does that improve the situation?

Other than that, I'm afraid that I'd need access to an Intel Mac to
debug this issue.

Albert

[Cleverton Hentz]

Hi,

Sorry for my misunderstood with LLVM version. The result of my port info is "llvm @2.6, Revision 2 (lang)" and I have install 2.6_1.

I try PURE_FLAGS, but I got same error. I need re-compile the pure with this option ? Because I simple set and run.

Any alternative for me ?

Thanks,

--

You received this message because you are subscribed to the Google Groups "pure-lang" group.
To post to this group, send email to pure...@googlegroups.com.
To unsubscribe from this group, send email to pure-lang+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pure-lang?hl=en.

[Albert Graef]

Cleverton Hentz wrote:
> Sorry for my misunderstood with LLVM version. The result of my port info
> is "llvm @2.6, Revision 2 (lang)" and I have install 2.6_1.

That's not consistent. Revision 2 of the port should be 2.6_2, not
2.6_1, right? (Ryan?)

Cleverton: What cpu do you have? Is it 32 bit (Intel Core) or 64 bit
(Intel Core 2)?

> I try PURE_FLAGS, but I got same error. I need re-compile the pure with
> this option ? Because I simple set and run.

No, that option is only recognized by 'make check'. If you run the
interpreter from the command line, try this:

pure --notc

[Albert Graef]

Albert Graef wrote:
> Well, it seems that it segfaults when calling a function, which would
> indicate that the LLVM JIT either generates wrong code for function
> calls or returns bad pointers for JITed functions. That's weird, because
> I'd expect the JIT to work the same as on other x86 systems, and it's
> working fine on Linux, FreeBSD, NetBSD and Windows.

This seems to be related: http://llvm.org/bugs/show_bug.cgi?id=5201

This supports my theory that the LLVM JIT generates bad code for
function calls in some situations. At least that seems to be true after
the JIT memory manager was changed somewhere on the road to LLVM 2.6.
Specifically, in LLVM 2.6 the JIT always creates near calls (32 bit
boundary) which might break on 64 bit systems, since the new memory
manager doesn't guarantee that the code of JITed functions is in
contiguous storage any more. (In fact I never saw this on Linux x86_64,
but I'm seeing all kinds of weird segfaults with LLVM 2.7svn now, and
I'm pretty sure that these are related to PR5201 as well. I'm currently
investigating this.)

Ryan, I don't recall, was your original report concerning these crashes
on Snow Leopard/x86_64 about Pure+LLVM 2.5, or did you already run LLVM
2.6 at that time? If the latter, it might be worth trying whether Pure
works with LLVM 2.5 on that platform.

[Cleverton Hentz]

Sorry again, version is 2.6_2. I'm try this configurations:

1:

LLVM 2.6 (Macport @2.6_2)

Pure 0.38 (@0.38_0+macosx)

2:

LLVM 2.5 (Macport @2.5_1)

Pure 0.36 (Macport @0.36_0+macosx)

In both I get segmentation fault with this code "map id (1..5);".

My CPU is Intel Core 2 Duo with two cores.

[Cleverton Hentz]

In configuration 1 I run "--notc" and 2 don't support this option.

[Ryan Schmidt]

On Dec 7, 2009, at 05:57, Albert Graef wrote:

> Cleverton Hentz wrote:
>> Sorry for my misunderstood with LLVM version. The result of my port info
>> is "llvm @2.6, Revision 2 (lang)" and I have install 2.6_1.
>
> That's not consistent. Revision 2 of the port should be 2.6_2, not
> 2.6_1, right? (Ryan?)

"port info llvm" shows the version currently available in the user's port tree; "port installed llvm" shows the version currently installed on the user's system. So it's certainly possible for the user to have 2.6_1 installed while 2.6_2 is available to be installed. Though in this case the user appears to have either misremembered the version, or subsequently upgraded llvm:

[Ryan Schmidt]

On Dec 7, 2009, at 06:26, Albert Graef wrote:

> This seems to be related: http://llvm.org/bugs/show_bug.cgi?id=5201
>
> This supports my theory that the LLVM JIT generates bad code for
> function calls in some situations. At least that seems to be true after
> the JIT memory manager was changed somewhere on the road to LLVM 2.6.
> Specifically, in LLVM 2.6 the JIT always creates near calls (32 bit
> boundary) which might break on 64 bit systems, since the new memory
> manager doesn't guarantee that the code of JITed functions is in
> contiguous storage any more. (In fact I never saw this on Linux x86_64,
> but I'm seeing all kinds of weird segfaults with LLVM 2.7svn now, and
> I'm pretty sure that these are related to PR5201 as well. I'm currently
> investigating this.)

That bug report says it was fixed in LLVM r88984 but the patch does not apply cleanly to the LLVM 2.6 sources so I can't easily test if that fixes the issue here.

> Ryan, I don't recall, was your original report concerning these crashes
> on Snow Leopard/x86_64 about Pure+LLVM 2.5, or did you already run LLVM
> 2.6 at that time? If the latter, it might be worth trying whether Pure
> works with LLVM 2.5 on that platform.

The llvm port wasn't updated to 2.6 until MacPorts r60440 (2009-11-12) so my prior report in September was with LLVM 2.5.

[Albert Graef]

Cleverton Hentz wrote:
> Sorry again, version is 2.6_2. I'm try this configurations:

Ok, so this is the same bug that Ryan reported. It seems that in fact
the LLVM JIT generates wrong code on OSX/x86_64.

If it's indeed related to the far call issue, then there's a chance that
LLVM 2.7 from svn might already fix this. Unfortunately, there's some
breakage in the latest LLVM 2.7 from svn, too. I'm current replaying
commits that seem to affect the JIT to see which recent LLVM revisions
Pure works with on my Linux system. Once I have this sorted out (it
takes a while, since I have to recompile different revisions of LLVM
over and over again), we can do another test using a revision of LLVM
2.7 for which there's hope that it works better.

Ryan, for the time being it might also be worth trying whether the 32
bit version works. Do you have access to a 32 bit OSX/x86 system somewhere?

Albert

[Ryan Schmidt]

On Dec 7, 2009, at 15:24, Albert Graef wrote:

> Ryan, for the time being it might also be worth trying whether the 32
> bit version works. Do you have access to a 32 bit OSX/x86 system somewhere?

All tests pass with pure 0.39 on Snow Leopard when built 32-bit.

I don't have access to a physically 32-bit Intel Mac, but I instructed MacPorts to build 32-bit by setting build_arch to i386 in macports.conf. The caveat is that all dependencies must be built 32-bit too, so you really have to decide to build 32-bit before you've installed any ports -- or uninstall all ports (sudo port -f uninstall installed) after switching build_arch. The ability to switch build architectures is also new for MacPorts 1.8.0, so many ports don't properly support it yet. In fact, I had to patch pure to make it work; see the attachment, which I think should be safe to commit to your repository.

[Albert Graef]

Albert Graef wrote:
> If it's indeed related to the far call issue, then there's a chance that
> LLVM 2.7 from svn might already fix this. Unfortunately, there's some
> breakage in the latest LLVM 2.7 from svn, too. I'm current replaying
> commits that seem to affect the JIT to see which recent LLVM revisions
> Pure works with on my Linux system. Once I have this sorted out (it
> takes a while, since I have to recompile different revisions of LLVM
> over and over again), we can do another test using a revision of LLVM
> 2.7 for which there's hope that it works better.

Well, it turns out that the proposed fix for PR5201 in LLVM 2.7svn
(r88984) is exactly what breaks fastcc+tail calls in the Pure
interpreter. Catch22. :(

Anyway, for the time being we might still be able to get it to work,
albeit without tail call optimization. That's still better than nothing.

Ryan, to conduct this test on OSX/x86_64, you'll need the following:

- Latest LLVM from svn.

- Latest Pure from svn (r2802 should be fine). You can also use Pure
0.39, but then you'll have to comment out line 160 in interpreter.cc,
see my previous post "Re: LLVM 2.7 svn Error" for details.

After installing LLVM 2.7svn, you should be able to build Pure with
'./configure --disable-fastcc' (same as on PPC). Then run 'make check'
to see whether it works.

Good luck!

[Albert Graef]

Ryan Schmidt wrote:
> All tests pass with pure 0.39 on Snow Leopard when built 32-bit.

That's good to know. I updated the system notes section in the INSTALL
file accordingly.

> In fact, I had to patch pure to make it work; see the attachment, which I think should be safe to commit to your repository.

Hmm, you're apparently using CXXFLAGS to pass options to the linker
there. That's not really what CXXFLAGS is meant for; it's for C++
compiler options. LDFLAGS is the right variable for passing options to
the linker. If there are options which must be passed to both compiler
and linker, you'll have to set up both CXXFLAGS and LDFLAGS accordingly.

[Ryan Schmidt]

On Dec 8, 2009, at 03:44, Albert Graef wrote:

> Ryan Schmidt wrote:
>
>> In fact, I had to patch pure to make it work; see the attachment, which I think should be safe to commit to your repository.
>
> Hmm, you're apparently using CXXFLAGS to pass options to the linker
> there. That's not really what CXXFLAGS is meant for; it's for C++
> compiler options. LDFLAGS is the right variable for passing options to
> the linker. If there are options which must be passed to both compiler
> and linker, you'll have to set up both CXXFLAGS and LDFLAGS accordingly.

MacPorts puts e.g. "-O2 -arch i386" into CFLAGS and CXXFLAGS. I guess -arch is a compiler flag and a linker flag then?

[Albert Graef]

Ryan Schmidt wrote:
> MacPorts puts e.g. "-O2 -arch i386" into CFLAGS and CXXFLAGS. I guess -arch is a compiler flag and a linker flag then?

Yes, so it needs to go into CFLAGS/CXXFLAGS *and* LDFLAGS. Actually, the
autoconf manual suggests to either put cross-phase options such as -m
into CC/CXX or into both CPPFLAGS and LDFLAGS. In any case, just adding
CXXFLAGS to the link line is a bad idea, that's not how these variables
are supposed to be used. Even if it works sometimes, it's definitely not
a clean solution.

[Ryan Schmidt]

On Dec 8, 2009, at 15:26, Albert Graef wrote:

> Ryan Schmidt wrote:
>> MacPorts puts e.g. "-O2 -arch i386" into CFLAGS and CXXFLAGS. I guess -arch is a compiler flag and a linker flag then?
>
> Yes, so it needs to go into CFLAGS/CXXFLAGS *and* LDFLAGS. Actually, the
> autoconf manual suggests to either put cross-phase options such as -m
> into CC/CXX or into both CPPFLAGS and LDFLAGS. In any case, just adding
> CXXFLAGS to the link line is a bad idea, that's not how these variables
> are supposed to be used. Even if it works sometimes, it's definitely not
> a clean solution.

Thanks, I'll see about getting that fix into MacPorts 1.8.2.

[Cleverton Hentz]

Hi,

I get and compile LLVM 2.7 (r91540). Binary of this version are locate in specific path, I don't want change my original configuration of LLVM and Pure. How I configure Pure svn version for look my specific dir with llvm 2.7 ?

I try "./configure --help" but don't see any option for it. This kind of configuration is possible ?

Cheers,

Cleverton

[Albert Graef]

Cleverton Hentz wrote:
> I get and compile LLVM 2.7 (r91540). Binary of this version are locate
> in specific path, I don't want change my original configuration of LLVM
> and Pure. How I configure Pure svn version for look my specific dir with
> llvm 2.7 ?
>
> I try "./configure --help" but don't see any option for it. This kind of
> configuration is possible ?

There's no configure option for it, but as Pure uses llvm-config to
figure out the required LLVM compilation options and libraries to link,
setting PATH so that it locates the right llvm-config at build time
should be all that's needed.

But note that the LLVM 2.7svn JIT currently has problems with tail calls
on x86_64, so you might have to run Pure with the --notc option. More
details about this can be found in the thread "LLVM 2.7 svn Error", see
http://groups.google.com/group/pure-lang/t/f1a9d7c09c5c0d9b.

[Cleverton Hentz]

Ok, Thanks!

--