Bug 491979

I'll add that "emacs -nw" does start, but lacking X support is huge.

$ rpm -q emacs
emacs-22.3-4.fc10.i386

On my Fedora 10 x86_64 system emacs-22.3-4.fc10.x86_64 seems to be working fine in this regard. Can you run it in gdb, and hit Ctrl+C to generate a backtrace? The strace output (strace -oslog emacs) might also be helpful.

On my Fedora 10 installation the xterm from which I start emacs clearly thinks that the application is running fine; I can move it from foreground to background, etc, but it simply does not display. It seems not to show any error messages when it is started or closed. I also find that emacs -nw is more or less normal. 

Uninstalling and reinstalling emacs from the repository changed nothing.

Please try with emacs -Q

(In reply to comment #3)
> On my Fedora 10 installation the xterm from which I start emacs clearly thinks
> that the application is running fine; I can move it from foreground to
> background, etc, but it simply does not display. It seems not to show any error
> messages when it is started or closed. I also find that emacs -nw is more or
> less normal. 

Can you please provide a strace log:
$ strace -oslog emacs
...
...
<Ctrl+C>
$

Attach slog to this bug report.

In case you do not have strace installed:
# yum -y install strace

Also do you have SELinux in enforcing mode?

(In reply to comment #4)
> Please try with emacs -Q  

The window appeared almost instantly.

Since '-Q' is equivalent '-q --no-site-file --no-splash', can you please run 'emacs' with the options turned on individually. eg.,
$ emacs -q
$ emacs --no-site-file
$ emacs --no-splash

Strace logs and GDB backtraces for the failed cases would be highly appreciated. Also do you have SELinux in enforcing mode? If yes, can you set it to permissive? Did you encounter any AVC denials?

(In reply to comment #7)
> Since '-Q' is equivalent '-q --no-site-file --no-splash', can you please run
> 'emacs' with the options turned on individually. eg.,
> $ emacs -q
> $ emacs --no-site-file
> $ emacs --no-splash
> 
> Strace logs and GDB backtraces for the failed cases would be highly
> appreciated. Also do you have SELinux in enforcing mode? If yes, can you set it
> to permissive? Did you encounter any AVC denials?  

SELinux is already in permissive mode.

emacs -q             -- worked
emacs --no-site-file -- worked
emacs --no-splash    -- worked

Not sure what happened, but after doing the "emacs -Q" emacs is now seems to be starting up every time.

In reply to question: trying "emacs -Q" and "emacs -q" does not result in any change in emacs behaviour on my system; emacs starts but produces no screen UI

emacs -Q didn't do anything for me.

Attached are an strace and a recent piece of my yum.log, because emacs hasn't changed on my system in quite some time, though libX11 and gtk2 did yesterday.

I have restarted since the libX11 upgrade.

From the strace it appears emacs is hanging on a pipe to /tmp/.X11-unix/X0...

--
socket(PF_FILE, SOCK_STREAM, 0)         = 4
connect(4, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"...}, 20) = 0
getpeername(4, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0\260\364\20\10\204E\3
7\10"...}, [20]) = 0
...
select(5, [4], [4], NULL, NULL)         = 1 (out [4])
writev(4, [{"\20\0\6\0\20\0\340\3WM_SAVE_YOURSELF"..., 24}], 1) = 24
select(5, [4], [], NULL, NULL)          = 1 (in [4])
read(4, "\1\0\211\0\0\0\0\0\245\1\0\0\0\0\0\0\30\0\0\0\0\0\0\0\2506x\t\0\0\0\0".
.., 4096) = 32
read(4, 0x9b2e1d4, 4096)                = -1 EAGAIN (Resource temporarily unavai
lable)
...
writev(4, [{"\30\1\6\0\20\0\340\3}\1\0\0z\1\0\0z\1\0\0\0\0\0\0"..., 24}], 1) = 2
4
select(5, [4], [], NULL, NULL
--

I'm still downloading debuginfo packages to get a reasonable stack trace.

Created attachment 336639 [details]
strace of emacs -Q

Created attachment 336640 [details]
Recent package changes

Created attachment 336641 [details]
result of "strace -o slog emacs" as requested

note that I could not kill strace with ^C; I had to suspend it and use kill.

Created attachment 336642 [details]
strace log following failure of "emacs -q" to create UI

Created attachment 336644 [details]
strace log from "emacs --no-site-file" which failed to open UI

Note that SELinux is in permissive mode on my machine.

I don't know what an AVC denial is, but I do not recall any mention of this in error messages.

Created attachment 336645 [details]
gdb emacs, r -Q, bt

Created attachment 336647 [details]
strace log following failure of "emacs --no-splash" to open a UI

Downgrading libX11 to libX11-1.1.4-6.fc10.i386.rpm appears to be a workaround. At this point I'm not sure if this is a bug in libX11, emacs or both. I'm hoping the emacs maintainer can figure that out and file a bug against libX11 if appropriate.

I am trying to get a trace of emacs using gdb. I have downloaded necessary debug info for my distribution of emacs as requested by gdb. 

"gdb emacs" produces no output except the usual start-up stuff. Is there any particular command I should try executing within gdb?

(In reply to comment #18)
> Downgrading libX11 to libX11-1.1.4-6.fc10.i386.rpm appears to be a workaround.
> At this point I'm not sure if this is a bug in libX11, emacs or both. I'm
> hoping the emacs maintainer can figure that out and file a bug against libX11
> if appropriate.  

I have a result that may help clarify that. I have a "private" installation of xmgrace on my machine (the Fedora downloaded version stopped working some weeks ago after an earlier upgrade, so I compiled a version from sources in my own home directory as a workaround). This xmgrace worked perfectly until the 23rd, and I am almost certain that it failed as a result of the same X11 upgrade as killed emacs. When xmgrace hangs and I kill it manually, it does give an error message: "XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
      after 3994 requests (3994 known processed) with 356 events remaining." I don't know if this is specifically helpful, but it does point to a bug in the X11 libraries rather than to a bug in emacs.

This is not only affecting Emacs -- it is also affecting:

* xmms
* xterm

Same behavior -- when launching as a non-privileged user, the program appears to get stuck in an EAGAIN loop waiting on reads to file descriptor 3, which is illustrated by these snippets:

xterm-strace.log - snippet:

connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"...}, 20) = 0
getpeername(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"...}, [20]) = 0
uname({sys="Linux", node="ghanima.liggettron.com", ...}) = 0
access("/var/run/gdm/auth-for-cliggett-66VHNM/database", R_OK) = 0
open("/var/run/gdm/auth-for-cliggett-66VHNM/database", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0600, st_size=67, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f4c000
read(4, "\1\0\0\26ghanima.liggettron.com\0\0010\0\22MI"..., 4096) = 67
read(4, ""..., 4096)                    = 0
close(4)                                = 0
munmap(0xb7f4c000, 4096)                = 0
fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
select(4, [3], [3], NULL, NULL)         = 1 (out [3])
writev(3, [{"l\0\v\0\0\0\22\0\20\0"..., 10}, {"\0\0"..., 2}, {"MIT-MAGIC-COOKIE-1"..., 18}, {"\0\0"..., 2}, {"P\331\rj\2555\256\243D\r\352\263\0\371ax"..., 16}, {""..., 0}], 6) = 48
read(3, "\1\0\v\0\0\0E\0"..., 8)        = 8
read(3, "XC\240\0\0\0\200\4\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0  \10\377T\236\37\10T"..., 276) = 276
select(4, [3], [3], NULL, NULL)         = 1 (out [3])
writev(3, [{"7\0\5\0\0\0\200\4\235\0\0\0\10\0\0\0\377\377\377\0b\0\5\0\f\0\0\0BIG-R"..., 40}], 1) = 40
select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "\1\0\2\0\0\0\0\0\1\202\0\0\0\0\0\0\24\0\0\0\0\0\0\0\0304\220\t\0\0\0\0"..., 4096) = 32
select(4, [3], [3], NULL, NULL)         = 1 (out [3])
writev(3, [{"\202\0\1\0"..., 4}], 1)    = 4
select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "\1\0\3\0\0\0\0\0\377\377?\0\0\0\0\1\0\0\0\0\0304\220\t\0\0\0\0\270.\37\10"..., 4096) = 32
select(4, [3], [3], NULL, NULL)         = 1 (out [3])
writev(3, [{"\24\0\6\0\235\0\0\0\27\0\0\0\37\0\0\0\0\0\0\0\0\341\365\5"..., 24}], 1) = 24
select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "\1\10\4\0&\0\0\0\37\0\0\0\0\0\0\0\227\0\0\0\200\263!\10H\25\241\277\231#\25\10X"..., 4096) = 184
read(3, 0x966b9dc, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [3], NULL, NULL)         = 1 (out [3])
writev(3, [{"b\0\5\0\t\0\0\0XKEYBOARD\0\0\0"..., 20}], 1) = 20
select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "\1\0\5\0\0\0\0\0\1\225c\243\0\0\0\0\24\0\0\0\0\0\0\0\0304\220\t\0\0\0\0"..., 4096) = 32
read(3, 0x966b9dc, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [3], NULL, NULL)         = 1 (out [3])
writev(3, [{"\225\0\2\0\1\0\0\0"..., 8}], 1) = 8

(In reply to comment #21)
> This is not only affecting Emacs -- it is also affecting:
> 
> * xmms
> * xterm

Please follow https://bugzilla.redhat.com/492085

After rebooting my laptop, emacs is again showing the original pathology. I'm going to post the appropriate strace logs now.

(In reply to comment #22)
> (In reply to comment #21)
> > This is not only affecting Emacs -- it is also affecting:
> > 
> > * xmms
> > * xterm
> 
> Please follow https://bugzilla.redhat.com/492085  

When I start xterm I get complains(In reply to comment #22)
> (In reply to comment #21)
> > This is not only affecting Emacs -- it is also affecting:
> > 
> > * xmms
> > * xterm
> 
> Please follow https://bugzilla.redhat.com/492085  

Should this be marked as a duplicate of 492085?

492085 has been closed as a dupe of 491813. Closing this as a dupe of 491813 - please put further detail there.

*** This bug has been marked as a duplicate of bug 491813 ***

Following the release of the latest version of the X11 libraries, this bug has vanished from my computer. Both emacs and xmgrace appear to run perfectly normally. THANK YOU VERY MUCH to the person or persons who found the problem and fixed it.