On Mar 13, 2008, at 2:42 AM, Alan W. Irwin wrote:
> The other point I want to make concerns segfaults which are defined as
> follows (by wikipedia): "A segmentation fault occurs when a program  
> attempts
> to access a memory location that it is not allowed to access, or  
> attempts to
> access a memory location in a way that is not allowed".
> http://en.wikipedia.org/wiki/Access_violation gives several  
> straightforward
> ways you can get those from C, but they miss the big one which is  
> memory
> management issues (i.e., reading or writing beyond the alloc'd memory)
> causing an indirect segfault.  As I understand it such memory  
> management
> issues do not directly cause a segfault, but they do cause you to  
> overwrite
> neighbouring alloc'd areas, and when you attempt to use pointers  
> from those
> overwritten areas, you end up accessing the wrong memory which  
> often, _but
> not always_ causes a segfault.

Agreed, but the segfault occurs because I did not think to check the  
return value of the function pango_cairo_create_layout(). It should  
return a pointer to a PangoLayout, but when it fails, as it does in  
our test case, it returns NULL. The program crashes when this null  
pointer is passed to the next function which expects a valid  
PangoLayout pointer. I can add a test for this and the program will  
no longer segfault, but this does not solve the problem of why  
pango_cairo_create_layout() is failing in the first place. Presumably  
it is trying to tell us something with the message:

(process:10860): GLib-GObject-WARNING **: cannot register existing  
type `PangoCairoFcFontMap'

Or maybe this could just mean that at some other point we are  
overwriting some crucial bit of memory?

Unfortunately I have not been able to trigger this bug using a simple  
cairo/pango program that contains just the apparently problematic  
function calls.


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Plplot-devel mailing list

Reply via email to