Re: problems building trunk in OpenBSD/i386

[Ken Raeburn]

On Jul 12, 2007, at 07:07, Eli Zaretskii wrote:
> > Date: Thu, 12 Jul 2007 02:37:33 -0700
> > From: Ryan Yeske <address@hidden>
> >
> > ./temacs --batch --load loadup bootstrap
> > pid 17656: Fatal error 'Cannot create kernel pipe' at line 200 in  
> > file /usr/src/lib/libpthread/uthread/uthread_init.c (errno = 24)
> > *** Signal 6
> >
> > EMACS_22_BASE is the last version that I know builds fine on this  
> > platform.
> >
> > Advice on how to proceed in debugging this appreciated.
>
> The backtrace indicates there's infinite recursion in gmalloc.c:
>
> > #365 0x08184f6d in __malloc_initialize () at gmalloc.c:615
> > #366 0x081856c1 in malloc (size=3072) at gmalloc.c:982
>
> These two lines repeat themselves again and again, with calls to other
> functions interspersed in between.
>
> I'm guessing that the infinite recursion causes Emacs to eventually
> run out of runtime stack, and then it dies with the above weird
> message, which really tells you that the program is in deep trouble.
>
> If you can step through the code in question with GDB and try to
> understand why it recurses, it will help.

The other parts of the stack trace indicate that the rest of the loop  
is in the C library -- pthread_once calls pthread_mutex_lock, which  
initializes some thread support code, which is causing some priority  
queue code to try to allocate storage, which winds up calling into  
gmalloc, which again ensures that initialization has been done by  
calling pthread_once.

The thread support in gmalloc.c appears to be turned on when gtk is  
available and selected and has the new file chooser interface, and  
pthread support is available.

As to how to fix it... I have no good idea at the moment.  I assume  
OpenBSD uses GCC exclusively; if the platform supports constructor  
attributes on functions, perhaps we could force __malloc_initialize  
to be called at program startup, without thread protection, and hope  
that threads don't get created before main starts.  It seems a bit  
dicey, but hey, so is replacing malloc. :-)  Trying to detect  
recursive calls as opposed to simultaneous calls from multiple  
threads seems tricky, with some of the thread support unavailable  
until after we finish.

It could probably be worked around by specifying a toolkit other than  
gtk, or turning off x11 support altogether, at configure time, until  
we get a real fix.

Ken