Okay if I understand this correctly, X is going through its usual Wakeup handling, and one of the input extensions tries to write a message to the log, however something is wrong and in trying to free a string (maybe the tmpBuf in LogVMessageVerb?) it crashes. Then, I guess it is trying to write this backtrace to the log but of course can't do that, and I guess this triggers the heap corruption?
This seems to be an unusually severe crash, it's not surprising apport had trouble with it. If there's any way we can get a full backtrace, it would help fill in some of the gaps in this understanding.
Would it be possible for you to run X in gdb with a break on xf86Wakeup(), and step through the lines in that routine to see which line leads to the crash?
Okay if I understand this correctly, X is going through its usual Wakeup handling, and one of the input extensions tries to write a message to the log, however something is wrong and in trying to free a string (maybe the tmpBuf in LogVMessageVerb?) it crashes. Then, I guess it is trying to write this backtrace to the log but of course can't do that, and I guess this triggers the heap corruption?
This seems to be an unusually severe crash, it's not surprising apport had trouble with it. If there's any way we can get a full backtrace, it would help fill in some of the gaps in this understanding.
Would it be possible for you to run X in gdb with a break on xf86Wakeup(), and step through the lines in that routine to see which line leads to the crash?