Re: glib-genmarshal seg fault solaris 2.6



James Henstridge <james daa com au> writes:

> Reed, Timothy A wrote:
> 
> >All,
> >	Under solaris 2.6 using gcc 3.0.4, glib-genmarshal will build, but
> >when it trys to run it seg faults.
> >
> >	Here is the output from the build:
> >
> >creating glib-genmarshal
> >echo "#ifndef __G_MARSHAL_H__" > xgen-gmh \
> >&& echo "#define __G_MARSHAL_H__" >> xgen-gmh \
> >&& ./glib-genmarshal --nostdinc --prefix=g_cclosure_marshal ./gmarshal.list
> >--header >> xgen-gmh \
> >&& echo "#endif /* __G_MARSHAL_H__ */" >> xgen-gmh \
> >&& (cmp -s xgen-gmh ./gmarshal.h || cp xgen-gmh ./gmarshal.h) \
> >&& rm -f xgen-gmh xgen-gmh~ \
> >&& echo timestamp > stamp-gmarshal.h
> >/bin/ksh: 16793 Segmentation Fault(coredump)	
> >
> This is the perl interpreter crashing.  It seems that the regular
> expressions in the script cause a stack overflow on some systems (with
> some versions of Perl).  I think the solution was to upgrade your Perl
> (not completely sure; see the gtk-devel-list archives).

That's what I thought of too. Except that:

 A) The perl glib-mkenums crash was fixed some time ago
 B) This is glib-genmarshal, not glib-mkenums and glib-genmarshal 
    is written in C

The first step in diagnosing this would be to get a backtrace
of wher eit is crashing. Using gdb, that would lok like:

 [ after crash ]
 cd gobject
 libtool gdb ./glib-genmarshal core
 (gdb) backtrace

(I assume dbx is somewhat similar if you aren't using GNU tools)

Regards,
                                        Owen



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]