atom feed29 messages in org.freebsd.freebsd-emulationRe: [PATCH] pipe2 for Linuxulator
FromSent OnAttachments
Jung-uk KimApr 10, 2012 3:56 pm.diff
Jung-uk KimApr 10, 2012 4:39 pm 
Jung-uk KimApr 10, 2012 5:27 pm 
Alexander BestApr 13, 2012 1:31 pm 
Alexander LeidingerApr 14, 2012 6:50 am 
Alexander LeidingerApr 14, 2012 6:54 am 
Alexander BestApr 14, 2012 1:32 pm 
Alexander LeidingerApr 14, 2012 1:47 pm 
Alexander LeidingerApr 14, 2012 3:02 pm 
Alexander BestApr 14, 2012 5:01 pm 
Alexander BestApr 15, 2012 3:11 am 
Alexander BestApr 15, 2012 4:22 am 
Alexander LeidingerApr 15, 2012 4:44 am 
Alexander BestApr 15, 2012 4:50 am.Other
Alexander BestApr 15, 2012 6:02 am 
Alexander LeidingerApr 15, 2012 7:30 am 
Alexander BestApr 15, 2012 7:41 am 
Alexander BestApr 15, 2012 11:15 am 
Alexander BestApr 15, 2012 11:29 am 
Alexander BestApr 15, 2012 11:46 am 
Alexander LeidingerApr 15, 2012 11:52 am 
Alexander LeidingerApr 15, 2012 12:00 pm 
Alexander BestApr 15, 2012 12:03 pm 
Alexander LeidingerApr 15, 2012 12:05 pm 
Alexander LeidingerApr 15, 2012 12:16 pm 
Alexander BestApr 15, 2012 1:56 pm 
Alexander BestApr 15, 2012 2:03 pm 
Jung-uk KimApr 16, 2012 2:32 pm 
Alexander BestApr 21, 2012 3:16 pm 
Subject:Re: [PATCH] pipe2 for Linuxulator
From:Alexander Best (arun@freebsd.org)
Date:Apr 15, 2012 1:56:56 pm
List:org.freebsd.freebsd-emulation

On Sun Apr 15 12, Alexander Leidinger wrote:

On Sun, 15 Apr 2012 19:04:08 +0000 Alexander Best <arun@freebsd.org> wrote:

On Sun Apr 15 12, Alexander Leidinger wrote:

On Sun, 15 Apr 2012 18:16:13 +0000 Alexander Best <arun@freebsd.org> wrote:

also...even after installing a fresh kernel and world with dtrace enabled, the "check_error.d" and "trace_futexes.d" fail and sometimes even render the flash instance unusable.

I assume with unusable you mean not fast enough. Well... buy a faster CPU. No, just kidding. Depending on what a D script does and how many probes are enabled in the D script, it is not unexpected that the system slows down. As told above, the scripts show what is possible. For real debugging you may want to use stripped down versions.

no actually. what i meant by "unusable" is that the d-scripts themself crash the flash instances.

Uhm... this is unexpected. DTrace disables destructive actions by default, and I do not activate them. Maybe some timing-sensitive code in the flash-player which does not handle the case that some parts can take longer than expected? I assume there is not bug in DTrace itself. There could be a bug in my patch, but I would assume it is not a heisen-bug as described here (the probes are handled by DTrace-macros, just the variables which are provided to D scripts are different from other probes).

this sounds reasonable. after exiting the dtrace script the crashed flash instance partially returns to normal behaviour. so indeed it seems that dtrace is having only an impact on flash's timing-code.

none of the linux processes actually crashes (that is is being terminated) in this scenario. ps alx shows that all processes still exist.

i'll play a bit more with the dtrace scripts and see if i can remove more stuff that isn't important for futex related matters.

good night. alex

Bye, Alexander.