Bug 13815
Summary: | emacs -nw compilation doesn't show the error message | ||
---|---|---|---|
Product: | Drivers | Reporter: | Aneesh Kumar K.V (aneesh.kumar) |
Component: | Other | Assignee: | drivers_other |
Status: | CLOSED CODE_FIX | ||
Severity: | blocking | CC: | alan, rjw |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.31-rc3 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 13615 | ||
Attachments: | strace log showing buggy behaviour |
Caused by: commit d945cb9cce20ac7143c2de8d88b187f62db99bdc Author: Alan Cox <alan@linux.intel.com> Date: Tue Jul 7 16:39:41 2009 +0100 pty: Rework the pty layer to use the normal buffering logic First-Bad-Commit : d945cb9cce20ac7143c2de8d88b187f62db99bdc Hi All, I had private mails with Alan before filing this bugzilla report, and Alan is not able to reproduce the problem. So are other able to reproduce it. I am right now trying to do a small test case and see if i can get it reproduced. A small c program that i am doing is getting me the error contents on ptmx. So emacs is doing something more. So if others are able to reproduce that will be a positive sign that is is not just a problem with my setup. -aneesh I tried with a fedora 10 install and i can reproduce it there. steps to reproduce. ALT-x compile use cc -g a.c to compile if you get the error repeat the compile using recompile command to do that ATL-x recompile and keep doing that. 1 out of 3 tries result in dropping the error information. -aneesh This patch fixes the issue for me http://article.gmane.org/gmane.linux.kernel/869359 Fixed by commit e043e42bdb66885b3ac10d27a01ccb9972e2b0a3 . |
Created attachment 22461 [details] strace log showing buggy behaviour To reproduce write a small program something like below main() { printf("%d\n",i); } Now in emacs say ALT-x compile use cc a.c command to compile. It is supposed to show the error messages in the compile window. With 2.6.30 it works fine. Where as 2.6.31-rc3 it doesn't list me any error. Reverting the patch d945cb9cce20ac7143c2de8d88b187f62db99bdc makes it work. Doing an strace on the failure case shows me that on the parent we don't get woken up in select on /dev/ptmx immediately when the data is avaiable in /dev/pts/3. So the child exit and the select timeout and a read from /dev/ptmx return EIO. Relevant strace log is attached below -aneesh