Everyone. I've been using CLion for some time and I do like it, except one thing. Maybe somebody had the same problem.
The thing is that when I print something in console, the IDE prints it back. For example, if I run that code
#include <iostream>
#include <string>
int main() {
std::string message;
std::getline(std::cin, message);
std::cout << "You've printed: " << message;
return 0;
}
the IDE will act like this:
Printing back
I think that problem lies in CMake, but as a newy I have no idea how to fix it. Could you help me?
That's probably because getline returns an istream& parameter
I ran into the same problem.
Seems like it is a known issue, related to MinGW and bugged in JetBrains tracker:
https://youtrack.jetbrains.com/issue/CPP-2580#u=1443705085694
It is just an issue with IDE / terminal obviously, program will run properly if run outside of the IDE.
Related
I was experimenting with C++ Insights and I got a result that was surprising to me and which I don't really understand. I was hoping some one can provide some illumination for.
Given this code snippet:
#include <string>
int main()
{
std::string a {"123"};
std::string b = {"123"};
std::string c = "123";
std::string d("123");
}
I was at least expecting a to be initialised differently to c. With c I was expecting some sort of temporary string to be copied and for a I was expecting just the constructor to be called directly.
Here is the link to c++ insights: here (You have to press the "play" button).
Every one of the different ways to initialise a string is the same. This really surprised me. I started with c++17 and then switched to c++11, which produced something more like what I was expecting.
Does this mean that all init types in c++17 are now the same? - is there a name for this, because I thought uniform init was only with the curly braces {} - is everything now uniform init?
My PDCurses program terminates when I pass the stdscr variable to any function that receives a WINDOW* argument (e.g., keypad and wprintw). But it works when I capture the WINDOW* returned by initscr and use it instead.
I assume that once initscr is called, the WINDOW* returned by it and the stdscr variable should be the same. But after comparing their addresses I realized it is not so.
I could keep using the WINDOW* returned by initscr, but that would not work in a multi-terminal program where one have to use newterm which returns a SCREEN*, not a WINDOW*. In that case I necessarily would need to use the stdscr variable, which still refuses to work.
Here is a sample code that works:
#include <curses.h>
int main()
{
WINDOW* wnd = initscr();
wprintw(wnd, "Hello world!");
refresh();
endwin();
return 0;
}
But this one does not:
...
int main()
{
initscr();
wprintw(stdscr, "Hello world!"); // the program terminates here
refresh();
endwin();
return 0;
}
This potentially multi-terminal program doesn't work either:
...
int main()
{
SCREEN* term = newterm(NULL, stdout, stdin);
set_term(term);
wprintw(stdscr, "Hello world!"); // the program terminates here
refresh();
endwin();
return 0;
}
So I don't know what is happening with the stdscr variable. I am using Windows 8.1 x64, VC++ x64 of Visual Studio 2012 and PDCurses 3.4.0.3 (downloaded with Nuget package manager).
So, referencing Git Issue #31: https://github.com/wmcbrine/PDCurses/issues/31
it looks like you probably were building without defining PDC_BUILD_DLL. As noted in win32/README (later win32/README.md, wincon/README.md):
"When you build the library as a Windows DLL, you must always define
PDCURSES_DLL_BUILD when linking against it. (Or, if you only want to
use the DLL, you could add this definition to your curses.h.)"
The described modification was made to the curses.h files bundled with the DLLs I distriubted on SourceForge, but not those from the NuGet project, nor apparently is the relevant documentation included in that package.
The last line of PDCurses' implementation of initscr() (really Xinitscr(), which is called by initscr(), but anyway) is simply return stdscr;. So there's absolutely no difference between stdscr and the return value of initscr().
I don't know what you're doing wrong, but I can't reproduce any problem with your sample program. You might want to specify more about your environment -- OS, compiler, PDCurses version -- and exactly what it is that you're interpreting as a crash. BTW, the inclusion of stdio.h here is unnecessary (but harmless).
PDCurses doesn't support multiple simultaneous terminals, anyway.
I am trying to hook some kernel function for learning purpose, I wrote the simple kernel module below, but for some reasons, the register_kprobe always returns -2. I didn't find nothing about what it says what this error means and have no idea how to continue. At first I thought it is because list_add is an inline function, so I tried replacing it with kvm_create_vm and got the same result. Then I checked the /proc/kallsyms and found that both don't appear there. So I chose kvm_alloc which is exported, and still I get error -2. I also tried alloc_uid but this worked just fine.
My question: What kind of functions can be hooked with kprobes?
#undef __KERNEL__
#define __KERNEL__
#undef MODULE
#define MODULE
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/kprobes.h>
#include <linux/ptrace.h>
MODULE_LICENSE("GPL");
static int pre(struct kprobe *kp, struct pt_regs *regs){
printk(KERN_INFO "It is working!\n");
return 0;
}
static struct kprobe kp = {
.symbol_name = "list_add",
.pre_handler = pre,
.post_handler = NULL,
.fault_handler = NULL
};
int init_module(void){
printk(KERN_INFO "Hi\n");
printk(KERN_INFO "register_kprobe: %d\n" , register_kprobe(&kp));
return 0;
}
void cleanup_module(void){
unregister_kprobe(&kp);
printk(KERN_INFO "Bye\n");
}
Edit
The line I stroked through was the main reason I got confused. I miss spelled kvm_alloc, it should be kvmalloc without the underscore. And this function got hooked just fine.
To probe inlined functions, you need to find all the PC addresses at which their inlined instances live, and plop those addresses into the struct kprobes .addr field. A tool such as systemtap searches DWARF debuginfo for such inlined functions to compute PC addresses. See readelf -w vmlinux; DW_TAG_inlined_subroutine, DW_AT_low_pc etc.
A negative return value can usually be interpreted as a negated errno value. Have a look at http://www.virtsync.com/c-error-codes-include-errno or so:
#define ENOENT 2 /* No such file or directory */
So the problem seems to be that register_kprobe could not find something, probably the list_add symbol. Let's dig into the source to figure out why it is that way.
register_kprobe calls kprobe_addr to resolve the symbol name, which in turn calls kprobe_lookup_name, which is a #define for kallsyms_lookup_name. So it seems that you need to get the symbol you want to hook into kallsyms for this to work.
For documentation about kprobes, have a look at Documentation/kprobes.txt in the kernel source tree. About kprobe'ing inline functions, it says:
If you install a probe in an inline-able function, Kprobes makes
no attempt to chase down all inline instances of the function and
install probes there. gcc may inline a function without being asked,
so keep this in mind if you're not seeing the probe hits you expect.
So, it doesn't really work for inlined functions.
Now that we have figured out the problems, let's look for solutions. You'll probably need to recompile your kernel for this though.
First, make sure that the kernel configuration option CONFIG_KALLSYMS_ALL is turned on – that makes sure that kallsyms knows about more symbols. Then, try moving the implementation of list_add into a seperate .c file and adding __attribute__ ((noinline)) to it. That new kernel build is going to be slower, but I think that your kprobe module should work with it.
I have the following std::begin wrappers around Eigen3 matrices:
namespace std {
template<class T, int nd> auto begin(Eigen::Matrix<T,nd,1>& v)
-> decltype(v.data()) { return v.data(); }
}
Substitution fails, and I get a compiler error (error: no matching function for call to 'begin'). For this overload, clang outputs the following:
.../file:line:char note: candidate template ignored:
substitution failure [with T = double, nd = 4]
template<class T, int nd> auto begin(Eigen::Matrix<T,nd,1>& v)
^
I want this overload to be selected. I am expecting the types to be double and int, i.e. they are deduced as I want them to be deduced (and hopefully correctly). By looking at the function, I don't see anything that can actually fail.
Every now and then I get similar errors. Here, clang tells me: substitution failure, I'm not putting this function into the overload resolution set. However, this does not help me debugging at all. Why did substitution failed? What exactly couldn't be substituted where? The only thing obvious to me is that the compiler knows, but it is deliberately not telling me :(
Is it possible to force clang to tell me what did exactly fail here?
This function is trivial and I'm having problems. In more complex functions, I guess things can only get worse. How do you go about debugging these kind of errors?
You can debug substitution failures by doing the substitution yourself into a cut'n'paste of the original template and seeing what errors the compiler spews for the fully specialized code. In this case:
namespace std {
auto begin(Eigen::Matrix<double,4,1>& v)
-> decltype(v.data()) {
typedef double T; // Not necessary in this example,
const int nd = 4; // but define the parameters in general.
return v.data();
}
}
Well this has been reported as a bug in clang. Unfortunately, the clang devs still don't know the best way to fix it. Until then, you can use gcc which will report the backtrace, or you can apply this patch to clang 3.4. The patch is a quick hack that will turn substitution failures into errors.
The Windows CRT in debug mode will show a "Abort,Retry, Ignore" window if the application hits an assert(false) and sometimes it is created many times and fills my screen.
I would love it if the assert would break in the debugger and not ask me any questions.
I have modified the CRT reporting flags which have had no effect.
I have also tried to modify the reporting hook. It does get called by after 25-30 "Abort" dialogs appear.
I am building a DLL that is loaded by a separate program if that helps. It also looks like the host program loading my DLL is not consistent with what thread is calling my code.
It seems like the one of the threads was stopped but the others are still running.
How do I configure the CRT to do this ?
This works (for me atleast, on vs 2008):
(Essentially, return TRUE from the hooked function)
int __cdecl CrtDbgHook(int nReportType, char* szMsg, int* pnRet)
{
return TRUE;//Return true - Abort,Retry,Ignore dialog will *not* be displayed
return FALSE;//Return false - Abort,Retry,Ignore dialog *will be displayed*
}
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
_CrtSetReportHook2(_CRT_RPTHOOK_INSTALL, CrtDbgHook);
assert(false);
getch();
return 1;
}
You could also write your own assert-like behavior (Note that this will show the "Break, Continue" dialog):
#define MYASSERT(x) { if(!(x)) {DbgRaiseAssertionFailure();} }
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
MYASSERT(false);
getch();
return 1;
}
Hope that helps!
Liao's answer takes you most of the way there, but I'd like to propose that you add one more thing to your debug hook:
int __cdecl StraightToDebugger(int, char*, int*)
{
_CrtDbgBreak(); // breaks into debugger
return TRUE; // handled -- don't process further.
}
Otherwise your assertions will just disappear and the process will terminate.
Problem with this approach is that -- at least for my home install of VC Express -- the debugger throws up a big "program.exe has triggered a breakpoint" message instead of the normal Assertion Failure, so it may not be a great improvement.
I'm not sure if you want the behavior to be for any assert, or whether you're just trying to use assert(false) specifically as a general-purpose pattern to unconditionally break into debugger on a given line. If it's the former, see Liao's and Kim's answers. If it's the latter, then you should really use the __debugbreak intrinsic function instead.
Why does it assert? assert(false) looks like "should never happen" code was executed in CRT. I would be scared if I were you. Is it always on one line? Are there any comments around it?
EDIT:
I mean: assert happens in CRT code because there is some assumption it is checking that you don't meet (maybe you managed to link to mixed runtime, or you making managed C++ assembly and forgot to manually initialize CRT, or you trying to call LoadLibrary from within DllMain, or some other thing that should never happen).
So before figuring out how to suppress asserts, find out why exactly does it assert in the first place. Otherwise you'll likely get seemengly unrelated problems later on and will have lots of fun trying to debug them. (from your question it is unclear if you know what those asserts are about)
Code like this
if(somebadcondition)
{
assert(false);
// recovery code
}
literally means "this branch of code should never be executed".
Why not use DebugBreak Function?
Or even use an opcode?
#ifdef _X86_
#define BreakPoint() _asm { int 3h }
#else
#define BreakPoint() DebugBreak()
#endif
Before Visual C++ 2005, the instruction,
__asm int 3 did not cause native code to be generated when compiled with
/clr; the compiler translated the
instruction to a CLR break
instruction. Beginning in Visual C++
2005, __asm int 3 now results in
native code generation for the
function. If you want a function to
cause a break point in your code and
if you want that function compiled to
MSIL, use __debugbreak.