Since today, Eclipse locks up when an error is printed to the console during JUnit tests.
Using jstat, I can see that it hangs in java.util.regex.Pattern$Curly.match0(Pattern.java:3782)
How can I find out which regexp causes the problem?
Note that I didn't install anything nor did I change any prefs; my guess is that a change in the code triggered a lingering problem in an existing regexp.
Seems to be something with a {}-quantifier (http://www.docjar.com/html/api/java/util/regex/Pattern$Curly.java.html). Posting the actual regexp will maybe help.
This is Bug 175888 - ConsolePatternMatcher causes large delays with some large input
I have attached a patch which shows the regexp that causes the problem.
Related
I use cppcheck to look for errors.
now I'm looking for a way the stop the cppcheck run after he found the first error.
Thanks for your help.
Looking at http://cppcheck.sourceforge.net/manual.pdf
There seems to be no option to stop at first issue. You could always contact them directly though to confirm or request the feature.
I have an Xcode project that will not display C++ std::strings when I am debugging. It's incredibly frustrating because I am having to resort to print statements or outputting each character one at a time in the LLDB console window, which is time consuming and hard to read.
Every other person using this same project is having the same problem, and other projects are not seeing this problem, so I would think that this is a project setting of some kind. I'm in debug and there are no optimizations turned on, so I've eliminated that as the issue. I've also compared project settings between working projects and the one with this problem and they appear identical in every way that they can be.
Here's a sample of the output I get, *_M_p in this example is correct, the first character of the string is a question mark:
And here's what I get in the debug console if I inspect the string one character at a time:
I've heard that switching back to GDB from LLVM might solve the problem, but GDB gave me other issues with debugging certain data types, so I'll just have new problems in that case.
My co-worker figured out the fix for this: Turn off the Guard Malloc option in the scheme settings.
Click the scheme that is exhibiting the problem
Click on Edit Scheme
Click on Diagnostics
Uncheck the 'Enable Guard Malloc' option.
Now std::strings should be showing up. We don't know why this is the case, it may be a bug in Xcode, but I would think it would've been spotted awhile ago. Also, this was tested on multiple projects and enabling Guard Malloc always causes std::strings to not show up properly in debugger.
Try this lldb command
exp -f s -- myString
You are telling the lldb to show the expression of your string with the format c String
This might not have caused the original poster's problem, but it caused mine: I was using Xcode 6.4 while most of the code had been built with 6.2. Switching to 6.2 made the values visible in the debugger.
Try this command
po string_name
I'm using VS2012 and I'm quite happy with it. But the problem is, whem I'm coding in C++, that the syntax highlighting is turning off an on all over again. Sometimes, the highlighting is off and I have to reload the file. Also, it highlighting is quite slow.
Does anyone know how to fix it?
I know this is a while ago but I have had this same problem appearing randomly until just now.
It would disable when the last line in a file was a single line comment. (// blah blah). As soon as i removed that the text highlighting worked again!
Edit: In this answer I assume that your problem description is correct. In other words, I'm assuming that occasionally C++ highlighting is working, and the other times the text appears as plain text: completely black and white.
My guess is you are using an extension which modifies or replaces the way Visual Studio highlights C++ code. Try temporarily disabling all of your extensions and checking again if the editor is working. Some extensions might have the Disable button disabled; in that case you'll need to uninstall the extension for this test (possibly through Control Panel → Programs and Features).
As an example of one common extension that completely replaces the C++ highlighter is Visual Assist. However, I do not personally use that product and I haven't heard of any specific problems with it of this nature. I am merely mentioning it as an example of an extension that completely changes the behavior of Visual Studio in regards to syntax highlighting of C++ code.
For me, highlighting always stops working when the first visible line in the editor begins with the characters '//' and I trigger reparsing somehow (CTRL + S for instance).
Highlighting always works fine when the first visible line in the editor begins with anything else, even with a whitespace, and I trigger reparsing somehow.
I could indent all my comments and never experience this problem, but now that I know about it, it's not so annoying anymore, so I let it be.
This is a bug in Visual Studio 2012:
https://connect.microsoft.com/VisualStudio/feedback/details/760154/syntax-highlighting-sometimes-not-working
If you're using only Intellisense, you may go to Edit->Intellisense->Toggle Completion Mode (or hit Ctrl + Alt + Space), play with it and see if it works (maybe you've pressed this combination of keys by accident).
I've also installed Update 3 and haven't had any problems since. Who knows..
I had the same problem. Disabling the extentions sadly did not work for me.
After searching around and realizing that it only happened on larger files,
I got it to work by turning harware acceleration off.
Tools->Options...->Environment->General
*Automatically adjust [...] (off)
*Use hardware graphics acceleration (off)
In my case, it turned out that a large block of code (a 200+ line method) was commented out with // starting in the first column, and this was causing the syntax coloring not to work. I changed the commenting delineation to /* ... */ for that method and all of the syntax coloring was fixed.
Personally, I found that things like:
#if 0// bla-bla
mess up syntax highlighting badly. The solution that works for is to put a space before a comment, like so:
#if 0 // bla-bla
I installed Visual Studio 2012 Update 3 yesterday and started experiencing the exact same behavior described in the original post. Based on some suggestions in this thread, I took at look at my extensions, and disabling AllMargins fixed the issue. I've since re-enabled AllMargins and everything appears to be working as it should.
Try disabling and re-enabling any of your extensions; hopefully that will fix the issue for you.
I'm currently trying to use the PlUnit test suit and encounter a problem to turn off the output of my predicates during the test.
The documentation says that I should be fine with something along the lines of set_test_options([silent(true)])., however that doesn't seem to have any effect on my test runs.
I tried to put those options into my load_test_files/1 call as well, but it didn't change anything.
If anyone can provide help about this library that'll be gratefully read, as I seem to misunderstand the documentation and am getting nowhere when trying to see what fails here.
The reason why I'm asking this, is because I'm coding in C++, in putty/ssh and I like the fact that I can code from pretty much everywhere without having to install anything.
So I'd like to have something that could help me debugging (viewing LIVE value of a variable, breakpoints, etc)
If you think that there's no such thing in this world, is there any good technique I could use to debug in command line?
Thanks
I've used gdb for command line debugging in the past with success:
http://www.gnu.org/software/gdb/
A decent tutorial can be found at:
http://www.cs.cmu.edu/~gilpin/tutorial/
vimgdb will give what you want. I've used it for about one year. The most interesting feature is:
Hightlight current line
List item
Can show disassembly code
Step into, Step over
inspect variables, memory address
Run all the underlying gdb command is possible
And, of course, set breakpoint, conditional breakpoint etc.
Highly customizable by vim key mapping and scripts.
Actually I use checkinstall to make an rpm for it, and installed it everywhere when I need to debug on the box.
I think it have the most important features I want from a visual debugger.
Have you tried gdb ? That's pretty much the command line debugger, but it's no vim plugin.
You have a script to do that: http://www.vim.org/scripts/script.php?script_id=1954
In my humble opinion, Vim is not designed to do such things and it is a bad idea to do so.