Code::Blocks hangs while debugging

[TF]

Sounds to me like a program is waiting for input somewhere.
Have you tried switching into all the other tasks to see if they
accept input?

yes, I've checked all message tabs. The only tab I can do something is the Debugger(debug) tab. But there I can only move cursor up, down, left and right, but no keyboard input is possible. Also I've looked behind C::B if there's a console window, but nothing is there

codeblocks doesnt seem to show window when debugging console applications.
all output of debugged app is shown on debuggers debug log though..

Yes I aggree with you. There looks something very strange for me, if I made a top output after start debugging (after executing the getline operation):

Code

22562 tf        16   0     0    0    0 Z  0.0  0.0   0:45.44 codeblocks <defunct>                                                    
19277 tf        16   0  8796 5444 2400 S  0.0  0.5   0:00.10 gdb                                                                     
19282 tf        16   0  2540  800  688 S  0.0  0.1   0:00.00 uebung1711                                                              

C::B is defunction ... something goes a little bit wrong here  :?

Regards,

Thomas

[Michael]

Sounds to me like a program is waiting for input somewhere.
Have you tried switching into all the other tasks to see if they
accept input?

yes, I've checked all message tabs. The only tab I can do something is the Debugger(debug) tab. But there I can only move cursor up, down, left and right, but no keyboard input is possible. Also I've looked behind C::B if there's a console window, but nothing is there

I have given it a try and yes, C::B wait for an input. The Debugger (debug) tab shows:

Please type in a String (max. 80 characters):

But where do you have the type the string :?? In Windows usually there is command line window of the application where you can put your input, but in Ubuntu 5.10, I cannot find where .

Best wishes,
Michael

[Pecan]

Sounds to me like a program is waiting for input somewhere.
Have you tried switching into all the other tasks to see if they
accept input?

I have given it a try and yes, C::B wait for an input. The Debugger (debug) tab shows:
Please type in a String (max. 80 characters):

But where do you have the type the string :?? In Windows usually there is command line window of the application where you can put your input, but in Ubuntu 5.10, I cannot find where .

Best wishes,
Michael

cmd or command.com is just the windows' shell. The program shown below would have to be run in a shell to use std in/out/err, print, keyboard etc.

The input would be at the same location to which the output went.
It's up to the program or the programmer to start the shell, not CB's
Currently, both are in std::I/O limbo...

I believe this is a programmer err, a logic err, an oversight....
Poor CB is the object of an injust accusation.

[Michael]

Sounds to me like a program is waiting for input somewhere.
Have you tried switching into all the other tasks to see if they
accept input?

I have given it a try and yes, C::B wait for an input. The Debugger (debug) tab shows:
Please type in a String (max. 80 characters):

But where do you have the type the string :?? In Windows usually there is command line window of the application where you can put your input, but in Ubuntu 5.10, I cannot find where .

Best wishes,
Michael

cmd or command.com is just the windows' shell. The program shown below would have to be run in a shell to use std in/out/err, print, keyboard etc.

The input would be at the same location to which the output went.
It's up to the program or the programmer to start the shell, not CB's
Currently, both are in std::I/O limbo...

I believe this is a programmer err, a logic err, an oversight....
Poor CB is the object of an injust accusation.

hmmm. When I run a successfully built program and I run it with C::B, C::B open a shell. But, when you debug the application within C::B, C::B should also open a shell, or? If I have to do it, how?

I will check a bit more in depth the different options after finishing to install prelink on my Ubuntu 5.10  .

Thanks .

Best wishes,
Michael

[TF]

The input would be at the same location to which the output went.
It's up to the program or the programmer to start the shell, not CB's
Currently, both are in std::I/O limbo...

I believe this is a programmer err, a logic err, an oversight....
Poor CB is the object of an injust accusation.

As I run the program with gdb, all messages appears like in C::B's debugger(debug) task but with gdb I can input a string ... Therefore I assume that C::B should anticipate the input in the debugger task, too ...

Did you ment in your post that this behaviour is caused by a C::B programmer err or a logic err in C::B ?  :? If so I should create a bug report ...

Best regards,

Thomas

[Pecan]

The input would be at the same location to which the output went.
It's up to the program or the programmer to start the shell, not CB's
Currently, both are in std::I/O limbo...

I believe this is a programmer err, a logic err, an oversight....
Poor CB is the object of an injust accusation.

As I run the program with gdb, all messages appears like in C::B's debugger(debug) task but with gdb I can input a string ... Therefore I assume that C::B should anticipate the input in the debugger task, too ...

Did you ment in your post that this behaviour is caused by a C::B programmer err or a logic err in C::B ?  :? If so I should create a bug report ...

Best regards,

Thomas

I'm conficted as to wheither this is a bug or not. gdb is a shell task, so you, as a programmer, can expect to have access to std i/o.  But CB is a graphics task without shell access. So I, as a programmer, would not expect to have std I/O access unless I provided the means to access it.

I'd submit this as a bug anyway, and see how the core devs react. Don't get upset if they yell at ya though. This might be cause for yelling.... :x

[TF]

Hi Pecan,

thanks for information

I've submitted this problem and hope the developer can fix it and won't yell too loud against me

Best regards,

Thomas