Perl 6 - the future is here, just unevenly distributed

IRC log for #divine, 2013-08-31

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
06:10 xstill skara, ono to stejně kompiluje, že. Opravím to
06:17 spito joined #divine
06:20 spito left #divine
06:27 xstill ten můj threadový příklad se už dá verifikovat, díky za ten atomic.
07:39 xHire joined #divine
08:37 xstill hm, dostávám na threadovém příkladu občas signal 11, asi budu v divine nějaký race
08:59 xstill ten SEGV je v poolu, dereference. níž ve stacku je allocate, llvm::Interprete::initial
09:00 xstill je to uvnitř valgrind sekce
09:00 xstill v fromFreeList
09:07 xstill je to divné, nevidím jak by se ten pointer mohl uvolnit než se dereferencuje
09:32 mornfall já jedu zachvíli do Vídně, klidně to vykoumej, já se budu zabývat tabulkama, resp. teď už storama zatim
09:32 mornfall večer se vrátim a kdyžtak se na to podívám
09:32 mornfall nebo teda jak chceš samozřejmě :-)
09:34 xstill uvidím co zjistím.
09:34 xstill btw. http://gcc.gnu.org/wiki/DebugFission
09:35 xstill bohužel to ale v gcc 4.7.2 nefunguje
09:35 xstill ačkoli tvrdí že by mělo
09:36 xstill ale zdá se že tam mají i další způsoby jak zlepšil práci linkeru
09:37 mornfall a všechno potřebuje gold
09:38 mornfall no nic
09:38 mornfall jdu :-) bbl
14:52 xstill super, void std::__enable_shared_from_this_helper<(__gnu_cxx::_Lock_policy)2>(std::__shared_count<(__gnu_cxx::_Lock_policy)2> const&, ...) je variadic někde v shared_ptr a tím pádem to nefunguje
14:54 xstill jako teda, vzhledem k tomu, že máme vlastní atomic je na zvážení jestli shared_ptr nepřeplácnout taky
16:02 xstill dobré je, že stdarg.h z PDClib nám to překládá přímo na llvm intrinsic
16:08 xstill a nebo taky možná ne, je to divné ale nevidím tam va_arg nikde
16:35 xstill ad SEGV: vypadá to, že se do free-listu dostane nevaliní Pointer
16:36 xstill nebo spíš je celej ten free-list vadnej
16:51 xstill co je to za divnou magii v pool.h:316 (ten freechunk( p ) je taková divná věc)
16:51 xstill ?
17:11 xstill hm, už to asi začínám chápat, jsem poněkud nečekal, že to jsou vlastně dva vnořený zřetězený seznamy, jeden v těch pointerch v head, a jeden na první pohled viditelnej přes next, kterej je ale jen k mezivláknové komunikaci
17:54 xstill nevím kde je chyba, zdá se že se tam dostává neinicializovaná hodnota z globálního free-listu
18:50 mornfall to je hrozně divný aby to byla chyba v Pool-u ne?
18:50 mornfall že to padá právě na tom jednom příkladu...
19:03 mornfall xstill: jak velkej ten atomic.bc je? :-)))
19:04 mornfall hm, a hlavně to segvilo v atomic_interface
19:18 mornfall jestli se někde nesdílí pool ve skutečnosti
19:19 xstill no právě že to nepadá jen na jednom
19:20 xstill ty atomiky mají řádově oba tak 2000 stavů myslím
19:20 xstill ale mě to padá na modelu, kde testuju thready
19:21 mornfall jo tak
19:21 xstill hm, zdá se že je to při inicializaci, nebo těstě po
19:21 xstill vlastně v tom stacku bylo initials
19:21 mornfall jo, mám tady gdb s padnutým procesem
19:22 mornfall zachvíli se na to podívám
19:26 xstill hm, tak mě napadá, jestli se ten free-list dynamicky alokovaný na 252 inicializuje...
19:26 xstill (nejsem si úplně jistý na čem všem záleží jestli jo)
19:29 xstill vlastně tam je inicializace explicitní
19:29 xstill ale v to je asi ten race
19:30 xstill protože alokace -> jiný to najde -> jiný vezme pointer -> inicializace
19:37 xstill až teda na to že atomic by měl být třída, takže k inicializaci v tom new by dojít mělo ne?
19:50 xstill hm, vida zdá se že i alokaci typu new int[ N ] lze udělat s inicializací new int[ N ]()
19:51 xstill aneb kolik různých druhý závorok lze zaspat za sebou v c++ :-P
19:57 xstill mornfall: zdá se že jsem to našel a opravil
20:06 mornfall oj :)
20:08 mornfall ale jestli to je ve _reelist_big tak možná trochu vysvětluje proč se to děje jen s LLVM
20:08 mornfall _freelist*
20:08 mornfall nic jinýho asi stavy větší než 4K negeneruje
20:09 mornfall a jo, asi to je fakt blbě
20:09 xstill jo no, docela mě překvapuje že ten atomic_iterface má tak velké stavy
20:10 xstill já blbec jsem si velikost stavů neověřil dřív
20:10 xstill takže jsem hledal chybu jinde
20:10 xstill na mailu máš pathch který přesouvá inicializaci přímo do new
20:12 mornfall to co mi není jasný je jak jde napsat třídu která se chová takhle
20:13 mornfall vysvětlit ten patch by mohl být dost dobrý úkol do C++ ;-)
20:13 xstill jak? že se neinicializuje na new[] ?
20:13 mornfall no, že se chová jako POD
20:13 xstill já jsem si musal najít jak to s tím new je na cppreference
20:14 xstill no on atomic může být jen wrapper nad C strukturou, kvůli C11
20:14 mornfall hmm
20:14 mornfall aha
20:14 xstill standard říká, že je to standard-layout, jen jsem nikde neviděl jak se to má inicalizovat
20:14 xstill protože to není úplně POD
20:15 mornfall no, ono asi hlavně záleží od specializace jestli to je nebo není POD
20:15 xstill jo no a mám podezření jestli ten náš atomic se chová stejně
20:16 xstill tohle je strašně zákeřné zákoutí C++
20:16 mornfall :-))
20:17 mornfall já na to dneska taky dojel
20:18 mornfall ještě jinde
20:20 xstill kdyžtak si pak přečti backlog, našel jsem že budeme potřebovat variadic-argument podporu
20:20 xstill a clang to asi nějak divně překládá nebo co
20:20 mornfall jo, vidím :-)
20:20 mornfall aj v trac-u
20:20 mornfall proč divně?
20:21 xstill zkoušel jsem přeložit použití va_arg a nikde tam nevidím odpovídající instrukci llvm
20:21 xstill ačkoli pdclib by to měla dát na intrinsic
20:22 mornfall to není instrukce ale call
20:22 mornfall call llvm.va_start nebo tak něco
20:23 xstill tohle myslím: http://llvm.org/docs/LangRef.html#va-arg-instruction
20:23 mornfall http://llvm.org/docs/LangRef.html#llvm-va-start-intrinsic
20:23 mornfall zajímavé
20:23 mornfall :-)
20:23 mornfall jo, va_arg je instrukce, jako jediná
20:43 mornfall no, otázka je jestli #ifdef __GNUC__ :-)
20:45 xstill zkusil jsem to i vyhodit ten ifdef
20:45 xstill ale ono jinak by tam nebylo ani va_start
20:46 mornfall Unfortunately, that's pretty much the only option right now, and what
20:46 mornfall Clang does – LLVM's va_arg instruction does not work with aggregate
20:46 mornfall types (see the Language Reference). Why? I'm not sure…
20:46 mornfall (rok stará informace teda)
20:48 mornfall Note that the code generator does not yet fully support va_arg on many targets. Also, it does not currently support va_arg with aggregate types on any target.
20:49 mornfall to je zase jednou podvod... :-P
20:49 xstill hm, to teda nevím co nám zbývá
21:19 xstill i když ono to vlastně není tak strašné, protože clang vygeneruje normální call a my si s tím pak můžeme nějak poradit uvnitř divine, třeba specielní funkcí, ne?
21:20 mornfall no, nebude to tak jednoduché
21:21 mornfall on do tý va_list struktury přímo hrabe
21:21 mornfall takže asi nezbude než v pdclib vyrobit inline assembler
21:21 mornfall nebo nějakou podobnou hrůzu
21:24 mornfall http://clang-developers.42468.n3.nabble.com/PATCH-adding-flag-for-generating-va-arg-instructions-td3918852.html tady to je aj s patchem
21:24 mornfall který se asi nedostal do upstream-u
21:24 xstill no myslel jsem spíš v pdclib vyrobit vlastní funkci na to, ale problém vlastně je že to obsahuje typ
21:25 mornfall z typu potřebuješ asi jen sizeof
21:26 mornfall takže jo, takhle to půjde, i když je to škaredý
21:27 mornfall já si mezičasem aspoň napsal test a našel co budu muset kde upravit
21:27 mornfall ale implementace nejdřív zejtra
21:28 xstill jasný, já zatím budu hrabat jinde :-)
21:30 xstill btw. s vcelku malýma modifikacema už jsme schopný zkompilovat a spustit test na pool pod divine
21:30 mornfall to je hezký :-)

| Channels | #divine index | Today | | Search | Google Search | Plain-Text | summary