Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Modrá je dobrá
zelená je lepší

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub C, C++ [ŽP: neomezená] (kategorie Programování) moderuje Šéf Lopuchu.
Archiv

Články

Jak bezpečně ukončit vlákno z DllMain
FastAllocPool - urychlení častých alokací a dealokací
Akce a zpráva jako objekt
Tuply v C++
Efektivní alokátor malých objektů a tady druhý a třetí díl
Šablony: Být vládce kvalifikátorů
Vracíme z funkce objekty
Základy komunikace mezi procesy (ve Windows)
Multiple Interface a Instance Factory
Multithreading v C++ (ve Win32)
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: hajkpfr
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
huh huh 27.1.2009 14:03  740
BTW, výborná kniha Pasti a propasti jazyka C++ jen za 87 Kč.
Zlevněno toho maj samozřejmě víc (Symbian atd...).
bredy 31.12.2008 00:32  739
Další pokus o Garbage Collector v C++
ago 4.11.2008 22:23  738
moc moc dakujem
bredy 4.11.2008 21:30  737
(slovenský překlad) :-D
bredy 4.11.2008 21:28  736
AGONo v Céčku můžeš použít normálně fopen(). Funkce akorát musí tento soubor buď vrátit nebo předat nějak jinak.

Soubor se deklaruje jako:
FILE *soubor;


Pokud ho chceš z funkce vracet.
FILE *otevriSoubor( ... ) {
  ...
  ...
  FILE *soubor = fopen(...);
  ...
  return soubor;
}

Pak soubor někdy zavřeš
fclose(f);

Více zde (český překlad)

ago 4.11.2008 20:51  735
Ahojte. Potrebujem (v Cecku)otvorit subor vo funkcii, ale tak aby zostal otvoreny aj po jej ukonceni. Proste aby s tym suborom mohli pracovat aj ine funkcie az kym ho nejakou inou funkciou nezatvorim. Mozno pre niekoho lahka otazka, no ja si akosi neviem dat rady :( Dakujem.
decide 23.9.2008 15:34  734
machAno, přesněji, nesaháš na GUI ze dvou vláken?
bredy 23.9.2008 11:50  733
založil jsem seriál o serializaci, kde jsou všechny články hezky překledně pod sebou. koho téma zajíma, necht zkusí následující link.

serializace objektů
mach 22.9.2008 15:57  732
Bredy: Diky. Prozkoumal jsem ruzny debugovaci nastroje a nakonec se dostal k tomu, ze sem to zkompiloval pod Linuxem a gdb/valgrindem (ktery jestli to dobre chapu kontroluje ty "narazniky", pokud je tam teda gcccko s parametrem -g da) nasel leakovani pameti :-)
bredy 19.9.2008 02:03  731
Při sledování paměti možná pomůže tohle Magic debug values
bredy 19.9.2008 01:56  730
Tohle se mi často dělo u objektů s počítanou referencí. Jedno vlákno snížilo referenci a druhé z výšilo. Občas se to ale trefilo mezi, že ti pak byl schopen vyjít výpočet tak že 1 + 1 = 1 (protože druhé vlákno z toho udělalo 0 a 0 + 1 = 1. Pak došlo k tomu, že jedno vlákno uvolnilo paměť (čítač referencí klesl na nulu) a to druhé tam následně zapsalo jedničku. Člověče, dost mě šokovalo, jak často mi to takhle spadlo.

Jinak tahle chyba se detekuje tak, že v debug verzi je paměť vyplněná známou hodnotou. Hodně pak pomůže prozkoumat obsah změnené paměti, zda změna neodpovídá něčemu. Například já na to přišel tak, že jedno 32-bit slovo tam bylo inkrementováno (mám pocit, že se to vyplñuje CDCDCDCD a já tam viděl CECDCDCDCD, takže to bylo jasné). A pozor na to, že chyba se může objevit až za hodně dlouho. Doporučuju logovat alokace a při vzniku chyby si projít log a najít tu alokaci, která paměť alokovala a dealokovala.

Pokud používáš nějaké chytré pointery, tak čítače referencí by měly být měněny přinejmenším funkcí InterlockedIncrement / Decrement, namísto obyčejné ++

Jo, aspektem téhle chyby je, že vzniká náhodně. Pokud ti vzniká pravidelně, tak tam někde skutečně zapisuješ do dealokované paměti. Ale to by mělo jít debugerem snadno zjistit.
mach 19.9.2008 00:18  729
BredyPresne tak, mam tam dve vlakna. Jedno je hlavni (stara se o vypocty, posila veci do OpenGL, …), druhe o nacitani obrazku. Dve knihovny jsou pouzivany v obou vlaknech (OpenGL a OpenCV) - ani u jedne nevim, jak moc je thread safe, takze tam mam dva mutexy (definovany jako globalni promenny) a pres ne je zajistena exklusivita pri praci vlanka s tema knihovnama. (Na ty mutexy pouzivam knihovnu pthreads-win32.)
bredy 18.9.2008 22:48  727
machNeběží ti tam dvě vlákna (nebo vice?)
mach 18.9.2008 21:16  726
Prosim, zabijte me.Mam muj program (na Windows XP + MSVC 2008 Express) a pada mi s touhle hlaskou:

HEAP[insight3d.exe]: HEAP: Free Heap block 293c770 modified at 293c780 after it was freed
Windows has triggered a breakpoint in insight3d.exe.


Dela to celkem nahodne:

  1. Casto pri nejake interakci s GUI (jako GUI knihovnu pouzivam Agar, ale neni to zas tak dulezite). Vetsinou mi pak Visual Studio zustane viset uvnitr funkce z te GUI knihovny.
  2. To same se mi ted zacalo dit i po napsani jedne funkce, ktera celkem intenzivne alokuje a dealokuje pamet (ale ne moc sofistikovane, nevypada to, ze tam mam overflow). V tomhle pripade to skonci provedenim free().

Pouzivam hodne (cca 10) cizich knihoven a hodne hodin uz na to nemuzu prijit. Tipuju, ze nejpravdepodobnejsi jsou dve moznosti:

  1. nektera z tech cizich knihoven prepisuje neco, co nema
  2. linkuju dohromady spatne verze knihoven (= zkompilovane pod ruznymi runtime)

Da se tohle nejak rozumne vydebugovat? Muzu u knihovny (.lib nebo .dll) zjistit, s kterym runtimem je zkompilovana (LIBCMT.lib nebo MSVCRT.lib)?

Co vim, tak clovek nesmi pouzivat dohromady knihovny zkompilovane s /MD a /MT - musi to byt jednotne. Kdyz se to pomicha, tak jednak linker zahlasi warning, ze spolu koliduji MSVCRT.lib a LIBCMT.lib a taky to muze odlitavat. Prosel jsem vsechny pouzivane knihovny a bud je prekompiloval nebo se alespon podival, co autori tvrdi. Ted bych tedy mel mit vsechno kompilovane jako "Multi-thread DLL" (/MD). Ale porad mi to pada.

Asi nejzavaznejsi dotaz: Muzu vzit knihovny (.lib, .dll) zkompilovane pod MSVC 2005 a pouzivat je v MSVC 2008 Express (tedy asi se muze stat, ze treba knihovny budou zkompilovane spolu s MSVCRT70.lib a hlavni program s MSVCRT80.lib). Pritom pokud nejaka knihovna alokuje pamet, tak ji uvolni jen ta sama knihovna - nikoliv jina.
bredy 9.9.2008 16:34  725
Serial o serializaci IIDruhý díl o serializaci

[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt