tracing exec system call

2002-10-17 Thread Ramkumar Chinchani
What would be the best way to *capture* the execv system call at its entry point from user space? ptrace()? What would be a good way to inspect the command line args to execv *after* the path, etc., has been resolved? This is useful if one wants to monitor a process and all the system calls it

Re: kevent subsystem

2002-05-10 Thread Ramkumar Chinchani
? Thanks. -Ram ==> Terry Lambert <[EMAIL PROTECTED]>/11:23pm/May 9, 2002 <== [Ramkumar Chinchani wrote: [> Has the POSIX event standard implemeted in FreeBSD? POSIX events are logged to [> a file. Which would give a better performance, assuming kevent can register more [&g

kevent subsystem

2002-05-09 Thread Ramkumar Chinchani
Has the POSIX event standard implemeted in FreeBSD? POSIX events are logged to a file. Which would give a better performance, assuming kevent can register more events? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Ptracing each other

2002-04-03 Thread Ramkumar Chinchani
How does make such a distinction inside the kernel? Is it possible to identify trace events in a trace and just ignore them? -Ram ==> Terry Lambert <[EMAIL PROTECTED]>/7:01pm/Apr 3, 2002 <== [Ramkumar Chinchani wrote: [> The requirement is that I have a theoretical framework w

Re: Ptracing each other

2002-04-03 Thread Ramkumar Chinchani
would one gdb gdb when it's gdbing you? [Maybe you need to explain WHY rather than WHAT. [ [ [On Wed, 3 Apr 2002, Ramkumar Chinchani wrote: [ [> [> Track means to basically trace the execution and watch the events that [> occur without any interprocess communication. [> [> -

Re: Ptracing each other

2002-04-03 Thread Ramkumar Chinchani
Track means to basically trace the execution and watch the events that occur without any interprocess communication. -Ram ==> Julian Elischer <[EMAIL PROTECTED]>/4:59pm/Apr 3, 2002 <== [that depends on what you mean by "track" [ [ [On Wed, 3 Apr 2002, Ramkumar Chinchani

Re: Ptracing each other

2002-04-03 Thread Ramkumar Chinchani
0:13PM -0500, Ramkumar Chinchani wrote: [ [> What are the pitfalls in two processes ptracing each other? [> [> Are there possibilities of deadlocks? [ [Yes. [http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/29741 [Last time I checked, both -STABLE and -CURRENT are affected by this bug. [ [ [Tim [

Ptracing each other

2002-04-03 Thread Ramkumar Chinchani
What are the pitfalls in two processes ptracing each other? Are there possibilities of deadlocks? -Ram To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Memory management bug in FreeBSD 4.5 RELEASE

2002-03-16 Thread Ramkumar Chinchani
But why does this not happen after i = 32 ? I hardly see any increase in memory usage after that. -Ram ==> mark tinguely <[EMAIL PROTECTED]>/11:30am/Mar 16, 2002 <== [> int i = 32; [> [> int [> main(){ while (1) malloc(i); } [> [> [> As long as i is in between 1 and 32, all memory is used

Memory management bug in FreeBSD 4.5 RELEASE

2002-03-16 Thread Ramkumar Chinchani
I wrote a small program as follows int i = 32; int main(){ while (1) malloc(i); } As long as i is in between 1 and 32, all memory is used up and all swap is used up, and then the process is killed. Again, when i > 32, all seems well. What could be the problem? -Ram To Unsubscribe: send m