Re: [GHC] #1346: bootstrap from HC files
#1346: bootstrap from HC files -+-- Reporter: simonmar |Owner: Type: bug | Status: new Priority: high |Milestone: 6.12 branch Component: Build System | Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Moderate (1 day) Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by kgardas): * cc: karel.gar...@centrum.cz (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1346#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked
#2910: throwTo can block indefinitely when target thread finishes with
exceptions
blocked
-+--
Reporter: int-e |Owner: igloo
Type: merge | Status: new
Priority: normal|Milestone: 6.10.2
Component: Runtime System| Version: 6.10.1
Severity: normal| Resolution:
Keywords:| Difficulty: Easy (1 hr)
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by simonmar):
Replying to [comment:3 int-e]:
As the patches I just attached suggest, this race is not completely
fixed. (I'm pretty certain - Conal's TestRace program locks up without the
first patch, but works fine so far with it. I also have a modified version
that logs thread creation and throwTo and shows the program lock up with
all threads finished except the main thread, which is blocked on an
exception.)
The second patch contains changes unrelated to this bug which I'm not
100% certain about - but they felt necessary.
Thanks - it's nice to have someone else looking at this code!
In response to your patches:
{{{
hunk ./rts/RaiseAsync.c 418
// Unblocking BlockedOnSTM threads requires the TSO to be
// locked; see STM.c:unpark_tso().
if (target-why_blocked != BlockedOnSTM) {
+ unlockTSO(target);
goto retry;
}
if ((target-flags TSO_BLOCKEX)
}}}
well spotted.
{{{
hunk ./rts/RaiseAsync.c 440
// thread is blocking exceptions, and block on its
// blocked_exception queue.
lockTSO(target);
+ if (target-why_blocked != BlockedOnCCall
+ target-why_blocked != BlockedOnCCall_NoUnblockExc) {
+ unlockTSO(target);
+ return;
+ }
blockedThrowTo(cap,source,target);
*out = target;
return THROWTO_BLOCKED;
}}}
again, well spotted - except that we want `goto retry` rather than
`return`.
{{{
hunk ./rts/RaiseAsync.c 267
target = target-_link;
goto retry;
}
+ // The thread may also have finished in the meantime.
+ if (target-what_next == ThreadKilled
+ || target-what_next == ThreadComplete) {
+ unlockTSO(target);
+ return THROWTO_SUCCESS;
+ }
blockedThrowTo(cap,source,target);
*out = target;
return THROWTO_BLOCKED;
}}}
`lockTSO()` doesn't lock the `what_next` field, only the
`blocked_exceptions` field, so I think this change is not necessary.
{{{
hunk ./rts/RaiseAsync.c 555
void
awakenBlockedExceptionQueue (Capability *cap, StgTSO *tso)
{
+lockTSO(tso);
+// Taking the tso lock before the following check assures that we
+// wait for any throwTo that may just be adding a new thread to the
+// queue. This is essential, because we may not get another chance
+// to wake up that thread.
if (tso-blocked_exceptions != END_TSO_QUEUE) {
hunk ./rts/RaiseAsync.c 561
- lockTSO(tso);
awakenBlockedQueue(cap, tso-blocked_exceptions);
tso-blocked_exceptions = END_TSO_QUEUE;
hunk ./rts/RaiseAsync.c 563
- unlockTSO(tso);
}
hunk ./rts/RaiseAsync.c 564
+unlockTSO(tso);
}
}}}
This is not necessary. However, while figuring out why, I did find the
real bug. Threads that fall through the cracks and end up on the
blocked_exceptions list of a finished or blocked target thread are
supposed to be caught by the GC (see comments at line 216 in
`MarkWeak.c`). However, this wasn't working in the case when the target
thread had finished, because `maybePerformBlockedException()` wasn't
handling the `ThreadComplete` or `ThreadKilled` case, so I've fixed that.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2910#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked
#2910: throwTo can block indefinitely when target thread finishes with
exceptions
blocked
-+--
Reporter: int-e |Owner: igloo
Type: merge | Status: new
Priority: normal|Milestone: 6.10.2
Component: Runtime System| Version: 6.10.1
Severity: normal| Resolution:
Keywords:| Difficulty: Easy (1 hr)
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by int-e):
Replying to [comment:4 simonmar]:
Thanks - it's nice to have someone else looking at this code!
You're welcome.
`lockTSO()` doesn't lock the `what_next` field, only the
`blocked_exceptions` field, so I think this change is not necessary.
Ah, I see. But I believe that the change still makes sense - see below.
Threads that fall through the cracks and end up on the
blocked_exceptions list of a finished or blocked target thread are
supposed to be caught by the GC ...
And that's the part I missed, although admittedly I'm a bit unhappy about
waiting for the next GC. Does the RTS perform a GC when it finds no other
work? In any case, there'll be some wait.
Now I believe we can prevent this from happening, with those two hunks
above. The key idea is that once the {{{what_next}}} field is set to
{{{ThreadComplete}}} or {{{ThreadKilled}}}, it will not be modified again.
As you wrote in the comment in {{{scheduleHandleThreadFinished}}},
{{{what_next}}} has already been set when
{{{awakenBlockedExceptionQueue}}} is called. So the only scenario we have
to prevent is that a thread throwing an exception finds its target
running, and then adds itself to the target's {{{blocked_exception}}}
queue, with the target thread completing and running
{{{awakenExceptionQueue}}} inbetween those two steps.
This can be accomplished by making {{{awakenExceptionQueue}}} take the TSO
lock every time, *and* checking whether the target has finished between
taking the TSO lock and calling {{{blockedThrowTo}}} for all calls to
{{{blockedThrowTo}}}, unless we can prove that the thread cannot finish in
the meantime.
My changes only covered the {{{NotBlocked}}} case. I believe that in the
{{{Blocked*}}} cases, the thread cannot finish in the meantime (they lock
the TSO, directly or indirectly, and then check that the thread is still
blocked - which implies that it has not finished), but I'm 100% not
certain.
To summarize: We would not use the TSO lock to protect the {{{what_next}}}
field - we'd use (or abuse?) it to prevent a specific race between
{{{blockedThrowTo}}} and {{{awakenExceptionQueue}}}.
I think the benefits are clear: We avoid one case of the RTS having to
wait for a GC.
The cost seems bearable: {{{awakenExceptionQueue}}} is only called when a
thread finishes or when it returns from a C call (and in the latter case,
we could continue to use the old variant). Both cases aren't exactly fast
paths. Then there's a cost in code complexity (the reasoning is fairly
tricky) - but that's your judgement call.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2910#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked
#2910: throwTo can block indefinitely when target thread finishes with exceptions blocked -+-- Reporter: int-e |Owner: igloo Type: merge | Status: new Priority: normal|Milestone: 6.10.2 Component: Runtime System| Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Easy (1 hr) Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonmar): Yes, I realise your patch was aimed at closing the race. I was worried about the cost of doing an unconditional `lockTSO` on thread exit, and the complexity of the invariant. However, I haven't been able to measure a difference in performance (yet!) so I'll probably go with your version (but also with my fixes, a little extra robustness won't hurt). The GC runs after 0.3 seconds of non-activity, BTW. This is tunable with the `+RTS -I` flag. Also, while playing with Conal's TestRace program I found two more races, patches to follow. yay! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2910#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1475: Adding imports and exports with Template Haskell
#1475: Adding imports and exports with Template Haskell -+-- Reporter: igloo |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by Deewiant): * cc: Deewiant (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1475#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1800: Template Haskell support for running functions defined in the same module
#1800: Template Haskell support for running functions defined in the same module -+-- Reporter: simonpj |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Template Haskell | Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by Deewiant): * cc: Deewiant (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1800#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked
#2910: throwTo can block indefinitely when target thread finishes with
exceptions
blocked
-+--
Reporter: int-e |Owner: igloo
Type: merge | Status: new
Priority: normal|Milestone: 6.10.2
Component: Runtime System| Version: 6.10.1
Severity: normal| Resolution:
Keywords:| Difficulty: Easy (1 hr)
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by simonmar):
More patches to merge:
{{{
Wed Jan 7 11:20:26 GMT 2009 Simon Marlow marlo...@gmail.com
* putMVar and takeMVar: add write_barrier() to fix race with throwTo
Wed Jan 7 12:06:52 GMT 2009 Simon Marlow marlo...@gmail.com
* fix a race where the timer signal could remain turned off, leading to
deadlock
Wed Jan 7 12:07:34 GMT 2009 Simon Marlow marlo...@gmail.com
* maybePerformBlockedException() should handle
ThreadComplete/ThreadKilled
Part of the fix for #2910
Wed Jan 7 12:08:08 GMT 2009 Bertram Felgenhauer in...@gmx.de
* Fix two more locking issues in throwTo()
Wed Jan 7 12:11:42 GMT 2009 Simon Marlow marlo...@gmail.com
* add comment
Wed Jan 7 14:05:07 GMT 2009 Simon Marlow marlo...@gmail.com
* Close the races between throwTo and thread completion
Any threads we missed were being caught by the GC (possibly the idle
GC if the system was otherwise inactive), but that's not ideal. The
fix (from Bertram Felgenhauer) is to use lockTSO to synchronise,
imposing an unconditional lockTSO on thread exit. I couldn't measure
any performance overhead from doing this, so it seems reasonable.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2910#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2917: alloca and allocaArray do not respect alignment
#2917: alloca and allocaArray do not respect alignment --+- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler (FFI)|Version: 6.10.1 Severity: normal| Resolution: Keywords:| Testcase: Os: Unknown/Multiple | Architecture: x86 --+- Comment (by guest): I've added a patch to use the alignment when allocating. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2917#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #849: Offer control over branch prediction
#849: Offer control over branch prediction -+-- Reporter: simonpj |Owner: Type: feature request | Status: new Priority: normal|Milestone: 6.10 branch Component: Compiler | Version: 6.4.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by tibbe): * cc: johan.tib...@gmail.com (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/849#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #2920: old-time on hackage is incorrectly packaged
#2920: old-time on hackage is incorrectly packaged
-+--
Reporter: dons | Owner:
Type: bug | Status: new
Priority: normal| Component: libraries (old-time)
Version: 6.10.1| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
old-time is missing its ./configure script:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/old-time
{{{
$ tar xzf old-time-1.0.0.0.tar.gz
$ cd old-time-1.0.0.0
$ ls
LICENSE Setup.hs System cbits include old-time.cabal
}}}
It needs:
{{{
$ cd ghc/libraries/old-time
$ ls
LICENSE System aclocal.m4 cbits configure.ac old-time.cabal
Setup.hs _darcs autom4te.cache configure include prologue.t
}}}
i.e. its ./configure script.
This leads to cabal install failures, for example
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2920
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2746: Documentation for Haskell 98 modules is empty
#2746: Documentation for Haskell 98 modules is empty
-+--
Reporter: simonmar |Owner:
Type: bug | Status: new
Priority: high |Milestone: 6.10.2
Component: Documentation | Version: 6.10.1
Severity: major | Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by waern):
Ok, so the problem with links that goes to the wrong place is now fixed
with this patch (in the HEAD):
{{{
Wed Jan 7 00:34:17 CET 2009 David Waern david.wa...@gmail.com
* Do not process boot modules
We should of course not try to produce documentation for boot modules!
The
reason this has worked in the past is that the output of real modules
overwrites the output of boot modules later in the process. However,
this
causes a subtle link environment problem. So let's get rid of this
stupid
behaviour.
We avoid processing boot modules, but we continue to typecheck them.
}}}
So that was a Haddock bug and not a GHC one.
Now Char from haskell98 has links to definitions in Data.Char and
GHC.Types.
Will tackle CTypes and the likes next.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2746#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #2921: __GLASGOW_HASKELL__ undefined
#2921: __GLASGOW_HASKELL__ undefined -+-- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 6.10.1| Severity: normal Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -+-- After manually forcing adding HsFFI.h to the search path of hsc2hs -- which is also broken, as reported in another bug -- __GLASGOW_HASKELL__ still seems to be undefined, breaking detections. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2921 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
