PrettyOS Fehler-/Testthread


  • Mod

    Weiß eigentlich jemand, warum man das damals so entschieden hat? Linux ist ja im Gegensatz dazu case-sensitive.



  • Der Zug bewegt sich bei mir immer unter Bochs nur weiter, wenn ich eine Taste drücke (oder ist das Absicht?).



  • Das ist überall so und liegt nicht an Bochs...


  • Mod

    Der Zug bewegt sich bei mir immer unter Bochs nur weiter, wenn ich eine Taste drücke (oder ist das Absicht?).

    Ja, das hat sich so ergeben, weil wir den inneren Loop nun nicht in der gesamten Shell, sondern nur in getch drehen (siehe Definition von getch in user-Lib). Wir fangen die vom Kernel zurück gegebene 0 dort ab.



  • Unter VirtualBox v3.1.4 r57640 stürtz PrettyOS Rev. 120 ab. Scheinbar geschieht dies, nachdem das Datum ausgegeben wird. Falls jemand interesse an der Log-Datei von VBox hat, ist diese hier zu finden: http://anubis2k5.bplaced.net/VBox.log

    Unter Qemu läuft das OS normal.



  • Das Problem ist bekannt und auch mit Microsoft Virtual PC läuft PrettyOS derzeit nicht, anscheinend gibt es auch Probleme mit einigen echten PCs, die damit vlt. zusammenhängen.


  • Mod

    00:00:03.394 PIT: mode=3 count=0x2e9b (11931) - 100.00 Hz (ch=0)
    00:00:05.612 fatal error in recompiler cpu: triple fault
    00:00:05.612 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    00:00:05.612 !!
    00:00:05.612 !! Guru Meditation -2301 (VERR_REM_VIRTUAL_CPU_ERROR)

    Leider versteht niemand bisher diesen "fatal error".



  • Sooo... Ich hab auch Fehler im Angebot 😉

    1. Page-Fault unter Qemu 0.12.2. Screenshot: http://kloke-witten.dyndns.org/~philipp/Temp/Fehler_Rev125.png

    2. Uhr läuft ca. 2x zu schnell unter Virtual Box 3.1.4

    3. Dieser Fehler ist etwas komplizierter zu beschreiben und ich hab ihn auch schon geschildert, wobei Erhard und ich nicht zu einer Lösung gekommen sind (Im IRC). Bevor das in Vergessenheit gerät, kommt hier die Fehlerbeschreibung (Ich hab das Verhalten auch noch etwas genauer Analysiert):
    Das Problem tritt in Userprogrammen bei der Texteingabe auf. Die Backspace-Taste funktioniert nicht richtig, wenn man versucht, das erste Zeichen der Zeile zu löschen: Es wird das erste Zeichen dieser Zeile und das letzte Zeichen der vorigen Zeile gelöscht. Der Schreibcursor springt dann auch in die vorige Zeile. Testsystem: Virtual Box 3.1.4; Der Fehler tritt meines Wissens nach auch mit anderen Simulationen auf, komischerweise hab aber bislang nur ich ihn reproduzieren können 😕 .

    mfg und in der Hoffnung, das die Fehler gefunden und behoben werden 🙂
    Mr X


  • Mod

    zu 3)
    Das ist der Code von gets:

    char* gets(char* s)
    {
        int i=0;
        char c;
    
        //settaskflag(0);
    
        do
        {
            c = getch();
            putch(c);
            if(c==8)  // Backspace
            {
               if(i>0)
               {
                  s[i-1]='\0';
                  --i;
               }
            }
            s[i] = c;
            i++;
        }
        while(c!=10); // Linefeed
        s[i]='\0';
    
        //settaskflag(1);
    
        return s;
    }
    

    Vielleicht fällt jemand da etwas auf? MrX und Cuervo mäkeln daran herum.

    //settaskflag(0); <--- warum auskommentiert?



  • Nachdem ich mir gets() näher beguckt hab, bin ich zu dem Schluss gekommen, das der Fehler mglw. eher in getch() o.ä. zu suchen ist.

    Abgesehen davon denke ich, das z.20 und 21 von einem else-Block umschlossen werden sollten; Es ist imho wohl eher nicht sinnvoll, Die Felder, wo gelöscht wurde mit dem Wert 8 zu füllen, nachdem man sie grad zuvor mit 0 gefüllt hat.


  • Mod

    Damit geht es nun:

    Testversion:

    char* gets(char* s)
    {
        int i=0,flag=0;
        char c;
        //settaskflag(0);
        do
        {
            c = getch();
            //settextcolor(i,0);///TEST
    
            if(c=='\b')  // Backspace
            {
               if(i>0)
               {
                  putch(c);
                  s[i-1]='\0';
                  --i;
               }
               else
               {
                   beep(50,20);
                   if(flag==false)
                   {
                       putch('\n');
                       flag=true;
                   }
               }
            }
            else
            {
                s[i] = c;
                putch(c);
                flag=false;
                i++;
            }
        }
        while(c!=10); // Linefeed
        s[i]='\0';
    
        settextcolor(15,0);
        int j;
        for(j=0;j<15;j++)
        {
            if(s[j]=='\b')
            {
                puts("backspace");
            }
            else if(s[j]=='\0')
            {
                puts("EOS");
                putch('\n');
                break;
            }
            else if(s[j]=='\n')
            {
                puts("NL");
            }
            else
            {
                putch(s[j]);
            }
            putch('\n');
        }
        //settaskflag(1);
    
        return s;
    }
    

    Ich kommentiere das aus und stelle es hoch. Liegt nicht am TTT, habe es separat mit einem anderen Programm getestet:

    #include "userlib.h"
    
    int main()
    {
        puts("********************************************************************************\n");
        puts("*                                  Eingabe-Test                                *\n");
        puts("********************************************************************************\n");
    
        char str[100];
    	for(int i = 0; i < 5; ++i)
    	{
    	    puts("Bitte Eingabe:\n");
    	    gets(str);
    	    puts(str);
    	}
    	return 0;
    }
    

  • Mod

    zu 1) das liegt an der in Paging neu eingebauten Funktion, die momentan nur ab 0xF0000000 funktioniert. Badestrand untersucht diesen Punkt bereits.

    zu 3) MS VPC läuft ok; Sun VB wirklich merkwürdig mit den Sekunden. 😃

    Man schafft es auch eher, bei Sun VB durch heftiges Drücken der Backspace-Taste in die obere Zeile zu geraten. Bei MS VPC gelingt mir das nicht.

    MS VPC ist für Tests offenbar gar nicht so schlecht geeignet.


  • Mod

    An gets(...) wird immer noch herum gemeckert. 🙄
    Bei mir klappt es soweit. Grund für Probleme liegt vermutlich an anderer Stelle. Eingegebener String kommt sauber an. Rücksprung auf obere Zeile nur selten (muss mit dem Taskwechsel zusammen hängen, den man ja ausschalten kann in der Funktion <--- wurde von MrX getestet: brachte nichts). Mysteriös.



  • Ich hab PrettyOS mal durch cppcheck gejagt. Folgendes Ergebnis kam raus (Irrelevantes à la "use fgets instead of gets" entfernt):

    [elf.c:74]: (style) struct or union member 'elf_header_t::shoff' is never used
    [elf.c:75]: (style) struct or union member 'elf_header_t::flags' is never used
    [elf.c:76]: (style) struct or union member 'elf_header_t::ehsize' is never used
    [elf.c:79]: (style) struct or union member 'elf_header_t::shentrysize' is never used
    [elf.c:80]: (style) struct or union member 'elf_header_t::shnum' is never used
    [elf.c:81]: (style) struct or union member 'elf_header_t::shstrndx' is never used
    [elf.c:101]: (style) struct or union member 'program_header_t::paddr' is never used
    [elf.c:104]: (style) struct or union member 'program_header_t::flags' is never used
    [elf.c:105]: (style) struct or union member 'program_header_t::align' is never used
    [fat12.c:676]: (style) The scope of the variable j can be reduced
    [paging.c:33]: (style) struct or union member '__attribute__::ext' is never used
    [video.c:177]: (style) The scope of the variable temp can be reduced
    [../tools/src/CreateFloppyImage.cpp:30]: (style) struct or union member 'BootSector::ignore1' is never used
    [../tools/src/CreateFloppyImage.cpp:31]: (style) struct or union member 'BootSector::oem_name' is never used
    [../tools/src/CreateFloppyImage.cpp:38]: (style) struct or union member 'BootSector::media_destriptor_byte' is never used
    [../tools/src/CreateFloppyImage.cpp:40]: (style) struct or union member 'BootSector::sectors_per_track' is never used
    [../tools/src/CreateFloppyImage.cpp:41]: (style) struct or union member 'BootSector::head_count' is never used
    [../tools/src/CreateFloppyImage.cpp:42]: (style) struct or union member 'BootSector::hidden_sectors' is never used
    [../tools/src/CreateFloppyImage.cpp:43]: (style) struct or union member 'BootSector::sector_count_ex' is never used
    [../tools/src/CreateFloppyImage.cpp:44]: (style) struct or union member 'BootSector::drive_number' is never used
    [../tools/src/CreateFloppyImage.cpp:45]: (style) struct or union member 'BootSector::ignore2' is never used
    [../tools/src/CreateFloppyImage.cpp:46]: (style) struct or union member 'BootSector::boot_signature' is never used
    [../tools/src/CreateFloppyImage.cpp:47]: (style) struct or union member 'BootSector::volume_serial' is never used
    [../tools/src/CreateFloppyImage.cpp:48]: (style) struct or union member 'BootSector::fs_name' is never used
    [../tools/src/CreateFloppyImage.cpp:50]: (style) struct or union member 'BootSector::bootloader' is never used
    [../tools/src/CreateFloppyImage.cpp:51]: (style) struct or union member 'BootSector::bootloader_sig' is never used
    [../user/user_program_c/userlib.c:418]: (style) The scope of the variable i can be reduced
    [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp1 can be reduced
    [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp2 can be reduced
    [../user/user_program_c/userlib.c:419]: (style) The scope of the variable temp3 can be reduced
    [../user/user_test_c/userlib.c:418]: (style) The scope of the variable i can be reduced
    [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp1 can be reduced
    [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp2 can be reduced
    [../user/user_test_c/userlib.c:419]: (style) The scope of the variable temp3 can be reduced
    

    Die Scope-Warnungen hab ich schonmal gefixt:
    fat12.c:

    void parse_dir(uint8_t* a, int32_t in, struct dir_entry* rs)
    {
       int32_t i = (in %DIR_ENTRIES) * 32;
    
       for(int32_t j=0;j<8;j++,i++)
       {
           rs->Filename[j] = a[i];
       }
    
       for(int32_t j=0;j<3;j++,i++)
       {
           rs->Extension[j] = a[i];
       } //...
    

    video.c:

    void scroll()
    {
        uint32_t blank = 0x20 | (attrib << 8);
        if(csr_y >= SCROLL_LINE)
        {
    		uint32_t temp = csr_y - SCROLL_LINE + 1;
            memcpy (vidmem, vidmem + temp * COLUMNS, (SCROLL_LINE - temp) * COLUMNS * 2);
            memsetw (vidmem + (SCROLL_LINE - temp) * COLUMNS, blank, COLUMNS);
            csr_y = SCROLL_LINE - 1;
        }
    }
    

    userlib.c:

    void showInfo(signed char val)
    {
        static char* line1 = "   _______                _______      <>_<>                                    "    ;
        static char* line2 = "  (_______) |_|_|_|_|_|_|| [] [] | .---|'\"`|---.                                "   ;
        static char* line3 = " `-oo---oo-'`-oo-----oo-'`-o---o-'`o\"O-OO-OO-O\"o'                               "  ;
    
        if(val==1)
        {
            char temp1 = line1[79];
            char temp2 = line2[79];
            char temp3 = line3[79];
    
            for(int i=79;i>0;--i)
            {
                line1[i] = line1[i-1];
                line2[i] = line2[i-1];
                line3[i] = line3[i-1];
            }
            line1[0] = temp1;
            line2[0] = temp2;
            line3[0] = temp3;
            printLine(line1,46,0xE);
            printLine(line2,47,0xE);
            printLine(line3,48,0xE);
        }
    }
    

  • Mod

    Danke! Wird demnächst implementiert.

    Irrelevantes à la "use fgets instead of gets" entfernt

    Ist schon berechtigt, denn momentan kann man locker über den Puffer hinaus schreiben. Damit kann man sich in unser OS "hinein hacken". Das gets sollten wir wirklich implizit in ein "fgets" mit stdin als file verwandeln.



  • Revision 151

    Ja, hallo erstmal!

    Die "FloppyImage.bin" funktioniert unter/auf "MS Virtual-PC" einigermaßen perfekt. Allerdings gibt es ein Problem in der "ckernel.c" bzw. in der "time.c":

    // ckernel.c Revision 151
    
     if (CurrentSeconds!=CurrentSecondsOld)
     {
       itoa(CurrentSeconds, timeBuffer);
       getCurrentDateAndTime(DateAndTime); // <- arbeitet nicht korrekt
       strcat(DateAndTime, "     ");
       strcat(DateAndTime, timeBuffer);
       strcat(DateAndTime, " seconds since start.");
    
       // output in status bar
       printf(DateAndTime, 49, 0xC);
     }
    

    "getCurrentDateAndTime" arbeitet wie ein "strcat". Darum wird der String pro Aufruf immer länger. Nach spätestens drei Aufrufen blockiert die VM, was heißt, daß "nichts mehr geht".

    Leider bin ich zu doof dafür um mir ein PrettyOS selbst zu kompilieren. Deshalb mußte ich die "FloppyImage.bin" reversen. 😞



  • +gjm+ schrieb:

    Leider bin ich zu doof dafür um mir ein PrettyOS selbst zu kompilieren. Deshalb mußte ich die "FloppyImage.bin" reversen. 😞

    Woran hapert's denn? Wir können da bestimmt helfen 😉



  • Das könnte inzwischen auch einfacher geworden sein: Wir haben ein neues makefile. Das hilft, wenn Du es unter Windows versuchst, da msys nicht mehr nötig ist.


  • Mod

    "getCurrentDateAndTime" arbeitet wie ein "strcat". Darum wird der String pro Aufruf immer länger. Nach spätestens drei Aufrufen blockiert die VM, was heißt, daß "nichts mehr geht".

    Danke für den Hinweis. Sehr wichtig, da wir Sun VB für USB EHCI Tests brauchen! 🙂



  • "doof" ist bei mir ein Synonym für "faul". Außerdem bin ich als "Windowser" nun mal verwöhnt (und verweichlicht). 🙂

    Revision 146

    Die Revision 146 läuft unter/auf "MS Virtual-PC" auch, sofern man die o.g. if-Abfrage in der ckernel.c "rauswirft":

    // FloppyImage.bin
    
     Offset    0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
    000049B0  00 00 89 C3 39 C7 [b]74[/b] 62 83 EC 08 8D 45 D4 50 53
    
    Offset 49B6:
    
    74 (JE) ersetzen durch EB (JMP)
    

    Allerdings wundert es mich, warum die Revision 146 auf "realen" PCs gelaufen sein soll. Eigentlich hätte es eine Art "Buffer Overflow" geben müssen.


Anmelden zum Antworten