Mit tegyek, ha elakadtam egy beadandóban (C nyelven)?
Leginkább sporadikus hiba jött elő, pedig a lényegi részeket minták alapján csináltam vagy épp másoltam. Hétvégén elkészítettem a lényegi kódot, tegnap és ma órák hosszat debug-oltam. Mármint mindent kiírattam a standard output-ra, mert persze nem IDE-t használunk.
Csak amikor a lib-beli függvény száll el, ráadásul egyik futásnál elszáll, másiknál nem, ha pedig éppen elszáll, akkor se mindig ugyanott - akkor már nem tudom, mit tegyek.
Ha pedig le is fut, olyan hiba jön elő, aminek szerintem fizikailag se kellene.
Konkrét és komoly kérdésem, hogy ilyenkor mi van?
A csoporttársaim se értenek hozzá jobban, vagy aki igen, az nem tud annyit segíteni, hogy ránéz a kódomra.
Attól tartok, hogy itt csak az ment meg, ha valaki ránézne a kódomra és egy munkahelyi szituációban is segítenek ilyenkor egymásnak az emberek...
Írd le:
* pontosan mi a feladat
* meddig jutottál benne (forráskód beillesztéséhez használj kódmegosztó oldalakat: pastebin.com, hastebin.com, ghostbin.co )
* hol akadtál el, pontosan milyen hibát tapasztalsz, miben kéred a segítségünket
"lib-beli függvény száll el"
Saját, vagy külső könyvtár? Használsz dinamikus "malloc" helyfoglalást is?
"olyan hiba jön elő"
Van hibaüzenet?
Teljesen normális ami veled történik, így tanul az ember programozni. A C (meg a C++) ilyen, ha téves memóriacímet adsz neki, akkor megnézi mi van ott és azzal megy tovább, akkor is, ha hülyeség. Nem mindig okoz hibát. Legrosszabb ha így véletlenül random helyre beírsz a memóriába, valamit átírsz, ami tök máshol okoz hibát. Mert a C azt csinálja, amit mondasz neki, és nem ellenőzi, hogy hülyeség-e, amíg az oprendszert nem zavarja.
Az egyik hibaforrás, ami ilyen dinamikus bugot okozhat, valóban a dinamikus memóriafoglalás. De téves tömbindexeléssel is lehet.
És amúgy nem biztos, hogy aki ért hozzá, az gyorsan rájönne, mi a gond. Marha nehéz lehet ezeket a hibákat kidebugolni.
Na, akkor... igaz, nem főállásban, de több, mint 20 éve foglalkozok programozással, szóval ki merem jelenteni, hogy van némi tapasztalatom. Igaz, hogy a C/C++ csak a hármas számú nyelv nálam (a Pascal és a Perl után), de a hibakeresés módszertana nem nyelvfüggő, és azért C-ben is tekintélyes mennyiségű programozás van már a hátam mögött. Szóval vágjunk bele!
"Leginkább sporadikus hiba jött elő"
Nem kötekedésből, de attól nem leszel előbbre, ha pár vaskalapos egyetemi oktatón kívül senki által nem használt kifejezéseket használsz. Értem én, hogy (sajnos) a felsőoktatásban (sőt, lassan már azon kívül is) sokan úgy próbálnak okosabbnak tűnni, hogy már alapszavakat sem hajlandók magyarul mondani, de nem hiszem, hogy ez célravezető lenne. Egyrészt mert így az első mondat elolvasása után a potenciális válaszolók többsége továbblép, másrészt mert nyelvromboló olyan helyzetekben idegen szavakat odaráncigálni, ahol ugyanarra van magyar eredetű szó vagy kifejezés.
"mert persze nem IDE-t használunk"
Nem is kell.
Nem tudom, mióta programoztok, de a különböző integrált fejlesztőeszközök a kezdeti fázisban csak elterelik a figyelmet a programozás lényegéről. Van oktatási tapasztalatom, és ki merem jelenteni, hogy egy (fél)professzinális IDE használatával sem jut előbbre a kezdő tanuló, sőt, gyakran csak még jobban összezavarja. Azt akkor érdemes elkezdeni használni (szerintem, és tapasztalataim alapján), amikor már az alapok letisztultak, és magabiztosan mozog az ember az adott nyelvben. Ráadásul alapszintű hibakeresésre bőven jó a klasszikus szövegkiírós módszer. Ha meg uncsi folyamatosan printf-ekkel bajlódni, nyugodtan írj magadnak saját hibakereső makrókat vagy függvényeket! Használd ki a programnyelv adta lehetőségeket! Nekem is úgy kezdődött minden programom, hogy #include "hiba.h". :) (Azért nem debug.h, nehogy összeakadjon egy esetlegesen a programozási környezet által biztosított debug.h-val.) Az ilyet, ha jól csinálja az ember, egyszer kell megírni, és évekig használhatja.
Nem kétlem, hogy mondjuk egy Eclipse, vagy egy Visual Studio (bár utóbbinak eléggé sajátságos a C-támogatása) beépített hibakeresője ne tudna hasznos lenni, hiszen temérdek nyalánkságot tartalmaz, mint pl. töréspontok, lépésenkénti programvégrehajtás, élő változókövetés, veremlistázás, stb, stb. Ezek többsége akkor használható, ha már az ember szerzett némi jártasságot, és "tudja, hogy mit csinál". Ráadásul egyáltalán nem baj, ha gyakorlatot szerzel a "nyers" hibakeresésben, ugyanis ki tudja, mikor kell olyan környezetben dolgoznod, ahol nem fog rendelkezésre állni profi hibakereső környezet. (Arduino, Game Boy, hogy csak két ilyet említsek a szakmai múltamból.)
"egy munkahelyi szituációban is segítenek ilyenkor egymásnak az emberek..."
Már ha tudnak.
Ameddig kezdő az ember, és vannak körülötte olyanok, akik jobban értenek hozzá, akkor ez járható út. Aztán ha te leszel az, aki a legjobban ért hozzá, menten magadra maradsz egy összetettebb hibánál. ;) Vagy ha olyan munkahelyre kerülsz, ami nem egy fejlesztő cég, és egyedül te vagy programozó.
(Egyébként az internet ekkor is rendelkezésre áll, csak jól kell használni.)
"Csak amikor a lib-beli függvény száll el"
Kicsit részletezhetnéd, hogy milyen könyvtárról van szó. Ez így "nesze semmi, fogd meg jól". Konkrétumok ismerete nélkül nem lehet konkrét segítséget nyújtani.
"olyan hiba jön elő, aminek szerintem fizikailag se kellene"
Mi a hiba, és miből gondolod ezt?
"ráadásul egyik futásnál elszáll, másiknál nem"
Tipikus példája a környezetfüggő viselkedésnek. Nincs ebben semmi misztikus, van, hogy egy kódrészlet viselkedése függ a használat és a futtatás körülményeitől. Mondjuk (béna példa, de szemléletes) ha lekérdezem a pontosidőt, kinyerem belőle az óra értékét, majd egy számot ezzel az értékkel elosztok, az csak akkor fog hibát eredményezni, ha 0:00 és 0:59 között futtatom a programot. 1:00-kor már nem.
Bár ha a külső könyvtár függvényében van ilyen hiba, az nagyobb probléma, ugyanis abba te nem (illetve nem könnyen) tudsz belenyúlni. (Vagy nem úgy használod, ahogy kell.)
"ha valaki ránézne a kódomra"
Nosza, mi tart vissza? ;)
"Aztán ha te leszel az, aki a legjobban ért hozzá, menten magadra maradsz egy összetettebb hibánál."
Ez valami vicc akarna lenni?
Sokszor elég a pihentebb elme, vagy más megközelítés egy probléma megoldásához, nem kell mindjárt a legjobbnál is jobbnak lenni.
"Értem én, hogy (sajnos) a felsőoktatásban (sőt, lassan már azon kívül is) sokan úgy próbálnak okosabbnak tűnni,"
Nem próbálnak sehogy okosabbnak tűnni. Nincs is erre semmi szükségük, veled ellentétben.
"másrészt mert nyelvromboló olyan helyzetekben idegen szavakat odaráncigálni, ahol ugyanarra van magyar eredetű szó vagy kifejezés."
Ez is egy veretes, diktatórikus, alaptalan hülyeség.
Elég szegényes lenne a nyelvünk ha tényleg mindenki így viselkedett volna a múltban. Ha a német, szláv és latin jövevényszavakat leválasztanánk - amelyek elég szépen beépültek a nyelvbe, részben még az alapszókincs részévé is váltak - akkor nem sok minden maradna.*
"Van oktatási tapasztalatom, és ki merem jelenteni, hogy egy (fél)professzinális IDE használatával sem jut előbbre a kezdő tanuló, sőt,"
Mid van neked? :)
* A 'forint', a 'tréfa' szavunk az olaszból, a 'kovács', a 'sonka', a 'csütörtök' a szlávból, a 'fánk', a 'cél', a 'palánk' és még sokezer másik német közvetítéssel került a magyar nyelvbe. A mérnökök nagyon megsínylenék a hiányukat. Hát még ha kitérnénk a latinra és az angolra is.
A pendrájvot, a processzort meg a filét mi a kutya-filének hívnád?
A 'program' szó sem magyar eredetű, mégis leírtad legalább egy tucatszor. Azt meg végképp nem tudom, hogy a 'potenciális' szóra, hogy nem találtál echte magyar megfelelőt?
Ha már mástól elvárod a hülyeséget, legalább te járj elöl példával, elvégre ez a hülyeség legalább a sajátod.
#5 Szokás szerint, nem a kérdésre válaszolsz, csak kötekedsz. Amúgy ha már a szavak használatárol okoskodsz:
A 'forint', 'kovács', 'sonka', 'csütörtök', és megannyi szavunk nem csak szimplán más nyelvekből beépült szavak, de ezek a köznyelvben előforduló legnépszerűbb (vagy akár egyetlen) szavaink ezekre a dolgokra. Ugyanakkor a 'sporadikus' egy ékesebb módja hogy azt mondjuk, "szórványos". Ez a példa pont olyan, mintha a sonkát cubáknak hívná valaki. Egy szűkebb közegben lehet hogy ez egy elterjedt, gyakran használt kifejezés, de általánosságban az emberek nem használják (vagy nem is ismerik) ezt a szót. Az, hogy magyar eredetű, vagy sem, édes mindegy, párszáz év után úgysem fog már számítani hogy éppen egy azerbajdzsáni szót vettünk át a lépegetős kutyafarokra, ami a lényeg hogy mi a köznyelvben használatos kifejezés, és mi az, ami a köznyelvtől eltér, kevésbé használt, ismert.
Mondom ezt úgy, hogy amúgy nincs problémám azzal, ha valaki "ékesebben szól", és végképp nem gondolom úgy, hogy ettől ő "okosabbnak próbál tűnni", van akinek ezek a szavak égnek be, és előbb jut ez eszébe, mint egy másik, amúgy közismertebb szinonímája.
Ez egy fals logika.
Addig kéne eljutnod, hogy a már beépült, meghonosodott, polgárjogot nyert szavaink [tízezrével vannak ilyenek] csak úgy nyerhették el jelenlegi státuszukat, ha volt aki használta, népszerűsítette őket.
Azt tudomásul kéne venni, hogy a nyelv egy élő, folymatosan változó dolog. És ezt a változást éppen a nyelv használói idézik elő, még pedig okkal, joggal. Ettől őket megfosztani nem lehet, nem is érdemes, mert az nagy bajjal járna.
Itt vagyok, csak tegnap közel éjfélig még ezzel foglalkoztam, ma meg mostanáig dolgoztam.
A lib-beli függvény azért szállt el a szülő process-ben, mert a pipe nem tudott megnyílni (bár túl sok a debug "logolásom", ezért ez az infó elveszett, ezért is lenne jobb az IDE). Utána pedig a parent-beli read() azért nem olvasott semmit, mert a child-ek meghaltak, mert az egyik printf()-ben véletlenül %s-el akartam integert kiíratni. Ezt is úgy találtam meg, hogy arra az egy sorra szűkült a probléma - hoppá, %d helyett %s.
A sporadikus szót a munkahelyemen is hallottam már. Nem tudom, hogy bírják emberek felhúzni magukat ezen a szón, már ha tényleg felhúzzák.
Már azért nem az első félévben vagyunk és egy IDE-ben debug módban sorról-sorra lehetne lépkedni és a változók tartalmát látni lehetne. Így meg mi marad? A printf(), nálam sok kódrészletben szó szerint minden sor után van egy printf().
A feladat.
Process-eket kell indítani fork()-kal, egyet vagy kettőt. Named pipe-ot használok.
Elvileg gond nélkül hozom létre, nyitom meg, zárom, unlink-elem a pipe-okat, ehhez segítségem is volt. A readonly, writeonly irány is jó.
A name változó benne a gyerek szál "neve", csak megkülönböztetésül, kb. csak stdout-ra kiírás miatt jó valamire is. "First" illetve "Second" lehet az értéke.
Kimenet:
> child_activity() - child = First / bytes waited for = 33 / bytes arrived = 33 / strlen(data) = 33 / data = << adat, a feladat szerint elvárt módon >>
> child_activity() - child = First / bytes waited for = 41 / bytes arrived = 41 / strlen(data) = 46 / data = << adat, a feladat szerint elvárt módon >>
> ▒(▒▒Uchild_activity() - child = First / bytes waited for = 40 / bytes arrived = 40 / strlen(data) = 46 / data = << adat, a feladat szerint elvárt módon >>
> љ(▒▒Uchild_activity() - child = First / bytes waited for = 38 / bytes arrived = 38 / strlen(data) = 46 / data = << adat, a feladat szerint elvárt módon >>
> љ(▒▒Uchild_activity() - child = First / bytes waited for = 41 / bytes arrived = 41 / strlen(data) = 46 / data = << adat, a feladat szerint elvárt módon >>
Néhány hibát sikerült kijavítanom tegnap éjjel, most itt vagyok elakadva.
Az adatok amúgy \n-re végződnek, de ezt a kód a legtöbb helyen jól kezeli.
Namost a gondom az, mint ahogy a kimenetből is látszódik, hogy mondjuk a második sort elnézve, a parent közli, hogy 41 byte-ot fog adni, 41 byte mérettel létre is hozza a char person[] ideiglenes változót, amiben fogadná, majd meg is érkezik maga az adat, tényleg 41 byte, de a char person[] nevű ideiglenes változóba még kerül valamiféle memóriaszemét is.
Ráadásul a változó tudtommal a stack-en van és mire fordul a for ciklus, addigra törlődik, így az a veszély se áll fenn, hogy ha i = 2-nél 40 hosszú volt, akkor i =3-nál nem lehet 33 hosszú, ha csak arra lenne szükség amúgy.
Lehet, ismétlem, csak lehet, hogy ha ez megoldódik, akkor leadhatom végre ezt a borzalmat... :D
Kapcsolódó kérdések:
Minden jog fenntartva © 2025, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!