[racket-dev] support for arm64 / aarch64
A user submitted the attached patch for partial support for arm64 on Debian/Ubuntu. It only enables cgc, 3m still hangs during compilation. If the patch makes sense to you, perhaps you'd like to apply it upstream. d From 7b5acfba9a1df00f0427d1d2e1a92570da3ab2d1 Mon Sep 17 00:00:00 2001 From: Yvan Roux yvan.r...@linaro.org Date: Wed, 23 Jan 2013 23:15:57 +0400 Subject: [PATCH] Add AArch64 (64-bit ARM) target support * include/private/gcconfig.h (AARCH64): New macro (defined only if __aarch64__). * include/private/gcconfig.h (mach_type_known): Update comment adding ARM AArch64 target. * include/private/gcconfig.h (NOSYS, mach_type_known, CPP_WORDSZ, MACH_TYPE, ALIGNMENT, HBLKSIZE, OS_TYPE, LINUX_STACKBOTTOM, DYNAMIC_LOADING, DATASTART, DATAEND, STACKBOTTOM): Define for AArch64. --- include/private/gcconfig.h | 37 + 1 file changed, 37 insertions(+) --- a/src/racket/gc/include/private/gcconfig.h +++ b/src/racket/gc/include/private/gcconfig.h @@ -76,6 +76,13 @@ # endif /* Determine the machine type: */ +# if defined(__aarch64__) +#define AARCH64 +#if !defined(LINUX) +# define NOSYS +# define mach_type_known +#endif +# endif # if defined(__arm__) || defined(__thumb__) #define ARM32 #if !defined(LINUX) !defined(NETBSD) !defined(OPENBSD) @@ -249,6 +256,10 @@ #define IA64 #define mach_type_known # endif +# if defined(LINUX) defined(__aarch64__) +#define AARCH64 +#define mach_type_known +# endif # if defined(LINUX) defined(__arm__) #define ARM32 #define mach_type_known @@ -529,6 +540,7 @@ /* running Amdahl UTS4 */ /* S390 == 390-like machine */ /* running LINUX */ + /* AARCH64== ARM AArch64 */ /* ARM32 == Intel StrongARM */ /* IA64 == Intel IPF */ /* (e.g. Itanium) */ @@ -1818,6 +1830,31 @@ # endif # endif +# ifdef AARCH64 +# define CPP_WORDSZ 64 +# define MACH_TYPE AARCH64 +# define ALIGNMENT 8 +# ifndef HBLKSIZE +# define HBLKSIZE 4096 +# endif +# ifdef LINUX +# define OS_TYPE LINUX +# define LINUX_STACKBOTTOM +# define DYNAMIC_LOADING + extern int __data_start[]; +# define DATASTART ((ptr_t)__data_start) + extern char _end[]; +# define DATAEND ((ptr_t)(_end)) +# endif +# ifdef NOSYS + /* __data_start is usually defined in the target linker script. */ + extern int __data_start[]; +# define DATASTART ((ptr_t)__data_start) + extern void *__stack_base__; +# define STACKBOTTOM ((ptr_t)__stack_base__) +# endif +# endif + # ifdef ARM32 # define CPP_WORDSZ 32 # define MACH_TYPE ARM32 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] crash running raco setup with racket 6.1
David Bremner da...@tethera.net writes: Building racket 6.1, from racket-6.1-src.tgz, the debian build calls make install twice, the first time with PLT_EXTRA=--no-docs --no-zo, and the second time with PLT_EXTRA=--no-launcher --no-install --no-post-install. This second (main) call is crashing after some recent change in Debian unstable (not sure what, but it worked Monday). As a point of information, I can duplicate the crash with yesterdays snapshot (20141022-d9f2a84). I didn't bother getting a backtrace there, but I can if it would help. d _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] crash running raco setup with racket 6.1
David Bremner da...@tethera.net writes: As a point of information, I can duplicate the crash with yesterdays snapshot (20141022-d9f2a84). I didn't bother getting a backtrace there, but I can if it would help. I verified that the version of libcairo2 is what makes a difference. Installing Debian version 1.12.16-5 made the racket build work again both for 6.1 and for the snapshot. Alas that's not going to be a feasible strategy for the official Debian builds. d _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] crash running raco setup with racket 6.1
Jens Axel Søgaard jensa...@soegaard.net writes: It might me worth doubling checking that the versions of the shared libaries that Racket loads matches your expectations. Then again, maybe there were an API change in Cairo that caused the problem - and if so the above is irrelevant. Since I'm building for Debian, I have less flexibility with the libraries; more or less the whole point is that everyone uses the same libcairo2. Of course there could be a problem with the way libcairo is compiled; then I'd expect a flood of complaints from other packages. I wasn't able to find a documented API change so far. I'd be very interested to know if other people can build racket with libcairo 1.14.0. It is quite new. I managed to isolate the problem a little to running scribble on a particular file. Here is a new backtrace (with libcairo symbols) from running % gdb --args build/racket/racket3m -j -X /home/bremner/software/debian/racket/debian/tmp/usr/share/racket/collects -G /home/bremner/software/debian/racket/debian/tmp/etc/racket debian/tmp/usr/share/racket/pkgs/images-doc/images/scribblings/images.scrbl #0 0x7713f077 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x77140458 in __GI_abort () at abort.c:89 #2 0x006a9fde in fault_handler ( sn=optimized out, si=0x9ea530, ctx=optimized out) at /home/bremner/software/debian/racket/src/racket/gc2/sighand.c:99 #3 signal handler called #4 _fill_xrgb32_lerp_opaque_spans ( abstract_renderer=0x7fff73d0, y=343, h=0, spans=0x1372088, num_spans=5) at ../../../../src/cairo-image-compositor.c:2249 #5 0x7fffeda67406 in blit_a8 (xmax=483, xmin=463, height=1, y=343, spans=0x1372078, renderer=0x7fff73d0, cells=optimized out) at ../../../../src/cairo-tor-scan-converter.c:1635 #6 glitter_scan_converter_render ( renderer=0x7fff73d0, antialias=1, winding_mask=optimized out, converter=optimized out) at ../../../../src/cairo-tor-scan-converter.c:1786 #7 _cairo_tor_scan_converter_generate ( converter=0x1370ff0, renderer=0x7fff73d0) at ../../../../src/cairo-tor-scan-converter.c:1849 #8 0x7fffeda5952c in composite_polygon ( extents=extents@entry=0x7fff8d00, polygon=polygon@entry=0x7fff88b0, fill_rule=fill_rule@entry=CAIRO_FILL_RULE_WINDING, antialias=antialias@entry=CAIRO_ANTIALIAS_GRAY, compositor=0x7fffedd02140 spans, compositor=0x7fffedd02140 spans) at ../../../../src/cairo-spans-compositor.c:801 #9 0x7fffeda59f95 in clip_and_composite_polygon ( compositor=compositor@entry=0x7fffedd02140 spans, extents=extents@entry=0x7fff8d00, polygon=polygon@entry=0x7fff88b0, fill_rule=CAIRO_FILL_RULE_WINDING, antialias=antialias@entry=CAIRO_ANTIALIAS_GRAY) at ../../../../src/cairo-spans-compositor.c:967 #10 0x7fffeda5abba in _cairo_spans_compositor_stroke ( _compositor=0x7fffedd02140 spans, extents=0x7fff8d00, path=optimized out, style=0x7fff9110, ctm=0x7fff9140, ctm_inverse=0x7fff9170, tolerance=0.10001, antialias=CAIRO_ANTIALIAS_GRAY) at ../../../../src/cairo-spans-compositor.c:1083 #11 0x7fffeda15d8f in _cairo_compositor_stroke ( compositor=0x7fffedd02140 spans, surface=0x74a88000, op=CAIRO_OPERATOR_CLEAR, source=0x70003, path=0xadaa38, style=0x7fff9110, ctm=0x7fff9140, ctm_inverse=0x7fff9170, tolerance=1.3906711615657361e-309, antialias=CAIRO_ANTIALIAS_GRAY, clip=0xa81480) at ../../../../src/cairo-compositor.c:157 #12 0x7fffeda27062 in _cairo_image_surface_stroke ( abstract_surface=optimized out, op=optimized out, source=optimized out, path=optimized out, style=optimized out, ctm=optimized out, ctm_inverse=0x7fff9170, tolerance=optimized out, antialias=CAIRO_ANTIALIAS_GRAY, clip=0xa81480) at ../../../../src/cairo-image-surface.c:964 #13 0x7fffeda5df56 in _cairo_surface_stroke ( surface=0xddfbd0, op=CAIRO_OPERATOR_OVER, source=0x7fff91a0, path=0xadaa38, stroke_style=0x7fff9110, ctm=0x7fff9140, ctm_inverse=0x7fff9170, tolerance=0.10001, antialias=CAIRO_ANTIALIAS_GRAY, clip=0xa81480) at ../../../../src/cairo-surface.c:2270 #14 0x7fffeda1dc02 in _cairo_gstate_stroke ( gstate=0xada700, path=path@entry=0xadaa38) at ../../../../src/cairo-gstate.c:1194 #15 0x7fffeda176e9 in _cairo_default_context_stroke ( abstract_cr=0xada6d0) at ../../../../src/cairo-default-context.c:1010 #16 0x7fffeda10725 in INT_cairo_stroke (cr=0xaa) at ../../../../src/cairo.c:2150 #17 0x776d4d1e in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #18 0x776d4788 in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #19 0x0069b696 in ffi_do_call ( argv=0x7fffca105a68, self=0x74a88000,
[racket-dev] crash running raco setup with racket 6.1
Building racket 6.1, from racket-6.1-src.tgz, the debian build calls make install twice, the first time with PLT_EXTRA=--no-docs --no-zo, and the second time with PLT_EXTRA=--no-launcher --no-install --no-post-install. This second (main) call is crashing after some recent change in Debian unstable (not sure what, but it worked Monday). At the end you can find a backtrace generated with % gdb --args racket/racket3m -j -X /home/bremner/software/debian/racket/debian/tmp/usr/share/racket/collects -G /home/bremner/software/debian/racket/debian/tmp/etc/racket -N raco -l- setup --no-user -j 1 --no-launcher --no-install --no-post-install (where DESTDIR=/home/bremner/software/debian/racket/tmp) This particular backtrace is generated with libcairo2 1.14.0-2 (I don't think the debian revision -2 is likely relevant). For what it's worth, my debian testing system has cairo 1.12.16-5 on it, and the build runs fine there. #0 0x7713f077 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x77140458 in __GI_abort () at abort.c:89 #2 0x006a9f9e in fault_handler ( sn=optimized out, si=0x9ea5b0, ctx=optimized out) at /home/bremner/software/debian/racket/src/racket/gc2/sighand.c:99 #3 signal handler called #4 0x7fffe9d63924 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #5 0x7fffe9da7406 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #6 0x7fffe9d9952c in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #7 0x7fffe9d99f95 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #8 0x7fffe9d9abba in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #9 0x7fffe9d55d8f in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #10 0x7fffe9d67062 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #11 0x7fffe9d9df56 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #12 0x7fffe9d5dc02 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #13 0x7fffe9d576e9 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #14 0x7fffe9d50725 in cairo_stroke () from /usr/lib/x86_64-linux-gnu/libcairo.so.2 #15 0x776d4d1e in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #16 0x776d4788 in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #17 0x0069b656 in ffi_do_call ( argv=0x7fffd0599a68, self=0x7458d004, argc=optimized out) at /home/bremner/software/debian/racket/src/racket/gc2/../src/../../foreign/foreign.c:3459 #18 0x0069b973 in ffi_do_call_after_stack_check ( argc=1, argv=0x7fffd0599a68, self=0x7fffbe99b338) at /home/bremner/software/debian/racket/src/racket/gc2/../src/../../foreign/foreign.c:3515 #19 0x00469215 in scheme_do_eval ( obj=optimized out, num_rands=1, num_rands@entry=-1, rands=optimized out, rands@entry=0x0, get_value=get_value@entry=-1) at /home/bremner/software/debian/racket/src/racket/gc2/../src/eval.c:2697 #20 0x004690f4 in scheme_do_eval ( obj=optimized out, num_rands=optimized out, num_rands@entry=-1, rands=optimized out, rands@entry=0x0, get_value=get_value@entry=-1) at /home/bremner/software/debian/racket/src/racket/gc2/../src/eval.c:3460 #21 0x004690f4 in scheme_do_eval ( obj=optimized out, num_rands=optimized out, num_rands@entry=-1, rands=optimized out, rands@entry=0x0, get_value=get_value@entry=-1) at /home/bremner/software/debian/racket/src/racket/gc2/../src/eval.c:3460 #22 0x0046 in begin0_execute ( obj=0x7fffecdf6548) at /home/bremner/software/debian/racket/src/racket/gc2/../src/eval.c:2257 #23 0x004689a8 in scheme_do_eval ( obj=optimized out, num_rands=optimized out, rands=optimized out, get_value=-1) at /home/bremner/software/debian/racket/src/racket/gc2/../src/eval.c:3759 #24 0x0048ebf1 in scheme_apply_chaperone ( o=0x7fffec08ce50, argc=2, argv=0x7fffd0599c40, auto_val=0x0, checks=85, checks@entry=0) at /home/bremner/software/debian/racket/src/racket/gc2/../src/fun.c:3714 #25 0x00468592 in scheme_do_eval ( obj=optimized out, num_rands=2, num_rands@entry=-1, rands=optimized out, rands@entry=0x0, get_value=get_value@entry=-1) at /home/bremner/software/debian/racket/src/racket/gc2/../src/eval.c:3087 #26 0x004690f4 in scheme_do_eval ( obj=optimized out, num_rands=optimized out, num_rands@entry=-1, rands=optimized out, rands@entry=0x0, get_value=get_value@entry=1) at /home/bremner/software/debian/racket/src/racket/gc2/../src/eval.c:3460 #27 0x00469cb2 in scheme_do_eval ( obj=optimized out, num_rands=optimized out, num_rands@entry=-1, rands=optimized out, rands@entry=0x0, get_value=get_value@entry=-1) at /home/bremner/software/debian/racket/src/racket/gc2/../src/eval.c:3660 #28 0x004690f4 in scheme_do_eval ( obj=optimized out,
Re: [racket-dev] advice on the 6.x build system.
Matthew Flatt mfl...@cs.utah.edu writes: Meanwhile, I haven't answered your original question. Can you remind me of the specific steps that I'd need to follow to try the script that you sent before? With your indulgence, I'll just answer this part now. I have re-included the Makefile as an attachment, since make is fussy about whitespace. Save the attached file to e.g. /tmp/test.mk In a recent checkout of the release branch, % make -f /tmp/test.mk build-indep-stamp the resulting build of racket will be in test-dest, in the top level directory of racket. For me, test-dest/usr/bin only has racket and raco in it. test.mk Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] advice on the 6.x build system.
I've been been trying to rework the debian racket packaging, and to
understand the new racket build system. I need to have the two seperate
targets, which most of the package installation is done in the the
build-indep-stamp target.
The following makefile snippet is _almost_ working, except that I'm
missing a launcher for drracket. After installing debian/tmp, running
/usr/lib/racket/gracket and (require drracket) seems to work ok to start
drracket, so I take that as indicating most of the packages / collects
are in the right place. Can anyone see what I'm doing wrong here?
I should say that I tried to make better use of the top level makefile,
but I ended up with wrong default collects paths (probably just a
different error on my part).
I tried all of this (most recently) with the current release branch
(c326c21b73356e)
destdir:=$(CURDIR)/debian/tmp
base_build_dir:=$(CURDIR)/racket/src/build
PRERACKET:=${destdir}/usr/bin/racket -X ${destdir}/usr/share/racket/collects
raco_args:=--catalog build/local/catalog --auto -i --skip-installed
${base_build_dir}/Makefile:
mkdir -p ${base_build_dir}
cd ${base_build_dir} $(CURDIR)/racket/src/configure --prefix=/usr
build-arch-stamp: ${base_build_dir}/Makefile
$(MAKE) -C ${base_build_dir}
$(MAKE) -C ${base_build_dir} DESTDIR=${destdir} install
touch $@
build-indep-stamp: build-arch-stamp
$(MAKE) RACKET=${PRERACKET} \
local-source-catalog
${PRERACKET} -N raco -l- \
pkg install ${raco_args} main-distribution racket-lib
touch $@
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] advice on the 6.x build system.
Matthew Flatt mfl...@cs.utah.edu writes: That said, is there a particular reason that basing the build on the git repo would be better? One reason is that I need I need to track from release to release the files that are removed from the racket source by debian for licensing-related reasons. Currently this looks like: ╰─ (git)-[new-master]-% git diff --stat dfsg..upstream .../drdr/static/jquery-1.6.2.min.js| 18 + .../resources/js/libs/gumby.min.js |1 + .../js/libs/jquery-1.9.1.min.js|5 + .../libs/jquery.mobile.custom.min.js |3 + .../js/libs/modernizr-2.6.2.min.js |4 + .../resources/js/plugins.js|8 + .../racket/benchmarks/common/maze.sch | 680 ++ .../racket/benchmarks/common/maze2.sch | 695 ++ .../common/psyntax-input.txt | 4296 .../benchmarks/common/typed/maze2.rktl | 772 ++ .../racket-test/tests/xml/xmltest.zip | Bin 0 - 107060 bytes I used to do this by importing the tarballs on top of the git history, but since 6.0 this import creates a massive diff because of all the re-arranging that happens in tarball creating process. At this point the I the history becomes difficult to follow (or at least ugly). From our point of view, once we have to delete things, the tarballs also lose their status as an pristine work of upstream. A second reason is that I want to be able to able to backport patches to older releases of racket running on Debian. This is much easier if I can just use git cherry-pick. A third reason (related) is that from time to time I need to test the Debian packaging of an as yet unreleased racket version, e.g. to check if a build failure is fixed in the upcoming 6.1.1 branch. d _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] potentially renaming /usr/bin/planet to /usr/bin/planet-racket in Debian
Hi All; We're currently trying to figure out the right way to handle a name conflict in Debian between racket and an rss aggregator named planet-venus. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680685 I don't use the command /usr/bin/planet myself, so I was wondering if anybody could explain the likely disruption caused by (hypothetically) renaming it. In particular is it likely to be somether where people are using it from scripts or cron jobs, or would making a shell alias (alias planet planet-racket) suffice to avoid retraining fingers? Thanks David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] build hang on s390x
On Mon, 27 Feb 2012 09:46:43 -0700, Matthew Flatt mfl...@cs.utah.edu wrote: My guess is that something is going wrong with the GC's write barrier. In src/racket/gc2/newgc.c around line 2677, if you change 1 to 0 in newgc-generations_available = 1; does the build make further progress? It doesn't seem to help; the build get stuck in the same place. I suppose this is the first time it tries to run racket3m since running gdb ./racket3m I get stuck in the same loop that James mentions. d _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] build hang on s390x
Hi, it's the debian guys again and their wacky architectures. The build on the s390x (64 bit version) seems to hang at the following place /usr/bin/make ../gracket3m make[6]: Entering directory `/home/bremner/racket-5.2.1+dfsg1/build/gracket/gc2' ../../racket/racket3m -cqu /home/bremner/racket-5.2.1+dfsg1/src/gracket/gc2/../../racket/gc2/xform.rkt --setup ../../racket/gc2 --cpp gcc -E -I/home/bremner/racket-5.2.1+dfsg1/src/gracket/gc2/../../racket/gc2 -I./../../racket/ -I/home/bremner/racket-5.2.1+dfsg1/src/gracket/gc2/../../racket/include/ -Dwx_xt -MMD --keep-lines -o xsrc/grmain.c +D INITIAL_COLLECTS_DIRECTORY=''`cd /home/bremner/racket-5.2.1+dfsg1/src/gracket/gc2/../../../collects; pwd`'' /home/bremner/racket-5.2.1+dfsg1/src/gracket/gc2/../grmain.c I killed it after about 30 minutes. The CPU is at 100%, but it doesn't seem to be using that much memory. Anything suggests for things to try to debug? d _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386
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 developers and my current understanding is that which signal (SIGBUS or SIGSEGV) is received is determined by the version of libc the binary is run under. So the most robust solution (from the narrow perspective of running on different/upgraded kFreeBSD systems) is indeed to catch both signals. One could of course do that for FreeBSD systems in general, but don't know what the tradeoffs are. David _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386
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) instead of SIGBUS. I suppose there is a good reason not to catch both signals? David 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. From 748f1dd0b6d387bc0577075e56afde3958c08f86 Mon Sep 17 00:00:00 2001 From: David Bremner brem...@debian.org Date: Tue, 10 May 2011 22:50:04 -0300 Subject: [PATCH] on GNU/kFreeBSD, catch both SIGBUS and SIGSEGV from mprotect --- src/racket/gc2/sighand.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/src/racket/gc2/sighand.c b/src/racket/gc2/sighand.c index 5b4b991..87e02aa 100644 --- a/src/racket/gc2/sighand.c +++ b/src/racket/gc2/sighand.c @@ -134,10 +134,13 @@ void fault_handler(int sn, siginfo_t *si, void *ctx) abort(); } # define NEED_SIGACTION -# if (defined(__FreeBSD__) (__FreeBSD_version 70)) || defined(__FreeBSD_kernel__) +# if (defined(__FreeBSD__) (__FreeBSD_version 70)) #define USE_SIGACTON_SIGNAL_KIND SIGBUS # else #define USE_SIGACTON_SIGNAL_KIND SIGSEGV +#ifdef __FreeBSD_kernel__ +# define ALSO_CATCH_SIGBUS +#endif # endif #endif @@ -230,6 +233,9 @@ static void initialize_signal_handler(GCTYPE *gc) act.sa_flags |= SA_ONSTACK; # endif sigaction(USE_SIGACTON_SIGNAL_KIND, act, oact); +# ifdef ALSO_CATCH_SIGBUS +sigaction(SIGBUS, act, oact); +# endif } # endif # ifdef NEED_SIGWIN @@ -263,6 +269,9 @@ static void remove_signal_handler(GCTYPE *gc) sigemptyset(act.sa_mask); act.sa_flags = SA_SIGINFO; sigaction(USE_SIGACTON_SIGNAL_KIND, act, oact); +# ifdef ALSO_CATCH_SIGBUS +sigaction(SIGBUS, act, oact); +# endif } # endif # ifdef NEED_SIGWIN -- 1.7.4.4 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386
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 current git master. I also got the same segmentation fault in an old version of the code (5.1.1+the previous kFreeBSD patches), where both versions compiled fine before this upgrade. I attach the stack trace. If it helps, this is with gcc 4.6.1. #0 scheme_gmp_tls_unload (s=0x8019c9930, data=0x0) at ./gmp/gmp.c:5813 #1 0x005db0fe in done_with_GC () at ./../src/thread.c:7591 #2 0x0060fb16 in garbage_collect (gc=value optimized out, force_full=value optimized out, switching_master=value optimized out, lmi=value optimized out) at ./newgc.c:4433 #3 0x00613aaa in allocate_slowpath (s=value optimized out) at ./newgc.c:1182 #4 allocate (s=value optimized out) at ./newgc.c:1220 #5 allocate (s=value optimized out) at ./newgc.c:1328 #6 GC_malloc_one_tagged (s=value optimized out) at ./newgc.c:1328 #7 0x00613dd4 in GC_malloc_pair (car=value optimized out, cdr=value optimized out) at ./newgc.c:1292 #8 0x004f0a45 in do_add_simple_require_renames (rn=0x8019ca720, required=0x8019ca690, orig_src=0x8019ca790, im=0x8019c8a08, pt=0x8019ca5b8, idx=0x8019c8580, marshal_phase_index=0x1, src_phase_index=0x1, can_override=1) at ./../src/module.c:2401 #9 0x004f0d70 in add_simple_require_renames (orig_src=0x8019ca790, rn_set=0x8019ca820, tables=0x8019ca7d0, im=0x8019c8a08, idx=0x8019c8580, import_shift=0x1, can_override=1, only_export_phase=0x0) at ./../src/module.c:2458 #10 0x00501bbc in do_module_begin (form=0x8019caa88, env=0x8019ca920, rec=0x7fffb630, drec=0) at ./../src/module.c:6185 #11 0x00627c46 in scheme_compile_expand_expr (form=0x8019caa88, env=0x8019ca920, rec=0x7fffb630, drec=value optimized out, app_position=0) at ./../src/compile.c:4159 #12 0x004fa9f3 in do_module (form=0x8019cae98, env=0x8019cab08, rec=0x7fffb630, drec=0) at ./../src/module.c:5665 #13 0x00627c46 in scheme_compile_expand_expr (form=0x8019cae98, env=0x8019cab08, rec=0x7fffb630, drec=value optimized out, app_position=0) at ./../src/compile.c:4159 #14 0x00443552 in compile_k () at ./../src/eval.c:3683 #15 0x00465faa in scheme_top_level_do_worker (k=0x442fc0 compile_k, eb=value optimized out, new_thread=0, dyn_state=0x0) at ./../src/fun.c:1123 #16 0x004492b4 in scheme_default_compile_handler (argc=value optimized out, argv=0x7fffbd10) at ./../src/eval.c:4273 #17 0x0044da19 in scheme_do_eval (obj=0x930610, num_rands=2, rands=0x7fffbd10, get_value=1) at ./../src/eval.c:2351 #18 0x0045e1de in apply_k () at ./../src/fun.c:1284 #19 0x00465faa in scheme_top_level_do_worker (k=0x45e150 apply_k, eb=value optimized out, new_thread=0, dyn_state=0x0) at ./../src/fun.c:1123 #20 0x00442d94 in call_compile_handler (form=value optimized out, immediate_eval=value optimized out) at ./../src/eval.c:3537 #21 0x00443a50 in compile_k () at ./../src/eval.c:3669 #22 0x00465faa in scheme_top_level_do_worker (k=0x442fc0 compile_k, eb=value optimized out, new_thread=0, dyn_state=0x0) at ./../src/fun.c:1123 #23 0x0044f413 in scheme_default_eval_handler (argc=value optimized out, argv=0x8019cebb0) at ./../src/eval.c:4260 #24 0x0044da19 in scheme_do_eval (obj=0x9305d0, num_rands=1, rands=0x8019cebb0, get_value=-1) at ./../src/eval.c:2351 #25 0x0044bf83 in scheme_do_eval (obj=0x8019cb040, num_rands=0, rands=0x0, get_value=-1) at ./../src/eval.c:2764 #26 0x0046d014 in scheme_finish_apply_for_prompt (prompt=0x0, _prompt_tag=value optimized out, proc=0x8019cb040, argc=0, argv=0x0) at ./../src/fun.c:5481 #27 0x0046d233 in scheme_apply_for_prompt (prompt=value optimized out, prompt_tag=value optimized out, proc=value optimized out, argc=value optimized out, argv=value optimized out) at ./../src/fun.c:5560 #28 0x00472711 in call_with_prompt (in_argc=value optimized out, in_argv=0x7fffc8f0) at ./../src/fun.c:5885 #29 0x0044da19 in scheme_do_eval (obj=0x91f9a0, num_rands=3, rands=0x7fffc8f0, get_value=-1) at ./../src/eval.c:2351 #30 0x00467002 in do_call_with_prompt (f=value optimized out, data=value optimized out, multi=1, top_level=0) at ./../src/fun.c:6077 #31 0x0046d3d5 in do_apply_with_prompt (rator=0x9305d0, num_rands=1, rands=0x7fffcaa8, multi=1, top_level=0) at ./../src/fun.c:1403 #32 0x0055272e in do_load_handler (data=value optimized out) at ./../src/portfun.c:4284 #33 0x0046fce1 in scheme_dynamic_wind (pre=0, act=0x552430 do_load_handler,
Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386
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 (squeeze), one should # define USE_SIGACTION_SIGNAL_KIND SIGBUS and as of recently in unstable, one should # define USE_SIGACTON_SIGNAL_KIND SIGSEGV I haven't figured out a nice preprocessor test yet (I don't know for certain such a test is possible; it might depend on the running kernel). I'm no autoconf expert, but perhaps a little test program could detect this. I suppose there is a good reason not to catch both signals? David _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386
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. Resident set size slowly climbs to 3G as it starts to compile racklog, and then it crashes with GC Warning: Out of Memory! Returning NIL! Segmentation fault David _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386
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 00:00:00 2001 From: David Bremner brem...@debian.org Date: Thu, 28 Apr 2011 20:00:37 -0300 Subject: [PATCH] Add cdefs.h and param.h before ieeefp.h. Change ieeefp.h to machine/ieeefp.h --- src/racket/src/number.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/racket/src/number.c b/src/racket/src/number.c index fea2871..1dc38e5 100644 --- a/src/racket/src/number.c +++ b/src/racket/src/number.c @@ -187,7 +187,9 @@ READ_ONLY Scheme_Object *scheme_single_inf_object, *scheme_single_minus_inf_obje #ifdef FREEBSD_CONTROL_387 -# include ieeefp.h +# include sys/cdefs.h +# include sys/param.h +# include machine/ieeefp.h #endif #ifdef LINUX_CONTROL_387 # include fpu_control.h -- 1.7.4.4 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386
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 bus error that you saw before? You are correct, I was/am using cgc. I needed configure --enabled places to avoid ./../src/thread.c:7679:20: error: ‘scheme_code_page_total’ undeclared (first use in this function) But then I had a bus error, as before. David _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] memory consumption (bug?) on Debian/kFreeBSD-i386
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 traceback from racket3m -cqu ./../../racket/gc2/xform.rkt --setup ../../racket/gc2 --cpp gcc -E -I./../../racket/gc2 -I./../../racket/ -I./../../racket/include/ -pthread -Dwx_xt -MMD --keep-lines -o xsrc/grmain.c +D INITIAL_COLLECTS_DIRECTORY=''`cd ./../../../collects; pwd`'' ./../grmain.c this is current git, with my ieeefp include patch #0 scheme_gmp_tls_unload (s=0x45958e24, data=0x0) at ./gmp/gmp.c:5813 #1 0x081fcf12 in done_with_GC () at ./../src/thread.c:7591 #2 0x08227e00 in garbage_collect (gc=0x8291d10, force_full=value optimized out, switching_master=value optimized out, lmi=value optimized out) at ./newgc.c:4395 #3 0x0822acf9 in allocate_slowpath (s=12) at ./newgc.c:1178 #4 allocate (s=12) at ./newgc.c:1216 #5 GC_malloc_one_tagged (s=12) at ./newgc.c:1324 #6 0x0820163e in do_extend_config (c=0x45959498, key=0x53, val=0x8278fa4) at ./../src/thread.c:6179 #7 0x081755fa in default_load (argc=2, argv=0x45948edc) at ./../src/portfun.c:4363 #8 0x4618d4f4 in ?? () #9 0x0809eac8 in scheme_do_eval (obj=0x0, num_rands=1167363804, rands=0x0, get_value=-1) at ./../src/eval.c:9550 #10 0x080c3858 in scheme_finish_apply_for_prompt (prompt=0x0, _prompt_tag=0x45704378, proc=0x45959560, argc=0, argv=0x0) at ./../src/fun.c:6672 #11 0x080c39af in scheme_apply_for_prompt (prompt=0x4577c788, prompt_tag=0x45704378, proc=0x45959560, argc=0, argv=0x0) at ./../src/fun.c:6751 #12 0x080c733c in call_with_prompt (in_argc=2, in_argv=0x45948f50) at ./../src/fun.c:7076 #13 0x4618d4f4 in ?? () #14 0x46194860 in ?? () #15 0x0809eac8 in scheme_do_eval (obj=0x0, num_rands=1167363920, rands=0xbfbfcff4, get_value=1) at ./../src/eval.c:9550 #16 0x080b2876 in apply_k () at ./../src/fun.c:2475 #17 0x080bcad8 in scheme_top_level_do_worker (k=0x80b27f0 apply_k, eb=1, new_thread=0, dyn_state=0x0) at ./../src/fun.c:2314 #18 0x080bccb8 in scheme_top_level_do (k=0x80b27f0 apply_k, eb=1) at ./../src/fun.c:2227 #19 0x0811f886 in _module_resolve (modidx=value optimized out, stx=0x0, env=0x0, load_it=1) at ./../src/module.c:3271 #20 0x08128f7c in compute_require_names (menv=0x45959658, phase=0x1, load_env=0x45958410, syntax_idx=0x459596e0) at ./../src/module.c:4077 #21 0x0813120e in chain_start_module (a=0xbfbfd248) at ./../src/module.c:4142 #22 scheme_module_start_finish (a=0xbfbfd248) at ./../src/module.c:4259 #23 0x4618f2c5 in ?? () #24 0x08114320 in scheme_module_start_start (a=0xbfbfd248, name=0x45959730) at ./../src/jitstack.c:494 #25 0x0812b28c in chain_start_module_w_push (m=0x45959750, env=0x45958410, restart=value optimized out, syntax_idx=0x459596e0, eval_exp=0, eval_run=1, base_phase=0, cycle_list=0x45959740) at ./../src/module.c:4251 #26 start_module (m=0x45959750, env=0x45958410, restart=value optimized out, syntax_idx=0x459596e0, eval_exp=0, eval_run=1, base_phase=0, cycle_list=0x45959740) at ./../src/module.c:4525 #27 0x0813126d in chain_start_module (a=0xbfbfd43c) at ./../src/module.c:4149 #28 scheme_module_start_finish (a=0xbfbfd43c) at ./../src/module.c:4259 #29 0x4618f2c5 in ?? () #30 0x08114320 in scheme_module_start_start (a=0xbfbfd43c, name=0x459598a0) at ./../src/jitstack.c:494 #31 0x0812b28c in chain_start_module_w_push (m=0x459598b0, env=0x45958410, restart=value optimized out, syntax_idx=0x45959870, eval_exp=0, eval_run=1, base_phase=0, cycle_list=0x827985c) at ./../src/module.c:4251 #32 start_module (m=0x459598b0, env=0x45958410, restart=value optimized out, syntax_idx=0x45959870, eval_exp=0, eval_run=1, base_phase=0, cycle_list=0x827985c) at ./../src/module.c:4525 #33 0x08135a08 in _dynamic_require (argc=value optimized out, argv=value optimized out, env=0x45958410, get_bucket=0, phase=0, indirect_ok=value optimized out, fail_with_error=1, position=value optimized out, mod_phase=0) at ./../src/module.c:1135 #34 0x081363ef in scheme_dynamic_require (argc=2, argv=0x45948fac) at ./../src/module.c:1200 #35 0x0809e7f8 in scheme_do_eval (obj=0x82affc8, num_rands=2, rands=0x45948fac, get_value=-1) at ./../src/eval.c:9291 #36 0x081213e4 in body_one_expr (prefix_plus_expr=0x45959968, argc=0, argv=0x0) at ./../src/module.c:4671 #37 0x0809d8a0 in scheme_do_eval (obj=0x45959978, num_rands=0, rands=0x0, get_value=-1) at ./../src/eval.c:9704 #38 0x080c3858 in scheme_finish_apply_for_prompt (prompt=0x0, _prompt_tag=0x45685808, proc=0x45959978, argc=0, argv=0x0) at ./../src/fun.c:6672 #39 0x080c39af in scheme_apply_for_prompt (prompt=0x457129e8, prompt_tag=0x45685808, proc=0x45959978, argc=0, argv=0x0) at ./../src/fun.c:6751 #40 0x080c733c in call_with_prompt (in_argc=3, in_argv=0xbfbfdb08) at ./../src/fun.c:7076 #41 0x0809e7f8 in scheme_do_eval (obj=0x82adb08,
Re: [racket-dev] racket 5.1 build failure on debian/kfreebsd
On Thu, 21 Apr 2011 23:06:23 -0300, David Bremner brem...@debian.org wrote: On Thu, 21 Apr 2011 19:32:18 -0600, Matthew Flatt mfl...@cs.utah.edu wrote: Besides some code-organization problems, my guess is that sconfig.h doesn't figure out that you're on a FreeBSD variant. Do you know what pre-processor definition should be detected, if it's not __FreeBSD__? At a guess, I'd say __FreeBSD_kernel__ The attached patch does indeed allow compilation to finish. There is a problem linking to pthreads , | gcc -o racketcgc main.o libracket.a libmzgc.a -ldl -lm | libracket.a(port.o): In function `start_green_thread_timer': | /home/bremner/racket/src/racket/src/port.c:8937: undefined reference to `pthread_create' | libracket.a(port.o): In function `kill_green_thread_timer': | /home/bremner/racket/src/racket/src/port.c:8956: undefined reference to `pthread_join' ` I can work around this by configure --enable-pthread, but I suspect the right fix is to add a stanza for GNU/kFreeBSD to src/configure. I'm a little baffled how this file is maintained, though. Is there a corresponding configure.ac somewhere? All the best David P.S. with --enable pthread racket3m bus errors out, but one problem at a time. commit 0e6d5413e1c20042475b63fb35b0531bce652fa8 Author: David Bremner brem...@debian.org Date: Fri Apr 22 12:28:12 2011 -0300 Detect Debian/kbsd kernel This is controlled by preprocessor macro __FreeBSD_kernel__ diff --git a/src/racket/sconfig.h b/src/racket/sconfig.h index f5408f3..1594078 100644 --- a/src/racket/sconfig.h +++ b/src/racket/sconfig.h @@ -320,7 +320,7 @@ /** x86/FreeBSD with gcc / -#if defined(__FreeBSD__) +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) # if defined(__i386__) # define SCHEME_PLATFORM_LIBRARY_SUBPATH i386-freebsd _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] racket 5.1 build failure on debian/kfreebsd
Hi All; I'm trying to build 5.1 on debian/kfreebsd, and I'm having problems with src/racket/src/port.c The main problems stem from MZ_FLUSH_* not being defined. This in turn seems to be because MZ_FDS is not defined at line 259. At that point I got stuck, I couldn't see what controlled this definition. The full build log is https://buildd.debian.org/status/fetch.php?pkg=racketarch=kfreebsd-amd64ver=5.1%2Bdfsg1-1stamp=1303128559 The relevant seeming part is as follows: gcc -I./.. -I/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/../include -g -Wall -c /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c -o port.o /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c: In function 'scheme_file_buffer': /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4649:12: error: 'MZ_FLUSH_NEVER' undeclared (first use in this function) /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4649:12: note: each undeclared identifier is reported only once for each function it appears in /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4651:12: error: 'MZ_FLUSH_BY_LINE' undeclared (first use in this function) /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4653:12: error: 'MZ_FLUSH_ALWAYS' undeclared (first use in this function) /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c: In function 'file_buffer_mode': /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4902:15: error: 'MZ_FLUSH_NEVER' undeclared (first use in this function) /build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4904:20: error: 'MZ_FLUSH_BY_LINE' undeclared (first use in this function) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
