At Wed, 11 May 2011 10:25:57 -0300, David Bremner wrote:
> On Tue, 10 May 2011 23:58:07 -0300, David Bremner 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 fol
On Tue, 10 May 2011 23:58:07 -0300, David Bremner 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 developers and
my cur
On Tue, 10 May 2011 00:14:42 -0300, David Bremner wrote:
> On Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt 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.
>
> I suppose
On Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt 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 (squeeze), one should
At Mon, 9 May 2011 06:56:48 -0600, Matthew Flatt 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.
>
> In "src/racket/gc2/sighand.c" around line 137:
>
> # if defined(__FreeBSD__
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.
In "src/racket/gc2/sighand.c" around line 137:
# if defined(__FreeBSD__) && (__FreeBSD_version < 70)
#define USE_SIGACTON_SIGNAL_KIND
On Fri, 29 Apr 2011 08:46:32 -0600, Matthew Flatt 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
current git mast
On Fri, 29 Apr 2011 08:46:32 -0600, Matthew Flatt wrote:
> I've pushed fixes for kFreeBSD, so let me know if you encounter further
> problems.
>
The latest commit (b5f86a26...) seems to fix all the remaining problems
I know about. The current git master builds, build collects, and passes
minimal
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 Thu, 28 Apr 2011 19:37:42 -0600, Matthew Flatt 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
traceback from
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 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 Flatt wr
At Thu, 28 Apr 2011 21:00:24 -0300, David Bremner wrote:
> On Thu, 28 Apr 2011 07:00:46 -0600, Matthew Flatt 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(__
On Thu, 28 Apr 2011 07:00:46 -0600, Matthew Flatt 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 bus error
On Thu, 28 Apr 2011 09:07:28 -0600, Matthew Flatt wrote:
> Looks like it should really be
>
> #ifdef FREEBSD_CONTROL_387
> #include
> #endif
>
> Does that work on your machine?
It works with the additional patch
>From a8be877b89891a0c19a99b37a6218057e04f5456 Mon Sep 17 00:00:00 2001
From:
At Wed, 27 Apr 2011 21:42:05 -0300, David Bremner wrote:
> --- a/src/racket/src/number.c
> +++ b/src/racket/src/number.c
> @@ -183,6 +183,8 @@ READ_ONLY Scheme_Object *scheme_single_inf_object,
> *scheme_single_minus_inf_obje
>
>
> #ifdef FREEBSD_CONTROL_387
> +#include
> +#include
> #incl
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 Wed, 27 Apr 2011 18:48:51 -0600, Matthew Flatt 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. Resident set s
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
I had to apply the attached patch to get current git or 5.1 to compile
on Debian/kFreeBSD-i386, but then it runs out of memory building the
docs in a 4G virtual machine (with not much swap).
I'm flying blind a bit here, I couldn't find much documentation. Does
that patch look problematic? Can s
19 matches
Mail list logo
