--- Comment #35 from jb at gcc dot gnu dot org 2008-02-10 16:55 ---
Patch with __gthread_mutex_destroy for all implementations:
http://gcc.gnu.org/ml/fortran/2008-02/msg00082.html
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #36 from jvdelisle at gcc dot gnu dot org 2008-02-10 18:07
---
Subject: Bug 35063
Author: jvdelisle
Date: Sun Feb 10 18:06:34 2008
New Revision: 132217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132217
Log:
2008-02-10 Danny Smith [EMAIL PROTECTED]
PR
--- Comment #37 from jvdelisle at gcc dot gnu dot org 2008-02-10 18:09
---
Interim windows only patch committed. Followup on Comment #35 for 4.4.
Keeping this PR open until then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
--- Comment #33 from tkoenig at gcc dot gnu dot org 2008-02-09 21:49
---
We should fix this in 4.3.0 (and it's a regression, too).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from jvdelisle at gcc dot gnu dot org 2008-02-10 00:25
---
Just waiting for someone who can approve it to actually approve it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2008-02-08 08:58
---
(In reply to comment #19)
I would not mind seeing a threaded example where
this could be tested and that confirms we need to lock internal units. :)
Me too :) I think I got confused between locking the
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2008-02-08 14:26
---
Reply to comment #23. With external units we have a treap structure which
holds pointers to the unit structures so that we reuse them as needed The
treap is searched first for an existing unit and returns that
--- Comment #28 from jvdelisle at gcc dot gnu dot org 2008-02-08 16:33
---
pthread_mutex_destroy() fixes the problem on Cygwin including the case in
Comment #26. It regression tests OK on Linux-x86-64. I am now just reviewing
to make sure we don't try to lock after a destroy, which
--- Comment #27 from jvdelisle at gcc dot gnu dot org 2008-02-08 14:58
---
OK OK I believe you. :) What the heck was I looking at before? :) I am just
working up the closehandle patch now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2008-02-08 18:10
---
Created an attachment (id=15118)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15118action=view)
Proposed patch, needs testing on mingw
Here is the patch. I have tested this on Cygwin, but not mingw. It
--- Comment #24 from jpr at csc dot fi 2008-02-08 12:12 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
This might be desirable for other reasons, but it will not fix the problem
completely.
Yeah well, the easy way out here would be to include
--- Comment #31 from jvdelisle at verizon dot net 2008-02-08 23:00 ---
Subject: Re: [Regression wrt g77] I/O leaks
handles/memory on Windows XP
mikko dot lyly at csc dot fi wrote:
--- Comment #30 from mikko dot lyly at csc dot fi 2008-02-08 22:31
---
I would appreciate
--- Comment #26 from fxcoudert at gcc dot gnu dot org 2008-02-08 14:39
---
(In reply to comment #25)
With external units we have a treap structure which
holds pointers to the unit structures so that we reuse them as needed.
I haven't looked at the source code, but I can assure you
--- Comment #30 from mikko dot lyly at csc dot fi 2008-02-08 22:31 ---
I would appreciate if others would review/test this patch.
I have applied this patch against rev 132188 on mingw32.
The problem described in comments #1 and #7 for internal and external units,
rspectively, seems
--- Comment #32 from jpr at csc dot fi 2008-02-09 06:46 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
hi,
the patch looks good to me, although from the clarity point of view and
to avoid potential problem with other thread models, i'd go all the way
--- Comment #16 from jpr at csc dot fi 2008-02-07 09:19 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
Well, the internal write case is anyway a regression introduced by this
patch
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00717.html
---
--- Comment #19 from Jerry_V_DeLisle at rl dot gov 2008-02-07 15:54 ---
Writing to an internal unit is nothing more than a fancy (formatted)
assignment. Each thread allocates its own unit structure. Its not like file
I/O where threads are accessing a common shared resource.
I should
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-02-07 15:01
---
Once again, good detective work by jpr. This then does make this a regression
wrt 4.1. I do not have a 4.1 build on my windows machine to check. Regardless
...
This begs a question. Why do we even want
--- Comment #20 from brian at dessent dot net 2008-02-07 21:17 ---
Subject: Re: I/O leaks handles/memory on Windows XP
1) __gthr_win32_mutex_init_function()
- sets counter=-1
- creates a semaphore (the windows handle!)
2)__gthr_win32_mutex_lock()
- increments counter
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2008-02-07 15:20
---
(In reply to comment #17)
This begs a question. Why do we even want locking on internal units? The
string is local to the thread and allocated on the stack most likely.
What about the case of two threads
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2008-02-08 03:14
---
The problem manifests with:
$ gfc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc43/configure --prefix=/usr/local/gfortran
--enable-languages=c,fortran --disable-bootstrap
--- Comment #22 from jpr at csc dot fi 2008-02-08 05:29 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
So if the above is really at fault then the
leak should not manifest on Cygwin at all.
The logic there is ok i guess, as i already noted later in
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-02-07 06:07
---
Yes this is a regression wrt g77 and I have noted this in the summary. I have
attempted to insert a mutex_unlock in the right place and it has no effect. I
think jpr's assessment is correct, there needs to be
--- Comment #15 from kargl at gcc dot gnu dot org 2008-02-07 06:26 ---
(In reply to comment #14)
Yes this is a regression wrt g77 and I have noted this in the summary. I have
attempted to insert a mutex_unlock in the right place and it has no effect. I
think jpr's assessment is
24 matches
Mail list logo
