Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - questions on Mac OS platform
- Has anybody successfully used llvm on the Mac with 7.10.1 RC1? My problem is described below. - Which is the recommended gcc to use when building source? - GNU gcc 4.9.2 - Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) - When using ghci with 7.10.1 RC1 I get the following errors intermittently. Is anybody else seeing these? - Too late for parseStaticFlags: call it before runGhc or runGhcT *** Exception: ExitFailure 1 - ld: library not found for -l:ghc31505_10.dylib collect2: error: ld returned 1 exit status phase `Linker' failed (exitcode = 1) Thanks On Fri, Jan 2, 2015 at 9:12 AM, George Colpitts george.colpi...@gmail.com wrote: Only problem remaining is compiling with -fllvm and running resulting executable . .. - llvm , compiling with llvm (3.4.2) gives the following warnings: - $ ghc -fllvm cubeFast.hs [1 of 1] Compiling Main ( cubeFast.hs, cubeFast.o ) clang: warning: argument unused during compilation: '-fno-stack-protector' clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' clang: warning: argument unused during compilation: '-I .' clang: warning: argument unused during compilation: '-fno-common' clang: warning: argument unused during compilation: '-U __PIC__' clang: warning: argument unused during compilation: '-D __PIC__' Linking cubeFast ... - running the resulting executable crashes (compiling without -fllvm gives no warnings and executable works properly) - cat bigCube.txt | ./cubeFast /dev/null Segmentation fault: 11 - Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0xfffd5bfd8460 - ... Configuration details: - Mac OS 10.10.1 (Yosemite) - uname -a Darwin iMac27-5.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64 - llvm info: - opt --version LLVM (http://llvm.org/): LLVM version 3.4.2 Optimized build with assertions. Built Oct 31 2014 (23:14:30). Default target: x86_64-apple-darwin14.0.0 Host CPU: corei7 - gcc --version gcc (Homebrew gcc 4.9.1) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - /usr/bin/ghc --info [(Project name,The Glorious Glasgow Haskell Compilation System) ,(GCC extra via C opts, -fwrapv) ,(C compiler command,/usr/bin/gcc) ,(C compiler flags, -m64 -fno-stack-protector) ,(C compiler link flags, -m64) ,(Haskell CPP command,/usr/bin/gcc) ,(Haskell CPP flags,-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs) ,(ld command,/usr/bin/ld) ,(ld flags, -arch x86_64) ,(ld supports compact unwind,YES) ,(ld supports build-id,NO) ,(ld supports filelist,YES) ,(ld is GNU ld,NO) ,(ar command,/usr/bin/ar) ,(ar flags,clqs) ,(ar supports at file,NO) ,(touch command,touch) ,(dllwrap command,/bin/false) ,(windres command,/bin/false) ,(libtool command,libtool) ,(perl command,/usr/bin/perl) ,(target os,OSDarwin) ,(target arch,ArchX86_64) ,(target word size,8) ,(target has GNU nonexec stack,False) ,(target has .ident directive,True) ,(target has subsections via symbols,True) ,(Unregisterised,NO) ,(LLVM llc command,llc) ,(LLVM opt command,opt) ,(Project version,7.8.3) ,(Booter version,7.6.3) ,(Stage,2) ,(Build platform,x86_64-apple-darwin) ,(Host platform,x86_64-apple-darwin) ,(Target platform,x86_64-apple-darwin) ,(Have interpreter,YES) ,(Object splitting supported,YES) ,(Have native code generator,YES) ,(Support SMP,YES) ,(Tables next to code,YES) ,(RTS ways,l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn) ,(Support dynamic-too,YES) ,(Support parallel --make,YES) ,(Dynamic by default,NO) ,(GHC Dynamic,YES) ,(Leading underscore,YES) ,(Debug on,False) ,(LibDir,/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3) ,(Global Package DB,/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d) ] - Not sure I found the correct instructions for building from source, I used the following: - $ autoreconf $ ./configure $ make $ make install On Tue, Dec 23, 2014 at 10:36 AM, Austin Seipp aus...@well-typed.com wrote: We are pleased to announce the first release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc1/ This includes
Re: Thread behavior in 7.8.3
I have narrowed down the problem a bit. It turns out that many times if I run the program and wait long enough, it will start. Given an event log, it may take from 1000-1 entries sometimes. When I look at a good start vs. slow start, I see that in both cases things startup and there is some thread activity for thread 2 and 3, then the application starts creating other threads, which is when the wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case, it just gets stuck on thread 2/3 activity for a very long time. If I switch from -C0.001 to -C0.010, the startup is more reliable, in that most starts result in an immediate GUI and i2c IO. The behavior suggests to me that some initial threads are starving the ability for other threads to start, and perhaps on a dual core machine it is more of a problem than single or quad core machines. For certain, due to some printing, I know that the main thread is starting, and that a print just before the first fork is not printing. Code between them is evaluating wxhaskell functions, but the main frame is not yet asked to become visible. From last week, I know that an non-gui version of the app is getting stuck, but I do not know if it eventually runs like this case. Is there some convention that when I look at an event log you can tell which threads are OS threads vs threads from fork? Perhaps someone that knows the scheduler might have some advice. It seems odd that a scheduler could behave this way. The scheduler should have some built in notion of fairness. On Jan 12, 2015, at 11:02 PM, Michael Jones m...@proclivis.com wrote: Sorry I am reviving an old problem, but it has resurfaced, such that one system behaves different than another. Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on a single core 32 bit Atom NUC. But on a dual core Atom MinnowBoardMax, something bad is going on. In summary, the same code that runs on two machines does not run on a third machine. So this indicates I have not made any breaking changes to the code or cabal files. Compiling with GHC 7.8.3. This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1 kernel. It is a dual core 64 bit I86 Atom processor. The application hangs at startup. If I remove the -C0.00N option and instead use -V0, the application runs. It has bad timing properties, but it does at least run. Note that a hang hangs an IO thread talking USB, and the GUI thread. When testing with the -C0.00N option, it did run 2 times out of 20 tries, so fail means fail most but not all of the time. When it did run, it continued to run properly. This perhaps indicates some kind of internal race condition. In the fail to run case, it does some printing up to the point where it tries to create a wxHaskell frame. In another non-UI version of the program it also fails to run. Logging to a file gives a similar indication. It is clear that the program starts up, then fails during the run in some form of lockup, well after the initial startup code. If I run with the strace command, it always runs with -C0.00N. All the above was done with profiling enabled, so I removed that and instead enabled eventlog to look for clues. In this case it lies between good and bad, in that IO to my USB is working, but the GUI comes up blank and never paints. Running this case without -v0 (event log) the gui partially paints and stops, but USB continues. Questions: 1) Does ghc 7.8.4 have any improvements that might pertain to these kinds of scheduling/thread problems? 2) Is there anything about the nature of a thread using USB, I2C, or wxHaskell IO that leads to problems that a pure calculation app would not have? 3) Any ideas how to track down the problem when changing conditions (compiler or runtime options) affects behavior? 4) Are there other options besides -V and -C for the runtime that might apply? 5) What does -V0 do that makes a problem program run? Mike On Oct 29, 2014, at 6:02 PM, Michael Jones m...@proclivis.com wrote: John, Adding -C0.005 makes it much better. Using -C0.001 makes it behave more like -N4. Thanks. This saves my project, as I need to deploy on a single core Atom and was stuck. Mike On Oct 29, 2014, at 5:12 PM, John Lato jwl...@gmail.com wrote: By any chance do the delays get shorter if you run your program with `+RTS -C0.005` ? If so, I suspect you're having a problem very similar to one that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some reason), involving possible misbehavior of the thread scheduler. On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones m...@proclivis.com wrote: I have a general question about thread behavior in 7.8.3 vs 7.6.X I moved from 7.6 to 7.8 and my application behaves very differently. I have three threads, an application thread that plots data with wxhaskell or sends it over a network (depends on
Re: Thread behavior in 7.8.3
Quoth Michael Jones m...@proclivis.com, ... 5) What does -V0 do that makes a problem program run? Well, there's that SIGVTALRM barrage, you may remember we went over that mid-August. I expect there are other effects. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
