http://bugs.cinelerra.org/show_bug.cgi?id=406
------- Comment #29 from [EMAIL PROTECTED] 2008-05-06 17:23 +2 -------
This could be a problem with XFlush.
I my system cinelerra usually hangs after displaying it's windows but
occasionally will come up OK.
I managed to obtained straces on all threads in both cases
(strace -ttffo run<n> cinelerra). Comparing the traces lead me to investigate
the main thread (thread 1) and the third thread started (thread 3).
Note: when referring to thread numbers I take the main task as thread 1 and
increase the thread number of each thread cloned. They bare no relation to the
thread numbers used by GDB when the program hangs.
When cinelerra hangs thread 3 is waiting for a select on file ID 7 while
thread 1 is waiting on thread 3 to finish. Here are the relevant parts of
strace for thread 1 (trace 1)
13:16:13.100823 select(8, [7], [7], NULL, NULL) = 1 (out [7])
13:16:13.100985 writev(7, [{"\31\0\v\0\1\0\200\3\0\0\0\0!
\0\0\10\177\265\0M\2\0\0DW\276\354\1\0\0\0"..., 44}], 1) = 44
13:16:13.101138 read(7, "\241
\v\0\10\177\265\0M\2\0\0DW\276\354\1\0\0\0\0\0\0\0\0\0\0\0W\235\303\356", 4096)
= 32
13:16:13.101262 read(7, 0xb86c54, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
13:16:13.101430 futex(0x410059e0, FUTEX_WAIT, 4300, NULL) = ? ERESTARTSYS (To
be restarted)
13:16:28.751805 --- SIGINT (Interrupt) @ 0 (0) ---
and thread 3 (trace 2)
13:16:09.354593 set_robust_list(0x410059f0, 0x18) = 0
13:16:09.355283 select(8, [7], [7], NULL, NULL) = 1 (out [7])
13:16:09.355385 writev(7,
[{"\1\0\n\0\1\0\200\3\361\0\0\0\0\0\0\0\1\0\1\0\0\0\0\0\0\0\0\0\n\0\0\0"...,
40}], 1) = 40
13:16:09.355629 select(8, [7], [], NULL, NULL) = ? ERESTARTNOHAND (To be
restarted)
13:16:28.903919 +++ killed by SIGABRT +++
when cinelerra come up thread 3 has terminated and thread 1 returns from
waiting on thread 3 in this case the straces are from thread 1 is (trace 3)
10:02:42.493273 select(8, [7], [7], NULL, NULL) = 1 (out [7])
10:02:42.493361 writev(7, [{"\31\0\v\0\1\0\200\3\0\0\0\0!
\0\0\10\177\265\0W\2\0\0D7\337\246\1\0\0\0"..., 44}], 1) = 44
10:02:42.493411 read(7, 0xb86c54, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
10:02:42.493471 futex(0x410059e0, FUTEX_WAIT, 5013, NULL) = 0
10:02:42.500653 select(7, [6], [6], NULL, NULL) = 1 (out [6])
and from thread 3 is (trace 4)
10:02:38.804571 set_robust_list(0x410059f0, 0x18) = 0
10:02:38.804750 select(8, [7], [7], NULL, NULL) = 1 (out [7])
10:02:38.804797 writev(7,
[{"\1\0\n\0\1\0\200\3\361\0\0\0\0\0\0\0\1\0\1\0\0\0\0\0\0\0\0\0\n\0\0\0"...,
40}], 1) = 40
10:02:38.805035 select(8, [7], [], NULL, NULL) = 1 (in [7])
10:02:42.500433 read(7, "\241
\v\0\10\177\265\0W\2\0\0D7\337\246\1\0\0\0\0\0\0\0\0\0\0\0W}\344\250", 4096) =
32
10:02:42.500494 read(7, 0xb86c54, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
10:02:42.500571 _exit(0) = ?
The differences in these traces is where the successful read of file id 7
occurs. When cinelerra hangs the read occurs in tread 1 (trace 1 line 3) when
cinelerra comes up it is in thread 3 (trace 4 line 5). In both cases there are
no successful reads in the other traces.
Further investigation has shown that the select, read and write system calls
for thread 1 occur in the XFlush statement at line 64 of file
guicast/bcclipboard.C wile those for thread 3 occur in the XNextEvent
statement at line 77 of the same file.
At the time that thread 1 executes the XFlush statement it is the only active
thread all other threads have either terminated, waiting for a lock, waiting
for a thread to finish or waiting for an event and of those waiting for an
event only thread 3 is associated with file id 7.
file id 7 is associated with a socket set up as follows
13:16:09.326643 socket(PF_FILE, SOCK_STREAM, 0) = 7
13:16:09.326680 connect(7, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 110)
= 0
13:16:09.326751 getpeername(7, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"},
[8371910236600008724]) = 0
and has the following flags set
strace.4298 13:16:09.327132 fcntl(7, F_GETFL) = 0x2 (flags O_RDWR)
strace.4298 13:16:09.327161 fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
strace.4298 13:16:09.327187 fcntl(7, F_SETFD, FD_CLOEXEC) = 0
there a a few read and writes to the socket prior to the clone of thread 3
which was achieved as follows:
strace.4298 13:16:09.329303 clone(child_stack=0x41005200,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x410059e0, tls=0x41005950, child_tidptr=0x410059e0) = 4300
after the clone and until cinelerra hangs or thread 3 terminates when
cinelerra come up the only use of file id 7 I have found are those in traces 1
to 4.
The documentation for XFlush clearly states that it flushes the output buffer
I assume to send them to the X server for processing. If this is the case I
would expect the selects and writes of traces 1 and 3 but not the reads that
follow. Is XFlush trying to flush the input buffers and why?
I belive that by attempting to read the input buffers XFlush is stealing an
event meant for thread three which causes thread 3 to terminate allowing the
wait on thread 1 to complete and cinelerra to come up.
I don't understand why this difference occurs. I thought it might be a
scheduling problem among the cinelerra threads but the timing on the left of
the trace lines contradict this. You will see that, when cinelerra comes up,
the successful read of trace 4 occurs after the unsuccessful read of trace 3.
If thread 3 had been scheduled after the write but before the read of trace 3
I would have expected the timing of the read in trace 4 to be before that of
the unsuccessful read of trace 3. The best I can suggest is that there is a
delay in the processing of the events by the X server which allows thread 1 to
get the unsuccessful read and exit XFlush before the X server returns the event
which allows which thread 3 then gets although there may be other reasons.
I have assumed that the successful reads are a response by the X server to the
writes of thread 1. I have no proof of this nor have I analysed the messages
which I believe to be client messages (33) with a BC_CLOSE_EVENT atom in which
the only fields set are type, message_type and format.
I use SUSE 10.3 version 2.6.22.17-0.1-default on an AMD Athlon 64 bit processor
(x86_64), use version 7.2-103.4 of xorg-x11-libs, version 7.2-51.2 of
xorg-x11-libxcb and version 2.6.1-18.3 of glibc.
--
Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
