Re: [racket-dev] segfault with #%variable-reference

2015-01-13 Thread Matthew Flatt
It wasn't that I forgot to implement pieces, after all. The problem was a bug in the byte compiler's handling of `#%variable-reference` when inlining. I've pushed a repair. At Mon, 12 Jan 2015 19:24:56 -0700, Matthew Flatt wrote: > It's supposed to be safe; the behavior in this example is definite

Re: [racket-dev] segfault with #%variable-reference

2015-01-12 Thread Matthew Flatt
It's supposed to be safe; the behavior in this example is definitely a bug. The `#%variable-reference` form used to work only on top-level and module variables. It seems that I forgot to fill in some pieces when I made `#%variable-reference` work on local bindings (several years ago, mainly for us

[racket-dev] segfault with #%variable-reference

2015-01-12 Thread Jon Zeppieri
I'm not sure if #%variable-reference is supposed to be unsafe or not (it's not mentioned in the documentation), but it looks like an attempt to get the location of an identifier that is neither top-level nor module-level results in a hard crash: === #lang racket/base (define (go) (define foo 3)

Re: [racket-dev] segfault during make

2015-01-08 Thread Spencer Florence
aha! That fixed it. Thanks. On Thu Jan 08 2015 at 6:18:12 AM Matthew Flatt wrote: > Do you have the latest "images-doc" and/or "gui-lib" packages? > > Recently, there was a problem with the "images" documentation where it > tried to use `racket/gui` at document-build time. At the same time, > th

Re: [racket-dev] segfault during make

2015-01-08 Thread Matthew Flatt
Do you have the latest "images-doc" and/or "gui-lib" packages? Recently, there was a problem with the "images" documentation where it tried to use `racket/gui` at document-build time. At the same time, there was also a problem in `racket/gui` that could cause a crash (mainly on Mac OS X) after `ra

[racket-dev] segfault during make

2015-01-08 Thread Spencer Florence
Hey all, When I try to run `make` on the current head the build segfaults while making the documentation. The last few lines of the output are: raco setup: 2 rendering: /pfds/pfds/scribblings/functional-data-structures.scrbl raco setup: 1 rendering: /future-visualizer/future-visualizer/scribbling

Re: [racket-dev] Segfault

2013-07-25 Thread Matthew Flatt
Thanks for the report! This information looks consistent with a bug that I recently fixed in the development version, and I've recommended a back-ported repair to be included in v5.3.6. At Thu, 25 Jul 2013 18:31:13 +0700 (NOVT), "oev" wrote: > It seems like the problem is kind of described at > ht

[racket-dev] Segfault

2013-07-25 Thread oev
It seems like the problem is kind of described at http://www.mail-archive.com/users@racket-lang.org/msg18395.html I was working long time and have got DrRacket "not responding" after 'New Tab' click. I use pre-release 32-bit version 5.3.5.900 on Windows 7 Professional SP1 64bit. Run DrRacket with

Re: [racket-dev] Segfault on HEAD?

2013-02-13 Thread Jon Rafkind
The latest commit d408ba4 fixes this for me. On 02/13/2013 10:14 AM, Asumu Takikawa wrote: > On 2013-02-13 10:36:09 -0600, Robby Findler wrote: >>I don't know what would help, but one thing that usually does is a stack >>trace. You can probably get it from a coredump file or by something l

Re: [racket-dev] Segfault on HEAD?

2013-02-13 Thread Asumu Takikawa
On 2013-02-13 10:36:09 -0600, Robby Findler wrote: >I don't know what would help, but one thing that usually does is a stack >trace. You can probably get it from a coredump file or by something like >this: >$ gdb `which racket` >   [... stuff ...] >(gdb) set args -l setup >

Re: [racket-dev] Segfault on HEAD?

2013-02-13 Thread Matthew Flatt
I'm trying a clean build now, and maybe the problem will be obvious. At Wed, 13 Feb 2013 10:36:09 -0600, Robby Findler wrote: > I don't know what would help, but one thing that usually does is a stack > trace. You can probably get it from a coredump file or by something like > this: > > $ gdb `wh

Re: [racket-dev] Segfault on HEAD?

2013-02-13 Thread Robby Findler
I don't know what would help, but one thing that usually does is a stack trace. You can probably get it from a coredump file or by something like this: $ gdb `which racket` [... stuff ...] (gdb) set args -l setup (gdb) run On Wed, Feb 13, 2013 at 10:24 AM, Asumu Takikawa wrote: > Hi all,

Re: [racket-dev] Segfault on HEAD?

2013-02-13 Thread Asumu Takikawa
On 2013-02-13 11:24:35 -0500, Asumu Takikawa wrote: > I get a reproducible segfault when I built Racket from git HEAD. This is > what I see: A git bisect seems to pinpoint the segfault to commit 4a0adb6a74630f4afc7fd85275ffca76836037b4. Cheers, Asumu _ Racket Developers

[racket-dev] Segfault on HEAD?

2013-02-13 Thread Asumu Takikawa
Hi all, I get a reproducible segfault when I built Racket from git HEAD. This is what I see: raco setup: 7 making: redex/examples (Reduction Semantics examples) reverse: contract violation expected: list? given: 4193052015854236082 SIGSEGV SI_KERNEL SI_CODE 128 fault on addr (nil) sent by ke