Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

SFGUI bad alloc

Werbeanzeige

Nimelrian

Alter Hase

Beiträge: 1 216

Beruf: Softwareentwickler (aktuell Web/Node); Freiberuflicher Google Proxy

  • Private Nachricht senden

11

18.09.2015, 00:13

Gerade mit SFML 2.3.1 und SFGUI 0.3.0 getestet, Compiler MSVC12 (VS2013). Gebaut in Release-Config, da das ganze im Debug Modus ewig braucht, um hochzulaufen. Bei mir knallte es nach 176217 Frames, ebenfalls mit einem bad_alloc. Bei einem zweiten Versuch bei Frame 177856.

Was mir aufgefallen ist: In der Release-Config bleibt die RAM-Nutzung relativ konstant, in der Debug-Config steigt sie allerdings pro Sekunde um ~0.5MB. Ich forsche mal noch ein bisschen nach.

Update: Wenn ich im Debug Build am Ende die Memory Leaks per _CrtDumpMemoryLeaks() checke, bekomme ich sehr, sehr viel Output. Im normalen SFML Test (Grüner Kreis) bekomme ich auch welche, aber bei weitem nicht so viele.
Ich bin kein UserSideGoogleProxy. Und nein, dieses Forum ist kein UserSideGoogleProxyAbstractFactorySingleton.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Nimelrian« (18.09.2015, 00:34)

Nimelrian

Alter Hase

Beiträge: 1 216

Beruf: Softwareentwickler (aktuell Web/Node); Freiberuflicher Google Proxy

  • Private Nachricht senden

12

18.09.2015, 00:59

Doppelpost da Erkenntnisgewinn und das sonst nicht von jedem gesehen wird:

Habe das Problem inzwischen auf die beiden table->Attach() Calls runterbrechen können. Ohne diese gibt es keinen bad_alloc. Sobald nur einer drin ist, knallt es irgendwann.
Edit: Auskommentieren von desktop.Update( 1.0f ); führt ebenfalls zu keinem bad_alloc.
Edit 2:
Habe das Ganze nochmal etwas runtergebrochen. Man beachte die auskommentierte Zeile. Auskommentiert gibt es keinen bad_alloc, ansonsten schon. Es gibt aber noch weitere Kombinationen, die auf dem einen Weg irgendwann einen bad_alloc generieren, und auf einem anderen Weg nicht.

Alles sehr komisch.
Ich würde da eigentlich schon sagen, dass irgendwo in SFML oder SFGUI ein Fehler vorliegt.

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

int main()
{
    sf::VideoMode video_mode{ 200, 200 };
    sf::RenderWindow window{ video_mode, "Test" };
    window.resetGLStates();
    sfg::SFGUI sfgui;
    sfg::Desktop desktop;
    sf::Event event;

    sfg::ScrolledWindow::Ptr scroled_window = sfg::ScrolledWindow::Create();
    sfg::Table::Ptr table = sfg::Table::Create();
    sfg::Button::Ptr button = sfg::Button::Create( "Test" );
    sfg::ProgressBar::Ptr bar = sfg::ProgressBar::Create();

    table->Attach( button, sf::Rect < sf::Uint32 > {0, 0, 2, 1} );
    table->Attach( bar, sf::Rect < sf::Uint32 > {1, 1, 1, 1} );

    scroled_window->AddWithViewport( table );
    desktop.Add( scroled_window );

    size_t frameCount = 0;

    while ( window.isOpen() )
    {
        while ( window.pollEvent( event ) )
        {
            desktop.HandleEvent( event );
            if ( event.type == sf::Event::Closed )
            {
                window.close();
            }
        }

        //bar->SetFraction( 1.0f );

        desktop.Update( 1.0f ); // Time 1 second
        window.clear( sf::Color{ 50, 50, 50 } );
        sfgui.Display( window );
        window.display();

        frameCount++;
        std::cout << frameCount << std::endl;
    }
}
Ich bin kein UserSideGoogleProxy. Und nein, dieses Forum ist kein UserSideGoogleProxyAbstractFactorySingleton.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Nimelrian« (18.09.2015, 04:06)

Volker_Neff

Treue Seele

  • »Volker_Neff« ist der Autor dieses Themas

Beiträge: 249

Wohnort: Hamburg

  • Private Nachricht senden

13

18.09.2015, 12:27

Oh da bin ich ja froh das nicht nur ich diesen Fehler habe. Ich glaube jedoch nicht das es an dem Table liegt. Ich habe ein zweites Konstrukt welches nur aus einem Table und einem Button besteht. Hier kann ich unendlich Updates ausführen. Wobei Unendlich hierbei etwa 8 Stunden bedeutet.
Was diese Funktion desktop.Update( 1.0f ); macht habe ich noch nicht so ganz verstanden da SFGUI keine Animationen zur Verfügung stellt.

Zitat von »Nimelrian«

Edit: Auskommentieren von desktop.Update( 1.0f ); führt ebenfalls zu keinem bad_alloc.

Hattest du sonst irgendwelche Nachteile durch das Auskommentieren?

Was ich noch einmal in den Raum werfen möchte ist das das erstellen von dem GUI Layout unglaublich viele Vertices entwickelt. Ich muss zu Hause noch einmal nachgucke wie viele genau aber es sind reichlich mehr als ursprünglich erwartet. Es geht wenn ich mich nicht vertan habe in etwa bis 200.000 wobei ein einfacher Table mit 4 Button nur etwa 300 Vertices sind.

Danke schon einmal für deine Unterstützung @Nimelrian

Edit: @Nimelrian unter welchem System hast du das Programm ausgeführt. Bei mit kann ich gar keinen Debug-Mode verwenden da die .dll von SFML und SFGUI aus irgendwelchen Gründen sich nicht starten lassen mit dem Error das die Bit Versionen nicht übereinstimmen, als es einen Konflikt zwischen 32 Bit und 64 Bit gibt denn ich auch durch neues Kompilieren nicht beheben konnte.

Nimelrian

Alter Hase

Beiträge: 1 216

Beruf: Softwareentwickler (aktuell Web/Node); Freiberuflicher Google Proxy

  • Private Nachricht senden

14

18.09.2015, 12:54

Win 7 64bit, allerdings mit den 32bit Versionen von SFML und SFGUI.
eXpl0it3r konnte es übrigens beim Compilen mit MinGW nicht nachvollziehen.
Ich bin kein UserSideGoogleProxy. Und nein, dieses Forum ist kein UserSideGoogleProxyAbstractFactorySingleton.

eXpl0it3r

Treue Seele

Beiträge: 386

Wohnort: Schweiz

Beruf: Professional Software Engineer

  • Private Nachricht senden

15

18.09.2015, 22:57

Zitat von »Nimelrian«

eXpl0it3r konnte es übrigens beim Compilen mit MinGW nicht nachvollziehen.
Das war mein Fehler, wird wohl schon irgendwann crashen.
Irgendwo gibt es einen Bug, was dazuführt, dass der m_vertex_count immer weiter ansteigt und irgendwann wird das OS keinen genug grossen zusammehängenden Speicherplatz mehr verteilen können und es kommt zum bad_alloc.
binary1248 konnte das Problem reproduzieren und ist jetzt am Suchen woran es liegt. ;)

Das nächste Mal vielleicht direkt im offiziellen SFGUI Forum mit einem minimalen Beispiel vorbei schauen, dann sehen es die betreffenden Leute direkt, ohne langen Umwege über Nimelrian und mich. :D
Blog: https://dev.my-gate.net/
—————————————————————————
SFML: https://www.sfml-dev.org/
Thor: http://www.bromeon.ch/libraries/thor/
SFGUI: https://github.com/TankOs/SFGUI/

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

16

19.09.2015, 09:55

Habt ihr es schonmal mit dem memleak detector von VS versucht? Siehe [Erledigt] Problem mit _CrtDumpMemoryLeaks oder https://msdn.microsoft.com/en-us/library/x98tx3cf.aspx
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Roflo

Alter Hase

Beiträge: 955

  • Private Nachricht senden

17

19.09.2015, 10:20

Zitat von »Nimelrian«

Wenn ich im Debug Build am Ende die Memory Leaks per _CrtDumpMemoryLeaks() checke, bekomme ich sehr, sehr viel Output.

Ja haben sie :P

eXpl0it3r

Treue Seele

Beiträge: 386

Wohnort: Schweiz

Beruf: Professional Software Engineer

  • Private Nachricht senden

18

19.09.2015, 10:33

Die Memoryleaks stammen wahrscheinlich vom Treiber. Läuft alles ohne Memoryleaks bei mir.
Das bad_alloc Problem sollte behoben sein. Einfach mal den neusten Commit auschecken und versuchen.
Blog: https://dev.my-gate.net/
—————————————————————————
SFML: https://www.sfml-dev.org/
Thor: http://www.bromeon.ch/libraries/thor/
SFGUI: https://github.com/TankOs/SFGUI/

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

19

19.09.2015, 13:00

Naja man kann sich ja anzeigen lassen woher diese Memleaks kommen. Dafür halt das "define new" etc. aber ist ja gut, wenn sich das Problem schon erledigt hat :) .
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Roflo

Alter Hase

Beiträge: 955

  • Private Nachricht senden

20

19.09.2015, 13:38

Der Treiber verwendet doch sicher einen anderen Heap als den, welcher mit _crtdumpmemoryleaks gecheckt wird. Und wenn diese funktion viel output lieferte, läge das doch dann nicht am treiber? :hmm:

Werbeanzeige

Ähnliche Themen