[OT] Some computer and computer equipment to give
Hi, I have some computers about 500Mhz. Tv cards, network cards, hard modems, video cards, a lot of new cables (net, audio, usb...). Its a good equipment and can be used for home servers and as a donation if someone here have the time to put linux on it. The equipment are located at my friend house in Ramat Gan. There is an ultimatum though ;) One day by his wife! (Maybe it can be bent, but not for long) So please contact him today. Ilan: ilanr1 at 012 dot net dot il Thanks, Kfir
Re: Something weird is happening
On Fri, 2007-12-07 at 16:03 +0200, Oron Peled wrote: On Friday, 7 בDecember 2007, Oded Arbel wrote: The first call that is interesting is of course the open() for /etc/protocols. In the second test (after I did ls /etc/protocols) it looks normal: open(/etc/protocols, O_RDONLY|0x8 /* O_??? */) = 8 but in the first test is looks like this: open(/etc/protocols, O_RDONLY|0x8 /* O_??? */) = -530 Reading man 2 open, it says that open() should return -1 in case of an error. I'm still looking as to what -530 means, but I've yet to find anything on the web. You wouldn't. An strace would show you the return value (which should be -1 for an error, and a translation to errno definition). The -530 heavily hints that you have somehow corrupted glibc (or kernel, or both). Another option is a simple memory hardware problem. However, I'm not sure if you can run memtest86+ in your hosting environment. If something still functions on this system, than an: rpmverify glibc kernel May shed more light. rpmverify glibc kernel return nothing (exactly nothing, no output whatsoever - I assume that it means there are no errors). Except for the weird inaccessibility of files until I get a shell to list them (and then possibly only for /etc though I doubt it), everything works correctly. -- Oded To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Something weird is happening
On Dec 8, 2007 6:59 PM, Oded Arbel [EMAIL PROTECTED] wrote: rpmverify glibc kernel May shed more light. rpmverify glibc kernel return nothing (exactly nothing, no output whatsoever Yes it did, it returned an error code. rpmverify glibc kernel; echo $? -- Oded -- Cheers, Maxim Veksler Free as in Freedom - Do u GNU ? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Something weird is happening
On Sat, 2007-12-08 at 20:04 +0200, Maxim Veksler wrote: On Dec 8, 2007 6:59 PM, Oded Arbel [EMAIL PROTECTED] wrote: rpmverify glibc kernel May shed more light. rpmverify glibc kernel return nothing (exactly nothing, no output whatsoever Yes it did, it returned an error code. rpmverify glibc kernel; echo $? Oh, I thought its like rpm -V. anyway - 0. it returns 0. nothing to see here, move along now... move along. -- Oded = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
ptrace help
Hi all, I need help trying to wrap my head around ptrace. I'm trying to create the most basic of programs: in the child process (right after the fork) I do: ptrace(PTRACE_TRACEME); printf(Being traced\n); execve(argv[opt_offset], argv+opt_offset, env); exit(1); In the parent I do: pid_t ret=waitpid(first_child, status, 0); ptrace( PTRACE_DETACH, ret ); ret=waitpid(first_child, status, 0); Instead of DETACH I already tried PTRACE_CONT and PTRACE_SYSCALL. What I expect to happen is that the child should run what I tell it to (I tell it to run echo hi), and be caught with both waits. Instead, the first wait catches a signal 5 (TRAP, as expected), but the second wait hangs forever AND THE ECHO DOES NOT RUN!! Also of interest is that when I added the printf after the TRACEME, that printf gets executed (output goes to the console) before the first wait at the parent. In other words, the program is not being traced immediately. I need help figuring out what the !*(#()@! is going on here. Thanks, Shachar P.s. Please do not send me to read strace's source code for reference. Strace's source code is so twisted I cannot understand how ANYONE can figure out what's going on there, and that's before mentioning the #ifdefs Sh. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ptrace help
On Sat, 2007-12-08 at 23:50 +0200, Shachar Shemesh wrote: Hi all, I need help trying to wrap my head around ptrace. I'm trying to create the most basic of programs: in the child process (right after the fork) I do: [... snipped ...] Shachar, You provided us with a description of the expected and actual behaviors. However, it would be better if you provided us with the full source code of a sample program involving ptrace, as written by you. From skimming man ptrace, it appears that the subprocess is stopped by ptrace actions and needs to be restarted. Overall the ptrace command set seems to be designed around the metaphor of an human-controlled debugger. --- Omer -- One does not make peace with enemies. One makes peace with former enemies. My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ptrace help
On Sat, Dec 08, 2007 at 11:50:17PM +0200, Shachar Shemesh wrote: In the parent I do: pid_t ret=waitpid(first_child, status, 0); ptrace( PTRACE_DETACH, ret ); ret=waitpid(first_child, status, 0); Instead of DETACH I already tried PTRACE_CONT and PTRACE_SYSCALL. What I expect to happen is that the child should run what I tell it to (I tell it to run echo hi), and be caught with both waits. Instead, the first wait catches a signal 5 (TRAP, as expected), but the second wait hangs forever AND THE ECHO DOES NOT RUN!! You are leaving out the last two arguments of ptrace() in the parent, so they take garbage values, causing an unknown signal to be sent to the child. Try it with ptrace(PTRACE_SYSCALL, ret, 0, 0); Also of interest is that when I added the printf after the TRACEME, that printf gets executed (output goes to the console) before the first wait at the parent. In other words, the program is not being traced immediately. That's because ptrace(PTRACE_TRACEME) does not stop the process. If you want it stopped immediately after the ptrace() call, you need to do it yourself; e.g. send yourself a STOP signal. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ptrace help
Adam Morrison wrote: First of all, thanks, I got it working. I still don't understand why it's working. You are leaving out the last two arguments of ptrace() in the parent, The man page says I'm allowed to do so in case the other arguments are not used. so they take garbage values, causing an unknown signal to be sent to the child. Try it with ptrace(PTRACE_SYSCALL, ret, 0, 0); Yes, that worked. What I don't understand, however, is why it worked. While the man page for PTRACE_SYSCALL mentions that addr is ignored (implying that data isn't), it does not actually tell me what the content of data is. When I tried writing 5 into data (i.e. - SIGTRAP) the next wait returns with Process exited with signal 5. It seems to be that when the data field is non-empty, the signal number I write there is actually delivered to the debugged process, but that is not documented in the manual, as far as I could see. Also of interest is that when I added the printf after the TRACEME, that printf gets executed (output goes to the console) before the first wait at the parent. In other words, the program is not being traced immediately. That's because ptrace(PTRACE_TRACEME) does not stop the process. If you want it stopped immediately after the ptrace() call, you need to do it yourself; e.g. send yourself a STOP signal. Is it being traced in any other reliable point? I now understand that the point it stops is when the first signal is being received, but I'm not sure whether exec guarantees that such a signal actually happens, or whether I should really send one myself. In any case, thanks again. You allowed me to pass the initial hurdle. Shachar = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
