On Thu, Jan 22, 2009 at 12:42:56AM -0500, Daniel Eischen wrote:
On Wed, 21 Jan 2009, David Schultz wrote:
I think there *is* a real bug here, but there's two distinct ways
to fix it. When a threaded process forks, malloc acquires all its
locks so that its state is consistent after a fork.
On Wed, 18 Mar 2009, Kostik Belousov wrote:
I looked at the issue once more recently, and I propose the following
much less intrusive patch. It is somewhat hackish, but I think that
it would be good to have this working. Most other Unixes do have
working thread library after the fork. Any
Kostik Belousov wrote:
I looked at the issue once more recently, and I propose the following
much less intrusive patch. It is somewhat hackish, but I think that
it would be good to have this working. Most other Unixes do have
working thread library after the fork. Any objections ?
diff --git
On Thu, Jan 22, 2009 at 12:42:56AM -0500, Daniel Eischen wrote:
On Wed, 21 Jan 2009, David Schultz wrote:
I think there *is* a real bug here, but there's two distinct ways
to fix it. When a threaded process forks, malloc acquires all its
locks so that its state is consistent after a fork.
On Mon, Jan 19, 2009 at 07:41:35PM -0500, Brian Fundakowski Feldman wrote:
On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote:
Brian Fundakowski Feldman wrote:
Could you, and anyone else who would care to, check this out? It's a
regression
fix but it also makes the code a
On Wed, 21 Jan 2009, Brian Fundakowski Feldman wrote:
On Mon, Jan 19, 2009 at 07:41:35PM -0500, Brian Fundakowski Feldman wrote:
On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote:
Brian Fundakowski Feldman wrote:
Could you, and anyone else who would care to, check this out? It's a
I think there *is* a real bug here, but there's two distinct ways
to fix it. When a threaded process forks, malloc acquires all its
locks so that its state is consistent after a fork. However, the
post-fork hook that's supposed to release these locks fails to do
so in the child because the child
On Wed, 21 Jan 2009, David Schultz wrote:
I think there *is* a real bug here, but there's two distinct ways
to fix it. When a threaded process forks, malloc acquires all its
locks so that its state is consistent after a fork. However, the
post-fork hook that's supposed to release these locks
On Thu, Jan 22, 2009, Daniel Eischen wrote:
On Wed, 21 Jan 2009, David Schultz wrote:
I think there *is* a real bug here, but there's two distinct ways
to fix it. When a threaded process forks, malloc acquires all its
locks so that its state is consistent after a fork. However, the
On Thu, Jan 22, 2009, David Schultz wrote:
If you can't implement functions that are required to be
async-signal-safe like fork() and exec() without malloc(), then
for now I guess we should go for something along the lines of what
Brian is proposing. If the app programmer has taken special
On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote:
Brian Fundakowski Feldman wrote:
Could you, and anyone else who would care to, check this out? It's a
regression
fix but it also makes the code a little bit clearer. Thanks!
Index: lib/libc/stdlib/malloc.c
Why does malloc
On Fri, Jan 09, 2009 at 09:39:08AM -0800, Julian Elischer wrote:
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian
Brian Fundakowski Feldman wrote:
Could you, and anyone else who would care to, check this out? It's
a regression
fix but it also makes the code a little bit clearer. Thanks!
Index: lib/libc/stdlib/malloc.c
Why does malloc need to change for this? Unless there's a really good
reason, I
On Fri, 9 Jan 2009, Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then
On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for
On Fri, Jan 09, 2009 at 11:34:26AM -0500, Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
On Fri, Jan 09, 2009 at 07:42:32PM +0200, Kostik Belousov wrote:
On Fri, Jan 09, 2009 at 11:34:26AM -0500, Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote:
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to go threaded, it
deadlocks because it already appears to have locks held. I am not familiar
enough with the current libthr/libc/rtld-elf interaction that
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to go threaded, it
deadlocks because it already appears to have locks held. I am not familiar
enough
In the last episode (Jan 08), Daniel Eischen said:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat
broken such that when a threaded program forks, and then its child
attempts to go threaded, it deadlocks because it already
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such
that
when a threaded program forks, and then its child attempts to go threaded, it
deadlocks
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to
Brian Fundakowski Feldman wrote:
On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
It appears that the post-fork hooks for malloc(3) are somewhat broken such that
when a threaded program forks, and then its child attempts to
24 matches
Mail list logo
