Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - hazardrok

Stran: 1 2 3 [4]
46
Vývoj / Re:Segmentation fault
« kdy: 01. 04. 2020, 07:52:57 »
Já ta mám vlákna přesně dvě. Jedno hlavní, které dělá většinu věcí. To druhé dělá jen jednu jedinou věc a tou je příjem SSH spojení. Tento příjem se mi totiž nepovedlo udělat jako neblokující.

47
Vývoj / Re:Segmentation fault
« kdy: 31. 03. 2020, 13:41:57 »
Od doby co jsem ten program spustil přes Valgrind, ani jednou to nespadlo. Je to v podstatě od doby co běží toto vlákno. Když ten program ručně kylnu třeba po několika dnech, vypíše mi to přibližně toto:
Kód: [Vybrat]
==30609==   total heap usage: 7,366,709 allocs, 7,366,674 frees, 686,513,208 bytes allocated
==30609==
==30609== LEAK SUMMARY:
==30609==    definitely lost: 0 bytes in 0 blocks
==30609==    indirectly lost: 0 bytes in 0 blocks
==30609==      possibly lost: 304 bytes in 1 blocks
==30609==    still reachable: 246,510 bytes in 34 blocks
==30609==         suppressed: 0 bytes in 0 blocks
==30609== Rerun with --leak-check=full to see details of leaked memory
==30609==
==30609== For counts of detected and suppressed errors, rerun with: -v
==30609== Use --track-origins=yes to see where uninitialised values come from
==30609== ERROR SUMMARY: 3971 errors from 23 contexts (suppressed: 0 from 0)
Takže stále pátrám...

48
Vývoj / Re:Segmentation fault
« kdy: 09. 03. 2020, 11:13:28 »
Z toho, jak jsi měl potřebu zmínit svoji opatrnost, úplně čiší, že s pamětí pracovat neumíš. Tak nepiš v Céčku.

Můžu se autora zeptat z čeho v mém dotazu vyplývá to, že neumím pracovat z pamětí?

Za komentáře díky. Zkusím rady aplikovat. Co se týče toho komentu
Citace
nedošla paměť? když malloc teda selhal...
tím si nejsem úplně jistej. Mám vyzkoušeno, že pokud dojde paměť, tak se zhroutí celej systém a dojde k jeho restartu. To se mi nikdy nestalo.

Jinak ten server mi běží už pár let a nikdy se mi to nestávalo. Nedávno jsem ale změnil princip řízení filedescriptorů ze select na epoll. To byl poměrně velký zásah a od té doby jsem začal mít tyto problémy. Furt mě to tak trochu směřuje tam.

Doufám, že Vám to všem jde líp než mě :-)

49
Vývoj / Segmentation fault
« kdy: 09. 03. 2020, 08:19:08 »
Ahoj chtěl bych se zeptat na problém se kterým si nevím rady. Napsal jsem si TCP server v Cčku. Občas se mi stane a je to čistě náhodný proces, že mi server spadne. Někdy se to nestane týdny a někdy se to děje několikrát denně. Nebyl jsem schopen dostat z návratové chyby víc než "Segmentation fault" tak jsem zpusil použít GDB. Díky němu mám lepší výpis toho co se tam děje:
Kód: [Vybrat]
Thread 2 "main" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff49e8700 (LWP 30711)]
_int_malloc (av=av@entry=0x7ffff0000020, bytes=bytes@entry=128)
    at malloc.c:3779
3779    malloc.c: No such file or directory.

Z tohodle také moc moudrej nejsem, protože osobně se funkci malloc vyhejbám. Používám jí velice zřídka a snažím se co nejdůsledněji kontrolovat její použití. Kód dokonce spadne v momentě, kdy ani nejsem v bloku jejího volání. Napadá mě tedy jediné a to je, že to způsobuje nějaká knihovna třetí strany. Používám pro řízení filedescriptorů epool což mi zde na fóru někdo poradil a také SQLlite.

Neřešil jste někdo něco podobného nebo nemáte nápad jak se tohoto problému zbavit?
Dík.


50
Server / Re:Maximální počet klientů vlastního TCP serveru
« kdy: 19. 12. 2019, 22:39:43 »
Tak jsem zkusil ten celej server predelat ze select() na epool() podle tohodle prikladu:
http://www.voidcn.com/article/p-uvhjqbmi-uo.html
V tuhle chvili mi startujou klienti a uz jich je vic nez 1600. Zatim se nestal zadnej karambol, takze se zda ze to bylo skutecne maximalnim omezenim FD_SETSIZE, ktere je defaultne na 1024.

Problem tedy povazuju za vyreseny. Dik moc vsem zucastnenym, doufam ze Vam prace dela radost :)

Jest bych chtel dodat, ze to proc ten server padal jsem doposud uplne nepochopil. Zrejme to bylo zpusobeno volanim FD_ISSET, vstupni parametry jsem totiz nekontroloval. Asi se to zavolalo s nejakym nesmyslem a tim to spadlo. Tim uz se ale zabyvat nebudu.

51
Server / Re:Maximální počet klientů vlastního TCP serveru
« kdy: 19. 12. 2019, 16:16:16 »
Dik za reakce, zkousim co se da...googleni, zmena bufru a nic nepomaha. Vse se zda ze by to melo fungovat.
Posledni reakce:
Citace
Střelba od boku: nepoužíváš náhodou select()?
Tak zde jsem ze zaseknul, protoze select skutecne pouzivam....

52
Server / Re:TCP server
« kdy: 19. 12. 2019, 12:51:05 »
Je to napsany v Ccku s pouzitim standartnich systemovych knihoven. Verze linuxu: Ubuntu 18.04.1 LTS.

53
Server / Maximální počet klientů vlastního TCP serveru
« kdy: 19. 12. 2019, 12:20:54 »
Ahoj, chtel bych se zeptat, zda by mi nekdo nedokazal poradit s TCP serverem. Napsal jsem si testovaci TCP server ke kteremu se pripojuji nejaka zarizeni zvenku a server z nich kazkou minutu stahne nejaka data. Ta zarizeni jsou trvale pripojena k serveru. Toto vse plni ma ocekavani a spolehlive funguje. Problem nastal v momente, kdy jsem se rozhodnul zatizit server. Zatez byla provedena tak, ze se vytvoril TCP clienta, ktery simuluje nove zarizeni a tento client byl nekoliksetkrat spusten. Jakmile mnozstvi clientu presahlo hodnotu 1024 server se zacal chovat divne a padat. Udajne je to dane tim, ze kazdy proces v linuxu ma nastaveno maximalni mnozstvi filedescriptoru, ktere muze pri svem behu otevrit. Overil jsem tedy tento prikaz:
Kód: [Vybrat]
ulimit -a a dostal tento vypis:
Kód: [Vybrat]
[core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 14853
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 14853
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Z tohoto jsem usoudil, ze mam skutecne nastaven maly limit a tak jsem do souboru:
Kód: [Vybrat]
/etc/security/limits.confpridal tyto dva radky:
Kód: [Vybrat]
rudolf          hard     nofile          32768
rudolf          soft     nofile          32768

Po restartu PC a novem vypisu maximalniho mnozstvi jsem dostal ocekavane udaje. Jake bylo ale me prekvapeni, kdyz po vytvoreni 1024 clientu server opet spadnul. V tento moment jsem uz naprosto bezradny a nevim jak dal. Nevite kde je problem? DIK.

54
Software / Re:Sledování průběhu práce na SW projektu
« kdy: 06. 11. 2019, 09:51:56 »
Ahoj a dík za reakce. Podle toho ale soudím, že jsem se možná špatně vyjádřil co vlastně chci...Občas za mnou přijde můj šéf a zeptá se mě kolik času jsem strávil programováním nějaké funkce. Tohle je schopen udělat třeba i za měsíc od realizace. Zjistil jsem, že většinou nedokážu odpovědět. Dělám to tam, že se kouknu do repozitáře (mercurial), kdy se dělaly nějaké změny, zalovím v paměti a řeknu počet hodin. On to vynásobí dvakrát až třikrát podle toho jak důvěrně se tvářím a vyplyne z toho výsledná hodnota.
Chtěl bych to nyní dělat lépe a mít větší přehled, protože občas si k tomu sednu i doma, ale tam se práce výrazně komplikuje. Člověk si občas odběhne např. přiložit, udělat oběd apod. Když mu řeknu, že jsem to dělal celý víkend kdy jsem začal v jedenáct dopoledne a skončil ve dvě ráno asi nebude úplně nadšenej sečtením všech hodin.
Podle mě tedy používat data z repozitáře nelze, protože ty jsou závislá na počtu provedených komitů. Ty by se tedy museli dělat nějak automaticky a tyto automatické oddělit od těch skutečných. Je možné se něco takového se děje, protože když sleduju historii úprav přímo v netbeans tak tam jsou nějaké lokální změny, které se zaznamenávají velice často. Nepovedlo se mi ale zatím zjistit kde se to bere, protože v repozitářích tyto záznamy buď nejsou nebo jsou skryté.

No každopádně pokud toto někdo nějak řeší pokud vůbec, tak se rád přiučím.

55
Software / Re:Sledování průběhu práce na SW projektu
« kdy: 05. 11. 2019, 12:36:49 »
Dík za reakci. Toto vypadá zajímavě, ale příjde mi že to je příliš svázané z repozitářem. Měl jsem na mysli něco odděleného od internetu co běží naprosto nezávisle.

56
Software / Sledování průběhu práce na SW projektu
« kdy: 05. 11. 2019, 08:27:04 »
Ahoj, nevíte někdo jestli existuje nějaký program, který by dokázal jakýmkoliv způsobem sledovat jak se mění obsah nějaké složky např. psaním softwaru nebo obecně textu? Toto pak třeba někam do grafu vykreslit nebo to umožnit jinak analyzovat.

57
Hardware / Re:Stabilita ESP8266
« kdy: 24. 10. 2019, 08:38:06 »
V navázání komunikace to není, ta je bez problémů. Třeba problém na kterej jsem nikdy nepřišel když je ESPčko připojené k TCP serveru a to spojení někde na cestě zanikne. Toto není v TCP nijak ošetřeno nebo nevím jak. ESPčko si stále myslí, že je spojení aktivní a čeká na příchozí data, protože z pohledu aplikační vstvy je v komunikaci slave. Těch se už nikdy nedočká. Toto je pro mě situace ze které se ten client jednoduše nedostane. Toto je samozřejmě řešitelné. Hůř řešitelná situace je, když espčko samo náhodně spadne. Z mých zkušeností to je v 99% způsobeno při mechanizmu přidělování dynamické paměti, který zkolabuje. Toto je samozřejmě také řešitelné, ale už je to v celku náhodný proces, který se nedá jednoduše ladit. Jedině zkoušením.


58
Hardware / Re:Stabilita ESP8266
« kdy: 24. 10. 2019, 07:48:19 »
No když tak čtu na co všechno se zde ESP8266 používá tak to možná není moc stabilní. Pokud se to používá jen jako modem a všechna ostatní chytristika je jinde, tak občasný restart nevadí, protože spojení se obnoví do pěti sekund od resetu. To nikdo ani nepozná.

59
Hardware / Re:Stabilita ESP8266
« kdy: 23. 10. 2019, 22:38:34 »
Čus, mě osobně stabilita naprosto dokonalá, ale toto je pouze jeden relativní pohled. Aktuálně znám víc než 500 zařízení,která jsou trvale připojena k síti a komunikují přes ESP8266. Neběží s posledním SDK, protože vývoj s tímto modulem je již ukončen (jde to neskutečně rychle dopředu), ale SW je velice dobře vyladěn, používá se a počítám že ještě v několika stovkách bude. Je vyzkoušeno, že stabilita je závislá nejenom na routeru ke kterému je to připojeno ale hlavně na topologii sítě. Např. pokud je to připojené jen k jednomu routeru, který je blízko a jde to rovnou ven, většinou není problém a komunikuje to trvale (každou minutu několik desítek bajtů tam a zpět) třeba i několik dní. V případě prostředí s větším počtem WiFi a následných dalších routerů což beru jako ekvivalent zarušení může komunikace chcípnout v řádu minut. Někdy se to samo zmátoří, ale dost často ne. Pak se to řeší jiným způsobem, ale z celkového pohledu toto běží už od prvního vydání ESP-07 což je několik let trvale pod napětím. Za tu dobu jich odešlo tak 10 při programování a tak 5 se jich vrátilo jako nefunkční. Mě osobně to přijde hodně dobrý.

60
Server / Vlastní server pro předávání dat z databáze
« kdy: 23. 10. 2019, 19:15:37 »
Ahoj, chtěl bych se zeptat na něco ohledně TCP serveru.

Úvodem...Napsal jsem si jednovláknovej zabezpečenej TCP server SSH s použitím knihovny openssh v céčku. Až na malé nedostatky, vcelku postačuje mým požadavkům. To jest přihlášení uživatele, vytvoření přenosového kanálu, odkomunikování žádosti uživatele. Díky tomu, že uživatel si se serverem vyměňuje maximálně pár set bajtů, dokáže naráz bez problémů obsluhovat více uživatelů. Těch nebude nikdy víc než pár set celkově natož v jeden okamžik.

Nyní bych chtěl přidat novou funkci a tou je vytvoření dalšího kanálu pro uživatele. Přes tento kanál bych rád uživateli nabídnul data z sql lite databáze. Jen bych chtěl upřesnit, že uživatele nemyslím uživatele v linuxu, ale uživatele ze seznamu jiné databáze.

A teď k dotazu...zvažuju dvě varianty řešení.
1. vytvoření tohoto nového kanálu udělám v novém vlákně a tím zjednoduším výměnu dat databáze,případně budu moci přenášet i větší soubory najednou.
2. zachovám kanál ve stávajícím vlákně a budu uživateli každý soubor dávkovat v menších blocích, dokud se data neodešlou.

Něco mi říká, že druhá varianta bude složitější, ale nevim proč mi příjde jako správnější cesta. Možná jsem jen neporozumněl vláknům a jejich výhodám...

Dokázal by mě někdo nasměrovat na správnou cestu? Za případné reakce moc díky a sory pokud je to dotaz mimo...jsem jen z FEL.

Stran: 1 2 3 [4]