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

[Max]

Hi Jens,

just for the records: I have solved this morning the problem by installing 
adobe and lucida fonts (75 and 100 dpi). I had not them before as I did not 
need them (only ddd showed some X warnings concerning missing fonts).

The clue was given by another program (totalview) which refuses to start with 
the message "No font to start up with.". It was quite clear then what I had to 
do :)

I do not know how you consider this incidence, but I would tag it as a bug, as 
the library is not able to cope with missing fonts (do not worry, even more 
expensive programs failed to start w/o any useful message). If need an help to 
test a possible solution, drop me an email, I will be glad to give my 
contribution.

With the best regards,
Max

On Tuesday 27 October 2009, Jens Thoms Toerring wrote:
>  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
>