Problem mit Chooser (Exec List) - Src angehängt

[Cyborg]

Glückwunsch zum Eigenfund des Problems Ich habe den Thread dummerweise auch erst jetzt gelesen, als ich die Lösung schreiben wollte

Ein paar (konstruktiv gemeinte) Anmerkungen noch zu Deinem Code, damit ich nicht ganz umsonst reingeschaut hab

1) Bitte solche Initialisierungsstunts, wie

Code: Alles auswählen

struct List bla;
NewList(&bla);

in Zukunft vermeiden (Interfaces aus Faulheit weggelassen). Sowas geht nämlich davon aus, daß der Compiler zur Überetzungszeit genau weiß, wie groß denn "struct List" eigentlich ist und daß er den allokierten Speicherbereich auch sauber initialisiert. In Zukunft sollen die Systemstrukturen aber privat werden und dann weiß der Compiler gar nichts mehr darüber. Eine Änderung in den Strukturen würde sehr wahrscheinlich zum Absturz führen. Daher bitte exec.library/AllocSysObject() und exec.library/FreeSysObject() für sowas benutzen (gibt auch ähnliche Funktionen in der dos.library und in Zukunft wohl noch anderswo). Das sieht dann ungefährt so aus:

Code: Alles auswählen

struct List *bla = NULL;
bla = (struct List *)AllocSysObjectTags(ASOT_LIST, TAG_DONE);

/* Nodes allokieren, hinzufügen, entfernen, freigegeben */

FreeSysObject(ASOT_LIST, bla); /* Die Liste MUSS hier bereits leer sein! */
bla = NULL;

2) Es gibt diverse vordefinierte Makros, um den ganzen

Code: Alles auswählen

NewObject(NULL, ...., TAG_DONE) 

Krempel etwas übersichtlicher zu machen. Ist im Prinzip Geschmackssache, aber ich persönlich finde sowas

Code: Alles auswählen

LAYOUT_AddChild, HGroupObject,
   LAYOUT_AddChild, ChooserObject,
      GA_ID, ...,
   ChooserEnd,
EndHGroup,

zumindest etwas übersichtlicher, als das vollausgeschriebene Zeug.

3) Der wichtigste Punkt zuletzt, den ich auch erst lernen mußte

MEMF_SHARED ist in 99% der Fälle absolut unnötig und sinnlose Speicherverschwendung, denn: MEMF_SHARED impliziert einen Lock des angeforderten Speicherbereichs(*). Das heißt, daß dieser Speicher nicht durch den Pager ausgelagert werden kann, was gerade auf Maschinen mit arg beschränkten Arbeitsspeicher (Classics!) einen enormen Nachteil darstellt und daher wirklich nur in absolut notwendingen Fällen gemacht werden sollte.

Wann ist also MEMF_SHARED tatsächlich notwendig? Antwort: Nur dann, wenn der Speicher in Interrupts genutzt werden soll (Obacht! Dazu gehört auch das Scheduling, sprich Task-Strukturen müssen auch gelockt sein!). ALLES andere kann und sollte mit MEMF_PRIVATE angefordert werden, denn hier macht es nichts aus, ob irgendeine Struktur erst vom Pager wieder geholt werden muß. Dauert dann halt nur etwas länger.

Einzige Ausnahme von dieser Regel betrifft Situationen, wo ein Forbid() nicht gebrochen werden darf. Denn der Pager würde das Forbid() brechen (Nebenbei: Forbid() bitte auch nur sehr sparsam einsetzen, wenn unbedingt nötig!).

Also nochmal zusammenfassend:

• MEMF_SHARED für Speicher, der in Interrupts oder während des Schedulings benutzt werden muß oder dessen Nutzung ein Forbid() nicht brechen darf.
• MEMF_PRIVATE für alles andere!

Leider wird dies von kaum einen Programmierer beachtet, was mit ein Grund ist, warum die Classics mit ihren 128MB so elends aus dem letzten Loch pfeiffen.


So, das war's mit dem kleinen Exkurs ins neue Speichersystem für heute, liebe Kinder. Jetzt könnt Ihr ja.. abschalten

Ach, die Fußnote fehlt noch:

(*) Alles unter 8KB passt in einen Slaballokator und wird sowieso nicht ausgelagert. Ab 8KB Größe wird aber ausgelagert, was nur mit nicht-gelocktem Speicher möglich ist. Bei MEMF_SHARED wird implizit gelockt, was - falls man semantisch absolut korrekt sein will - eigentlich bedeutet, daß man vor einem FreeVec() von MEMF_SHARED Speicher eigentlich erst ein Unlock() aufrufen müßte! Glücklicherweise wird solcher MEMF_SHARED nach FreeVec() auch aus dem Mapping genommen, wodurch das Locking nicht mehr ins Gewicht fällt. Ruft man allerdings explizit Lock() auf oder setzt AVT_Lock, TRUE - insbesondere bei kleinen Speicherbereichen -, dann muß man auch zwingend Unlock() aufrufen.

[ShawnBaxe]

@Cyborg

Danke - aber so ganz alleine hab ich den Fehler nicht gefunden. Da hatte ich (siehe vorherige Seiten des Threads) tatkräftige Hilfe

Auch Dir viele Dank für die Erklärungen - ich werde versuchen mir das zu merken und werde auch direkt entsprechende Änderungen in meinem Quellcode vornehmen.

[ShawnBaxe]

@Cyborg

Also ich habe jetzt versucht die Exec Listen, die letztlich den Inhalt des aktuallen Verzeichnisses (pro ListBrowser) vorhalten sollen per IExec->AllocSysObjectTags() zu initialisieren (im Konstruktor der Klasse - in der Klassendeklaration kann und darf man in C++ keine Initialisierungen vornehmen).
Das Ergebnis ist ein gnadenloser Crash. Scheint allerdings an UAE zu liegen. Anders kann ich mir das nicht erklären. Ich bekomme jedes Mal einen DSI beim Testen. Habe auch AllocSysObject() versucht. Außerdem habe ich probiert innerhalb einer Methode sowas zu machen. Das Ende vom Lied (laut Stacktrace): genau die Methode verursacht dann einen DSI. Das passiert übrigens nur, wenn ich Exec-Listen anlege - mit Message-Ports etc. geht alles gut.

So ähnlich sieht das bei mir aus:

Header

Code: Alles auswählen

class Gui
{
    private:
        struct List    *m_FilesLeft;
        struct List    *m_FilesRight;

    ....
};

Source

Code: Alles auswählen

Gui:Gui()
{
    m_FilesLeft  = (struct List *)IExec->AllocSysObjectTags(ASOT_LIST, TAG_DONE);
    m_FilesRight = (struct List *)IExec->AllocSysObjectTags(ASOT_LIST, TAG_DONE);
}

Auch die Listen vorher mit NULL zu initialisieren hat nichts gebracht.

Was mich zu folgendem bringt:

@Blackbird

Wie hattest Du Dir das mit der Leihgabe des Amiga vorgestellt, sofern das Angebot noch steht? Ich wohne ja nicht so ganz um die Ecke und habe derzeit auch leider keinen PKW. Nachdem ich festellen muss, dass UAE noch relativ instabil ist, wäre es letztlich doch sinnvoller echte Hardware für die Entwicklung zu nutzen.
Ich mache mir da halt etwas Sorgen, weil wir hier ja nicht von einer Tüte Haribo, sondern von sauteurer Hardware sprechen.

[Blackbird]

Ahhh, kommst du also langsam zur Vernunft, oder haben dir die anderen gut zugeredet

Na ja,
ich will das hier aber nicht öffentlich diskutieren, keine Bange das wird nichts bürokratisches, und ich merke auch nochmals an, das die Kiste von der Reperatur noch nicht da ist, und ich nicht weis wann sie wieder bei mir ist ! (nur so als Anmerkung nochmal erwähnt).....

Ich warte da noch auf einen Anruf

Sicherlich ist die Kiste was wert das eine Haribotüte übersteigt, aber ich denke das kann ich verantworten wenn ich sie dir "borge"

Sobald ich was weis, PM ich dich an, das kann schnell gehen, kann aber auch noch etwas dauern !!!


Ps:
Entgegen meiner Behauptung das auf der Kiste kein OS4.1 FE drauf ist, kannst du davon ausgehen das es bis dahin dann doch drauf ist.....Wir sind hier scheinbar gut vernetzt, da klappt das

[Cyborg]

@ ShawnBaxe

Hast Du in gui.h GetVolumeListPtr() auch umgebaut, so daß sie dir direkt m_Volumes und nicht die Referenz &m_Volumes zurückgibt?

An UAE liegt das m. E. nicht, denn AllocSysObject() wird überall im System genutzt, auch und gerade für Listen. Würde es also an UAE liegen, würde das System wohl gar nicht erst hochfahren. Deshalb tippe ich auf einen kleinen Fehler, wie oben. Ein richtiger Amiga würde damit nämlich genauso abstürzen.. kann aber nicht schaden, einen richtigen Amiga zu haben

[ShawnBaxe]

@Cyborg

m_Volumes habe ich gar nicht angefasst. Ich habe es, wie oben beschrieben, mit zwei anderen Listen gemacht. Interessant ist folgendes:

Als ich noch das Problem mit den Volumelisten im Chooser hatte, schmierte es auch ab - auf einem "echten" Amiga dagegen kam zwar Unsinn in den Choosern an, aber das Programm schmierte nicht ab (siehe Beitrag #3 im Thread). Und der Code war auf beiden Systemen exakt der gleiche. Darum komme ich auf UAE als mögliche Ursache.

[Blackbird]

Das könnte nur Glück gewesen sein das an der Adresse was stand was verwertbar war....

Das sieht man auch teilweise an der Ausgabe die du erwähnst...
Kann gut gehen, muß aber nicht. Wenn du Pech hast gibt das einen Systemfreeze vom feinsten

[Cyborg]

@ShawnBaxe

Ah, sorry, hab ich irgendwie überlesen, daß Du andere Listen genommen hast. Wie auch immer, ich würde auf jeden Fall prüfen, ob Du auch immer die richtigen Zeiger auf die Listen übergibst (AddTail(), etc.), das scheint mir das wahrscheinlichste Problem.

Du könntest auch den aktuellen Code mal hier anhängen, dann wäre die Diagnose viel einfacher und ggf. kommt tatsächlich heraus, daß es aus irgendeinem Grund an UAE liegt.. ist ja auch noch nicht ausgereift, die PPC-Emu von UAE.

[ShawnBaxe]

Okay...also das ist interessant. Ich habe UAE nochmal komplett geschlossen, erneut gestartet und das Programm gestartet - kein Absturz. Ich bekomme das Gefühl, dass UAE irgendwie Mist bei der Speicheremulation macht. Es sieht so aus, als müsste ich UAE komplett neu starten, nachdem ich einen Crash hatte, da er ansonsten alles durcheinanderwürfelt. Fazit: UAE PPC (QEMU) ist zumindest momentan sehr unzuverlässig, was das schreiben von Software relativ schwierig macht
Trotzdem hänge ich hier mal den aktuellen Code an (ist nicht übermäßig sauber geschrieben und aufgebaut, denke ich, aber daran arbeite ich noch )

Das Archiv entspricht der aktuellen Revision 14.

Achtung: bei Auswahl eines Volumes öffnet sich eine Konsole, die dessen Inhalt ausgibt. Ist als Test gedacht, um zu sehen, ob ich genug Hirnmasse habe, um die entsprechenden Daten via dos.library zu holen

[ShawnBaxe]

Brauche nochmal Hilfe (wird wohl nicht das letzte Mal sein )

Also...ich hole mir den Inhalt eines Verzeichnisses für die Listbrowser Gadgets mit ExamineDir. Wenn ich jetzt die Protection abfrage, bekomme ich natürlich eine Bit Mask zurück. Als String ist das eine Reihe von 2 und 0. Bin jetzt nicht so der studierte Typ Ich möchte den Spaß gerne in "lesbarer" Form (z.B. ----RWED oder H---RWED - je nachdem welche Flags gesetzt sind) haben. Wie gehe ich da am besten vor? Momentan hole ich mir quasi ja die Bitmaske und schiebe sie in einen stringstream und von da aus in einen string - was natürlich unsinnig ist, ohne die Daten vorher zu verarbeiten.