Bugzilla – Full Text Bug Listing
| Summary: | [console] Cannot have both stdout in console and in file | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Axel Mueller <aegges> | ||||||
| Component: | cdt-debug-dsf | Assignee: | Pawel Piech <pawel.1.piech> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Pawel Piech <pawel.1.piech> | ||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | marc.khouzam, pawel.1.piech | ||||||
| Version: | 7.0 | Flags: | marc.khouzam:
review+
|
||||||
| Target Milestone: | 7.0 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Axel Mueller
It is even worse. There is also no output in the given file! Some more info. Stdout to console and file works well when no debugger is selected, i.e. a Run Configuration is used. When output to file is activated an exception occurs: java.lang.IllegalArgumentException: Attempted to beginRule: P/HelloWorld, does not match outer scope rule: org.eclipse.cdt.dsf.debug.model.DsfLaunch$EventSchedulingRule@4abf6d1e at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:136) at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:326) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:85) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:285) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:117) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1914) at org.eclipse.core.internal.resources.Resource.delete(Resource.java:766) at org.eclipse.core.internal.resources.Resource.delete(Resource.java:752) at org.eclipse.debug.internal.ui.views.console.ProcessConsole.<init>(ProcessConsole.java:152) at org.eclipse.debug.internal.ui.views.console.ProcessConsoleManager.launchChanged(ProcessConsoleManager.java:145) at org.eclipse.debug.internal.core.LaunchManager$LaunchNotifier.run(LaunchManager.java:454) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.debug.internal.core.LaunchManager$LaunchNotifier.notify(LaunchManager.java:435) at org.eclipse.debug.internal.core.LaunchManager.fireUpdate(LaunchManager.java:997) at org.eclipse.debug.core.Launch.fireChanged(Launch.java:388) at org.eclipse.cdt.dsf.debug.model.DsfLaunch.access$1(DsfLaunch.java:1) at org.eclipse.cdt.dsf.debug.model.DsfLaunch$1.run(DsfLaunch.java:78) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) The exception occurs in /org.eclipse.debug.ui/ui/org/eclipse/debug/internal/ui/views/console/ProcessConsole.java line 152: ifile.delete(true, new NullProgressMonitor()); However, I don't understand why an exception is thrown. Created attachment 169911 [details]
Patch to elimiate custom notification job.
I should have known better than mess with scheduling rules...
Does this patch take care of the problem for you (it works for me)?
(In reply to comment #4) > Does this patch take care of the problem for you (it works for me)? Yep. I am fine with this patch. Tested on Linux. I committed the fix. Marc please review. *** cdt cvs genie on behalf of ppiech *** Bug 314258 - [console] Cannot have both stdout in console and in file [*] DsfLaunch.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf/src/org/eclipse/cdt/dsf/debug/model/DsfLaunch.java?root=Tools_Project&r1=1.4&r2=1.5 (In reply to comment #6) > I committed the fix. Marc please review. Very nice. And we avoid the whole multi-thread problems that were caused by having two jobs running at the same time. Nice! I have never tried this feature (log to file or/and console) before, but now that I have, I wonder if we don't have another bug here. Since we have two launch processes, we we log to a file, we seem to have a conflict where the content of the file is sometimes the GDB output while other times the Inferior's output. Both consoles are writing to the same file and my guess is that the last one to open the file will have it's output there (or maybe the last one to write?) One way around this is to check the Append box, so as to keep all output from both consoles. But it seems like an imperfect solution to me. CDI has this problem too by the way. Is this a bug, or is this a known limitation? (In reply to comment #9) > CDI has this problem too by the way. > Is this a bug, or is this a known limitation? I've never used this feature, so it's news to me... (In reply to comment #9) > I have never tried this feature (log to file or/and console) before, but now > that I have, I wonder if we don't have another bug here. > > Since we have two launch processes, we we log to a file, we seem to have a > conflict where the content of the file is sometimes the GDB output while other > times the Inferior's output. Both consoles are writing to the same file and my > guess is that the last one to open the file will have it's output there (or > maybe the last one to write?) > > One way around this is to check the Append box, so as to keep all output from > both consoles. But it seems like an imperfect solution to me. > > CDI has this problem too by the way. > Is this a bug, or is this a known limitation? I have never experienced this problem with CDI. To be sure I just tested it with CDT 7.0 again. No problem. The log file and console shows only the output of my application. I have not tested yet this with DSF (I was waiting for this fix). You can be sure that I will open a bug report if I encounter any problems :) BTW, I can remember that there were some people on the CDT newsgroup who experienced mixed output (in the console!). Perhaps it occurs only on Windows? (In reply to comment #11) > I have never experienced this problem with CDI. To be sure I just tested it > with CDT 7.0 again. No problem. The log file and console shows only the output > of my application. I have not tested yet this with DSF (I was waiting for this > fix). You can be sure that I will open a bug report if I encounter any problems > :) I've tried it on both Windows and Linux with CDI and I definitely see gdb output to the output file. Furthermore, the gdb output gets partially overwritten once the application writes something. Axel, can you let me know if you see this too? (In reply to comment #12) > (In reply to comment #11) > > I have never experienced this problem with CDI. To be sure I just tested it > > with CDT 7.0 again. No problem. The log file and console shows only the output > > of my application. I have not tested yet this with DSF (I was waiting for this > > fix). You can be sure that I will open a bug report if I encounter any problems > > :) > > I've tried it on both Windows and Linux with CDI and I definitely see gdb > output to the output file. Furthermore, the gdb output gets partially > overwritten once the application writes something. > > Axel, can you let me know if you see this too? I tested both CDI and DSF with the latest CDT (checkout from HEAD yesterday) and in both cases I do not see any output interferences. My use case was a simple Hello World with output redirected to console and file (no append, Linux x64, gdb 7.1). The gdb output (gdb traces active) was only visible in its own console and did never appear in the output file. And as I said before I was using this feature with CDI and Helios very often and did never experience any problems. What was your test scenario? (In reply to comment #13) > I tested both CDI and DSF with the latest CDT (checkout from HEAD yesterday) > and in both cases I do not see any output interferences. My use case was a > simple Hello World with output redirected to console and file (no append, Linux > x64, gdb 7.1). The gdb output (gdb traces active) was only visible in its own > console and did never appear in the output file. And as I said before I was > using this feature with CDI and Helios very often and did never experience any > problems. > What was your test scenario? Linux 32, gdb 7.0, HEAD, simple Hello World with output redirected to console and file, no append. I tried both DSF and CDI and both did the same. Launch, then go to the gdb console and give the command 'show version', I see the output in the output file. Then run the program to completion, I see the 'hello world' printout at the top of the output file with the gdb stuff below it, like this: > cat outcdi.txt !!!Hello World!!! Stopped due to shared library event Stopped due to shared library event GNU gdb (GDB) 7.0.1 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. (In reply to comment #14) > (In reply to comment #13) > > I tested both CDI and DSF with the latest CDT (checkout from HEAD yesterday) > > and in both cases I do not see any output interferences. My use case was a > > simple Hello World with output redirected to console and file (no append, Linux > > x64, gdb 7.1). The gdb output (gdb traces active) was only visible in its own > > console and did never appear in the output file. And as I said before I was > > using this feature with CDI and Helios very often and did never experience any > > problems. > > What was your test scenario? > > Linux 32, gdb 7.0, HEAD, simple Hello World with output redirected to console > and file, no append. I tried both DSF and CDI and both did the same. > > Launch, then go to the gdb console and give the command 'show version', I see > the output in the output file. Then run the program to completion, I see the > 'hello world' printout at the top of the output file with the gdb stuff below > it, like this: > > > cat outcdi.txt > !!!Hello World!!! > Stopped due to shared library event > Stopped due to shared library event > GNU gdb (GDB) 7.0.1 > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. I followed your instructions (this time Linux 64 with gdb 7.0 (Ubuntu 9.10), CDT RC3) but still no problem (CDI and DSF). A test run on Ubuntu 32Bit gdb 7.0 and CDT 6.0.2 (CDI) did also works flawlessly. All platforms use Java 1.6 (if this matters). Created attachment 170571 [details] Screenshot of Common tab settings (In reply to comment #15) > I followed your instructions (this time Linux 64 with gdb 7.0 (Ubuntu 9.10), > CDT RC3) but still no problem (CDI and DSF). A test run on Ubuntu 32Bit gdb 7.0 > and CDT 6.0.2 (CDI) did also works flawlessly. All platforms use Java 1.6 (if > this matters). I tried with Java 6 and RC3 I still see it. We must not be understanding each other :-) Try this: 1- create a C++ Hello world 2- open debug configurations and create one for the project (it will use DSF-GDB) 3- go to the Common launch tab and click on File and put the file name (check the attachment to confirm you see what I see) 4- make sure that file does not exist on your file system (so we know it is empty) 5- press Debug -> you will end up on the line that prints Hello World 6- in the debug view, select the gdb entry (to get the proper console showing) 7- go to the console view and type 'show version' you should see the gdb version 8- Go to a unix shell and look at the content of the output file => I see the gdb version printout (In reply to comment #16) > Created an attachment (id=170571) [details] > Screenshot of Common tab settings > > (In reply to comment #15) > > > I followed your instructions (this time Linux 64 with gdb 7.0 (Ubuntu 9.10), > > CDT RC3) but still no problem (CDI and DSF). A test run on Ubuntu 32Bit gdb 7.0 > > and CDT 6.0.2 (CDI) did also works flawlessly. All platforms use Java 1.6 (if > > this matters). > > I tried with Java 6 and RC3 I still see it. We must not be understanding each > other :-) Try this: > > 1- create a C++ Hello world > 2- open debug configurations and create one for the project (it will use > DSF-GDB) > 3- go to the Common launch tab and click on File and put the file name (check > the attachment to confirm you see what I see) > 4- make sure that file does not exist on your file system (so we know it is > empty) > 5- press Debug -> you will end up on the line that prints Hello World > 6- in the debug view, select the gdb entry (to get the proper console showing) > 7- go to the console view and type 'show version' you should see the gdb > version > 8- Go to a unix shell and look at the content of the output file => I see the > gdb version printout Ha, I finally found the difference :-) It is point 4. I usually create an empty file or use an existing one (it's content is deleted anyway or better said the file is deleted and then recreated according to the source code). The reason is that when you click in the launch configuration any of the three buttons Workspace/File System/Variables you have to select an existing file. Unfortunately, it is not possible to create a new file from this dialog (why??), so I use New File beforehand. When I follow your instructions I get mixed console output. (In reply to comment #17) > Ha, I finally found the difference :-) It is point 4. I usually create an empty > file or use an existing one (it's content is deleted anyway or better said the > file is deleted and then recreated according to the source code). Even when I re-use an existing file I see the problem... > The reason is > that when you click in the launch configuration any of the three buttons > Workspace/File System/Variables you have to select an existing file. > Unfortunately, it is not possible to create a new file from this dialog > (why??), so I use New File beforehand. From the dialog you can't because it is a standard Open File dialog. However, nothing prevents you from typing the file by hand in the text box instead of opening the dialog. Or you can select any existing file from the dialog and then modify it before clicking Debug. > When I follow your instructions I get mixed console output. So, what do you think? A bug? We have two consoles, so the first question is: "Do we want to store the output of both consoles, or just the Application console?" We could argue we just want the output of the application, since the gdb console has a 'save' button anyway. (In reply to comment #18) > (In reply to comment #17) > > Ha, I finally found the difference :-) It is point 4. I usually create an empty > > file or use an existing one (it's content is deleted anyway or better said the > > file is deleted and then recreated according to the source code). > > Even when I re-use an existing file I see the problem... Ah, I narrowed the problem. It only works correctly, i.e. no mixed console output if you choose a file *within your workspace*. It does not matter then if the file exists or not. > So, what do you think? A bug? We have two consoles, so the first question is: > "Do we want to store the output of both consoles, or just the Application > console?" > > We could argue we just want the output of the application, since the gdb > console has a 'save' button anyway. I would say it is definitely a bug. The UI shows clearly two different consoles. As a user I would not expect to have the output of these two consoles mixed in one file. I would prefer to have only the output of the application saved in the file. BTW, in the launch config it says "Standard input and output". But output to stderr is saved as well in the file (and shown in the console). Sometimes it would be helpful to have two separated files for stout and stderr. But that is another story ... (In reply to comment #19) > I would say it is definitely a bug. The UI shows clearly two different > consoles. As a user I would not expect to have the output of these two consoles > mixed in one file. I would prefer to have only the output of the application > saved in the file. I have opened Bug 315207 to track all this. We can put the current bug to rest. Thanks. |