Re: forking heap question
- From: Edscott Wilson García <edscott imp mx>
- To: Paul Davis <pbd op net>
- Cc: Havoc Pennington <hp redhat com>, gtk-list gnome org
- Subject: Re: forking heap question
- Date: Tue, 04 Dec 2001 14:14:15 -0600
Paul Davis wrote:
>
> >Neither do I think it's possible. Yet, it is so. Maybe a failed malloc()
>
> no its not. virtual address spaces make it so. children have no access
> to their parent's address space. global variables make no difference.
>
> >or free() makes the child access a gtk widget it's not supposed to, via
> >some globally defined variable. This is the offending code executed by
> >the child (the complete file is xtree_cpy.c from program xftree of the
> >xfce desktop environment with CVS at sourceforge.net):
> >
> >The recursive call makes the parent fail quickly. The non recursive call
> >also makes it
> >fail, as long as the child executes it the subroutined enough number of
> >times.
>
> have you checked that the recursion bottoms out? if the child uses all
> of available RAM (physical and swap), the parent will make
> a malloc call that returns NULL.
Yes. It does not bottom out. And the error occurs also in the
non-recursive case, when the
subroutine is performed within a simple loop. I have also noticed that
with gtk either the parent or the child can take over the gtk widgets,
depending on who accesses them first. So I believe some error (probably
memory allocation stuff) is fooling gtk into thinking that the child has
taken over the widgets, so when the parent tries to access them, it gets
the "x io error", of course. This explanation would leave child and
parent heaps totally independent, as should be. Maybe there is a way to
tell gtk at the fork point whether child or parent will keep the widgets
instead of leaving it up to gtk to decide?
--
saludos,
Edscott
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]