headers
Jörg F. Wittenberger | 1 Oct 2011 13:52

Re: EINTR with self-pipe signal trampoline

Thanks Mario.

I just checked.  The Scheduler code I'm using does not have this bug.

On Sep 29 2011, Mario Domenech Goulart wrote:

>Hi Jörg,
>
> On 29 Sep 2011 13:11:49 +0200 Jörg F. Wittenberger 
> <Joerg.Wittenberger <at> softeyes.net> wrote:
>
>> Recently (maybe 4.7.3 or .4) I'm seeing missbehavior from formerly
>> well working code.  I can't say that's chickens fault but neither I
>> can say it's not.
>
>4.7.3 has a bug that may affect your applications:
>https://bugs.call-cc.org/ticket/668
Permalink | Reply | 0 comments |
headers
Alan Post | 2 Oct 2011 00:01
Favicon
Gravatar

sandbox egg: C_emit_trace_info

The sandbox egg makes a call to the runtime.c procedure:

  C_emit_trace_info

In commit 2d5244dd01d4e91ed6f73bb566e92f04a2ab6361 of core,
this procedure was deprecated in favor of:

  C_emit_eval_trace_info
	C_emit_syntax_trace_info

Below is the patch bringing the sandbox egg up-to-date with
this API change.  I noted that the C_emit_trace_info was
mapped to C_emit_eval_trace_info, so I changed all of the
calls in the sandbox egg to C_emit_eval_trace_info.

Would someone that better understands this egg verify that
none of the calls should instead be to C_emit_syntax_trace_info?

Will someone with access rights apply this patch to the trunk
branch of the sandbox egg?

-Alan

<++> sandbox-trace-info.patch
Index: sandbox.scm
===================================================================
--- sandbox.scm	(revision 25270)
+++ sandbox.scm	(working copy)
 <at>  <at>  -455,8 +455,8  <at>  <at> 
     (and (list? lst)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jim Ursetto | 2 Oct 2011 02:18
Picon

Re: sandbox egg: C_emit_trace_info

Patch looks good to me but should be ACKed by the egg author (Felix)

On Oct 1, 2011, at 5:01 PM, Alan Post wrote:

> The sandbox egg makes a call to the runtime.c procedure:
> 
>  C_emit_trace_info
> 
> In commit 2d5244dd01d4e91ed6f73bb566e92f04a2ab6361 of core,
> this procedure was deprecated in favor of:
> 
>  C_emit_eval_trace_info
> 	C_emit_syntax_trace_info
> 
> Below is the patch bringing the sandbox egg up-to-date with
> this API change.  I noted that the C_emit_trace_info was
> mapped to C_emit_eval_trace_info, so I changed all of the
> calls in the sandbox egg to C_emit_eval_trace_info.
> 
> Would someone that better understands this egg verify that
> none of the calls should instead be to C_emit_syntax_trace_info?
> 
> Will someone with access rights apply this patch to the trunk
> branch of the sandbox egg?
> 
> -Alan
> 
> <++> sandbox-trace-info.patch
> Index: sandbox.scm
> ===================================================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Welland | 2 Oct 2011 06:23
Picon

Moving an app from chicken-3.4, replacement for "cookie" egg?

Also, docs seem to be missing from the chicken 3 eggs pages and I could not download the cookie egg with "chicken-setup -f cookie".

Thanks,

Matt
-=-

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Permalink | Reply | 1 comment |
headers
Matt Welland | 2 Oct 2011 06:55
Picon

Re: Moving an app from chicken-3.4, replacement for "cookie" egg?

Nevermind. chicken-setup -f puts the egg in /tmp, not in the local dir. I have the source and it seems to compile fine in 4.7.0

On Sat, Oct 1, 2011 at 9:23 PM, Matt Welland <estiforta <at> gmail.com> wrote:
Also, docs seem to be missing from the chicken 3 eggs pages and I could not download the cookie egg with "chicken-setup -f cookie".

Thanks,

Matt
-=-

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Permalink | Reply | 0 comments |
headers
Jörg F. Wittenberger | 2 Oct 2011 12:36

Question again on heap mutation from signal handlers.

Kon (or maybe Felix)

On Sep 1 2011, Kon Lovett wrote:

> Probably of no use to you but … When I added all the extra unix
> (Chicken v2 I think) signals stuff I figured (ha) that a Scheme
> signal handler could only perform operations that accessed existing
> structures, no heap mutation. I used handlers that basically only
> set flags.

Is there a way to verify that signal handlers can not allocate
on the heap?

As far as I understand runtime.c this should be true.
But it's fairly complicated to reason here.
It would be very, very helpful to be sure about that one.

Since my eat-all-mem issue was gone all too suddenly with yet
another git update (the one with the larger update to types.db),
I'm afraid it might be a false positive.

And there are the downsides of the approach I've take to
get around this (possibly fake) issue.  Not only makes
it the interrupt latency a little larger (since what it tries
to do is to wait for gc to finish); I've used to have a signal
handler, which would write a thread listing into the log file.
This has been extraordinary reliable even when I managed to
mess up the thread system.  No longer avail.

Now I tried to re-enable the old handler invocation to confirm
that the old issue would come back.
So far it did not - which is confusing.

Thanks a lot

/Jörg

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Permalink | Reply | 18 comments |
headers
Jörg F. Wittenberger | 2 Oct 2011 13:37

Re: replace signal with sigaction

Hi,

in this message
http://lists.nongnu.org/archive/html/chicken-users/2011-09/msg00292.html
I sent out a strange bug.  Sorry for that.

The child-registering fork() should be:

(define (save-fork)
 (let* ((ie (##sys#fudge 14))
        (pid (begin (chicken-disable-interrupts!)
                    ((foreign-lambda int "fork")))))
   (case pid
     ((0) (set! processes-running (make-hash-table fx= number-hash)))
     ((-1) (if ie (chicken-simple-enable-interrupts!)))
     (else (hash-table-set! processes-running pid (list pid))
            (if ie (chicken-simple-enable-interrupts!))))
   pid))

The way I miss-cut&pasted it together would switch off interrupt
handling completely.  (Which I did not notice, since those changes
in signal handling would work even with interrupt disabled.

Actually this make me wonder if it would be possible to actually
remove it from the source.  Wait - I'm not proposing that hereby.

/Jörg
Permalink | Reply | 0 comments |
headers
Jim Ursetto | 2 Oct 2011 17:33
Picon

Re: sandbox egg: C_emit_trace_info

Felix applied in sandbox 1.8, thanks!

On Oct 1, 2011, at 5:01 PM, Alan Post wrote:

> The sandbox egg makes a call to the runtime.c procedure:
> 
>  C_emit_trace_info
> 
> In commit 2d5244dd01d4e91ed6f73bb566e92f04a2ab6361 of core,
> this procedure was deprecated in favor of:
> 
>  C_emit_eval_trace_info
> 	C_emit_syntax_trace_info
> 
> Below is the patch bringing the sandbox egg up-to-date with
> this API change.  I noted that the C_emit_trace_info was
> mapped to C_emit_eval_trace_info, so I changed all of the
> calls in the sandbox egg to C_emit_eval_trace_info.
> 
> Would someone that better understands this egg verify that
> none of the calls should instead be to C_emit_syntax_trace_info?
> 
> Will someone with access rights apply this patch to the trunk
> branch of the sandbox egg?
> 
> -Alan
> 
> <++> sandbox-trace-info.patch
> Index: sandbox.scm
> ===================================================================
> --- sandbox.scm	(revision 25270)
> +++ sandbox.scm	(working copy)
>  <at>  <at>  -455,8 +455,8  <at>  <at> 
>     (and (list? lst)
> 	 (length lst) ) )
> 
> -  (define (emit-trace-info info)
> -    (##core#inline "C_emit_trace_info" info #f ##sys#current-thread) )
> +  (define (emit-eval-trace-info info)
> +    (##core#inline "C_emit_eval_trace_info" info #f ##sys#current-thread) )
> 
>   (define (compile-call x e)
>     (let* ([fn (compile (car x) e #f)]
>  <at>  <at>  -466,25 +466,25  <at>  <at> 
>       (case argc
> 	[(#f) (##sys#syntax-error-hook "syntax error - malformed expression" x)]
> 	[(0) (lambda (v)
> -	       (emit-trace-info info)
> +	       (emit-eval-trace-info info)
> 	       (check-point fuel/lambda)
> 	       ((##core#app fn v)) ) ]
> 	[(1) (let ([a1 (compile (car args) e #f)])
> 	       (lambda (v)
> -		 (emit-trace-info info)
> +		 (emit-eval-trace-info info)
> 		 (check-point fuel/lambda)
> 		 ((##core#app fn v) (##core#app a1 v))) ) ]
> 	[(2) (let* ([a1 (compile (car args) e #f)]
> 		    [a2 (compile (list-ref args 1) e #f)] )
> 	       (lambda (v)
> -		 (emit-trace-info info)
> +		 (emit-eval-trace-info info)
> 		 (check-point fuel/lambda)
> 		 ((##core#app fn v) (##core#app a1 v) (##core#app a2 v))) ) ]
> 	[(3) (let* ([a1 (compile (car args) e #f)]
> 		    [a2 (compile (list-ref args 1) e #f)]
> 		    [a3 (compile (list-ref args 2) e #f)] )
> 	       (lambda (v)
> -		 (emit-trace-info info)
> +		 (emit-eval-trace-info info)
> 		 (check-point fuel/lambda)
> 		 ((##core#app fn v) (##core#app a1 v) (##core#app a2 v) (##core#app a3 v))) ) ]
> 	[(4) (let* ([a1 (compile (car args) e #f)]
>  <at>  <at>  -492,12 +492,12  <at>  <at> 
> 		    [a3 (compile (list-ref args 2) e #f)]
> 		    [a4 (compile (list-ref args 3) e #f)] )
> 	       (lambda (v)
> -		 (emit-trace-info info)
> +		 (emit-eval-trace-info info)
> 		 (check-point fuel/lambda)
> 		 ((##core#app fn v) (##core#app a1 v) (##core#app a2 v) (##core#app a3 v) (##core#app a4 v))) ) ]
> 	[else (let ([as (map (lambda (a) (compile a e #f)) args)])
> 		(lambda (v)
> -		  (emit-trace-info info)
> +		  (emit-eval-trace-info info)
> 		  (check-point fuel/lambda)
> 		  (apply (##core#app fn v) (map (lambda (a) (##core#app a v)) as))) ) ] ) ) )
> 
> <-->
> -- 
> .i ma'a lo bradi cu penmi gi'e du
> 
> _______________________________________________
> Chicken-users mailing list
> Chicken-users <at> nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
Permalink | Reply | 0 comments |
headers
Jörg F. Wittenberger | 2 Oct 2011 19:02

Re: Question again on heap mutation from signal handlers.

On Oct 2 2011, Jörg F. Wittenberger wrote:

>Kon (or maybe Felix)
>
>On Sep 1 2011, Kon Lovett wrote:
>
>> Probably of no use to you but … When I added all the extra unix
>> (Chicken v2 I think) signals stuff I figured (ha) that a Scheme
>> signal handler could only perform operations that accessed existing
>> structures, no heap mutation. I used handlers that basically only
>> set flags.
>
>Is there a way to verify that signal handlers can not allocate
>on the heap?
>
>As far as I understand runtime.c this should be true.
>But it's fairly complicated to reason here.
>It would be very, very helpful to be sure about that one.
>
>Since my eat-all-mem issue was gone all too suddenly ...
>Now I tried to re-enable the old handler invocation to confirm
>that the old issue would come back.
>So far it did not - which is confusing.

To summarize: no reason for confusion: "so far" meant: about 20
min. trying to force it.  Sometimes it's easier to just wait :-/

At least it reduces confusion.  A bit, that is.

If I could knew for sure that signal handlers may not touch the heap,
I would know that the approach to accept the higher latency in exchange
for the more natural coding of signal handlers would be worth the
time.

Alan: DON'T enable the normal signal handling.  It might work some
seemingly infinite time.  But eventually goes into EAM mode.
No theory why; just observation so far.

/Jörg

PS: If it eventually turns out to be true that the signal handler
has been the issue I had.  Plus it would turn out to be verifiable
that always running with interrupts disabled does not eventually
harm normal behaviour.  ...  THEN I'd call that a productive time!
We could leave quite some code with the garbage collector.

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Permalink | Reply | 0 comments |
headers
Christian Kellermann | 2 Oct 2011 22:40
Gravatar

Re: FrOSCon 2011 Talks

* John Gabriele <jmg3000 <at> gmail.com> [110823 07:27]:
> Regarding the chickenista guide pdf, some minor issues I noticed:

[snip]

> As far as more substantial feedback on the content itself, I would've
> liked longer descriptions for most of the bullet points in section
> 4.4, as well as more explanation about what exactly a "unit" is and
> what the differences are between units, extensions, eggs, and modules.
> 
> Thanks again for the docs!

I finally managed to import the guide to the wiki at
https://wiki.call-cc.org/chickenista-guide

This page is linked from the tutorials section so maybe newcomers
will find it more easily.

Thanks John and everyone who helped here!

Kind regards,

Christian

--

-- 
Who can (make) the muddy water (clear)? Let it be still, and it will
gradually become clear. Who can secure the condition of rest? Let
movement go on, and the condition of rest will gradually arise.
 -- Lao Tse.
Permalink | Reply | 0 comments |

Gmane