Re: Replacing linuxthreads with NGPT in Gentoo Linux

Am Sonntag den, 29. September 2002, um 20:59, schrieb Martin Schlemmer:

> I and some others have tried to replace linuxthreads with NGPT
> fairly early, and then only compiling against NGPT.
>
> I will have the NGPT setup running on my box for a week or two
> depending on response, but if none is accuired, I will be forced
> to do a clean install as currently many things that is a must
> on a desktop box do not work (XMMS, MPlayer, gliv, etc) :(

I think it would be good for ngpt to get xmms (mp3 player) going.

xmms can make use of _lots_ of plugins that are dlopen()ed on startup.
I got xmms running on SMP when removing most of plugins - because on SMP
the initialization runs amok? (see below)
Everything works until I define MAXNATIVETHREADS=1 on SMP - then
it get stuck like on UP (there it makes _little_ progress).
Seems that there's a problem with ngpt not being preemptive.

Nn SMP I link /lib/libpthread.so.0 to ngpt.
I do an "ulimit -s 1000" to get a stacktrace with all
plugins under /usr/X11R6/lib/xmms/ loaded:
(I get similar stacktraces when I remove crossfade plugin)

#0  0x40047ef8 in pth_mutex_release () from /lib/libpthread.so.0
#1  0x400382f9 in pthread_mutex_unlock () from /lib/libpthread.so.0
#2  0x403a1358 in malloc () from /lib/libc.so.6
#3  0x40358f0a in _nl_make_l10nflist () from /lib/libc.so.6

[...]
#4429 0x40356ee5 in __dcigettext () from /lib/libc.so.6
#4430 0x40356690 in dcgettext () from /lib/libc.so.6
#4431 0x0807eb43 in segfault_handler ()
#4432 0x400382f9 in pthread_mutex_unlock () from /lib/libpthread.so.0
#4433 0x403a1358 in malloc () from /lib/libc.so.6
#4434 0x40358f0a in _nl_make_l10nflist () from /lib/libc.so.6
#4435 0x40357b4d in _nl_find_domain () from /lib/libc.so.6
#4436 0x40356ee5 in __dcigettext () from /lib/libc.so.6
#4437 0x40356690 in dcgettext () from /lib/libc.so.6
#4438 0x0807eb43 in segfault_handler ()
#4439 0x400382f9 in pthread_mutex_unlock () from /lib/libpthread.so.0
#4440 0x403a1358 in malloc () from /lib/libc.so.6
#4441 0x4021ca7c in g_malloc () from /usr/lib/libglib-1.2.so.0
#4442 0x4022676e in g_strsplit () from /usr/lib/libglib-1.2.so.0
#4443 0x4009c9c9 in xmms_cfg_open_file () from 
/usr/X11R6/lib/libxmms.so.1
#4444 0x4068ea9c in get_oplugin_info ()
    from /usr/X11R6/lib/xmms/Output/libcrossfade.so
#4445 0x4068bd4d in get_oplugin_info ()
    from /usr/X11R6/lib/xmms/Output/libcrossfade.so
#4446 0x08062d24 in init_plugins ()
#4447 0x0810d4bd in skin_default_viscolor ()
#4448 0x2f007475 in ?? ()
Cannot access memory at address 0x7074754f

The recursion is due to an "i18n" segfault handler in xmms:

void segfault_handler(int sig)
{
         printf(_("\nSegmentation fault\n\n"
                  "You've probably found a bug in XMMS, please visit\n"
                  "http://bugs.xmms.org and fill out a bug report.\n\n"));
         exit(1);
}

Note: there is NO pthread_mutex_lock in the stacktrace.
I don't understand the comment in pthread.c:922:
/*
**  MUTEX ROUTINES
**      NOTE:   We need to use the thread safe libc malloc routine.  
Therefore,
**              it is necessary for us to export these entries so that 
the stock
**              libc will think that we are the stock libpthread and use 
the
**              thread safe malloc.  However, during initialization, 
we're single
**              threaded and can use the normal malloc.  So, we 'fake' 
the mutex
**              operations until we get fully initialized after which we 
let
**              the normal mutex operations do their stuff.  We also do 
this
**              during shutdown.
*/

xmms:main.c:
         init_plugins();

         /* Plugins might start threads that can call gtk */
         GDK_THREADS_ENTER();

It seems that xmms plugins spawn some threads, and ngpt initialization
is running astray?