[gst-devel] Re: basicomega on i686

[Andy Wingo]

Hi Christian,

I really don't know what's up with i686 glibc and basicomega, if
anything. Your email is not a very good bug report :P Perhaps this issue
was sorted out already, but I wanted to mention one possibility, in case
the issue is still there. Of course I can't test this possibility, so
it's mere speculation...

As you know, omega cothreads uses up the stack in pieces, one piece per
element. It assumes that it has 2M of stack space to work with, divided
into 16 pieces (see the top of cothreads.c). Now this 2M size is
arbitrary, and based on the old pre-i686 glibc's default stack size.
For new threads in gstthread.c, we explicitly ask for a 2M stack. But
for the main thread, we never try to query or even change the size with
getrlimit/setrlimit(2). I would suggest looking here for a solution (try
calling setrlimit(RLIMIT_STACK,rlim_struct_for_2M).

So what might be happening is too many (more than 8) elements are being
put into the main thread and it's trying to use memory that doesn't
belong to it.

Note also that the STACK_SIZE macro in cothreads.c and the STACK_SIZE
macro in gstthread.c depend on each other.

Just keep in mind the saying about the worth of free advice :-)

Cheers,

Wingo.

On Sat, 2004-01-17 at 16:35, Christian Schaller wrote:
> Hi Andy,
> I want to add a task item to the tasklist on the new website for fixing
> basicomega on i686 glibc. I found this message when going through the
> old mails. Is this the explanation for basicomega not working on i686
> glibc?
> 
> Christian
> 
> On Wed, 2002-08-28 at 07:15, Andy Wingo wrote:
> > On Wed, 28 Aug 2002, Thomas Vander Stichele wrote:
> > 
> > > Is this something that might be useful to us ?
> > 
> > This is the reason that cothreads was borked on your redhat boxen,
> > because they provided 686 packages which enabled this new feature. The
> > thing is, getrlimit returns -1 for the max stack size for od libc's, so
> > this isn't of a whole lot of use. Maybe I can get the cothreads tests to
> > pass reliably if I think hard enough about it, though... I wuold be
> > interested about the possibility of 8M+ stacks, come to think of it.
> > 
> > peace,
> > 
> > wingo.
> > 
> > > 
> > > Thomas
> > > 
> > > ---------- Forwarded message ----------
> > > Date: Tue, 27 Aug 2002 14:43:10 -0600
> > > From: Vincent Cassi <cassi at vexcel.com>
> > > To: Jakub Jelinek <jakub at redhat.com>
> > > Cc: libc-alpha <libc-alpha at sources.redhat.com>
> > > Subject: Re: pthread_attr_setstacksize limitation
> > 
> > > > On Fri, Jul 26, 2002 at 04:01:30PM -0600, Vincent Cassi wrote:
> > > > > > It is enough if you just use an
> > > > {i686,alpha*,sparc*,s390*,ia64}-*-*
> > > > > > configured glibc (on i686 built with --enable-kernel=2.4.1 or
> > > > later).
> > > > > >
> > > > > >         Jakub
> > > > >
> > > > > Thanks for the quick answer but I do not understand what you mean.
> > > > > By enough, do you mean I don't have to use a stack size bigger than
> > > > > 2Mb ?
> > > > > Or do you mean it will be ok if I use a kernel later than 2.4.1. ?
> > > > >
> > > > > BTW, I use a 2.4.19-rcl kernel on a i686.
> > > >
> > > > If you configure glibc with i686-*-linux* --enable-kernel=2.4.1 or
> > > > later,
> > > > then it will use %gs based threads, which means thread stack sizes are
> > > > no longer limited to 2MB.
> > > >
> > > >         Jakub
> > 
> > > I have been out for a while, that's why I haven't sent you this email
> > > before.
> > 
> > > Thanks for all your help. I'm not anymore limited to 2MB of thread stack
> > > sizes.
> > 
> > > Now my limitation is 8MB (which is definitely better!) and I'm wondering
> > > if
> > > there is a way to have a bigger one?
> > > Or is it a kernel limitation ?
> > 
> > > Thank you for your time,
> > 
> > > Vincent
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Jabber - The world's fastest growing 
> > real-time communications platform! Don't just IM. Build it in! 
> > http://www.jabber.com/osdn/xim
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> > 
-- 
Andy Wingo <wingo at pobox.com>