Current xserver head segfault

[Lukas Hejtmanek]

On Fri, Jun 20, 2008 at 08:47:41AM +0930, Peter Hutterer wrote:
> for some reason your memory looks corrupted between POE and UDS. I don't know
> if that's a result of optimization or actual corruption. Can you recompile
> with -O0 and see if the problem persists, and if the backtrace changes?
> 
> Checking the source - POE doesn't touch the device argument, so it should not
> change between POE and UDS.
> And the pointer passed into realloc should never be invalid, since it was
> calloc'd and then alloc'd, both of which should guarantee either NULL or a
> valid memory address.

those are only optimization. With -O0, I can see sane values expect the
realloc value.

However, it seems that memmove in SeKeySymsMap causes memory poisioning:
==18289== Invalid write of size 1
==18289==    at 0x4C27C24: memmove (mc_replace_strmem.c:517)
==18289==    by 0x447352: SetKeySymsMap (string3.h:59)
==18289==    by 0x538176: CopyKeyClass (exevents.c:197)
==18289==    by 0x53901F: DeepCopyDeviceClasses (exevents.c:547)
==18289==    by 0x539A72: ChangeMasterDeviceClasses (exevents.c:756)
==18289==    by 0x539B59: UpdateDeviceState (exevents.c:801)
==18289==    by 0x53A664: ProcessOtherEvent (exevents.c:1002)
==18289==    by 0x57E255: ProcessKeyboardEvent (xkbPrKeyEv.c:209)
==18289==    by 0x4D2E2B: mieqProcessInputEvents (mieq.c:370)
==18289==    by 0x47DFC8: ProcessInputEvents (xf86Events.c:239)
==18289==    by 0x44ED20: Dispatch (dispatch.c:368)
==18289==    by 0x4343AC: main (main.c:415)
==18289==  Address 0x1a08d158 is 0 bytes after a block of size 5,952 alloc'd
==18289==    at 0x4C266E1: realloc (vg_replace_malloc.c:429)
==18289==    by 0x4F796A: Xrealloc (utils.c:1387)
==18289==    by 0x566243: XkbUpdateCoreDescription (xkbUtils.c:459)
==18289==    by 0x578197: XkbInitDevice (xkbInit.c:553)
==18289==    by 0x4478CF: InitKeyClassDeviceStruct (devices.c:1135)
==18289==    by 0x447960: InitKeyboardDeviceStruct (devices.c:1437)
==18289==    by 0x5788FD: XkbInitKeyboardDeviceStruct (xkbInit.c:695)
==18289==    by 0x448CFF: CoreKeyboardProc (devices.c:452)
==18289==    by 0x44841D: ActivateDevice (devices.c:369)

XkbUpdateCoreDescription runs twice and in the first run it sets maxSymsPerkey
to 6 and in the second run it sets the value 8. Knowing nothing about
internals, but it may happend that these two allocations are copied over each
other and memory corruption is on the way. (as it seems that on the
maxsymsperkey memory allocation depends)

-- 
Lukáš Hejtmánek