Re: using a stage1 as a compiler for a later ghc?
Isaac Dupree wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm on a system with main ghc = 6.4.2. I've built a ghc 6.6 stage1. Is there any problem using that ghc-inplace as a compiler for GHC HEAD? (which is done e.g. by ./configure - --with-ghc=/home/isaac/hardly-mine-at-all/build/ghc-6.6/compiler/stage1/ghc-inplace ?) (which I want to do because, theoretically 6.6 should be faster here, since it supports -fasm unlike the ubuntu-edgy-powerpc-ghc-6.4.2, and also considering how my gcc likes to crash randomly a few times during anything as extensive as compiling ghc...) Sure, that should work. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to debug a segfault.
David Brown wrote: I'm developing a program with GHC-6.6. I've been on amd64, and haven't had problems, but now when I run the program on on x86 (after cleaning and recompiling), I'm getting a segfault. gdb isn't very helpful at all: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212873040 (LWP 26946)] 0x080b45b8 in s2EI_info () (gdb) bt #0 0x080b45b8 in s2EI_info () #1 0x081757a8 in ?? () #2 0x0004 in ?? () #3 0xb7875278 in ?? () I am using some various bindings to some C libraries, some I have written and some written by others. But, I'm not able to figure out where to even begin looking for the problem. Any advice on how I might be able to better debug this? Would compiling unregistered help (I'll have to figure out how to build libraries for that)? Fortunately I wrote a wiki page on just this subject, mainly so that I can say RTFM :-) After reading the FM, if you're still having difficulties then post a followup and we'll try to help if we can. http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to debug a segfault.
Simon Marlow [EMAIL PROTECTED] writes: Fortunately I wrote a wiki page on just this subject, mainly so that I can say RTFM :-) After reading the FM, if you're still having difficulties then post a followup and we'll try to help if we can. http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes Nice! How complicated would it be to teach gdb about GHC's calling convention, stack format, etc. Anyone who knows? -Matthias -- Matthias Neubauer | Universität Freiburg, Institut für Informatik | tel +49 761 203 8060 Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to debug a segfault.
Simon Marlow wrote: David Brown wrote: 0x080b45b8 in s2EI_info () Fortunately I wrote a wiki page on just this subject, mainly so that I can say RTFM :-) After reading the FM, if you're still having difficulties then post a followup and we'll try to help if we can. http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes This looks quite helpful, but still like it is going to be a pain in the neck. I did figure a few things out last night. - I grepped all of the libraries going into the program, and found the s2EI_info defined in libHSbase.o - Thanks to the splitting, I unared libHSbase.o into individual files, and found this label in a file that appears to be the code to 'Foreign.C.peekCAString'. This makes sense with the assembly shown. - It appears to be trying to dereference a NULL pointer. I'm going to try the back-in-time approach given to see if I can track down what is calling this. I discovered it isn't just x86, but appears to be this particular machine. My other machines work fine. There might be a library difference between the machines, or something like that. Thanks, David ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
TFP 2007: Last Call for Participation
Dear Colleagues, The deadline to register for TFP 2007 is quickly approaching. You may register at: http://cs.shu.edu/tfp2007/registration.html . Also, please be advised that the deadline to make hotel reservations at the guaranteed rate for TFP 2007 participants is also quickly approaching. Hotel information can be found at: http://cs.shu.edu/tfp2007/accomodations.html . You may browse the program and schedule for TFP 2007 at: http://cs.shu.edu/tfp2007/schedule.html . We look forward to seeing you in NYC!!! Cheers, Marco Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://cs.shu.edu/tfp2007/___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to debug a segfault.
David Brown wrote: I discovered it isn't just x86, but appears to be this particular machine. My other machines work fine. There might be a library difference between the machines, or something like that. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212225872 (LWP 10128)] 0x080b3618 in s2EI_info () (gdb) pstk 0xb79ff6b4: 0x805d0b8 s6MR_info 0xb79ff6b0: 0x8159494 zzlibzm0zi3_CodecziCompressionziZZlibziStream_a2_closure 0xb79ff6ac: 0x8159494 zzlibzm0zi3_CodecziCompressionziZZlibziStream_a2_closure 0xb79ff6a8: 0x815c020 base_DataziByteStringziBase_nullForeignPtr_closure 0xb79ff6a4: 0xb7a8768c 0xb79ff6a0: 0xb7a87510 0xb79ff69c: 0x81747a8 It looks like it might be in the zlib code. The only place that this code obviously does a peekCString is when it is about to throw an error. I'll check for a null pointer here, recompile and see if that helps. Hmm. I recompiled 'zlib' with some extra tracing and now the problem doesn't happen. Even without the tracing it is fine. Must have been something wrong with the compiled library. Scary. But, everything is working fine now. Dave ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to debug a segfault.
David Brown wrote: Hmm. I recompiled 'zlib' with some extra tracing and now the problem doesn't happen. Even without the tracing it is fine. Must have been something wrong with the compiled library. Scary. But, everything is working fine now. I figured out what the problem is. I've been working in a shared directory with both an amd64 and an x86 machines using the files. I've been going back and forth. I've been blowing away the 'dist' directory and rebuilding when moving from one platform to the other. However, what I missed is that the hsc2hs target files are placed alongside the source, not in the dist directory. I had been building zlib on x86 using the hs generated on an amd64 machine. The offsets in the structures were wrong. How difficult would it be to have Cabal store the target files in the 'dist' directory with everything else? This also makes revision control a little more challenging, because I have to hand-pick a few select .hs files to ignore, since the rest of my code is sitting right next to them. Thanks, David Brown ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci and ghc -threaded broken with pipes forking
Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
At Wed, 28 Feb 2007 11:15:04 -0600, John Goerzen wrote: You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs I get an erro when I use that darcs command-line, and test2.hs does not appear to be in the directory afterwards. Am I doing something wrong ? $ darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh Copying patch 54 of 54... done! Applying patch 54 of 54... done. darcs: Couldn't find a tag matching tag-name glasgow ml $ dpkg -l darcs Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii darcs 1.0.9~rc1-0.1 an advanced revision control system j. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
On Wed, Feb 28, 2007 at 10:40:18AM -0800, Jeremy Shaw wrote: At Wed, 28 Feb 2007 11:15:04 -0600, John Goerzen wrote: You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs I get an erro when I use that darcs command-line, and test2.hs does not appear to be in the directory afterwards. Am I doing something wrong ? Oops. I hadn't pushed out that tag yet. It's there now. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Hello, Your first problem is just a line buffering issue. You need to explicitly set the line buffer inside the child processes: redir fstdin stdInput hSetBuffering stdin LineBuffering redir fstdout stdOutput hSetBuffering stdout LineBuffering This is because the forked child process in not hooked up to a tty, so GHC decides that block buffering would be a good choice. Once you fix that you will encounter some new race condition type bugs. These bugs will show up, even *without* the -threaded flag. hth, j. At Wed, 28 Feb 2007 13:29:17 -0600, John Goerzen wrote: On Wed, Feb 28, 2007 at 10:40:18AM -0800, Jeremy Shaw wrote: At Wed, 28 Feb 2007 11:15:04 -0600, John Goerzen wrote: You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs I get an erro when I use that darcs command-line, and test2.hs does not appear to be in the directory afterwards. Am I doing something wrong ? Oops. I hadn't pushed out that tag yet. It's there now. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
On Wed, Feb 28, 2007 at 01:06:25PM -0800, Jeremy Shaw wrote: Hello, Your first problem is just a line buffering issue. You need to explicitly set the line buffer inside the child processes: redir fstdin stdInput hSetBuffering stdin LineBuffering redir fstdout stdOutput hSetBuffering stdout LineBuffering Hi Jeremy, First, many thanks for looking into this. That doesn't make sense to me, since these aren't used for anything in Haskell prior to the call to executeFile. The Haskell buffers should just disappear, since the Haskell process disappears, right? Once you fix that you will encounter some new race condition type bugs. These bugs will show up, even *without* the -threaded flag. Hrm, could you point out a couple? I'm developing as many unit tests as I can, and haven't had any problem running them under a non-threaded GHC. I am aware that the debug statements can write over each other at some cases, or even get inserted into the pipeline in a few situations, but these are only used in exceptional cases and will generally be removed from the code before too long. Other than that, I think I've got it OK. My unit tests are covering singleton commands and 2-4 commands in a pipe, including various permutations of calls to external programs and Haskell functions. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Hello, Hrm, setting the LineBuffering mode had the side-effect of setting the underlying file description to non-blocking mode. When the executeFile process took over, it would die with an error about 'standard input temporarily unavailable'. So, ignore that. j. At Wed, 28 Feb 2007 15:23:53 -0600, John Goerzen wrote: On Wed, Feb 28, 2007 at 01:06:25PM -0800, Jeremy Shaw wrote: Hello, Your first problem is just a line buffering issue. You need to explicitly set the line buffer inside the child processes: redir fstdin stdInput hSetBuffering stdin LineBuffering redir fstdout stdOutput hSetBuffering stdout LineBuffering Hi Jeremy, First, many thanks for looking into this. That doesn't make sense to me, since these aren't used for anything in Haskell prior to the call to executeFile. The Haskell buffers should just disappear, since the Haskell process disappears, right? Once you fix that you will encounter some new race condition type bugs. These bugs will show up, even *without* the -threaded flag. Hrm, could you point out a couple? I'm developing as many unit tests as I can, and haven't had any problem running them under a non-threaded GHC. I am aware that the debug statements can write over each other at some cases, or even get inserted into the pipeline in a few situations, but these are only used in exceptional cases and will generally be removed from the code before too long. Other than that, I think I've got it OK. My unit tests are covering singleton commands and 2-4 commands in a pipe, including various permutations of calls to external programs and Haskell functions. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Hello, Here is a simplified example that seems to exhibit the same behaviour, unless I screwed up: --- module Main where import System.Posix import System.IO import System.Exit main = do putStrLn running... (stdinr, stdinw) - createPipe (stdoutr, stdoutw) - createPipe pid - forkProcess $ do hw - fdToHandle stdoutw hr - fdToHandle stdinr closeFd stdinw hGetContents hr = hPutStr hw hClose hr hClose hw exitImmediately ExitSuccess closeFd stdoutw closeFd stdinw hr2 - fdToHandle stdoutr hGetContents hr2 = putStr getProcessStatus True False pid = print --- Compiling with: ghc --make -no-recomp test3.hs -o test3 ./test3 works. But compiling with: ghc --make -no-recomp -threaded test3.hs -o test3 ./test3 results in a hang. If you comment out the hGetContents hr = and change 'hPutStr hw' to 'hPutStr hw hi', then it seems to work ok. As you suggested, it seems that hGetContents is not ever seeing the EOF when -threaded is enabled. I think it gets 'Resource temporarily unavailable' instead. So, it keeps retrying. Assuming I have recreated the same bug, we at least have a simpiler test case now... j. At Wed, 28 Feb 2007 11:15:04 -0600, John Goerzen wrote: Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Linker error when building GHC HEAD on Mac OS
I'm trying to build GHC HEAD on Mac OS 10.4.8 (PowerPC), but end up with a linker error: ../compiler/stage1/ghc-inplace -o stage2/ghc-6.7.20070228 -H16m -O -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing - I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -DDEBUGGER - threaded -fforce-recompstage2/main/Main.o /usr/bin/ld: warning multiple definitions of symbol _UP /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib (terminal.so) definition of _UP /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib (lib_termcap.o) definition of _UP /usr/bin/ld: warning multiple definitions of symbol _BC /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib (terminal.so) definition of _BC /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib (lib_termcap.o) definition of _BC /usr/bin/ld: warning multiple definitions of symbol _PC /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libreadline.dylib (terminal.so) definition of _PC /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libncurses.dylib (lib_tputs.o) definition of _PC /usr/bin/ld: Undefined symbols: _stg_interp_constr1_entry _stg_interp_constr2_entry _stg_interp_constr3_entry _stg_interp_constr4_entry _stg_interp_constr5_entry _stg_interp_constr6_entry _stg_interp_constr7_entry _stg_interp_constr8_entry collect2: ld returned 1 exit status ghc: 19070104 bytes, 4 GCs, 120108/120108 avg/max bytes residency (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.10 MUT (4.20 elapsed), 0.05 GC (0.08 elapsed) :ghc make[3]: *** [stage2/ghc-6.7.20070228] Error 1 make[2]: *** [stage2/ghc-6.7.20070228] Error 2 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 Anyone any pointers? Cheers, Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc -fasm declared not too shabby
Got some initial nobench numbers for ghc head -fvia-C versus -fasm, on amd64: http://www.cse.unsw.edu.au/~dons/nobench/x86_64/results.html Overall all of nobench, ghc -fasm averages 3% slower. Not too shabby! There's some wider variation on the microbenchmarks in the imaginary class: one case 20% faster, another 30% slower, average 2% slower. On real programs though, 3% slower on average. The big benefit of course, no perl, no gcc and faster compilation times. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
