 |
|
| Linux Forum Index » Linux Development - System » Futex Wait Called... |
|
Page 1 of 1 |
|
| Author |
Message |
| pandi... |
 Posted: Thu Oct 22, 2009 5:43 pm |
|
|
|
Guest
|
I am working on fedora core 7, kernel version 2.6.21, gcc version
4.1.2. I have my user space application which communicate with my char
driver using write and read system calls. I have a thread in
application to send data to driver and concurrently a signal handler
(user space) is register. write calls is invoking continuously and
read call is also invoking continuously on notification from driver.
Here am facing a problem of "futex_wait" at one time. Even though my
user space application has no mutex locking, FUTEX_WAIT is called and
nothing proceeds after this.
I got below lines form strace of my process and always getting lock at
same address.
--- SIGRT_15 (Real-time signal 13) at (no spam) 0 (0) ---
futex(0x4aa700b0, FUTEX_WAIT, 2, NULL
please guide me to solve this issue or what could be reason for above
things.
if need any more info, i will give u. |
|
|
| Back to top |
|
|
|
| David Schwartz... |
| Posted: Thu Oct 22, 2009 6:04 pm |
|
|
|
Guest
|
On Oct 22, 8:43 pm, pandi <pandi.... at (no spam) gmail.com> wrote:
Quote: I got below lines form strace of my process and always getting lock at
same address.
--- SIGRT_15 (Real-time signal 13) at (no spam) 0 (0) ---
futex(0x4aa700b0, FUTEX_WAIT, 2, NULL
please guide me to solve this issue or what could be reason for above
things.
if need any more info, i will give u.
Attach to the process with 'gdb' and see what function it's in.
DS |
|
|
| Back to top |
|
|
|
| Rainer Weikusat... |
| Posted: Fri Oct 23, 2009 5:32 am |
|
|
|
Guest
|
David Schwartz <davids at (no spam) webmaster.com> writes:
Quote: On Oct 22, 8:43 pm, pandi <pandi.... at (no spam) gmail.com> wrote:
I got below lines form strace of my process and always getting lock at
same address.
--- SIGRT_15 (Real-time signal 13) at (no spam) 0 (0) ---
futex(0x4aa700b0, FUTEX_WAIT, 2, NULL
please guide me to solve this issue or what could be reason for above
things.
if need any more info, i will give u.
Attach to the process with 'gdb' and see what function it's in.
This can still cause all kinds of weird effects, especially when the
process is multi-threaded. A more robust way to use gdb in such a
situation is to send a SIGQUIT (3) to the program (Ctrl-\) and run gdb
with the binary and the resulting coredump[*] as argument.
[*] In absence of deliberate sabotage, eg, as in fetchmail,
this can be enabled by using ulimit -c <size in K>. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Wed Dec 09, 2009 11:15 pm
|
|