Code::Blocks Forums
User forums => Using Code::Blocks => Topic started by: kccheng on June 14, 2011, 09:23:55 pm
-
Hi,
I'm using C::B under WinXP.
I have a DLL project and assign a host application for the DLL.
The host application is a window application (Gtk2) but also has
a Console (DOS prompt) attached.
In C::B, when I run the DLL (via host application) the Console will
be popup without problem. But if I use C::B debugger (gdb), the
Console will disappear.
If I run my DLL + host application directly via gdb command line,
the Console will be popup correctly too. So my best guess is C::B
remove the Console of my host application.
Anyone know what's the problem here ? Thanks.
KC
-
Hm, have you tried the debugger branch nightly?
That version has a feature to run the host in a terminal.
-
Hm, have you tried the debugger branch nightly?
That version has a feature to run the host in a terminal.
I can try that. But I'm quite new to C::B ... could you
please tell me where can I find the nightly branch ? Any binary distribution
for nightly branch ?
Thanks a lot
KC
-
Hm, have you tried the debugger branch nightly?
That version has a feature to run the host in a terminal.
I can try that. But I'm quite new to C::B ... could you
please tell me where can I find the nightly branch ? Any binary distribution
for nightly branch ?
Thanks a lot
KC
Nightly builds (http://forums.codeblocks.org/index.php/board,20.0.html)
-
Nightly builds (http://forums.codeblocks.org/index.php/board,20.0.html)
One more simple question.
I found the latest nightly build maybe 7178, and there is another
DEBUGGER BRANCH which is 7075.
Does 7178 include everything in 7075 DEBUGGER BRANCH ?
KC
-
One more simple question.
I found the latest nightly build maybe 7178, and there is another
DEBUGGER BRANCH which is 7075.
Does 7178 include everything in 7075 DEBUGGER BRANCH ?
Mmm... I installed both and got the answer myself ... they are different.
Only 7075 DEBUGGER BRANCH has new debugger features which
are not merged into 7178 yet.
-
Yes, the normal nightly uses code from trunk in svn.
The debugger's branch nightly use the code in the wxpropgrid_debugger branch in svn.
-
Just update the situation of my original question.
The debugger branch nightly build doesn't fix the issue ...
no terminal (DOS prompt) and all of the message I display
by printf() disappear.
-
Have you enable the "Run host in terminal" setting?
Who does create the console the application or C::B, if it is the application you can't blame C::B.
-
Have you enable the "Run host in terminal" setting?
Who does create the console the application or C::B, if it is the application you can't blame C::B.
I enabled "Run host in terminal", but it doesn't work.
The application is a simple Gtk2 app. compiled without -mwindows linker options. So
even it was run via click on icon, it will come with a DOS prompt console.
If I set the Gtk2 app as DLL's host application,
the C::B Build->Run will run the host application which still comes with DOS prompt.
But if I use C::B Debug->start ... the host application will be run without DOS prompt.
If I use text mode gdb to run the Gtk2 app (host app) directly, it will run with
DOS prompt.
That's why I guess it might be something inside C::B's debugger plugin.
Regards,
KC
-
Hm, strange...
Can you try this steps:
1. make a console application
2. make a dll project
3. declare/export a function in the dll
4. call the function in the console application
5. active the dll project and try to debug it (probably you'll need to enable the "run host in terminal" option)
-
Hm, strange...
Can you try this steps:
1. make a console application
2. make a dll project
3. declare/export a function in the dll
4. call the function in the console application
5. active the dll project and try to debug it (probably you'll need to enable the "run host in terminal" option)
I do a similar test. Create a DLL project, and set the host application to a Console Application
I simply set the host application to "c:\windows\system32\attrib.exe" with arg "C:\windows\temp\*.*"
OK, I know ... the application does not use the function exported by DLL ... since I don't think
it's important to see if DOS prompt will be disappear or not.
Now in DLL's project, "Debug->Start" ... will make DOS prompt disappear with/without
"run host in terminal".
The message will be re-direct to "Debugger log"
Using "Build->Run" ... the DOS prompt will show up and run "attrib C:\windows\temp\*.*"
correctly.
Well, message show on "Debugger log" seems not show up in real-time ... but
if it catch all message, I think I can live with that.
Regards,
KC
-
Keep in mind that there is a little difference between "Build -> Run" and "Debug -> Start"
In the "Build -> Run" situation, C::B starts console_runner, which then starts your application and when your application finishes it prints "Press any key to continue message"
The debugger on the other hand doesn't use console_runner, so no message is printed. You can achieve similar effect by putting a breakpoint at the '}' of the main function.
Well, message show on "Debugger log" seems not show up in real-time ... but
if it catch all message, I think I can live with that.
The log window has some refresh problems on windows, the messages are almost "realtime".
You have to scroll up-down, so the log window can be refreshed correctly...
-
Thanks for the helpful information.
KC
-
Well, message show on "Debugger log" seems not show up in real-time ... but
if it catch all message, I think I can live with that.
The log window has some refresh problems on windows, the messages are almost "realtime".
You have to scroll up-down, so the log window can be refreshed correctly...
Hi,
I have done more test on debugger log, it's not just the refresh issue you mentioned.
What I found is all message from printf() will not be flush automatically even the message
include "\n". I need to enforce flush by calling fflush(0) right after each printf() to make them
show on debugger log immediately.
But debugger log does catch all message eventually which should normally
goes to Console.
I don't think this is correct behavior. The "\n" in printf() should cause auto flush.
Could this be improved in the future ?
Best Regards,
KC
-
The log window has some refresh problems on windows, the messages are almost "realtime".
You have to scroll up-down, so the log window can be refreshed correctly...
This is an annoying behavior I have encountered for several years. :D
I have no idea how to solve this. :(
-
I don't think this is correct behavior. The "\n" in printf() should cause auto flush.
Could this be improved in the future ?
Can you quote the standard, where you've read this?
-
I don't think this is correct behavior. The "\n" in printf() should cause auto flush.
Could this be improved in the future ?
Can you quote the standard, where you've read this?
I don't have any standard in hand and don't remember where I got this understanding.
After a quick search of my books ... I found something related to this in
W.Richard Stevens' famous book "Advanced Programming in the UNIX Env."
Ch. 5.4 Buffering
Well, I think maybe it's not printf's standard. Be correctly, the stdout and stderr
are line buffered I/O stream. So, the question becomes:
Since C::B Debug log console will capture stdout/stderr from debuggee ...
does C::B Debug log console should also behave like a line buffered I/O stream ?
so the debuggee can have similar expectation with/without C::B.
Regards,
KC
-
Since C::B Debug log console will capture stdout/stderr from debuggee ...
does C::B Debug log console should also behave like a line buffered I/O stream ?
so the debuggee can have similar expectation with/without C::B.
The log is line buffered I think. Take a look at PipedProcess if you don't believe me.