I have encountered a very strange issue with printing to console using std::cout in a c++11 application under CentOS.
printf("Before...\n"); // This gets printed with no issue
std::cout << "This won't be printed to console\n" << std::flush; // This won't get printed
std::cout.flush();
printf("After...\n"); // This gets printed with no issue
The output in the console is:
Before...
After...
The cout message for some reason is not printed. There is no stdout redirection in my code. I purposely redirected cout to a file but the issue was not solved. I am confused as to where to track down the issue.
What would prevent cout from printing? In what potential scenarios, cout stops functioning? What could be the issue?
Related
When doing a std::cout << "Start" << std::endl; in vscode for Mac it always prints #"Start\r\n" to the debug console.
Is there a way to get rid of the #"\r\n" characters so that it would only print Start?
Best, Hu
You probably currently using llbd , try using externalConsole instead, by adding "externalConsole": true to launch.json, which will send the output to a separate terminal window.
I have a visual c++ redistributable installer exe in a resource file. File is extracted, moved to %TEMP%, run with QProcess and removed after process ends. The problem I have is that file removal fails with "Permission denied" even with escalated privileges. It seems that it is caused by file still being used by something (busy) because it starts working if I add a 1 second delay before removal.
QFile vcredistResource2015(":\\data\\vc_redist.x86.exe");
QString dst2015 = QDir::temp().absolutePath()+"/vc_redist.x86.exe";
vcredistResource2015.copy(dst2015);
QProcess p2015;
p2015.start(dst2015);
p2015.waitForFinished(-1);
//QThread::sleep(1); //this line solves it
QFile rm15(dst2015);
rm15.setPermissions(QFile::ReadOther|QFile::WriteOther);
if (rm15.exists() && rm15.remove()) {
qDebug() << "removed 2015";
}
else {
qDebug() << rm15.errorString(); //Permission denied here
}
Problem:
CLion doesn't output any console output for debugging purposes.
I'm using CLion with the MingW compiler and cmake. No matter whether I use:
std::cout << "Testing" << std::endl;
Or:
printf("Testing");
I don't see any console output.
Attempts at Resolution:
1:
I've checked "Run", "Debug", "Terminal" and "Cmake". I've attempted to edit my configurations but "Debug" doesn't show up.
2:
Next, I went to Settings->Build,Execution,Deployment->CMake to edit the Generation types. I added Debug and RelWithDebInfo and still to no avail.
3:
I also attempted to add "-Debug" to Cmake, but I still have no output.
4:
The closest thing I've received for debugging is using GDB to view variable values at break points. This only works in the "RelWithDebInfo" generation.
Solution:
I ended up figuring out what the problem was.
I'm developing a Qt GUI application within CLion on Windows. You have to specify a console for console output to print onto.
Call this Console() function early in your main for a console prompt to open up. Now, whenever you run
QDebug() << <string>;
or
std::cout << <string> std::endl;
You'll see your debugging statements. Hope this helps somebody else out there with the same problem.
Code:
void Console()
{
AllocConsole();
FILE *pFileCon = NULL;
pFileCon = freopen("CONOUT$", "w", stdout);
COORD coordInfo;
coordInfo.X = 130;
coordInfo.Y = 9000;
SetConsoleScreenBufferSize(GetStdHandle(STD_OUTPUT_HANDLE), coordInfo);
SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE),ENABLE_QUICK_EDIT_MODE| ENABLE_EXTENDED_FLAGS);
}
Source:
I found a solution here:
[0] Console output in a Qt GUI app?
There's a simpler solution that doesn't require adding any code. Simply add the following environment variable in your debug configuration:
QT_ASSUME_STDERR_HAS_CONSOLE=1
With this, CLion shows QDebug and QML's console.*() when started with a debugger.
I am using Mac OSX. I have created a buffer overflow vulnerable program:
#include<stdio.h>
#include<string.h>
int neverCalled() {
puts("You got me to be called");
return 0;
}
int main() {
puts("Name: ");
char name[64];
gets(name);
return 0;
}
I also have created an input file containing 88 "A"s (0x414141...) and 0x700E000001000000
When run in gdb:
(gdb) run < input
I get the output: You got me to be called and then a EXC_BAD_ACCESS error. Meaning that I exploited the program successfully.
When run it in terminal:
$ ./vulnerable < input
I get the output: Segmentation fault: 11 and nothing more.
Why does my buffer overflow work in gdb but fail in normal terminal.
gdb on mac os X appears to disable address space layout randomization
http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/
Why 0x700E000001000000? Your exploit seems to be layout-specific, probably out of what gdb prints when typing "p neverCalled".
This is not guaranteed in all executions. As cabellicar123 correctly pointed out, the layout where libraries and executable are mapped in a process are randomized and not guaranteed to be the same between executions.
For some reason it seems that gdb always gets the same layout. As an exercise include "printf("%p"\n", neverCalled)" somewhere in your program and see how the value changes.
Trying to make a bug log into a Ruby program so that when I come across bugs I can run the program and it will automatically write the bugs to a text file. I was able to get everything to write to a file but every time that I enter a new bug in it just overwrites the file and only can hold one entry at a time.
Here is my code thus far:
print "What is the error message? "
msg = "Error message: " + gets.chomp
print "What does the error mean? "
mean = "Error meaning: "+gets.comp
print "What resolved the error? "
resolved = "Error resolution: " + gets.comp
File.open('Bug_Log.txt', 'w') do |write|
write.puts msg
write.puts mean
write.puts resolved
end
This is happening because you're opening the file in 'w' mode, which overwrites the file, instead of 'a' ("append") mode, which will append to what's already in the file.
Try changing this line:
File.open('Bug_Log.txt', 'w') do |write|
to this:
File.open('Bug_Log.txt', 'a') do |write|