I'm using 4.08.1 on linux.
I think that `waitQSemN' provided with the concurrent library
is broken,
...
Below is my fix:
[ fix deleted ]
Thanks, I've applied your patch and it'll be in 4.08.2.
Cheers,
Simon
___
Glasgow-haskell-bugs
I think it was fixed in 4.08.1. In any case 4.08 has a nasty bug
in the NCG register allocator; you should move to 4.08.1 if you
haven't already.
It was fixed post 4.08.1, and will be in 4.08.2.
From 'cvs log RnSource.lhs':
ghc-4-08-1: 1.76.2.4
...
I'm trying to use the catch function in the Exception library
in hslibs.
But I can't even get my programs to compile. It feels like this is a
silly mistake on my side but I'll ask anyway. I've boiled it
down to the
following program:
We changed the Exception interface around a bit
The package in pkgsrc for 4.04 on NetBSD 1.5 doesn't properly
compile. I've also tried just compiling 4.08.1 from source,
using the hc files. They both fail at the same spot with
similar errors, which are listed below.
NetBSD 1.5 has switched to an ELF file format. I don't know
if this
Given
getrusage(RUSAGE_SELF, t);
cpu[0] = t.ru_utime.tv_sec;
cpu[1] = 1000 * t.ru_utime.tv_usec;
cpu[2] = t.ru_stime.tv_sec;
cpu[3] = 1000 * t.ru_stime.tv_usec;
in `getCPUTime.c', I don't understand
return ((fromIntegral (I# (indexIntArray# frozen#
Given
getrusage(RUSAGE_SELF, t);
cpu[0] = t.ru_utime.tv_sec;
cpu[1] = 1000 * t.ru_utime.tv_usec;
cpu[2] = t.ru_stime.tv_sec;
cpu[3] = 1000 * t.ru_stime.tv_usec;
in `getCPUTime.c', I don't understand
return ((fromIntegral (I# (indexIntArray#
"foreign label ..." delivers a pointer to the named C object.
- I think,
the question is: What happens when this object is a pointer itself?
When defining hello.c hello.h as follows, the example works fine:
hello.c:
#include "hello.h"
const char hello[] ="hello, world";
hello.h:
With ghc-4.08.1, running on Linux with -0 -O2-for-C, I get:
loop
With ghc-4.08, running on Solaris, with -O -O2-for-C, I get:
hsc: no threads to run: infinite loop or deadlock?
With ghc-4.08, running on Solaris, with -Onot, the compilation works.
For the sources you will need the
Hi Christian,
* Define the DllMain function in C (dllMain.c):
#include windows.h
#include Rts.h
static char* args[] = { "ghcDll" };
BOOL
STDCALL
DllMain
( HANDLE hModule
, DWORD reason
, void* reserved
)
{
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS
isn't right in 4.08 (or the CVS repo.) If the assumption is
that ForeignObj
cannot be mutated once created (which looks like being the
case now since
writeForeignObj is marked as deprecated), the defn should be
something like:
makeForeignObj :: Addr - Addr - IO ForeignObj
The dependency "concurrent" should be added to line 11 of
/hslibs/net/Makefile so that it becomes:
HSLIB_DEPS = lang text concurrent
After that fix, 'make boot' goes through.
Thanks, I've applied your fix.
Cheers,
Simon
___
I think I've narrowed the problem down a bit further. It
looks as if the reason GHC is
hanging after the end of the main action is that there's a
handle still open to a socket
(to another process). If I hClose the handle explicitly
before the end of the main action,
the hClose action
SimonM, can you merge 1.5 into the 4-08-branch, please?
done.
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
I think I found the most simple version to reproduce this bug.
module Main where
import Posix
import IO
main = do
_ - installHandler sigUSR1 (Catch (return ())) Nothing
-- will fail
-- _ - installHandler sigUSR1 Ignore Nothing -- will work
loop
loop = do
putStr " "
On Mon, Oct 09, 2000 at 01:42:45PM +0200, Volker Stolz wrote:
It seems that in 4.08 4.08.1 signal handling still seems
to be flawed:
I forgot to mention that this only happens when using job-control:
1) start the program
2) use Ctrl-Z to suspend
3) kill -USR1
4) fg to resume,
John's stToIO could be implemented in terms of runST, like so:
stToIO :: (forall s . ST s a) - IO a
stToIO st = return (runST st)
maybe you want strictness here (i.e. applying seq to the result of runST
before returning), maybe not. I'm sure there are arguments both ways.
first time poster, long time listener :-) Possibly a known
one, but the
NCG in 4.08.1 doesn't emit suitably decorated names when calling
out to 'foreign import'ed functions that use the stdcall
calling convention,
e.g.,
sof$ cat foo.hs
module Foo { foreign import stdcall decorateMe
I noticed that GHC mentions a powerpc AIX port. I was
wondering what the
difficulty would be in porting GHC to Linux-PPC.
Probably not too hard. The PPC code is still there, but hasn't been tested
for a while (AFAIK, ghc 4.xx has never compiled on a PPC). You may need to
extract some bits
Dear glasgow-haskell-users glasgow-haskell-bugs,
At haskell.org we're going to be switching the mailing lists from majordomo
(which is somewhat old and clunky) to Mailman, which will amongst other
things make my life a lot easier, provide better archives, add digest
support and allow
As suggested by the README, I did
./configure --exec-prefix=/home/sml/bin/ia32-linux --enable-hc-boot
make boot
make
and then I get the following error:
--
--
===fptools== Finished making `all' in
Thanks for a great bug report. There was indeed a bug (at least one), which
I've just fixed in the CVS sources. The read buffer was being accidentally
flushed as a write buffer by the hClose. I'm still not quite sure why this
caused the file to grow, however.
Workaround: don't use
Just for completeness - I saw a few mails about missing files in the
binary dist. causing problems when installing on sparc. I have had the
same problem and as one of the files I had problems with was
not mentioned
I thought I'd summarize:
Some perl scripts are not created as they
The following program:
module Main(main) where
main:: IO()
main = do {
xs - mapM readFile (take 1000 (repeat "tmp"));
return ();
}
Results in the error:
Fail: resource exhausted
Action: openFile
Reason: process file table full tmp
That looks reasonable - there's
Arguably, readFile is too strict: why is the file opened, if there
aren't any characters needed. What is the motivation for opening the
file eagerly?
Once we've started reading lazilly, it's hard to generate errors. The file
is opened eagerly so that any errors generated (such as if the
Got a failed install on the binary release of ghc-4.08.1
using the sparc-sun-solaris2 package.
Cya,
Niall
bash-2.03$ make install
Configuring ghc, version 4.08.1, on sparc-sun-solaris2 ...
Creating a configured version of ghc-4.08.1 ..
cat: cannot open
ghc-4.08 (the current version in
http://www.haskell.org/ghc/dist/4.08/ghc-4.08-i386-unknown-lin
ux.tar.gz)
compiles the following program without error:
module Main(main) where
main = main
data Foo = baz
According to the Haskell 98 report, this is not legal Haskell. Are
there are
If I give both the option -imydir _and_ -Xmydir to
`mkdependHS' - even if the -X appears after the -i option on
the command line - `mkdependHS' silently ignores the -X
option.
[This is with a vanilla GHC 4.06.]
I would rather expect that the -X overrides the -i (and it
would
Mon, 24 Jul 2000 22:16:32 +1000, Manuel M. T. Chakravarty
[EMAIL PROTECTED] pisze:
[...]
we get an executable that dumps core (as the Pretty module in
`-package text' also defines a data type `Doc').
With correct dependencies in Makefile Pretty should be compiled
before Main. Then
Hi there,
I tried to build ghc-4.08 from the sorce distribution for FreeBSD.
There's a FreeBSD port of 4.08 on the way. I'm currently trying to track
down a couple of problems that people have reported.
Which source distribution are you using here? The standard
ghc-4.08-src.tar.gz or the
Nice bug!
I think I've fixed this now. The fix will be backported to 4.08.1 after
some testing.
Cheers,
Simon
| The ``foreign import'' bug for Float types is still present
| in ghc-4.08.
This bug is definitely present in the native code route.
It would be good to know if the bug exists on the via-C route.
If you recompile with -fvia-C (perhaps check with -v to be sure
it really does go
Going via C is fine, as long as you -#include the relevant
prototype for the
C function you're calling. Otherwise the C compiler
automatically promotes
the arguments/result to doubles and you're hosed.
There's been a great deal of discussion on the FFI list (as
I'm sure you've
Sorry to be so dense, but my question was about the syntax of the
-#include flag - where does it go (commandline? in the source? in a
pragma?), and how is the filename specified?
-#include="filename"
-#include "filename"
-#include filename
etc. The on-line GHC documentation
FWIW:
I downloaded the src tarball, but had problems in building the
4.08 compiler.
1) ghc/compiler/main/CodeOutput.lhs did not import hPutStrLn or
stderr from IO and failed to compile.
2) Building with 4.06 compiler, the build crashes in ghc/lib/std
while trying to make the
Yesterday I downloaded ghc-4.08 (thanks again to Simon).
When I ran ghc-4.08 today I got a
$ ghc geom.hs
Segmentation Fault - core dumped
I think it is caused by the following contrived
list-comprehension.
c' = [ e | e - c, ((elem e ls) ]
Note that the level of parentheses is
I took a look (or maybe some more) at the well-known, totally buggy
Time module...
I think, I sorted out the main problems and fixed them:
Comitted, thanks!
Simon
ghc-pre-4.07-2613-i386-unknown-linux.tar.gz
inherits this bug from ghc-4.06:
main =
let xs =
[((1,[0,0,0,0,2,0,0,0,0,2]),(-5,[0,0,0,0,1,0,3,3,0,1])),
((1,[0,1,0,0,0,1,0,0,0,1]),(-5,[0,1,0,0,0,1,0,0,0,1])),
Fail: Prelude.chr: bad argument
nofib/real/compress2 fails with the same message, for us.
We haven't investigated. Perhaps it's the same bug.
With a quick grep through the two programs, my guess is that 'toEnum'
is being specialised at type Char to an internal function 'chr', and
grepping through sources suggests that nobody tried to implement this,
only the exception constructor exists... OTOH stack overflow works.
import Exception
main:: IO ()
main = print (length (l++l)) `catchAllIO` print
where l = [0::Int ..]
Yes, I know: heap overflow is somewhat
Simon Marlow [EMAIL PROTECTED] writes:
So, the question is, "Should readFile on a directory throw an IO
error?" If so, then there is a bug in Hugs; if not,
there is a bug
(or at least a severe misfeature) in Green Card (and a
bug in the ghc
libraries, which do t
So, the question is, "Should readFile on a directory throw an IO
error?" If so, then there is a bug in Hugs; if not, there is a bug
(or at least a severe misfeature) in Green Card (and a bug in the ghc
libraries, which do throw an IO error).
I rather think that openning a directory fail,
May I know what happened?
Regards,
xu na
PS:
panic! (the `impossible' happened):
Lex.popContext: empty context
Please report it as a compiler bug to
[EMAIL PROTECTED]
You probably have a parse error in your file. This error message has
improved somewhat in recent
When compiling ghc-4.06 I get this error message:
../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall
-optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline
-optc-Waggregate-return -optc-Wpointer-arith
Hmm. I would guess that your gcc is using the native HP/UX
assembler and not GNU as, so it doesn't understand the .file
directive. If you sent us the output of
make EXTRA_HC_OPTS=-optc-v
we could check that hypothesis. However ...
Here it is, hope it helps:
sorry, I
I pulled down the 4.07 branch this morning and tried to build
it with 4.06.
Unfortunately, I get this:
../../driver/ghc-inplace -recomp -cpp -fglasgow-exts -fvia-C
-Rghc-timing -O
-package-name std -static -split-objs-c PrelIOBase.lhs -o
PrelIOBase.o
-osuf o
Warning:
Tue, 23 May 2000 07:03:56 -0700, Simon Marlow
[EMAIL PROTECTED] pisze:
I believe I've fixed this one now.
Erm, but there must be another bug. Its effect is
fatal error: evacuate: THUNK_SELECTOR: strange selectee 27
The best way to reproduce it that I could found is the following
Hi,
my program uses (data-) variables beginning with _. This is
legal Haskell
98 and Hugs accepts it. GHC 4.06 thinks these are constructors.
This was indeed a bug in 4.06, but we've fixed it since and the fix will be
in the upcoming 4.07. Incedentally, the bug was that identifiers
I have a simple Haskell source file that uses unboxed tuples
and causes
GHC-4.07 (from the CVS repository last week) to crash, with or without
optimization.
The source (Bug.hs) is:
module Bug (scaleInt) where
import PrelGHC
scaleInt :: (# Int, Int #) - Int - Int
scaleInt ival i
Yes, although it's quite big as a bug report.
http://qrczak.ids.net.pl/Haber-0.1.tar.gz
It's Linux.
$ make
$ COLUMNS=70 LINES=25 ./haber bug.html
I could not find a repeatable example which fails on an 80x25 screen
now (this one fails on 128x48 too). It fails with "EVACUATED
Yes, although it's quite big as a bug report.
http://qrczak.ids.net.pl/Haber-0.1.tar.gz
It's Linux.
$ make
$ COLUMNS=70 LINES=25 ./haber bug.html
I could not find a repeatable example which fails on an 80x25 screen
now (this one fails on 128x48 too). It fails with "EVACUATED object
"Signal 127"?! I don't understand this.
Doesn't seem to happen here, but it may be a bug in your 'as'. GHC's native
code generator is now used by default when GHC is invoked without -O, so the
problem isn't your gcc, but more likely your binutils.
Cheers,
Simon
Grrr. This works:
module Main (main) where
import IO
import Posix
import PosixUtil
import Concurrent
main = do
h - openFile "/tmp/fifo" ReadMode
fd - handleToFd h
threadWaitRead (fdToInt fd)
line - hGetLine
Thu, 11 May 2000 06:39:10 -0700, Simon Marlow
[EMAIL PROTECTED] pisze:
The solution, if you're interested, is to open the file in blocking
mode and set O_NONBLOCK later on with an fcntl().
It means that waiting for the writer blocks the whole program, right?
Yes, and that's another
It is certainly better after a fix, at least for
single-threaded programs
which work perfectly.
With native threads (BTW, are they expected to work soon?) it
would work
well too.
Perhaps... but pthreads emulated in user-space would suffer from the same
problems as GHC, because they
However I think I am getting exactly the same problem. (On
Solaris/Sparc,
using CVS GHC compiled by itself.) However instead of using
pipes I am
using sockets.
Even worse, if the party of the second part closes the handle
attached to
the socket, and the Haskell process to which the
I encountered the problem too a few days ago. It does not wait for
another process to open the fifo, but returns EOF immediately.
It works only when another process opened the fifo for writing before
we opened it for reading.
The problem happens in ghc-4.06 and 4.07. It worked OK in
ghc-4.07 can´t read from Unix-FIFOs because a hGetLine will
throw an EOF.
module Main (main) where
import IO
main = do
h - openFile "/tmp/fifo" ReadMode
line - hGetLine h
putStrLn line
hClose h
dhs@monster [15:46:31] mkfifo /tmp/fifo; ./test
Fail: end of file
ghc-4.06 (downloaded from the ftp site; I haven't tried the current
CVS version) appears to have a bug in the FFI, demonstrated by the
following code using Floats.
[ snip ]
I believe this bug was fixed recently (foreign imports with non-IO return
types weren't being handled properly).
Mike Jones wrote:
I get this error with 4.05. If it is important, I can send source.
c:/tmp/ghc5016.hc:30113: warning: `X1Z_closure' was declared
`extern' and later `static'
This is one of GHC's classics. But it isn't a real error, only a
warning from the C compiler, which you can
I got the following problem executing my program:
mpirun -np 52 truth.exe +RTS -H128m -M128m -RTS ...
Heap exhausted;
Current maximum heap size is 67108864 bytes;
use `+RTS -Msize' to increase it.
Although I increased manually the Heap-size, this option seems to be
ignored. I compiled
hslibs/posix/doc/posix.sgml says that FileMode is an instance of Eq
and Integral, but in reality it is not. There is no way of examining
FileModes! I will have to reimplement an interface to stat() myself.
Yes, it's a bit sad. The POSIX library needs a complete re-implementation,
but I'd
../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall
-optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline
-optc-Waggregate-return -optc-Wpointer-arith
-optc-Wbad-function-cast -O2 -optc-DCOMPILING_RTS -static
-O2
I think
test9: fatal error: resurrectThreads: thread blocked in a
strange way
qualifies.
hehe ;) Better send me that program.
Simon
OK, this is why I think it's happening. Stg.h (#include'd via Rts.h)
sets the macro _POSIX_C_SOURCE. This prevents Sparc/Solaris'
sys/time.h
defining "struct timeval" and gettimeofday. (Indeed if I add the line
#undef _POSIX_C_SOURCE to RtsUtils.c just before include sys/time.h
it
Building 4.07 with 4.06 works fine, but in a second bootstrapping
phase the fresh 4.07 can't compile itself, at least not with
"SRC_HC_OPTS += -O". Without -O everything seems to work...
We know about this one. I'm about to commit a hack, and Simon will follow
up with the Real Fix in due
In the real application I also get the error:
bingraph: fatal error: evacuate: THUNK_SELECTOR: strange selectee 27
which I'm hoping is related, because I have no idea what it means and
I can't reproduce this in an example program. Any idea where I should
be looking for the cause of this ?
Consider
import Exception hiding ( catch )
main = tryAll (let x = x in x :: ()) = print
(Using current CVS; WinNT box).
My understanding was that GHC exceptions could catch blackholes.
But the above program causes:
bash% ../driver/ghc-inplace Blackhole.hs -syslib
==fptools== gmake boot --no-print-directory -r;
in /usr/local/pub-bkb/ghc/fptools/ghc/includes
--
--
gmake[2]: *** No rule to make target `Profiling.h', needed by
`mkNativeHdr.o'. Stop.
gmake[1]: *** [boot] Error 1
Simon Marlow wrote:
Yes, I removed Profiling.h from ghc/includes and added it
to ghc/rts. You
might need to 'make boot'
Actually it was gmake boot that was falling over. However I
seem to have
fixed that by doing "gmake depend" in ghc/includes (the
.depend file
With sources (and GHC) as checked out at 3am BST today:
/usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -cpp -fglasgow-exts
-O -H12m -c LALR.lhs -o LALR.o -osuf o
LALR.lhs:314: Variable not in scope: `newArray'
LALR.lhs:316: Variable not in scope: `freezeArray'
LALR.lhs:336: Variable
Er, has this bug report been lost? It doesn't seem to have
been dealt with . . .
There may be bootstrapping problems when building GHC with a snapshot
(post-4.06) build, because we only support the following scenarios:
- bootstrapping GHC with a released version
-
As I discovered, ghc doesn't implement the standard library
function "doesFileExist"
correctly.
I can't repeat this problem on Linux, so it may be a HP-specific bug. Can
anyone with an HP box verify it?
Cheers,
Simon
On FreeBSD using ghc 4.04, long running commands executed with
System.system are being interrupted by virtual alarms leading to
errors such as:
o Fail: interrupted
Action: system
Reason: system command interrupted rm -f xxx yyy
o Virtual timer expired
o gcc: Internal
The correct handling would be:
- block SIGALRM/SIGVTALRM/SIGPROF
- *then* fork() (else you have a race condition where the child could
receive *and handle* the signal)
This race condition is harmless, I think. The VTALRM handler just
increments a counter, and we're about to blow away this
`/usr/local/pub-bkb/ghc/fptools/ghc/rts/gmp/mpz'
../driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall
-optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline
-optc-Waggregate-return -optc-Wpointer-arith
-optc-Wbad-function-cast
I downloaded the sources from GHC 4.06, made the shallow tree, added a
build.mk in mk/ with -H80, later with -H80 -O2, made
./configure in ghc/
and ./configure in the main tree, (copied both .y files because happy
doesn't work on links done with lndir -- it's only NT), said
make boot and
Reuben Thomas wrote:
I already came across this, and Sigbjørn sent me a fix,
which should soon
be in CVS. Just in case it's not, it follows below. I found
that I also
needed to change rts/gmp/configure.in so that the first
call to AC_INIT
occurred after the setting of the three
Simon Marlow wrote:
What version of autoconf is this, just out of interest?
autoconf --version
Autoconf version 2.13
Oh no, don't tell me I've got to install a private copy of
yet another bit of
software to compile GHC . . .
It builds fine for me here with autoconf 2.13 on Solaris
Simon Marlow wrote:
It builds fine for me here with autoconf 2.13 on Solaris.
Perhaps you have
some old configure files lying around in ghc/rts/gmp/*.
Try blowing away
your gmp subtree and starting again.
After deleting the whole of ghc, rerunning autoconf several times
(why isn't
Compiling the following with ghc-4.06 produces an erroneous
error message:
module O where
a :: Int
a = 1
b :: Int
b = 2
c :: Int
c = 3
f :: Int - Bool
f i = case i of
a - True
b - True
c - True
The compiler complains:
o.hs:14: Pattern match(es) are
On the subject of bugs for which fixes are found which don't
seem to make
it into the CVS repository for a while, why exactly does RtsUtil.h
still contain the line
extern StgStablePtr errorHandler;
when "errorHandler" isn't actually defined anywhere?
("extern" of course doesn't
The following code does nothing one sent a -USR1 but "succeeds" (i.e.
fails with "User defined signal 2") on -USR2.
I'd be happy if someone could point me to the important thing I'm
constantly missing.
Oh dear. It looks like signal handling support has been broken for some
time. A patch to
causes the entire program to crash. (Not just the thread
that is doing the
threadWaitRead.) Is this not a little drastic? To run the
attached code use
ghc -syslib posix -syslib concurrent -cpp ThreadWaitFail.hs -o TWF
./TWF
You're right, this is a bug. But I'm not sure what to do
When making ghc from cvs, make all fails due to a
SocketPrim -syslib lang -syslib text
-optc-DNON_POSIX_SOURCE -c SocketPrim.lhs -o SocketPrim.o -osuf o
does not exist
Action: getDirectoryContents
Reason: no such file or directory
I've already fixed that one (and a related bug in ghc itself)
yesterday evening. But I don't know when exactly these changes
are mirrored in the anonCVS.
A note for GHC-from-CVS afficionados: Due to versionitis which is not
reflected in GHC's version number, you probably have to
ghc 4.06, solaris 5.7, distributed binaries.
the extra closing brace isn't caught in time...
main
= do
putStr "hello" }
hence:
panic! (the `impossible' happened):
Lex.popContext: empty context
Thanks for the report. This one was fixed recently in the CVS
It appears that the library Native has disappeared between 4.04 and
4.06, in the big hslibs reorganisation. Can we expect it to return,
and if so, when will it come back?
I don't think it's going to return, but if there is something you rely on
from it, then we should attempt to support it
They should not.
Thanks, this is now fixed (well partially, we don't attempt to lex
hexadecimal literals any more).
Cheers,
Simon
GHC's lexer (function Lex.mk_var_token) treats names starting with
an underscore followed by an uppercase letter as a constructor (conid)
and not as a variable (varid):
module Foo where
data T = _ThisWorksAlthoughItShouldNot
_ThisShouldWorkButItDoesNot = '?'
A comment in the
The following code crashes when compiled with -O2. With -O it does
not crash. Some trivial modifications make the crash go away.
Sorry, I can't repeat this one. As far as I can tell, using -O2 does three
things
- it forces -fvia-C (on by default anyway)
- it passes -O2 to
2.95.1
With -O -O2-for-C it still crashes. With -O it does not.
With -O2-for-C it does not.
(gdb) bt
#0 0x804932a in Main_zn_fast2 ()
#1 0x500c0444 in ?? ()
#2 0x500c1fa4 in ?? ()
#3 0x468bfc45 in ?? ()
Cannot access memory at address 0x8908468b.
We could investigate further,
(when doing gmake in the fptools directory.)
../../../ghc/driver/ghc-inplace -o DtdToHaskell -cpp
-fglasgow-exts -syslib text-H40m -OnotDtdToHaskell.o
DtdToTypeDefPP.o
/usr/local/pub-bkb/ghc/fptools/hslibs/data/libHSdata.a(FiniteM
ap__1.o)(.text+0x38): undefined reference to
I believe I've fixed the foreign export problems now, at least the examples
I've tried now work. However, this is a fairly large change so it may need
a couple of days to settle down.
Cheers,
Simon
You mean this one:
subl $RESERVED_C_STACK_BYTES + 4*SIZEOF_LONG,%esp
subracting from %esp caused the program to exit? Surely not!
Specifically, anything after the subl large number,%esp
did not happen. Perhaps causing an uncaught page fault?
(I dont think that the subl
Martin Kowalczyk writes:
$ ghc -fglasgow-exts -c Crash.hs
$ ghc -c crash.c
$ ghc -fglasgow-exts Crash.o Crash_stub.o crash.o -o crash
$ ./crash
10302
zsh: segmentation fault ./crash
$ ghc --version
The Glorious Glasgow Haskell
Bug (1): A totally clean, top of the CVS tree does not work on NT 4.0.
Behavior: returns with no result, any program.
Strange: Adding '+RTS -s' makes things work fine.
I think that there is not enough stack space on the C stack,
and the "change %esp register is failing us". The alloca
Hello lovely GHC people. I may have found a bug.
If I leave a hanging right brace where one might have been for a 'let'
expression, eg:
let env' = extendVarEnvList rho env }
I then receive the message:
panic! (the `impossible' happened):
Lex.popContext: empty context
I believe this bug is the weak ptr bug I fixed last week. In any case, the
example works with the latest sources (and I verified that it indeed crashes
under ghc-4.06).
The story (not part of the bug report).
I've made most of a Haskell-Perl interface for fun. Closures
are convertible in
Hello again,
When making cvs it halts because of a
Profiling.c:462: parse error before `'
I have appended a log.
It looks like you had a conflict when you cvs updated. Check Profiling.c
for the telltale ''. If you didn't make any changes to Profiling.c that
you want to keep (I suspect
I just updated cvs and now make fails because of a
Profiling.c:462: strucuture has no member named `emitted'
thingy. Log appended.
my bad; now fixed.
Cheers,
Simon
701 - 800 of 1053 matches
Mail list logo
