Szegmentálási hiba az AllocAppender # 470

Hozzászólások

Link másolása Idézet válasz

yazd kommentálta 2014. január 17

Megkapta ezt a szegmentálási hibát az étrendsablon renderelésekor.

A hiba minden alkalommal megismételhető.
Miközben megpróbáltam hibakeresni, naplóztam a változókat az AllocAppender put () fájlba. Bár az m_maradó elég helyről számolt be, annak elérése előállította a segfaultot.

yazd kommentálta 2014. január 17

A további tesztek azt mutatják, hogy az m_data maga nem érhető el.

yazd kommentálta 2014. január 18

A VibeManualMemoryManagement használatával a szegfault nem fordul elő.

etcimon kommentálta 2014. január 18

Gondjaim voltak a GC móddal is, szerintem a vibe memóriáját alapértelmezés szerint manuálisan kell kezelni.

yazd kommentálta 2014. január 29

Lezárom ezt a kérdést, mivel nyilvánvalóan rossz jelentés reprodukálható eset nélkül.
Ha egy kis, megismételhető esetre jutok, akkor újra kinyitom.

jebblik kommentálta 2014. május 1-jét

Azt hiszem, most ütöttem le ezt a hibát - kapott egy memfa-ban egy segfaultot és egy törött stack nyomot.

Sajnos az alkalmazás zárt forráskódú, és az összeomlás csak utána történt

Úgy tűnik, hogy a VibeManualMemoryManagement megoldás nekem is megoldja ezt.

s-ludwig kommentálta 2014. május 12

luismarques kommentálta 2014. május 12

@yazd nem értem, az első hozzászólásban azt mondtad, hogy "A hiba minden alkalommal megismételhető"; miért zárták ezt később "rossz jelentésként, reprodukálható eset nélkül"? Az én esetemben, amelyet a @ s-ludwig megemlít, a hiba nem reprodukálható determinisztikusan, így ha van egy determinisztikus példád, akkor ez segít.

yazd kommentálta 2014. május 12

Eredetileg számomra reprodukálható volt, de nem volt minimális teszt. Cseréltem néhány dolgot, és működött, és elvesztettem az ügyet. Megpróbálok visszatérni a projekthez, és újra reprodukálni a kérdést. Azt hiszem, megér néhány órát az időmből.

etcimon kommentálta 2014. május 12

@luismarques volt kézi memóriakezelésed, amikor ez a hiba bekövetkezett?

yazd kommentálta 2014. május 12

Nem, a kézi memóriakezelő verzióval minden megfelelően működött.
Edit: Ops, csak észrevettem, hogy a kérdés a luismarques-ra vonatkozik.

etcimon kommentálta 2014. május 12

Rengeteg problémám volt kézi memóriakezelés nélkül, ezért továbbra is tartom, hogy alapértelmezés szerint be kell kapcsolnia.

s-ludwig kommentálta 2014. május 12

Rengeteg problémám volt kézi memóriakezelés nélkül, ezért továbbra is tartom, hogy alapértelmezés szerint be kell kapcsolnia.

Ez az veszélyes (azaz nem @ biztonságos)! A HTTPServerRequest bármelyik memóriájának használata a kérelemkezelőn kívül memória sérülést okoz (pl. Ehhez elegendő egy lekérdezési paraméter használata AA kulcsként)! A req/res paraméterek hatókörének hozzáadása a legkevesebb, ami szükséges ahhoz, hogy ez az alapértelmezett beállításnak tekinthető legyen. De ez egy kicsit nehéz az értékcsökkenési útvonal biztosítása szempontjából.

Más nyelveken ez nem lenne igazán figyelemre méltó (főleg a C és részben a C ++), de a D esetében ez egyfajta norma, hogy a memóriasérülés szempontjából a GC miatt nem lehet sok rosszat elkövetni, szóval ez meglehetősen váratlan.

etcimon kommentálta 2014. május 12

a memóriasérülés szempontjából nem lehet sok rosszat elkövetni a GC miatt, így ez valahogy váratlan.

Ez vicces, mert azt gondoltam, hogy a vibe.utils.memory úgy lett beállítva, hogy manuálisan kezelje a legtöbb dolgot, annak ellenére, hogy az USE_GC értéke true.

luismarques kommentálta 2014. május 12

@etcimon: Az alapértelmezett automatikus memóriakezelést használom.

s-ludwig kommentálta 2014. május 12

Igen, de a HTTP szerver az defaultAllocator () szoftvert használja, amely egy tiszta GC alapú elosztó, ha a kézi memóriakezelés nincs engedélyezve. A manualAllocator () többnyire olyan belső dolgokra használható, amelyek nem részei az API-nak.

etcimon kommentálta 2014. május 12

Tehát . itt csak egy gyors találgatás a hangulati képességeim gyakorlásához, de ezek a használati esetek többnyire nem a TCP-kapcsolat által kapott ubájtokra vonatkoznak? Ez a kör alakú pufferben lenne, és a hozzáférés megsértése azt jelenti, hogy a kör alakú puffert a GC gyűjtötte, igen?

edit: Nvm, ami nem lenne lehetséges, mert a TCPConnection.read (dst) lemásolja az adatokat a pufferből

s-ludwig kommentálta 2014. május 16

Éppen balesetem volt (érvénytelen ír hozzáférés) azon a helyen, amely 100% -ban reprodukálható volt. Miután megváltoztatta a GC.realloc használatát GC.extendre, a baleset megszűnt. Vagy vagy valamit rosszul csináltam a GC.realloc-szal, vagy van egy, de ott (vagy van valami homályos halom korrupció, de remélhetőleg nem.).

yazd kommentálta 2014. május 16

Nem tudtam reprodukálni az esetemet, de szerencsére igen. Remélhetőleg ez kijavítja.

s-ludwig kommentálta 2014. május 16

Egy másik empirikus bizonyíték: Éppen most fedeztem fel, hogy a vibed.org webhely gyakran összeomlott egy általános védelmi hiba miatt, de abbahagyta ezt azóta, amióta átépítettem a "fix" vibe.d verziót. Tehát nem garantált, hogy a GPF-et itt okozta ez a probléma, de legalább valószínűnek tűnik.

s-ludwig kommentálta 2014. május 19

Bezárás, amíg új bizonyíték nem merül fel. A vibed.org folyamat már nem zuhant le, mivel a javítás beépítésre került (most 3 napig fut).

etcimon kommentálta 2014. május 20

Tehát ez azt jelenti, hogy a GC.realloc memóriasérülést okozhat más felhasználási esetekben, például asszociatív tömbökben? Úgy gondolom, hogy ez az oka annak is, hogy nem "varázsszámokhoz" folyamodik?

etcimon kommentálta 2014. május 20

Ok, találtam néhány hatalmas hibát a GC.realloc rutinban

Nyilvánvaló, hogy az updateCache fájlokat kiterjesztésben és átcsoportosításban használják az új kiosztás méretének gyorsítótárazásához, mert ez felgyorsítja a findSize metódust. Azonban sehol sem található a realloc módszer egy meghatározott ágában (amikor az előző méret kisebb, mint egy oldalméret, azaz 4096 bájt)
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L679

Tehát, ha a következőket hajtja végre, meg kell kapnia egy írási hozzáférés megsértését:
1- 2048 bájt kiosztása
2 - Átalakítás 1024 bájtnál kisebb értékre
3- Helyezze újra 2048 bájtra

A 2048 bájt kiosztást figyelmen kívül hagyjuk, mert a realloc szerint a psize 2048 bájt. Bármi, ami ezt a logikát követte, az írási hozzáférés megsértését vonja maga után. (Feltéve, hogy nem történt másik átcsoportosítás között.)

. ÉS ha a régi és az új kiosztási méret nagyobb, mint egy oldal (4096 bájt), és az egymást követő oldalblokkok nem találhatók az oldaltáblázatban, akkor a cache frissítést is kihagyja azzal, hogy ugyanazzal a malloc útvonalon halad, mint fent

Ez IS megakadályozza az oldalak felszabadulását, és az általam tapasztalt GC memóriaszivárgásokhoz vezet! (végre megtalálta!)