spitzak at gmail.com
Sat Mar 17 23:01:31 PDT 2012
I have done some more debugging of this.
weston-terminal *always* crashes for me after exactly hitting return 12,
13, or 14 times in it. It does not matter if I hit them quickly or
slowly. I can get the same crash by clicking in the window a bunch of times.
Adding a lot of debugging messages clearly shows that the last thing the
terminal does is this:
wl_shm at 3.create_buffer(new id 24, fd 8, 646, 390, 2584, 0)
Which sends a message with an object id = 3, opcode = 0, and size = 28
(this is from a print statement I put into wl_proxy_marshal).
A similar print statement in wl_client_connection_data in weston gets
object id = 0, opcode = 0, and size = 0.
These printouts show that it successfully sent the same message many
times before this failure.
Other programs like dnd will crash but they are more unpredictable. When
dnd crashes it is also always doing wh_shm at 3.create_buffer but the
received object id and opcode are garbage numbers like 610217550 and 33.
But the size is always zero!
Occasionally I have also seen clients crash due to EAGAIN, either on the
sendmsg call or the recvmsg call. It appears you are purposely asking
for non-blocking I/O but not checking for the would-block error
indicator? Adding EAGAIN to the same two places in wayland that EINTR
causes a retry seems to have fixed this, but I suspect I don't know
enough about socket programming to have any idea why it is written this way.
On 03/17/2012 03:33 AM, Ander Conselvan de Oliveira wrote:
> Em 16-03-2012 20:34, Bill Spitzak escreveu:
>> weston-terminal is apparently crashing after about 12 characters are
>> typed. This is on the same system I had to turn EGL_DEPTH_SIZE off on. I
>> get the following messages:
>> nvfx_screen_get_param:103 - Warning: unknown PIPE_CAP 57
>> disconnect from client 0x92c50a8
>> Error sending request: Broken pipe
>> ./client-run.sh: line 34: 6436 Aborted $1
>> Seems to me that some buffer is overflowing?
> I saw the same thing yesterday, but did not have time to do much
> debugging. What I was seeing is that a call to wl_map_lookup() with an
> id 0 fails, so the compositor kills the client but I could not figure
> out where the id 0 was coming from.
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel