Bugzilla – Full Text Bug Listing
| Summary: | java.io.IOException: Cannot create pty | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Jens Seidel <jensseidel> |
| Component: | cdt-core | Assignee: | Project Inbox <cdt-core-inbox> |
| Status: | RESOLVED INVALID | QA Contact: | Doug Schaefer <cdtdoug> |
| Severity: | normal | ||
| Priority: | P3 | CC: | aleherb+eclipse, marc.khouzam |
| Version: | 8.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Jens Seidel
*** Bug 350426 has been marked as a duplicate of this bug. *** This is affecting DSF-GDB also, except that we don't have a log printout of the error. This works for me on FC13 x86_64. In bug 350426 comment 5 you mentioned a possible reason: > The problem occurs in a chroot Linux session, do I have to mount something such > as devpts on /chroot/dev/pts to get ptys? Seems I haven't ... Have you tried this? I think you need to investigate it yourself, maybe with strace. (In reply to comment #3) > This works for me on FC13 x86_64. > > In bug 350426 comment 5 you mentioned a possible reason: > > > The problem occurs in a chroot Linux session, do I have to mount something such > > as devpts on /chroot/dev/pts to get ptys? Seems I haven't ... > > Have you tried this? > I think you need to investigate it yourself, maybe with strace. I remounted indeed /proc, /dev (via mount option bind) and /sys (but excluded /dev/pts in the chroot) and debugging still did not work. But please note that I have seen "out of pty" no longer since weeks. Since I was also installing Eclipse on another notebook I verified that debugging causes there also problems. These seem to be gdb related. See Bug #350426 Comment #9. This system is a native one, no chroot involved. I tried to debug it again also in the chroot after remounting it (and not starting ressource intensive processes such as firefox) and have still problems. But the problem changed! Now the debugger outputs: 850,735 14^error,msg="Warning:\nCannot insert breakpoint 1.\nError accessing memory address 0x7b9: E\ ingabe-/Ausgabefehler.\n" (This is different to the log in attachment of Bug #198645). So it seems the original problem vanished and was replaced by another gdb specific issue. I didn't noticed it from beginning as the symptoms are similar: debugging is not possible. PS: The source uses heavy template instanciations. (In reply to comment #4) > (This is different to the log in attachment of Bug #198645). Sorry, I mean attachment #1 [details] in #350426 (In reply to comment #4) > I remounted indeed /proc, /dev (via mount option bind) and /sys (but excluded > /dev/pts in the chroot) and debugging still did not work. But please note that > I have seen "out of pty" no longer since weeks. So, this specific error "Cannot create PTY" does no longer occur? Then I'd suggest to close this bug and continue with a debugger specific bug report, maybe reopen bug 350426. (In reply to comment #6) > (In reply to comment #4) > > I have seen "out of pty" no longer since weeks. > > So, this specific error "Cannot create PTY" does no longer occur? Then I'd > suggest to close this bug and continue with a debugger specific bug report, > maybe reopen bug 350426. Marc should decide. I do no longer find "Cannot create PTY" in my logs (only twice two weeks ago) but he thinks it is the same problem. Once I use clang++ instead of g++ (with same flags, same breakpoints) I do no longer get the "Cannot insert breakpoint" error but again the previous behaviour of Bug #350426: The output of the debugger and my program are mixed, both on the gdb traces and the myApplication console. PS: There exists /proc/sys/kernel/pty/max which is set to 4096 on my system. I raised it to 10240 but see no change. Maybe you can reproduce this problem by lowering it? PS2: Often I'm also affected by either #Bug 349283 or #Bug 349284. Is there a relation? (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #4) > > > I have seen "out of pty" no longer since weeks. > > > > So, this specific error "Cannot create PTY" does no longer occur? Then I'd > > suggest to close this bug and continue with a debugger specific bug report, > > maybe reopen bug 350426. > > Marc should decide. I do no longer find "Cannot create PTY" in my logs (only > twice two weeks ago) but he thinks it is the same problem. I just read Marc's comment: > When you were using CDI, there was a printout indicating that the PTY was not > created. Now that you are using DSF, there is no printout, but I'm guessing we > are having the same problem and hitting an exception at > StartOrRestartProcessSequence_7_0:287 So it seems DSF does not log this error but it might still be the same issue. I'd suggest to strace the JVM process if open("/dev/ptmx") succeeds. (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #4) > > > > I have seen "out of pty" no longer since weeks. > I just read Marc's comment: > > When you were using CDI, there was a printout indicating that the PTY was not > > created. Now that you are using DSF, there is no printout, but I'm guessing we > > are having the same problem and hitting an exception at > > StartOrRestartProcessSequence_7_0:287 > > So it seems DSF does not log this error but it might still be the same issue. > I'd suggest to strace the JVM process if open("/dev/ptmx") succeeds. Did so: strace -p 8711 -tt -e trace=open -f -o jvm.open There is no attempt to open "/dev/ptmx", found only $ grep -r /dev/ jvm.open 22362 15:07:52.904478 open("/dev/ptyp0", O_RDWR) = -1 ENOENT (No such file or directory) 22398 15:07:52.927923 open("/dev/tty", O_RDWR|O_NONBLOCK) = 3 22401 15:08:15.494146 open("/dev/ptyp0", O_RDWR) = -1 ENOENT (No such file or directory) 22433 15:08:15.517470 open("/dev/tty", O_RDWR|O_NONBLOCK) = 3 22435 15:09:07.525142 open("/dev/ptyp0", O_RDWR) = -1 ENOENT (No such file or directory) 22467 15:09:07.552293 open("/dev/tty", O_RDWR|O_NONBLOCK) = 3 The process now even fails to start. I tried to start the debugger multiple times and always get now using strace: eclipse.buildId=I20110613-1736 java.version=1.6.0_20 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Framework arguments: -product org.eclipse.epp.package.linuxtools.product Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.linuxtools.product Error Mon Jul 04 15:09:08 CEST 2011 Error in final launch sequence org.eclipse.core.runtime.CoreException: Failed to execute MI command: -exec-run Error message from debugger back end: During startup program exited normally. at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:114) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:206) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:96) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:85) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:854) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:703) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:928) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1132) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: java.lang.Exception: During startup program exited normally. at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:885) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:716) and at the beginning a single time: Error Mon Jul 04 15:05:52 CEST 2011 Error in final launch sequence org.eclipse.core.runtime.CoreException: Connection is shut down at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:114) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:206) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:96) at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:85) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:854) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:703) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:928) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1132) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Using clang++ the problem during debugging is clearly Eclipse fault. Using gdb directly works well. Changing std::flush to std::endl avoids the trouble as well as new lines are introduced. (In reply to comment #9) > Did so: > > strace -p 8711 -tt -e trace=open -f -o jvm.open > > There is no attempt to open "/dev/ptmx" You are right, this seems to be problem with strace. However, I do see the call to open("/dev/ptmx") when I start eclipse with strace. (In reply to comment #10) > (In reply to comment #9) > > Did so: > > > > strace -p 8711 -tt -e trace=open -f -o jvm.open > > > > There is no attempt to open "/dev/ptmx" > > You are right, this seems to be problem with strace. However, I do see the > call to open("/dev/ptmx") when I start eclipse with strace. I tried it two further times and see now "/dev/ptmx" as well: After adding a symlink from /dev/ptyp0 to /dev/ptmx: jvm.open2:26719 15:46:32.882840 open("/dev/ptmx", O_RDWR) = 124 jvm.open2:26719 15:46:32.882995 open("/dev/ptyp0", O_RDWR) = 124 jvm.open2:26752 15:46:32.937304 open("/dev/tty", O_RDWR|O_NONBLOCK) = 3 jvm.open2:26753 15:47:14.510399 open("/dev/ptyp0", O_RDWR) = 59 jvm.open2:26786 15:47:17.687544 open("/dev/tty", O_RDWR|O_NONBLOCK) = 3 Why is /dev/tty opened? Could this be the problem? After removing the symlink: jvm.openWithoutLink:26863 15:50:02.245834 open("/dev/ptmx", O_RDWR) = 110 jvm.openWithoutLink:26863 15:50:02.245972 open("/dev/ptyp0", O_RDWR) = -1 ENOENT (No such file or directory) jvm.openWithoutLink:26896 15:50:02.310194 open("/dev/tty", O_RDWR|O_NONBLOCK) = 3 jvm.openWithoutLink:26900 15:50:21.506071 open("/dev/ptyp0", O_RDWR) = -1 ENOENT (No such file or directory) jvm.openWithoutLink:26933 15:50:23.257289 open("/dev/tty", O_RDWR|O_NONBLOCK) = 3 The behaviour of the debugger is always the same. (In reply to comment #11) > jvm.open2:26719 15:46:32.882840 open("/dev/ptmx", O_RDWR) = 124 > jvm.open2:26719 15:46:32.882995 open("/dev/ptyp0", O_RDWR) = 124 /dev/ptyp0 is an old name for the pty master. I believe that something is wrong with /dev/ptmx and the clib function getpt() trys /dev/ptyp0 as fallback. Can you use "script" or "screen" in your chrooted Linux? (In reply to comment #12) > (In reply to comment #11) > > jvm.open2:26719 15:46:32.882840 open("/dev/ptmx", O_RDWR) = 124 > > jvm.open2:26719 15:46:32.882995 open("/dev/ptyp0", O_RDWR) = 124 > > /dev/ptyp0 is an old name for the pty master. Right. > I believe that something is wrong > with /dev/ptmx and the clib function getpt() trys /dev/ptyp0 as fallback. > Can you use "script" or "screen" in your chrooted Linux? Don't know what you mean. I use screen all the time (and start eclipse, ... from it) but what should I do? Thanks for the getpt() hint: $ cat test.c #define _GNU_SOURCE /* See feature_test_macros(7) */ #include <stdlib.h> #include <stdio.h> #include <errno.h> #include <string.h> int main() { printf("errno: %d\n", errno); int ret = getpt(); printf("Return value: %d\n", ret); printf("errno: %d, %s\n", errno, strerror(errno)); if (ret != -1) close(ret); return ret; } $ gcc test.c -o getpt $ ./getpt errno: 0 Return value: -1 errno: 2, No such file or directory $ strace ./getpt execve("./getpt", ["./getpt"], [/* 33 vars */]) = 0 brk(0) = 0x1e39000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f07c1f8f000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=109506, ...}) = 0 mmap(NULL, 109506, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f07c1f74000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\356\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1453376, ...}) = 0 mmap(NULL, 3561608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f07c1a0d000 mprotect(0x7f07c1b69000, 2097152, PROT_NONE) = 0 mmap(0x7f07c1d69000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c000) = 0x7f07c1d69000 mmap(0x7f07c1d6e000, 18568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f07c1d6e000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f07c1f73000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f07c1f72000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f07c1f71000 arch_prctl(ARCH_SET_FS, 0x7f07c1f72700) = 0 mprotect(0x7f07c1d69000, 16384, PROT_READ) = 0 mprotect(0x600000, 4096, PROT_READ) = 0 mprotect(0x7f07c1f90000, 4096, PROT_READ) = 0 munmap(0x7f07c1f74000, 109506) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f07c1f8e000 write(1, "errno: 0\n", 9errno: 0 ) = 9 open("/dev/ptmx", O_RDWR) = 3 statfs("/dev/pts", {f_type=0x1021994, f_bsize=4096, f_blocks=2560, f_bfree=2339, f_bavail=2339, f_files=256787, f_ffree=255072, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0 statfs("/dev/", {f_type=0x1021994, f_bsize=4096, f_blocks=2560, f_bfree=2339, f_bavail=2339, f_files=256787, f_ffree=255072, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0 close(3) = 0 open("/dev/ptyp0", O_RDWR) = -1 ENOENT (No such file or directory) write(1, "Return value: -1\n", 17Return value: -1 ) = 17 write(1, "errno: 2, No such file or direct"..., 36errno: 2, No such file or directory ) = 36 exit_group(-1) = ? Now after mount -t devpts none chroot/dev/pts/ ./getpt errno: 0 Return value: 3 errno: 0, Success So it was indeed my problem of not mounting /dev/pts/. I feel so silly! As I wrote I tried the same on another host where the debugger also failed, but this was probably (now verified) the gdb bug (Comment #4). I suggest you check the return value of getpt() and log an possible error with the hint to mount /dev/pts :-)) (In reply to comment #12) > Can you use "script" or "screen" in your chrooted Linux? Ah, you mean just using it? No, you're right, not without /dev/pts: $ LANG=C script openpty failed Beendet :-)) (In reply to comment #13) > I suggest you check the return value of getpt() and log an possible error with > the hint to mount /dev/pts :-)) Better error reporting is certainly desirable, however, there can be a variety of reasons why creating the PTY fails. Anyway, thanks for your investigations. I'll close this bug and create another one about improving the error reporting (bug 351267). (And, of course, DSF-GDB should not silently swallow the exception.) |