October 2005 - Glasgow-haskell-users

Re: Default name of target executable
by Tomasz Zielonka 24 Oct '05

24 Oct '05

On 10/14/05, Tomasz Zielonka <tomasz.zielonka(a)gmail.com> wrote: > On 10/14/05, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > > HEAD definitely. We don't change the specification of STABLE, only fix > > bugs. > > Great, I have the initial implementation, but I'll try to make it > prettier. Here is the patch. Some notes: - I am not sure if it's OK to modify Session in this place. Perhaps my code should be called from DriverPipeline.staticLink, but it has no access to module graph, and I didn't want to make such a big change - I wanted to add .exe suffix on Windows, but if I think that GHC relies on mingw32 tools to add it when necessary. - There is some documentatin in separate_compilation.xml. I wrote about the ability to put Main in file other than Main.hs, but I couldn't find documentation for this feature. Tell me if there are other places where this feature should be mentioned. - I didn't check that docs are properly generated after my changes. Besides, the language can be incorrect. Best regards Tomasz

1 1

RE: GHC-6.4.1 on FreeBSD-amd64 port progress
by Simon Marlow 24 Oct '05

24 Oct '05

On 18 October 2005 20:26, Wilhelm B. Kloke wrote: > Simon Marlow <simonmar(a)microsoft.com> schrieb: >> >> At this point you can either do 'make install stage=1', or you can >> just use the compiler you built to build a clean GHC in another >> tree, i.e. with ./configure >> --with-ghc=/path/to/bootstrap/ghc/compiler/ghc-inplace. > > Now I am getting the following really strange error message: > > ==fptools== gmake all -wr; > in /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/compiler > ------------------------------------------------------------------------ > /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/compiler/ghc-inplace > -H16m -O -istage1/utils -istage1/basicTypes -istage1/types > -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck > -istage1/deSugar -istage1/coreSyn -istage1/specialise > -istage1/simplCore -istage1/stranal -istage1/stgSyn > -istage1/simplStg -istage1/codeGen -istage1/main > -istage1/profiling -istage1/parser -istage1/cprAnalysis > -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm > -istage1/nativeGen -istage1/ghci -Istage1 -DGHCI -package > template-haskell -package readline -DUSE_READLINE -cpp -fglasgow-exts > -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser > -package unix -ignore-package lang -recomp -Rghc-timing -H16M > '-#include "hschooks.h"' -i../lib/compat -ignore-package Cabal -H80m > -c prelude/PrimOp.lhs -o stage1/prelude/PrimOp.o -ohi > stage1/prelude/PrimOp.hi > > prelude/PrimOp.lhs:104:0: parse error (possibly incorrect indentation) > <<ghc: 30809992 bytes, 2 GCs, 129776/129776 avg/max bytes residency > (1 samples), 60M in use, 0.00 INIT (0.00 elapsed), 0.08 MUT (0.10 > elapsed), 0.01 GC (0.02 elapsed) :ghc>> > gmake[2]: *** [stage1/prelude/PrimOp.o] Fehler 1 > gmake[1]: *** [install] Fehler 1 > gmake[1]: Leaving directory > `/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc' > gmake: *** [install] Fehler 1 > > I checked that PrimOp.lhs is identical with the versions in > -i386amd64 and -amd64, so the error message text is certainly > misleading. PrimOp.lhs includes a bunch of files that are auto-generated from primops.txt. In ghc/compiler you should have a bunch of files called primop-*-incl, which are generated by the genprimopcode program in ghc/utils/genprimopcode. If these files are empty or corrupt, just remove them and re-build. Are you building GHC in a fresh tree now? I'd recommend doing that. Cheers, Simon

2 2

RE: Segfaulting programs with GHC 6.4.1
by Simon Marlow 24 Oct '05

24 Oct '05

On 22 October 2005 03:25, John Goerzen wrote: > Here's some more data. > > I tried this program with three versions of GHC. > > GHC 6.4 with forkIO: could not produce a segfault at all > GHC 6.4 with forkOS: rapid segfault (<30 sec) > > GHC 6.4.1 with forkIO: segfault in <5 min > GHC 6.4.1 with forkOS: segfault in <1 min > > GHC 6.5: same results as GHC 6.4.1 > > Now, I also obtained a backtrace from GHC 6.4 with forkOS. Here's a > bit of it: > > #0 0x080c2e3e in ForeignziCziString_zdwpeekCAString_info () > #1 0xb7a9e868 in ?? () > #2 0x00000020 in ?? () > #3 0xb7ecb08c in _res () from /lib/tls/libc.so.6 > #4 0xb7ad80ec in ?? () > #5 0x00000004 in ?? () > #6 0x016b0d36 in ?? () > #7 0xb7ac3f9c in ?? () > #8 0x93c0cef9 in ?? () > #9 0x4359a1e1 in ?? () > #10 0x000742d3 in ?? () > #11 0x00000000 in ?? () > .... > #2021 0x00000000 in ?? () > #2022 0xb7ed80a6 in __pthread_mutex_cond_lock () from > /lib/tls/libpthread.so.0 #2023 0x080c2f4c in > ForeignziCziString_zdwpeekCAString_info () > > now this is the first time something from pthread actually appeared, > which is interesting. > > The code surrounding that CAString_info is: > > 0x080c2f44 <ForeignziCziString_zdwpeekCAString_info+356>: and > %eax,(%eax) 0x080c2f46 <ForeignziCziString_zdwpeekCAString_info+358>: > add %al,(%eax) 0x080c2f48 > <ForeignziCziString_zdwpeekCAString_info+360>: and $0x0,%al > 0x080c2f4a <ForeignziCziString_zdwpeekCAString_info+362>: add > %al,(%eax) 0x080c2f4c <ForeignziCziString_zdwpeekCAString_info+364>: > movl $0x80c2f10,0x0(%ebp) 0x080c2f53 > <ForeignziCziString_zdwpeekCAString_info+371>: jmp *(%esi) > 0x080c2f55 <ForeignziCziString_zdwpeekCAString_info+373>: nop > 0x080c2f56 <ForeignziCziString_zdwpeekCAString_info+374>: nop Hi John, Thanks for trying to narrow this down. At this stage it looks like some kind of heap corruption. Can you reproduce it on more than one machine? (we have to rule out hardware failure, it's happened before and can cost a lot of debugging time). BTW, the stack trace isn't useful beyond the top element, the reason being that GHC's virtual machine doesn't use the C stack. gdb can usually tell you which bit of code the crash happened in, but if it was in Haskell code then you don't have any information from the C stack. I'll need to reproduce it here. Can you give me a set of instructions to get me up to the right point? Cheers, Simon

2 1

GHC and Windows (DLL/FFI) woes
by Esa Ilari Vuokko 23 Oct '05

23 Oct '05

Hi! I have been trying to build some Windows DLLs with GHC, and I have run into some misfeatures or maybe I have misunderstood how to use GHC. Any help or advice would be appreciated. :) First of all, I can't get ghc to generate stubs from foreign export in anywhere else than next to original source, which is sort of annoying. I would like all the generated files to go quite a bit diffrent place than source directory. Next, --make and --mk-dll don't seem to work together. Ok, what I do, is I just --make -no-link and then --mk-dll all the object files I find :) It seems that -i flag and compiling those _stub.c have following problem: if path given in -i flag contains any /- or \-characters, i.e. any real subpaths, it seems to stop with something like: \source\sunrise\haskell\haskell\..\debug\build\haskell\plugin-hs-test/d:: createDirectory: invalid argument (Invalid argument) It seems a bit random what is the supposed "filename" part of the path, typically it contains drive letter and few colons, it doesn't seem totally random data. Thanks, --Esa Ilari Vuokko

1 0

RE: Segfaulting programs with GHC 6.4.1
by Simon Marlow 22 Oct '05

22 Oct '05

On 21 October 2005 13:27, John Goerzen wrote: > It wasn't from my build tree, but: > > jgoerzen@katherina:/usr/lib/ghc-6.4.1$ grep -ri s34n_info * > Binary file libHSbase.a matches > Binary file libHSdata.a matches > > I unpacked libHSbase.a and found: > > $ grep -ri s34n_info . > Binary file ./String__1.o matches > Binary file ./Posix__6.o matches (this one doesn't match if I omit > -i) > > Identical results from libHSdata.a. > > I thought I would also look at s3eu_info. It too is in libHSbase.a: > > $ grep -r s3eu_info . > Binary file ./Internals__19.o matches > Binary file ./String__1.o matches > > objdump -x String__1.o yields, among other things: > ... > SYMBOL TABLE: > 00000000 l d .text 00000000 .text > 00000068 l O .text 0000000c s34n_info > 00000190 l O .text 00000008 s3et_info > 000000c4 l O .text 00000008 s351_info > 00000160 l O .text 00000008 s3eu_info > 00000000 l d .data 00000000 .data > 00000000 l d .bss 00000000 .bss > 00000000 g O .data 00000004 > ForeignziCziString_zdwpeekCAString_closure > 0000000c g O .text 0000000c > ForeignziCziString_zdwpeekCAString_info 00000000 *UND* > 00000000 GHCziBase_Izh_con_info 00000000 *UND* 00000000 > GHCziBase_Czh_con_info 00000000 *UND* 00000000 > GHCziBase_ZC_con_info 00000000 *UND* 00000000 stg_gc_ut > 00000000 *UND* 00000000 GHCziBase_ZMZN_closure > > Now, I may be totally reading this wrong, but seeing several > references > to Foreign and String made me think of CStrings. That made me > suspicious of this function. You may remember I asked about it on > IRC, > and we thought it was OK: > > msg :: String -> IO () > msg l = > do t <- myThreadId > let disp = (show t) ++ ": " ++ l ++ "\n" > withCStringLen disp (\(c, len) -> hPutBuf stdout c len >> > hFlush stdout) > > This may be a complete red herring, but I just thought I'd bring it > up. > Maybe it's a clue anyway. > > Here's the disassemble output: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1407190096 (LWP 31315)] > 0x080ba84a in s34n_info () > (gdb) disassemble s34n_info > Dump of assembler code for function s34n_info: > 0x080ba834 <s34n_info+0>: mov %edi,0x8(%esp) > 0x080ba838 <s34n_info+4>: mov %edi,%eax > 0x080ba83a <s34n_info+6>: add $0x8,%eax > 0x080ba83d <s34n_info+9>: mov %eax,%edi > 0x080ba83f <s34n_info+11>: cmp 0x5c(%ebx),%eax > 0x080ba842 <s34n_info+14>: ja 0x80ba86b <s34n_info+55> > 0x080ba844 <s34n_info+16>: mov 0x0(%ebp),%edx > 0x080ba847 <s34n_info+19>: mov 0x4(%esi),%eax > 0x080ba84a <s34n_info+22>: cmpb $0x0,(%eax,%edx,1) the crash is here ^^^ it does appear to be something string-related, because that instruction isn't a common one in GHC-generated code - comparing a byte against zero, with a non-trivial addressing mode, looks very much like a string traversal. Do you have any other CString-related code in your program? Cheers, Simon

3 6

RE: Segfaulting programs with GHC 6.4.1
by Simon Marlow 21 Oct '05

21 Oct '05

On 21 October 2005 10:20, John Goerzen wrote: > On Fri, Oct 21, 2005 at 09:52:50AM +0100, Simon Marlow wrote: >> At this stage we need to resort to gdb. Run the version of the >> program compiled with -debug under gdb, and take a look at the >> backtrace when it crashes. Hopefully it'll be somewhere in the RTS, >> if it's somewhere in Haskell code you won't get an informative >> backtrace. > > OK, here's what I've got. There's a little bit here -- no idea if > this provides any clues. In fact, it looks pretty much the same as > when I ran gdb against the core file that it created when it crashed > -- but with the addition of the last few lines. Here are the useful > bits: > > ThreadId 9: quix.us:70:9:/Software/mulinux/Newer > Upload/mulinux-14r0.iso > ThreadId 8: > serpiente.dgsca.unam.mx:70:0:0/noticia_mex_mundo/nacional/febrero94/07/d epo/07febdepo14.txt > [New Thread -1416234064 (LWP 26413)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1214252112 (LWP 26365)] > 0x080ba84a in s34n_info () > (gdb) bt > #0 0x080ba84a in s34n_info () > #1 0xb7ac8374 in ?? () > #2 0xb7a01910 in ?? () > #3 0xb7ac8764 in ?? () > #4 0xb7a05bac in ?? () > #5 0x00028738 in ?? () > #6 0x08172728 in MainCapability () > #7 0x00000002 in ?? () > #8 0x00000001 in ?? () > #9 0xb7ac266c in ?? () > #10 0x00000001 in ?? () > #11 0xb7ac8738 in ?? () > #12 0x00000000 in ?? () > #13 0x00000000 in ?? () > ... [ thousands of lines of this deleted ] ... > #1872 0x00000000 in ?? () > #1873 0x00000000 in ?? () > #1874 0x08174058 in ?? () > #1875 0x08174058 in ?? () > #1876 0xb7a774b4 in ?? () > #1877 0xb79ff138 in ?? () > #1878 0x08134aa5 in allocBlock () > #1879 0x080ba95c in s3eu_info () A couple more things to try: disassemble s34n_info to see where exactly it crashed, and if there are any calls in there you recognise, and 'grep s34n_info *.o' over your object files to see which object that symbol comes from. Cheers, Simon

2 1

RE: Segfaulting programs with GHC 6.4.1
by Simon Marlow 21 Oct '05

21 Oct '05

On 21 October 2005 09:24, John Goerzen wrote: > On 2005-10-20, John Goerzen <jgoerzen(a)complete.org> wrote: >> I am running GHC 6.4.1 on Linux x86. I have a program that is >> multithreaded, and since the upgrade from GHC 6.4, the program is >> segfaulting. > > Some additional data: > > * Removing -O2 from the compile flags didn't help. (If anything, > it made things worse.) > > * You can see the source for this program with: > > darcs get --partial --tag=bug20051020 > http://darcs.complete.org/gopherbot > > Yes, it is what it sounds like ;-) At this stage we need to resort to gdb. Run the version of the program compiled with -debug under gdb, and take a look at the backtrace when it crashes. Hopefully it'll be somewhere in the RTS, if it's somewhere in Haskell code you won't get an informative backtrace. If it's possible for us to reproduce the bug here, I'll happily take a look. Cheers, Simon

2 1

RE: dumping stack with -xc
by Simon Marlow 21 Oct '05

21 Oct '05

On 21 October 2005 08:45, John Meacham wrote: > How do I force a stack dump with -xc? > > my program is locking up in an infinite loop, but it keeps going and > won't die itself, I was hoping it would dump stack on ctrl-c but it > does not seem to. is there any way to force it to happen? installing a > signal handler that fails does not work as it always reports > Main.main. John Tricky; you might try setting the stack size small enough to trigger a stack overflow (+RTS -K). Apart from this, there's no way to get a stack trace as far as I'm aware. We should probably make async exceptions generate a stack trace with -xc too, so you could use a ^C handler that throws an async exception in the main thread. If you compile with profiling then ^C should give you a time profile, which should give you a clue where the infinite loop is. Cheers, Simon

1 0

Segfaulting programs with GHC 6.4.1
by John Goerzen 21 Oct '05

21 Oct '05

Hello, I am running GHC 6.4.1 on Linux x86. I have a program that is multithreaded, and since the upgrade from GHC 6.4, the program is segfaulting. Initially, the program was written using forkIO. It segfaulted, but not very often. I was able to capture a strace that showed it doing a select right before the crash, but it didn't crash reliably enough for me to get anything else. With forkOS, it is crashing much more reliably and I was able to get some output from +RTS -debug -DbsS. I'm including the last few lines below, and can attach more if you need it. I have no C extensions or unsafe IO going on here. I am using HSQL to connect to PostgreSQL. Previously, I used HSQL to connect to Sqlite3, and the change didn't make any difference, so I suspect the DB can be ruled out. Other than that, the program is network-intensive and DB-intensive and uses about 20 threads to download data from various hosts and note what it did in the DB. Any insight, and suggestions for next steps, would be greatly appreciated. Thanks, -- John thread 571 @ 0xb7a1e000 is blocked on an external call thread 590 @ 0xb7a36828 is blocked on an MVar thread 591 @ 0xb7a36420 is blocked on an external call thread 641 @ 0xb7a494a8 has completed thread 642 @ 0xb7a490a0 has completed sched (task 0xaa1bebb0): worker: giving up capability (no threads to run) sched (task 0xaa1bebb0): worker: released capability sched (task 0xaa1bebb0): worker: wait for capability (cond: (nil)) sched (task 0xab1ffbb0): worker: returning; workers waiting: 0 sched (task 0xab1ffbb0): worker: got capability sched (task 0xab1ffbb0): worker (token 2): re-entering RTS sched (task 0xab1ffbb0): thread 2 did a _ccall_gc sched (task 0xab1ffbb0): worker: released capability sched (task 0xab1ffbb0): worker (token 2): leaving RTS sched (task 0xb71ffbb0): worker: returning; workers waiting: 0 sched (task 0xb71ffbb0): worker: got capability sched (task 0xb71ffbb0): worker (token 571): re-entering RTS sched (task 0xab9ffbb0): worker: returning; workers waiting: 0 sched (task 0xab1ffbb0): worker: returning; workers waiting: 1 Segmentation fault (core dumped)

1 1

dumping stack with -xc
by John Meacham 21 Oct '05

21 Oct '05

How do I force a stack dump with -xc? my program is locking up in an infinite loop, but it keeps going and won't die itself, I was hoping it would dump stack on ctrl-c but it does not seem to. is there any way to force it to happen? installing a signal handler that fails does not work as it always reports Main.main. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0