weston-terminal crash

[Bill Spitzak]

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.
>
> Cheers,
> Ander
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel