Topic: Cheat-Codes für Einzelspieler?

Ja, anhand der Namen, bzw. Dateipfade der fraglichen "Verursacher-Libs" war mir schon klar, dass es sich nicht um unmittelbar aus den widelands-Quellen stammenden Code handelt; gelegentlich werden Bugs indessen ja durch bestimmte Verwendung (die bspw. zum Durchlaufen relevanter Codepfade (ggf. mit schädlichen Argumenten) ausgelöst (wie gesagt: Noobie..).

Wenn speziell diese Speicherlecks (oder was ASan dafür hält - afaik haben solche Werkzeuge ja auch nicht immer Recht..) bereits bekannt sind, gibt es hier vermutlich keinen Grund, das weiterzuverfolgen.

An zwei Stellen sind mir übrigens asserts um die Ohren geflogen:

widelands: /home/dr1fter/src/tmp/widelands/src/graphic/texture.cc:162: virtual Texture::~Texture(): Assertionis_initializer_thread()' failed. Aborted (core dumped) `

dann Folgefehler (nehme ich an), nachdem ich das fragliche assert mit einem try-catch(...) eingeschlossen hatte; ich dachte zumindest, dass das nicht (sofort) fatale Folgen hat, wenn Fehler im Destruktor ignoriert..:

widelands/src/wui/productionsitewindow.cc:284: void ProductionSiteWindow::worker_table_selection_changed(): Assertionworker_type_' failed. Aborted (core dumped) + (nachdem ich das erste assert auskommentiert hatte)widelands/src/wui/productionsitewindow.cc:285: void ProductionSiteWindow::worker_table_selection_changed(): Assertion worker_xp_decrease_' failed. Aborted (core dumped)

Da gehe ich allerdings wirklich mal davon aus, dass das halt ein Entwicklungs-Artefakt ist (trat im Zusammenhang mit der Warenbestandseditierung auf). Mit etwas durchsterben habe ich die Mission dann noch erfolgreich geschafft

Um Missverständnissen vorzubeugen: ich erwarte keinen Support oder Hilfe (für die o.g. Fehler), und mir ist schon klar, dass ich wenn ich will, dass es "einfach nur läuft" halt auf einen freigegebenen Stand zurückgehen, oder selbst fixen muss

sapere aude!

user, advocate, and sometimes developer of free (as in freedom) software

Top

Quote

Bzgl ASan: Also die -d-Option ist ganz neu, bis vor kurzem war Debug mit ASan der Standard und die Optionen -r -a haben das jeweils umgeschaltet. Dass -d ein vorheriges -a überschreibt ist also ein Bug. Übrigens, wenn du einmal mit ASan kompiliert hast kannst du es nicht mehr nachträglich abschalten sondern musst dazu das gesamte Build-Verzeichnis löschen.

ASan hat laut Dokumentation angeblich garantiert immer Recht wenn es Memory Leaks meldet. Allerdings soll es angeblich eine Möglichkeit geben, Leaks aus 3rd-Party-Bibliotheken zu unterdrücken … das muss ich mir mal anschauen.

Bezüglich asserts: Das Texture-Assert ist ein Bug, der im Nachgang des neuen Multithreading-Features noch manchmal nicht-reproduzierbar auftaucht (lies: meine Schuld ), und andere Asserts sind mit hoher Wahrscheinlichkeit auch damit verwandt. Falls du diese Asserts öfter siehst könntest du versuchen sie in gdb zu fangen:

gdb ./widelands
   run
   (... warten bis es ein SIGABRT gibt ...)
   bt
   info threads
   thread N   # N ist dabei die ID des anderen Widelands-Threads – meist hat der eine Thread ID 1 und der andere 23 oder 24
   bt

Die Backtrace beider Threads wäre zum Debuggen enorm hilfreich

Top

Quote

Dass -d ein vorheriges -a überschreibt ist also ein Bug

allerdings einer, den ihr dokumentiert habt (steht in der online-hilfe direkt beim -a dran..):

65 echo " Note: The ASan setting is overridden by setting the build type, so these"
66 echo " options should be given after the build type option, when needed."

kann mal schauen, ob ich eine Korrektur dazu als PR einreiche, wenn gewünscht? So ein paar Zeilen Bourne Shell Script bekomme ich sicherlich noch hin

Gerne

Top

Quote

Caldessa wrote:

Ich würde gerne auch ein wenig rumtüfteln, habe aber so leider gar keine Ahnung wie ich vorgehen muss. Gibts da eine "einfache" Möglichkeit und Beschreibung dazu?

Woran möchtest du denn knobeln? Am Build, oder eher am "richtigen" Code?

Die Quellen findest du auf github.com:

https://github.com/widelands bzw. https://github.com/widelands/widelands

Im CONTRIBUTING.md wird auf das widelands-wiki verwiesen, in dem grob umrissen wird, wie man sich beteiligen kann:

https://www.widelands.org/wiki/Contribute/

Falls du dich tatsächlich speziell für den Build interessierst (das ist ja typischerweise eher ein Rand-Thema^^), könnte vermutlich die Lektüre der Dokumentationen zu CMake und ninja helfen (eher CMake):

https://cmake.org/ https://cmake.org/cmake/help/v3.7/generator/Ninja.html

Wo man eine Referenzdokumentation zur Bourne Shell findet, weiß ich nicht (man findet per Google einiges auf diversen Universitäten). Allerdings gibt es die Referenzdokumentation zur GNU Bourne-Again-Shell (aka bash):

https://www.gnu.org/software/bash/manual/bash.html

Caveat: das shebang im compile.sh verweist explizit auf die bourne-shell. Daher nehme ich an, dass es unerwünscht ist, bash-spezifika zu verwenden (bash ist eine zur bourne-shell kompatible shell mit zu bourne-shell inkompatiblen Erweiterungen (bspw. [[ vs [).

Weiß nicht, ob ich dir damit helfen konnte. Vllt noch ein Hinweis: wenn du vorhast, unter Windows zu entwickeln: davon kann ich aus persönlicher mehrjähriger Erfahrung nur abraten (man macht sich das Leben da schon unnötig schwer..)

sapere aude!

user, advocate, and sometimes developer of free (as in freedom) software

Top

Quote

Caldessa wrote:

Hallo zusammen. Ich würde gerne auch ein wenig rumtüfteln, habe aber so leider gar keine Ahnung wie ich vorgehen muss. Gibts da eine "einfache" Möglichkeit und Beschreibung dazu?

Gruss Caldessa

Wie dr1fter schon schrieb, kommt es darauf an was du ausprobieren möchtest. Falls es um "Cheats" geht, wäre eine Beschäftigung mit unserem Lua Interface hilfreich. (https://www.widelands.org/documentation/lua_index/)
Für ein spezifisches ÜProblem können wir auch den richtigen Einstiegspunkt benennen.
Das gleichze gilt auch für unseren Source Code falls man sich hier beteiligen möchte

Top

Quote