Closed GoogleCodeExporter closed 8 years ago
Exactly the same problem here.
Original comment by jan.h....@gmail.com
on 11 Nov 2008 at 4:18
Similar results with 6.10.1, also with gridSelect
See those similar, but not exactly the same x11 errors attached:
Original comment by vogt.a...@gmail.com
on 13 Nov 2008 at 3:26
Attachments:
Original comment by SpencerJ...@gmail.com
on 23 Nov 2008 at 11:03
Original comment by SpencerJ...@gmail.com
on 23 Nov 2008 at 11:06
What architecture are you guys on? As it happens, I am running the release GHC
with
darcs XMonad/XMC, but I don't notice any issues with Prompt - but I'm on an
i386 Ubuntu.
Original comment by gwe...@gmail.com
on 23 Nov 2008 at 11:27
This is on x86_64
Original comment by vogt.a...@gmail.com
on 24 Nov 2008 at 2:52
Since we see this error on x86_64, but not i386, it is logical to assume that
the
issue is most likely in our FFI code. The next step is to audit all the X11
calls
that prompt makes and check that the proper sized types are used.
Original comment by SpencerJ...@gmail.com
on 5 Dec 2008 at 5:00
With 5 Dec xm darcs (with xft), X11-1.4.5, xorg-server-1.5.2 on i686 and x86_64
machines:
simpleTabbed works on i686, but on x86_64 allocates space for tabs and draws
nothing,
does not freeze. (i.e. a gap appears with root visible)
http://hpaste.org/12713#a4 --simpleTabbed stdError output
shellPrompt works on i686, does nothing then freezes on x86_64.
http://hpaste.org/12713#a2 --shellPrompt stdError output
Original comment by wirtwo...@gmail.com
on 5 Dec 2008 at 4:38
Recompiled without xft and still get same errors (simpleTabbed shellPrompt) on
x86_64/6.10. Attached is ghc-pkg list and output from sjanssen's test code.
Original comment by wirtwo...@gmail.com
on 5 Dec 2008 at 8:29
Attachments:
Thanks for all the excellent test data. All tests so far have an error similar
to:
> xmonad: X11 error: BadMatch (invalid parameter attributes), request code=1,
error
code=8
Which indicates an invalid parameter (BadMatch) on a XCreateWindow call (X11
opcode
1). Naturally all subsequent X calls operating on that window will fail,
leading to
a failure to render windows and, in the case of Prompt which gathers input from
the
window, lock ups.
We have also seen that superficially similar programs have different results,
sometimes even varying from machine to machine.
All of these results point to one of two things: incorrect foreign import
declarations for createNewWindow, or correct foreign declarations but incorrect
code
generation by GHC.
The next step is to come up with a minimal test program and ask for help from
GHC HQ.
Original comment by SpencerJ...@gmail.com
on 6 Dec 2008 at 7:40
xmobar-0.9 and xmobar-darcs also trigger similar error when xmobar is run from
cli or
spawned in xmonad.hs. These were xmobars compiled with ghc-6.10.1 on two
different
64-bit gentoo systems. Reverting to ghc-6.8.3 and rebuilding haskell bits makes
prompt/showWS/decorations/xmobar work again.
Original comment by wirtwo...@gmail.com
on 26 Dec 2008 at 2:10
This seems to be a GHC optimization bug. As a workaround, try this in
xmonad-contrib:
> runghc Setup clean
> runghc Setup configure --disable-optimization # and any other flags you
usually pass
> runghc Setup build
> runghc Setup install
> xmonad --recompile
Please advise whether this solves the issue or not.
Original comment by SpencerJ...@gmail.com
on 8 Jan 2009 at 2:35
This fixes the issue for me, thanks.
Original comment by frederik...@gmail.com
on 8 Jan 2009 at 10:34
This fixes it for me too
Original comment by vogt.a...@gmail.com
on 8 Jan 2009 at 11:39
This has been bothering me for some time in my Gentoo install.
That fix worked for me too, so I attach a modified ebuild for Gentoo which
includes
that flag and a warning with instructions on how to proceed after recompiling
it. I
didn't know how to contact the haskell overlay team, I hope someone sees the
ebuild
here. I hope it's useful to someone. It seems to have worked for me at least.
Original comment by yobonobo...@gmail.com
on 9 Jan 2009 at 5:50
Attachments:
worked here as well, darcs xmonad-contrib, ghc 6.10 on arch linux.
Original comment by sean.esc...@gmail.com
on 12 Jan 2009 at 5:32
Using CentOS 5.1 with GHC 6.10.1 x86_64. Same issue. Disabling optimization
fixed
this for me as well.
Original comment by coreyoco...@gmail.com
on 16 Jan 2009 at 5:53
We need to construct a test case for the GHC team, and submit a bug report
here,
http://hackage.haskell.org/trac/ghc/newticket?type=bug
Original comment by don...@gmail.com
on 16 Jan 2009 at 5:56
Now we wait for GHC HQ.
http://hackage.haskell.org/trac/ghc/ticket/2961
Original comment by SpencerJ...@gmail.com
on 16 Jan 2009 at 11:43
The bug has been fixed in GHC head. Now we wait for the next GHC release to
verify.
Original comment by SpencerJ...@gmail.com
on 26 Jan 2009 at 9:04
I can't reproduce this with ghc 6.10.2
Original comment by vogt.a...@gmail.com
on 9 Apr 2009 at 1:56
Original comment by SpencerJ...@gmail.com
on 9 Apr 2009 at 8:04
Original issue reported on code.google.com by
vogt.a...@gmail.com
on 20 Oct 2008 at 5:22Attachments: