[Bugs] #4061 sugar-toolkit-gtk3 IMME: Global gesture: can crash Sugar under certain circumstances

[Sugar Labs Bugs]

#4061: Global gesture: can crash Sugar under certain circumstances
-----------------------------------+----------------------------------------
    Reporter:  erikos              |          Owner:  erikos  
        Type:  defect              |         Status:  new     
    Priority:  Immediate           |      Milestone:  0.98    
   Component:  sugar-toolkit-gtk3  |        Version:  0.97.x  
    Severity:  Blocker             |       Keywords:          
Distribution:  OLPC                |   Status_field:  Assigned
-----------------------------------+----------------------------------------

Comment(by dsd):

 Yes, its an X crash. I got this trace with debuginfo installed:

 {{{

 (gdb) bt
 #0  0xb6a4ee38 in raise () from /lib/libc.so.6
 #1  0xb6a50478 in abort () from /lib/libc.so.6
 #2  0xb6a8b4e0 in ?? () from /lib/libc.so.6
 #3  0xb6a91c08 in ?? () from /lib/libc.so.6
 #4  0xb6a94788 in ?? () from /lib/libc.so.6
 #5  0xb6a97428 in calloc () from /lib/libc.so.6
 q
 #6  0x0013a9b4 in ProcXIQueryPointer (client=0x3961c8) at
 xiquerypointer.c:153
 #7  0x0013011c in ProcIDispatch (client=<optimized out>) at extinit.c:406
 #8  0x000388b8 in Dispatch () at dispatch.c:428
 #9  0x00028138 in main (argc=8, argv=0x28138 <main+1052>, envp=<optimized
 out>)
     at main.c:295
 }}}

 The crash site (calloc) plus the fact that the other trace I took being
 different agrees - this must be some kind of memory corruption.

 To stop X restarting you can do:
 {{{
  systemctl stop olpc-dm.service
 }}}

 To start X just once via the normal display-manager path (integrating with
 PAM and all that):
 {{{
 olpc-dm
 }}}

 To run Sugar in a more bare bones environment:
 {{{
 X # on one terminal
 DISPLAY=:0 sugar-session # on another terminal
 }}}
 (I can't reproduce the crash under that environment)

 Running X under valgrind doesn't seem like it is going to work on ARM.
 Take a simple test:
 {{{
 bash-4.2# valgrind X
 ==2638== Memcheck, a memory error detector
 ==2638== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
 ==2638== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
 ==2638== Command: X
 ==2638==
 disInstr(arm): unhandled instruction: 0xECECA102
                  cond=14(0xE) 27:20=206(0xCE) 4:4=0 3:0=2(0x2)
 ==2638== valgrind: Unrecognised instruction at address 0x4018638.
 ==2638==    at 0x4018638: ??? (in /usr/lib/ld-2.16.so)
 ==2638== Your program just tried to execute an instruction that Valgrind
 ==2638== did not recognise.  There are two possible reasons for this.
 ==2638== 1. Your program has a bug and erroneously jumped to a non-code
 ==2638==    location.  If you are running Memcheck and you just saw a
 ==2638==    warning about a bad jump, it's probably your program's fault.
 ==2638== 2. The instruction is legitimate but Valgrind doesn't handle it,
 ==2638==    i.e. it's Valgrind's fault.  If you think this is the case or
 ==2638==    you are not sure, please let us know and we'll try to fix it.
 ==2638== Either way, Valgrind will now raise a SIGILL signal which will
 ==2638== probably kill your program.
 }}}

 Maybe you will have more luck debugging this on your development machine
 (x86, I assume).

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/4061#comment:4>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system