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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Jaenis

Pages: 1 2 3 [4]
46
General / Memory corruption with fs::Sprite
« on: July 21, 2009, 07:27:55 am »
I got version from SVN and compiled it and now I can link with static libraries. And now nvwa could catch the memory allocation, so that error is gone.

Though it found a memory leak  :wink:

Code: [Select]

C:\Code\Code\SFMLTest>test.exe
Leaked object at 003328C0 (size 4, 00447C0B)
Leaked object at 00332930 (size 212, 004489BA)
*** 2 leaks found

C:\Code\Code\SFMLTest>addr2line -e test.exe 00447C0B 004489BA
C:\Code\Code\Libs\SFML\trunk\src\SFML\Window/Context.cpp:82
C:\Code\Code\Libs\SFML\trunk\src\SFML\Window/WindowImpl.cpp:61



Context.cpp:82:
Code: [Select]
static Context* GlobalContext = new Context; // Never deleted, on purpose

WindowImpl.cpp:59-62:
Code: [Select]
WindowImpl* WindowImpl::New()
{
    return new WindowImplType();
}

That WindowImpl::New gets called from that Context constructor, so that known "never deleted" line seems to be causing both of these leaks.

Would there be any way to actually delete that global context before program exit? Just to make this clean  :D

47
General / Memory corruption with fs::Sprite
« on: July 21, 2009, 05:58:07 am »
Quote from: "Laurent"
Quote
So in short ~ResourcePtr() calls myResource->Disconnect(*this);
which then calls myObservers.erase(&Observer); (where observer is ResourcePtr) and this ends up to deletion of unknown memory addess.

Why "unknown memory address"? This is the address of the ResourcePtr which is being destroyed, I don't see any error there.
Plus, there's no dynamic allocation/deletion involved in this process (except the ones happening in std::set but there's no error there), I don't understand why your tool is reporting something.


I actually debugged this for a while and got into conclusion that this memory was allocated inside of dll, so nvwa could not see it. And therefore it reported unknown memory address deletion when this memory was deleted.
That std::set::erase command was in inl file, so it was compiled for my program and nvwa could track that. (nvwa overwrites new and delete operators, so it couldn't see memory allocation in external library)

So, I assume that this can be ignored now :)

Quote from: "Laurent"
Quote
will get thousands of errors with static libs

I'm curious to see them :)


Here you go, this is with g++ ver 4.3.3
Code: [Select]
C:\Code\Code\SFMLTest>make
g++ -c -o Obj/main.o Src/main.cpp -W -Wall -ISrc -MMD -Werror -ISrc/Lib
g++ -Wl,--enable-auto-import -o test.exe Obj/main.o -lmingw32 -lsfml-graphics-s-d -lsfml-window-s-d -lsfml-system-s-d
c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../libsfml-graphics-s-d.a(Sprite.o): In function `ZN2sf6SpriteC2Ev':
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/Sprite.cpp:38: undefined reference to `__gxx_personality_sj0'
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/Sprite.cpp:38: undefined reference to `_Unwind_SjLj_Register'
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/Sprite.cpp:42: undefined reference to `_Unwind_SjLj_Resume'
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/Sprite.cpp:42: undefined reference to `_Unwind_SjLj_Unregister'
c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../libsfml-graphics-s-d.a(Sprite.o): In function `ZN2sf6SpriteC1Ev':
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/Sprite.cpp:38: undefined reference to `__gxx_personality_sj0'
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/Sprite.cpp:38: undefined reference to `_Unwind_SjLj_Register'
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/Sprite.cpp:42: undefined reference to `_Unwind_SjLj_Resume'
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/Sprite.cpp:42: undefined reference to `_Unwind_SjLj_Unregister'
...snip...
c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../libsfml-graphics-s-d.a(Sprite.o): In function `ZNSt8_Rb_treeIPN2sf11ResourcePtrINS0_5ImageEEES4_St9_IdentityIS4_ESt4lessIS4_ESaIS4_EE8_S_valueEPKSt18_Rb_tree_node_base':
D:/Programmes/CodeBlocks/bin/../lib/gcc/mingw32/3.4.4/../../../../include/c++/3.4.4/bits/stl_tree.h:(.text$_ZNSt8_Rb_treeIPN2sf11ResourcePtrINS0_5ImageEEES4_St9_IdentityIS4_ESt4lessIS4_ESaIS4_EE14_M_create_nodeERKS4_[std::_Rb_tree<sf::ResourcePtr<sf::Image>*, sf::ResourcePtr<sf::Image>*, std::_Identity<sf::ResourcePtr<sf::Image>*>, std::less<sf::ResourcePtr<sf::Image>*>, std::allocator<sf::ResourcePtr<sf::Image>*> >::_M_create_node(sf::ResourcePtr<sf::Image>* const&)]+0xc): undefined reference to `__gxx_personality_sj0'
..snip..
c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../libsfml-graphics-s-d.a(RenderWindow.o): In function `ZN2sf12RenderWindowC2Ev':
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/RenderWindow.cpp:41: undefined reference to `__gxx_personality_sj0'
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/RenderWindow.cpp:41: undefined reference to `_Unwind_SjLj_Register'
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/RenderWindow.cpp:41: undefined reference to `_Unwind_SjLj_Resume'
D:/Programmation/Cpp/SFML/tags/1.5/src/SFML/Graphics/RenderWindow.cpp:41: undefined reference to `_Unwind_SjLj_Unregister'
..snip...

Seems that all errors are for undefined references to '__gxx_personality_sj0', '_Unwind_SjLj_Register', '_Unwind_SjLj_Resume' and '_Unwind_SjLj_Unregister'


Since that looks quite a lot like version error with compilers (SFML was compiled with ver 3.4.4 and mine is 4.3.3) I tried to compile with version 3.4.5, here's that:
Code: [Select]

C:\Code\Code\SFMLTest>g++ --version
g++ (GCC) 3.4.5 (mingw-vista special r3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

C:\Code\Code\SFMLTest>make
g++ -c -o Obj/main.o Src/main.cpp -W -Wall -ISrc -MMD -Werror -ISrc/Lib
C:/Code/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/SFML/System/ResourcePtr.inl: In destructor `sf::ResourcePtr< <template-parameter-1-1> >::~ResourcePtr() [with T = sf::Image]':
Src/main.cpp:159:   instantiated from here
C:/Code/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/SFML/System/ResourcePtr.inl:68: error: no matching function for call to `sf::Image::Disconnect(sf::ResourcePtr<sf::Image>* const) const'
C:/Code/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/SFML/System/Resource.inl:86: note: candidates are: void sf::Resource<T>::Disconnect(sf::ResourcePtr<T>&) const [with T = sf::Image]
make: *** [Obj/main.o] Error 1

Somehow it won't even compile :)

Maybe if I grab a version from SVN and compile that, then I probably could link it. Worth a try...

48
General / Memory corruption with fs::Sprite
« on: July 20, 2009, 07:18:41 pm »
I am using nvwa to track memory leaks and Sprite class (or Resource) seems delete a pointer twice when it goes out of scope.

I have following program
Code: [Select]

#include <SFML/Graphics.hpp>

int main()
{
// Create the main window
sf::RenderWindow App(sf::VideoMode(800, 600), "SFML window");

// Load image
sf::Image Image;
if (!Image.LoadFromFile("Image.png"))
return EXIT_FAILURE;

// Own context to isolate the error
{
// Create sprite
sf::Sprite Sprite(Image);
}  // Double deletion here

return EXIT_SUCCESS;
}


On the marked line nvwa will kill the application because deletion of unknown memory address.

I compiled this in MinGw 4.3.3 with SFML_DYNAMIC flag and I am using dynamic libraries (will get thousands of errors with static libs)
SFML version is 1.5, using debug versions (no change if I use non-debug)

Here's backtrace from gdb
Code: [Select]

...std stuff removed...
#9  0x004be99c in std::set<sf::ResourcePtr<sf::Image>*, std::less<sf::ResourcePtr<sf::Image>*>, std::allocator<sf::ResourcePtr<sf::Image>*> >::erase (this=0x22feac, __x=@0x22fae4)
    at c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../../include/c++/4.3.3-dw2-tdm-1/bits/stl_set.h:448
#10 0x00470a3e in sf::Resource<sf::Image>::Disconnect (this=0x22feac,Observer=@0x22fe94)
    at c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../../include/SFML/System/Resource.inl:87
#11 0x0046cc09 in ~ResourcePtr (this=0x22fe94)
    at c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../../include/SFML/System/ResourcePtr.inl:68
#12 0x0046cd95 in _fu0___ZTVN2sf6SpriteE ()
    at c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../../include/SFML/Graphics/Sprite.hpp:45
#13 0x004017d0 in main () at Src/main.cpp:17


So in short ~ResourcePtr() calls myResource->Disconnect(*this);
which then calls myObservers.erase(&Observer); (where observer is ResourcePtr) and this ends up to deletion of unknown memory addess.
Quite weird...

Pages: 1 2 3 [4]
anything