I am newbie to Xcode. I try to create a first problem with C++ (image below) and set some breakpoints to test debugging. I get a problem with input in console window. Particularly, whenever I get input line, I type number and there is nothing i can see in console until i change between target output and all output (i.e. if i am on "target output" and type anything, i have to change into "all output" to see the number i typed, vice versa). And there is one more problem: I can delete the number i typed, i.e. if i type 3, it only allow me to add postfix number such as 31 or anything like it. Cannot change the number.
Does anyone know this problem? Please help me. Thank a lot.
This is my code
in the old way you were allocating an empty array you should give its size which is 'n' here
int *a=new int(n);
your old code had some undefined behavior due to the out of bound access you were trying to do accessing without allocating
at the end of your code you should deallocate the dynamic allocated memory like this :
delete[] a;
I am debugging a program that reads data from a binary file and puts it into the fields of a TaggerDataUnigram object, TaggerDataUnigram being a class derived from TaggerData. All the reading operations read a number of data objects specified in the file and put the objects into fields of TaggerData. Therefore, I defined a function ReadForNumberToRead that takes a file and a Reader* as arguments, Reader being a base class for functors that define how to read the data from the file. Each Reader derivative takes a TaggerData* as an argument and stores the value of the pointer as a member. Unfortunately, TaggerData uses getters and setters, but the getters return references to the fields. So, for example, OpenClassReader accesses TaggerData::open_class through tagger_data_pointer_->getOpenClass().
Example: ForbiddingRuleReader's Constructor:
ForbiddingRuleReader::ForbiddingRuleReader(
FILE*& tagger_data_input_file_reference,
TaggerData* tagger_data_pointer)
: Reader(tagger_data_input_file_reference, tagger_data_pointer) {}
tagger_data_pointer_ is a protected member of Reader.
Reader::Reader(FILE*& tagger_data_input_file_reference,
TaggerData* tagger_data_pointer)
: TaggerDataFileInputOutput(tagger_data_input_file_reference),
tagger_data_pointer_(tagger_data_pointer) {} // tagger_data_pointer_ is initialized.
. . . and the identical constructor of ArrayTagReader:
ArrayTagReader::ArrayTagReader(FILE*& tagger_data_input_file_reference,
TaggerData* tagger_data_pointer)
: Reader(tagger_data_input_file_reference, tagger_data_pointer) {}
Their usages are likewise the same:
void TaggerDataUnigram::ReadTheForbiddingRules(
FILE*& unigram_tagger_data_input_file_reference) {
ForbiddingRuleReader forbidding_rule_reader(
unigram_tagger_data_input_file_reference,
this);
ReadForNumberToRead(unigram_tagger_data_input_file_reference,
&forbidding_rule_reader);
}
[. . .]
void TaggerDataUnigram::ReadTheArrayTags(
FILE*& unigram_tagger_data_input_file_reference) {
ArrayTagReader array_tag_reader(unigram_tagger_data_input_file_reference,
this);
ReadForNumberToRead(unigram_tagger_data_input_file_reference,
&array_tag_reader);
}
Needless to say, the TaggerDataUnigram object is not going out of scope.
OpenClassReader and ForbiddingRuleReader both work perfectly; they store a copy of the file and TaggerData* as fields and successively read data from the file and put it into its respective field in TaggerData. The problem arises when the ArrayTagReader is constructed. Despite sharing an identical constructor and being used the same way as ForbiddingRuleReader, something goes terribly wrong--tagger_data_pointer_ does not point to the same location in memory as the TaggerData* tagger_data_pointer the object was constructed with!
Breakpoint 1, ArrayTagReader::ArrayTagReader (this=0x7fffffffd640, tagger_data_input_file_reference=#0x7fffffffd720: 0x62a730, tagger_data_pointer=0x7fffffffd8c0)
at array_tag_reader.cc:10
10 : Reader(tagger_data_input_file_reference, tagger_data_pointer) {}
(gdb) print tagger_data_pointer
$1 = (TaggerData *) 0x7fffffffd8c0 <----------
(gdb) continue
Continuing.
Breakpoint 2, ArrayTagReader::operator() (this=0x7fffffffd640) at array_tag_reader.cc:12
12 void ArrayTagReader::operator()() {
(gdb) print tagger_data_pointer_
$2 = (TaggerData *) 0x7fffffffd720 <----------
In both OpenClassReader and ForbiddingRuleReader, tagger_data_pointer_ is equal to tagger_data_pointer.
Strangely, errors do not result immediately, even though the pointer is clearly invalid.
Breakpoint 3, ArrayTagReader::operator() (this=0x7fffffffd640) at array_tag_reader.cc:12
12 void ArrayTagReader::operator()() {
(gdb) print *tagger_data_pointer_
$3 = {_vptr.TaggerData = 0x62a730, open_class = std::set with 0 elements, forbid_rules = std::vector of length 275736, capacity -17591907707330 = {{tagi = -1972060027,
[. . .]
However, upon the first call of TagIndexReader::operator(), the program encounters a segmentation fault, specifically SIGSEGV. It's no surprise; though TagIndexReader's tagger_data_pointer_ is valid, a great part of the TaggerDataUnigram object was compromised.
Breakpoint 4, TagIndexReader::operator() (this=0x7fffffffd650) at tag_index_reader.cc:7
7 void TagIndexReader::operator()() {
(gdb) print tagger_data_pointer_
$16 = (TaggerData *) 0x7fffffffd8c0 <---------- This is the correct value.
(gdb) print *tagger_data_pointer_
$17 = {_vptr.TaggerData = 0x41e5b0 <vtable for TaggerDataUnigram+16>,
open_class = std::set with 6467592 elements<error reading variable: Cannot access memory at address 0x5200000051>,
Why is tagger_data_pointer being copied incorrectly? Why does the program not encounter a segmentation fault immediately after trying to write to invalid memory? How can I resolve this issue?
Thank you for your time.
Update:
These might be useful:
void ArrayTagReader::operator()() {
std::wstring array_tag = Compression::wstring_read(
tagger_data_file_reference_);
tagger_data_pointer_->getArrayTags().push_back(array_tag);
}
void ReadForNumberToRead(
FILE* tagger_data_input_file_reference,
Reader* pointer_to_a_reader) {
for (int unsigned number_to_read =
Compression::multibyte_read(tagger_data_input_file_reference);
number_to_read != 0;
--number_to_read) {
pointer_to_a_reader->operator()();
}
}
Update:
Somehow, I missed the declaration of tagger_data_poiner_ in ArrayTagReader; making the pointers const generated the compiler error that brought this to my attention. What I still don't understand is why:
The compiler didn't complain about the use of an uninitialized pointer.
The program did not encounter a segmentation fault when trying to modify e.g. tagger_data_poiner_->getArrayTags().
"tagger_data_pointer_ does not point to the same location in memory as the TaggerData* tagger_data_pointer the object was constructed with"
That generally means the value has been overwritten. A very common cause is an buffer overflow in the preceding field, or less common an _under_flow in the following field. It also explains why this is a problem that occurs only n one of your two classes; the other class has other neighbors. Still, not all overwrites are buffer over/underflows. Invalid typecasting is another possible problem.
Since you don't mean to change the pointer, do make it const. A second debugging technique is to replace the field with an array of 3 identical copies. Create a function that checks if all three are the same, throws if not, and otherwise return the single value. In the places where you dereferenced the pointer, you now call this check function. This gives you a good chance to detect the exact nature of the change. Even more fancy algorithms add extra padding data with known values.
Despite sharing an identical constructor and being used the same way as ForbiddingRuleReader
I'm not sure why you think these are important, but I can tell you that according to the C++ standard, these have absolutely no relevance concerning whether two types have the same memory layout or whether one can reinterpret_cast (or the moral equivalent) between them.
I was not able to read your code properly as everything but the "UPDATE" is extremely messy and very hard to read for anyone but the author. The UPDATE part seems OK. So I'll just drop by a few tips on copying using pointers (as I recently saw that many people make these mistakes) and maybe it helps.
Make sure you're not just copying from or to a memory location that is not "marked" as allocated. In other words, if you have a pointer and you're just copying data in array to memory location it points to, nothing stops your program or other programs currently running on the computer to modify that area. You first allocate space (using new, malloc etc.) and then you can copy from/to it.
type *p = new type[size];
Even if you've satisfied point 1, make sure copied space doesn't exceed size.
Advice on the question, by comments on it (I can't comment ATM)...
You may be a really good programmer. But you'll make mistakes. Meaning you'll have to find them. Meaning you should keep your code tidy. But there's far more crucial reason for being tidy. People reading your code don't really know where everything "should" be. For them reading a messy code is mission impossible. That's important because someone might have to continue your work for the company on your code. Or if you're looking for help from other programmers, like you're doing right now, you need people to get you.
An indentation should be 1 tab or 4 spaces (you can't use tab on StackOverflow), for every sub-block in your code (covered with { }), unless if the block is empty.
If an instruction is continuing in the next row because of the length, it also deserves an indent. In this case you can also add additional tabs or spaces to make everything look nice. For example, if you have an equation long enough to be separated in 3 rows, you can make every row start from '=' of the first row.
"UPDATE" section looks much better than the rest, but you should still use 4-space indent instead of 2-space indent.
I am new to LLDB and I am working with various std::vectors in my code, however when I try to print the values of a vector or to query the size of my vector with something like expr '(int)myVector[0]' or expr '(int)myVector.size()' the debugger prints values that have nothing to do with the values I know there are in the vector.
As I'm learning to debug with command line and LLDB, I'm sure I'm missing something here, can anyone spot my error or give some advise?
EDIT Forgot to say that I'm under OS X Mavericks with the latest command-line tools installed.
I found the answer myself. Apparently the overloaded operators like [] are not allowed since they are inlined, see this question for a better explanation on that.
Moreover, I don't know why did I put single quotes for the statement I wanted to evaluate (I'm pretty sure I saw it in other place ... what do they actually mean in LLDB?) like so expr 'printf("Hey")'
So, taking out the quotes and using the answer in the cited question it suffices with something like
expr (int) myVector.__begin_[0]
to get the single value of a position in the vector.
Use p myVector or po myVector. These will print out the contents of your vector (alongside the size) in a couple of different formats.
To print a single value from the vector, you can use something like p (int)myVector[0].
I am doing some debugging of an application that uses boost::spirit. This means that backtraces are very deep and that many of the intermediate layers have function names that take several pages to print. The length of the function names makes examining the backtrace difficult. How can I have gdb limit the length of a function name to 1 or 2 lines? I'd still like the see the full path to the file and line number, but I don't need four pages of template parameters!
I don't think it can be done directly right now. I think it would be a reasonable feature.
However, you can write your own implementation of "bt" in Python and then apply whatever transforms you like. This isn't actually very hard.
I'm using VS2008 to write a program. There's one specific line in my code that causes a numerical error. It is:
Qp[j] = (Cp - Cm)/(Bp + Bm);
Qp is a std::vector. When I comment this line out, the numerical error disappears. I am going through my code line by line to find all the places that access Qp[j]. I was wondering if there was a feature in VS2008 or a linux program that wraps around the executable that can identify every line of code that reads from that section of memory (the specific element in the vector)?
I tried searching online but the keywords I used brought up results relating to global variables.
--- EDIT
Hi all. To those have responded, thank you. Just to clarify my question:
Imagine I have a vector with 5 elements. I'd like to know all the places in my code that use the value stored in element 3 at any point in time during execution. Is there an easy way to do this?
I am not sure if I understand you correctly, but if you comment out that line and the code works then maybe the problem is that line, and you don't need to check others lines.
Maybe in your case you get in the situation where Bp+Bm = 0 (division by zero error).
Qp may not have as many elements as the index j, check the size of Qp.