On Fri, Aug 19, 2005 at 20:18:41 +0000, Vincenzo Mallozzi wrote: > On Friday 19 August 2005 11:47, Bhanu Kalyan Chetlapalli wrote: > > I am not very sure, but actually functions like _exit etc are declared > > using the GCC attribute "noreturn". Even if you are using different > > functions, there is a good chance that this attribute might be set. > > > > From unistd.h > > > > extern void _exit (int __status) __attribute__ ((__noreturn__)); > > > > noreturn attribute *may* not restore the registers saved by the > > calling function (as part of the optimization). This can possibly > > explain the segmentation violations etc. > > I don't think this is the cause of segfault as, when I return back to a > previous system state, I restore registers relative to threads I'm > monitoring. If I restore the register of all threads all at once, they > restart from a previous state. The error occurs when, after a restoring, the > threads reach the end. At this point, the segfault occurs. > Do you have an idea on how I can manage the sys_exit using a technique > different from the syscall hijacking. Does the cause of the segfault lie in user or kernel mode? That is, do you get a kernel OOPS or similar message, or just segfault in the process? If you get an OOPS (or some error from kernel), that'd mean that you are not saving the kernel stack of the process properly. If you don't, try to get a core dump from the segfault and see where it happens. As once the thread actually invokes the sys_exit syscall no other user-space instruction will run, it seems likely the segfault actually happens somewhere in libc exit. A core dump might show that you have corrupted or not preserved some structure that the thread needs in the exit function. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
