2 Systems
System A with Process A
System B with Process B
So my question here is
Process B should be not be invoked till there is event from Process A..
Is this possible in ARINC 653
It would be helpful if any leads
Related
I have two process (Linux ELF): process A is a main process and B is a child process (A uses fork() to create B). A also uses ptrace to trace the B (like some kind of sandbox) catching the B’s int 3 instruction.
I want to use GDB to debug process B. When I tried GDB to attach the child process B, it shows an error that B is already under debug. So do I have a way to debug the child process which is already under another “debugger”?
In my case, A and B have interactions, I cannot directly patch or rewrite the code in A to disable ptrace function.
So do I have a way to debug the child process which is already under another “debugger”?
No.
Having a child that is ptrace'd by its parent, with non-trivial interaction between the two, is one of the few effective anti-debugging techniques.
To debug B, you would have to run it without A sandboxing it, and would have to replicate the interaction between A and B by "emulating" what process A normally does to process B through GDB.
I am using queues in the context of processes and threads and there is a constellation with a strange behavior which i do not understand.
the used queue is defined like this: multiprocessing.Queue(1)
First Constellation (works fine)
initiate queue
Process 1 starts Process 2 (queue in parameters)
Process 1 starts Thread
2 Loops (one inside Thread one in Process 2) are communcating via the queue: everything works fine
Second Constellation (does not work)
Process 1 starts Process 2
inside Process 2 queue is initiated
Process 2 starts Process 3 (queue in parameters)
Process 2 starts Thread
2 Loops (one inside Thread one in Process 3) are communcating via the queue:
--> Loop in Thread in Process2 says always queue is full (wants to put something in the queue)
--> Loop in Process 3 says always queue is empty
Third Constellation (works fine)
Process 1 starts Process 2
inside Process 2 queue is initiated
Process 2 starts Process 3 (queue in parameters)
2 Loops (one in Process 2 one in Process 3) are communcating via the queue: everything works fine
I do not understand what's the problem with the second constellation. I read that this could happen if one first starts the thread and then the child-process. But i start Process 3 first and then start the Thread in Process 2. And if the thread is the Problem why does constellation 1 work?
I have a questions regarding the actual synchronization points in the following c - like psuedocode examples. In our slides the synchronization point is shown to occur at the point indicated below.
Two process 2 way synchronization, x and y = 0 to start
Process 1
signal(x);
//Marked as sync point
wait(y);
Process 2
signal(y);
//This arrow isn't as exact but appears to be near the middle again.
wait(x);
Now for just two process 2 way sync this seems to make sense. However, when expanding this two 3 process 3 way sync this logic seems to break down. There are no arrows given in the slide deck.
3 Process 3 Way Synchronization (S1, S2, S3 = 0 to start)
Process 0
signal(S0);
signal(S0);
wait(S1);
wait(S2);
Process 1
signal(S1);
signal(S1);
wait(S0);
wait(S2);
Process 2
signal(S2);
signal(S2);
wait(S0);
wait(S1);
Now I find the sync point couldn't actually be between the signal and the wait. For example:
Let's so Process 0 runs first and signals S0 once. Now S0 = 1. Now let's say that before the second signal(S0) can be run that the process is interrupted and Process 1 runs next. Let's say that only one signal(S1) can be run before the process is interrupted. Now the value of S1 = 1. Now let's say that Process 2 runs next. This signal(S2) is allowed to run so S2 = 2. Now the process is not interrupted so it is allowed to continue. Wait(S0) runs which decrements S0 by 1. S0 now equals 0. However, process 2 is allowed to continue running because S0's value is not a negative value. Now wait(S1) is allowed to run and a similar thing here happens.
At this point Process 2 is done running. However Process 0 and Process 1 did not finish their signal's. If the sync point is truly in between signals and wait then this solution to 3 way 3 process sync is incorrect.
A similar issue can arise in solution for 3 process 3 way synchronization that allows each process to run more than one instance of itself at a time. Attached is that slide but I will not explain why the "middle" point in the process can't be the sync point as I already have a huge wall of text.
Please let me know which way is correct, no amount of googling has given me an answer. I will include all relevant slides.
I have a process with two threads.
First thread is doing async work - it waits for IO on descriptors and timer events in epoll_wait.
Second thread is doing a lot of IO/memory work - it reads data from disk, process it in memory, allocates a lot of new memory, write it to disk and so on.
The problem is that first thread blocks in epoll_wait for much longer time, then was requested in timeout for epoll_wait(e.g. timeout was specified as 1500 ms and actually return from epoll_wait occures in 10 seconds).
This behavior I can reliably reproduce in virtual machine(VirtualBox with Ubuntu 16.04).
Example of behavior from GDB:
Thread 2.1 "se.real" hit Breakpoint 1, boost::asio::detail::epoll_reactor::run (this=0x826ebe0, block=true, ops=...) at /opt/com/include/boost/158/boost/asio/detail/impl/epoll_reactor.ipp:392
392 in /opt/com/include/boost/158/boost/asio/detail/impl/epoll_reactor.ipp
16:36:38.986826839
$17 = 1945
Thread 2.1 "se.real" hit Catchpoint 3 (call to syscall epoll_wait), 0xf7fd8be9 in __kernel_vsyscall ()
16:36:38.992081396
<INSIDE KERNEL>
Thread 2.1 "se.real" hit Catchpoint 3 (returned from syscall epoll_wait), 0xf7fd8be9 in __kernel_vsyscall ()
16:36:54.681444938
Breakpoint 1 is set to instruction prior to call epoll_wait, printed argument is timeout argument value(1945 ms).
Printed time is time from shell date +"%T.%N" command.
Catchpoint 3 is syscall catchpoint for epoll_wait syscall(first for enter, second for return).
We can easily see that we have spent in kernel for ~ 16 seconds, when 1945 ms were requested.
I have gathered perf record with -e 'sched:*' events from another reproduction. And I perfectly see:
se.real 4277 [001] 113049.144027: sched:sched_switch: prev_comm=se.real prev_pid=4277 prev_prio=120 prev_state=t|K ==> next_comm=strace next_pid=4142 next_prio=120
se.real 4277 [001] 113056.407952: sched:sched_stat_runtime: comm=se.real pid=4277 runtime=153767 [ns] vruntime=409222246640 [ns]
No any other sched event for thread 4277(first thread with async IO and epoll_wait) for ~7 seconds. In mean time there are a lot of sched activity between this events. This activity includes both second thread(thread with a lot of IO/memory work), swapper/kswapd, and other userspace processes.
The question is what I can do to give a chance for running first thread?
Update: changing scheduling policy to SCHED_FIFO for process doesn't solve problem - I'm still able stably reproduce the issue.
Process B epolls on the pipe (EPOLLIN|EPOLLET).
Process A writes 1KiB in pipe.
Process B wakes up.
Process B reads 1KiB from the pipe.
Process A writes 1KiB in pipe.
Process B epolls on the pipe.
The state of the pipe does not change during epoll, but has changed since the last read. Will process B wake up again?
My understanding from the FAQ (Q9) in http://linux.die.net/man/4/epoll is that you will get another event in step 6 (assuming that you can guarantee that step 5 really happens after step 4 and the pipe is empty after step 4).
Having said that, you might get more events than guaranteed (but you have to be careful only to rely on documented behavior) - see http://cmeerw.org/blog/753.html#753 and http://cmeerw.org/blog/750.html#750
While it's true that the kernel wakes up on step 6, that is not what's documented by the manual page. The use case you provide does not conform to how EPOLLET is supposed to be used.
According to the documentation, step 6 should be "read from the FD". The only time you are supposed to poll from the FD is after you tried to read and got EAGAIN.
See also: What is the use case for EPOLLET?