Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: This problem surfaced in relation to bug 196337, but it can be reproduced with regular C/C++ Local Application launches on Solaris. It severely hinders the development of terminal-based applications with CDT on Solaris. To reproduce: 1. Create and run a C/C++ Local Application launch that launches "/bin/bash -i" (make sure that "Connect process input/output to a terminal" is enabled) 2. As the standard console will not pass Ctrl-C to the terminal, choose a different interrupt character: for example, use "@" by typing "stty intr @" at the shell prompt 3. Now use the cat command to copy from standard input to a file by typing "cat >testfile" at the prompt 4. To exit the "cat" program, type the interrupt character "@" followed by return (return is necessary because of line buffering) ==> Problem #1: cat should terminate because the "@" character should trigger an interrupt equivalent to Ctrl-C, but nothing happens 5. Terminate the "cat" program by ending the input with Ctrl-D (which signals the end of input and does get passed on by the console view) ==> Problem #2: instead of just terminating the "cat" program the shell itself also gets terminated by the Ctrl-D I believe the root of the problem is related to the session set-up in exec_pty.c, line 99 (see http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core.solaris/library/exec_pty.c?annotate=1.5&root=Tools_Project#l99): setpgid(getpid(), getpid()); The process is made a process group leader but the session is never registered with the terminal API. Line 99 should probably read: tcsetpgrp(STDIN_FILENO, setsid()); I tried this modification but it caused trouble when calling stty, because whereas stdin and stdout are connected to a proper terminal, stderr is connected to a pipe (see line 86), which is not a terminal. When I removed the pipe and redirected stderr directly to the pseudo-terminal's slave device, problem #1 (process interruption) went away. As a negative side effect I noticed that the console coloring for stdout and stderr got sometimes mixed up. Problem #2 (Ctrl-D terminating not only the active process but also the parent shell) still persisted after my change. I am mainly working on Solaris so I don't know whether this sort of problem affects other platforms as well. I started using the CDT Spawner for bug 196337, but the above described problem prevents local terminals from behaving correctly under Solaris. Developers working on terminal-based applications for Solaris will also be affected by this issue.
Created attachment 150767 [details] Patch with proposed fix. The main feature of this patch is a new "console" option to the PTY class. It tells it whether the PTY is to be used with the console view. If console==true, the current PTY behavior is preserved (i.e. the PTY is configured for no echo), otherwise the PTY is configured for standard behavior. The PTY.isConsole() flag is also used by Spawner.exec2(), which if console==true, redirects process's stderr to a pipe as is done now (otherwise it redirects it to the PTY). The second feature is PTY.setTerminalSize(), which allows PTY master owner to update the terminal size. The patch does not include binaries, which will need to be built and committed for each platform.
Thanks for submitting that, Pawel. I hope it gets integrated into the Eclipse code base very promptly, as it would enable us to finish the last couple of steps for bug 196337, so that local terminal access works reasonably. I originally filed this bug against Solaris, but of course we need to address it for Linux, too. Perhaps we should reset this bug's Platform attribute to All?
Created attachment 150778 [details] Build libraries for linux-x86 platform.
Created attachment 150884 [details] Updated patch with warnings fixes. This patch adds fixes from bugs: bug 82744, bug 145737, bug 237611, bug 272364, bug 272370, bug 272373.
Created attachment 150885 [details] Updated binaries for linux.x86
(In reply to comment #4) > Created an attachment (id=150884) [details] > Updated patch with warnings fixes. > This patch adds fixes from bugs: bug 82744, bug 145737, bug 237611, bug 272364, > bug 272370, bug 272373. Pawel, I think the patch is incomplete. I don't see the changes from those bugs and the patch also does not seem to address the original problems from comment 0. I tried the attached linux binaries with the process connector plug-in from bug 196337, but this did not work very well for me. I connected to 'sh' but there was no echo and output was distorted.
(In reply to comment #6) > I don't see the changes from those bugs and the patch also does not seem to > address the original problems from comment 0. Correction: It looks like the changes from those bugs are included, but some files are missing in the patch.
(In reply to comment #7) > Correction: It looks like the changes from those bugs are included, but some > files are missing in the patch. Yes, I noticed this last night as well when I tried to apply the patch in a new workspace. I'll re-generate the patch when I get back to Linux. (In reply to comment #6) > I tried the attached linux binaries with the process connector plug-in from bug > 196337, but this did not work very well for me. I connected to 'sh' but there > was no echo and output was distorted. That's a bummer. I've been testing with /bin/bash and it looked pretty good. I'll try 'sh' as well.
Created attachment 150946 [details] Binaries for win32.x86.
Created attachment 150950 [details] Updated patch with complete file set and aix. Seems that I also forgot about aix...
(In reply to comment #6) > I tried the attached linux binaries with the process connector plug-in from bug > 196337, but this did not work very well for me. I connected to 'sh' but there > was no echo and output was distorted. I tried 'sh' and it worked for me as well as bash. Do you see any errors about the PTY library loading? Are you able to debug PTY and see if the library does get loaded?
(In reply to comment #11) > > I tried 'sh' and it worked for me as well as bash. Do you see any errors about > the PTY library loading? Are you able to debug PTY and see if the library does > get loaded? Note that sh is often just a symlink to bash. Do you both have a similar configuration in that respect?
(In reply to comment #12) > Note that sh is often just a symlink to bash. Do you both have a similar > configuration in that respect? For me (on Ubuntu 8.04) it's actually a link to dash. In either case though, if there was no echo there must have been a more serious problem... as in the PTY didn't get created.
(In reply to comment #13) > (In reply to comment #12) > > Note that sh is often just a symlink to bash. Do you both have a similar > > configuration in that respect? > For me (on Ubuntu 8.04) it's actually a link to dash. In either case though, > if there was no echo there must have been a more serious problem... as in the > PTY didn't get created. The libpty.so cannot be loaded. I get an UnsatisfiedLinkError: Error: .../org.eclipse.cdt.core.linux.x86/os/linux/x86/libpty.so: Can't load IA 32-bit .so on a IA 32-bit platform The same happens with the libspawner.so. When I build the libraries locally, it works. This is on RHEL WS 4 (Update 8). I'll attach the libraries from my workspace.
Created attachment 151409 [details] linux.x86 binaries built on RHEL WS 4
Created attachment 151685 [details] solaris.sparc binaries built on Solaris 9
Created attachment 151698 [details] Complete source patch with @since tags, javadoc and cosmetics This patch adds @since tags and javadoc to new API in PTY.java, includes the win32 changes and some cosmetics.
CQ:WIND00199002 - scheduled for CDT 7.0m6 Since we don't have a Mac available at Wind River, we will need some Community help for creating spawner binaries and testing on the Mac. Any voluneers?
I applied Toni's patch and rebuilt the natives on Mac OS. Unfortunately the problem, as described in comment 0, is still there. Running through the steps works in a native shell, but fails in a run launch. I verified that the java was picking up my newly built lib with lsof, and have clean'ed, etc. Furthermore if I press ctrl-D Eclipse locks up (the native call doesn't appear to return). This happens with or without the patch: java.lang.Thread.State: RUNNABLE at org.eclipse.cdt.utils.spawner.SpawnerOutputStream.close0(Native Method) at org.eclipse.cdt.utils.spawner.SpawnerOutputStream.close(SpawnerOutputStream.java:73) at org.eclipse.debug.internal.core.InputStreamMonitor.closeInputStream(InputStreamMonitor.java:151) at org.eclipse.debug.internal.core.StreamsProxy.closeInputStream(StreamsProxy.java:120)
(In reply to comment #19) > I applied Toni's patch and rebuilt the natives on Mac OS. Unfortunately the > problem, as described in comment 0, is still there. Running through the steps > works in a native shell, but fails in a run launch. I verified that the java > was picking up my newly built lib with lsof, and have clean'ed, etc. I assume you were trying this out from the Eclipse Console. I don't think we can solve the Eclipe console problems and it's not a real terminal. This patch is mainly to enable a real terminal (from the TM project) to re-use the CDT spawner. Would you be able to try the TM terminal connector from bug 196337? BTW, if it's a popular feature, we could try to use the TM terminal for CDT's GDB integration. This at least would give a better use case for fixing this bug.
Created attachment 158151 [details] Mac OS patch I noticed that the Mac OS code does not seem to make the tty the controlling terminal. This might be the reason why you still see the problems in comment 0. Could you try again with this patch? I have no explanation for the blocking native call. It just does a close(fd).
(In reply to comment #21) > Could you try again with this patch? Thanks Toni. Unfortunately no luck still. The patch has made a difference - now if I run bash as a run launch, it exits immediately with "return code -1". In the debugger the behaviour seems to the same as the existing jnilibs.
Created attachment 158730 [details] Mac OS second try There was also a setsid() call missing. Could you try once more? This time I am quite confident, otherwise I need a Mac...
(In reply to comment #23) > Created an attachment (id=158730) [details] > Mac OS second try > > There was also a setsid() call missing. Could you try once more? This time I > am quite confident, otherwise I need a Mac... It's a bit better Toni, the echo'ing seems to have disappeared. Sadly trying "stty int @" givens an error: bash-3.2$ stty intr @ bash: [11283: 1] tcsetattr: Inappropriate ioctl for device [1]+ Stopped stty intr @ bash-3.2$ Is this expected?
(In reply to comment #24) > It's a bit better Toni, the echo'ing seems to have disappeared. Sadly trying > "stty int @" givens an error: Sorry, that's actually a run launch. In the debugger it looks similar to before: bash-3.2$ stty intr @ stty intr @ bash-3.2$ cat > foo cat > foo @ @
(In reply to comment #24) > (In reply to comment #23) > > Created an attachment (id=158730) [details] [details] > > Mac OS second try > > > > There was also a setsid() call missing. Could you try once more? This time I > > am quite confident, otherwise I need a Mac... > > It's a bit better Toni, the echo'ing seems to have disappeared. Sadly trying > "stty int @" givens an error: > > bash-3.2$ stty intr @ > bash: [11283: 1] tcsetattr: Inappropriate ioctl for device > > [1]+ Stopped stty intr @ > bash-3.2$ > > Is this expected? Thanks for trying again. This error is due to the fact that in console mode stderr is not associated with the tty (Mirko mentioned this already in comment#0). I concentrated my test on the real tty mode in the terminal view so that I missed that problem (which exists on linux and solaris too). I guess in console mode we need to keep the setpgid() call instead of the setsid() to restore the current behavior.
Created attachment 158976 [details] Mac OS last try James, could you give this patch one more try? This should keep the current behavior for console mode, i.e. all limitations of comment#0 are still present, but there should be no regression. I built and tested on linux-x84, linux-x86_64 and solaris-sparc and verified that it works there.
(In reply to comment #27) > James, could you give this patch one more try? I have done, and the issue in comment 24 is gone. Unfortunately, even using the local program connector from bug 196337, I'm unable to make it handle crtl-C or some other set interrupt signal. In fact the behaviour seems equivalent to the currently checked in mac os x libs :s
(In reply to comment #28) > (In reply to comment #27) > > James, could you give this patch one more try? > > I have done, and the issue in comment 24 is gone. Phew. > Unfortunately, even using the local program connector from bug 196337, I'm > unable to make it handle crtl-C or some other set interrupt signal. In fact > the behaviour seems equivalent to the currently checked in mac os x libs :s If you tried with Mirko's latest patch, this is to be expected. It does not yet use the new API. It should work with Pawel's local program connector, though. I just noticed that Pawel's "Updated terminal process plugin" attachment is actually a CDT patch, but you can use the obsoleted attachment at https://bugs.eclipse.org/bugs/attachment.cgi?id=150775 instead. Thanks for your patience!
Created attachment 159125 [details] Mac OS 'last try' binaries (In reply to comment #29) > Thanks for your patience! Phew, looks good using Pawel's Process connection type. Binaries attached, built on 10.6.2: Macintosh-9:os james$ gcc -v Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/usr/include/c++/4.2.1 --host=i686-apple-darwin10 --target=i686-apple-darwin10 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)
Thanks for working on this guys! I didn't have a chance to try it out yet, but I'm looking forward to seeing your efforts become a part of Eclipse!
(In reply to comment #30) > Phew, looks good using Pawel's Process connection type. Excellent. I think we are finally ready to commit the changes and binaries for following platforms: - linux.x86 - linux.x86_64 - solaris.sparc - macosx - win32 All other platforms will stay unchanged and thus will not support the new API, but should still be functional as before, ie. the libraries should still link successfully (At least this is what I can confirm for linux and solaris). If anybody bothers to build and test for other platforms, please attach source patch and binaries ASAP.
(In reply to comment #32) > All other platforms will stay unchanged and thus will not support the new API, > but should still be functional as before Just wondering, what does "not support the new API" mean in practice? From a quick look at the code, it seems that a plain Java client which calls the new API PTY#setTerminalSize(int,int) on a Platform which still runs the old native libs will run into a NoSuchMethodError. I think that this should be documented as an @throws clause in the method's Javadoc. Catching the error and handling it somehow may be another option. Throwing an unchecked exception seems OK to me in the interest of keeping things simple, but I do think that the behavior on an unsupported PLatform should be documented.
(In reply to comment #33) > From a quick look at the code, it seems that a plain Java client which > calls the new API > > PTY#setTerminalSize(int,int) > > on a Platform which still runs the old native libs will run into a > NoSuchMethodError. I think that this should be documented as an @throws clause > in the method's Javadoc. Catching the error and handling it somehow may be > another option. This will cause an UnsatisfiedLinkError. I suggest to catch the error and log it once per session. > Throwing an unchecked exception seems OK to me in the interest of keeping > things simple, but I do think that the behavior on an unsupported PLatform > should be documented. I don't even know the state of current pty support on all different platforms, but I'll add a comment to setTerminalSize() and the new constructor.
Created attachment 159173 [details] Final source patch (Java + C) for linux, solaris and macosx
Created attachment 159174 [details] Binaries for linux (x86, x86_64) and solaris
Committed to HEAD. Special thanks to Mirko, Pawel and James.
(In reply to comment #37) > Committed to HEAD. > Special thanks to Mirko, Pawel and James. Thank you Toni! BTW, if bug 196337 is fixed in TM, CDT could support redirecting of debugee process output to a true terminal rather than the standard console.
I'm having trouble loading the CDT 7.0.0 M6 native library for this (I'm using Mac OS X 10.5.8): http://www.eclipse.org/forums/index.php?t=msg&th=166981 Please leave a comment if you have any insight on this. Thanks!
(In reply to comment #39) > I'm having trouble loading the CDT 7.0.0 M6 native library for this (I'm using > Mac OS X 10.5.8): > http://www.eclipse.org/forums/index.php?t=msg&th=166981 > Please leave a comment if you have any insight on this. Thanks! James built the libs on 10.6.2 (comment 30). Maybe that's the problem? You could try and build the libraries on your Mac. They should work on later version as well, I guess.
Created attachment 166435 [details] Mac OS 10.5.8 binaries Indeed, there seems to be a problem running Mac OS X 10.6 binaries on a 10.5 system. The 10.6 binaries contain a new 10.6-specfic load command, LC_DYLD_INFO_ONLY (0x80000022). I compiled the latest sources locally, replaced the *.jnilib files in org.eclipse.cdt.core.macosx_5.2.0.201003151310.jar, and restarted Eclipse with -clean, and the libraries were loaded without any problem. I assume that Mac OS 10.6 is fully backwards compatible and that the 10.5 libraries would also work on 10.6. If someone can verify that the attached libraries (compiled on 10.5.8) are fine on 10.6 as well then I would suggest to use the 10.5 binaries instead of the 10.6 ones.
On my Mac OS X 10.5.8 system, I see problem #2 (from comment #0) fixed, but not problem #1. Without redefining the interrupt character, when I press Command-C while executing the cat command I just see "^C" being printed to the terminal, but no interrupt being triggered. Similar, after issuing an "stty intr @", I just see "@" characters printed. I'm using the local terminal connector from bug 196337 with the patch for bug 310376. My terminal settings seem to be all right: bash-3.2$ stty -a speed 9600 baud; 0 rows; 0 columns; lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo -extproc iflags: -istrip icrnl -inlcr igncr ixon -ixoff ixany imaxbel iutf8 -ignbrk brkint -inpck -ignpar -parmrk oflags: opost onlcr -oxtabs -onocr -onlret cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>; eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; I also checked the signal handlers by sending SIGINTs manually. When I send a SIGINT to the shell itself nothing happens (not sure whether that's okay or not); when I send a SIGINT to the child process (i.e., cat) it terminates, but I get a warning like bash: [7244: 2] tcsetattr: Inappropriate ioctl for device The warning does not occur when sending SIGINT to other long-running processes (I ran a "find /" to test). In other words, on Mac OS 10.5.8 I still don't see full terminal functionality with the local terminal connector. Does anyone know how and where exactly a Ctrl-C key press is turned into an interrupt signal and what other tests would be helpful to debug why Ctrl-C doesn't work properly?
(In reply to comment #42) > bash: [7244: 2] tcsetattr: Inappropriate ioctl for device This would indicated that stderr is not connected to the pty. This is expected behavior in console (non-terminal) mode. Are you sure you have used PTY(false)?
(In reply to comment #43) > Are you sure you have used PTY(false)? Oops, my fault. Sorry for the false alarm. I had made the change, but in my launch configuration I accidentally picked up the bundle from the development platform, not from the workspace. So please disregard comment #42. I should probably stop working on this stuff so late at night ;-) However, it does look like the binaries shipped with CDT 7.0.0 M6 will only run on Mac OS 10.6. James (or someone else running 10.6), can you verify that the binaries that I supplied in attachment #166435 [details] also work on Mac OS 10.6? If they work I would suggest that we replace the current binaries with the 10.5 ones.
(In reply to comment #44) > James (or someone else running 10.6), can you verify that the binaries that I Thanks Mirko, I did some simple tests, and I can load and use the libraries fine on 10.6 x86. Have committed, should be part of Monday's M7 build.
*** cdt cvs genie on behalf of jblackburn *** Bug 248071 libraries rebuilt on Mac OS X 10.5, forward compatible with 10.6 [*] libspawner.jnilib 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core.macosx/os/macosx/x86_64/libspawner.jnilib?root=Tools_Project&r1=1.2&r2=1.3 [*] libpty.jnilib 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core.macosx/os/macosx/x86_64/libpty.jnilib?root=Tools_Project&r1=1.2&r2=1.3 [*] libspawner.jnilib 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core.macosx/os/macosx/x86/libspawner.jnilib?root=Tools_Project&r1=1.3&r2=1.4 [*] libpty.jnilib 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core.macosx/os/macosx/x86/libpty.jnilib?root=Tools_Project&r1=1.3&r2=1.4 [*] libspawner.jnilib 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core.macosx/os/macosx/ppc/libspawner.jnilib?root=Tools_Project&r1=1.5&r2=1.6 [*] libpty.jnilib 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core.macosx/os/macosx/ppc/libpty.jnilib?root=Tools_Project&r1=1.5&r2=1.6
