Comment 2 for bug 931397

Revision history for this message
Peter Wu (lekensteyn) wrote :

Another setting that makes Xorg segfault is AutoEnableDevices "false". All these settings
have one common behavior: it xf86ConfigLayout.inputs to contain a list of devices.

In xf86Init.c:809 InitInput(), the loop is executed if the above condition (Auto*Devices
false) holds. An excerpt:
 808 /* Initialize all configured input devices */
 809 for (pInfo = xf86ConfigLayout.inputs; pInfo && *pInfo; pInfo++) {
 810 (*pInfo)->options = xf86AddNewOption((*pInfo)->options, "driver", (*pInfo)->driver);
 811 (*pInfo)->options = xf86AddNewOption((*pInfo)->options, "identifier", (*pInfo)->name);
 812 /* If one fails, the others will too */
 813 if (NewInputDeviceRequest((*pInfo)->options, NULL, &dev) == BadAlloc)
 814 break;
 815 }

Line 813 is the one to pay attention to. It passes xf86ConfigLayout.inputs->options to
NewInputDeviceRequest. This seems to be a XF86OptionPtr:
(gdb) print *(XF86OptionPtr)xf86ConfigLayout.inputs->options
$1 = {list = {next = 0x555555a17910}, opt_name = 0x555555a179a0 "CorePointer", opt_val = 0x555555a17980 "on", opt_used = 0, opt_comment = 0x0}

NewInputDeviceRequest expects an InputOption * which will look like:
(gdb) print *(InputOption*)xf86ConfigLayout.inputs->options
$2 = {key = 0x555555a17910 "@z\241UUU", value = 0x555555a179a0 "CorePointer", next = 0x555555a17980}
That's exactly the garbage that I got in the report. What's more important, what change
caused this? Xorg -configure segfaults as well, though I'm not sure if it's related to
this issue.