|
From: janjust <tja...@un...> - 2011-06-29 13:29:51
|
Hi all, Does anyone have any pointers on how to catch when a fork in a client occurs? Precisely my aim is to order the PIDs with respect to when they occurred. Say client creates a total of 3 children excluding the parent. I'd like to know roughly in the SBs or even instructions if possible when that fork call started. My current understanding is that when the client forks, valgrind process will replicate itself. Catching the fork within the child is not a problem by simply checking the PID of the child; however, how would I go about making sure that the parent knows that a child has been created? Not within the client, but within Valgrind. Thoughts? -- View this message in context: http://old.nabble.com/catching-a-fork%28%29-in-client-tp31954761p31954761.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Tom H. <to...@co...> - 2011-06-29 13:48:08
|
On 29/06/11 14:29, janjust wrote: > Does anyone have any pointers on how to catch when a fork in a client > occurs? Precisely my aim is to order the PIDs with respect to when they > occurred. Presumably you're righting a tool, and want to know how the tool should get called when a fork occurs? I can't see any other context in which the question makes sense, but you didn't actually say what the context of your question was. What you need to look at is VG_(atfork) in include/pub_tool_libcproc.h anyway, which will let you register callbacks to be called at various points in the fork process. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: janjust <tja...@un...> - 2011-06-29 13:55:30
|
Thanks for the tip, I'll look into that. To clarify: Yes I'm writing my own tool, the aim is to trace instructions and dump them to a pid.out But in each parent I'd like to intercept the fork and simply dump a keyword in the pid<parent>.out that says FORK_OCCURED, makes sense? Tommy Bugzilla from to...@co... wrote: > > On 29/06/11 14:29, janjust wrote: > >> Does anyone have any pointers on how to catch when a fork in a client >> occurs? Precisely my aim is to order the PIDs with respect to when they >> occurred. > > Presumably you're righting a tool, and want to know how the tool should > get called when a fork occurs? I can't see any other context in which > the question makes sense, but you didn't actually say what the context > of your question was. > > What you need to look at is VG_(atfork) in include/pub_tool_libcproc.h > anyway, which will let you register callbacks to be called at various > points in the fork process. > > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- View this message in context: http://old.nabble.com/catching-a-fork%28%29-in-client-tp31954761p31954980.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-06-30 13:43:26
|
>> I thought anything in a pub_tool_* header was available to tools? > >Yeah .. it is. I'm not exactly clear about the architectural rationale >of having a formal core-tool interface >(include/pub_tool_tooliface.h) and >also a bunch of functions (include/pub_tool_everythingelse.h). There's >probably a good reason, but I don't know what it is. I understand that pub_tool_tooliface.h is what allows the tool to give some of "its tool" functions/data to the core, so that the core receive the needed tool functions it must know about. While all the other pub_tool_everythingelse.h is what the tool can call itself directly from the core. But I did not check exhaustively pub_tool_tooliface.h to see it is only made of such "give something to the core so core can call the tool". Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Julian S. <js...@ac...> - 2011-06-30 13:10:07
|
> What you need to look at is VG_(atfork) in include/pub_tool_libcproc.h > anyway, which will let you register callbacks to be called at various > points in the fork process. That's not part of the formal core-tool interface though. Another possibility is to use the VG_(needs_syscall_wrapper) facility in the core-tool interface, which allows your tool to be notified of all system calls, arguments and results, before and after the syscalls, and then ignore all of them except __NR_fork. J |
|
From: Julian S. <js...@ac...> - 2011-06-30 13:21:21
|
> I thought anything in a pub_tool_* header was available to tools? Yeah .. it is. I'm not exactly clear about the architectural rationale of having a formal core-tool interface (include/pub_tool_tooliface.h) and also a bunch of functions (include/pub_tool_everythingelse.h). There's probably a good reason, but I don't know what it is. J |
|
From: Tom H. <to...@co...> - 2011-06-30 13:11:45
|
On 30/06/11 14:09, Julian Seward wrote: >> What you need to look at is VG_(atfork) in include/pub_tool_libcproc.h >> anyway, which will let you register callbacks to be called at various >> points in the fork process. > > That's not part of the formal core-tool interface though. > Another possibility is to use the VG_(needs_syscall_wrapper) > facility in the core-tool interface, which allows your tool to > be notified of all system calls, arguments and results, before > and after the syscalls, and then ignore all of them except __NR_fork. I thought anything in a pub_tool_* header was available to tools? Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: janjust <tja...@un...> - 2011-07-01 15:40:17
|
VG_(needs_syscall_wrapper) was exactly what I was looking for. Question: When running a simple fork program I see that syscallno returns it as a clone() call syscallno=56 not a fork() syscallno=57. Does this have to do with the way linux implements fork()? or is this due to valgrind? Can you shed some light if you know what's happening? WAROQUIERS Philippe wrote: > > >>> I thought anything in a pub_tool_* header was available to tools? >> >>Yeah .. it is. I'm not exactly clear about the architectural rationale >>of having a formal core-tool interface >>(include/pub_tool_tooliface.h) and >>also a bunch of functions (include/pub_tool_everythingelse.h). There's >>probably a good reason, but I don't know what it is. > > I understand that pub_tool_tooliface.h is what allows the tool to > give some of "its tool" functions/data to the core, so that the core > receive the needed tool functions it must know about. > > While all the other pub_tool_everythingelse.h is what the tool can > call itself directly from the core. > > But I did not check exhaustively pub_tool_tooliface.h to see it is only > made of such "give something to the core so core can call the tool". > > > Philippe > > ____ > > This message and any files transmitted with it are legally privileged and > intended for the sole use of the individual(s) or entity to whom they are > addressed. If you are not the intended recipient, please notify the sender > by reply and delete the message and any attachments from your system. Any > unauthorised use or disclosure of the content of this message is strictly > prohibited and may be unlawful. > > Nothing in this e-mail message amounts to a contractual or legal > commitment on the part of EUROCONTROL, unless it is confirmed by > appropriately signed hard copy. > > Any views expressed in this message are those of the sender. > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- View this message in context: http://old.nabble.com/catching-a-fork%28%29-in-client-tp31954761p31974703.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: John R. <jr...@bi...> - 2011-07-01 15:49:49
|
> Question: When running a simple fork program I see that syscallno returns it > as a clone() call syscallno=56 not a fork() syscallno=57. > > Does this have to do with the way linux implements fork()? or is this due to > valgrind? glibc implements fork() as clone() with some particular parameters. Run under 'strace' to see them. -- |