Kezdőoldal » Számítástechnika » Programozás » Mit tegyek, ha elakadtam egy...

Mit tegyek, ha elakadtam egy beadandóban (C nyelven)?

Figyelt kérdés

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...


2021. ápr. 27. 22:04
1 2
 1/14 anonim ***** válasza:

Í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

2021. ápr. 27. 22:11
Hasznos számodra ez a válasz?
 2/14 anonim ***** válasza:

"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?

2021. ápr. 27. 22:13
Hasznos számodra ez a válasz?
 3/14 anonim ***** válasza:

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.

2021. ápr. 27. 22:33
Hasznos számodra ez a válasz?
 4/14 anonim ***** válasza:

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? ;)

2021. ápr. 27. 23:10
Hasznos számodra ez a válasz?
 5/14 anonim ***** válasza:
0%

"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.

2021. ápr. 28. 09:27
Hasznos számodra ez a válasz?
 6/14 anonim ***** válasza:

#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.

2021. ápr. 28. 12:55
Hasznos számodra ez a válasz?
 7/14 anonim ***** válasza:

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.

2021. ápr. 28. 13:26
Hasznos számodra ez a válasz?
 8/14 A kérdező kommentje:

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ó.


[link]

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

2021. ápr. 28. 17:41
 9/14 A kérdező kommentje:
Egyébként az előző munkahelyemen is úgy lehetett debug-olni, hogy az ember kilogolta a hibát, ráadásul MSSQL-adatbázisba logolta a dobozos szoftver. A jelenlegi munkahelyemen is van ilyen debug-olás is, bár itt már talán ritkább, szerencsére.
2021. ápr. 28. 17:43
 10/14 A kérdező kommentje:
Mondjuk ha a háttérben strcpy() vagy hasonló történik, akkor gondolom meg tud nőni a person mérete. Vagy valami ilyesmi...
2021. ápr. 28. 17:45
1 2

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

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!