Re: [XForms] fl_set_font_name() and segmentation fault error

[Jens Thoms Toerring]

Hi Max,

On Tue, Oct 27, 2009 at 08:33:07AM +0100, Max wrote:
> small addition to what I wrote this night: the even more reduced code
> attached to this email produces a segmentation fault error (or a BadFont X
> error if run within valgrind) only if the second call to fl_set_font_name()
> is included (line 27).
> 
> I have compared valgrind logs with one and two calls to this functions,
> results are attached. As you can see, the second call to fl_set_font_name()
> will trigger a bounce of errors related to invalid access memory and/or
> free() calls.
>
> I am not an X-expert, but it seems to me that X (or Xforms?) frees some 
> locations after that the first call to fl_set_font_name() is performed...

Unfortuantely, even after trying the test program with XForms
compiled in different ways (with and without debugging support
etc.) I'm not able to reproduce any of the effects you're getting,
neither concening segmentation faults (I guess it's from line 27,
isn't it?)/X errors nor the output of valgrind. For me the program
simply works without any problems and what valigrind outputs is
just

==12342== Memcheck, a memory error detector.
==12342== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==12342== Using LibVEX rev 1884, a library for dynamic binary translation.
==12342== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==12342== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation
framework.
==12342== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==12342== For more details, rerun with: -v
==12342== 
==12342== Use of uninitialised value of size 8
==12342==    at 0x56AD6CB: (within /usr/lib/libX11.so.6.2.0)
==12342==    by 0x56AE25F: (within /usr/lib/libX11.so.6.2.0)
==12342==    by 0x56AE48D: XrmQGetResource (in /usr/lib/libX11.so.6.2.0)
==12342==    by 0x56AED57: XrmGetResource (in /usr/lib/libX11.so.6.2.0)
==12342==    by 0x4E62598: fl_get_resource (flresource.c:658)
==12342==    by 0x4E62949: fli_get_app_resource (flresource.c:1447)
==12342==    by 0x4E629F1: fl_get_app_resources (flresource.c:1462)
==12342==    by 0x4E63646: fl_initialize (flresource.c:749)
==12342==    by 0x40069D: main (max.c:23)
==12342== 
==12342== Conditional jump or move depends on uninitialised value(s)
==12342==    at 0x56AD6F0: (within /usr/lib/libX11.so.6.2.0)
==12342==    by 0x56AE25F: (within /usr/lib/libX11.so.6.2.0)
==12342==    by 0x56AE48D: XrmQGetResource (in /usr/lib/libX11.so.6.2.0)
==12342==    by 0x56AED57: XrmGetResource (in /usr/lib/libX11.so.6.2.0)
==12342==    by 0x4E62598: fl_get_resource (flresource.c:658)
==12342==    by 0x4E62949: fli_get_app_resource (flresource.c:1447)
==12342==    by 0x4E629F1: fl_get_app_resources (flresource.c:1462)
==12342==    by 0x4E63646: fl_initialize (flresource.c:749)
==12342==    by 0x40069D: main (max.c:23)
==12342== 
==12342== ERROR SUMMARY: 216 errors from 2 contexts (suppressed: 10 from 2)
==12342== malloc/free: in use at exit: 181,449 bytes in 685 blocks.
==12342== malloc/free: 5,443 allocs, 4,758 frees, 563,769 bytes allocated.
==12342== For counts of detected errors, rerun with: -v
==12342== Use --track-origins=yes to see where uninitialised values come from
==12342== searching for pointers to 685 not-freed blocks.
==12342== checked 422,384 bytes.
==12342== 
==12342== LEAK SUMMARY:
==12342==    definitely lost: 0 bytes in 0 blocks.
==12342==      possibly lost: 0 bytes in 0 blocks.
==12342==    still reachable: 181,449 bytes in 685 blocks.
==12342==         suppressed: 0 bytes in 0 blocks.
==12342== Rerun with --leak-check=full to see details of leaked memory.

As you can see the only 2 complaints valgrind has are from places
several levels down within the X library and not related to any
fonts stuff (they are triggered by the line with fl_initialize()).
My X version is

X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0

and we both seem to be using libX11.so.6.2.0 (and I'm also using
a 64-bit system). gcc is

gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)

and valgrind is

valgrind-3.4.1-Debian

So I am sorry but I have no idea where these differences come
from and I don't even have an idea where to start trying to
figure out what's happening. Perhaps someone else here on the
mailing list could be so kind to test the program on their
machines and tell what they observe?

                             Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de