Új hozzászólás Aktív témák
-
#39560925
törölt tag
válasz
kingabo
#2507
üzenetére
Tudom mit csinál az a try-catch blokk, az előzményt is olvasd el.
Csak debugolas céljából volt ott. Végülis fölöslegesen, mert már emvy segítségével megoldódott a probléma.Tehát az előzmény:
SO-n azt írták, hogy egy kezeletlen exception miatt meghívódik a terminate() ami meghívja az alkalmazás abort()-ját és ezért áll le.
Próbáltam, hogy try-catch blokkba elkapok mindent a függvényhívás körül, de ugyan úgy abortálódott a futás. Egyébként msdn-en semmit nem írnak arról, hogy ezek a függvények exceptiont dobnának. -
#39560925
törölt tag
Először is odaadom a Socket és az UDP_Socket forrását. A thread indítása elég összetett és inkább nem adnám oda. A threadként elindított függvény egy objektum tagfüggvénye, és ezt az objektumot először inicializálom az első beérkező csomag függvényében.
Így deklarálom az objektumot:
auto forwarder = std::make_shared<RTP_proxy>();Ha a csomagban megfelelő content van és még nem létezik forwarder a forráscímhez tartozóan, akkor csinálok egy új forwardert:
forwarder = std::make_shared<RTP_proxy>(proxy_IP, rtp_addr, call_ID);Hozzáadom a forwardereket tároló map-hez:
RTP_forwarder_list[rtp_addr] = forwarder;És elindítom az új szálat:
std::thread(&RTP_proxy::run, RTP_forwarder_list[rtp_addr].get()); -
#39560925
törölt tag
válasz
#39560925
#2499
üzenetére
Tehát az UDP_Socket operator<< függvénye lentebb olvasható (mint mondtam is, mindig működik). A sender_address és a sender_port egy std::string és uint16_t típusú, inicializált változók.
Itt megtörtént a standard outputra kiírás:
De közben felvillan a "debug error!" hibaüzenet, amiből utána ennyi látszik:
Jó, mi?
-
#39560925
törölt tag
az opertor<< nem csinál semmit csak kiír. Az is mindig jól működik, kivéve ebben a szálban. Nem használ közös adatot, két külön objektumról van szó amik a saját tagváltozóit írják ki.
std::ostream& operator<<(std::ostream& os, const Socket& sock)
{
os << sock.IP_address << ":" << sock.port;
return os;
}A két szál közös adatai meg mutex-ekkel védett stl tárolók, de odáig most nem jut el a program, hogy használja is őket a második szál.
-
#39560925
törölt tag
válasz
#39560925
#2494
üzenetére
Kicsit elrontottam a debugolási lépések leírását, nem azok a képek vannak, amikre emlékeztem.
Szóval a második képhez tartozó helyes szöveg ez lenne: várakozik is csomagra timeout nélkül, ahogy annak lennie kell.
Az első képhez meg csak annyi a komment, hogy meghívódik a recvfrom()
-
#39560925
törölt tag
Részleteket tudok mutatni, és elmondom mit csináltam.
Elöljáróban annyit, hogy csináltam egy wrapper osztályt a winapi köré, hogy OO módon tudjam kezelni socketeket, és amúgy tök jól működik.
Itt az 1. számú szálon meghívódik a rcvfrom() és várakozik is csomagra timeout nélkül, ahogy annak lennie kell:
Miután küldök neki egy csomagot, azt szépen feldolgozza a szál:
És visszatér a recvfrom:
Ezek után elindítja a 2. számú szálat, ami egy másik socketre hívja meg a recvfrom()-ot:
Megnyomom az F11-et (step into) és voilà:
Látom szerkesztettél és call stack kell, intézek egyet.
Itt a call stack, nyilván csak az abortot előidéző utasításig tudom megnézni:
-
#39560925
törölt tag
winapit socketet használó programot írok. Amikor egy ezzel kapcsolatot api hívást csinálok az egyik szálból, pl select(), vagy recvfrom(), akkor elszáll a program a fenti hibaüzenettel. Túrtam elég sokat a netet, de nem találtam róla semmi használhatót.
SO-n azt írták, hogy egy kezeletlen exception miatt meghívódik a terminate() ami meghívja az alkalmazás abort()-ját és ezért áll le.
Próbáltam, hogy try-catch blokkba elkapok mindent a függvényhívás körül, de ugyan úgy abortálódott a futás. Egyébként msdn-en semmit nem írnak arról, hogy ezek a függvények exceptiont dobnának.
Én arra gyanakszom, hogy a többszálúság miatt lehet, de minden socketet csak egy, a saját szálából használok. Egyébként is úgy debugoltam, hogy a másik szál aludt, mikor erre a függvényhívásra lépett az utasításszámláló.A másik furcsa jelenség a következő: overloadoltam az operator<<-t az egyik saját osztályomnak. Tökéletesen működik mindig, kivéve abban a szálban, ami a fenti hibát produkálja. Egész pontosan mikor megtörténik az outputra kiírás, akkor is dob egy ilyen hibaüzenetet, de ekkor még tovább tudom futtatni a programot. WTF?
UI: bocs, hogy nem print screeneltem, a szituációban egyszerűbb volt fotózni.
-
#2487
#39560925
törölt tag
WonderCSabo
#2484
#39560925
törölt tag
válasz
WonderCSabo
#2484
üzenetére
A legtöbb példában amit láttam nem egy osztály tagfuggvenyet adták át, hanem egy globális függvényt, ezért először nem értettem, hogy miért kell 2 paraméter a thread konstruktorának, aztán végül leesett.
emvy: valóban tökmindegy, csak annyi, hogy a mainben meg be kell várni azt a szálat.
Amúgy deklaráltam egy threadeket tároló listát és abba pusholtam bele a futás közben létrehozott threadeket, aztán a létrehozó szál végén vegigiteraltam a listán és mindre meghívtam a joint, így rendben működik.
-
Csak debugolas céljából volt ott. Végülis fölöslegesen, mert már emvy segítségével megoldódott a probléma.
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- PlayStation 1 / 2
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Milyen SSD-t vegyek?
- Bittorrent topik
- Borderlands 4
- Riasztó topik
- Bemutatkozott a HHKB legújabb, Topre kapcsolókkal szerelt billentyűzete
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- HiFi műszaki szemmel - sztereó hangrendszerek
- Projektor topic
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone 13 Pro 128GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3082
- HIBÁTLAN iPhone XS Max 64GB Gold -1 ÉV GARANCIA - Kártyafüggetlen, MS2898, 100% Akkumulátor
- Okosóra felvásárlás!! Samsung Galaxy Watch 5 Pro, Samsung Galaxy Watch 6 Classic
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest