Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: GDB: Pointer being freed was not allocated  (Read 8711 times)

0 Members and 1 Guest are viewing this topic.

ErikPerik

  • Newbie
  • *
  • Posts: 19
    • View Profile
GDB: Pointer being freed was not allocated
« on: November 05, 2010, 04:50:51 pm »
I just downloaded the example from the tutorials on SFML 1.6 on networks and selectors and it compiles and runs fine on my Macbook using Xcode. However, when I have connected a client and start sending messages to the server, I get the following message from GDB (From the server):

Quote
*** set a breakpoint in malloc_error_break to debug
Server(1447) malloc: *** error for object 0xa0061db0: pointer being freed was not allocated


The error appears to originate from this line:

Code: [Select]

// Else, it is a client socket so we can read the data he sent
                sf::Packet Packet;
                if (Socket.Receive(Packet) == sf::Socket::Done)
                {
// Extract the message and display it
                    std::string mess;
                    Packet >> mess;
                    std::cout << "A client says: \"" << Message << "\"" << std::endl;


To be more precise, when this line is present:

Code: [Select]
Packet >> mess;

I have not made any other alterations to the code posted here: http://www.sfml-dev.org/tutorials/1.6/sources/network-packets.cpp

Is this a bug in SFML 1.6?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
GDB: Pointer being freed was not allocated
« Reply #1 on: November 05, 2010, 04:54:42 pm »
I don't think it's a bug. You're the first one to report it, and the sf::Packet class can hardly contain such a bug.

Would you be able to investigate further? Maybe you can break at the position of the error, and display the call stack?
Laurent Gomila - SFML developer

ErikPerik

  • Newbie
  • *
  • Posts: 19
    • View Profile
GDB: Pointer being freed was not allocated
« Reply #2 on: November 05, 2010, 05:21:05 pm »
I don't know how to copy the stacktrace, but here is what I get when I set the breakpoint: "malloc_error_break"



The error appears to originate from the assign:ment of the string to my string inside Packet's operator>>. Any ideas?

EDIT: The error disappears if I replace the "std::string mess" with "char foo[300]", so it must be an error in how Packet takes care of std::string.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
GDB: Pointer being freed was not allocated
« Reply #3 on: November 05, 2010, 06:00:23 pm »
Thanks :)

That's weird because std::string and char[] are handled exactly the same way. Can you check the value of the Length variable in operator >>, when the error happens?
Laurent Gomila - SFML developer

ErikPerik

  • Newbie
  • *
  • Posts: 19
    • View Profile
GDB: Pointer being freed was not allocated
« Reply #4 on: November 05, 2010, 06:16:49 pm »
Which Length variable do you mean? I printed the value of "Packet.GetDataSize()" for the received string "Hello world" and got 15, and "Hello world".size() which is 11. Could this be of interest?

I'm thinking it might be that you're memcpy:ing the data in operator>> for char-arrays but only assigning the raw data for std::strings, but this might be handled automatically by std::string itself?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
GDB: Pointer being freed was not allocated
« Reply #5 on: November 05, 2010, 06:32:13 pm »
Quote
Which Length variable do you mean?

The one at the beginning of sf::Packet::operator >>(std::string&).

Quote
I printed the value of "Packet.GetDataSize()" for the received string "Hello world" and got 15, and "Hello world".size() which is 11. Could this be of interest?

Nop, this is perfectly ok. The 4 extra bytes are for storing the size of the string.

Quote
I'm thinking it might be that you're memcpy:ing the data in operator>> for char-arrays but only assigning the raw data for std::strings, but this might be handled automatically by std::string itself?

Yes.
Laurent Gomila - SFML developer

ErikPerik

  • Newbie
  • *
  • Posts: 19
    • View Profile
GDB: Pointer being freed was not allocated
« Reply #6 on: November 05, 2010, 07:04:25 pm »
I am a bit new to debuggin with GDB, how would I go about getting the value of the Length variable, when I have put a breakpoint over the "Packet >> mess;"-line?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
GDB: Pointer being freed was not allocated
« Reply #7 on: November 05, 2010, 07:08:41 pm »
I don't know the XCode debugging interface at all. Usually, you have a "watch" window where you can add variables and see their values. Maybe you can also move the mouse cursor over the variable, to see its value in a small popup (Visual Studio does that).
Laurent Gomila - SFML developer

ErikPerik

  • Newbie
  • *
  • Posts: 19
    • View Profile
GDB: Pointer being freed was not allocated
« Reply #8 on: November 05, 2010, 08:06:01 pm »
I'm having trouble viewing the contents of that specific variable, it appears that it is out of context for the debugger.

Ignoring the Xcode GUI and only using the GDB console I have added a breakpoint at "Packet >> mess;" and used the command "up" to set the current context to "#6  0x000add0e in sf::Packet::operator>> ()", and from there I should be able to "print Length", but it says "No symbol "Length" in current context.".

And in the GUI that particular method (and all above it) (talking about #6   0x000add0e in sf::Packet::operator>>), when I have selected it, I can't view Local variables, only "Globals" and "Registers". Any ideas?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
GDB: Pointer being freed was not allocated
« Reply #9 on: November 05, 2010, 08:47:54 pm »
Sorry, I can't help you.

Maybe you can recompile SFML with some std::cout inside, to print what the debugger can't show you?
Laurent Gomila - SFML developer

bastien

  • Full Member
  • ***
  • Posts: 231
    • View Profile
    • http://bastien-leonard.alwaysdata.net
GDB: Pointer being freed was not allocated
« Reply #10 on: November 06, 2010, 02:54:59 am »
You can use the print command in gdb to show the values of data, e.g. “print ptr->some_value”. However I'm not sure it will handle any C++ expression. See http://sourceware.org/gdb/current/onlinedocs/gdb/C-Plus-Plus-Expressions.html#C-Plus-Plus-Expressions.
Check out pysfml-cython, an up to date Python 2/3 binding for SFML 2: https://github.com/bastienleonard/pysfml-cython

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
GDB: Pointer being freed was not allocated
« Reply #11 on: November 06, 2010, 11:50:57 am »
I hope this can help you to solve the free-issue :

declare the following macro
_GLIBCXX_FULLY_DYNAMIC_STRING=1

More information here : http://stackoverflow.com/questions/2234557/c-using-getline-prints-pointer-being-freed-was-not-allocated-in-xcode .
SFML / OS X developer

ErikPerik

  • Newbie
  • *
  • Posts: 19
    • View Profile
GDB: Pointer being freed was not allocated
« Reply #12 on: November 07, 2010, 09:46:08 pm »
@Hiura: This did not solve the problem for me. It can be that I applied the setting incorrectly (I added the line _GLIBCXX_FULLY_DYNAMIC_STRING=1 to the "Preprocessor macros" in the target settings Build tab, like it said). Unfortunately.

And I did not get GDB to print out the contents of the Length variable.

cloakdood

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: GDB: Pointer being freed was not allocated
« Reply #13 on: January 05, 2013, 08:32:41 am »
I have come across the exact same issue. The only way I have found to circumvent it is to compile and use SFML 2.0, unfortunately.

I apologize if a solution has been posted elsewhere, but this was the first hit in google and I would like others to see it if they have the same issue.