[OSy] problem pri testu malloc1

[Jiri Tousek]

Tak od autoru Siria jsme dostali patch, ktery ten problem odstranuje.
Jak koukam, do listu jej neposlali (mozna kvuli zasade neposilat moc
kodu) - kdyby nekdo jiny jeste ten patch potreboval, obratte se na ne
- chci jen, aby kazdy, koho se to tyka, vedel, ze ten patch existuje.

J.T.

On 12/3/06, Jiri Tousek <jiri.tousek at gmail.com> wrote:
> 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
> > >
> >
>