- In what header file are flockfile(), funlockfile() defined?
- Under what conditions is strtok_r defined?
- For the segfault in g_print(), could you run 
  pango-querymodules under a debugger, break in g_print()
  then trace through and see what happens in detail? 

  My guess is that g_convert_with_fallback() is returning
  NULL because it can't open the converter between 
  UTF-8 and the results of g_get_charset(), but I'd 
  like to have that confirmed, and also find out what
  is the result of g_get_charset()

Thanks,
                               Owen

+- In what header file are flockfile(), funlockfile() defined?

stdio.h

+- 
Under what conditions is strtok_r defined?

#if defined(_REENTRANT) || 
defined(_THREAD_SAFE)
                /* _POSIX_REENTRANT_FUNCTIONS */
extern char     
*strtok_r __((char *, const char *, char **));
extern int      strerror_r __((int, char 
*, int));
#endif

+- For the segfault in g_print(), could you run
+  pango-
querymodules under a debugger, break in g_print()
+  then trace through and see what 
happens in detail?

I tried, but before it crashes I stepped thousands of lines 
and
still nothing happened. I'm not good at C because I don't use it
myself. Why 
don't you get rid of memcpy, which a dangerous C thing?
Success,

Manuel

Can you figure out why flockfile and funlockfile are
not being found, since pango-utils.c includes pango-utils.h
which includes stdio.h

What does 'glib-config --cflags gthread' produce? It should
include -D_REENTRANT on many systems, and Pango uses these
flags when compiling.

Almost any C function is "dangerous" in the sense that it
can cause a crash when called with invalid parameters.
memcpy no more or less than any other. In this case,
memcpy is being called from with your C library, so we
couldn't get rid of it even if we wnated to.

You probably need to use a combination of "step" and
"next" (or maybe called step over) to find the problem.
Unfortunately, there is not much I can do on the crash
until it is localized to a specific piece of code.
One thing that might help trace it down is if, in
strdup_convert, you add the line:

 g_print ("Charset is %s\n", charset);

And see what is printed out.

+Can you figure out why flockfile and funlockfile are
+not being found, since pango-
utils.c includes pango-utils.h
+which includes stdio.h

I can only think of one 
reason, that neither _REENTRANT nor
_THREAD_SAFE is defined.

+What does 
'glib-config --cflags gthread' produce? It should
+include -D_REENTRANT on many 
systems, and Pango uses these
+flags when compiling.

$ glib-config --cflags 
gthread
-I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include

+In 
this case,
+memcpy is being called from with your C library, so we
+couldn't get 
rid of it even if we wnated to.

I see, thanks.

+One thing that might help trace 
it down is if, in
+strdup_convert, you add the line:

I can't find this 
function.

Here's the last gdb output:
(gdb) step
g_propagate_error 
(dest=0xfffffffffffffffc, src=0x6) at gerror.c:228
228           return;
(gdb)
237     
}
(gdb)
g_convert_with_fallback (
    str=0x1400039e0 
"/usr/users/coul1358/local/lib/pango/1.0.0/modules/libpango-
arabic-x.so 
ArabicScriptEngineX PangoEngineShape PangoRenderX ", len=121,
    
to_codeset=0x14000700a "ISO-8859-1", from_codeset=0x30041036240 "UTF-8",
    
fallback=0x30041036248 "?", bytes_read=0x0, bytes_written=0x0, error=0x0)
    
at gconvert.c:719
719           return NULL;
(gdb)
862     }
(gdb)
0x30001031b30 in 
strdup_convert (
    string=0x1400039e0 
"/usr/users/coul1358/local/lib/pango/1.0.0/modules/libpan
go-arabic-x.so 
ArabicScriptEngineX PangoEngineShape PangoRenderX ",
    charset=0x14000700a 
"ISO-8859-1") at gmessages.c:535
535         return g_strconcat ("[Invalid UTF-8] ", 
string, NULL);
(gdb)
g_print (
    format=0xfffffffffffffffc <Error reading 
address 0xfffffffffffffffc: Invalid
 argument>) at gmessages.c:833
833               fputs 
(lstring, stdout);
(gdb)
831               gchar *lstring = strdup_convert (string, 
charset);
(gdb)
833               fputs (lstring, stdout);
(gdb)

Program received 
signal SIGSEGV, Segmentation fault.
0x3ff800d758c in __memccpy ()
(gdb) 
bt

+ Trace 20761

828             
fputs (string, stdout); /* charset is UTF-8 already */
829           else
830             {
831               gchar 
*lstring = strdup_convert (string, charset);
832
833               fputs (lstring, 
stdout);
834               g_free (lstring);
835             }
836           fflush (stdout);
837         }
(gdb) 
print lstring
No symbol "lstring" in current context.
(gdb) up
#2  
0x30001032ae4 in g_print (
    format=0x3ffc0097a30 "# ModulesPath = 
/usr/users/coul1358/local/lib/pango/1.
0.0/modules\n#\n") at 
gmessages.c:833
833               fputs (lstring, stdout);
(gdb) print lstring
$1 = (gchar 
*) 0x0

Hope this helps, Manuel

Owen, why is it interesting what 

glib-config --cflags gthread 

produces ? 
Wouldn't that be 

pkg-config --cflags gthread-2.0
 
nowadays ?

Also, it just occurs to me that we have a problem here if glib
has been configured with --
enable-threads=no and the system
headers declare these functions only when 
explicitly requested
via -D_REENTRANT or similar. The higher layers probably 
need
to use e.g. strtok vs. strtok_r depending on G_THREADS_ENABLED
being 
defined in glib.h or not. 

Yeah, pkg-config --cflags was what I meant, and what would be 
useful here.

The presence of --disable-threads has always seemed to me like a 
bad idea.

But bug #79472 contains a patch to get rid of strtok_r in
Pango, which is probably the right approach here.

[ For future reference ... one bug per problem is a bit easier
  to deal with ]

 - I've filed the the flockfile, strtok_r problems as bug 81668
   (I'll ignore the possibility that glib was configured
    with --disable-threads for now.)
 - The segfault is more or less the same as bug bug 77341 which
   is fixed in Pango. I've filed the Tru64-specific part
   as bug 81669.

And am closing this bug,