Ú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:
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.
-
#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.
-
-
#39560925
törölt tag
Van egy osztály, amiben van egy függvény aminek nincs paramétere és nincs visszatérési értéke. Ezt a függvényt szeretném meghívni egy másik osztályból külön szálként std:threadet használva. Ennek mi a helyes módja?
Ú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!
- Logitech G27 szett eladó! Posta az árban!
- Dell Precision 7560 - Intel Core i9-11950H 32GB 1TB SSD FHD
- Manli NVIDIA GeForce GTX 1650 4 GB hibátlan, 100%-ban tesztelt állapotban!
- NVIDIA Quadro P4000 8 GB hibátlan, 100%-ban tesztelt állapotban!
- Bomba ár! Lenovo ThinkPad T480s - i5-8GEN I 8GB I 256GB I 14" FHD I HDMI I Cam I W11 I Gari!
- HIBÁTLAN iPhone 14 Pro 256GB Gold -1 ÉV GARANCIA - Kártyafüggetlen, MS3519
- BESZÁMÍTÁS! Asus H370-A i5 9600K 16GB DDR4 512GB SSD RTX 2060 Super 8GB Zalman T7 Zalman 500W
- REFURBISHED - DELL Performance Dock WD19DCS (210-AZBN)
- Gamer PC-Számítógép! Csere-Beszámítás! R5 5500 / RX 6600XT / 32GB DDR4 / 512GB SSD
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: Promenade Publishing House Kft.
Város: Budapest