[Gluster-devel] glusterd crashes when synctask is used in conjunction with inner functions.
Krishnan Parthasarathi
kparthas at redhat.com
Mon Oct 8 17:21:37 UTC 2012
----- Original Message -----
> From: "Jeff Darcy" <jdarcy at redhat.com>
> To: "Krishnan Parthasarathi" <kparthas at redhat.com>, gluster-devel at nongnu.org
> Sent: Monday, October 8, 2012 6:10:46 PM
> Subject: Re: [Gluster-devel] glusterd crashes when synctask is used in conjunction with inner functions.
>
> On October 8, 2012 7:02:34 AM Krishnan Parthasarathi
> <kparthas at redhat.com> wrote:
> > I have been rewriting some of the volume operations (like
> > volume-start,
> > volume-add-brick, volume-remove-brick) using synctask library (aka
> > syncops).
> > This change has the following immediate benefits,
> >
> > - volume-start would return success/failure depending on the
> > success/failure of
> > brick process(es) spawned.
> > - would make glusterd's epoll thread 'more' available.
> >
> > </context>
> >
> > While I was making the changes in http://review.gluster.com/3969, I
> > noticed that
> > whenever the code executing on a synctask called into dict_foreach,
> > which was supplied
> > a function ptr, defined as an inner function, glusterd crashed.
> > When I rewrote
> > inner function as a static function, glusterd wouldn't crash.
> >
> > Has anyone seen or can explain (or give possible leads to analyse)
> > this
> > behaviour?
> > FWIW, inner functions are only available as part of GNU extensions
> > to C. So, I
> > assumed it is not such a bad thing to move the inner functions
> > 'out',
> > in my patch.
>
> Ugh. I noticed this pattern while I was looking at some AFR stuff
> recently. I thought it was rather clever, and pondered a bit about
> how
> it might be implemented in gcc/libc. Apparently it was a bit too
> clever, and the implementation leaves something to be desired. An
> inner function might be more elegant than defining private structures
> to pass through our own context pointer, but in the interest of both
> portability and not having to debug compiler code I think changing
> these to work the "old fashioned" way would actually be a good thing.
FWIW, inner functions also make it harder to debug with gdb (read breakpoints).
I am yet to demonstrably establish that inner functions' would
crash when run in synctask. I hope some of you might be able to shed
light on how I could resolve that.
thanks,
krish
>
>
>
More information about the Gluster-devel
mailing list