Threaded runtime error

2006-03-21 Thread Volker Stolz 
With -HEAD from darcs the new threaded runtime seems to trigger an assertion in
FreeBSD's libpthread.  Maybe this is some sign of an error in the RTS?
I can only find references to this happending also in MySQL, but I haven't found
any explanation yet.

This is 'timeout' from the testsuite:

[EMAIL PROTECTED] [20:17:08]> ./timeout 10 /usr/bin/true
FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in file 
/usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0)

[EMAIL PROTECTED] [20:20:15]> uname -a
FreeBSD menelaos.informatik.rwth-aachen.de 6.1-BETA3 FreeBSD 6.1-BETA3 #1: Mon 
Mar 13 10:45:03 CET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MENELAOS  
i386

A debugging RTS around this location shows:

sched (task 0x80b9600): created thread 5, stack size = f2 words
sched (task 0x80b9600): new bound thread (5)
sched (task 0x80b9600): ### NEW SCHEDULER LOOP (task: 0x80b1e00, cap: 0x80aed20)
sched (task 0x80b9600): ### Running thread 5 in bound thread
sched (task 0x80b9600): -->> running thread 5 ThreadRunGHC ...
sched (task 0x80b9600): --<< thread 5 (ThreadRunGHC) stopped, yielding
sched (task 0x80b9600): ### Running thread 5 in bound thread
sched (task 0x80b9600): -->> running thread 5 ThreadRunGHC ...
sched (task 0x80b9400): returning; I want capability 0
sched (task 0x80b9400): returning; got capability 0
sched (task 0x80b9400): thread 2: re-entering RTS
sched (task 0x80b9400): --<< thread 2 (ThreadRunGHC) stopped, yielding
sched (task 0x80b9400): -->> running thread 2 ThreadRunGHC ...
sched (task 0x80b9400): thread 2 did a safe foreign call
sched (task 0x80b9400): freeing capability 0
sched (task 0x80b9400): thread 2: leaving RTS
sched (task 0x80b9600): thread 5 did a safe foreign call
sched (task 0x80b9600): starting new worker on capability 0
FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in file 
/usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0)
sched (task 0x80b9600): returning; I want capability 0
sched (task 0x80b9600): returning; got capability 0
sched (task 0x80b9600): thread 4: re-entering RTS
-- 
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
"All the excitement lies in pattern matching." (SPJ et al.)

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #732: Error in shutdownHaskell() in Win32 DLL

2006-03-21 Thread GHC 
#732: Error in shutdownHaskell() in Win32 DLL
-+--
Reporter:  [EMAIL PROTECTED]  |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone:  6.4.2  
   Component:  Runtime System|  Version:  6.4.1  
Severity:  normal| Keywords: 
  Os:  Windows   |   Difficulty:  Easy (1 hr)
Architecture:  Unknown   |  
-+--
If an exception occurs in a Windows DLL produced by GHC,
 the following error message appears:

 {{{
 ghcDll: internal error: too many hs_exit()s
 Please report this as a bug to glasgow-haskell-bugs@haskell.org,
 or http://www.sourceforge.net/projects/ghc/
 }}}

 == How to reproduce ==

 1. Make a Haskell DLL using the enclosed Dll.hs and dllMain.c, e.g.
 {{{
 ghc -c Dll.hs -fglasgow-exts
 ghc -c dllMain.c
 ghc --mk-dll -o test.dll Dll.o Dll_stub.o dllMain.o
 }}}

 2. Generate an export library for the DLL, e.g.
 {{{
 lib /DEF:test.def /MACHINE:x86 /OUT:test.lib
 }}}

 3. Compile the executable with Visual C++ and run it.
 {{{
 cl -c testdll.cpp
 link testdll.obj test.lib /OUT:testdll.exe
 testdll.exe
 }}}

 Note: if I comment out the shutdownHaskell() call from dllMain.c
 (the line marked with /***/), it works fine.

 Kind regards,

 Cyril

  --- Dll.hs ---
 {{{
 module Dll (test) where

 foreign export ccall test :: IO ()

 test = error "Exception occurred"
 }}}

  --- dllMain.c ---
 {{{
 #include 
 #include 

 extern void __stginit_Dll(void);

 static char* args[] = { "ghcDll", NULL };

 BOOL
 STDCALL
 DllMain
( HANDLE hModule
, DWORD reason
, void* reserved
)
 {
   if (reason == DLL_PROCESS_ATTACH) {
   startupHaskell(1, args, __stginit_Dll);
   return TRUE;
   } else if (reason == DLL_PROCESS_DETACH) {
 /***/   shutdownHaskell();
   }
   return TRUE;
 }
 }}}

  --- test.def ---
 {{{
 EXPORTS
 test
 }}}

  --- testdll.cpp ---
 {{{
 extern "C" void test();

 int main() {
 test();
 return 0;
 }
 }}}

-- 
Ticket URL: 
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] #731: GHCi doesn't work on powerpc64

2006-03-21 Thread GHC 
#731: GHCi doesn't work on powerpc64
--+-
Reporter:  simonmar   |Owner: 
Type:  bug|   Status:  new
Priority:  normal |Milestone: 
   Component:  GHCi   |  Version:  6.4.1  
Severity:  normal | Keywords: 
  Os:  Unknown|   Difficulty:  Unknown
Architecture:  powerpc64  |  
--+-
See diagnosis from Duncan Coutts:

 [http://www.haskell.org//pipermail/cvs-ghc/2006-March/028889.html]

-- 
Ticket URL: 
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] #492: Retainer and biographical profiling with STM

2006-03-21 Thread GHC 
#492: Retainer and biographical profiling with STM
-+--
  Reporter:  simonmar|  Owner:  simonmar
  Type:  bug | Status:  closed  
  Priority:  normal  |  Milestone:  6.4.2   
 Component:  Runtime System  |Version:  6.4.1   
  Severity:  normal  | Resolution:  fixed   
  Keywords:  | Os:  Unknown 
Difficulty:  Unknown |   Architecture:  Unknown 
-+--
Changes (by simonmar):

  * architecture:  => Unknown
  * resolution:  None => fixed
  * difficulty:  => Unknown
  * status:  assigned => closed
  * os:  => Unknown

Comment:

 fixed in 6.4.2

-- 
Ticket URL: 
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] #716: Unloading a dll generated by GHC doesn't free all resources

2006-03-21 Thread GHC 
#716: Unloading a dll generated by GHC doesn't free all resources
-+--
  Reporter:  [EMAIL PROTECTED]  |  Owner:  simonmar
  Type:  bug | Status:  reopened
  Priority:  normal  |  Milestone:  6.6 
 Component:  Runtime System  |Version:  6.4.1   
  Severity:  normal  | Resolution:  
  Keywords:  | Os:  Unknown 
Difficulty:  Unknown |   Architecture:  Unknown 
-+--
Changes (by simonmar):

  * resolution:  fixed =>
  * milestone:  6.4.2 => 6.6
  * status:  closed => reopened

Comment:

 On second thoughts I'll leave the ticket open until it's fully fixed.  I
 don't expect to fix it properly in 6.4.2, though - the best chance for a
 complete fix is in the HEAD with the threaded RTS.  As far as I'm aware,
 in the HEAD's threaded RTS, all threads should shut down properly at exit
 except those currently blocked in foreign calls.

-- 
Ticket URL: 
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] #716: Unloading a dll generated by GHC doesn't free all resources

2006-03-21 Thread GHC 
#716: Unloading a dll generated by GHC doesn't free all resources
-+--
  Reporter:  [EMAIL PROTECTED]  |  Owner:  simonmar
  Type:  bug | Status:  closed  
  Priority:  normal  |  Milestone:  6.4.2   
 Component:  Runtime System  |Version:  6.4.1   
  Severity:  normal  | Resolution:  fixed   
  Keywords:  | Os:  Unknown 
Difficulty:  Unknown |   Architecture:  Unknown 
-+--
Changes (by simonmar):

  * resolution:  => fixed
  * status:  new => closed

Comment:

 Now fixed, at least partially.  Please test.  I've addressed the timer
 thread issue.

 I've run a test program that loads & unloads a DLL several hundred times
 without crashing (it used to crash before the patch).

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs