January 2016 - ghc-tickets

[GHC] #11500: C finalizer of a finalized ForeignPtr may be called again when RTS shuts down
by GHC 27 Jan '16

27 Jan '16

#11500: C finalizer of a finalized ForeignPtr may be called again when RTS shuts down -------------------------------------+------------------------------------- Reporter: skydust | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The C finalizer of a ForeignPtr that was explicitly finalized (finalizeForeignPtr) is sometimes called again when the RTS shuts down. Expected behaviour: - The test script (./test.sh) below never stops Observed behaviour: - After a while, the test script stops with an error message indicating double free or memory corruption {{{#!sh $ ./test.sh }}} {{{ [1 of 1] Compiling Main ( finalizer_hs.hs, finalizer_hs.o ) Linking finalizer_hs ... *** Error in `./finalizer_hs': double free or corruption (!prev): 0x00000000010b85e0 *** ./test.sh: line 3: 20482 Aborted (core dumped) ./finalizer_hs +RTS -N 178 }}} File finalizer_hs.hs {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} import Foreign (Ptr, FunPtr, malloc) import Foreign.ForeignPtr (newForeignPtr, finalizeForeignPtr) import Control.Monad (forM, forM_) foreign import ccall "stdlib.h &free" p_free :: FunPtr (Ptr a -> IO ()) main :: IO () main = do fps <- forM [1 .. 10000] $ \_ -> do p <- malloc newForeignPtr p_free (p :: Ptr Int) forM_ fps finalizeForeignPtr }}} File test.sh: {{{#!sh ghc finalizer_hs.hs -threaded CNT=0 while ./finalizer_hs +RTS -N; do CNT=$((CNT+1)); done echo $CNT }}} Note: running several instances of ./test.sh concurrently triggers the problem faster Issue detected on following tested setups: - Linux 32bit GHC 7.10.2 - Linux 64bit GHC 7.8.3 - Linux 64bit GHC 7.8.4 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11500> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5654: Profiling semantics bug
by GHC 27 Jan '16

27 Jan '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow <marlowsd@…>): In [changeset:"85daac593c498f581d46f44982ee5dcf1001f611/ghc" 85daac5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85daac593c498f581d46f44982ee5dcf1001f611" Fix cost-centre-stack bug when creating new PAP (#5654) See comment in `AutoApply.h`. This partly fixes #5654. New test added, and renamed the old test to match the ticket number. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9105: Profiling binary consumes CPU even when idle on Linux.
by GHC 27 Jan '16

27 Jan '16

#9105: Profiling binary consumes CPU even when idle on Linux. ----------------------------+--------------------------------- Reporter: robinp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The program is main = forever $ threadDelay 1000000 >> return () . Compiled with 32bit GHC 7.6.3 or 7.8.2 on Debian (inside a VM), GHC 7.4.1 on Ubuntu (not VM). The non-profiling binary doesn't consume CPU, the profiling does ~10% (of a 2Ghz machine). Running with +RTS -I0, so this is not the idle gc. When strace-ing, the profiling one seems to receive a constant flow of SIGVTALRM, while the normal receives one burst each second. I see I can switch off "master tick interval" with -V0, and then CPU is not used, but the consequences of this are not very well documented (apart from context switching becoming deterministic). Interestingly, if I compile using profiling on Windows (latest haskell- platform, 64bit), it doesn't use more CPU than the non-profiling. So, the question is, why does this happen on Linux, and if it can be avoided somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11496: Build profiling libraries on `validate --slow`
by GHC 27 Jan '16

27 Jan '16

#11496: Build profiling libraries on `validate --slow` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be good to test the `profiling` test ways regularly (`prof`, `profasm`, `profthreaded` etc.). These test ways require the profiling libraries to be built first, which `validate` doesn't do at the moment. We do release profiling libraries, so we'd better make sure they work correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11496> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11451: Inconsistent warnings for unused binders
by GHC 27 Jan '16

27 Jan '16

#11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider compiling this with `-Wunused-matches`: {{{ class C a where op :: a -> a instance C (Maybe a) where op x = x }}} We get no warnings, even though `a` is patently unused. But suppose we add an associated type {{{ class C a where type T a op :: a -> a instance C (Maybe a) where type T (Maybe a) = Int -- Warning on this line op x = x }}} Now we get a warning for an unused binding for `a` on the `type instance`. Edward complained about this inconsistent behaviour in [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-January/026114.html this email thread]. My thoughts: * Currently GHC does not warn about type variables bound in the instance head but unused in the `where` part. Fixing that might be a good idea, but would be a new feature. * However, given that we don't warn about them, we should definitely not warn about instance type variables being unused in an associated type. But we could warn about ones specific to the associated type itself. Eg {{{ class C2 a where type T2 a b instance C2 (Maybe a) where type T2 (Maybe a) x = Int -- Line XXX }}} Here, on line `XXX`, we might reasonably warn about the unused `x`, but not about the unused `a`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #11489: Segmentation fault when .prof file not writeable
by GHC 27 Jan '16

27 Jan '16

#11489: Segmentation fault when .prof file not writeable -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To reproduce: {{{ $ echo 'main = return ()' > Test.hs $ touch Test.prof $ chmod -w Test.prof $ ghc -prof Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./Test +RTS -hr{} -hc Can't open profiling report file Test.prof Segmentation fault (core dumped) }}} The warning is ok (maybe it should be an error?), but it shouldn't segfault. Running `./Test +RTS -hr` works fine. http://downloads.haskell.org/~ghc/master/users-guide/profiling.html#rts- options-for-heap-profiling: * `-hc`: Breaks down the graph by the cost-centre stack which produced the data. * `-hr⟨cc⟩`: Restrict the profile to closures with retainer sets containing cost-centre stacks with one of the specified cost centres at the top. Bug exists since dbef766ce79e37a74468a07a93b15ba1f06fe8f8 (2002): {{{ - you can now restrict a heap profile to certain retainer sets, but still display by cost centre (or type, or closure or whatever). }}} Because it didn't update this code+comment introduced in db61851c5472bf565cd1da900b33d6e033fd743d (2001): {{{ // The following line was added by Sung; retainer/LDV profiling may need // two output files, i.e., <program>.prof/hp. if (RtsFlags.ProfFlags.doHeapProfile == HEAP_BY_RETAINER) RtsFlags.ProfFlags.doHeapProfile = 0; }}} Another relevant commit a4e17de6a38eb37cabff165e8f280a236ffa8af6: {{{ Author: simonmar <unknown> Date: Wed Nov 28 15:42:26 2001 +0000 [project @ 2001-11-28 15:42:26 by simonmar] Don't need the .prof file when LDV-profiling. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11489> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11497: LAMBORGHINI MANYLINE JOINT SHARE
by GHC 26 Jan '16

26 Jan '16

#11497: LAMBORGHINI MANYLINE JOINT SHARE -------------------------------------+------------------------------------- Reporter: | Owner: kamaljitchakraborty | Type: feature | Status: new request | Priority: highest | Milestone: 7.10.4 Component: Build System | Version: 7.0.4 Keywords: LAMBORGHINI | Operating System: MacOS X MANYLINE JOINT SHARE | Architecture: Other | Type of failure: Other Test Case: none | Blocked By: Blocking: | Related Tickets: no Differential Rev(s): no | Wiki Page: none -------------------------------------+------------------------------------- http://lamborghini.com [[Image(link company_profile_1800x405.kamaljit.jpg )]] * '''bold''', ''' myself a worker in this company : THIS THE COMPANY WEBSITE ADDRESS ''', * ''italic'' * '''''VIA MODENA 12,40019,SAN'T AGATA BOLOGNESE [B0]''''' or ''italic and ''' italic bold ''' '' * __LAMBORGHINI MANYLINE JOINT SHARE__ * {{{schoolbook century}}} or `monospace` (hence ` RESPECTED FERRUCCIO LAMBORGHINI` or {{{:LAMBORGHINI}}} quoting `{{{VAT ID:00591801204 wire with ||:ICIC0002790}}} quoting) * ~~strike-through KAMALJITCHAKRABORTY~~ * ^LAMBORGHINI AUTOMOBILI S.p.A^ * ,,subscript,, * **RESPECTED STEPHAN WINKELMANN**, //**RESPECTED PATRICK KUJALA as well**//,**SRI SUSIT KUMAR CHAKRABARTI**, and **'' bold italic **'' //(since 0.40)// [[Image(thumb_IMG_0216_1024.jpg)]] * {{{Item}}} 1CK: Friday, February 19th, 2016 - Monday, February 22nd, 2016 {{{WINTER ACCADEMIA LIVIGNO - AVANZATO 1 }}} * Item 1.1 * Item 1.1.1 * Item 1.1.2 * Item 1.1.3 * Item 1.2 * {{{Item}}} 2CK: Sunday, February 21st, 2016 - Wednesday, February 24th, 2016 {{{WINTER ACCADEMIA LIVIGNO - AVANZATO 2 }}} * Item 2.2.1 * Item 2.2.2 * Item 2.2.3 * {{{Item}}} 3CK:Tuesday, February 23rd, 2016 - Friday, February 26th, 2016 {{{WINTER ACCADEMIA LIVIGNO - AVANZATO 3}}} * Item 3.3.1 * Item 3.3.2 * Item 3.3.3 * {{{Item}}} 4CK: Thursday, February 25th, 2016 - Saturday, February 27th, 2016 {{{WINTER ACCADEMIA LIVIGNO - INTENSIVO 1}}} * Item 4.4.1 * Item 4.4.2 * Item 4.4.3 - items can start at the beginning of a line and they can span multiple lines - be careful though to continue the line with the appropriate indentation, otherwise that will start a new paragraph... 1. Item 1 a. Item 1.a a. Item 1.b i. Item 1.b.i i. Item 1.b.ii 1. Item 2 And numbered lists can also be restarted with an explicit number: 3. Item 3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10324: our rts/ghc-prim/base shared library tricks don't work on Android
by GHC 26 Jan '16

26 Jan '16

#10324: our rts/ghc-prim/base shared library tricks don't work on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.10.1 Component: Compiler | Operating System: Other Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I experimented with building dynamically linked executables on Android, and figured I should record my findings somewhere. (I'm interested in dynamic Haskell libraries because I'd like to eventually get ghci on Android, though obviously that would also require a bunch of packaging work!) Building a GHC with dynamic library support was no major problem, and I could build a dynamically linked "Hello, world" executable too. The problem arose when trying to actually run the executable: I got a message to the effect that there were unresolved symbols (that live in libHSrts) when loading libHSbase. I tried relinking the executable to put libHSrts before libHSbase in the list of NEEDED shared libraries, and now I instead got an error about missing symbols (that live in libHSbase) when loading libHSrts. I then tried rebuilding libHSrts against libHSbase... and then I got the first error again, about missing symbols (that live in libHSrts) when loading libHSbase, while loading libHSrts. I didn't try also rebuilding libHSbase against libHSrts, because at that point the base library would be dependent on the RTS flavor, which we don't really want. It appears based on these tests that the Android dynamic loader only looks for missing symbols in a shared library in the dependencies of that library in a depth-first fashion, while the Linux ld.so seems to do something more like loading every (direct and indirect) dependency of the executable first and then resolving symbol references between them all at once. I didn't fully characterize the Android loader behavior though, and it's possible that if we could remove the references from libHSrts to libHSbase and libHSghc-prim, then we could list libHSrts first among the dependencies of an executable, and hopefully once libHSrts has been loaded, the loader would then use its symbols to resolve references when loading the libHSghc-prim and libHSbase libraries, even without those libraries having NEEDED entries for libHSrts. Removing the references from libHSrts to libHSbase/libHSghc-prim should be fairly mechanical if we can use constructors in the latter libraries (basically emulate dynamic linking by adding a global variable to libHSrts which is a struct holding the addresses of the base/ghc-prim symbols it needs, and have constructors in those libraries fill in those addresses on load). If that doesn't work, another possibility may be to statically link libHSrts (or whatever part of it we need) into the executable and export libHSrts's dynamic symbols so that they can be used by libHSghc-prim (or other Haskell libraries). I also haven't tested whether this kind of mutual recursion between an executable and its shared library dependencies works on Android. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7790: Add dummy undefined symbols to indicate ways
by GHC 26 Jan '16

26 Jan '16

#7790: Add dummy undefined symbols to indicate ways -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Clever and simple, I like it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7790#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 26 Jan '16

26 Jan '16

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria Comment: I'm going to try my hand at this in my spare cycles. If it's blocking anyone feel free to grab it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0