One of my systems (Mac, GHC 7.6.3 64 bit) is encountering a crash immediately on start. No vty code has been executed in this case. According to valgrind the stack is the same: crash at evacuate1 in the GC.
I've reproduced the lint failure with a small example separate from Yi: https://gist.github.com/coreyoconnor/8693470 This only fails when compiled ghc -O -debug -dcore-lint Main The core lint error also occurs with GHC HEAD compiled at 2013/12/12. For now I just filed this as a bug. I figure any core lint error is a bug in GHC. *shrug* https://ghc.haskell.org/trac/ghc/ticket/8714 I'll see about working around this. Cheers, Corey -Corey O'Connor [email protected] http://corebotllc.com/ On Wed, Jan 29, 2014 at 1:05 AM, Corey O'Connor <[email protected]>wrote: > I tried compiling vty then yi with core-lint. The vty compile succeeded > without error. The yi compile failed with quite a few errors. I've attached > the full core-lint output. > > The error appears to be the existential argument to HLState. The > description is: > > <no location info>: Warning: > In the type `cache_s9bd' > @ cache_s9bd is out of scope > > Not sure why the error occurs. Some existential quantification issue? > > I've run yi under valgrind. Which gives a bit more information to where > the invalid write occurs: > > evacuate1 (in /home/coconnor/.cache/yi/yi-linux-x86_64) > scavenge_block1 (in /home/coconnor/.cache/yi/yi-linux-x86_64) > scavenge_loop1 (in /home/coconnor/.cache/yi/yi-linux-x86_64) > scavenge_until_all_done (in /home/coconnor/.cache/yi/yi-linux-x86_64) > GarbageCollect (in /home/coconnor/.cache/yi/yi-linux-x86_64) > scheduleDoGC (in /home/coconnor/.cache/yi/yi-linux-x86_64) > schedule (in /home/coconnor/.cache/yi/yi-linux-x86_64) > scheduleWorker (in /home/coconnor/.cache/yi/yi-linux-x86_64) > start_thread (in > /nix/store/zm4bhsm8lprkzvrjgqr0klfkvr21als4-glibc-2.17/lib/ > libpthread-2.17.so) > > Cheers, > Corey > > > -Corey O'Connor > [email protected] > http://corebotllc.com/ > > > On Tue, Jan 28, 2014 at 1:09 PM, Corey O'Connor <[email protected]>wrote: > >> >>> Well, did you manage to narrow down whether this is a problem with Vty >>> or Yi? I imagine it's a problem with a change from 4.7 to 5.0 in Vty. In >>> that case, did you manage to come up with a test case in Vty itself? >>> >> >> I never did narrow this down to yi or vty. Only yi + vty causes me any >> issue. Yi - vty (by removing the output statements) does not crash with the >> same or similar steps. However, for memory corruption type bugs that >> doesn't mean much; the corruption could just be elsewhere and benign. None >> of the vty tests or example programs encounter a crash. The tests and >> examples exercise all the same code paths as yi. Last I checked test >> covered all normal execution pathways. Only failure pathways representing >> internal inconsistencies (which should not occur) are not exercised. All >> the tests have also run under valgrind with no warnings or errors. >> >> So yea.. The data I have doesn't help narrow it down much. Just kinda >> guessing... >> >> The changes in vty 5 largely eliminate unsafe and primitive operations. >> They are replaced with libraries that, presumably, do the same but with >> higher assurance of being correct. The only part that wasn't changed from >> vty 4.7 to 5 was the output layer. Which did some careful pointer >> manipulation to set up a buffer for efficient output. This was the code I >> removed from yi and assumed most likely to be the source of problems. >> >> >>> I have two more 32-bit Linux boxes (headless) that I could be trying to >>> replicate the problem on but it'd be much easier to do so if the test >>> was automated rather than me sitting here for 5 minutes and playing with >>> tabs in Yi. >>> >> >> Agreed. Thus far I haven't found an easy way to replicate the problem >> aside from a ridiculous: install everything and manually switch tabs a lot. >> :-\ >> >> >>> If you don't know where in Vty the problem is, maybe you could at least >>> automate Yi to do the tab business for you. See [1] for a useful config >>> file which you can use to automate keystrokes. If you could provide such >>> config with your test case, it'd be much easier on anyone trying to >>> reproduce the problem. >>> >>> In any case, I don't think we can safely consider a move to Vty 5.0 with >>> this issue around. >>> >> >> Agreed. The release of vty 5 is on hold until this issue is resolved. >> >> >>> >>> [1]: >>> >>> https://github.com/yi-editor/yi/blob/master/yi-contrib/src/Yi/Config/Users/Cmcq.hs >>> >>> >>> -- >>> Mateusz K. >>> >>> -- >>> -- >>> Yi development mailing list >>> [email protected] >>> http://groups.google.com/group/yi-devel >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "yi.devel" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> > -- -- Yi development mailing list [email protected] http://groups.google.com/group/yi-devel --- You received this message because you are subscribed to the Google Groups "yi.devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
