- Glasgow-haskell-users

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

[ ghc-Feature Requests-1333482 ] Supertyping of classes
by SourceForge.net 20 Oct '05

20 Oct '05

Feature Requests item #1333482, was opened at 2005-10-20 11:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1333482&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Supertyping of classes Initial Comment: see "Supertyping Suggestion for Haskell" [url]http://repetae.net/john/recent/out/supertyping.html[/url] example: [code] class Num a <= Group a where (+) :: a -> a -> a negate :: a -> a [/code] apart from multiple inheritance, it could work like this: [code] import Prelude hiding ((+),negate) import qualified Prelude ((+),negate) class Group a where (+) :: a -> a -> a negate :: a -> a instance Num a => Group a where (+) = (Prelude.+) negate = Prelude.negate [/code] - coeus_at_gmx_de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1333482&group_…

1 0

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

20 Oct '05

On 20 October 2005 10:35, Simon Marlow wrote: > On 19 October 2005 20:41, Wilhelm B. Kloke wrote: > >> Simon Marlow <simonmar(a)microsoft.com> schrieb: >>> >>> Are you building GHC in a fresh tree now? I'd recommend doing that. >> >> Now I am using a *really* fresh tree. Formerly the compilation of >> Apply.cmm did not render an instructive error message, just >> failed for some sort of memory access exception. Now I have: >> >> ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W >> -optc-Wstrict-prototypes -optc-Wmissing-prototypes >> -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return >> -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel >> -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static >> -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h >> -#include RtsUtils.h -#include StgRun.h -#include Schedule.h >> -#include Printer.h -#include Sanity.h -#include STM.h -#include >> Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h >> -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h >> -#include Apply.h -fvia-C -dcmm-lint -c parallel/RBH.c -o >> parallel/RBH.o ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static >> -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h >> -#include RtsUtils.h -#include StgRun.h -#include Schedule.h >> -#include Printer.h -#include Sanity.h -#include STM.h -#include >> Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h >> -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h >> -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o >> ghc-asm: don't know how to mangle assembly language for: >> x86_64-unknown-freebsd > > Uhuh. This means that GHC is attempting to build a registerised > version (which is what happens by default). If you don't plan to > work on registerised support right now, you could set > 'GhcUnregisterised=YES' in mk/build.mk. Incedentally, registerised support should be quite easy, since I've already done it for x86_64-unknown-linux, where the ABI and toolchain are the same AFAIK, so it might just be a case of enabling x86_64-unknown-freebsd in the right places (ghc-asm.lprl for one, I can't remember if there's anywhere else off hand). Cheers, Simon

1 0

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

20 Oct '05

On 19 October 2005 20:41, Wilhelm B. Kloke wrote: > Simon Marlow <simonmar(a)microsoft.com> schrieb: >> >> Are you building GHC in a fresh tree now? I'd recommend doing that. > > Now I am using a *really* fresh tree. Formerly the compilation of > Apply.cmm did not render an instructive error message, just > failed for some sort of memory access exception. Now I have: > > ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W > -optc-Wstrict-prototypes -optc-Wmissing-prototypes > -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return > -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel > -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static > -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h > -#include RtsUtils.h -#include StgRun.h -#include Schedule.h > -#include Printer.h -#include Sanity.h -#include STM.h -#include > Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h > -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h > -#include Apply.h -fvia-C -dcmm-lint -c parallel/RBH.c -o > parallel/RBH.o ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static > -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h > -#include RtsUtils.h -#include StgRun.h -#include Schedule.h > -#include Printer.h -#include Sanity.h -#include STM.h -#include > Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h > -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h > -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o > ghc-asm: don't know how to mangle assembly language for: > x86_64-unknown-freebsd Uhuh. This means that GHC is attempting to build a registerised version (which is what happens by default). If you don't plan to work on registerised support right now, you could set 'GhcUnregisterised=YES' in mk/build.mk. Cheers, Simon

1 0

Re[2]: cc1plus.exe not included in Win32 distro
by Bulat Ziganshin 20 Oct '05

20 Oct '05

Hello Sigbjorn, Tuesday, October 18, 2005, 3:58:03 AM, you wrote: >> the official Win32 distro does not contain cc1plus.exe, needed to compile CPP files SF> Should GHC binary dists include a C++ compiler? I'd say SF> no, but if there are practical and compelling reasons to do SF> so, it's no big deal to re-include the binary. well, i scanned a number of libs and apps and found that they all include only C sources (not counting wxHaskell, which anyway is distributed in precompiled form). so i'm a bit out of luck: my program contains huge C++ libs. so i need to include in my program and library instructions to install C++ compiler. but this depends on the version of GHC installed. may be you can include such instructions in your distro? something like it: "In order to compile C++ files, you nedd to download ... and then install/unapck it to the $GHC/gcc-lib directory" btw, i just copied cc1plus.exe to this directory from migw32 3.4.2 installation. is that enough? and thank you - installer size was really greatly reduced in this version -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

RE: Help wanted! Win32 and HGL for GHC on Windows
by Simon Peyton-Jones 20 Oct '05

20 Oct '05

| | * The libraries/HGL package works fine on Unix, where it sits on top | | of the libraries/X11 package. But it does not work properly on | | Windows, where it sits on top of libraries/Win32. It is not clear | | whether the problem is with the HGL package or the Win32 package. | | As usual I am unable to find the time to look more carefully at this so | please pass this report on to whomever is dealing with HGL. | | I haven't heard what problems others have found but here is what I just | experienced. | | ...snip... Mike: thanks for giving detailed info about what works and what doesn't with HGL and Win32. So far I have had no volunteers, so I'm afraid HGL may stay broken. If anyone is interested in helping, let me know and I'll fwd Mike's info on to you. Simon

1 0

New 6.4.1 windows installer
by Sigbjorn Finne 20 Oct '05

20 Oct '05

A test installer for a patched version of ghc-6.4.1 for Windows is now available, http://haskell.org/ghc/dist/6.4.1/ghc-6-4-1-bld1.msi Unless I'll hear of any packaging snafus, it'll be hooked up to the GHC web pages tomorrow. Notice that by default this installer will deposit bits in the same directory as the original 6.4.1 installer, so if you treasure the original bits.... The installer includes all 6.4.1 fixes committed as of 2005-10-20T01:00:00+0000. In particular, usage of Cabal from a GHCi-like setting should now work OK. --sigbjorn

1 0

RE: Cross-Compiling with GHC?
by Simon Marlow 19 Oct '05

19 Oct '05

On 18 October 2005 20:17, Rich Fought wrote: > GHC noob here, trying to compile a small app for a Linux/PPC target > from a Linux/x86 host. > > I take it this must be doable, since it is possible to build GHC for > new platforms and GHC itself is written in Haskell. > I'm just trying to find out if anyone has formulated a guide to this > already, before I jump in (and I did try Google > without much luck). I'm afraid building GHC for the target is not an > option. > > My first thought to try is to build an unregisterised GHC on x86 from > scratch and use it to compile my app to C code, > which I can then cross-compile to PPC. Something tells me however > that this C code still may have some x86 specific > stuff in it. This is possible, but far from easy. The kind of cross-compilation we do to port GHC to a new platform isn't full cross compilation - we compile Haskell to C on the host, and then C to object code on the target system. You can do the same to compile your app, but remember that you need all the libraries and the RTS compiled for the target too. Basically GHC is a special case of an app that we cross-compile in this way. If you want to try this, you'd need to proceed something like this: - follow the porting instructions, build the libraries and RTS on the target, but stop before building GHC - put your app in the GHC build tree. Generate unregisterised .hc files on the host, take them to the target and build there. I've ommitted a *lot* of details. This plan works in theory. Alternatively, you could try to make GHC do proper cross-compiling, using a cross-toolchain on the host system. This would have more lasting value, at least. Definitely a fair bit of work though. Cheers, Simon

1 0