| Summary: | [console] When PTY allocation fails ( on Windows ) the code NPEs | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Randy Rohrbach <Randy.Rohrbach> | ||||
| Component: | cdt-debug-dsf-gdb | Assignee: | Randy Rohrbach <Randy.Rohrbach> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | cdtdoug, dd.general-inbox, marc.khouzam, pawel.1.piech, Randy.Rohrbach | ||||
| Version: | 0 DD 1.0 | ||||||
| Target Milestone: | DD 1.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Randy Rohrbach
Created attachment 96488 [details]
PTY NPE fix for Windows
Committed the changes in the attach patch. Randy Marking fixed. Randy Mark Please see my explanations and fixes. I checked in this fix so it would work. I do not know your code real well, so perhaps there is a better way to do this. Please feel free to change anything and everything I did. It was getting in my way in terms of testing on Windows. I am sure it works fine on Linux. So please review my changes. Randy (In reply to comment #4) Thanks for dealing with this. I don't have a windows machine, so I can't try it. Would it be possible to send me the exception? I want to make sure we can redirect to a PTY on windows too. The CDT has a wrapper around the PTY, and maybe it is for windows? I'll investigate more. If you are not able to get the exception easily, please let me know and I'll try to get my hands on a windows machine. thanks With the latest changes I made to support bug 226931 the PTY code has completely changed. I tried to pay attention to this bug and I believe an exception would not cause an NPE anymore. Randy, can you verify? Thanks Mark I tried verifying this, there are no NPE's, but there is also no output. I would have expected the "Hello world" output to come out in my console - nothing. Also I set a breakpoint in initInferiorInputOutput() and it is not being called. So I cannot verify this at this time. I updated both CDT and DSF today ( 12:44PM EST ) to get the latest. randy (In reply to comment #7) > I tried verifying this, there are no NPE's, but there is also no > output. I would have expected the "Hello world" output to come > out in my console - nothing. This is probably due to the fact that GDB buffers the output and I believe we close the streams before it gets flushed. It is not a problem when we use a PTY but in your case it is a problem so I'll look into it. Can you try the same test with a CDT launch? You should see the output, but only once your program has stopped (or maybe a lot of output has been written.) If that is the case, then it is the because of the buffering (but we still have a bug ourselves). You can refer to bug 212916 for more details. > Also I set a breakpoint in initInferiorInputOutput() and it is not > being called. So I cannot verify this at this time. I assume that you are setting the breakpoint at the very start of initInferiorInputOutput()? It is strange that it does not stop... This method should be called by every launch, at the very start; and again, if you press the Restart button. Can you confirm? Thanks Re-opening to re-assign Re-assigning to Randy to fill some missing information I need to know before I can verify. Mark
So I rerun the DSF and CDT tests and here is what I see. For whatever reason the initInferior... is being called now. When the code goes to allocate a new PTY() it throws an exception. This is because the static initialization code below throws an exception when the class is loaded.
static {
try {
System.loadLibrary("pty"); //$NON-NLS-1$
hasPTY = true;
} catch (SecurityException e) {
// Comment out it worries the users too much
//CCorePlugin.log(e);
} catch (UnsatisfiedLinkError e) {
// Comment out it worries the users too much
//CCorePlugin.log(e);
}
}
So I do not have "pty" dll that is desired. This is also true when I run the CDT path. So there is no output in the console window period. Instead the difference is the that when the CDT is launched I get a DOS like output window in which the console IO shows up. When I launch DSF there is no suhc window.
I will try and locate./install the DLL and see how that works.
Randy
Mark I figured out where the pty comes from . it is part of the architecture specific jar files. So for example the org.eclipse.cdt.core.linux.x86...jar file contains a libpty.so file and this is where it is loaded for linux x86. Correspondingly the org.eclipse.cdt.core.win32.....jar file should have a pty dll in it. It does not. In checking the CDT build area there is simply no source for WIN32 versions. So PTY is not supported on WIN32. OK so far. but this seems to me to be a deficiency in the product. When the CDT launch fires up on WIN32 I get a DOS like window where the output does come out. It does not come to the Console window of course, but at least I can see it. When I launch DSF there is no such DOS like WINDOW and thus no output. There is also no indication that there has been an issue in startup ( e.g. to PTY available ). So I would think we would want to be similar to CDT in that we at least supply the DOS like output when the OPTY is not available. my .02$ worth Randy (In reply to comment #12) > So I would think we would want to be similar to CDT in that we at least supply > the DOS like output when the PTY is not available. Thanks Randy for the this info which I really needed. I agree with you that we need to support the case where no PTY is available, especially since we don't have one for WIN32. I will close this bug as we have fixed the NPE and the code properly recovers from a missing PTY library. I will open a new bug to track the fact that there is no output seen from the inferior if we don't have a PTY library. I believe this was the situation before I added the PTY logic: the inferior never reached the console. I've reassigned the bug to you to verify. Thanks Fixed. Opened bug 231883 to track the needed support for console printing when a PTY is not available. Closing out 1.0 bugs. |