By interpreting the 1st argument as an address and reading the value on this
address, I get a 0 for the first three lines of my output (which are the futex
calls).
Very nice how you use awk and the created header file in the middle of your
code. I tried it. It works ;-)
A few answers ago, you s
Hi,
> By interpreting the 1st argument as an address and reading the value on this
> address, I get a 0 for the first three lines of my output (which are the
> futex calls).
No surprise for the first one because you just pushed a 0 at it to
unblock your process.
For the later ... I just wonder
Hi,
1) To have a less cryptic output you may add one function to your
program.
It is composed of an automatically built part from header (on my
system /usr/include/asm/unistd_32.h) sc.h file and
a C source file that includes the former.
a) Building the sc.h by :
awk 'NR==1 { printf("#include <%s>
Thanks for your quick answers!
After poking a zero, I performed a little loop to get the system call number
(orig_eax) and the next two arguments (ebx, ecx) of the next 20 system calls.
This is how it looks:
syscall=240 (1st_arg=-1210085564 2nd_arg=0)
syscall=240 (1st_arg=-1210085564 2nd_arg=1)
> You are right. I dont need to restore the signal handler - one system call
> less in my signal handler.
> I now saved a snapshot of the unfinished futex call. So I can experiment as
> often as I want.
> Poking a 1 does not work. But Poking a 0 works perfektly fine.
Thank you for this informati
You are right. I dont need to restore the signal handler - one system call less
in my signal handler.
I now saved a snapshot of the unfinished futex call. So I can experiment as
often as I want.
Poking a 1 does not work. But Poking a 0 works perfektly fine.
And youre also right : I cannot use str
Yes yes ! Normally the connect(2) should be followed by a send(2).
It is impossible to strace and use survfutex at the same time on your
process because both of them use the ptrace(2) and a process cannot be
ptraced twice at the same time (the ATTACH will not work).
But, you can use the tcpdump co
Hi,
> Basically my program looks like this:
>
> static volatile sig_atomic_t child_terminated=0;
>
> void sigchld_handler(int sig) {
> int copy_errno=errno;
> debug("Received SIGCHLD");
> child_terminated=1;
> signal(SIGCHLD,sigchld_handler);
> errno=copy_errno;
> }
>
> int
By the way: The last system call before SIGCHLD arrives is "connect".
This call is also part of the debug procedure. But strace does not mark
this call as "unfinished". Normally "connect" is followed by a "send".
--
Futex hang when exiting using the window close button
https://bugs.launchpad.net/
Basically my program looks like this:
static volatile sig_atomic_t child_terminated=0;
void sigchld_handler(int sig) {
int copy_errno=errno;
debug("Received SIGCHLD");
child_terminated=1;
signal(SIGCHLD,sigchld_handler);
errno=copy_errno;
}
int main() {
signal(SIGCHLD,sig
Hi Wayne,
A - There are some "strange" behaviours with signal on Linux since the
advent of posix threads. I mean "strange" for programer that is used
with the simple fork()/wait()/exit().
What I just concluded with all of this, is :
if one choose to use this then he has to avoid using s
Hi Rogers,
Thanks for your interesting C-code!
Occasionally I am experiencing the same problem.
The program freezes due to a FUTEX_WAIT call (detected by the use of strace),
directly after the arrival of SIGCHLD.
After reading some documents on futexes I believe to know, that the reason for
the d
** Changed in: xchat-gnome (Ubuntu)
Importance: Undecided => Low
Assignee: (unassigned) => Ubuntu Desktop Bugs (desktop-bugs)
--
Futex hang when exiting using the window close button
https://bugs.launchpad.net/bugs/57731
You received this bug notification because you are a member of Ubunt
Hi,
When you try to quit, do you use an Interrupt key sequence (i.e.
Ctrl-C) ?
-Rogers
> I know almost nothing about this, but I am seeing the same error in
> xmoto. I try to quit and it hangs until I kill it with -9. Strace
> reveals a futex hang. 100% reproducible. Hardy Heron with fglrx.
>
>
I know almost nothing about this, but I am seeing the same error in
xmoto. I try to quit and it hangs until I kill it with -9. Strace
reveals a futex hang. 100% reproducible. Hardy Heron with fglrx.
** Changed in: xchat-gnome (Ubuntu)
Status: New => Confirmed
--
Futex hang when exiting us
Hi,
I am experiencing same trouble on a self made program.
I made a tool used to unfreeze process (and watch periodically) : survfutex
I send you the source in attachment. You can try it on the frozen process to
check that it works (normaly it would). It is using the ptrace(2) syscall to
attach t
On Tue, Aug 29, 2006 at 09:24:59AM -, Guillaume Desmottes wrote:
> I suppose you don't know how to reproduce this bug?
I tried closing xchat in the same manner a second time and was unable to
reproduce the crash, unfortunately.
--
- mdz
--
Futex hang when exiting using the window close bu
The futex thing is definitely a side effect of something, and not the
cause. Other than that, I don't know.
--
Futex hang when exiting using the window close button
https://launchpad.net/bugs/57731
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/list
I suppose you don't know how to reproduce this bug?
David, any idea about this issue?
--
Futex hang when exiting using the window close button
https://launchpad.net/bugs/57731
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
19 matches
Mail list logo
