CODEWITHSUNDEEP
c++g++
lord.didger
lord.didger

Reputation: 1407

g++ misunderstands c++ semantics

There are two possible solutions to the problem: I don't understand the c++ semantics or g++ does.

I am programming a simple network game now. I have been building a library the game uses to communicate over the network. There is a class designated to handle the connection between the apps. Another class implements server functionality so it possess a method accept(). The method is to return a Connection class.

There are a few way to return the class. I have tried these three:

Connection accept() {
...
return Connection(...);
}

Connection* accept() {
...
return new Connection(...);
}

Connection& accept() {
...
Connection *temp = new Connection(...);
return *temp;
}

All three were accepted by g++. The problem is that the third is somewhat faulty. When you use internal information of the object of type Connection, you will fail. I don't know what is wrong because all fields within the object look like initiasized. My problem is that when I use any function from protocol buffers library my program is terminated by Segmentation fault. The function below fails every it calls the protobuf library.

 Annoucement Connection::receive() throw(EmptySocket) {
    if(raw_input->GetErrno() != 0) throw EmptySocket();
    CodedInputStream coded_input(raw_input);
    google::protobuf::uint32 n;
    coded_input.ReadVarint32(&n);
    char *b;
    int m;
    coded_input.GetDirectBufferPointer((const void**)&b, &m);
    Annoucement ann;
    ann.ParseFromArray(b, n);
    coded_input.Skip(n);
    return ann;
  }

I get this every time:

Program received signal SIGSEGV, Segmentation fault. 0x08062106 in google::protobuf::io::FileInputStream::CopyingFileInputStream::GetErrno (this=0x20) at /usr/include/google/protobuf/io/zero_copy_stream_impl.h:104

When I changed the accept() to the second version, it finnaly worked (the first is good too but I modified conception in the meanwhile).

Have you come across any problem that is similiar to this one? Why the third version of accept() is wrong? How should I debug the program to find such a horrible bug (I thought protobuf need some fix whereas the problem was not there)?

Upvotes: 1

Views: 386

Answers (3)

Erik Olson
Erik Olson

Reputation: 1164

You overlooked raw_input=0x20 which is obviously an invalid pointer. This is in the helpful message you got in the debugger after the segfault.

For general problems of this type, learn to use Valgrind’s memcheck, which gives you messages about where your program abused memory.

Meanwhile I suggest you make sure you understand pass by value vs pass by reference (both pointer and C++ reference) and know when constructors, copy constructors and destructors are called.

Upvotes: 0

Chris Card
Chris Card

Reputation: 3266

"How should I debug the program to find such a horrible bug?" If you are on Linux try running under valgrind - that should pick up any memory scribbling going on.

Upvotes: 1

Mark B
Mark B

Reputation: 96301

First, returning by reference something allocated on the heap is a sure recipe for a memory leak so I would never suggest actually doing that.

The second case can still result in a leak unless the ownership semantics are very well specified. Have you considered using a smart pointer instead of a raw pointer?

As for why it doesn't work, it probably has to do with ownership semantics and not because you're returning by reference, but I can't see a problem in the posted code.

Upvotes: 3

Related Questions