At Wed, 11 May 2011 10:25:57 -0300, David Bremner wrote:
On Tue, 10 May 2011 23:58:07 -0300, David Bremner brem...@debian.org wrote:
I don't claim to understand all the implications yet, but the following
patch seems to work, i.e. catching both SIGSEGV and SIGBUS with the same
handler.
On Tue, 10 May 2011 23:58:07 -0300, David Bremner brem...@debian.org wrote:
I don't claim to understand all the implications yet, but the following
patch seems to work, i.e. catching both SIGSEGV and SIGBUS with the same
handler.
As a followup, I talked a bit more to the Debian/kFreeBSD
On Tue, 10 May 2011 00:14:42 -0300, David Bremner brem...@debian.org wrote:
On Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
Maybe someone decided that SIGSEGV is the right signal after all for an
mprotect() violation (which Rackets catches as a write barrier)
On Fri, 29 Apr 2011 08:46:32 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
I've pushed fixes for kFreeBSD, so let me know if you encounter further
problems.
It seems the updates (gcc?) on kFreeBSD (i386 and amd64) cause a
regression: I am getting a segmentation fault from make gracket3m with
On Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
Maybe someone decided that SIGSEGV is the right signal after all for an
mprotect() violation (which Rackets catches as a write barrier) instead
of SIGBUS.
This seems to be about right. In Debian/kFreeBSD stable
I've pushed fixes for kFreeBSD, so let me know if you encounter further
problems.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
On Wed, 27 Apr 2011 18:48:51 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
Do you have any process limits set? (My impression is memory is often
limited by default on FreeBSD systems.)
There was a limit of 512M on data segment size, which I raised to 2G, but it
doesn't seem to change much.
Looking back at previous messages reminds me that you may be using
`--enable-cgcdefault'. Is that still the case? If so, the memory
problem makes sense, because conservative GC has problems at the scale
of `raco setup'.
To make 3m work right, src/racket/gc2/sighand.c needs a
__FreeBSD_kernel__
On Thu, 28 Apr 2011 09:07:28 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
Looks like it should really be
#ifdef FREEBSD_CONTROL_387
#include ieeefp.h
#endif
Does that work on your machine?
It works with the additional patch
From a8be877b89891a0c19a99b37a6218057e04f5456 Mon Sep 17
On Thu, 28 Apr 2011 07:00:46 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
To make 3m work right, src/racket/gc2/sighand.c needs a
__FreeBSD_kernel__ on line 128:
#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__NetBSD__) || defined(__OpenBSD__)
Does that avoid the
At Thu, 28 Apr 2011 21:00:24 -0300, David Bremner wrote:
On Thu, 28 Apr 2011 07:00:46 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
To make 3m work right, src/racket/gc2/sighand.c needs a
__FreeBSD_kernel__ on line 128:
#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
I think I'm asking the wrong question. I should instead ask:
What does the man page for fpsetmask() say should be #included?
(The switch to #include ieeefp.h was based on a FreeBSD man page.)
At Thu, 28 Apr 2011 21:01:11 -0300, David Bremner wrote:
On Thu, 28 Apr 2011 09:07:28 -0600, Matthew
On Thu, 28 Apr 2011 19:37:42 -0600, Matthew Flatt mfl...@cs.utah.edu wrote:
But then I had a bus error, as before.
A stack trace might be helpful. Otherwise, I guess I'll have to set up
a kFreeBSD virtual machine.
I couldn't find any documentation on fpsetmask so far, but here is a
That patch looks fine.
Do you have any process limits set? (My impression is memory is often
limited by default on FreeBSD systems.)
At Wed, 27 Apr 2011 21:42:05 -0300, David Bremner wrote:
I had to apply the attached patch to get current git or 5.1 to compile
on Debian/kFreeBSD-i386, but
14 matches
Mail list logo
