bugThe FreeType Project - Bugs: bug #25479, Null pointer assigments at...

 
 

bug #25479: Null pointer assigments at different locations

Submitted by:  Andreas Kunschke <systing>
Submitted on:  Tue 03 Feb 2009 07:06:42 AM UTC  
 
Severity: 3 - NormalItem Group: Crash
Status: Works For MePrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 04 Feb 2009 08:36:40 AM UTC, comment #6:

Because freetype2 cache system runs well, we will create a patch for this problem in the next time.
May be that where are some special compiling strategies for risc archictures which you can't see on cisc systems.
But nevertheless I would indicate that this sort of programming is really tricky (and I also used this tricks in the past) but heavy to port in the next time, because of the new compiler development strategies.
Thank you for your fast assistance.

Andreas Kunschke <systing>
Wed 04 Feb 2009 07:49:48 AM UTC, comment #5:

With gcc 4.3.2, I still can't repeat your results on my
x86 GNU/Linux box, using exactly the same compiler options.
Either the problem is specific to the PPC platform or to gcc
4.2.2, and later versions can fix this automagically (or
there is a bug in recent gcc versions so that those warnings
are no longer reported).

The summary is that if you want this fixed, I need patches
from you since I have no possibility to test it by myself.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 03 Feb 2009 09:56:27 AM UTC, comment #4:

in the following you see the compiling result with #undef FTC_INLINE:
ppc_4xxFP-gcc -ansi -pedantic -I./objs -I./builds/ppc -I./include -c -Wall -O2 -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="<ftmodule.h>" -I./src/smooth -o objs/smooth.o ./src/smooth/smooth.c
ppc_4xxFP-gcc -ansi -pedantic -I./objs -I./builds/ppc -I./include -c -Wall -O2 -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="<ftmodule.h>" -I./src/cache -o objs/ftcache.o ./src/cache/ftcache.c
In file included from ./src/cache/ftcache.c:23:
./src/cache/ftcmanag.c: In function 'FTC_Manager_LookupSize':
./src/cache/ftcmanag.c:197: warning: dereferencing type-punned pointer will break strict-aliasing rules
./src/cache/ftcmanag.c: In function 'FTC_Manager_LookupFace':
./src/cache/ftcmanag.c:323: warning: dereferencing type-punned pointer will break strict-aliasing rules
In file included from ./src/cache/ftcache.c:24:
./src/cache/ftccache.c: In function 'ftc_node_mru_up':
./src/cache/ftccache.c:79: warning: dereferencing type-punned pointer will break strict-aliasing rules
In file included from ./src/cache/ftcache.c:25:
./src/cache/ftccmap.c: In function 'FTC_CMapCache_Lookup':
./src/cache/ftccmap.c:374: warning: dereferencing type-punned pointer will break strict-aliasing rules
In file included from ./src/cache/ftcache.c:26:
./src/cache/ftcglyph.c: In function 'FTC_GCache_Lookup':
./src/cache/ftcglyph.c:190: warning: dereferencing type-punned pointer will break strict-aliasing rules

Andreas Kunschke <systing>
Tue 03 Feb 2009 09:41:50 AM UTC, comment #3:

First of all, the cache module is still experimental, mainly
because it can't be maintained well since David has zero time
to work on FreeType.

Now, I've undefined `FTC_INLINE' in ftcmru.h and compiled with
`-O3 -Wall'. I still don't get a single warning (using the CVS).

I've compiled with and without `FTC_INLINE' defined using
`-O3 -Wall -fno-inline', and I don't get a warning either.

Please tell me an exact recipe how to reproduce the warnings.
Not that I don't believe you, but I need a means to repeat it
in a generic way.

Of course, patches are always welcomed to fix this issue.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 03 Feb 2009 09:15:25 AM UTC, comment #2:

Hi Werner,
as you see in my example I took the code in none inline mode.
If you compile in standard mode with INLINE active you will never see any warning.
Why?
Please have a look to ftcmru.h to the inline definition of
FTC_MRULIST_LOOKUP_CMP. At line 192 the casting with (void*)
(FTC_MruNode)(void)&(node));
avoid this warning because the compiler ignore any type dependence after void*.
Now please compare this with
FTC_MruList_Lookup(&manager->sizes,scaler,(FTC_MruNode*)&node );
Here you see no casting to a void pointer which generates now the warning.
This uncovers the weak point of all this definitions.
Decoupling the definition one time the processors registers contains an undependend pointer which can be used a lot of program parts later. So no context between a null pointer assignment and this definition break is directly visible.
So please don't think inserting (void*) solves all this problems. This only cover all the weak point and makes it much more difficult to detect such errors.
Please refer to:
http://lists.opensuse.org/opensuse-programming-de/2003-09/msg00116.html
for more details.

Andreas Kunschke <systing>
Tue 03 Feb 2009 07:51:34 AM UTC, comment #1:

Interesting. If I compile freetype 2.3.8 on my GNU/Linux box
with `-O3 -Wall', which activates -fstrict-aliasing according
to the info pages of 4.3.2 (and -Wall includes
-Wstrict-aliasing), I don't get a single warning.

Can you elaborate?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 03 Feb 2009 07:06:42 AM UTC, original submission:

Package: Freetype2
Version: 2.1.7 up to 2.3.8

Compiling with ppc_4xxFP-gcc (version: 4.2.2) returns at many locations the warning "dereferencing type-punned pointer will break strict-aliasing rules"
This generates unpredicatical code with null pointer assignments at runtime if you compile your code without the compiler option -mno-strict-align. Using this option kills any code optimisation so that it can't be more than a workaround.

Example:

FTC_Manager_LookupSize( FTC_Manager manager,
FTC_Scaler scaler,
FT_Size *asize )
{
FT_Error error;
FTC_SizeNode node;
...
...
error = FTC_MruList_Lookup(&manager->sizes,scaler,(FTC_MruNode*)&node );
if ( !error )
*asize = node->size;
...
...

Casting the pointer node (FTC_MruNode)&node in this way and building an assigment like asize = node->size will not longer run stable with gcc-compilers newer than V3.3

For more information about this warning and its results please visit:
http://lists.opensuse.org/opensuse-programming-de/2003-09/msg00116.html
May be helpful for understanding thr problem.

Andreas Kunschke <systing>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by wl (Posted a comment)
  • -unavailable- added by systing (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 04 Feb 2009 07:50:40 AM UTCwlStatusNeed Info=>Works For Me
      Open/ClosedOpen=>Closed
    Tue 03 Feb 2009 07:51:34 AM UTCwlStatusNone=>Need Info
      Assigned toNone=>wl

    Back to the top


    Powered by Savane 3.1-cleanup1