[OSy] problem pri testu malloc1

[Jiri Tousek]

Dobry den.

Prosel jsem si ty zdrojaky, opravil par drobnych chyb, ale nepomohlo to.

Nechal jsem si tedy vypsat kompletni trace msimu (267MB log soubor
:P), a po dukladnem prozkoumani si myslim, ze jsem objevil pricinu:

Ta panic, kterou to hazi, nastane v kstack_free (soubor kstack.S
prevzaty z Kalista) pote, co je z kernel_level prectena poskozena
hodnota. Pricina panic tedy je, ze si kropim do oblasti, kde je ulozen
kernel_level (i ta chybova hlaska, ktera se tim stane necitelna).

Toto je prislusny kus logu (cteni poskozene hodnoty a vstup do
kstack_free_panic):
    80002364    xor   k0, k0, k0        # k0: 0x8001a1b0->0x0
    80002368    lui   k0, 0x8001        # 0x8001=32769, k0: 0x0->0x80010000
    8000236C    ori   k0, k0, 0xa1b0    # 0xffffa1b0h=41392, k0:
0x80010000->0x8001a1b0
    80002370    lw    k1, (k0)          # 0x0=0
    80002374    addiu k1, k1, 0xffff    # 0xffffffff=65535, k1:
0x8f8e8d8d->0x8f8e8d8c
    80002378    sw    k1, (k0)          # 0x0=0
    8000237C    bltz  k1, 0x3           # 0x3=3
    80002380    nop
    8000238C    xor   a0, a0, a0        # a0: 0x80010000->0x0
    80002390    lui   a0, 0x8001        # 0x8001=32769, a0: 0x0->0x80010000
    80002394    j     +0x1220           # 0x1220=4640

(hodnota kernel_level je evidentne prepsana testem: 0x8f8e8d8d)

kernel_level je v kstack.S definovan takto:
        .data

kernel_level:
        .word        0

        .text

Podle mapy binary.lds by mela byt sekce .data urcite pod &_kernel_end,
aspon si to myslim.

V tom logu je ale jeste dalsi zajimava informace - adresa symbolu kernel_level:
    80002364    xor   k0, k0, k0        # k0: 0x8001a1b0->0x0
    80002368    lui   k0, 0x8001        # 0x8001=32769, k0: 0x0->0x80010000
    8000236C    ori   k0, k0, 0xa1b0    # 0xffffa1b0h=41392, k0:
0x80010000->0x8001a1b0
    80002370    lw    k1, (k0)          # 0x0=0

Pokud to ctu spravne, adresa kernel_level je 0x8001a1b0.
Ale adresa _kernel_end je 0x8000c624, podle ladiciho tisku i podle kernel.map.

V tomto okamziku to do sebe cele zapada - kernel pada v okamziku, kdy
se vyplnuje 128kB blok pameti, lezici temer urcite (podle ladicich
tisku z drivejsich behu bez trace on) kolem te kriticke adresy
0x8001a1b0. Behem vyplnovani prijde interrupt exception, a pri jejim
zpracovani se narazi na chybny obsah kernel_level.

Zkousel jsem (jen pro potvrzeni) opet udelat "pametovy polstar", ale
tentokrat uz jsem vedel, jak ma byt velky, aby ochranil tu adresu, a
kdyz jsem takto rovizorne adresu konce kernelu upravil, test prosel.

Omlouvam se za zdlouhavy popis, chci se jen ujistit, ze to vsechno do
sebe zapada.

Pokus je moje dedukce spravna, vime uz v cem je problem.

Co ale stale nechapu je, jak problem vznikl a jak ho resit.
Nabizi se nejaka chyba v nasich makefilech (pri linkovani). Vsechny
soubory, o kterych si myslim, ze jsou relevantni pro problem, jsem
umistil docasne na http://www.ms.mff.cuni.cz/~tousj3am/osy/, prosim
opet o jakoukoliv pripominku ci radu. Mam za to, ze chyba je v tom, ze
symbol kernal_level je az za _kernel_end, ale nevim proc tomu tak je.

Dekuji

J.T.


On 12/2/06, Jiri Tousek <jiri.tousek at gmail.com> wrote:
> Dekuji za radu, projdu to, aspon si trochu sjednotim styl (komentaru
> je tam uz ted vic nez kodu :D)
>
> J.T.
>
> On 12/2/06, Martin Decky <decky at nenya.ms.mff.cuni.cz> wrote:
> > > Do jisteho momentu vse funguje, pak
> > > ale pridani jakehokoliv kodu (i kodu napriklad ve funkcich kolem
> > > virtualni pameti, ktere se urcite nevolaji) zpusobi chybu. Z toho to
> > > vypada, jako bych pri zvetseni zdrojaku si zacal zapisovat do kodu
> > > programu, ale jsem si pomerne jisty, ze vsechny alokacejsou nad
> > > adresou _kernel_end.
> >
> > Ta pricina urcite neni v tom, ze zvetsujete zdrojak, spis se ta pamet
> > kropi v dusledku nejake chyby spravy pameti porad, jen se v tomto
> > pripade projevi.
> >
> > > Zkousel jsem pro jistotu alokovat pamet az o 4kB dal od kernelu,
> > > zvetsovat velikost zasobniku vlakna. Bez uspechu.
> >
> > Magie s pridavanim ruznych pametovych polstaru vetsinou nefunguje (a
> > pokud nahodou funguje, ale neni jasne proc, tak to svedci o tom, ze je v
> > kodu neco hodne spatne).
> >
> > Nejlepsi (i kdyz nejpracnejsi) je dusledne projit radku po radce kod
> > spravy pameti, zkontrolovat, zda se nekde nevyskytuje nejaka divna
> > konstrukce (ten cas tomu venovany lze soucasne pouzit k duslednemu
> > okomentovani kodu), na mista, odkud prichazi nejaka hodnota "z venku",
> > je vhodne dat asserty kontrolujici konzistenci atd.
> >
> >
> > M.D.
> > _______________________________________________
> > OSy mailing list
> > OSy at nenya.ms.mff.cuni.cz
> > http://nenya.ms.mff.cuni.cz/mailman/listinfo/osy
> >
>