Thanks! Is there a quick explanation for why it was only crashing intermittently?
On Thu, Jul 23, 2015 at 10:50 AM, Matthew Flatt <[email protected]> wrote: > Thanks! Repair pushed. > > At Wed, 22 Jul 2015 15:35:37 -0400, Stephen Chang wrote: >> Here is another seg faulting example. >> >> example3a.rkt: >> >> #lang racket >> (require (for-syntax syntax/parse)) >> (provide test) >> (define-syntax test >> (syntax-parser >> [_ >> #:with lam+ >> (local-expand >> #'(λ (z) (let-syntax ([z (make-rename-transformer #'z)]) z)) >> 'expression null) >> #'(define-syntax x #'lam+)])) >> (test) >> >> example3b.rkt: >> >> #lang racket >> (require "example3a.rkt") >> >> To reproduce: >> 1) Open example3b.rkt in drracket and run. It may or may not crash >> with a seg fault. >> 2) Delete compiled directory and run again. >> >> Observations: >> - A crash typically occurs after repeating the steps 2-3 times but >> sometimes I have to run-and-compile 5 or more times. >> - The provide appears to be necessary to cause the crash, even though >> it's unused in the second file. >> - I'm not sure which parts of the macro are actually needed to create >> the crash but the local-expand and define-syntax seem to be involved. >> >> >> On Tue, Jul 21, 2015 at 3:39 PM, Stephen Chang <[email protected]> wrote: >> >> Repair pushed. The problem was related to the bytecode format, so I >> >> had to bump the version number. >> > >> > Ah ok. This makes sense because I occasionally could not reproduce the >> > crash unless I forced a recompile. Sorry, I should have mentioned this >> > initially. Thanks. >> > >> >> >> >> Thanks! >> >> >> >> At Tue, 21 Jul 2015 13:27:14 -0400, Stephen Chang wrote: >> >>> The previous example now works. Thanks. >> >>> >> >>> But here is a variation that still seg faults: >> >>> >> >>> file1.rkt: >> >>> >> >>> #lang racket >> >>> (require (for-syntax syntax/parse)) >> >>> (provide (rename-out [my-define define])) >> >>> (define-syntax my-define >> >>> (syntax-parser >> >>> [(_ x:id e) >> >>> ;; undef is unbound identifier >> >>> #:with y (local-expand #'undef 'expression null) >> >>> #'(void)])) >> >>> >> >>> ; (my-define X 1) produces: "undef: unbound identifier in module in: >> >>> undef" >> >>> >> >>> file2.rkt >> >>> >> >>> #lang racket >> >>> (require "file1.rkt") >> >>> (define X 1) >> >>> >> >>> Running file2.rkt in drracket with the new expander crashes drracket >> >>> with: >> >>> >> >>> SIGSEGV MAPERR si_code 1 fault on addr 0x20 >> >>> Aborted >> >>> >> >>> On Mon, Jul 20, 2015 at 3:49 PM, Matthew Flatt <[email protected]> >> >>> wrote: >> >>> > I've just pushed a repair for this bug. Thanks for the report! >> >>> > >> >>> > >> >>> > >> >>> >> On Jul 20, 2015, at 12:47 PM, Stephen Chang <[email protected]> >> >>> >> wrote: >> >>> >> >> >>> >> The following code produces a seg fault with the new expander (today's >> >>> >> build) in the scenario described below: >> >>> >> >> >>> >> file1.rkt: >> >>> >> >> >>> >> #lang racket >> >>> >> (require (for-syntax syntax/parse)) >> >>> >> >> >>> >> (define-syntax (define-constructor stx) >> >>> >> (syntax-parse stx >> >>> >> [(_ X:id) >> >>> >> #'(define-syntax X >> >>> >> (syntax-parser >> >>> >> [(_ x (... ...)) #'(void x (... ...))]))])) >> >>> >> >> >>> >> (define-constructor C) >> >>> >> >> >>> >> (define-syntax define-alias >> >>> >> (syntax-parser >> >>> >> [(_ alias:id e) >> >>> >> #:with e+ (local-expand #'e 'expression null) >> >>> >> #'(define-syntax alias >> >>> >> (syntax-parser [x:id #'e+]))])) >> >>> >> >> >>> >> (define-alias D (C 1)) >> >>> >> >> >>> >> file2.rkt: >> >>> >> (require "file1.rkt") >> >>> >> >> >>> >> A few notes: >> >>> >> - running file2.rkt in DrRacket with the new expander crashes drracket >> >>> >> with the error: >> >>> >> >> >>> >> SIGSEGV MAPERR si_code 1 fault on addr (nil) >> >>> >> Aborted >> >>> >> >> >>> >> - running file2.rkt with racket (new expander) produces no error >> >>> >> - running file2.rkt produced no error with the old expander >> >>> >> - running file1.rkt with either racket or drracket, new expander or >> >>> >> old expander, produces no error >> >>> >> >> >>> >> I'm not completely caught up with the new expander threads so >> >>> >> apologies in advance if someone has already raised this issue. >> >>> >> >> >>> >> -- >> >>> >> You received this message because you are subscribed to the Google >> Groups >> >>> "Racket Developers" group. >> >>> >> To unsubscribe from this group and stop receiving emails from it, send >> an >> >>> email to [email protected]. >> >>> >> To post to this group, send email to [email protected]. >> >>> >> To view this discussion on the web visit >> >>> >> https://groups.google.com/d/msgid/racket-dev/CAFfiA1LDBwHox-1iP9UdDQOKSLMU-TbhU >> >>> Vtbsd-TLrNNO0eB_g%40mail.gmail.com. >> >>> >> For more options, visit https://groups.google.com/d/optout. >> >>> >> > > -- > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/20150723145046.4AD8D6501DD%40mail-svr1.cs.utah.edu. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAFfiA1%2BR5qgeLU1ibArgoJLe8GQysm6MgY1-%3DtEVA9Mrfb2prQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
